上图中，客户端首先发送SYN数据包，然后服务器发送SYN+ACK数据包，最后客户端发送ACK数据包，接下来就可以发送内容了。这三个数据包的发送过程，叫做TCP握手。
再来看HTTPs链接，它也采用TCP协议发送数据，所以它也需要上面的这三步握手过程。而且，在这三步结束以后，它还有一个
SSL握手
。
总结一下，就是下面这两个式子。
HTTP耗时 = TCP握手
HTTPs耗时 = TCP握手 + SSL握手
所以，HTTPs肯定比HTTP耗时，这就叫SSL延迟。
命令行工具
curl
有一个w参数，可以用来测量TCP握手和SSL握手的具体耗时，以访问支付宝为例。
$ curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://www.alipay.com
TCP handshake: 0.022, SSL handshake: 0.064
上面命令中的w参数表示指定输出格式，time_connect变量表示TCP握手的耗时，time_appconnect变量表示SSL握手的耗时（更多变量请查看
文档
和
实例
），s参数和o参数用来关闭标准输出。
从运行结果可以看到，SSL握手的耗时（64毫秒）大概是TCP握手（22毫秒）的三倍。也就是说，在建立连接的阶段，HTTPs链接比HTTP链接要长3倍的时间，具体数字取决于CPU的快慢和网络状况。
所以，如果是对安全性要求不高的场合，为了提高网页性能，建议不要采用保密强度很高的数字证书。一般场合下，1024位的证书已经足够了，2048位和4096位的证书将进一步延长SSL握手的耗时。
这个测量结果只对比了一次完整的SSL握手与HTTP访问的区别。但实际使用环境中超过90%的HTTPS请求都是重用SSL Session的，交互次数和消息传输的开销都要小很多。
除了博主分析的SSL握手的交互次数多以外，实际环境中一次完整的SSL握手还会因为一些原因变得更慢：
1. 服务端发送的Server Certificate包可能包含上级证书链，在普遍使用2048位RSA的环境中，这个包会超过2K或者3K，在移动或慢速网络下可能会丢包并引起TCP的重传
2. 浏览器会检查服务端证书的吊销状态----根据服务端证书扩展项中的地址去下载黑名单或访问OCSP服务，如果这些地址无法访问或者被墙，则会让浏览器等上很长一段时间。
3. 如果是采用带客户端认证的SSL握手，浏览器遍历当前系统的可用证书时，可能会由于某些USBKey的驱动或CSP实现问题，卡住一段时间。
以上原因综合作用时，会让一次HTTPS访问慢到无法想象。
time_appconnect:The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.
从手册上的解释来看这个参数指的是HTTPs的耗时，而不只是SSL握手的耗时。
ps：峰哥，您好，很喜欢您的博客，带给我很多帮助，诚挚感谢。
引用letslawful的发言：
time_appconnect:The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.
从手册上的解释来看这个参数指的是HTTPs的耗时，而不只是SSL握手的耗时。
ps：峰哥，您好，很喜欢您的博客，带给我很多帮助，诚挚感谢。
time_appconnect 指的应该是从开始链接到ssl握手完成总共耗时，这个时间是包含time_connect的
如果SSL证书的管理权都集中在少数人或者经过“授权”的人手里，那我肯定反对HTTPS和SSL。但是现实是：其实完全可以用openssl这个自由软件生成SSL证书，所以是完全自由开放的技术，你可以：
openssl req -newkey rsa:8192 -nodes -x509 -keyout xx.key -out xx.crt -days 999999
然后就可以享用了。
引用冰枫火灵X的发言：
如果SSL证书的管理权都集中在少数人或者经过“授权”的人手里，那我肯定反对HTTPS和SSL。但是现实是：其实完全可以用openssl这个自由软件生成SSL证书，所以是完全自由开放的技术，你可以：
openssl req -newkey rsa:8192 -nodes -x509 -keyout xx.key -out xx.crt -days 999999
然后就可以享用了。
