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 改变了什么？带来了哪些提升？

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

HTTP/1.x 协议下绿色的 Waiting Time 延迟可观

而 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 支持。