据说,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握手的耗时。
(完)
陈佳 说:
现在计算资源和网络资源都提高了很多,可以推广https了。
2014年9月24日 22:06 | # | 引用
崔俊伟 说:
如果只是cpu的话倒是不怕
2014年9月24日 22:25 | # | 引用
TheFappening 说:
此文好像与以前的一篇矛盾了哦: www.ruanyifeng.com/blog/2011/02/seven_myths_about_https.html
2014年9月24日 22:55 | # | 引用
mz 说:
所以叫你们上SPDY
2014年9月24日 23:21 | # | 引用
nnkken 说:
2014年9月24日 23:25 | # | 引用
亮黑色书脊 说:
并不矛盾吧,这里说的是TCP连接建立的延时,没有考虑链接中提到的其他因素。虽然,本文最后的结论我并不赞同,HTTPS带来的好处在我看来远胜过性能的牺牲。
2014年9月24日 23:28 | # | 引用
b 说:
不光是这个,握手成功建立连接后每次传送数据还要加密解密,不过是用的对称加密会快些,不过还是比不加密来得慢
2014年9月24日 23:45 | # | 引用
笨乌不飞 说:
HTTPS everywhere by Google:
https://www.youtube.com/watch?v=cBhZ6S0PFCY&utm_source=wmx_blog&utm_medium=referral&utm_campaign=tls_en_post
2014年9月25日 00:34 | # | 引用
srs 说:
连接建立只占用传输全程的一小部分时间吧。
2014年9月25日 03:59 | # | 引用
fis 说:
种种原因,感觉现在已经到了不加密不行的阶段了
2014年9月25日 06:08 | # | 引用
小鱼 说:
这个测量结果只对比了一次完整的SSL握手与HTTP访问的区别。但实际使用环境中超过90%的HTTPS请求都是重用SSL Session的,交互次数和消息传输的开销都要小很多。
除了博主分析的SSL握手的交互次数多以外,实际环境中一次完整的SSL握手还会因为一些原因变得更慢:
1. 服务端发送的Server Certificate包可能包含上级证书链,在普遍使用2048位RSA的环境中,这个包会超过2K或者3K,在移动或慢速网络下可能会丢包并引起TCP的重传
2. 浏览器会检查服务端证书的吊销状态----根据服务端证书扩展项中的地址去下载黑名单或访问OCSP服务,如果这些地址无法访问或者被墙,则会让浏览器等上很长一段时间。
3. 如果是采用带客户端认证的SSL握手,浏览器遍历当前系统的可用证书时,可能会由于某些USBKey的驱动或CSP实现问题,卡住一段时间。
以上原因综合作用时,会让一次HTTPS访问慢到无法想象。
2014年9月25日 09:35 | # | 引用
TONYHEAD 说:
我因为又拍云的二级域名需要花费5秒在SSL Negotiation上所以把网站前台切换回HTTP了。
2014年9月25日 23:34 | # | 引用
daming 说:
做科普可以,但是不懂装懂误导别人就不对了。
一年以前 Google 等各大厂商已经把 TLS 的证书升级到 2048 bits了,1024 已经不太够了
2014年9月28日 09:54 | # | 引用
ml 说:
关键问题是HTTP协议本身,keep-alive,
连接复用,就不用重新握手了。
握手是慢点,中间的加密与不加密,耗时差不多。
2014年9月28日 21:36 | # | 引用
chinassl 说:
现在1024位加密已经过时了,现在所有SSL证书签发要求都是2048位起的,文章写的不错
2014年10月21日 10:35 | # | 引用
sapwood 说:
今天的CPU都支持加密指令,加密已经是稀松平常的事情。还有,虽然HTTPS链接通信次数比HTTP多。但建立在HTTPS之上的SPDY可以复用链接。这样其实比HTTP省。
2014年10月22日 00:14 | # | 引用
abc 说:
习惯用https,另外https引用图片不能缓存吗?表示怀疑,如果没有超过上次请求的过期时间(或者服务器304),应该可以使用本地缓存的。
2014年10月31日 11:21 | # | 引用
SSL 说:
SPDY 会让mac用户很郁闷的,也有可能是mac下的spdy相关程序算法有bug,亲测Mac下访问spdy网站,会阻塞10+s,关闭浏览器spdy支持一均ok。
2014年11月 3日 10:38 | # | 引用
小谈博客 说:
明白了,https慢的原因和加密的关系,文章讲的很通俗易懂,教科书这样写就好了!
2014年11月13日 17:30 | # | 引用
superwiles 说:
应该说的具体一些,其实瓶颈是在 cpu 处理大整数模乘法这块。
具体一点 RSA 1k 已经基本淘汰, RSA2k 是主流 DH 这些也有人会用。
以后RSA 8k 也许会成为主流,用硬件加速可以解决这个问题。
2015年2月 2日 00:03 | # | 引用
luolie 说:
很到位,每次看阮兄博文都收获不小
2015年4月18日 21:15 | # | 引用
linchen 说:
阮老师其实是来秀网速的,他的是0.022 0.064,而我的是0.176 0.354。
2015年5月29日 22:56 | # | 引用
光网烈火 说:
延迟基本上感觉不到
2015年6月 2日 01:07 | # | 引用
jiemo 说:
发现不怎么靠谱,估计都是从别人那抄过来的。没有验证过吧。
同一个博客中有两个相互矛盾的文章
2015年9月18日 10:59 | # | 引用
lulianqi15 说:
非对称算法是一个数学算法,本身非常耗时(这也是这种算法安全的原因之一,而即使加密速度靠硬件提升了,必然的被破解的代价也会随硬件的升级而变小,所以必须使用更大的KEY,这样速度又会降下来)。如果所有http都使用ssl/tls的话,那每次握手都可能需要密钥的生成,或者至少需要使用非对称算法解密通讯密钥(实际数据也不会使用非对称算法,代价太大)。这样对服务器运算能力的要求就会异常的大,一般服务提供方是无法承受的。所以个人觉得都用https不太现实,未来应该会出现低耗高效的模式
2015年11月 2日 14:41 | # | 引用
toykou 说:
我的小站使用过startssl和沃通免费SSL,我感觉后者速度要快很多,和http比起来,好像感觉没有明显延时。
2015年11月24日 09:05 | # | 引用
LIUTONG 说:
越看越糊涂
2016年1月18日 11:42 | # | 引用
嘻嘻 说:
我是从网页开始学程序的,尽管网页代码还没加密,但如果这一块也开始变乱码!!!以后的人自学会更加困难,反编译和解密一样,属于大师,如果网页也加密了,天底下哪里去找这么庞大的免费代码!其实,大家都不要实名上网就会好很多,除非有人想比赛加密
2016年11月 1日 15:39 | # | 引用
lmath 说:
HTTPS 仅仅加密传输过程,代码到浏览器的后就会被解密,所以你依然可以在你访问的页面上看到明文的代码。
2017年4月13日 23:35 | # | 引用
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:峰哥,您好,很喜欢您的博客,带给我很多帮助,诚挚感谢。
2017年8月 2日 15:36 | # | 引用
业余草 说:
“自从我知道这个掌故以后”,文中提到的掌故是什么意思?第一次听说,是典故的意思吗?
2017年9月26日 14:34 | # | 引用
搬砖工 说:
time_appconnect 指的应该是从开始链接到ssl握手完成总共耗时,这个时间是包含time_connect的
2019年1月26日 11:06 | # | 引用
冰枫火灵X 说:
如果SSL证书的管理权都集中在少数人或者经过“授权”的人手里,那我肯定反对HTTPS和SSL。但是现实是:其实完全可以用openssl这个自由软件生成SSL证书,所以是完全自由开放的技术,你可以:
openssl req -newkey rsa:8192 -nodes -x509 -keyout xx.key -out xx.crt -days 999999
然后就可以享用了。
2019年12月 9日 20:50 | # | 引用
xyf 说:
然而依然是这样,只不过有开源的组织给我们把一些事情给做了
2021年10月29日 10:58 | # | 引用