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

**HTTP/2 的 Server Push 的特性是怎样的？有什么用？** 答：浏览器为了不浪费带宽，会先分析完文档再下载资源。而由于各个资源的相互掣肘依赖，其中还会有某个资源阻塞的情况。当然，现代浏览器也不是傻瓜，它们会通过预加载来提速。通常浏览器预加载提速有两种方法： 1. 分析文档，提前加载； 2. 根据用户行为预加载，如鼠标在链接上的 hover 悬停动作等。 除此之外，前端开发工程师也可以通过 dns-prefetch 等属性指定浏览器的预加载行为，更流行的方法是放弃缓存带来的便利性，将几个特别重要的资源内联在 HTML 文档中。 [](http://www.bokeyy.com/wp-content/uploads/2015/12/exportfile-1.jpg) 没有 Server Push，HTTP/1.1 的资源加载流 HTTP/2 的 Server Push 特性把这些包袱从浏览器或者前端工程师手里拿过来，直接丢给了应用层。使用 HTTP/2 的 Server Push 就相当于使用升级版的内联资源。首先，浏览器在完全不清楚 HTML 文档是什么情况的前提下，就可以得到服务器推送的资源文件。而且，与内联资源不同的是，客户端也可以选择暂停、或者拒绝这份推送。 [](http://www.bokeyy.com/wp-content/uploads/2015/12/IMG_0318-0.jpg) 有 Server Push 的 HTTP/2 资源加载流 还有，将内联资源换成 Server Push 的好处还有很多，可以被缓存、被多个页面共用、和其它资源一起多路复用，还可以享受服务器端指定的优先级权重和次序（如图）。 [](http://www.bokeyy.com/wp-content/uploads/2015/12/exportfile-2.jpg) Server Push 中，每个资源（每个资源都是一个 steam ）都可以有权重和优先次序 作为一个前端工程师，我认为 HTTP/2 的 Server Push 特性解决了 HTTP/1.x 的无脑顺序加载资源，导致前端不得不为了预加载、首屏时间、省流量延迟加载等问题，用有限的标签和内联 JavaScript 脚本的方式去弥补的这个问题。由于 Server Push 触发的时机远早于内联 JavaScript Loader ，而且从 HTTP 协议等语义上定义了资源优先权重和 先后次序，允许客户端启动或暂停 Server Push，有望从根本上让加载时机和次序的控制变得既高效又容易。虽然 Server Push 不会暴露接口给 JavaScript ，但是可以和 Sever Sent Event 协同合作（[参考文献](https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/)）。 [](http://www.bokeyy.com/wp-content/uploads/2015/12/CNYFaJlUkAA7oS9.jpg) HTTP/2 Server Push 的实测效果