编者按 / 本文来自老朋友 Fabio Sonnati，他回顾了陪伴其生涯的 Flash 和 RTMP 技术，感谢刘歧对本文的审校，并给出很多补充信息。

翻译 /  核子可乐

技术审校 / 刘歧

原文链接：https://sonnati.wordpress.com/2022/12/22/fcs-and-rtmp-streaming-technologies-from-the-future/

特别说明：Fabio Sonnati 已授权 LiveVideoStack 对本文翻译与发布，特此感谢。

我还清楚地记得，自己当初刚刚接触流媒体和实时通信技术时感受到的热情与兴奋。我热爱视频压缩与交互式 Web，也积极与 Flash 社区合作、探索交互体验的设计思路。但在 Macromedia 发布 Flash Communication Server 1.0 (审校者注：下文称 FCS) 时，我的职业生涯才真正迎来了转机。那是 2002 年 9 月，谁能想到 20 年后的今天，作为其中底层技术之一的 RTMP 协议仍然陪伴在我们左右。

在 Flash 之父 Jonathan Gay 的帮助下，Pritham Shetty 牵头缔造了流媒体历史上的这座不朽丰碑。Pritham 在网络实时通信方面拥有海量的专业知识储备，早在 1996 年就曾为 NTT 开发一套基于 Java 的 Web 客户端，用于连接多名用户以实现体验同步。而同样由他于 1996 年开发的个性化服务器，甚至被很久之后才诞生的 Netflix 公司所使用。

FCS 是一款出色的服务器，能够在 Flash Player 6.0 中实现实时通信、视频流直播与点播等功能。FCS 的架构确实超前于其所处的时代，我当初用上它的时候匹配的还是下行速率 640 Kbps / 上行速率 128 Kbps 的 ADSL 宽带，外加 64 Kbps GPRS 手机。尽管堪称互联网的 “远古” 时期，那时候的 FCS 就已经能通过孱弱的网络连接与其他用户开展实时通信，也为支撑未来的交互式应用程序做好了准备。

众所周知，又过了 18 年，全世界受到新冠疫情的冲击，人们开始高度依赖于 Microsoft Teams、Google Meet 和 Zoom 等实时通信技术。如果把 FMS（审校者注：FCS 后来的版本名称为 FlaSh Media Server，再后来又更名为 Adobe Media Server）视为一片实验场，那 Flash 开发人员无疑可以在其中轻松开发出类似的视频会议类应用。Flash 能在浏览器内生成多条音频 - 视频数据流，通过 RTMP 协议进行传输，并由 FMS 在服务器端编排以供 Flash 客户端播放。

我觉得这套堆栈的最大优点就是简单而优雅。作为一名媒体解决方案架构师，我的整个职业生涯都受到了 FCS 这些亮点的启发。以 FCS 为基础，还出现了用 Action Script 1.0（本质上就是 JavaScript，审校者注：AS 与 JS 略有一些差别，不过都参考的 ECMAScript 标准）编写的脚本式非阻塞 I/O 堆栈。每次用户连接、应用程序启动、连接断开和常规交互都会触发一个事件，代码则通过活动或异步 I/O 操作做出响应，借此将发布模式下的 RTMP 流接入订阅模式下的 RTMP 流，再配合脚本编排进其他交互和数据共享（奇怪的是，该架构跟 Node.js 其实非常相近。在 Flash 最终被淘汰时，我还是可以用早期 Node 和 FFmpeg 来替代过往使用的各种 FCS 服务用例）。

RTMP 的这种简单性和高效性，也是它至今仍得到广泛青睐的主要原因。RTMP 能够在 TCP、SSL 或 HTTP (S)（审校者注：分别是 RTMP、RTMPE、RTMPS）中交替传输音频、视频与数据标签，并以透明方式实现对直播和点播用例的近实时（延迟仅为几毫秒）传输。在此期间还可向传输流中插入 RPC 调用，并轻松以可记录方式实现通信会话的交互式重播。

这时虽然距离 WebRTC 被构思出来还有十年，但当时的这套堆栈已经能为开发者带来无穷的可能性。最终，我成了 FCS（当时也被称为 Flash Media Server/Adobe Media Server）技术专家，在接下来 10 年中开发了不少高级应用程序（例如凭借 Flash + FCS 这对强强组合的出色灵活性，我得以在 2008 年开发出意大利第一套采用自适应比特率流媒体的电视节目回看方案。）。

遗憾的是，由于 Adobe 定下了荒谬且限制过多的定价模型，FCS/FMS/AMS 最终并没能取得应有的成功和广泛普及。尽管如此，它还是对互联网流媒体做出了不可磨灭的贡献。

总之，RTMP 二十岁生日快乐！也感谢伟大的 FCS 和各位作者！