前言

引入任何一種新技術(shù)都是有原因和目的的。比如 HTTP keep-alive 允許客戶端和服務(wù)端用同一個(gè) TCP 連接發(fā)送/接收多個(gè)請(qǐng)求/響應(yīng)，減少了昂貴的 TCP 建立連接和斷開連接的過程；HTTP pipelining 允許客戶端在收到響應(yīng)之前繼續(xù)發(fā)送冪等方法（GET 和 HEAD）的請(qǐng)求，提升在高延遲連接下頁面的加載速度；HTTP/2 更是定義了幀（frame）和流（stream），真正地復(fù)用了 TCP 連接，從而解決了 pipelining 不能解決的問題（例如「快」的響應(yīng)被「慢」的響應(yīng)阻塞的問題）。

Server push 的意義很簡(jiǎn)單，說白了就是為了提前推送響應(yīng)。這里面包含兩個(gè)問題——推什么和怎么推。

推什么？

使用 HTTP/1.x 協(xié)議時(shí)，由于連接不能完全被復(fù)用，許多站點(diǎn)為了減少連接數(shù)和請(qǐng)求數(shù)，會(huì)把樣式表和腳本內(nèi)聯(lián)到 html 中。如果不考慮緩存，可以認(rèn)為這是提前推送了樣式表和腳本的響應(yīng)。許多介紹 server push 的文章也以推送這些靜態(tài)資源為例。

上圖是我畫的一張示意圖。可以看到，使用 server push 后，兩個(gè)靜態(tài)資源文件隨著 HTML 一同被推了回來。主要省去了兩部分時(shí)間：一部分是接收和解析 HTML 的時(shí)間（不一定是接收和解析完整 HTML 的時(shí)間，瀏覽器很可能一發(fā)現(xiàn)引用了靜態(tài)資源文件，就發(fā)起請(qǐng)求）；另一部分是請(qǐng)求靜態(tài)資源文件的時(shí)間。

但是，我個(gè)人認(rèn)為現(xiàn)階段用 server push 推送靜態(tài)資源并不是一件有意義的事情，原因在于：

HTML 文件通常不大，而且樣式表一般很靠前，瀏覽器發(fā)現(xiàn)這類靜態(tài)資源的時(shí)間幾乎可以忽略不計(jì)；
HTTP/2 已經(jīng)能夠復(fù)用 TCP 連接了，請(qǐng)求不再像以前那樣昂貴，請(qǐng)求的實(shí)際數(shù)據(jù)很小，發(fā)送請(qǐng)求的時(shí)間也幾乎可以忽略不計(jì)；
國(guó)內(nèi)的 CDN 普遍不支持 server push，這意味著，如果要推送靜態(tài)資源，就必須耗費(fèi)自己服務(wù)器的帶寬，同時(shí)也享受不到 CDN 的各種好處了；
靜態(tài)資源通常會(huì)被緩存很長(zhǎng)時(shí)間，提前推送的話，在大多數(shù)情況下反而會(huì)浪費(fèi)流量。

因此，我們推送的資源并不是靜態(tài)資源，而是 API：

相比較靜態(tài)資源文件，瀏覽器更難發(fā)現(xiàn) API 請(qǐng)求，必須等到接收和解析完 JS 文件，執(zhí)行到相關(guān)語句，瀏覽器才會(huì)發(fā)送請(qǐng)求；
API 一般不緩存，即便緩存，緩存的時(shí)間也比靜態(tài)資源短得多。

當(dāng)然，server push 對(duì)要推送的資源是有限制的：其請(qǐng)求必須是可緩存的、安全的，而且不能帶有請(qǐng)求體。換句話說，server push 可以推 GET 和 HEAD 請(qǐng)求的響應(yīng)。

怎么推？

Server push 的原理很簡(jiǎn)單，本質(zhì)上就是先替你請(qǐng)求再告訴你。

假設(shè)服務(wù)端接收到客戶端對(duì) HTML 文件的請(qǐng)求，決定用 server push 推送一個(gè)樣式表文件。那么，服務(wù)端會(huì)構(gòu)造一個(gè)請(qǐng)求，包括請(qǐng)求方法和請(qǐng)求頭，填充到一個(gè) PUSH_PROMISE 幀里發(fā)送給客戶端，來告知客戶端它已經(jīng)代勞發(fā)了這個(gè)請(qǐng)求。客戶端可以根據(jù) PUSH_PROMISE 幀里提供的 Promised Stream Id 來讀推過去的響應(yīng)。

當(dāng)客戶端收到這個(gè) PUSH_PROMISE 幀的時(shí)候，它就知道服務(wù)端將要推送一個(gè)樣式表文件回來。如果此時(shí)客戶端需要請(qǐng)求這個(gè)樣式表文件，即便服務(wù)端還沒推完，它也不會(huì)往服務(wù)端發(fā)送對(duì)樣式表文件的請(qǐng)求。

這里需要注意的是避免競(jìng)爭(zhēng)。在上面的例子中，必須先發(fā)送 PUSH_PROMISE，再發(fā)送 HTML 的內(nèi)容。這是因?yàn)?HTML 中存在對(duì)樣式表文件的引用，一旦客戶端發(fā)現(xiàn)了這個(gè)引用卻還沒收到 PUSH_PROMISE，它就會(huì)發(fā)起請(qǐng)求。這會(huì)引起 PUSH_PROMISE 和對(duì)樣式表文件的請(qǐng)求之間的競(jìng)爭(zhēng)，從而 server push 有一定的幾率失敗。

另一種競(jìng)爭(zhēng)是不可避免的。如果客戶端認(rèn)為它不需要某個(gè)即將被推過來的資源（比如這個(gè)資源還在緩存的有效期內(nèi)），那么它會(huì) reset 掉相應(yīng)的流。但是即便如此，服務(wù)端在收到 RST_STREAM 幀的時(shí)候，很有可能已經(jīng)推了一部分?jǐn)?shù)據(jù)了。這種服務(wù)端開始推送數(shù)據(jù)和 RST_STREAM 幀之間的競(jìng)爭(zhēng)是難以避免的（這是 feature 而不是 BUG）。

Demo

為了測(cè)試 server push 的效果，我們拿餓了么 PC的餐廳列表頁面做了個(gè) demo。

在開啟 server push 之前，timeline 如下：

使用 server push 推送頁面請(qǐng)求的 API 之后，timeline 變成了這樣：

一方面，timeline 總時(shí)間變短了。兩者 Loading、Scripting、Rendering 和 Painting 的時(shí)間比較接近，但是主動(dòng)推送 API 后，Idle 從超過 280ms 縮短至 50ms 左右，商家圖片的開始加載時(shí)間也大幅提前了（視覺上就是餐廳列表瞬間出來了）。

另一方面，頁面的 DOMContentLoaded 和 Load 時(shí)間有所提升（在 Network 面板中，沒有截圖）。這是意料之中的，客戶端在請(qǐng)求 HTML 之后需要同時(shí)接收 HTML 和 API 的響應(yīng)。這并不影響頁面與資源的總體加載時(shí)間變短。

Demo 終究只是 demo。推送 API 比推送靜態(tài)資源復(fù)雜許多，具體在于大多數(shù) API 是需要帶參數(shù)的。即便只推送 GET 方法的 API，也需要帶上 query string 和 header 里（包括 Cookie）的參數(shù)。

如果你好奇怎么驗(yàn)證 server push 有沒有生效，請(qǐng)打開 Network 面板，你會(huì)看到一排漂亮的「Push」：