HTTP 推送

上週我在斯達哥爾摩住了幾天，出席了 HTTP 研討會，參與了不少吸引人的討論。其中一次是關於 HTTP 推送及其優缺點、早期實驗結果的。

由於早期實驗部署結果不那麼理想，人們對 HTTP 推送大體持著懷疑態度，不過我想分享下自己更樂觀一些的觀點。

HTTP 推送能做哪些預載入不能做的事？

從懷疑者那裡一再聽到的觀點是，“推送相對於預載入來說，只不過節省了一次 RTT（Round Trip Time）而已”。在實踐中，這並非總是對的，有一個使用案例，推送可以完成，但預載入無法做到。

利用伺服器思考時間（think-time）

如今，HTML 響應很少只是單純的靜態資源了。它們通常都是通過資料庫獲取所需的資訊、使用高階語言（可能略微慢一些）動態生成的。雖然後端響應時間確實可以而且應當優化，但幾百毫秒的響應時間也並不常見。

有一個常見的建議，“提早 flush” HTML，在查詢資料庫並構建動態內容的同時，傳送 HTML 的首個 chunk 塊。但是，並非所有服務端的構架都能這麼簡單地實現。

另外一個讓問題變得困難的因素是，需要開始向瀏覽器傳送資料時，我們尚無法確定響應的構建是否會完全成功。為避免出現響應建立邏輯出錯（比如說，資料庫錯誤或者服務端程式碼執行失敗），我們需要在應用邏輯中建立一種“回滾”已傳送響應資料的方式，並向使用者展示錯誤資訊。

儘管這肯定有可能做得到（甚至是自動化的），但目前還沒有一種通用的方式能夠作為協議的一部分。

因此一般場景是，Web 伺服器等待後端數百毫秒以構建頁面，而後開始返回資料。這時候我們就碰到了慢啟動（譯者注：slow start，可參考此文），所以首次 RTT 只能傳送大約 14 KB 資料，第二次 28 KB 左右，如此等等。由此我們知道，將 HTML 傳送出去，需要用去伺服器思考時間加上慢啟動時間。在思考時間期間，瀏覽器對接下來所需的資源一無所知，故也不會針對接下來所需資源的關鍵路徑傳送任何請求。

而且，即使我們試著耍小聰明，針對那些資源新增 preload 報頭，若我們不提早 flush 文件開頭，那還是沒有對思考時間加以利用。

現在，將這個與使用 HTTP 推送能做的事情做個對比。伺服器可以利用思考時間來推送相關的關鍵性資源 —— 尤其是 CSS 和 JS。這樣一來，當思考時間結束時，我們極有可能已將所有關鍵性資源都推送給瀏覽器了。

還有額外好處，這些資源也預熱了 TCP 連線，也提升了擁塞視窗（congestion window），確保思考時間之後的首個 RTT 中，可以使用 28 KB，56 KB，乃至更大的擁塞視窗傳送 HTML（這取決於思考時間的長短，以及在此期間我們推送了多少資源）。

一起來看下具體案例：一個 120 KB 的 HTML 頁面，關鍵 CSS 有 24KB，關鍵 JS 有 74 KB，在 100ms RTT、無限頻寬的網路環境下是如何載入的？

沒有 HTTP 推送的情況下，生成 HTML 等待了 300ms，接著 4 次 RTT 傳送 HTML，因為慢啟動的緣故，使用了一個 RTT 請求 JS 和 CSS。在首次渲染之前，時間超過了 800 毫秒。

使用 HTTP 推送，CSS 和 JS 會在 HTML 請求到達之後儘快推送出去，傳送它們需要 3 個 RTT（又一次因為慢啟動），它們將擁塞視窗增大至 128 KB 左右，將要傳送 HTML 時，一個 RTT 就能可以了。首次渲染總時間： 400 毫秒。

首次渲染加速了 50%！也不算很差嘛。。。

HTTP 推送不盡如意的地方

我認為人們在錯誤地使用 HTTP 推送的原因之一是，他們在某些並不能提供任何好處甚至損害效率的場景下使用它。

盲目推送靜態資源

使用 HTTP 推送可能做的錯事之一就是告訴你自己，“啊，這些資源是所有頁面都需要的，把它們配置成所有頁面都推送”。

這很糟糕，原因是快取。在訪問第一個頁面之後，這些資源很可能就在使用者的瀏覽器快取中，然而你卻在悶頭推送。你可能會爭辯說，這可比內聯所有這些資源好多了。是這樣的，不錯，但，我必須反過來告訴你，內聯資源也是糟糕的主意。

所以，若你在以這種方式盲目推送資源，請確保它是你想要內聯在頁面中的唯一的資源，也就是關鍵的 CSS。否則，你就是在冒險讓重複的請求變慢。

你可能會以為，流重置（stream resets）會幫助推送已快取的資源去避免浪費頻寬和時間。你可能錯了。很顯然，並非所有瀏覽器會檢查快取並終止已快取資源的推送。就算它們會這樣，在流重置訊號到達伺服器之前，還是使用了一整個 RTT 時間傳送資料。尤其是有多個資源時，這樣做將可能帶來大量資料浪費。

將內容放入瀏覽器快取

你可能以為，推送會將資源放入瀏覽器快取，可以用來做一些像使當前資源失效這樣的工作。至少目前不是如此。研討會上的討論的話題之一就是現實問題，可能我們需要改變當前的推送行為，支援與瀏覽器快取直接互動。不過當前，推送還做不到這些。推送響應進入推送快取，只有真實請求它們時才會放到 HTTP 快取中。

因此，如果你在推送資源，希望它們在未來的某個頁面中使用，那麼瀏覽器有可能在用到它們之前已經將它們扔出推送快取之外了。

至少目前的實現是這樣的。

填補 HTML 下發之後的管道

通常，在頁面的下載迴圈中，使用的頻寬之間會存在間隙。這意味著我們沒能儘快下發資源，通常這是因為瀏覽器發現資源的延遲。

儘管我們應當儘量下發頁面所需資源以填滿這些間隙，但通常使用預載入比推送更好。預載入將快取、cookie以及內容協商納入考慮，它不會像推送那樣存在著過度傳送或錯誤傳送的風險。就填補這些間隙而言，推送並無任何優勢，所有的只是劣勢。故最好不要使用推送達成此目的，使用預載入吧。

快取摘要（Cache Digests）

從上面我們可以看到，HTTP 推送的一大缺點就是，伺服器並不必然清楚瀏覽器的快取狀態，因此在推送時我們可能會將已在快取中存在的資源推送出去。

有一個標準擴充套件的提案，叫做 Cache Digests。其基本思想是瀏覽器在 HTTP/2 連線初始化之後，向伺服器傳送摘要，伺服器在下發資源之前能夠精確判斷資源是否已在瀏覽器快取中存在。

該提案尚處於早期，可能需要簡化，這樣實現起來花費更少，不過我敢說，離開這個特性，HTTP 推送只能算半成品。

總結

HTTP 推送可以用來顯著提升載入效能。正確使用時能為首個關鍵路徑載入提速，帶來效能指標的改善。

推送依然是非常新的技術，像其他所有新工具一樣，在找到使用的最優方式之前，還有很長的路要走。這一路多少會有點痛苦。

是故早期實驗的初始結果，可能並非全如我們所希望的那樣。讓我們把那些結果作為標誌，指示我們關於推送的使用需要更多聰明才智吧，別妄下結論說它是無用的特性。

感謝 Tim Kadlec 和 Marcos Caceres 審閱本文（特別感謝 Tim，在製作 RTT 圖解原型時的幫助）。