别让SSL握手时间偷走你的用户，CDN优化实战

很多朋友问我，为什么网站上了CDN，首屏还是慢？我通常先让他测一下SSL握手时间，什么？你从来没注意过这个指标？那今天咱们就把这个“隐形杀手”扒个干净。

先讲原理，你去访问一个HTTPS网站，浏览器和服务器要先“握手”，互相确认身份，商量加密方式，这就像进小区门，保安要看你的证件，还要登记，一来一回好几个步骤，这个过程的耗时就是SSL握手时间，它不包括下载网页内容，纯粹是“交朋友”的时间，在传统连接下，TCP三次握手要1.5个RTT（往返时间），TLS握手要1-2个RTT，加起来差不多3个RTT，如果你的服务器在海外，一个RTT要200毫秒，那光握手就快一秒了,用户等得心里发毛。

CDN怎么解决？CDN把服务器部署到用户旁边，让RTT从200毫秒变成20毫秒，但是注意！很多人以为上了CDN，SSL握手时间就自动归零，错，CDN只是把边缘节点和你用户之间的RTT缩短了，但边缘节点到源站的回源链路呢？如果源站很远，或者回源也要重新做SSL握手，那用户的首次访问依然可能卡顿，这里有个核心概念：SSL握手时间分为“客户端到边缘”和“边缘到源站”两段，用户访问时，客户端与CDN边缘节点握手，如果命中了缓存，边缘节点无需回源，那用户感知的SSL握手时间就是客户端到边缘这一段，很短，如果没命中缓存，边缘节点需要回源，那源站那边还有一段SSL握手，但这一段通常不会让用户直接等，因为CDN可以提前与源站建立连接并复用,也就是连接池技术。

别让SSL握手时间偷走你的用户，CDN优化实战

应用场景很典型，比如一个做跨境电商的网站，用户遍布全球，源站部署在美国，以前用户直接连源站，欧洲用户平均SSL握手时间要400毫秒，亚洲用户要350毫秒，上了CDN后，全球用户都连最近的节点，SSL握手时间降到50毫秒以内，但注意，如果CDN没配置会话复用（TLS session resumption），每次请求都要重新握手，那时间又会飙回去，会话复用就是让浏览器和边缘节点记住之前的“暗号”，下次直接对暗号，不用再走完整流程，我见过一个客户，启了CDN但没开TLS会话复用，SSL握手时间还是200多毫秒,白白浪费了CDN的作用。

再讲一个真实案例，有个视频网站，页面加载很慢，技术团队查了半天，发现网络请求里一个JS文件的SSL握手时间长达800毫秒，他们以为CDN失效了，实际上呢？那个JS文件放在另一个域名下，而这个域名没有接入CDN，还挂在源站上，用户访问时，HTML从CDN边缘秒开，但解析到那个外部JS，又得重新走一遍到源站的TCP+SSL握手，这就像你坐高铁到了市中心，结果出站后还要骑着破自行车去郊区，记得把所有静态资源都接入CDN，并且统一使用同一个域名,或者至少保证每个资源域名的SSL握手时间都短。

常见误区还有：一，SSL握手时间只有首次访问才有，不对，会话复用失效后，每次都要握手；而且现在浏览器对并发连接限制，同一个站点有多个连接，每个连接都可能进行TLS握手，二，只要用了HTTP/2就不需要优化SSL握手时间？HTTP/2只是多路复用，握手流程仍然存在，而且HTTP/2握手还要加上ALPN协商，三，用测速工具看整体加载时间就觉得无所谓，你要看瀑布图里那个“TLS Handshake”或者“SSL”那一栏，很多工具默认不展开,你得自己点开。

告诉你一个傻瓜式优化法，如果你用CDN，第一，选支持TLS 1.3的边缘节点，它把握手从2个RTT压缩到1个RTT；第二，开启TLS session resumption；第三，配置OCSP stapling，减少证书链验证的额外请求；第四，最重要，监控你的SSL握手时间，分地域、分运营商去监控，如果某个地区SSL握手时间突然涨了，那可能是当地节点有问题，或者你的CDN调度策略把用户导到了远的节点，CDN不是一装了事，SSL握手时间是你跟用户之间的“第一道门槛”，这道门槛要是太高，后面内容再快也白搭，用户的手指头就在“刷新”键上，你给他800毫秒的等待，他就敢给你80%的跳出率，别让SSL握手时间偷走你的用户，现在就打开控制台,看看那个数字吧。