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 握手的具体耗时,以访问支付宝为例。

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

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

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

(完)

1 收藏 3 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 1、可惜1024位已经被破,且很多证书提供商不再提供1024位证书了。根据NSA的运算能力,用1024和不加密没有多大区别。
    2、po主一定不知道SSL可以重用上个连接的握手结果,况且HTTP/1.1支持Keep-Alive重用连接。
    3、以上两点在今年的Google I/O大会上有证明。po主一定没有认真看。

  • 所以一要开启 Keep-Alive,二要使用椭圆曲线。最好使用 CloudFlare 这样的 CDN 服务。CDN 用得好,一个来回省下的就上百毫秒了。

跳到底部
返回顶部