說到 hyperframes凡是碰過 HTTP/2 協(xié)議棧的人多半繞不開 hyperframe 這個(gè)名字。它是 HTTP/2 生態(tài)里最底層的那一層 Python 庫(kù)專職負(fù)責(zé)幀的構(gòu)造和解析把線上二進(jìn)制字節(jié)流翻譯成帶類型的幀對(duì)象也把業(yè)務(wù)層要發(fā)送的幀重新編碼成字節(jié)。說白了沒有它h2 連接層、hyper 客戶端這些上層建筑就只能自己從零實(shí)現(xiàn)幀邏輯。本文我打算從項(xiàng)目定位、幀格式規(guī)范、庫(kù)的實(shí)操用法、排障經(jīng)驗(yàn)四個(gè)角度把這套東西完整講一遍。適合剛開始接觸 HTTP/2 的工程師也適合已經(jīng)在用 h2、hyper 但想搞明白底層幀長(zhǎng)什么樣的同學(xué)看完你至少能徒手解析一幀、寫出自己的抓幀工具遇到 GOAWAY、幀超長(zhǎng)這類問題也知道往哪兒查。1. hyperframes 項(xiàng)目拆解HTTP/2 幀庫(kù)到底解決了什么問題1.1 從二進(jìn)制分幀說起為什么 HTTP/2 離不開幀HTTP/1.1 時(shí)代請(qǐng)求和響應(yīng)是純文本的頭字段用\r\n分隔body 靠Content-Length或者 chunked 編碼判斷邊界。這種設(shè)計(jì)在簡(jiǎn)單的請(qǐng)求—響應(yīng)模型下沒問題但一旦想做多路復(fù)用立刻撞墻TCP 上只有一條有序字節(jié)流你沒法從字節(jié)流里干凈地切出“這是請(qǐng)求 A 的頭這是請(qǐng)求 B 的 body”pipeline 又天然有隊(duì)頭阻塞體驗(yàn)極差。HTTP/2 的解法是徹底改造成二進(jìn)制分幀所有數(shù)據(jù)被切成一個(gè)個(gè)獨(dú)立的幀每個(gè)幀都帶一個(gè) 31 位的 stream id標(biāo)明它屬于哪條流。這樣一來多個(gè)請(qǐng)求可以在同一條 TCP 連接上交錯(cuò)傳輸接收方按 stream id 重新組裝互不干擾。幀frame就是這條連接上的最小傳輸單位而 hyperframes 這個(gè)名字拆開看就是 HTTP 的 Hyper 加上 Frame 的復(fù)數(shù)指的就是這套幀機(jī)制本身以及圍繞它的 Python 實(shí)現(xiàn) hyperframe 庫(kù)。1.2 hyperframe 在 Hyper 生態(tài)中的位置它和 h2、hyper 的分工很多人第一次接觸 hyperframe 是在看 h2 或者 hyper 源碼的時(shí)候這三個(gè)項(xiàng)目經(jīng)常被放在一起讀起來容易懵。實(shí)際上它們各管一段職責(zé)非常清楚hyper完整可用的 HTTP/2 客戶端/服務(wù)端接近用戶態(tài)的直接上層。h2HTTP/2 的協(xié)議狀態(tài)機(jī)負(fù)責(zé)連接生命周期、流調(diào)度、錯(cuò)誤處理這些“協(xié)議邏輯”。hpackHPACK 頭壓縮算法純壓縮/解壓不關(guān)心幀。hyperframe幀的編碼與解碼層只負(fù)責(zé)“字節(jié)和對(duì)象之間的轉(zhuǎn)換”不做任何連接管理。這么拆分的核心原因是分層測(cè)試。協(xié)議狀態(tài)機(jī)不該關(guān)心一幀在線上到底長(zhǎng)什么樣幀層也不該去理解連接狀態(tài)。舉個(gè)場(chǎng)景h2 要發(fā)送一個(gè) SETTINGS 幀它只需要構(gòu)造SettingsFrame對(duì)象填充參數(shù)然后調(diào)用serialize()拿字節(jié)上 socket接收端把字節(jié)喂給FrameBuffer取出來的是一個(gè)已經(jīng)分好類的幀對(duì)象h2 再根據(jù)對(duì)象類型去更新自己的狀態(tài)機(jī)。沒有 hyperframe 這一層狀態(tài)機(jī)就得自己拼字節(jié)、拆字節(jié)代碼里全是魔術(shù)數(shù)字根本沒法維護(hù)。1.3 適合什么人用三種典型場(chǎng)景第一種是協(xié)議學(xué)習(xí)者。我一直覺得讀十遍 RFC 7540 不如親手拆一幀。hyperframe 的 frame 類命名和規(guī)范一一對(duì)應(yīng)HeadersFrame、DataFrame、SettingsFrame源碼量不大讀起來幾乎就是在讀規(guī)范本身。第二種是中間件開發(fā)者。寫代理、網(wǎng)關(guān)、Mock 服務(wù)或者給測(cè)試環(huán)境造流量經(jīng)常需要繞過完整連接層直接構(gòu)造特定幀。比如你想驗(yàn)證“收到一個(gè) payload 超長(zhǎng)的 SETTINGS 幀時(shí)服務(wù)端會(huì)不會(huì)回 FRAME_SIZE_ERROR”用 hyperframe 幾行代碼就能做。第三種是排障工程師。連接被異常關(guān)閉、GOAWAY 刷屏、流被人為重置這些問題的根源經(jīng)常要下探到幀級(jí)才能定位。手里有一個(gè)能解析任意字節(jié)流的幀工具比抓包軟件更靈活因?yàn)槟憧梢灾苯影堰壿媽戇M(jìn)自己的監(jiān)控腳本。2. 幀格式硬核拆解讀懂九字節(jié)幀頭與九類幀2.1 逐字節(jié)拆幀頭length、type、flags、stream id 各管什么HTTP/2 的每一幀開頭固定是 9 個(gè)字節(jié)的幀頭后面跟著 payload。幀頭長(zhǎng)這樣字段長(zhǎng)度說明Length24 bitpayload 長(zhǎng)度不含幀頭自身最大可到 2^24-1Type8 bit幀類型0x0 到 0x9 為規(guī)范定義類型Flags8 bit各種布爾標(biāo)記按幀類型語(yǔ)義不同R1 bit保留位必須為 0收到為 1 按協(xié)議錯(cuò)誤處理Stream Identifier31 bit所屬流 id0 表示連接級(jí)幀注意 Length 只算 payload不算這 9 個(gè)字節(jié)。這個(gè)坑我見過好幾個(gè)人踩抓包看到一幀“總共” 18 字節(jié)以為是幀頭payload結(jié)果拆完發(fā)現(xiàn) 18 是純 payload線上實(shí)際是 27 字節(jié)。Wireshark 里顯示的也是“Frame Header: 9 bytes Payload: 18 bytes”。拆幀頭不需要什么重型工具Python 自帶能力就夠def parse_frame_header(header: bytes) - tuple: length int.from_bytes(header[0:3], big) frame_type header[3] flags header[4] stream_id int.from_bytes(header[5:9], big) 0x7FFFFFFF return length, frame_type, flags, stream_id幀頭所有多字節(jié)字段都是大端序和 IP/TCP 頭一致讀習(xí)慣了很順手。stream id 的 31 位里最高位是保留位所以這里用 0x7FFFFFFF把最高位去掉。2.2 九種幀類型一覽從 DATA 到 CONTINUATIONRFC 7540 定義了 9 種幀類型hyperframe 的hyperframe.frame模塊里每一種都有對(duì)應(yīng)的類。我把關(guān)鍵信息整理成一張對(duì)照表幀類型Type 值關(guān)鍵 Flags核心作用DATA0x0END_STREAM、PADDED傳輸請(qǐng)求/響應(yīng)實(shí)體內(nèi)容HEADERS0x1END_STREAM、END_HEADERS、PADDED、PRIORITY開啟新流并攜帶壓縮頭塊PRIORITY0x2無調(diào)整流優(yōu)先級(jí)RST_STREAM0x3無終止某條流并攜帶錯(cuò)誤碼SETTINGS0x4ACK協(xié)商連接級(jí)參數(shù)PUSH_PROMISE0x5END_HEADERS、PADDED服務(wù)端預(yù)告將推送資源PING0x6ACK心跳與往返時(shí)延測(cè)量GOAWAY0x7無服務(wù)端優(yōu)雅關(guān)閉連接WINDOW_UPDATE0x8無流量控制窗口增量CONTINUATION0x9END_HEADERS頭塊太長(zhǎng)時(shí)繼續(xù)傳輸優(yōu)先級(jí)機(jī)制在工程實(shí)踐中用得很少很多實(shí)現(xiàn)直接忽略 weight所以 PRIORITY 幀更多是“規(guī)范里有用的時(shí)候要兼容”。PUSH_PROMISE 則因?yàn)榘踩詥栴}主流站點(diǎn)默認(rèn)ENABLE_PUSH0直接關(guān)掉但在協(xié)議實(shí)現(xiàn)層面必須能解析它否則遇到老客戶端還是會(huì)被打懵。2.3 用一組真實(shí)字節(jié)流驗(yàn)證幀結(jié)構(gòu)空說沒用我直接給一組線上能看到的字節(jié)。比如一個(gè)標(biāo)準(zhǔn)的 SETTINGS 幀包含三個(gè)參數(shù)HEADER_TABLE_SIZE4096、ENABLE_PUSH0、MAX_CONCURRENT_STREAMS128它在線上是下面這一串000012 04 00 00000000 000100001000 000200000000 000300000080第一行是幀頭000012是 length十進(jìn)制 1804是 SETTINGS00是 flags沒有 ACK00000000是 stream id 0連接級(jí)幀必須用 0。第二行是 18 字節(jié) payload每個(gè)參數(shù)固定 6 字節(jié)2 字節(jié)參數(shù) id 4 字節(jié)值所以 3 個(gè)參數(shù)正好 18 字節(jié)。把這串完整的字節(jié)丟進(jìn) hyperframe 的FrameBuffer它會(huì)告訴我們應(yīng)該看到什么import binascii from hyperframe.frame import FrameBuffer raw binascii.unhexlify( 000012040000000000 000100001000000200000000000300000080 ) fb FrameBuffer(max_frame_size65536) fb.add_data(raw) while fb.has_available_data(): frame fb.next_frame() print(frame.__class__.__name__, frame.stream_id, frame.flags, frame.settings)輸出是SettingsFrame 0 set() {1: 4096, 2: 0, 3: 128}。這就對(duì)上了。你只要會(huì)拆這么一幀后面所有幀類型都是一樣的套路無非是 payload 語(yǔ)義不同。3. hyperframe 實(shí)操?gòu)臉?gòu)造握手包到流式解析3.1 環(huán)境準(zhǔn)備安裝 hyperframe 與 hpack實(shí)操之前先把依賴裝好pip install hyperframe hpackhyperframe 的定位就是“輕”它不依賴任何第三方庫(kù)Python 3.6 就能跑。hpack 不是它的依賴但實(shí)際操作中HeadersFrame.data里裝的是 HPACK 壓縮后的頭塊你不會(huì)想手工壓縮所以順手裝上后面構(gòu)造 HEADERS 幀會(huì)用到。提示hyperframe 只有幀編解碼能力沒有 socket 封裝。這意味著你自己負(fù)責(zé)從 TCP 讀字節(jié)、向 TCP 寫字節(jié)連接管理、超時(shí)、重試統(tǒng)統(tǒng)不管。第一次用可能會(huì)覺得“怎么這么簡(jiǎn)陋”但這恰恰是它擅長(zhǎng)的——把一件事做到極致別的交給上層。3.2 用代碼構(gòu)造一次 HTTP/2 連接握手HTTP/2 連接建立第一步是客戶端發(fā)送 24 字節(jié)的 Connection Preface緊接著是一個(gè) SETTINGS 幀。Preface 是固定的 ASCII 字符串PREFACE bPRI * HTTP/2.0\r\n\r\nSM\r\n\r\n assert len(PREFACE) 24然后用 hyperframe 構(gòu)造 SETTINGS 幀from hyperframe.frame import SettingsFrame client_settings SettingsFrame(0) client_settings.settings[SettingsFrame.HEADER_TABLE_SIZE] 4096 client_settings.settings[SettingsFrame.ENABLE_PUSH] 0 client_settings.settings[SettingsFrame.MAX_CONCURRENT_STREAMS] 128 first_bytes PREFACE client_settings.serialize() print(len(first_bytes)) # 24 27 51SettingsFrame(0)里的 0 是 stream idSETTINGS 是連接級(jí)幀必須傳 0。serialize()返回的就是可以直接扔進(jìn) TCP 的完整字節(jié)。這里有個(gè)小細(xì)節(jié)settings是個(gè)普通 dict插入順序會(huì)影響線上字節(jié)順序但規(guī)范明確說 SETTINGS 參數(shù)順序無關(guān)緊要解析端不關(guān)心所以不用刻意排序。握手還沒完。連接建立后客戶端要發(fā)請(qǐng)求第一個(gè)請(qǐng)求是 odd stream id1 上的 HEADERS 幀。頭塊需要 hpack 壓縮from hyperframe.frame import HeadersFrame from hpack import Encoder encoder Encoder() header_block encoder.encode([ (:method, GET), (:path, /), (:scheme, https), (:authority, example.com), (accept, text/html), ]) hf HeadersFrame(stream_id1) hf.data header_block hf.flags.add(END_HEADERS) wire hf.serialize() print(len(wire), wire.hex())hf.flags.add(END_HEADERS)是在告訴對(duì)端這個(gè)頭塊已經(jīng)完整后面沒有 CONTINUATION 了。如果頭塊太大超過了對(duì)端聲明的MAX_HEADER_LIST_SIZE你需要拆成多個(gè) HEADERS/CONTINUATION 分片傳這是另一個(gè)話題后面排障部分會(huì)說。3.3 FrameBuffer 流式解析解決半包與粘包TCP 是字節(jié)流沒有“消息邊界”。你從 socket 讀到的數(shù)據(jù)可能只包含半個(gè)幀也可能一次包含好幾個(gè)幀。FrameBuffer就是為這個(gè)場(chǎng)景設(shè)計(jì)的from hyperframe.frame import FrameBuffer fb FrameBuffer(max_frame_size65536) def feed(data: bytes) - None: fb.add_data(data) while fb.has_available_data(): frame fb.next_frame() print( fstream{frame.stream_id:5} ftype{frame.__class__.__name__:16} fflags{sorted(frame.flags)} fpayload{len(frame.serialize()) - 9} bytes )用法就是每收到一塊 socket 數(shù)據(jù)add_data塞進(jìn)去然后循環(huán)next_frame往外取。內(nèi)部它會(huì)維護(hù)一個(gè)緩沖區(qū)攢夠一整幀才給next_frame沒攢夠就返回 False。payload 長(zhǎng)度我用len(frame.serialize()) - 9算因?yàn)樾蛄谢鰜砭褪菐^payload減掉固定 9 字節(jié)幀頭就是 payload 大小。這個(gè)緩沖邏輯是所有 HTTP/2 實(shí)現(xiàn)的基礎(chǔ)h2 連接層內(nèi)部也就是這么用的。理解了 FrameBuffer你就理解了為什么網(wǎng)絡(luò)編程里“自己拼 buffer”是個(gè)高頻需求。3.4 寫一個(gè)幀查看小工具把上面的feed函數(shù)擴(kuò)展一下就能做一個(gè)最簡(jiǎn)單的離線幀查看器用來分析抓包文件#!/usr/bin/env python3 usage: python inspect_frames.py capture.bin import sys from hyperframe.frame import FrameBuffer fb FrameBuffer(max_frame_size65536) def feed(data: bytes) - None: fb.add_data(data) while fb.has_available_data(): f fb.next_frame() print( fstream{f.stream_id:5} ftype{f.__class__.__name__:16} fflags{sorted(f.flags)} fpayload{len(f.serialize()) - 9} bytes ) def main() - None: with open(sys.argv[1], rb) as fh: while chunk : fh.read(4096): feed(chunk) if __name__ __main__: main()抓包可以用tcpdump -i lo -w capture.bin tcp port 8443也可以用nghttp -v https://example.com這種現(xiàn)成工具做幀級(jí)輸出對(duì)照。自己寫一遍的好處是你可以按需過濾只打印 GOAWAY、統(tǒng)計(jì)幀類型分布、算平均 payload 大小這些邏輯腳本化之后會(huì)變成排障利器。排障提醒解析前要確認(rèn)字節(jié)流是從幀邊界開始對(duì)齊的。如果從任意中間字節(jié)開始解析第一幀頭必然錯(cuò)位后面全是垃圾。抓包時(shí)如果連上了 TCP 中間狀態(tài)先找到 Preface 或者 SETTINGS 幀頭對(duì)齊。4. 實(shí)戰(zhàn)中的坑幀級(jí)排障記錄4.1 未知幀類型擴(kuò)展幀與兼容性問題HTTP/2 規(guī)范允許實(shí)現(xiàn)定義自己的擴(kuò)展幀類型只要 type 值不沖突。FrameBuffer 遇到不認(rèn)識(shí)的類型不會(huì)拋異常而是給你一個(gè)UnknownFrame把原始 payload 原樣包在里面。這個(gè)設(shè)計(jì)很聰明未知幀按“不影響狀態(tài)”處理符合規(guī)范的兼容要求。我在實(shí)踐中遇到過一類坑某個(gè)內(nèi)網(wǎng)組件用自定義擴(kuò)展幀做心跳探活抓包軟件和常規(guī)庫(kù)都不認(rèn)識(shí)Wireshark 里只顯示“Unknown frame”。當(dāng)時(shí)用 hyperframe 解析后看到是UnknownFrame再把 payload 按十六進(jìn)制打印才看出端倪。所以排障時(shí)別看到 Unknown 就跳過payload 里往往帶著實(shí)現(xiàn)方的“私貨”。4.2 幀超長(zhǎng)與流 id 奇偶最容易翻車的兩個(gè)規(guī)則幀超長(zhǎng)是高頻錯(cuò)誤。RFC 7540 規(guī)定默認(rèn)最大幀大小是 16384 字節(jié)但接收方必須有能力處理至少這個(gè)值發(fā)送方只有在收到對(duì)端 SETTINGS 里MAX_FRAME_SIZE的聲明后才能發(fā)送更大的幀。你在FrameBuffer(max_frame_size65536)里設(shè)的 65536 只是本地接收上限不代表對(duì)端也愿意收這么大的數(shù)據(jù)幀。構(gòu)造測(cè)試幀時(shí)如果 payload 超過 16384而對(duì)方又沒聲明過更大的MAX_FRAME_SIZE那對(duì)方可以直接判定為 FRAME_SIZE_ERROR 并斷流。流 id 的奇偶規(guī)則也容易忘客戶端主動(dòng)發(fā)起的流必須是奇數(shù)1、3、5...服務(wù)端推送的流必須是偶數(shù)2、4、6...。也就是說一個(gè)實(shí)現(xiàn)必須嚴(yán)格遵守自己角色的奇偶規(guī)則。SETTINGS、PING、GOAWAY 這類連接級(jí)幀只能出現(xiàn)在 stream 0你往 stream 0 上發(fā) HEADERS 或者 DATA對(duì)方會(huì)直接 PROTOCOL_ERROR。4.3 CONTINUATION、SETTINGS ACK 與窗口更新的細(xì)節(jié)CONTINUATION 的拼圖規(guī)則HEADERS 或 PUSH_PROMISE 如果沒帶END_HEADERSflag后面必須緊跟著 CONTINUATION 幀中間不允許插入任何其他類型的幀包括 DATA 和 SETTINGS。我之前寫過一個(gè)半吊子實(shí)現(xiàn)頭塊大時(shí)拆了兩片中間夾了個(gè) PING結(jié)果服務(wù)端老實(shí)不客氣地送了 RST_STREAM。這個(gè)錯(cuò)誤抓包時(shí)極其隱蔽因?yàn)?PING 本身合法但位置非法。SETTINGS ACK 不能帶 payload收到對(duì)端 SETTINGS 后你要回一個(gè)帶 ACK flag 的 SETTINGS 幀作為確認(rèn)。這個(gè) ACK 幀的 payload 必須是空的如果往里面塞了任何參數(shù)屬于 PROTOCOL_ERROR。反過來不帶 ACK 的 SETTINGS 幀又必須帶至少一個(gè)參數(shù)空 payload 的非 ACK SETTINGS 也是錯(cuò)的。WINDOW_UPDATE 增量不能為 0frame payload 里那個(gè)遞增的窗口值范圍是 1 到 2^31-1傳 0 會(huì)觸發(fā)流級(jí)或連接級(jí)的流控錯(cuò)誤。連接級(jí)窗口和流級(jí)窗口是兩套獨(dú)立的計(jì)數(shù)調(diào)流控時(shí)別把兩個(gè)值搞混。4.4 一個(gè)真實(shí)案例連接池 GOAWAY 風(fēng)暴去年做網(wǎng)關(guān)壓測(cè)遇到一個(gè)詭異現(xiàn)象服務(wù)端日志里全是 GOAWAY客戶端重試率從 0.2% 一路爬到 8%。抓包結(jié)果如下from hyperframe.frame import FrameBuffer, GoAwayFrame, ErrorCode # 假設(shè)這是抓包解出來的一個(gè) GOAWAY 幀 goaway GoAwayFrame(0) goaway.last_stream_id 3 goaway.error_code ErrorCode.NO_ERROR # 等價(jià)于傳 0 print(goaway.serialize().hex())表面看很正常error_code 是 0NO_ERRORlast_stream_id 是 3這是優(yōu)雅關(guān)閉不是崩潰。但頻率高得離譜每幾百個(gè)請(qǐng)求就來一次。深入排查后發(fā)現(xiàn)問題不在幀本身而在連接語(yǔ)義上游負(fù)載均衡配了空閑超時(shí)空閑連接會(huì)被它主動(dòng)發(fā) GOAWAY 回收而客戶端的 h2 連接池沒有正確理解last_stream_id的含義繼續(xù)在舊連接上開新流。服務(wù)端收到已聲明關(guān)閉的連接上的新流請(qǐng)求自然一路拒絕。修復(fù)方案是客戶端在收到 GOAWAY 后把所有 stream id 大于last_stream_id的請(qǐng)求視為“當(dāng)前連接不可再用”引導(dǎo)到新建連接同時(shí)連接池在取連接前判斷一下是否已經(jīng)收過 GOAWAY。這個(gè)案例給我的教訓(xùn)是排幀級(jí)問題不能只看幀本身還要看幀之間的狀態(tài)關(guān)系。GOAWAY 不是錯(cuò)誤它是一次“通知”通知之后該干什么才是協(xié)議實(shí)現(xiàn)真正考功夫的地方。5. 擴(kuò)展玩法和一點(diǎn)個(gè)人體會(huì)5.1 用 hyperframe 做服務(wù)端邊界行為驗(yàn)證在自己掌控的測(cè)試環(huán)境里用 hyperframe 構(gòu)造一些邊界情況的幀可以高效驗(yàn)證服務(wù)端實(shí)現(xiàn)是否規(guī)范。比如發(fā)一個(gè)window_increment0的 WINDOW_UPDATE看目標(biāo)是回 FLOW_CONTROL_ERROR 還是直接忽略發(fā)一個(gè) payload 超長(zhǎng)的 DATA 幀看是否觸發(fā) FRAME_SIZE_ERROR發(fā)一個(gè)不帶END_HEADERS的 HEADERS 后面卻跟上 DATA 幀觀察對(duì)方能否正確識(shí)別協(xié)議錯(cuò)誤。這類驗(yàn)證腳本寫起來非?？煲?yàn)?hyperframe 的構(gòu)造 API 足夠接近協(xié)議本身from hyperframe.frame import WindowUpdateFrame bad WindowUpdateFrame(stream_id1) bad.window_increment 0 # 故意構(gòu)造非法值 wire bad.serialize()注意這類測(cè)試要在自己的環(huán)境做目的是驗(yàn)證兼容性和魯棒性不是拿公網(wǎng)服務(wù)當(dāng)靶子。規(guī)范的邊界行為測(cè)試是協(xié)議開發(fā)生命周期里正常的一部分和壓測(cè)、故障演練是同類事情。5.2 幀級(jí)流量觀察從抓包到性能洞察除了排障幀分布本身就很有信息量。我用 FrameBuffer 寫過一個(gè)簡(jiǎn)單的統(tǒng)計(jì)腳本對(duì)長(zhǎng)連接上的所有幀按類型計(jì)數(shù)然后看 payload 長(zhǎng)度分布。幾次觀察下來有幾個(gè)穩(wěn)定規(guī)律body 密集的接口DATA 幀占絕大多數(shù)幀平均 payload 越大傳輸效率越高如果大量 DATA 幀只有幾百字節(jié)說明應(yīng)用層寫入碎片化可以考慮合并寫。頭大的場(chǎng)景比如 Cookie 特別多HEADERS CONTINUATION 幀數(shù)量會(huì)明顯上升這時(shí)候該優(yōu)化的是 HPACK 壓縮效率和頭精簡(jiǎn)而不是 TCP 參數(shù)。幀頭固定 9 字節(jié)的代價(jià)在“小幀”場(chǎng)景會(huì)被放大1 萬字節(jié)的 body 切成 10 個(gè) 1000 字節(jié)的幀幀頭開銷接近 1%切成 16KB 的大幀后開銷基本可以忽略。時(shí)間序列上如果觀察到 WINDOW_UPDATE 的發(fā)送頻率和 DATA 幀大小不匹配往往能發(fā)現(xiàn)流控窗口配置過小的問題。這類分析用現(xiàn)成抓包工具也能做但寫腳本的好處是可以長(zhǎng)期跑、出報(bào)表、接告警把“感覺慢”變成“數(shù)據(jù)說話”。5.3 最后一點(diǎn)實(shí)際操作體會(huì)回頭說點(diǎn)個(gè)人感受。我最早學(xué) HTTP/2 是硬啃規(guī)范說實(shí)話效率很低幀類型記了又忘。后來?yè)Q了個(gè)土辦法用 hyperframe 把九種幀輪著構(gòu)造一遍、序列化、再解析回來對(duì)著結(jié)果看規(guī)范里的字段說明一下就通了。這個(gè)庫(kù)的價(jià)值不在于它多復(fù)雜而在于它把協(xié)議規(guī)范翻譯成了你隨手能擺弄的 Python 對(duì)象邊界情況、flag 組合、payload 格式全都能用代碼驗(yàn)證。踩過幾次 GOAWAY 和 CONTINUATION 的坑之后我的體會(huì)是幀層的問題通常不難定位難的是把“字節(jié)層面的現(xiàn)象”映射到“連接狀態(tài)的因果鏈”上。工具只是幫你看到現(xiàn)象真正解決問題靠的是對(duì)協(xié)議層里每一比特的敬畏。如果你也想深入這一塊建議從今天開始拿一個(gè)真實(shí)的 HTTP/2 抓包文件用上面的腳本把它完整拆一遍。拆過十幀你再看 h2 源碼會(huì)感覺每一行都透亮。