当前位置: 代码迷 >> 综合 >> HTTP2 十分钟速知
  详细解决方案

HTTP2 十分钟速知

热度:61   发布时间:2024-01-16 23:53:14.0

HTTP/2 十分钟速知

升级到 HTTP/2 后,那些针对HTTP/1.x 的优化手段需要如何变化?

答:总结来说,除了多域名增加并行 TCP 连接数不再适用以外,启用 HTTP/2 几乎不用考虑太多。

首先,由于 HTTP/2 是复用了一个 TCP 连接进行多次传输,所以适用于 HTTP/1.x 的多域名增加并发 TCP 连接数的策略已经不再适用了。不仅如此,如果你的 CDN 和主站不是指向同一 IP 且共用同一个 https 证书的话,HTTP/2 就不会在同一个 TCP 连接中也完成来自 CDN 的资源的传递,而是会为 CDN 徒增一个额外的 TCP 连接。

第二,虽然 HTTP/2 让同一 TCP 连接下的多文件的传输速度变快了,但是其实,适度的合并资源文件中行为在 HTTP/2 也是可以接受的(参考文献),不需要为了升级 HTTP/2 就背上沉重的负担,对合并资源赶尽杀绝。

最后,其实 Server Push 只是一个升级版的内联资源。 Server Push 是个很好的特性。由于 HTTP/2 的 Server Push 特性允许服务器充分利用带宽,并按一定的优先次序向客户端推送资源,客户端甚至都还没获取完 HTML 文档就可以接收。因此,使用 Server Push 特性,不仅资源加载时机提前了,对带宽的利用更加充分了,而且也更加灵活了。但是, Nginx 最新版本目前还不支持 Server Push 特性。

HTTP/1.x升级到HTTP/2所需的前端优化调整总结

HTTP/2 的浏览器支持情况如何?

答:全球过半份额的浏览器已经支持 HTTP/2 了。当然,中国 IE8/9/10 和非 Windows10 下的IE11 的份额可能比国外大不少。 然而这并不用太担心,服务器会向客户端发送一份支持协议的列表,不支持 HTTP/2 的客户端可以选择自己支持的协议,一般是 HTTP/1.x 协议。

2015年底HTTP/2的浏览器支持情况(点击查看最新)

HTTP/2 的性能优化方面要注意什么吗?

答:当一个 TCP 连接需要同时需要加载很多文件的时候,HTTP/2 的多路复用和 Server Push 的优先级机制可以带来性能的很大提升。然而,HTTP/2 带来的性能提升却往往不能弥补 TLS(https) 带来的负面影响。甚至于,对于某些非常大的文件和视频直播流,有可能有时候会需要禁用 https 得到可接受的性能。

不过,好消息是,你可以参照此文(Is TLS Fast Yet?)检查一下,关于 https 性能有什么可以做的(参考文献)。因为网络环境的不同、延迟也不同,每个应用的特点也不尽相同,所以升级前后还需要自行做性能测试,判断什么最适合自己。

升级 HTTP/2 的前提条件是什么?

答:由于现在所有支持 HTTP/2 的浏览器都强制只使用 TLS(https) 连接,所以:获取证书,并且让服务器支持 https 是必须的先决条件。

用 nginx 如何启用 HTTP/2 支持?

答:很简单,只需编译安装最新版 Nginx,并在配置中启用:

server {listen 443 ssl http2 default_server;ssl_certificate    server.crt;ssl_certificate_key server.key;...
}

详见中文指南(Nginx HTTP2 的编译和配置)。也可以看官方文章(NGINX Open Source 1.9.5 Released with HTTP/2 Support)。

HTTP/2 的 Server Push 的特性是怎样的?有什么用?

答:浏览器为了不浪费带宽,会先分析完文档再下载资源。而由于各个资源的相互掣肘依赖,其中还会有某个资源阻塞的情况。当然,现代浏览器也不是傻瓜,它们会通过预加载来提速。通常浏览器预加载提速有两种方法:
1. 分析文档,提前加载;
2. 根据用户行为预加载,如鼠标在链接上的 hover 悬停动作等。
除此之外,前端开发工程师也可以通过 dns-prefetch 等属性指定浏览器的预加载行为,更流行的方法是放弃缓存带来的便利性,将几个特别重要的资源内联在 HTML 文档中。

没有 Server Push,HTTP/1.1 的资源加载流

HTTP/2 的 Server Push 特性把这些包袱从浏览器或者前端工程师手里拿过来,直接丢给了应用层。使用 HTTP/2 的 Server Push 就相当于使用升级版的内联资源。首先,浏览器在完全不清楚 HTML 文档是什么情况的前提下,就可以得到服务器推送的资源文件。而且,与内联资源不同的是,客户端也可以选择暂停、或者拒绝这份推送。

有 Server Push 的 HTTP/2 资源加载流

还有,将内联资源换成 Server Push 的好处还有很多,可以被缓存、被多个页面共用、和其它资源一起多路复用,还可以享受服务器端指定的优先级权重和次序(如图)。

Server Push 中,每个资源(每个资源都是一个 steam )都可以有权重和优先次序

作为一个前端工程师,我认为 HTTP/2 的 Server Push 特性解决了 HTTP/1.x 的无脑顺序加载资源,导致前端不得不为了预加载、首屏时间、省流量延迟加载等问题,用有限的标签和内联 JavaScript 脚本的方式去弥补的这个问题。由于 Server Push 触发的时机远早于内联 JavaScript Loader ,而且从 HTTP 协议等语义上定义了资源优先权重和 先后次序,允许客户端启动或暂停 Server Push,有望从根本上让加载时机和次序的控制变得既高效又容易。虽然 Server Push 不会暴露接口给 JavaScript ,但是可以和 Sever Sent Event 协同合作(参考文献)。

HTTP/2 Server Push 的实测效果

HTTP/2 的 Server Push 和 Server Sent Event 的关系?

HTTP/2 的 Server Push 不向浏览器端暴露 API,也并不是 SSE(Server Sent Event)的替代。相反,它可以和 SSE 很好的协作。具体参见此文末尾。

HTTP/2 改变了什么?带来了哪些提升?

HTTP/1.x 公认最大的性能瓶颈就是 TCP 连接数过多。建立一个 TCP 连接需要三次握手,也就是三次往返于服务器和客户端之间。三次握手所需的时间无法用提升带宽来弥补。而现在的网页一般都内容丰富,在 HTTP/1.x 下载完整个网页一般需要很多很多个 TCP 连接。如果用开发者工具查看网络加载流,可以看到阻塞时间(也叫做 Time To First Byte,参考文献),尤其是小资源的阻塞时间占比非常大。此外,每次 TCP 连接都需要传递 HTTP Header 信息,也是一笔带宽开销。这还不够,HTTP/1.x 由于基本是无脑按顺序加载资源,需要浏览器和前端工程师对预加载、加载优先级等做很多额外的工作。

HTTP/1.x 协议下绿色的阻塞时间延迟可观

而 HTTP/2 解决了这个问题。相比之下,HTTP/2 一方面复用同一IP且同一证书下的一个 TCP 连接,另一方面压缩了 HTTP Header,最后还提供了 Server Push 特性,解决了这些问题。

更多可翻阅 HTTPS、SPDY和HTTP/2的性能比较 某个TCP连接数非常多的网页性能实测比较。

国内外有哪些网站已经启用了 HTTP/2 支持?

答:HTTP/2的试验版本是SPDY。SPDY 在国内外已经有很多生产环境采用了。此外,国外的 Google 、Twitter 和 Facebook 这三个著名的网站已经启用了 HTTP/2 支持。



原文地址:https://www.bokeyy.com/post/get-to-know-http-2-in-10-minutes.html

尊重原创,尊重分享,麻烦您转载时,也注明原创地址