HTTP/2 簡介

HTTP/2 可將我們先前在應用程式內執行的許多 HTTP/1.1 解決方法復原，並在傳輸層本身中解決這些問題，因此這項技術可讓應用程式更迅速、簡單且完善可靠。更棒的是，這樣也開啟了許多全新機會，可以用來最佳化應用程式並提升效能！

HTTP/2 的主要目標是透過啟用完整要求和回應多工處理的方式縮短延遲時間、透過高效率壓縮 HTTP 標頭欄位來將通訊協定負擔降至最低，並支援要求優先順序和伺服器推送。為了實作這些規範，也有大量支援其他通訊協定強化項目的支援，例如新的流量控制、錯誤處理和升級機制，但所有網頁程式開發人員應瞭解並在應用程式中使用這些最重要的功能。

HTTP/2 不會以任何方式修改 HTTP 的應用程式語意。所有核心概念都維持不變，例如 HTTP 方法、狀態碼、URI 和標頭欄位。相反地，HTTP/2 會修改資料的格式 (框架) 以及在用戶端和伺服器之間傳輸的方式，兩者都會管理整個程序，並隱藏新框架層中應用程式的複雜度。因此，所有現有應用程式都可在不經修改的情況下傳送。

為什麼不是 HTTP/1.2？

為達成 HTTP 工作群組所設定的效能目標，HTTP/2 導入了新的二進位檔框架層，其與先前的 HTTP/1.x 伺服器和用戶端無法回溯相容，因此主要通訊協定版本會遞增至 HTTP/2。

也就是說，除非您是使用原始 TCP 通訊端來實作網路伺服器 (或自訂用戶端)，否則您不會看到任何差異：所有新的低層級框架都是由用戶端和伺服器代表您執行。唯一可觀察的差異將改善要求優先順序、流量控制及伺服器推送等新功能的效能和可用性。

SPDY 和 HTTP/2 的簡短歷史

SPDY 是 Google 開發的實驗性通訊協定，並於 2009 年中宣布，主要目標是解決 HTTP/1.1 的一些知名效能限制，嘗試減少網頁的載入延遲時間。具體而言，概述的專案目標如下：

• 將網頁載入時間縮短 50%。
• 避免網站作者變更內容。
• 將部署的複雜程度降到最低，並避免網路基礎架構發生變更。
• 與開放原始碼社群攜手合作，共同開發這個新的通訊協定。
• 收集實際效能資料，以便驗證實驗通訊協定。

不久之後，Google 軟體工程師 Mike Belshe 和 Roberto Peon 分享了新 SPDY 通訊協定的實驗性實作結果、說明文件及原始碼：

目前為止，我們只在實驗室條件中測試了 SPDY。初步的結果令人振奮：我們透過模擬的家用網路連線下載前 25 大網站後，效能已大幅提升，網頁載入速度最多可快 55%。 (Chromium 網誌)

到了 2012 年，Chrome、Firefox 和 Opera 支援新的實驗性通訊協定，而且越來越多的網站 (例如 Google、Twitter、Facebook) 和小型網站都在基礎架構內部署 SPDY。實際上，SPDY 的產業在業界採用率上升後，成為事實的標準。

觀察這種趨勢，HTTP 工作團隊 (HTTP-WG) 開始新嘗試，試圖運用從 SPDY 中學到的經驗，進行建構及改善，並提出正式的「HTTP/2」標準。我們擬定了一份新的章程，也針對 HTTP/2 提案發出公開呼叫，在工作小組中多次討論之後，紛紛採用 SPDY 規範做為新 HTTP/2 通訊協定的起點。

在未來幾年內，SPDY 和 HTTP/2 也持續平行演變，而 SPDY 可做為實驗性分支版本，可用於測試 HTTP/2 標準的新功能和提案。最適合紙的呈現方式可能無法正常運作，反之亦然。SPDY 提供了一種路徑，可在每個提案納入 HTTP/2 標準之前進行測試和評估。最終，這個程序長達三年，並產生了十餘份中繼草稿：

• 2012 年 3 月：呼叫 HTTP/2 提案
• 2012 年 11 月：HTTP/2 首次草稿 (根據 SPDY)
• 2014 年 8 月：發布 HTTP/2 draft-17 和 HPACK draft-12
• 2014 年 8 月：工作群組上次呼叫 HTTP/2
• 2015 年 2 月：IESG 核准的 HTTP/2 和 HPACK 草稿
• 2015 年 5 月：發布 RFC 7540 (HTTP/2) 和 RFC 7541 (HPACK)

在 2015 年初，IESG 團隊審查並核准發布的新 HTTP/2 標準。不久之後，Google Chrome 團隊已宣布淘汰 TLS 的 SPDY 和 NPN 擴充功能：

來自 HTTP/1.1 的 HTTP/2 主要變更將著重於效能提升。某些關鍵功能，例如多工處理、標頭壓縮、優先順序和通訊協定交涉，隨後在名為 SPDY 的非標準通訊協定中演變而來。Chrome 自 Chrome 6 版起就開始支援 SPDY，但由於 HTTP/2 的大部分優點都已經使用 HTTP/2，因此該告別了。我們預計在 2016 年初停止支援 SPDY，同時移除名為 NPN 的 TLS 擴充功能支援，並同時在 Chrome 中改用 ALPN。我們強烈建議伺服器開發人員改用 HTTP/2 和 ALPN。

我們很高興能參與引進 HTTP/2 的開放標準程序，希望由於業界廣泛參與標準化和實作，希望他們能擁有廣泛的採用。(Chromium 網誌)

隨著 SPDY 和 HTTP/2 啟用的伺服器、瀏覽器和網站開發人員的演變，可在開發新的通訊協定時獲得實際體驗。因此，HTTP/2 標準在設計初期便是最佳且廣泛測試的標準之一。在 IESG 核准前，HTTP/2 有數十個經過全面測試，可用於實際工作環境的用戶端和伺服器實作。事實上，在最終通訊協定獲得核准的幾週後，許多使用者都開始享受這項功能所帶來的優勢，因為許多熱門瀏覽器 (和許多網站) 部署了完整的 HTTP/2 支援。

設計與技術目標

舊版 HTTP 通訊協定經過特別設計，目的是簡化實作程序：HTTP/0.9 是可啟動全球資訊網的單行通訊協定；HTTP/1.0 以資訊標準說明 HTTP/0.9 的熱門擴充功能；HTTP/1.1 也導入了官方的 IETF 標準。請參閱「HTTP 歷史摘要」一文。因此，HTTP/0.9-1.x 確實達成了目標：HTTP 是網際網路上最常採用的應用程式通訊協定之一。

遺憾的是，由於實作的簡單性也對應用程式效能造成代價：HTTP/1.x 用戶端必須使用多個連線才能實現並行並縮短延遲時間；HTTP/1.x 不會壓縮要求和回應標頭，因而造成不必要的網路流量；HTTP/1.x 不允許有效的資源優先排序，導致基礎 TCP 連線的使用不當等等。

這些限制並不致命，但隨著網路應用程式在日常生活的應用範圍、複雜度和日常生活中日益重要，它們對網路的開發人員和使用者而言，都產生了日益嚴重的負擔，而 HTTP/2 的設計可精確解決以下問題：

HTTP/2 可藉由導入標頭欄位壓縮功能，並允許在同一連線中使用多個並行交換庫，藉此更有效率地使用網路資源，並減少延遲時間... 具體來說，它允許在同一個連線上交錯要求和回應訊息，並使用有效的 HTTP 標頭欄位編碼。另外，它也能讓您排定要求的優先順序，讓更重要的要求更快完成，進一步提升效能。

與 HTTP/1.x 相比，產生的通訊協定會更符合網路，因為使用的 TCP 連線數量較少。這表示與其他資料流的競爭較少，而長期連線則能更有效地運用可用網路容量。最後，HTTP/2 也能夠使用二進位訊息框架，以更有效率的方式處理訊息。(超文本傳輸通訊協定第 2 版，草稿 17)

請務必注意，HTTP/2 是擴充，而非取代先前的 HTTP 標準。HTTP 的應用程式語意都相同，且不會對提供的功能或核心概念 (例如 HTTP 方法、狀態碼、URI 和標頭欄位) 做出任何變更。這些變更已明確不在 HTTP/2 處理的範圍內。儘管如此，雖然高階 API 仍維持不變，但您必須瞭解低層級變更如何解決之前通訊協定的效能限制。以下將概略介紹二進位檔取景層及其功能

二進位檔取景層

HTTP/2 所有效能增強的核心是新的二進位框架層，這會指定 HTTP 訊息在用戶端和伺服器之間封裝和傳輸的方式。

「層」是指在通訊端介面與公開應用程式的較高階 HTTP API 之間導入新的最佳化編碼機制的設計選項：HTTP 語意 (例如動詞、方法和標頭) 不受影響，但在傳輸過程中編碼方式則不同。與以換行符號分隔的純文字 HTTP/1.x 通訊協定不同，所有 HTTP/2 通訊會拆分為較小的訊息和影格，每個通訊和影格都以二進位格式編碼。

因此，用戶端和伺服器都必須使用新的二進位編碼機制互相瞭解：HTTP/1.x 用戶端無法解讀僅限 HTTP/2 的伺服器，反之亦然。幸好，用戶端和伺服器會代表我們執行所有必要的框架作業，因此應用程式依然不太瞭解所有變更。

串流、訊息和外框

我們引進了新的二進位檔取景機制，改變用戶端與伺服器之間交換資料的方式。為了說明這項程序，我們來熟悉 HTTP/2 術語：

• 串流：已建立連線的位元組流動資料流，可能包含一或多則訊息。
• 訊息：對應至邏輯要求或回應訊息的完整影格順序。
• Frame：HTTP/2 中最小的通訊單位，每個通訊單位均包含影格標頭，至少要識別影格所屬的串流。

這些術語的關係可總結如下：

• 所有通訊都是透過單一 TCP 連線執行，該連線可以執行任何數量的雙向串流。
• 每個串流都有專屬 ID，以及用來傳遞雙向訊息的選用優先順序資訊。
• 每則訊息都是邏輯 HTTP 訊息，例如要求或回應，且含有一或多個影格。
• 框架是傳送特定類型資料 (例如HTTP 標頭、訊息酬載等。來自不同串流的影格可能會交錯，然後在每個影格的標頭中透過嵌入式串流 ID 重新組合。

簡單來說，HTTP/2 會將 HTTP 通訊協定通訊細分為經過二進位編碼的影格交換，然後對應至屬於特定串流的訊息，這些訊息都會在單一 TCP 連線中多工處理。另外，也是啟用 HTTP/2 通訊協定提供的所有其他功能和效能最佳化作業的基礎。

要求和回應多工處理

使用 HTTP/1.x 時，如果用戶端想同時發出多個 TCP 連線以改善效能，則必須使用多個 TCP 連線 (請參閱使用多個 TCP 連線)。這個行為是 HTTP/1.x 提供模型的直接結果，可確保每次連線一次只能傳送一個回應 (回應佇列)。更糟的是，這也會導致造成行頭封鎖和基礎 TCP 連線效率低落的問題。

HTTP/2 中的新二進位檔框架層能移除上述限制，並讓用戶端和伺服器將 HTTP 訊息拆分為獨立的影格、交錯，然後在另一端重新組合，進而啟用完整要求和回應多工處理。

快照會擷取同一連線中多個傳輸中的串流。用戶端正在將 DATA 影格 (串流 5) 傳輸至伺服器，伺服器正在針對串流 1 和 3，將一段交錯的影格傳送至用戶端。因此檔期中有三個平行串流。

您可將 HTTP 訊息細分為獨立的頁框、交錯它們，然後在另一端重新組合，這是 HTTP/2 最重要的單一改善功能。事實上，它為整個網路技術堆疊中的許多效能優勢帶來漣漪效應，讓我們可以：

• 同時並行多個要求，不封鎖任何要求。
• 同時交錯多個回應，且不封鎖任何回應。
• 使用單一連線並行傳送多個要求和回應。
• 移除不必要的 HTTP/1.x 解決方法 (請參閱針對 HTTP/1.x 進行最佳化，例如串連檔案、圖片合併字元和網域資料分割)。
• 排除不必要的延遲時間並改善可用網路容量的使用率，藉此縮短頁面載入時間。
• 還有更多福利...

HTTP/2 中新的二進位檔取景層可解決 HTTP/1.x 中發現的行前封鎖問題，且無需多個連線，就能平行處理及傳送要求和回應。因此，我們的應用程式可以更快、更簡單且更便宜的部署方式。

串流優先順序

如果 HTTP 訊息可以分割成多個個別的影格，而且我們允許將多個串流的影格進行多工處理，則影格交錯以及由用戶端和伺服器傳送的順序都將是關鍵效能考量。為方便起見，HTTP/2 標準允許每個串流都具備相關聯的權重和依附元件：

• 您可以為每個串流指派 1 到 256 之間的整數權重。
• 每個串流都有一個明確依附於另一個串流。

串流依附元件和權重的組合可讓用戶端建構並傳遞「優先順序樹狀結構」，表示偏好接收回應的方式。如此一來，伺服器可藉由控制 CPU、記憶體和其他資源的分配方式，來優先處理串流處理，並且在有回應資料可用後分配頻寬，以確保以最佳方式向用戶端傳送高優先順序回應。

HTTP/2 內串流依附元件的宣告方式，是將其他串流的專屬 ID 參照為其父項；如果省略 ID，系統會將串流視為依附於「根串流」。宣告串流依附元件表示，如果可能，父項串流應在依附元件之前分配資源。也就是「請在回應 C 之前處理並交付回應 D」。

共用相同父項 (即同層級串流) 的串流應根據其權重按比例分配資源。舉例來說，假設串流 A 的權重為 12，而其中一個同層級 B 的權重為 4，則請判斷每個串流應接收的資源比例：

1. 所有權重的總和：4 + 12 = 16
2. 將每個串流的權重除以總權重：A = 12/16, B = 4/16

因此，串流 A 應接收四分之三的時間，串流 B 應會收到四分之一的可用資源；串流 B 應接收分配給串流 A 的三分之一的資源。讓我們繼續查看上圖中的更多實際操作範例。由左至右如下所示：

1. 串流 A 和 B 都未指定父項依附元件，也都說它依附於隱含的「根串流」；A 的權重為 12，而 B 的權重為 4。因此，根據比例權重：串流 B 應會收到分配到串流 A 資源的三分之一。
2. 串流 D 依附於根串流；C 則依附於 D。因此，D 應該會在 C 之前接收完整資源配置。由於 C 的依附元件傳達出更強的偏好，因此權重是不連續的。
3. 串流 D 應該會在 C 之前收到所有資源的完整分配。C 應該會在 A 和 B 之前收到完整資源配置；串流 B 應會收到三分之一分配給串流 A 的資源。
4. 串流 D 應該會在 E 和 C 之前收到資源的完整分配情形；E 和 C 應比 A 和 B 之前分配到相同的分配比例；A 和 B 應該會根據權重進行比例分配。

如以上範例所示，串流依附元件和權重組合提供了表達資源優先順序的明確語言，這是改善瀏覽效能的重要功能，因為有許多資源類型的依附元件和權重都不同。更棒的是，HTTP/2 通訊協定也可讓用戶端隨時更新這些偏好設定，進而在瀏覽器中進一步最佳化。換句話說，我們可以變更依附元件，並根據使用者互動和其他信號重新分配權重。

每個來源一個連線

導入新的二進位檔框架機制後，HTTP/2 不再需要同時有多個 TCP 連線來連接多工串流；每個串流都會分割成多個影格，可以交錯並優先處理。因此，所有 HTTP/2 連線都具有永久性，每個來源也只需要一個連線，這樣可以帶來許多效能優勢。

對於 SPDY 和 HTTP/2 來說，終止功能是對單一壅塞控制管道進行任意多工處理。讓我印象深刻 它的重要性和運作方式我所喜歡的指標之一，是建立只具有單一 HTTP 交易的連線比例 (這樣可以使交易產生所有負擔)。以 HTTP/1 來說，74% 的有效連線僅傳輸單一交易，永久連線的效果不如預期。但在 HTTP/2 中，這個數字會降至 25%。這可說是減少經常性的負荷。(HTTP/2 目前在 Firefox 中運作，Patrick McManus)

大部分的 HTTP 傳輸都相當短且容易爆發，TCP 則是針對長期的大量資料移轉進行最佳化。透過重複使用相同的連線，HTTP/2 能夠更有效率地使用每個 TCP 連線，也能大幅降低整體通訊協定負擔。此外，使用較少的連線也能降低整個連線路徑 (即用戶端、中繼和來源伺服器) 的記憶體和處理用量。這樣可以降低整體作業成本，並提高網路使用率和容量。因此，遷移至 HTTP/2 不僅能減少網路延遲，也能改善總處理量並降低營運成本。

流量控制

流量控制是一種機制，可防止傳送方因其不希望或無法處理的資料過度加深接收者的壓力：接收器可能處於忙碌狀態、負載較重，或可能僅願意為特定串流配置固定數量的資源。舉例來說，用戶端可能要求使用高優先順序的大型影片串流，但使用者已暫停影片，而用戶端現在希望暫停或節流從伺服器傳輸影片，以免擷取及緩衝處理不必要的資料。此外，Proxy 伺服器也許具有快速的下游連線，且上游連線速度很慢，同樣想要調節下游傳送資料的速度，以便符合上游傳輸資源的速度，以此類推。

以上要求是否提醒您 TCP 流量控制？它們應該因為問題實際上完全相同 (請參閱流程控制一節)。不過，由於 HTTP/2 串流會在單一 TCP 連線中產生多工處理，因此 TCP 流量控制不夠精細，而且不提供必要的應用程式層級 API 來規範個別串流的傳送作業。為解決此問題，HTTP/2 提供一組簡易的建構區塊，可讓用戶端和伺服器實作自己的串流和連線層級流程控制項：

• 流量控制是有方向性的。每個接收器都可視需要設定每個串流和整個連線想要的視窗大小。
• 流量控制是以抵免額為準。每個接收器都會通告其初始連線和串流流程控制視窗 (以位元組為單位)，每當傳送者發出 DATA 影格，並透過接收器傳送的 WINDOW_UPDATE 影格遞增時，此視窗就會縮減。
• 無法停用流量控制項。HTTP/2 連線建立時，用戶端和伺服器會交換 SETTINGS 框架，藉此為流量控制視窗設定雙向大小。流量控制視窗的預設值設為 65,535 位元組，但接收器可以設定較大的視窗大小上限 (2^31-1 位元組)，並在收到任何資料時傳送 WINDOW_UPDATE 影格來維護。
• 流量控制是以躍點的方式控制，而非端對端。也就是說，中介商可以使用自己的條件來控制資源使用情況，並根據自己的條件和經驗法則實作資源分配機制。

HTTP/2 未指定任何用於導入流量控制的特定演算法。相反地，它提供簡單的構成元素，並將實作作業延後到用戶端和伺服器，讓用戶端和伺服器能夠實作自訂策略來協調資源使用與分配，並實作新的提供功能，以改善網頁應用程式的實際和感知效能 (請參閱速度、效能和人為感知)。

舉例來說，應用程式層流程控制項可讓瀏覽器只擷取特定資源的一部分，然後將串流流程控制視窗降至零，將擷取作業設為保留狀態，稍後再繼續。換句話說，這項功能可讓瀏覽器擷取圖片的預覽畫面或第一次掃描，然後顯示圖片並允許其他優先順序高的擷取作業繼續執行，等到其他重要資源載入完成後再繼續擷取。

伺服器推送

HTTP/2 的另一項強大新功能是可讓伺服器針對單一用戶端要求傳送多個回應。也就是說，除了回應原始要求之外，伺服器也可以推送其他資源至用戶端 (圖 12-5)，而用戶端無需明確請求每個資源。

為什麼我們需要瀏覽器採用這類機制？一般的網頁應用程式由數十個資源組成，只要檢查伺服器提供的文件，用戶端就能找到這些資源。因此，為何不要消除額外延遲，並讓伺服器提前推送相關資源？伺服器已經知道用戶端需要哪些資源，也就是伺服器推送。

事實上，如果您曾透過資料 URI 內嵌 CSS、JavaScript 或任何其他資產 (請參閱資源內嵌)，表示您已具備伺服器推送的實際經驗。透過手動將資源內嵌至文件中，我們真的應該先將該資源推送至用戶端，不必等待用戶端提出請求。有了 HTTP/2，我們就能達到相同的結果，但會帶來額外的效能優勢。推送資源可以是：

• 由用戶端快取
• 在不同頁面中重複使用
• 多工處理與其他資源
• 伺服器決定優先順序
• 已由客戶拒絕

PUSH_PROMISE 指南

所有伺服器推送串流都會透過 PUSH_PROMISE 影格啟動，藉此表明伺服器的意圖，將上述資源推送至用戶端，而且必須在要求推送資源的回應資料之前放送。這個交付順序非常重要：用戶端必須知道伺服器要推送哪些資源，才能避免對這些資源重複發出要求。要符合這項規定最簡單的策略，就是先傳送所有 PUSH_PROMISE 影格，其中僅包含承諾資源的 HTTP 標頭，而不要在父項回應 (即 DATA 影格) 之前傳送。

用戶端收到 PUSH_PROMISE 影格後，可以選擇拒絕串流 (透過 RST_STREAM 影格)。(例如資源已在快取中 就可能會發生這種情況)。這是與 HTTP/1.x 相比的重大改善項目相較之下，資源內嵌 (對 HTTP/1.x 的常用「最佳化」) 的使用行為相當於「強制推送」：用戶端無法選擇退出、取消，或個別處理內嵌的資源。

透過 HTTP/2，用戶端仍可以完全掌控伺服器推送的使用方式。用戶端可以限制同時推送的串流數量；調整初始流程控制視窗，以控制初次開啟串流時要推送的資料量；或完全停用伺服器推送功能。這些偏好設定會在 HTTP/2 連線開始時透過 SETTINGS 影格進行通訊，並且隨時可能更新。

與內嵌資源不同的是，每個推送的資源都是串流，因此可讓用戶端個別進行多工處理、排定優先順序及處理。根據瀏覽器強制執行的唯一安全限制，推送的資源必須符合相同來源的政策：伺服器必須為提供的內容具權威性。

標頭壓縮

每次 HTTP 傳輸都會包含一組標頭，說明轉移的資源及其屬性。在 HTTP/1.x 中，這個中繼資料一律會以純文字格式傳送，並且會增加每次傳輸的 500 至 800 位元組的負擔，如果使用 HTTP Cookie，則可增加 KB 數。(請參閱測量和控制通訊協定負載)。為降低負擔並提升效能，HTTP/2 會使用兩種簡單但強大的技術的 HPACK 壓縮格式來壓縮要求和回應標頭中繼資料：

1. 它可讓傳輸的標頭欄位透過靜態 Huffman 程式碼進行編碼，進而減少各自的傳輸大小。
2. 其需要維護並更新已建立索引的標頭欄位清單 (換句話說，它會建立共用的壓縮內容)，然後做為參考，以便有效對之前傳送的值進行編碼。

Huffman 編碼允許在轉移時壓縮個別值，而先前移轉值的已建立索引清單可讓我們透過傳輸可有效查詢及重建完整標頭鍵/值的索引值來編碼重複值。

進一步最佳化時，HACK 壓縮內容由靜態和動態資料表組成：在規格中定義靜態資料表，並提供所有連線可能會使用的常見 HTTP 標頭欄位清單 (例如有效的標頭名稱)；動態資料表一開始會是空的，並根據特定連線中的交換值進行更新。因此，我們使用靜態 Huffman 編碼來隱藏先前未出現的值，減少每個要求的大小，並改用索引取代每端靜態或動態資料表中既有的值。

HPACK 的安全性與效能

早期版本的 HTTP/2 和 SPDY 使用 zlib 搭配自訂字典壓縮所有 HTTP 標頭。這使得傳輸標頭資料的大小減少了 85% 至 88%，並且網頁載入時間延遲顯著改善。

在頻寬較低的 DSL 連結 (也就是上傳連結只有 375 Kbps) 上，要求標頭壓縮能夠大幅縮短特定網站 (也就是發出大量資源要求的網站) 的網頁載入時間。我們發現，由於標頭壓縮的關係，網頁載入時間縮短了 45 至 1142 毫秒。(SPDY 白皮書、chromium.org)。

然而，在 2012 年夏季，針對傳輸層安全標準 (TLS) 和 SPDY 壓縮演算法發布了「CRIME」安全性攻擊，這可能導致工作階段遭駭。因此，zlib 壓縮演算法已由 HPACK 取代，這經過特別設計，旨在解決發現的安全性問題、提高效率並正確實作，同時確保 HTTP 標頭中繼資料的壓縮效果良好。

如需 HPACK 壓縮演算法的完整詳細資料，請參閱 IETF HPACK - Header Compression for HTTP/2。

延伸閱讀

• 「HTTP/2」：Ilya Grigorik 的完整文章
• 「設定 HTTP/2」 - 如何由 Surma 在不同的後端設定 HTTP/2
• 「HTTP/2 開始最佳化！」– Ilya Grigorik 簡報者：Velocity 2015
• 「HTTP/2 推送的 Thumb 規則」 - 由 Tom Bergan、Simon Pelchat 和 Michael Buettner 說明推送的使用時機和方式。