藉助HTTP 2打造更迅捷的Web體驗

2022-06-23 20:14:09 字數 3227 閱讀 8810

http/2 的目標

2015 年 2 月,網際網路工程任務組(ietf)批准了 http/2 標準提案,1999 年 http/1.1 正式標準化 ,而 http/2 是自那時以來的首個重大升級。http/2 的主要目標是與 http/1.1 完全語義相容的基礎上,進一步減少網路延遲。換句話說,http/2 要在不破壞原有 web 體系的基礎上使它變得更快。

spdy 的起源

自 2009 年底以來,google 一直在開發一個實驗性的協議,這個神祕的協議名叫 spdy(讀作 speedy)。spdy 並不是一個首字母縮略詞,其實,它是 google 註冊的一個商標,http/2 正是起源於這個 spdy 實驗。事實上,後來有許多曾經參與 spdy 專案的核心開發者同樣也加入到 http/2 的開發中去。在 2015 年 2 月,google正式宣佈停止支援 spdy 計劃,全力支援 http/2 的開發,預計在 2016 年前實現全部功能。

http/1.1

自 1999 年以來,http/1.1 默默地為我們服務了十幾年,它是在當時那樣的計算機和網路應用場景下被設計出來的。我不說你也知道,http 早就應該升級了。為了便於描述 http/1 是如何工作的,我在下面放了幾張**。根據序號的順序你就會看到,從客戶端開始(很可能是一個web瀏覽器)與右方的伺服器建立一個 http/1 的連線。

(2) 客戶端/瀏覽器隨後傳送一個 get 請求(http 方法)獲取 index.html 頁面。 (3) 伺服器響應客戶端請求的資源。 (4-7) 在我們這個簡單的示例中,這個不斷進行的 請求-響應迴圈過程 持續地獲取樣式表和指令碼來完善整個 html 文件。 (8) 最終,這個 http/1 連線斷開了。

線頭阻塞(head-of-line blocking)

如你所見,客戶端/瀏覽器 花費大量的時間等待每一個資源被響應。因為 http/1 不能在同一個連線上進行併發請求,瀏覽器通常需要開啟多個連線來加速請求資源的過程。

代價高昂的連線

即使開啟多個連線能有效提高資源的載入速度,但是從計算機網路的角度來看,開啟每一個連線的代價都很高。所以,現代瀏覽器通常都有最多 6-8 個 http/1.1 連線的限制,許多**現在需要載入 80多個或者更多的資源,這些連線限制逐漸成為了整個 web 系統的效能瓶頸。

http 管線化(http pipelining)

http/1.1 嘗試利用一個名為 http管線化的技術解決效能瓶頸問題,不幸的是,單一的大檔案和過慢的響應仍然會阻塞所有後續的請求。http管線化 不難部署,但你基本上不太可能去部署它,現代瀏覽器幾乎都不怎麼支援 http 管線化的功能,因為許多媒介和伺服器不能正確地處理它(譯者注:可以參考 檢視一下支援的平臺)。

http/2 多路複用(multiplexing)

多路複用允許同時通過單一的 http/2 連線發起多重的請求-響應訊息,為了向你們量化展示一個 http/2 連線到底快多少,我準備了一套並排的圖對比 http/2 與 http/1 的效能,在這個簡單的示例中只請求 3 個資源,從 web 頁面開始渲染到載入結束,http/2 比 http/1 節省不少時間。

推而廣之,當 80 個資源複合請求時,與 http/1.1 相比,很明顯通過單一連線進行傳遞的 http/2 更高效!

其它提高 http/2 效能的因素

在 http/2 中,伺服器推送是指在客戶端請求之前傳送資料的機制。如果一個請求是由你的主頁發起的,伺服器很可能響應主頁內容、logo以及樣式表,因為它知道客戶端會用到這些東西。這相當於在一個 html 文件內集合了所有的資源,不過與之相比,伺服器推送有一個很大的優勢:可以快取!

當然這同時也是它的一個缺點,如果客戶端已經快取了資料,此時會產生不必要的冗餘。這也是為什麼我推薦伺服器提示(server hints)的原因。

伺服器提示(server hints)

伺服器提示可以先於客戶端檢測到將要請求的資源,提前通知客戶端,伺服器不傳送所有資源的實體,它只傳送資源的 url。客戶端接到提示後進一步驗證之前的快取,如果發現需要這些資源,則正式發起請求。伺服器提示對 http/2 來說興許不是最新的,但非常值得在這裡順便一提,因為它沒有上文提到的伺服器推送冗餘的缺點。

伺服器提示是通過 http link header 和與已實現的 link prefetching 語義重疊的部分來實現的。舉個例子,一個 http link header 看起來是這樣的:

css**

link: ; rel=prefetch  

如果 html 文件的 head 標籤中有一個 prefetch link標籤,不需要在服務端有額外的實現,舉個例子:

css**

"prefetch"

href=

"">  

儘管 http/2 的主要目標是使網路更快,但是因為它不強制加密連線,目前飽受批判。還好的是,主導的瀏覽器廠商迄今為止都拒絕開發不加密的 http/2,所以 http/2 需要通過**部署一個加密的連線。如果你不認為這對 web 的未來大有裨益,請移步我的文章 https 無所不在。

瀏覽器支援

http/2 現在或者將來會被所有主流瀏覽器支援。

伺服器支援

支援 http/2

支援 spdy,但不支援 http/2

目前沒有支援 http/2 計劃的

其它 http/2 實現

最後,有關 http/2 的暢想

正如我們所探索的,http/2 早就應該為升級 web 而出現,當它在接下來的幾年中被廣泛接受,**和其它 web 服務將會變得更快,比以前任何時候更加能幹。感謝有遠見的瀏覽器廠商們,http/2 將會增強使用者的隱私和安全。我認為對於整個 web 生態來說,http/2 是一次至關重要的飛躍,未來有許多新的事業正等著我們去開拓。

如果關於 http/2 你有任何的問題或建議,可以在 twitter 上 @benjaminpatch

致謝