前言

HTTP/2協議在TCP連接之初進行協商通信，只有協商成功，才會涉及到后續的請求-響應等具體的業務型數據交換。

HTTP版本標識符

• h2，基于TLS之上構建的HTTP/2，作為ALPN的標識符，兩個字節表示，0x68, 0x32，即https
• h2c，直接在TCP之上構建的HTTP/2，缺乏安全保證，即http
• 在HTTP/2 RFC文檔出現之前，以上版本字段需要添加上草案版本號，類似于h2-11,h2c-17

HTTP/2 請求過程

針對直接建立在標準TCP之上HTTP2，在未知服務器是否提供HTTP/2支持之前，可以依賴現有HTTP/1.1進行試探。

HTTP版本的請求內容

客戶端發起請求，只有請求報頭： GET / HTTP/1. 1 Host: server. example. com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

服務器若不支持HTTP/2，直接按照HTTP/1.1響應即可 HTTP/1. 1 200 OK Content-Length: 243 Content-Type: text/html . . .

服務器支持HTTP/2，通知客戶端一起切換到HTTP/2協議下吧

HTTP/1. 1 101 Switching Protocols Connection: Upgrade Upgrade: h2c [ HTTP/2 connection . . .

101響應空行之后，服務器必須發送的第一個幀為SETTINGS幀（其負載可能為空）作為連接序言

客戶端接收到101響應后，也必須發送一個序言作為響應，其邏輯結構： PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // 純字符串表示，翻譯成字節數為24個字節 SETTINGS幀 // 其負載可能為空 服務器端和客戶端所發送的連接序言有所不同。

客戶端可以馬上發送請求幀或其它幀過去，不用等待來自服務器端的SETTINGS幀

任一端接收到SETTINGS幀之后，都需要返回一個包含確認標志位SETTIGN作為確認

其它幀的正常傳輸

HTTP/2的直接連接

客戶端預先知道服務器提供HTTP/2支持，可以免去101協議切換的流程開銷。 具體流程：

客戶端必須首先發送一個連接序言，其邏輯結構： PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // 純字符串表示，翻譯成字節數為24個字節 SETTINGS幀 // 其負載可能為空

發送完畢序言之后，客戶端可以不用等待來自服務器端響應，馬上發送HTTP/2其它幀

服務器端接收到客戶端的連接序言之后，需要發送一個SETTINGS幀作為連接序言

任一端接收到SETTINGS幀之后，都需要返回一個包含確認標志位SETTIGN作為確認

其它幀的正常傳輸

HTTPS版本建立連接

HTTP/2安全版本在TLS上構建，協商采用的ALPN擴展協議，采用“h2”作為協議標識符（http版本則是“h2c”）。一定程度上可認為不存在試探是否支持或直接連接的煩惱，因為這個過程直接在TLS層協商而成。

流程如下：

客戶端和服務器端TLS層協商

客戶端發送連接序言（同上表示，PRI + SETTINGS）

接收到客戶端連接序言之后，服務器端發送連接序言

雙方各自確認SETTINGS幀

其它幀的正常傳輸

HTTPS和HTTP Upgrade方式協商

HTTPS協商是強制，封裝在TLS之上ALPN擴展實現，HTTP只有非直接連接方式才會存在通過101 協議切換方式進行升級。

這里有一張圖形象說明其流程。

統一的連接過程

這里不論是HTTP還是HTTPS，在兩端成功協商之后（或HTTP的直接連接），其連接過程都是一樣的

注意事項

客戶端發起的HTTP/1.1請求，其流標識符為1，默認優先級；半關閉“half closed”狀態，一旦完成HTTP/2的連接，將被應用于響應

文檔提到的客戶端可以通過HTTP Alternative Services（簡稱為[ALT-SVC]，類似于CNAME機制）獲得通知服務器是否支持HTTP/2，但目前看來僅僅是草案建議而已

連接序言用于最后兩端協商確認雙方要使用HTTP/2協議，建立初始化的HTTP/2連接環境

客戶端若知服務器支持HTTP/2，可免去通過HTTP/1.1 101協議切換方式進行升級，在建立連接后即可發送序言，否則只能在接收到服務器端101響應后發送序言

建立在TLS上的HTTP/2通過ALPN擴展協商機制取代101協議切換

連接序言所包含的SETTINGS幀其負載可以為空

針對一個TCP連接，服務器第一個要發送的幀必須是SETTINGS幀

為了避免不必要延遲，客戶端可以在發送完畢序言之后發送幀數據，不用等待來自服務器端的序言SETTINGS幀

客戶端接收到服務器端作為序言的SETTINGS幀，需要遵守其設定

在一些環境下需要提供一個順序機制，允許服務器在客戶端發送業務幀之前發送SETTINGS，這需要客戶端配合

客戶端和服務器端任何一方接收到無效連接序言需要拋出PROTOCOL_ERROR類型連接錯誤，若收到GOAWAY幀，可忽略

小結

HTTP/2連接的建立協商機制比HTTP/1.1稍微復雜了一些。

對比明文版的HTTP/1.1和HTTP/2完成一次請求-響應：

HTTP/1.1在建立建立之后，只需要發送請求報文數據

HTTP/2客戶端需要在連接建立之初馬上發送一個連接序言過去，然后才是正常請求

兩端（客戶端+服務器端）的兩次完整的連接序言+確認的交互流程，多了兩次往返過程

在弱網絡環境下，會不會加重網絡負載，只能拭目一看了。

引用

《Implementing HTTP/2 client in 60 minutes》

原文?http://www.blogjava.net/yongboy/archive/2015/03/18/423570.html

轉載于:https://www.cnblogs.com/yudar/p/4642593.html

總結

以上是生活随笔為你收集整理的HTTP/2笔记之连接建立的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。