编者按/ 本文来自老朋友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和各位作者！
详情请扫描图中二维码或点击阅读原文了解大会更多信息。
继续阅读
阅读原文
关键词
服务器
技术
流媒体
架构
RTMP协议