[[173785]]

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

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

HTTP 推送能做哪些預加載不能做的事?

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

利用服務器思考時間(think-time)

如今，HTML 響應很少只是單純的靜態(tài)資源了。它們通常都是通過數(shù)據(jù)庫獲取所需的信息、使用高級語言(可能略微慢一些)動態(tài)生成的。雖然后端響應時間確實可以而且應當優(yōu)化，但幾百毫秒的響應時間也并不常見。

有一個常見的建議，“提早 flush” HTML，在查詢數(shù)據(jù)庫并構建動態(tài)內(nèi)容的同時，發(fā)送 HTML 的首個 chunk 塊。但是，并非所有服務端的構架都能這么簡單地實現(xiàn)。

另外一個讓問題變得困難的因素是，需要開始向瀏覽器發(fā)送數(shù)據(jù)時，我們尚無法確定響應的構建是否會完全成功。為避免出現(xiàn)響應創(chuàng)建邏輯出錯(比如說，數(shù)據(jù)庫錯誤或者服務端代碼運行失敗)，我們需要在應用邏輯中創(chuàng)建一種“回滾”已發(fā)送響應數(shù)據(jù)的方式，并向用戶展示錯誤信息。

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

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

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

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

還有額外好處，這些資源也預熱了 TCP 連接，也提升了擁塞窗口(congestion window)，確保思考時間之后的首個 RTT 中，可以使用 28 KB，56 KB，乃至更大的擁塞窗口發(fā)送 HTML(這取決于思考時間的長短，以及在此期間我們推送了多少資源)。

一起來看下具體案例：一個 120 KB 的 HTML 頁面，關鍵 CSS 有 24KB，關鍵 JS 有 74 KB，在 100ms RTT、無限帶寬的網(wǎng)絡環(huán)境下是如何加載的?

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

 無推送情況下的頁面加載

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

 HTTP 推送情況下的頁面加載

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

HTTP 推送不盡如意的地方

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

盲目推送靜態(tài)資源

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

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

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

你可能會以為，流重置(stream resets)會幫助推送已緩存的資源去避免浪費帶寬和時間。你可能錯了。很顯然，并非所有瀏覽器會檢查緩存并終止已緩存資源的推送。就算它們會這樣，在流重置信號到達服務器之前，還是使用了一整個 RTT 時間發(fā)送數(shù)據(jù)。尤其是有多個資源時，這樣做將可能帶來大量數(shù)據(jù)浪費。

將內(nèi)容放入瀏覽器緩存

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

因此，如果你在推送資源，希望它們在未來的某個頁面中使用，那么瀏覽器有可能在用到它們之前已經(jīng)將它們?nèi)映鐾扑途彺嬷饬恕?/p>

至少目前的實現(xiàn)是這樣的。

填補 HTML 下發(fā)之后的管道

通常，在頁面的下載循環(huán)中，使用的帶寬之間會存在間隙。這意味著我們沒能盡快下發(fā)資源，通常這是因為瀏覽器發(fā)現(xiàn)資源的延遲。

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

緩存摘要(Cache Digests)

從上面我們可以看到，HTTP 推送的一大缺點就是，服務器并不必然清楚瀏覽器的緩存狀態(tài)，因此在推送時我們可能會將已在緩存中存在的資源推送出去。

有一個標準擴展的提案，叫做 Cache Digests。其基本思想是瀏覽器在 HTTP/2 連接初始化之后，向服務器發(fā)送摘要，服務器在下發(fā)資源之前能夠精確判斷資源是否已在瀏覽器緩存中存在。

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

總結

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

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

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

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