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 文档中。
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
尊重原创，尊重分享，麻烦您转载时，也注明原创地址