編者按 / 本文來自老朋友 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 和各位作者！