Skip to content

HTTP2 explained

Jump to bottom
changwu edited this page Mar 12, 2016 · 9 revisions

HTTP/2

HTTP/1.1 在 1999 年發佈, 網頁內容擷取的 protocol, 但時至今日, 由於一個頁面平均為 1.9MB, 並含超過 100 個資源, 在現代網頁中, HTTP/1.1 的效能並不好, 因此 web developer 發展出最佳實踐 (Best practice) 來改善效能瓶頸.

到了 2009 年, 兩個 google 的工程師開發了 SPDY 來降低網頁讀取時的延遲.

SPDY

  1. 允許在單一 TCP 連線中同時送出多個請求達成多工
  2. 允許瀏覽器能夠優先傳送重要的資源
  3. 壓縮並減少 HTTP header
  4. 實作 Server push, 讓重要資源在尚未請求前, 先推送到瀏覽器
  5. 要求瀏覽器與客戶端之間要進行 HTTPs 連線

SPDY 不是要取代 HTTP, 只是在 HTTP 上, 修改既有的協定來進行溝通

現有瀏覽器的版本支援情形

HTTP/2

目前, 最新的瀏覽器開始支援 HTTP/2, Google 也計畫在 2006 年停止對 SPDY 的支援, 另外, HTTP/2 支持 SPDY 原有的功能, 除了必須在 HTTPs 上運行之外, 因此目前的瀏覽器以實作 HTTP/2 for TLS (https) 為主. HTTP/2 的規格在 2015 年 2 月發佈, 與 SPDY 一樣, 瀏覽器與服務器都必須支援 HTTP/2.

HTTP/2 相容於 HTTP/1.1, 如果你有 gmail, 並使用 Chrome 瀏覽器, 你可能不曉得你已經使用過 SPDY 與 HTTP/2. 過去網站開發的最佳實踐, 可能在 HTTP/2 下是有損效能的. 在全面過渡到 HTTP/2 前, 必須先了解使用者的瀏覽器是否支援 HTTP/2, 以下為在這段過渡期的建議:

對於多數網站, 難點不在提供 HTTP/2 支援, 而在如何建立安全連線. Google 搜尋排名會將是否支援安全連線列入考量, 瀏覽器也會提醒是否連線安全, 在 HTML5 的部份, 如果未採用加密連線, 像 geolocation 這樣的特色是無法使用的.

在 HTTP 1.1 中, 存取一張大圖, 比存取多張小圖來的有效率, 因為讀取多張小圖需要建立多條連線, 過去我們會採 CSS Sprite 的方式來避免多個連線, 但有時, 儘管使用者只會讀取其中一張小圖, 我們仍須下載整個檔案, 另外亦不容易使用 cache 機制. HTTP/2 具有多工的能力, 小圖可在 queue 中進行傳送, 毋需建立多個連線.

在 HTTP 1.1 中, 為避免建立多個連線, CSS JS Inline & Data URI 也是常見手段之一, 嵌入圖像會造成樣式表變得肥大, 如果使用者不需該圖像卻仍須下載會造成負擔.

CSS JS Concatenation 也是手段之一, 將多個 css 或 js 檔案合併成一個來提高效能, 但在 cache 機制下, 當有一行改變時, 就必須重新讀入檔案. 整體而言, HTTP/2 中, http 請求的成本變低, 可以多考慮檔案被存取的頻繁程度, 以及如何組織來最佳化效能.

HTTP/1.1 中, 連線的數目是有限的, 如果要讀入的資源數量較大, 一種方式是透過不同的 domain 來讀取, 這種手段叫做 domain sharding. 由於 HTTP/2 可以多工請求資源, 使用這類技巧需要建立多個 TCP 連線, 對於效能會有所損害.

對於 sprite 技巧, 若有需要, 可以建立 small sprites, 多考慮頁面的檔案組織, 避免使用 Concatenation.

HTTP/2 Action

  1. 建立安全連線或透過 TLS
  2. 在網站開發時導入 HTTP/2
  3. 統計使用者支援 HTTP/2 的情形
  4. 檢查 hosting
  5. 進行 HTTP/2 最佳化

Clone this wiki locally