[[173785]]

上周我在斯達哥爾摩住了幾天，出席了 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 毫秒。

 HTTP 推送情況下的頁面加載

首次渲染加速了 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 圖解原型時的幫助）。