[[285457]]

前言

超文本傳輸協議(HTTP)是一種非常成功的協議。但是，HTTP/1.1 使用底層傳輸的 方式，其中有幾個特性對今天的應用程序性能有負面影響。

特別是，HTTP/1.0 在給定的 TCP 連接上一次只允許一個請求未完成。HTTP/1.1 添加了請求流水線操作(request pipelining)，但這只是部分地解決了請求并發性，并且仍然受到隊首阻塞的影響。因此，需要發出許多請求的 HTTP/1.0 和 HTTP/1.1 客戶端使用多個連接到服務器以實現并發，從而減少延遲。

[[285458]]

 

此外，HTTP 頭字段通常是重復且冗長的，導致不必要的網絡流量以及導致初始 TCP(https://tools.ietf.org/html/rfc7540#ref-TCP) 擁塞窗口被快速的填滿。當在新的 TCP 連接上發出多個請求時，這可能導致過多的延遲。

HTTP/2 通過定義了一個優化過的 HTTP 語義，它與底層連接映射，用這種方式來解決這些問題。具體而言，它允許在同一連接上交錯請求和響應消息，并使用 HTTP 頭字段的有效編碼。它還允許對請求進行優先級排序，使更多重要請求更快地完成，從而進一步提高性能。

HTTP/2 對網絡更友好，因為與 HTTP/1.x 相比，可以使用更少的 TCP 連接。這意味著與其他流量和長連接的競爭減少，反過來可以更好地利用可用網絡容量。最后，HTTP/2 還可以通過使用二進制消息幀來更有效地處理消息。

HTTP/2 最大限度的兼容 HTTP/1.1 原有行為：

1. 在應用層上修改，基于并充分挖掘 TCP 協議性能。

2. 客戶端向服務端發送 request 請求的模型沒有變化。

3. scheme 沒有發生變化，沒有 http2://

4. 使用 HTTP/1.X 的客戶端和服務器可以無縫的通過代理方式轉接到 HTTP/2 上。

5. 不識別 HTTP/2 的代理服務器可以將請求降級到 HTTP/1.X。

一. HTTP/2 Protocol Overview

 

HTTP/2 為 HTTP 語義提供了優化的傳輸。HTTP/2 支持 HTTP/1.1 的所有核心功能，但旨在通過多種方式提高效率。

HTTP/2 中的基本協議單元是一個幀。每種幀類型都有不同的用途。例如，HEADERS 和 DATA 幀構成了 HTTP 請求和響應的基礎;其他幀類型(如 SETTINGS，WINDOW_UPDATE 和 PUSH_PROMISE)用于支持其他 HTTP/2 功能。

HTTP/2 是一個徹徹底底的二進制協議，頭信息和數據包體都是二進制的，統稱為“幀”。對比 HTTP/1.1 ，在 HTTP/1.1 中，頭信息是文本編碼(ASCII編碼)，數據包體可以是二進制也可以是文本。使用二進制作為協議實現方式的好處，更加靈活。在 HTTP/2 中定義了 10 種不同類型的幀。

通過使每個 HTTP 請求/響應交換與其自己的 stream 流相關聯來實現請求的多路復用。stream 流在很大程度上是彼此獨立的，因此阻塞或停止的請求或響應不會阻止其他 stream 流的通信。

由于 HTTP/2 的數據包是亂序發送的，因此在同一個連接里會收到不同請求的 response。不同的數據包攜帶了不同的標記，用來標識它屬于哪個 response。

HTTP/2 把每個 request 和 response 的數據包稱為一個數據流(stream)。每個數據流都有自己全局唯一的編號。每個數據包在傳輸過程中都需要標記它屬于哪個數據流 ID。規定，客戶端發出的數據流，ID 一律為奇數，服務器發出的，ID 為偶數。

數據流在發送中的任意時刻，客戶端和服務器都可以發送信號(RST_STREAM 幀)，取消這個數據流。HTTP/1.1 中想要取消數據流的唯一方法，就是關閉 TCP 連接。而 HTTP/2 可以取消某一次請求，同時保證 TCP 連接還打開著，可以被其他請求使用。

流量控制和優先級確?？梢杂行У厥褂枚嗦窂陀昧?。流量控制有助于確保只傳輸接收者可以使用的數據。確定優先級可確保首先將有限的資源定向到最重要的流。

HTTP/2 添加了一種新的交互模式，服務器可以將響應推送到客戶端。服務器推送允許服務器推測性地將數據發送到服務器預測客戶端將需要這些數據的客戶端，通過犧牲一些網絡流量來抵消潛在的延遲。服務器通過合成請求來完成此操作，并將其作為 PUSH_PROMISE 幀發送。然后，服務器能夠在單獨的流上發送對合成請求的響應。

由于連接中使用的 HTTP 頭字段可能包含大量冗余數據，因此壓縮包含它們的幀。允許將許多請求壓縮成一個分組的做法對于通常情況下的請求大小具有特別有利的影響。

HTTP 協議不帶有狀態，每次請求都必須附上所有信息。所以，請求的很多字段都是重復的，比如 Cookie 和 User Agent，每次請求即使是完全一樣的內容，依舊必須每次都攜帶，這會浪費很多帶寬，也影響速度。HTTP/1.1 雖然可以壓縮請求體，但是不能壓縮消息頭。有時候消息頭部很大。

HTTP/2 對這一點做了優化，引入了頭信息壓縮機制(header compression)。一方面，頭信息使用 gzip 或 compress 壓縮后再發送;另一方面，客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發送同樣字段了，只發送索引號，這樣就提高速度了。

頭部壓縮大概可能有 95% 左右的提升，HTTP/1.1 統計的平均響應頭大小有 500 個字節左右，而 HTTP/2 的平均響應頭大小只有 20 多個字節，提升比較大。

 

接下來分 4 部分詳細討論 HTTP/2。

解開 HTTP/2 的面紗：HTTP/2 是如何建立連接的

幀和流層描述了 HTTP/2 幀的結構和形成多路復用流的方式。

幀和錯誤定義了包括 HTTP/2 中使用的幀和錯誤類型的詳細信息。

HTTP 映射和附加要求描述了如何使用幀和流表示 HTTP 語義。

雖然一些幀層和流層概念與 HTTP 隔離，但是該規范沒有定義完全通用的幀層。幀層和流層是根據 HTTP 協議和服務器推送的需要而定制的。

二. Starting HTTP/2

HTTP/2 連接是在 TCP 連接之上運行的應用層協議。客戶端是 TCP 連接發起者。

HTTP/2 使用 HTTP/1.1 使用的相同 "http" 和 "https" URI scheme。HTTP/2 共享相同的默認端口號: "http" URI 為 80，"https" URI 為 443。因此，需要處理對目標資源 URI (例如 "http://example.org/foo" 或 "https://example.com/bar")的請求的實現，首先需要發現上游服務器(客戶端希望建立連接的直接對等方)是否支持 HTTP/2。

1. HTTP/2 Version Identification

本文檔中定義的協議有兩個標識符。

• 字符串 "h2" 標識 HTTP/2 使用傳輸層安全性(TLS)TLS12的協議。該標識符用于 TLS 應用層協議協商(ALPN)擴展TLS-ALPN字段以及識別 HTTP/2 over TLS 的任何地方。

"h2�"字符串被序列化為 ALPN 協議標識符，作為兩個八位字節序列：0x68,0x32。

• 字符串 "h2c" 標識通過明文 TCP 運行 HTTP/2 的協議。此標識符用于 HTTP/1.1 升級標頭字段以及標識 HTTP/2 over TCP 的任何位置。

"h2c" 字符串是從 ALPN 標識符空間保留的，但描述了不使用 TLS 的協議。協商 "h2" 或 "h2c" 意味著使用本文檔中描述的傳輸，安全性，成幀和消息語義。

2. Starting HTTP/2 for "http" URIs

在沒有關于下一跳支持 HTTP/2 的 prior knowledge 的情況下請求 "http" URI 的客戶端使用 HTTP 升級機制([RFC7230]的第 6.7 節)?？蛻舳送ㄟ^發出包含帶有 "h2c" 標記的 Upgrade 頭字段的HTTP/1.1 請求來完成此操作。這樣的 HTTP/1.1 請求必須包含一個 HTTP2-Settings(第 3.2.1 節)頭字段。

例如：

GET / HTTP/1.1

Host: server.example.com

Connection: Upgrade, HTTP2-Settings

Upgrade: h2c

HTTP2-Settings:

在客戶端可以發送 HTTP/2 幀之前，必須完整地發送包含有效負載主體的請求。這意味著大型請求可以阻止連接的使用，直到完全發送為止。

如果初始請求與后續請求的并發性很重要，則可以使用 OPTIONS 請求執行升級到 HTTP/2，但需要額外的往返。不支持 HTTP/2 的服務器可以響應請求，就像沒有 Upgrade 頭字段一樣：

HTTP/1.1 200 OK

Content-Length: 243

Content-Type: text/html

...

服務器必須忽略 Upgrade 頭字段中的 "h2" 標記。具有 "h2" 的令牌的存在意味著 HTTP/2 over TLS，這種方式替代 3.3 節中所述協商過程。

支持 HTTP/2 的服務器通過 101(交換協議)響應接受升級。在響應 101 末尾的空行之后，服務器可以開始發送 HTTP/2 幀。這些幀必須包括對啟動升級的請求的響應。

例如：

HTTP/1.1 101 Switching Protocols

Connection: Upgrade

Upgrade: h2c

[ HTTP/2 connection ...

服務器發送的第一個 HTTP/2 幀必須是由 SETTINGS 幀組成的服務器連接前奏。收到 101 響應后，客戶端必須發送連接前奏，其中包括 SETTINGS 幀。

在升級之前發送的 HTTP/1.1 請求被賦予 stream 流標識符 1 (參見第 5.1.1 節)，它是默認優先級值(第 5.3.5 節)。Stream 流 1 從客戶端隱式"半封閉"的流向服務器(參見第5.1節)，因為請求是作為 HTTP/1.1 請求完成的。在開始 HTTP/2 連接之后，stream 流 1 用于響應。

3. HTTP2-Settings Header Field

從 HTTP/1.1 升級到 HTTP/2 的請求必須包含一個 "HTTP2-Settings" 頭字段。HTTP2-Settings 標頭字段是一個特定于連接的 header 字段，其中包含管理 HTTP/2 連接的參數，這個參數在服務器接受升級請求的情況下提供的。

HTTP2-Settings = token68 

如果此 header 字段不存在或存在多個連接，則服務器不得升級到 HTTP/2 的連接。服務器不得發送此 header 字段。

HTTP2-Settings 頭字段的內容是 SETTINGS 幀的有效負載，編碼為 base64url 字符串(即[RFC4648]第 5 節中描述的 URL 和文件名安全的 Base64 編碼，省略任何尾隨的 '=' 字符)。ABNF RFC5234(RFC5234：https://tools.ietf.org/html/rfc5234) 生成 "token68" 在 [RFC7235]的第 2.1 節中定義。

由于升級僅用于立即連接，因此發送 HTTP2-Settings header 字段的客戶端也必須在 Connection 頭字段中發送 "HTTP2-Settings" 作為連接選項，以防止它被轉發。

服務器解碼并解釋這些值，就像任何其他 SETTINGS 幀一樣。不必明確確認這些設置，因為 101 響應用作隱式確認。在升級請求中提供這些值，目的的為了使客戶端有機會在從服務器接收任何幀之前提供參數。

4. Starting HTTP/2 for "https" URIs

向 "https" URI發出請求的客戶端使用 TLS TLS12(https://tools.ietf.org/html/rfc7540#ref-TLS12) 和應用層協議協商(ALPN)擴展 TLS-ALPN(https://tools.ietf.org/html/rfc7540#ref-TLS-ALPN)。

HTTP/2 over TLS 使用 "h2" 協議標識符。"h2c" 協議標識符不得由客戶端發送或由服務器選擇; "h2c" 協議標識符描述了一個不使用 TLS 的協議。

一旦 TLS 協商完成，客戶端和服務器都必須發送連接前奏。

5. Starting HTTP/2 with Prior Knowledge

客戶端可以通過其他方式了解特定服務器是否支持 HTTP/2。例如，ALT-SVC 描述了一種可以獲得服務器是否支持 HTTP/2 的機制。

客戶端必須發送連接前奏，然后可以立即將 HTTP/2 幀發送到服務器; 服務器可以通過連接前奏的存在來識別這些連接。這只影響通過明文 TCP 建立 HTTP/2 連接; 通過 TLS 支持 HTTP/2 的實現必須在 TLS TLS-ALPN 中使用協議協商。同樣，服務器必須發送連接前奏。

如果沒有其他信息，先前對 HTTP/2 的支持并不是一個強信號，即給定服務器將支持 HTTP/2 以用于將來的連接。例如，可以更改服務器配置，使群集服務器中的實例之間的配置不同，或者更改網絡條件。

6. HTTP/2 Connection Preface

"連接前奏" 有些地方也會翻譯成 "連接序言"。

在 HTTP/2 中，每個端點都需要發送連接前奏作為正在使用的協議的最終確認，并建立 HTTP/2 連接的初始設置。客戶端和服務器各自發送不同的連接前奏。

客戶端連接前奏以 24 個八位字節的序列開始，以十六進制表示法為：

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 

也就是說，連接前奏以字符串 "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" 開頭。該序列必須后跟 SETTINGS 幀，該幀可以為空?？蛻舳嗽谑盏?101 (交換協議)響應(指示成功升級)或作為 TLS 連接的第一個應用程序數據八位字節后立即發送客戶端連接前奏。如果啟動具有服務器對協議支持的 prior knowledge 的 HTTP/2 連接，則在建立連接時發送客戶端連接前奏。

注意：選擇客戶端連接前奏，以便大部分 HTTP/1.1 或 HTTP/1.0 服務器和中間件不會嘗試處理更多幀。請注意，這并未解決 TALKING 中提出的問題。

連接前奏里面的字符串連起來是 PRISM ，這個單詞的意思是“棱鏡”，就是 2013 年斯諾登爆出的“棱鏡計劃”。

服務器連接前奏包含一個可能為空的 SETTINGS 幀，該幀必須是服務器在 HTTP/2 連接中發送的第一幀。

作為連接前奏的一部分從對等端收到的 SETTINGS 幀，必須在發送連接前奏后得到確認。

為避免不必要的延遲，允許客戶端在發送客戶端連接前奏后立即向服務器發送其他幀，而無需等待接收服務器連接前奏。但是，需要注意的是，服務器連接前奏 SETTINGS 幀可能包含參數，這些參數是客戶端希望與服務器通信時必須的參數。在接收到 SETTINGS 幀后，客戶端應該遵守所建立的任何參數。在某些配置中，服務器可以在客戶端發送附加幀之前發送 SETTINGS，從而提供避免此問題的機會。

客戶端和服務器必須將無效的連接前奏視為 PROTOCOL_ERROR 類型的連接錯誤。在這種情況下可以省略 GOAWAY 幀，因為無效的連接前奏表明對等方沒有使用 HTTP/2。

最后，我們抓包看一下 HTTP/2 over TLS 是如何建立連接的。當 TLS 握手結束以后(TLS 握手的流程這里暫時省略，客戶端和服務端已經通過 ALPN 協商出了接下來應用層使用 HTTP/2 協議進行通信，于是會見到類似如下的抓包圖：

 

可以看到在 TLS 1.3 Finished 消息之后，緊接著就是 HTTP/2 的連接序言，Magic 幀。

 

客戶端連接前奏以 24 個八位字節的序列開始，以十六進制表示法為：

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 

連接前奏就是字符串 "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" 開頭。Magic 幀之后緊跟著 SETTINGS 幀。當服務端成功 ack 了這條消息，并且沒有連接報錯，那么 HTTP/2 協議就算連接建立完成了。