建议一:现在是否需要迁移到HTTP/2
最后更新于:2022-04-01 04:49:37
实现HTTP/2很简单,看看我们的白皮书就明白了([PDF](https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf))。不过,HTTP/2并不是万能的银弹,它只对某些Web应用有用,对另外一些则没那么有用。
如果你使用SSL/TLS(以后简称TLS),那么HTTP/2可以提升网站性能。如果你没有,那在使用HTTP/2之前要先支持TLS。这时候,使用TLS的性能损耗大致可以被使用HTTP/2的性能提升抵销。不过还是建议你在实际应用之前先测试一下。
HTTP/2有五大优势。
1. 每个服务器只用一个连接。HTTP/2对每个服务器只使用一个连接,而不是每个文件一个连接。这样,就省掉了多次建立连接的时间,这个时间对TLS尤其明显,因为TLS连接费时间。
2. 加速TLS交付。HTTP/2只需一次耗时的TLS握手,并且通过一个连接上的多路利用实现最佳性能。HTTP/2还会压缩首部数据,省掉HTTP/1.x时代所需的一些优化工作,比如拼接文件,从而提高缓存利用率。
3. 简化Web应用。使用HTTP/2可以让Web开发者省很多事,因为不用再做那些针对HTTP/1.x的优化工作了。
4. 适合内容混杂的页面。HTTP/2特别适合混合了HTML、CSS、JavaScript、图片和有限多媒体的传统页面。浏览器可以优先安排那些重要的文件请求,让页面的关键部分先出现,快出现。
5. 更安全。通过减少TLS的性能损失,可以让更多应用使用TLS,从而让用户信息更安全。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-11-13_56455e8965d6c.png)
HTTP/2的多路复用示意图
相应地,HTTP/2也有五个不足之处。
1. 单连接开销比较大。HPACK数据压缩算法会更新两端的查找表。这样可以让连接有状态,而破坏状态就意味着要重建查找表,另外单连接占用内存较多。
2. 你可能不需要SSL。如果你的数据不需要保护,或者已经使用DRM或其他编码进行保护了,那么TLS的安全性对你可能无所谓。
3. 需要抛弃针对HTTP/1.x的优化。HTTP/1.x优化在支持HTTP/2的浏览器中会影响性能,因此可能需要花时间把它们推倒重来。
4. 对下载大文件不利。如果你的应用主要提供大文件下载或者流媒体播放,那可能不想用TLS,而且在只有一个流的情况下,多路复用也体现不出什么优势。
5. 你的客户也许不在乎。你的客户很可能不在乎他分享的自家猫咪的视频是否受到TLS和HTTP/2的保护。
总之,一切要看性能。这方面,有好消息也有坏消息。
好消息是我们在内部对NGINX做过测试,结果从理论上能够得到印证:对于要通过典型网络延迟请求的混合内容网页,HTTP/2的性能好于HTTP/1.x和HTTPS。基于连接的RTT,结果可以分三种情况。
* 很低的RTT(0-20ms):HTTP/1.x、HTTP/2和HTTPS基本无差别。
* 典型网络RTT(30-250ms):HTTP/2比HTTP/1.x快,而且它们都比HTTPS快。美国两个相邻城市间的RTT约为30 ms,而东西海岸间(约3000英里)则约为70 ms。东京到伦敦间最短路径的RTT大约240 ms。
* 高RTT(300ms及以上):HTTP/1.x比HTTP/2快,后者又比HTTPS快。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-11-13_56455e898fa42.png)
这张图显示了首次渲染的时间,也就是用户第一次在自己屏幕上看到网页内容的时间。这个时间一般认为关系到用户对网站响应速度的感知。
要想了解我们测试的更多内容,请看这个[HTTP/2的介绍视频](https://www.youtube.com/watch?v=4OiyssTW4BA&feature=youtu.be),来源是nginx.conf 2015。
然而,每个网页都不相同,实际上每个用户的会话也不一样。如果你托管流媒体或提供大文件下载,那你的决定可能不一样,甚至相反。
你最终可能发现投入产出比并不明显。如果是这样,那你得多学习一下,针对自己的内容多做一些测试,然后咱们可以聊一聊。(想找点资料?可以看看NGINX网络研讨:[What’s New in HTTP/2?](https://www.nginx.com/resources/webinars/whats-new-in-http2/))。