7.3 直播时代的霸主：RTMP（RTMP & The Live Streaming Dynasty）
7.2 节的天平停在了最激进的一极：RTP 为了毫秒级互动，宁可丢包也不重传。本节要讲的是另一个极端的选择——抱住 TCP 的可靠性不放，用几秒延迟换一路安稳。做出这个选择的 RTMP（Real-Time Messaging Protocol），在直播行业的王座上坐了整整十年，至今仍是推流端的事实标准 [1]。
RTMP 的特别之处，在于它把第七章前半段的两大主角拧在了一起：线上跑的媒体数据，几乎就是 7.1.3 讲过的 FLV 标签序列——同一种编码、同一套标签，只是从文件搬进了 TCP 长连接。读懂 RTMP，等于同时复习了容器与传输两侧的知识。
本节按 "背景 → 握手 → 封包 → 消息 → 时序" 的顺序递进：
- 7.3.1 Flash 时代的直播王朝：TCP 稳定取向的取舍逻辑；从私有协议到公开规范的曲折身世；Flash 退场后推流端的长尾
- 7.3.2 握手：C0/C1/C2 与 S0/S1/S2：三个 1536 字节块的交换流程；版本协商与状态机；这套 "不像握手的握手" 背后的工程考量
- 7.3.3 Chunk 封包：一次消息，多次封装：Basic Header 的三种形态、Message Header 的四型压缩、Chunk Size 的流控意义——多路复用在字节层面的实现
- 7.3.4 Message 类型族与 AMF 编码：音视频、数据、命令、共享对象、整合消息的类型编号；AMF0/AMF3 的自描述编码与字节序陷阱
- 7.3.5 命令消息与流管理时序：connect/createStream/play/publish 的完整会话流程；NetConnection 与 NetStream 的双层信道模型
完成本节后，我们将手握直播时代最经典的一套协议全景：它不仅解释了 OBS 推流按钮背后的字节流，也为 7.4 节 "直播为什么要搬家到 HTTP" 埋下了对照组。