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 效能限制，藉此縮短網頁載入時間。具體來說，列出的專案目標設定如下：

• 指定網頁載入時間 (PLT) 縮短 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)

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

與 HTTP/1.1 相比，HTTP/2 的主要變更著重於提升效能。某些重要功能，例如多工處理、標頭壓縮、優先順序和通訊協定交涉，從較早的開放非標準通訊協定 (SPDY) 中完成的工作演變。自 Chrome 6 版以來，Chrome 已支援 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 術語：

• 串流：在已建立的連線中雙向流動資料，可能會傳送一或多則訊息。
• 訊息：對應至邏輯要求或回應訊息的完整影格序列。
• 影格：HTTP/2 中的最小通訊單位，每個單位都包含影格標頭，至少可用來識別影格所屬的串流。

這些字詞的關係摘要如下：

• 所有通訊都是透過單一 TCP 連線執行，且該連線可容納任意數量的雙向串流。
• 每個串流都有專屬的 ID 和選用的優先順序資訊，可用於傳送雙向訊息。
• 每則訊息都是一則邏輯 HTTP 訊息，例如要求或回應 (由一或多個影格組成)。
• 框架是儲存特定類型資料的最小通訊單位，例如：HTTP 標頭、郵件酬載等。不同串流的影格可能會交錯，再透過每個影格標頭中的嵌入式串流 ID 重新組合。

簡單來說，HTTP/2 會將 HTTP 通訊協定通訊分解為二元編碼框架交換，然後將這些影格對應至屬於特定串流的訊息，這些影格全都會在單一 TCP 連線中多工處理。這個基礎可以啟用 HTTP/2 通訊協定提供的所有其他功能和效能最佳化項目。

要求與回應多工處理

使用 HTTP/1.x 時，如果用戶端想要提出多項平行要求來提升效能，則必須使用多個 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/1 有效連線來說，只有單筆交易 - 永久連線的實用性不如所有人想要一樣。但在 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 編碼功能允許在傳輸時壓縮個別值，而先前傳輸值的索引清單可讓我們傳送能有效查詢及重建完整標頭鍵與值的索引值，以便對重複值進行編碼。

在進一步最佳化的過程中，HPACK 壓縮內容包含一個靜態和動態資料表：靜態資料表定義於規格中，並提供所有連線可能使用的常見 HTTP 標頭欄位清單 (例如有效的標頭名稱)；動態資料表起初為空白，並根據特定連線內的交換值進行更新。因此，使用靜態 Huffman 編碼功能從未看過的值，並替換每一端靜態或動態資料表中已有的值的索引，藉此縮減每個要求的大小。

HPACK 的安全性與效能

早期的 HTTP/2 和 SPDY 版本使用 zlib 搭配自訂字典來壓縮所有 HTTP 標頭。傳輸標頭資料的大小減少了 85% 至 88%，並大幅縮短網頁載入時間：

在頻寬 DSL 連結中 (特別是在低頻寬 DSL 連結中，上傳連結的尺寸只有 375 Kbps)，尤其要求標頭壓縮能大幅改善特定網站 (也就是發出大量資源要求的網站) 的網頁載入時間。我們發現受到標頭壓縮的影響，網頁載入時間縮短了 45 至 1142 毫秒。(SPDY 白皮書，chromium.org)

但是，2012 年夏天，被傳輸層安全標準 (TLS) 和 SPDY 壓縮演算法發布了「CRIME」安全攻擊，這可能會導致工作階段盜用。因此，zlib 壓縮演算法已由 HPACK 取代。HPACK 的設計目的在於解決發現的安全性問題、有效且簡單地實作，當然還可以啟用 HTTP 標頭中繼資料的良好壓縮。

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

其他資訊

• 「HTTP/2」 - 由 Ilya Grigorik 撰寫的完整文章
• 「設定 HTTP/2」- 如何透過 Surma 在不同後端設定 HTTP/2
• "HTTP/2 已上線，讓我們來最佳化！"– 簡報者：Ilya Grigorik (2015 年 Velocity )
• 「HTTP/2 推送的 Thumb 規則」- Tom Bergan、Simon Pelchat 和 Michael Buettner 分析使用推送時間和方式的分析結果。