7.3.1 Flash 时代的直播王朝（The Flash-Era Live Dynasty）

天平的另一极：抱住 TCP 不放

7.2.4 的结尾留下了一个悬念：如果观众要的不是 "实时互动"，而是 "稳定地看完一场直播"，协议该怎么选？RTMP 给出的答案干脆利落——走 TCP，默认端口 1935，一个字节都不许丢 [1]。

这笔账算得很精明。直播场景里，主播与观众天然隔着几秒到几十秒的缓冲距离，观众根本不差那两三秒；可一旦丢包，解码器面对的是花屏、卡顿甚至整条流的中断——这才是直播事故。TCP 的重传与排序恰好把 "不丢、不乱" 包办了，代价是队头阻塞带来的延迟累积。RTMP 把赌注全押在可靠性一侧，与 RTP 构成了天平的两极：一个用补偿机制换时效，一个用缓冲深度换安稳。

从 Macromedia 到 Adobe：一段被收购改写的出身

RTMP 的出身带着浓厚的产品色彩。它并非标准组织会议室里的产物，而是 Macromedia 为自家产品线量身打造的私有协议：一端是装在几乎每一台浏览器里的 Flash Player（Adobe 当年宣称其装机率超过九成），另一端是服务端的 Flash Media Server（FMS），RTMP 就是两者之间传输音视频、数据与远程调用的那根管道 [1]。

2005 年 12 月，Adobe 完成对 Macromedia 的收购，Flash 全家桶连同 RTMP 一起改姓 Adobe。这次收购改变了协议的归属，却没有改变它的定位：RTMP 始终服务于 Flash 生态，协议规范的文本长期握在厂商手里。围绕这条私有管道，整个直播行业长出了完整的产业链——编码器、流媒体服务器、CDN、播放器——彼时想在网页里看直播，几乎绕不开 Flash 与 RTMP 这对组合。

先成事实标准，后有规范文本

私有协议统治行业，总会引来逆向工程的冲撞。开源社区对 RTMP 的抓包分析持续多年，2009 年双方矛盾公开化之后，Adobe 放开了协议规范的访问，并于 2012 年 12 月整理发布了本书所引的 v1.0 版本 [1]。

这个时间点颇值得玩味：规范文本落定时，协议的统治期已经过半。RTMP 走的是一条 "先成为事实标准，后拥有规范文本" 的路——行业早已按抓包与实现惯例运转多年，规范更多是事后追认。这个出身在协议身上留下了抹不掉的印记，后文会反复遇见：某些命令（如 releaseStream、onFCPublish）压根没写进规范，却是每家服务器都实现的 "行规"；规范里某些字段的语义含糊之处，也只能靠实现惯例补齐。读 RTMP 的规范，需要时刻带着 "文本只是下限，实现才是现实" 的清醒。

Flash 退场之后：推流端的长尾

王朝终有落幕时。随着浏览器集体转向 HTML5，Adobe 于 2020 年底终止 Flash Player 的分发与支持，播放端的 RTMP 随之退场——今天的浏览器拉流，主力已是 7.4 节要讲的 HLS、HTTP-FLV 这些基于 HTTP 的方案。

可协议的另一端活得好好的。推流侧（主播端 → 服务器的第一公里），RTMP 至今仍是事实标准：打开 OBS 或任意一台硬件编码器，输出协议列表里 RTMP 永远排在最前。原因并不神秘——推流是 "一点对一点" 的上行传输，TCP 的队头阻塞影响有限，而 RTMP 生态里服务器、CDN 边缘节点的存量部署庞大到没人愿意先动。行业于是形成了心照不宣的分工：上行 RTMP，下行 HTTP，直播平台的边缘节点把进站的 RTMP 流转封装成 HLS/HTTP-FLV 分发出去。

老树也在发新芽。针对 FLV 时代 CodecID 只有 4 bit、装不下 HEVC/AV1 的天花板（7.1.3 的伏笔），开源社区推动的 enhanced-RTMP 规范用扩展字段为 RTMP 接上了新一代编码器 [6]——这个续命手术，我们到 7.5 节回顾协议编年史时再细看。

小结：传奇从三个数据块开始

回看 RTMP 的身世：生于产品、长于生态、规范迟到、播放端谢幕、推流端长尾——它的每一页都写着工程现实对协议设计的塑造。但无论如何评价它的历史地位，想读懂线上流动的 RTMP 字节，都得从会话的第一步开始：客户端与服务器见面时交换的那三个 1536 字节数据块。下一节，我们拆解这套不太像握手的握手。