SSL延迟有多大?

作者: 阮一峰

日期: 2014年9月24日

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

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

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

slow connection

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

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

tcp handshake

上图中,客户端首先发送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握手的耗时。

(完)

珠峰培训

stuQ

留言(30条)

现在计算资源和网络资源都提高了很多,可以推广https了。

如果只是cpu的话倒是不怕

此文好像与以前的一篇矛盾了哦: www.ruanyifeng.com/blog/2011/02/seven_myths_about_https.html

所以叫你们上SPDY

引用陈佳的发言:

現在計算資源和網絡資源都提高了很多,可以推廣https了。

但是網絡應用傳輸量也提高了很多……

引用TheFappening的发言:

此文好像与以前的一篇矛盾了哦: www.ruanyifeng.com/blog/2011/02/seven_myths_about_https.html

并不矛盾吧,这里说的是TCP连接建立的延时,没有考虑链接中提到的其他因素。虽然,本文最后的结论我并不赞同,HTTPS带来的好处在我看来远胜过性能的牺牲。

不光是这个,握手成功建立连接后每次传送数据还要加密解密,不过是用的对称加密会快些,不过还是比不加密来得慢

连接建立只占用传输全程的一小部分时间吧。

种种原因,感觉现在已经到了不加密不行的阶段了

这个测量结果只对比了一次完整的SSL握手与HTTP访问的区别。但实际使用环境中超过90%的HTTPS请求都是重用SSL Session的,交互次数和消息传输的开销都要小很多。

除了博主分析的SSL握手的交互次数多以外,实际环境中一次完整的SSL握手还会因为一些原因变得更慢:
1. 服务端发送的Server Certificate包可能包含上级证书链,在普遍使用2048位RSA的环境中,这个包会超过2K或者3K,在移动或慢速网络下可能会丢包并引起TCP的重传
2. 浏览器会检查服务端证书的吊销状态----根据服务端证书扩展项中的地址去下载黑名单或访问OCSP服务,如果这些地址无法访问或者被墙,则会让浏览器等上很长一段时间。
3. 如果是采用带客户端认证的SSL握手,浏览器遍历当前系统的可用证书时,可能会由于某些USBKey的驱动或CSP实现问题,卡住一段时间。

以上原因综合作用时,会让一次HTTPS访问慢到无法想象。

我因为又拍云的二级域名需要花费5秒在SSL Negotiation上所以把网站前台切换回HTTP了。

做科普可以,但是不懂装懂误导别人就不对了。
一年以前 Google 等各大厂商已经把 TLS 的证书升级到 2048 bits了,1024 已经不太够了

关键问题是HTTP协议本身,keep-alive,
连接复用,就不用重新握手了。
握手是慢点,中间的加密与不加密,耗时差不多。


现在1024位加密已经过时了,现在所有SSL证书签发要求都是2048位起的,文章写的不错

今天的CPU都支持加密指令,加密已经是稀松平常的事情。还有,虽然HTTPS链接通信次数比HTTP多。但建立在HTTPS之上的SPDY可以复用链接。这样其实比HTTP省。

习惯用https,另外https引用图片不能缓存吗?表示怀疑,如果没有超过上次请求的过期时间(或者服务器304),应该可以使用本地缓存的。

引用mz的发言:

所以叫你们上SPDY

SPDY 会让mac用户很郁闷的,也有可能是mac下的spdy相关程序算法有bug,亲测Mac下访问spdy网站,会阻塞10+s,关闭浏览器spdy支持一均ok。

明白了,https慢的原因和加密的关系,文章讲的很通俗易懂,教科书这样写就好了!

应该说的具体一些,其实瓶颈是在 cpu 处理大整数模乘法这块。
具体一点 RSA 1k 已经基本淘汰, RSA2k 是主流 DH 这些也有人会用。
以后RSA 8k 也许会成为主流,用硬件加速可以解决这个问题。

很到位,每次看阮兄博文都收获不小

阮老师其实是来秀网速的,他的是0.022 0.064,而我的是0.176 0.354。

延迟基本上感觉不到

发现不怎么靠谱,估计都是从别人那抄过来的。没有验证过吧。
同一个博客中有两个相互矛盾的文章

非对称算法是一个数学算法,本身非常耗时(这也是这种算法安全的原因之一,而即使加密速度靠硬件提升了,必然的被破解的代价也会随硬件的升级而变小,所以必须使用更大的KEY,这样速度又会降下来)。如果所有http都使用ssl/tls的话,那每次握手都可能需要密钥的生成,或者至少需要使用非对称算法解密通讯密钥(实际数据也不会使用非对称算法,代价太大)。这样对服务器运算能力的要求就会异常的大,一般服务提供方是无法承受的。所以个人觉得都用https不太现实,未来应该会出现低耗高效的模式

我的小站使用过startssl和沃通免费SSL,我感觉后者速度要快很多,和http比起来,好像感觉没有明显延时。

越看越糊涂

我是从网页开始学程序的,尽管网页代码还没加密,但如果这一块也开始变乱码!!!以后的人自学会更加困难,反编译和解密一样,属于大师,如果网页也加密了,天底下哪里去找这么庞大的免费代码!其实,大家都不要实名上网就会好很多,除非有人想比赛加密

引用嘻嘻的发言:

我是从网页开始学程序的,尽管网页代码还没加密,但如果这一块也开始变乱码!!!以后的人自学会更加困难,反编译和解密一样,属于大师,如果网页也加密了,天底下哪里去找这么庞大的免费代码!其实,大家都不要实名上网就会好很多,除非有人想比赛加密

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:峰哥,您好,很喜欢您的博客,带给我很多帮助,诚挚感谢。

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接