7.6 实战：推流抓包与低延迟拉流（practice_8）
理论版图已经拼齐：容器三杰、RTP 价值观、RTMP 四层叠构、HLS 文件哲学、现代协议群像。本节把它们全部按进真实流量里检验——实验一 推一路 RTMP 流，逐字节拆解抓包；实验二 拉起一条 HLS 流，量一量 LL-HLS 的延迟成色。前文每一处 "实测锚点"，都出自这两个实验。
任务定义与环境
实验环境全部本地闭环：MediaMTX 开源流媒体服务器充当 RTMP/HLS 服务端，ffmpeg 把标准测试序列 foreman_cif.y4m 推成直播流。两组实验的分工：
- 实验一（RTMP 抓包分析）：在推流路径上架本地代理，把客户端与服务器双向的原始字节完整落盘（
rtmp_c2s.bin145,679 字节、rtmp_s2c.bin3,467 字节），再用教学脚本逐层解析——对照 7.3 全节的规则，一条消息一条消息地认领 - 实验二（HLS 拉流量测）：同一服务器输出 HLS，用轮询脚本记录媒体列表的更新节奏，抓取分片与 part 样本做字节级解析——验证 7.4 的标签语义与延迟账本
工程实现
教学脚本 practice_8_rtmp_analyzer.py 为纯 Python 实现、零第三方依赖，解析路径与 7.3 的知识分层一一对应：
一行命令即可复现全部分析：python3 practice_8_rtmp_analyzer.py parse。它不只是本次实验的工具，更是一份可运行的 7.3 节伪代码——读完脚本再读规范，字里行间的字段会自己站起来。
实验一：握手与会话的逐字节还原
先看握手阶段的还原输出：
handshake: C0 version=3 (expect 3)
C1 time=0 zero=09007c02 random=1528B
handshake: S0 version=3 (expect 3)
S1 time=0 zero=00000000 random=1528B
这里藏着一颗彩蛋：7.3.2 引用规范说 C1 的 zero 字段 MUST 全为 0，可 ffmpeg 发来的实测值是 09007c02——规范的红线，实现并不紧张；服务器（MediaMTX）的 S1 倒是规规矩矩全零。服务器宽容接纳、握手照常完成，这是 7.3.1 "文本只是下限，实现才是现实" 的又一例证：读抓包时见到 "违规" 字段先别慌，先分清是规范约束还是实现惯例。
握手完成后的会话时序，7.3.5 的图 7-7 已做过全景对照，此处补上字节级账本里的三组数字：
其一，双向的不对称。 客户端→服务器共解析出 422 条消息（媒体数据为主），服务器→客户端仅 6 条（三条协议控制 + 两条 _result + 一条 onStatus）。推流场景的不对称一目了然：控制信道三言两语，媒体信道滔滔不绝。
其二，信道分配的教科书范本。 抓包里的 cs/ms 编号与 7.3 的规则严丝合缝：
| 信道 | 角色 | 实测内容 |
|---|---|---|
| cs=2, ms=0 | 协议控制 | Window Ack 2.5M、Set Peer Bandwidth（Dynamic）、Set Chunk Size 65536 |
| cs=3, ms=0 | 连接层命令 | connect、releaseStream、FCPublish、createStream 及 _result |
| cs=8, ms=1 | 流命令 | publish（stream='live'） |
| cs=5, ms=1 | 状态应答 | onStatus（NetStream.Publish.Start） |
| cs=4, ms=1 | 音频 | AAC seq-header 7B 先行，随后 raw 帧约 23ms 一条 |
| cs=6, ms=1 | 视频 | AVC seq-header 50B 先行，随后 NALU 帧每 40ms 一条（25 fps） |
其三，媒体节奏与码率波动。 音频 23ms、视频 40ms 的双节拍，与 25 fps、AAC 帧长的理论值分毫不差；"先送配置、再流数据" 的两段式开场后，关键帧 NALU 一口气 4,033 字节，后续帧间帧稳定在 460~660 字节区间——VBR 码流的波峰波谷，在消息粒度上纤毫毕现。另外，双方向各自把 Chunk Size 协商到 65536，7.3.3 说过的 "推流方向调大切片" 在此坐实。
实验二：LL-HLS 拉流量测
实验二开局就有一份意外之喜：MediaMTX 默认输出的 HLS 已是 LL-HLS + fMP4 全家桶（EXT-X-VERSION:10），本章 7.4 的全部新标签一次性集齐。两级列表的内容已在 7.4.2 逐行认领，part 与整片的字节级对照也在 7.4.5 拆过，这里补上是量测视角的三笔账。
轮询账。 媒体列表以约 2 秒的节拍滚动：media_sequence 实测从 1 递增至 4，窗口稳定保持 7 个整片；每个整片由 8 个 240ms 的 part 组成，PRELOAD-HINT 始终指向尚未出生的下一个 part——7.4.5 的机制描述，在列表的一次次刷新里全部兑现。
延迟账。 整片粒度 2 秒，按 7.4.5 的三重构成，传统玩法下这条流的延迟下界在 4~6 秒；而 part 粒度 240ms 加 PART-HOLD-BACK=0.6s，下界被压进亚秒量级。需要诚实说明边界：本实验在 localhost 闭环（拉取 TTFB 不足 1ms），量到的是 机制决定的延迟下界，公网环境的真实延迟还需叠加传输与 CDN 因素。
码率账。 抓得整片样本 14,527 字节、EXTINF 2.0 秒，折算分片码率约 58 kbps；主索引声明的 BANDWIDTH=56,675（约 56.7 kbps 峰值）与之同量级自洽——7.4.4 的峰值口径，用真实数据走了一遍验算。
动手延伸
想让 Chunk 切片的手感再长一层肌肉记忆，本章【在线展示】的 RTMP Chunk 切片模拟器 随时待命：调整消息长度与 Chunk Size，观察 fmt 选择与头部开销的变化，再回到这份抓包对照，字段会越发亲切。
小结
两个实验，一枚印章：7.3 的四层叠构在 422 条消息里逐条应验，7.4 的 LL-HLS 机制在轮询日志里分秒不差，连规范与实现的缝隙（非零的 zero 字段）都被抓包照了个正着。协议学到这个份上，才算是既读得懂文本、也认得出字节。下一节，第七章小结，并为第八章的系统实战搭好过桥。