Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

https 性能的坑

  我们都知道,TLS 传输是需要加密的,于是有人就担心传输的加解密会耗费服务器资源。实际上传输过程的加密是对称加密,并不会占用太多资源。反而是建立连接的那一步使用的是非对称加密,会耗费较多资源。所以在架构上我们就应该考虑如何合理分配这部分开销。
  TLS 的问题并不在于传输过程中的数据加解密,而是在于连接建立时需要进行非对称加密。如果请求是大量且零碎的短连接,服务器需要和每个短连接的客户端建立 TLS,于是大量的非对称加密就会使服务器的 CPU 负载就会变得非常高。非对称加密的性能比对称加密低好几个数量级,建立连接加解密的数据量虽然不大,但也相当于同等数据量对称加密成千上万次的开销了。
  网络上的很多文章介绍 https 的性能时经常都说它比普通的 http 慢三倍左右。确实如果自己做一个测试,拿一个 http 请求和 https 请求的耗时来做比较可以得到这样的结果。但是!问题不在这儿。当同一台服务器处理大量请求时,也许前 200 个请求已经把 CPU 就跑满了,之后的请求就会变得非常慢。甚至后续的请求会一直积压,直到超时。
  对于 https 的场景,外层的负载均衡应该使用四层代理服务器来做(好像 nginx 1.9 后也支持四层代理了),把计算密集型的非对称加解密分布到应用集群的每个服务器上。又或者如果担心这些 CPU 开销影响到业务的话,可以专门搞一个计算密集型的集群来处理 https 握手,然后再转发到业务集群上。
  玩好 https 不是光看建立连接的耗时那么简单。要考虑 CPU 瓶颈,考虑如何转嫁这些运算量到其它 CPU 相对空闲的机器上。
  另外,不要再问 https 比 http 慢多少,应该问 https 比 http 多消耗多少资源。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^