HTTP2 多路複用原理以及 gRPC 抓包分析
一、背景
HTTP2 入門 這篇文章我們講了採用多路複用技術來實現一個 TCP 連接承載多個 HTTP 並行請求，但它具體是如何實現的呢，因爲 HTTP2 的多路複用是 gRPC 高性能最主要的原因之一，下面我們就來詳細瞭解一下。
二、HTTP2 多路複用基本原理
1、幀
HTTP2 在 HTTP1 基礎上引入了二進制分幀層，數據封包給下層協議之前將數據打散成更小的幀並以二進制的方式進行編碼傳輸。
幀結構
2、流
流是一個虛擬的概念，我們把一次請求 / 響應中，擁有同一流標識符的所有幀抽象成一個流。
在流的層面數據是有序的，但在 TCP 層面數據是無序的。將多個 HTTP 消息分解爲互不依賴的幀，然後交錯發送（對於同一個 HTTP 消息是按順序發送的），在另一端依據流標識符組裝起來，這樣就實現了多路複用。
三、gRPC 案例抓包分析
我們首先將 gRPC 初體驗 中 Server 端打包部署在測試環境 118.178.255.158(內部 IP:172.16.79.224)，然後在本機運行客戶端代碼進行抓包實驗。
tcpdump -ieth0 port 50051 -w grpc.pcap用 WireShark 打開後需要設置 50051 端口採用 HTTP2 協議解析
完整數據包如下：
Protocol 協議有 TCP、HTTP2、GRPC 三種。
通過數據包我們分析出客戶端與服務端交互過程如下
1、 第 1~3 個包 TCP 三次握手
2、 第 4 個包 服務端 -> 客戶端 幀類型爲 SETTINGS 設置連接的參數及管理流控制窗口。
3、第 5 個包 客戶端的應答
4、第 6 個包 客戶端 -> 服務端 幀類型爲 Magic 主要作用是對使用 HTTP2 協議的確認，確定啓用 HTTP2 連接。
5、第 7~8 個包，服務端 -> 客戶端，服務端的應答及 SETTINGS 幀
6、第 9~11 個包，客戶端 -> 服務端，管理流控制窗口、應答、SETTINGS 幀。
7、第 12 個包，服務端 -> 客戶端 ，應答
8、第 13 個包，GRPC 客戶端 -> 服務端，發送 HEADERS 幀，HEADERS 幀用來傳遞 HTTP 頭信息，另外還發送了 DATA 幀，包括兩部分 GRPC Message 和 ProtoBuf
9、第 14 個包 服務端 -> 客戶端 ，發送 HEADERS 幀和 DATA 幀
10、第 15~18 TCP 四次揮手
總結
1、gRPC 在 TCP 三次握手之後會發送 MAGIC 和 SETTINGS 幀來確認協議和配置。
2、gRPC 在傳輸數據過程會設計滑動窗口等流控制策略。
3、gRPC 附加信息基於 HEADERS 幀傳輸，具體請求和響應數據基於 DATA 幀傳輸。
4、gRPC 請求和響應分爲 HTTP 和 gRPC 狀態。
注：本人對於 gRPC 剛學會了一個 HelloWorld 但未有更深入的學習，這兩天一直有個疑惑，因爲例子是完全基於 SDK 調用，而非請求 HTTP 接口，很是懷疑 gRPC 到底是直接走 TCP Socket 層還是走 HTTP2，通過抓包分析發現確實是走 HTTP2，後續會進一步研究 gRPC 的使用和源代碼。
四、友情鏈接
3、序列化方案對比
4、HTTP2 入門
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NoxI7O8mGUPiW734ZmoB5w