1. 从一次帧边界错乱的排障说起hyperframes 到底解决什么问题说到 hyperframes圈内一般指的是 HTTP/2 里那一整套二进制帧frame的统称而在 Python 生态里它对应一个具体到不能再具体的库hyperframe。去年我维护一个自研网关底层跑的是 HTTP/2 RPC 通道遇到一个特别诡异的 bug客户端偶尔会把两条相互独立的响应合并进同一个 TCP 报文里发过来。我按 HTTP/1.1 时代的惯性思维去报文里找空行、找 Content-Length、找 chunked 的结束标记折腾了一个下午全是徒劳。后来把报文用 hexdump 拉出来一个字节一个字节看才意识到问题本质HTTP/2 的帧边界根本不由任何分隔符决定而是由每个帧头里那三个字节的 length 字段自己说了算我一直在用一个旧协议的思维去解一个新协议的字节流当然解不出来。也就是从那次开始我把 hyperframe 这个库从头到尾读了一遍并用它重写了网关里的帧解析模块。这篇文章就是围绕这次实战展开的帧头 9 个字节怎么排布、十种标准帧类型和 hyperframe 类的对应关系、怎么手工组装和解析一帧、以及我在真实项目里踩过的那些标志位和流控的坑。如果你要写 HTTP/2 客户端或服务端、要排查慢请求、要做一个协议测试工具或者只是想在 Wireshark 里看懂那些 Frame 到底是什么这篇都适合你。哪怕你之前没碰过 HTTP/2只要会 Python 基础语法顺着文章一步步来也能上手。1.1 为什么 HTTP/2 要把帧从流里单独拆出来HTTP/1.1 的消息是文本格式起始行、一堆 Header、空行、Body靠 CRLF 和 Content-Length 来切分。这套方案在简单场景下没毛病但有两个天生缺陷一是文本解析慢二是同一个连接上一次只能跑一个请求后面的请求必须排队这就是所谓的队头阻塞。HTTP/2 为了解决这两个问题把整个协议改成了二进制帧一个 TCP 连接上可以同时跑多个逻辑上的流stream每个流承载一个请求-响应交换而流里的数据被切成一小块一小块这些小块的载体就是帧。帧与帧之间可以在连接上任意交错接收方靠帧头里的 stream id 把它们重新归位到各自的流上。这里有个关键点需要理解TCP 给你的是一条没有边界的字节流它不关心你上层怎么切数据。HTTP/2 的每个帧都是自描述的帧头里写清楚了这个帧有多长、是什么类型、携带哪些标志、属于哪个流接收方必须严格按帧头声明的长度去消费字节流。套用个生活化的比喻TCP 是一条水管HTTP/2 把水打成一格一格的集装箱——帧每个集装箱上写编号stream id和用途type接收方按编号把集装箱分到不同的传送带上。hyperframe 干的事就是负责把这些集装箱从车上搬上搬下把字节流解成 Frame 对象或者把 Frame 对象重新序列化成字节流。装卸队不关心箱子里面装的是什么货但箱子的尺寸、标签、编号它必须门儿清。1.2 hyperframe 在 python-hyper 栈里的位置python-hyper 是一个 Python 的 HTTP/2 协议实现家族主要三个库h2 是完整的协议栈负责连接状态机、流的生命周期、流控调度这些上层管理hpack 负责 HPACK 头部压缩处理请求/响应头的编码和解码hyperframe 则是最底层的帧仓库职责非常单一——字节到 Frame 的解析、Frame 到字节的序列化、以及标志位和字段的合法性校验。搞清楚这条边界很重要否则你会走弯路。hyperframe 不维护连接状态你发了一个 HEADERS 帧之后它不会提醒你这个流还没结束它不做 HPACK 压缩你塞给它的 header block 必须已经在外面用 hpack 编码好了它不管 TLS如果你走 https帧要先包在 TLS record 里那不是 hyperframe 的管辖范围。很多人第一次用 hyperframe 拼请求失败就是因为把不属于它的职责强加给它了。它的定位是协议积木里的最小单元——当你需要自己实现协议栈、写抓包校验工具、或者做异常帧注入测试时这套积木就是最趁手的工具。2. 帧头九个字节的位级拆解长度、类型、标志位与流 ID 的排布HTTP/2 的所有帧开头都是完全相同的 9 字节帧头这是整个协议最基础也最需要吃透的部分。当前规范是 RFC 9113它取代了早年的 RFC 7540帧头格式没有动过还是四段字段。2.1 四段字段的排布与为什么这么设计偏移长度字段说明03 字节Length帧载荷长度24 位无符号整数网络字节序大端31 字节Type帧类型即 0 到 9 的标准类型和扩展类型41 字节Flags标志位按位使用不同帧类型对每一位的定义不同54 字节R Stream Identifier最高 1 位保留必须为 0低 31 位是流 ID你可能想问Length 为什么是 24 位而不是 32 位因为 24 位能表达的最大值已经是 16777215约 16MB足够覆盖极大单帧场景而协议还要求默认单帧上限 16384这两个数字后面我们要区分清楚。Stream Identifier 为什么是 31 位而不是 32 位最高位保留给未来扩展同时 31 位有符号范围在多数语言里处理起来不会踩符号位陷阱。整段帧头一律大端序排列这在网络协议里是通用约定解析时尤其注意不要用本机小端序去读。标志位这一字节最容易被想当然。同一个 0x1 位在 DATA 帧和 HEADERS 帧上叫 END_STREAM在 SETTINGS 帧和 PING 帧上却叫 ACK。所以解读 flags 一定要结合帧类型不能死记第 0 位是啥。下面这张表是十种标准帧里最常用的标志位速查位值适用帧含义00x1DATA / HEADERSEND_STREAM数据发送完毕00x1SETTINGS / PINGACK确认收到对端帧20x4HEADERS / PUSH_PROMISE / CONTINUATIONEND_HEADERS头部块结束30x8DATA / HEADERS / PUSH_PROMISEPADDED载荷带填充50x20HEADERSPRIORITY帧内携带优先级信息2.2 手工解析一个 SETTINGS 帧逐字节读出来实践出真知我直接拿一个真实会出现在连接建立阶段的字节序列来演示。下面这段是一个 SETTINGS 帧加上它的载荷共 21 个字节我从 Wireshark 的抓包里导出来过类似的东西00 00 0c 04 00 00 00 00 00 00 03 00 00 00 64 00 04 00 00 ff ff逐个字节拆前 3 字节00 00 0c是长度十六进制 0x0c 12说明载荷区有 12 字节。第 4 字节04是类型十进制的 4 正是 SETTINGS。第 5 字节00是 flags这里是 0表示普通 SETTINGS 而非 ACK。第 6 到第 9 字节00 00 00 00是流 IDSETTINGS 是连接级帧流 ID 必须是 0。从第 10 字节开始是 12 字节载荷SETTINGS 载荷是若干个 6 字节一组的参数前 2 字节是参数 ID后 4 字节是参数值。第一组00 03 00 00 00 64ID 0x0003 对应 SETTINGS_MAX_CONCURRENT_STREAMS最大并发流数值 0x00000064 100。第二组00 04 00 00 ff ffID 0x0004 对应 SETTINGS_INITIAL_WINDOW_SIZE初始流控窗口值 0x0000ffff 65535。解析完全不依赖任何上下文单凭这一段字节就能还原全部信息这正是自描述帧的设计初衷。用 hyperframe 做同样的事代码相当干净from hyperframe.frame import Frame, SettingsFrame raw bytes.fromhex(00000c04000000000000030000006400040000ffff) frames, consumed Frame.parse_frames(raw) for frame in frames: if isinstance(frame, SettingsFrame): print(settings:, frame.settings) print(consumed bytes:, consumed)输出会是settings: {3: 100, 4: 65535}consumed bytes: 21。注意parse_frames返回两个值第二个是实际消费的字节数——这在处理 TCP 粘包时极其有用你拿总字节数减去 consumed剩下的就是下一帧的数据。这个返回值我是经常用的比单纯遍历 frames 重要得多。2.3 为什么解析要区分严格模式hyperframe 的parse_frames有个strict参数默认False。在我常驻的 6.x 版本里遇到未注册的未知帧类型时非严格模式会把它包装成ExtensionFrame原样返回保留 type、flags、body 原始字节严格模式则直接抛出UnknownFrameError。这个设计跟协议本身的精神是相通的RFC 9113 明确要求端点收到未知帧类型时必须忽略因为未来可能增加新帧类型老实现在不认识的情况下跳过即可不能把连接搞挂。所以如果你在写服务端我建议用非严格模式把未知类型当成透明数据继续读后续字节strictTrue更适合测试场景用来暴露你预期之外的帧类型。3. 十种标准帧类型与 hyperframe 类的映射一张表讲清职责边界HTTP/2 标准定义了十种帧类型hyperframe 为每一种都对应了一个类类名基本就是帧名去掉空格加上 Frame。理清这张映射表你就拿到了理解整个协议帧层的索引。3.1 一张表串起来类型编号帧名称hyperframe 类允许的流 ID用途0DATADataFrame大于 0传输请求/响应体1HEADERSHeadersFrame大于 0打开流、携带头部块2PRIORITYPriorityFrame大于 0调整流的优先级3RST_STREAMRstStreamFrame大于 0终止一个流4SETTINGSSettingsFrame只能为 0协商连接级参数5PUSH_PROMISEPushPromiseFrame大于 0服务端主动推送预告6PINGPingFrame只能为 0心跳与往返时延测量7GOAWAYGoAwayFrame只能为 0优雅关闭、告知已处理流范围8WINDOW_UPDATEWindowUpdateFrame0 或大于 0流控窗口恢复9CONTINUATIONContinuationFrame大于 0头部块超长时的续传这里有个非常容易忽略的约束哪些帧能用流 ID 0哪些不能协议写得死死的。SETTINGS、PING、GOAWAY 是连接级帧流 ID 必须是 0WINDOW_UPDATE 分两种流 ID 为 0 时调整的是连接级窗口大于 0 时调整的是对应流的窗口其余所有帧都要求流 ID 大于 0。如果你构造了一个 DATA 帧把 stream_id 填成 0对端会直接判定 PROTOCOL_ERROR 并断开连接。这个错我见过不少新手犯因为 hyperframe 构造函数不拦你它是协议层的事。3.2 重点类型的协议语义SETTINGS 是连接建立后第一波交互的主角每个参数项固定 2 字节 ID 加 4 字节值。标准参数有 6 个SETTINGS_HEADER_TABLE_SIZEHPACK 动态表上限、SETTINGS_ENABLE_PUSH是否允许服务端推送、SETTINGS_MAX_CONCURRENT_STREAMS最大并发流数、SETTINGS_INITIAL_WINDOW_SIZE初始流控窗口、SETTINGS_MAX_FRAME_SIZE单帧上限、SETTINGS_MAX_HEADER_LIST_SIZE头部块总大小上限。注意 SETTINGS 的 ACK 帧载荷必须为空带了载荷的 ACK 属于协议错误。HEADERS 和 CONTINUATION 是一对搭档。HEADERS 帧打开一个新流或者给已有流附加头部它的载荷是 HPACK 编码后的 header block fragment。如果这个 block 太长、超过了对端通告的单帧上限协议要求必须拆成多个 HEADERS/CONTINUATION 帧接力发送并且用 END_HEADERS 标志标记结束。hyperframe 不会帮你做这个分片它只管单帧的序列化分片逻辑属于 h2 那种完整协议栈的职责。PUSH_PROMISE 在现实流量里几乎见不到因为主流浏览器默认都关掉了服务端推送你只要知道它存在、以及它和 HEADERS 一样要遵守 END_HEADERS 规则就够了。PING 是最实用的调试工具载荷固定 8 字节你可以塞任意 8 字节当标识对端必须原样回一个 ACK 的 PING。在排查连接到底还活着吗这种问题时发一个带随机数的 PING 比啥都直观。GOAWAY 则是优雅下线的关键它携带 last_stream_id语义是我这边不会再处理任何流 ID 大于这个值的流了服务端要重启前发一个 GOAWAY 告诉客户端别开新流了已开的老流还能老老实实跑完。RST_STREAM 是流的终止牌payload 里是一个 4 字节错误码常见的有 PROTOCOL_ERROR0x1、FLOW_CONTROL_ERROR0x3、STREAM_CLOSED0x5、FRAME_SIZE_ERROR0x6、REFUSED_STREAM0x7、CANCEL0x8、COMPRESSION_ERROR0x9、ENHANCE_YOUR_CALM0xb调协议时认出这些错误码能省很多翻文档的时间。PRIORITY 帧载荷固定 5 字节1 位独占标记加 31 位依赖流 ID再加 1 字节权重权重合法范围是 1 到 256默认 16。4. 实操从组装第一帧到完整收发循环理论说再多不如亲手组装一帧。这一节我把几个最常用的组装、解析、收发场景完整写出来代码都是可以直接复制跑的。4.1 构造 SETTINGS 并序列化逐字节核对输出第一步从最简单的 SETTINGS 开始。我们要发送两个参数最大并发流数 100、初始流控窗口 65535。from hyperframe.frame import SettingsFrame settings SettingsFrame(stream_id0) settings.settings { SettingsFrame.SETTINGS_MAX_CONCURRENT_STREAMS: 100, SettingsFrame.SETTINGS_INITIAL_WINDOW_SIZE: 65535, } raw settings.serialize() print(raw.hex( ))输出是00 00 0c 04 00 00 00 00 00 00 03 00 00 00 64 00 04 00 00 ff ff把它跟第 2.2 节手工拆解的那段字节比对一下一模一样。这说明什么呢说明 hyperframe 的序列化逻辑就是严格按协议走的长度自动算成 12类型自动填 4流 ID 保持 0POST 参数按插入顺序排列。用这个库的好处就是你不用自己拼字节但建议拼完之后还是hex( )出来肉眼过一次对协议的理解就是在这种对照里加深的。提示设置settings.settings这个字典时参数顺序影响序列化后的字节顺序。协议没有规定 SETTINGS 条目必须排序所以对端解析不依赖顺序但你核对抓包时要注意这点别因为顺序对不上就以为出错了。4.2 用 hpack hyperframe 拼一个真实的 GET 请求帧真正发请求时HEADERS 帧的 payload 必须是 HPACK 压缩后的 header block这活儿 hyperframe 不干得交给 hpack。两者配合的套路是这样的from hpack import Encoder from hyperframe.frame import HeadersFrame from hyperframe.flags import Flags # 1) 用 HPACK 编码头部块 encoder Encoder() header_block encoder.encode([ (b:method, bGET), (b:scheme, bhttps), (b:authority, bexample.com), (b:path, b/index.html), ]) # 2) 把编码后的字节塞进 HEADERS 帧 frame HeadersFrame(stream_id1) frame.data header_block frame.flags | Flags.END_HEADERS | Flags.END_STREAM raw frame.serialize() print(raw.hex( ))这里两个细节值得讲。第一伪头字段:method、:scheme、:authority、:path这些都是必须的没有它们对端无法路由请求这是 HTTP/2 的硬性要求。第二flags | Flags.END_HEADERS | Flags.END_STREAM表示头部块到此结束、同时这个流没有请求体了一个 GET 请求就是这么一帧搞定的。如果你的请求带 body那就不置 END_STREAM后面再跟一个或多个 DATA 帧在最后一个 DATA 帧上置 END_STREAM。接收端解码同样简单from hpack import Decoder decoder Decoder() headers decoder.decode(header_block) print(headers)会得到形如[(b:method, bGET), ...]的列表。注意收发两端必须各用一个长生命周期的 encoder/decoder 实例因为 HPACK 的上下文是连接级的动态表状态一直在变用完了就丢等于每次从零开始压缩率会非常难看在某些严格实现下还可能被认为是协议违规。4.3 FrameBuffer处理粘包和半包的正确姿势文章开头那个 bug 的解法其实就在这里。网络世界里 一个 TCP 报文可能装着半个帧也可能装着好几个完整帧直接用parse_frames去啃 socket 裸数据必然出问题。hyperframe 提供了FrameBuffer来专门解决这个缓冲、拼接的问题from hyperframe.frame import FrameBuffer buf FrameBuffer() buf.feed(packet1) # 第一次 recv 到的数据 frames buf.get_frames() # 可能一个完整帧都没有 buf.feed(packet2) # 第二次 recv 到的数据 frames buf.get_frames() # 凑齐了再取它的内部维护了一个字节缓冲区和游标feed只是往里塞数据get_frames才会尝试从缓冲里把完整帧一个一个抠出来没凑够 9 字节帧头就返回空列表不产生异常。这背后的逻辑正是第 1.1 节说的那个核心认知帧边界由帧头里的 length 字段决定而FrameBuffer把这个判断封装成了开箱即用的 API。我在排障时反复用到的场景是第一次recv只收到了一个帧的前 5 个字节get_frames返回空第二次recv把剩下的 16 个字节补齐了get_frames才吐出一个完整 SETTINGS 帧。如果你不用FrameBuffer、硬要把两次 recv 的数据分别解析你就会被半包折磨得死去活来。这是我给所有初学者的第一条忠告凡是 readsocket 的代码解析帧一律走 FrameBuffer别自己写拼接逻辑。4.4 最小连接发送前言 SETTINGS读对端的 SETTINGSHTTP/2 有个特别容易被忽略的仪式客户端连接建立后必须先原样发送 24 字节的连接前言connection preface再紧跟一个 SETTINGS 帧。前言是固定的 ASCII 字符串PRI * HTTP/2.0\r\n\r\nSM\r\n\r\nhyperframe 不会替你生成这个前言它只负责帧。所以一个最小可跑的明文 HTTP/2h2c客户端长这样import socket from hyperframe.frame import SettingsFrame, FrameBuffer preface bPRI * HTTP/2.0\r\n\r\nSM\r\n\r\n settings SettingsFrame(stream_id0) settings.settings {SettingsFrame.SETTINGS_MAX_CONCURRENT_STREAMS: 128} sock socket.create_connection((127.0.0.1, 8080), timeout5) sock.sendall(preface settings.serialize()) buf FrameBuffer() buf.feed(sock.recv(4096)) for frame in buf.get_frames(): print(type(frame).__name__, stream_id, frame.stream_id)跑通这个最小循环本地起一个 h2c 明文服务比如 python-h2 仓库自带的 example或者 nghttp2 的 nghttpd你会发现服务端收到前言后会立刻回一个自己的 SETTINGS后续才能谈别的。如果你的服务在 TLS 后面那么这些帧要先经过 TLS 解密才能看到TCP 层收到的是 TLS record这是另一个战场了后面抓包部分会讲。这里先记住一个原则前言不是帧帧也不是前言两者缺一不可很多互操作问题都是前言发错或者漏发导致的。5. 我踩过的帧级雷区标志位、流控与长度上限代码能跑只是第一步真正让你长记性的是线上那些诡秘的失败。这一节全是我在真实项目里被坑过、并且后来在 hyperframe 源码里找到答案的地方。5.1 PADDED 和 PRIORITY 同时出现时载荷顺序是固定套路帧载荷里带填充padding用来掩盖报文长度特征头部帧还可能在开头塞优先级信息。当 HEADERS 帧同时置了 PADDED0x8和 PRIORITY0x20两个标志时payload 的布局是严格固定的顺序错一位后面全乱Pad Length (1 字节仅当 PADDED) E Stream Dependency (4 字节仅当 PRIORITY) Weight (1 字节仅当 PRIORITY) Header Block Fragment真正的内容 Padding填充字节也就是说Pad Length 永远是载荷的第一个字节优先级那 5 字节紧随其后最后才是真正的 header block 和填充尾巴。当年我自己写解析器的时候先把 priority 放在 Pad Length 前面解析结果一切正常的数据在带 PADDED 的帧上全部错位排查了很久才发现是顺序问题。如果你用 hyperframe这个顺序它内部已经处理好了但如果你要对着 Wireshark 核对字节、或者自己写一个极简解析器这个布局必须烂熟于心。DATA 帧的 PADDED 逻辑要简单一点载荷第一个字节是 Pad Length后面是数据最后是填充字节没有优先级那 5 字节的干扰。5.2 stream 0 被滥用协议错误藏在细节里再说一遍因为真的太多人犯DATA、HEADERS、PRIORITY、RST_STREAM、PUSH_PROMISE、CONTINUATION 这些帧出现在 stream 0 上直接判 PROTOCOL_ERROR。stream 0 是连接级的专属通道只给 SETTINGS、PING、GOAWAY 和连接级 WINDOW_UPDATE 用。另外流 ID 的奇偶也有讲究客户端发起的流必须是奇数服务端发起的流必须是偶数这是协议约定。拿 hyperframe 构造帧时它不会校验这个但你把一个 stream_id2 的 HEADERS 发给服务端服务端大概率直接 RST_STREAM 甚至 GOAWAY。所以自测的时候stream id 的合法性一定要自己把关库不帮你拦的坑最终都会在线上等你。5.3 流控窗口是发多少字节扣多少不是发多少帧HTTP/2 的流控是窗口式的连接级窗口和每个流的窗口初始都是 65535除非对端通过 SETTINGS_INITIAL_WINDOW_SIZE 改了。你每发一个 DATA 帧窗口就扣掉这个帧的字节数注意这里扣的是受控字节数——数据长度 填充长度 那 1 字节 Pad Length 都要算进去。hyperframe 的 DataFrame 有个flow_controlled_length属性就是帮你算这个的用它对账比手算稳得多。对端要靠 WINDOW_UPDATE 帧给你回血每个 WINDOW_UPDATE 的增量不能是 0而且窗口总额不能超过 2^31 - 1否则都是 FLOW_CONTROL_ERROR。我踩过的具体场景是这样测试环境调大了 SETTINGS_INITIAL_WINDOW_SIZE 到 1MB结果有个老服务端没同步这个配置我在本地一口气发了 20 万字节的数据对方直接 RST_STREAM 把流掐了。所以记住改流控参数必须两端协商一致而且窗口恢复依赖对端的 WINDOW_UPDATE这不是你单方面能决定的。流控调度那一整套逻辑属于 h2 这种完整协议栈的职责hyperframe 只负责帮你把 WINDOW_UPDATE 帧正确序列化出去。5.4 帧长度上限16384 是默认值不是协议上限这里有三层数字我每次讲都要强调一遍Length 字段是 24 位理论最大值 16777215协议默认的帧大小上限是 16384通过 SETTINGS_MAX_FRAME_SIZE 可以把单帧上限调高但不能超过 16777215。很多人把 16384 当成协议写死的天花板这不对它只是默认值。调高上限本身没问题但必须确保两端都通过 SETTINGS 协商过你在 SETTINGS 里发了 MAX_FRAME_SIZE1048576对端也回了一个确认你才能发超过 16384 的大帧。否则按默认上限超长帧会被对端以 FRAME_SIZE_ERROR 直接断连。我见过一个团队把上限调大以后忘了在接收侧同步结果生产环境间歇性连接被重置查了很久。5.5 SETTINGS ACK 与未知帧类型的处理哲学SETTINGS 有个对称性要求一方发出 SETTINGS另一方必须回一个 ACK 的 SETTINGS 帧不回或者回得慢对端可能会以 SETTINGS_TIMEOUT 断连。所以在写客户端握手逻辑时收到对端 SETTINGS 后的第一反应永远是回 ACK没有例外。另一个容易别扭的地方是未知帧类型协议要求忽略但 hyperframe 默认非严格模式会返回 ExtensionFrame严格模式直接抛异常。如果你在实现服务端面对未知类型应该跳过、保持连接存活把 strictTrue 用在测试工具里才能第一时间发现流量里有非预期帧。一个库的严格性和协议的宽容性在这个点上打架你要根据使用场景选边站。5.6 hyperframe 不碰 HPACK头部压缩上下文是连接级的这是新手最容易撞的墙自己手拼了一个 HEADERS 帧塞的却是明文头部字节发给服务端以后收到 COMPRESSION_ERROR整个人懵掉。原因很简单HTTP/2 里所有 HEADERS 帧的载荷都默认是 HPACK 压缩块连接一建立双方就进入同一个 HPACK 上下文。你塞明文进去对端用压缩解码器去读根本读不通。所以正确做法是header block 必须用 hpack 的 Encoder 生成并且同一个连接上的所有 HEADERS 都用同一个 encoder 实例因为动态表的索引状态是跨帧连续的。hyperframe 在这个链条里只负责把编码后的字节放进帧并序列化压缩和解压完全在它外面。你越早接受这条职责边界越少受苦。6. 用 Wireshark 和 tshark 对照验证你的帧解析写完了组装和解析的逻辑怎么证明它是对的我自己的验证方法始终是同一套抓真实流量导出字节交给 Python 解析再跟 Wireshark 的解码结果逐帧比对。这个方法我用了好几年比任何单元测试都更能暴露问题因为真实流量里的标志位组合千奇百怪你写测试用例根本构造不出那么全的场景。6.1 抓一份真实的 HTTP/2 流量先用curl -V确认你的 curl 带了 HTTP2 特性输出里要有 nghttp2。然后对一个支持 HTTP/2 的公开站点发起请求curl --http2 -v https://nghttp2.org -o /dev/null用 Wireshark 在默认网卡抓包就能看到 HTTP/2 帧。如果流量走 TLS443 端口基本都是你只会在 TCP 层看到 TLS record这时候需要给 Wireshark 喂会话密钥才能解开里面的 HTTP/2 帧。方法是在发起请求前设置环境变量export SSLKEYLOGFILE/tmp/h2keys.log curl --http2 -v https://nghttp2.org -o /dev/null然后到 Wireshark 的 Preferences → Protocols → TLS 里把 (Pre)-Master-Secret log filename 指向/tmp/h2keys.log重新打开抓包文件就能看到明文帧了。正规的做法是只解密自己的流量用 SSLKEYLOGFILE 调自己的服务和客户端这是日常排查手段不是啥黑科技。6.2 过滤、定位、取字节抓包里最常见的帧就是 SETTINGS 和 WINDOW_UPDATE。Wireshark 的 HTTP/2 显示过滤器很直观http2只看所有 HTTP/2 帧http2.type 4只看 SETTINGS 帧http2.flags 0x1只看带 ACK 的帧。点开任意一条 SETTINGS 帧Wireshark 会帮你把 Length、Type、Flags、Stream ID、以及每个参数项都解析得明明白白。这时候右键这条记录选择复制 → 把它导成 Hex Stream或者直接用 Wireshark 的 Export Packet Bytes 存成文件这段字节就是你可以喂给 Python 的原始帧数据。tshark 命令行版本也很有用尤其适合批量导出tshark -r h2.pcapng -Y http2.type 4 -T fields -e frame.number这条命令会列出所有 SETTINGS 帧对应的包序号方便你在图形界面里快速跳转定位。6.3 一个朴素但对账有效的脚本拿到一段 Hex Stream 后存成一个文本文件跑下面这个几十行的小脚本import sys from hyperframe.frame import Frame, SettingsFrame hexdata open(sys.argv[1]).read().strip().replace( , ).replace(\n, ) frames, consumed Frame.parse_frames(bytes.fromhex(hexdata)) for frame in frames: print(type(frame).__name__, stream, frame.stream_id, flags, hex(frame.flags)) if isinstance(frame, SettingsFrame): print( settings:, frame.settings)把打印结果跟 Wireshark 同一帧的解析栏逐项对类型对不对、stream id 对不对、flags 对不对、SETTINGS 摘出来的参数值对不对。我自己的经验是一次抓包能对上九成以上你的解析器就已经可以拿出去见人了剩下的那一成往往就是某个带 PADDED 或 PRIORITY 组合的罕见帧而这恰恰是 5.1 节说的字节顺序问题最容易藏身的地方。所以我在每次改造解析代码后都会固定做一轮这样的回归把 tshark 导出的不同类型帧各挑几条喂一遍。真实流量的多样性是任何测试框架都给不了你的。回头看hyperframe 整个库的核心源码其实只有几百行通读一遍 frame.py 比看十篇文档都值。如果让我给一条学习路径那就是先把 RFC 9113 的 4.1 节和六个帧类型的定义打印出来再对照 hyperframe 源码读一遍最后用 Wireshark 里的真实帧验证。这套组合拳打完HTTP/2 的帧层你基本就吃透了。要是想再进一步可以去翻 h2 是怎么把这一帧一帧组织成流状态机的那又是另一层很有意思的风景——不过那就是下一篇的事了。