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.comTCP handshake: 0.022, SSL handshake: 0.064

        上面命令中的w参数表示指定输出格式，timeconnect 变量表示 TCP 握手的耗时，timeappconnect 变量表示 SSL 握手的耗时（更多变量请查看文档和实例），s参数和o参数用来关闭标准输出。

        从运行结果可以看到，SSL 握手的耗时（64 毫秒）大概是 TCP 握手（22 毫秒）的三倍。也就是说，在建立连接的阶段，HTTPs 链接比 HTTP 链接要长 3 倍的时间，具体数字取决于 CPU 的快慢。

        所以，如果是对安全性要求不高的场合，为了提高网页性能，建议不要采用保密强度很高的数字证书。一般场合下，1024 位的证书已经足够了，2048 位和 4096 位的证书将进一步延长 SSL 握手的耗时。

        （完）