SSL延迟有多大？

据说，Netscape公司当年设计SSL协议的时候，有人提过，将互联网所有链接都变成HTTPs开头的加密链接。

这个建议没有得到采纳，原因之一是HTTPs链接比不加密的HTTP链接慢很多。（另一个原因好像是，HTTPs链接默认不能缓存。）

自从我知道这个掌故以后，脑袋中就有一个观念：HTTPs链接很慢。但是，它到底有多慢，我并没有一个精确的概念。直到今天我从一篇文章中，学到了测量HTTPs链接耗时的方法。

首先我解释一下，为什么HTTPs链接比较慢。

HTTPs链接和HTTP链接都建立在TCP协议之上。HTTP链接比较单纯，使用三个握手数据包建立连接之后，就可以发送内容数据了。

上图中，客户端首先发送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/ TLS证书服务的高可用性？ 如何解决SSL/ TLS证书服务的高可用性？ 全面的推广和应用SSL/TLS，会给站点安全性带来质的提升，彻底杜绝中间人攻击、网络劫持等攻击行为。但于此同时，考虑全站https之后的高可用保障时，SSL/TLS证书的安全性问题就逐步凸显出来。
一文解码：如何解决SSL/ TLS证书服务的高可用性？ 2017年1月份，Google将Chrome 56中所有的 http站点标记为不安全，并对所有使用http方式的登录交互页发出醒目的“不安全”提示。 Apple自2015年WWDC大会开始，就在计划逐步推进实施ATS(App与后台服务器通讯强制使用https通讯)的实施，并在2017年WWDC大会上发布明确的时间节点，使https服务成为所有iOS及MAC上App的标配。
阿里云环境中TLS/SSL握手失败的场景分析 TLS/SSL握手是一个相对复杂的过程，在阿里云环境中结合产品，安全等特性，可能会让TLS/SSL握手过程的不定性更多。本文来总结下各种握手失败的场景。
优化 Tengine HTTPS 握手时间 ## 背景 网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下，客户端打开一个链接需要DNS查询（1个 RTT），TCP握手（1个 RTT），TLS 握手（2个RTT），以及最后的 HTTP 请求和响应，可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间，而首字节时间对 web 体验非常重要，可以体现在网站的首屏时间，直接影响用户判断网站的快慢，所以首字节时间（TTFB）是
一文看懂https如何保证数据传输的安全性的 一文看懂https如何保证数据传输的安全性的 大家都知道，在客户端与服务器数据传输的过程中，http协议的传输是不安全的，也就是一般情况下http是明文传输的。但https协议的数据传输是安全的，也就是说https数据的传输是经过加密。
阮一峰 阿里技术专家。著名技术博客作者，技术方向为 React + Node，自由软件运动的支持者