HTTP/2 與 WEB 性能優(yōu)化（一）

來源：http://imququ.com/post/http2-and-wpo-1.html
作者：Jerry Qu

2013 年 11 月份開始，我的博客開始支持了 SPDY 協(xié)議（詳見這里），也就是 HTTP/2 的前身。今年二月份，Google 宣布將在 16 年初放棄對 SPDY 的支持，隨后 Google 自家支持 SPDY 協(xié)議的服務(wù)都切到了 HTTP/2。今年 5 月 14 日，HTTP/2 以?RFC 7540?正式發(fā)布。目前，瀏覽器方面，Chrome 40+ 和 Firefox 36+ 都正式支持了 HTTP/2；服務(wù)器方面，著名的 Nginx 表示會在今年底正式支持 HTTP/2。

不得不說這幾年 WEB 技術(shù)一直在突飛猛進(jìn)，爆炸式發(fā)展。昨天還覺得 HTTP/2 很遙遠(yuǎn)，今天已經(jīng)遍地都是了。對于新鮮事物，有些人不愿意接受，覺得好端端為什么又要折騰；有些人會盲目崇拜，認(rèn)為它是能拯救一切的救世主。HTTP/2 究竟會給前端帶來什么，什么都不是？還是像某些人說的「讓前端那些優(yōu)化小伎倆直接退休」？我打算通過寫一系列文章來嘗試回答這個問題，今天是第一篇。

提出問題

我們知道，一個頁面通常由一個 HTML 文檔和多個資源組成。有一些很重要的資源，例如頭部的 CSS、關(guān)鍵的 JS，如果遲遲沒有加載完，會阻塞頁面渲染或?qū)е掠脩魺o法交互，體驗很差。如何讓重要的資源更快加載完是我本文要討論的問題。

HTTP/1

分析

我們先來考慮資源外鏈的情況。通常，外鏈資源都會部署在 CDN 上，這樣用戶就可以從離自己最近的節(jié)點(diǎn)上獲取數(shù)據(jù)。一般文本文件都會采用 gzip 壓縮，實際傳輸大小是文件大小的幾分之一。服務(wù)端托管靜態(tài)資源的效率通常非常高，服務(wù)端處理時間幾乎可以忽略。在忽略網(wǎng)絡(luò)因素、傳輸大小以及服務(wù)端處理時間之后，用戶何時能加載完外鏈資源，很大程度上取決于請求何時能發(fā)出去，這主要受下面三個因素影響：

• 瀏覽器阻塞（Stalled）：瀏覽器會因為一些原因阻塞請求。例如在 rfc2616 中規(guī)定瀏覽器對于一個域名，同時只能有 2 個連接（HTTP/1.1 的修訂版中去掉了這個限制，詳見?rfc7230，因為后來瀏覽器實際上都放寬了限制），超過瀏覽器最大連接數(shù)限制，后續(xù)請求就會被阻塞。再例如現(xiàn)代瀏覽器在加載同一域名多個 HTTPS 資源時，會有意等第一個 TLS 連接建立完成再請求其他資源；
• DNS 查詢（DNS Lookup）：瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接。將域名解析為 IP 的這個系統(tǒng)就是 DNS。DNS 查詢結(jié)果通常會被緩存一段時間，但第一次訪問或者緩存失效時，還是可能耗費(fèi)幾十到幾百毫秒；
• 建立連接（Initial connection）：HTTP 是基于 TCP 協(xié)議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文。這個過程通常也要耗費(fèi)幾百毫秒；

當(dāng)然我們一般都會給靜態(tài)資源設(shè)置一個很長時間的緩存頭。只要用戶不清除瀏覽器緩存也不刷新，第二次訪問我們網(wǎng)頁時，靜態(tài)資源會直接從本地緩存獲取，并不產(chǎn)生網(wǎng)絡(luò)請求；如果用戶只是普通刷新而不是強(qiáng)刷，瀏覽器會在請求頭帶上協(xié)商字段?If-Modified-Since?或?If-None-Match，服務(wù)端對沒有變化的資源會響應(yīng) 304 狀態(tài)碼，告知瀏覽器從本地緩存獲取資源。304 請求沒有正文，非常小。

也就是說資源外鏈的特點(diǎn)是，第一次慢，第二次快。

再來看看資源內(nèi)聯(lián)的情況。把 CSS、JS 文件內(nèi)容直接內(nèi)聯(lián)在 HTML 中的方案，毫無疑問會在用戶第一次訪問時有速度優(yōu)勢。但通常我們很少緩存 HTML 頁面，這種方案會導(dǎo)致內(nèi)聯(lián)的資源沒辦法利用瀏覽器緩存，后續(xù)每次訪問都是一種浪費(fèi)。

解決

很早之前，就有網(wǎng)站開始針對第一次訪問的用戶將資源內(nèi)聯(lián)，并在頁面加載完之后異步加載這些資源的外鏈版本，同時記錄一個 Cookie 標(biāo)記表示用戶來過。用戶再次訪問這個頁面時，服務(wù)端就可以輸出只有外鏈版本的頁面，減小體積。

這個方案除了有點(diǎn)浪費(fèi)流量之外（一份資源，內(nèi)聯(lián)外鏈加載了兩次），基本上能達(dá)到更快加載重要資源的效果。但是在流量更加寶貴的移動端，我們需要繼續(xù)改進(jìn)這個方案。

考慮到移動端瀏覽器都支持 localStorage，可以將第一次內(nèi)聯(lián)引入的資源緩存起來后續(xù)使用。緩存更新機(jī)制可以通過在 Cookie 中存放版本號來實現(xiàn)。這樣，服務(wù)端收到請求后，首先要檢查 Cookie 頭中的版本標(biāo)記：

• 如果標(biāo)記不存在或者版本不匹配，就將資源內(nèi)聯(lián)輸出，并提供當(dāng)前版本標(biāo)記。頁面執(zhí)行時，會把內(nèi)聯(lián)資源存入 localStorage，并將資源版本標(biāo)記存入 Cookie；
• 如果標(biāo)記匹配，就輸出 JavaScript 片段，用來從 localStorage 讀取并使用資源；

由于 Cookie 內(nèi)容需要盡可能的少，所以一般只存總的版本號。這會導(dǎo)致頁面任何一處資源變動，都會改變總版本號，進(jìn)而忽略客戶端所有 localStorage 緩存。要解決這個問題可以繼續(xù)改進(jìn)我們的方案：Cookie 中只存放用戶唯一標(biāo)識，用戶和資源對應(yīng)關(guān)系存在服務(wù)端。服務(wù)端收到請求后根據(jù)用戶標(biāo)識，計算出哪些資源需要更新，從而輸出更有針對性的 HTML 文檔。

這套方案要投入實際使用，要處理一系列異常情況，例如 JS / Cookie / localStorage 被禁用；localStorage 被寫滿；localStorage 內(nèi)容損壞或丟失等等?？紤]成本和實際收益，推薦只在移動項目中使用這種方案。

HTTP/2

對于 HTTP/2 來說，要解決前面這個問題簡直就太容易了，開啟「Server Push」即可。HTTP/2 的多路復(fù)用特性，使得可以在一個連接上同時打開多個流，雙向傳輸數(shù)據(jù)。Server Push，意味著服務(wù)端可以在發(fā)送頁面 HTML 時主動推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請求再響應(yīng)。另外，服務(wù)端主動推送的資源不是被內(nèi)聯(lián)在頁面里，它們有自己獨(dú)立的 URL，可以被瀏覽器緩存，當(dāng)然也可以給其他頁面使用。

服務(wù)端可以主動推送，客戶端也有權(quán)利選擇接收與否。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送?RST_STREAM?幀來拒收。

可以看到，HTTP/2 的 Server Push 能夠很好地解決「如何讓重要資源盡快加載」這個問題，一旦普及開來，可以取代前面介紹過的 HTTP/1 時代優(yōu)化方案。