翻譯：Alex

技術審校：章琦

本文來自 OTTVerse，作者為 Krishna Rao Vijayanagar。

▲掃描圖中二維碼了解音視頻技術大會更多信息▲

Easy-Tech #028#

什么是 RTMP？

RTMP（Real-Time Messaging Protocol，實時消息傳輸協議）是一種用于低延遲、實時音視頻和數據傳輸的雙向互聯網通信協議，由 Macromedia（后被 Adobe 收購）開發。RTMP 的工作原理是：通過建立和維護 RTMP 客戶端和 RTMP 服務端之間的通信路徑來實現快速、可靠的數據傳輸。

RTMP 最初用于 Adobe Flash Player 的媒體傳輸，但是眾所周知，Flash 在 2020 年 12 月已被棄用。這意味著 RTMP 也會隨之消亡并塵封嗎？當然不！

在現代視頻傳輸場景中，RTMP 依然占據一席之地，尤其在與轉碼器協同工作方面，這得益與 RTMP 所具有的低延遲和實時傳輸屬性。

大部分具備行業標準的編碼器（如 encoding.com、Bitmovin、Harmonic 和 AWS Elemental 等）都能夠生產 RTMP 數據源。同樣，Twitch、YouTube、Facebook Live 等流媒體服務和 Dacast、Ant Media、Wowza 等直播平臺都能接收 RTMP 推流。

本篇文章將深入了解：

RTMP 的歷史

RTMP 的工作原理

如何建立 RTMP 連接

RTMP 的替代方案

RTMP 的優點和缺點

事不宜遲，讓我們先來了解 RTMP 協議的歷史。

RTMP 的歷史

RTMP 由 Adobe 推出，用于超級流行的 Adobe Flash 播放器中，數百萬網站曾使用這款播放器向用戶展示視頻。在鼎盛時期，大約超過 90~95% 有視頻內容的網站上都使用 Adobe Flash 播放器來播放視頻。

Adobe 對 RTMP 的定義如下：

RTMP （實時信息傳輸協議）用于在 Adobe Flash 平臺技術（包括 Adobe Flash 播放器和 Adobe AIR）間實現音頻、視頻和數據的高性能傳輸。現在，作為一種開放規范，RTMP 可用于創建實現與 Adobe Flash 播放器兼容的 AMF、SWF、FLV 和 F4V 等開放格式的音頻、視頻和數據傳輸的產品和技術。——Adobe

然而，隨著 Flash 的棄用，RTMP 不再用于向 Adobe Flash 播放器傳輸視頻，同時還要面臨與基于 HTTP 的視頻傳輸協議 MPEG-DASH 和 HLS 的競爭。但是，RTMP 仍然在向編碼器傳輸視頻的過程中發揮著重要作用，我們在下文將會講到。

RTMP 的工作原理

正如我們在上文中所了解到的，RTMP 是一種基于 TCP 的、用于數據、音頻和視頻傳輸的雙向通信協議。

RTMP 的工作原理是：通過建立和維護 RTMP 客戶端和 RTMP 服務端之間的通信路徑來實現快速、可靠的數據傳輸。

與基于 HTTP 的傳輸協議 HLS 和 DASH 的操作相似，RTMP 也是將多媒體流分割成切片：通常情況下，音頻為 64 字節，視頻為 128 字節。切片的大小可以由客戶端和服務端之間協商獲得。

傳統觀點認為切片尺寸不應太大，也不應太小。較大的切片在寫入操作中引起延遲，而太小的切片則會增加 CPU 的負載。

圖片來源: Wikipedia

通過將視頻流分割成切片，RTMP 可以將來自不同視頻流的切片交織在一起，并在單個連接上傳輸，這種方法被稱為 “多路復用”，與視頻直播中的統計多路復用類似。不過在實際中，包含幾個切片的數據包被交織在一起后，使得 RTMP 傳輸更加高效，并允許 RTMP 創建多個虛擬、可尋址的視頻傳輸通道。在解碼端，這些交織的數據包可以被解復用，從而獲取到最初的音頻和視頻數據。

RTMP 連接設置：握手、連接、推拉流

現在，讓我們一起來了解 RTMP 連接是如何建立的，從而幫助我們更好地理解 RTMP 協議的工作原理。RTMP 建立連接可分為三步：握手、連接和推拉流。

讓我們分別看下這三個步驟。

第一步：握手

RTMP 中的握手過程相對簡單，在建立 TCP 連接后進行。在此握手過程中，每一方（客戶端和服務端）發送三個數據包，分別為 C0、C1、C2 （客戶端）和 S0、S1 、S2（服務端）。

下面是對 RTMP 握手過程的解釋：

客戶端向服務器發送 C0 數據包，數據包中包含客戶端請求的 RTMP 版本。

然后客戶端在沒有等到服務器表示已接收到 C0 的情況下，發送包含了 1536 字節隨機數據的 C1。

此時，服務器必須等到它收到 C0 才能響應 S0 和 S1（可選）。在這個階段，服務器知道客戶端所請求的 RTMP 版本。服務器響應 S0 和 S1—— 它們本質上是 C0 和 C1 的副本。

然后客戶端和服務器交換 C2 和 S2，之后握手完成，連接建立。

圖片來源: Wikipedia

第二步：連接

連接步驟發生在 RTMP 客戶端和 RTMP 服務端之間的握手之后。在連接過程中，客戶端和服務器使用 AMF 編碼交換編碼過的信息。

AMF 代表 Action Message Format，用于在 Adobe Flash 客戶端和 Flash 媒體服務器之間發送信息。或者，程序員可以使用 AFM 序列化 ActionScript 和 XML 的對象圖。AMF 在 RTMP 流傳輸中用于客戶端和服務器之間的通信，表明信息類型和內容。更多關于 AMF 的信息，可以在這里閱讀：https://en.wikipedia.org/wiki/Action_Message_Format 。

下面的示例顯示了由客戶端向 RTMP 服務器發出的信息。其中使用了連接 URL、音頻編解碼器、視頻編解碼器和所使用的 AMF 版本號。在此示例中，AMF 的版本為 3.0。

(Invoke) "connect" (Transaction ID) 1.0 (Object1) { app: "sample", flashVer: "MAC 10,2,153,2", swfUrl: null, tcUrl: "rtmpt://127.0.0.1/sample ", fpad: false, capabilities: 9947.75 , audioCodecs: 3191, videoCodecs: 252, videoFunction: 1 , pageUrl: null, objectEncoding: 3.0 }

RTMP 服務器的響應信息：

(Invoke) "_result" (transaction ID) 1.0 (Object1) { fmsVer: "FMS/3,5,5,2004", capabilities: 31.0, mode: 1.0 } (Object2) { level: "status", code: "NetConnection.Connect.Success", description: "Connection succeeded", data: (array) { version: "3,5,5,2004" }, clientId: 1728724019, objectEncoding: 3.0 }

在這一步中，客戶端和服務器還會交換 Set Peer Bandwidth 和 Window Acknowledgement Size 協議信息。當成功執行，這些信息會表示連接的建立，然后服務器就可以傳輸視頻數據了。音視頻編解碼器和其他參數的詳細定義，請參考 RTMP 規范: https://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf 。

第三步：推拉流

在 RTMP 握手和連接步驟后，RTMP 客戶端和 RTMP 服務器之間的連接已經建立，現在就可以傳送數據了。為了實現數據的傳輸，RTMP 規范定義了下面幾個命令：

createStream

play

play2

deleteStream

closeStream

receiveAudio

receiveVideo

publish

seek

pause

在這些命令的幫助下，才有可能使用 RTMP 協議傳輸視頻。

現在你對 RTMP 連接的工作原理已經有了基本的理解，接下來讓我們了解一些常用的 RTMP 變體。

RTMP 的變體：RTMPS、RTMPT、RTMFP、RTMPE、RTMP Proper

在這一部分，我們將簡單介紹用于特定目的的 RTMP 變體，讓我們從 RTMPS 開始。

RTMPS： RTMPS 只是基于 TLS/SSL 連接的 RTMP。與 RTMPE 相比，設置和使用 RTMPS 要復雜一些，但是能夠確保一定程度的安全性。如果你計劃使用 RTMP 將視頻傳輸到 Facebook Live，你需要使用 RTMPS（來源：https://developers.facebook.com/blog/post/2019/04/16/live-video-uploads-rtmps/ ）。

RTMPE： RTMPE 使用了包含 Diffie–Hellman key exchange 和 HMACSHA256 的行業標準加密。它生成了一對 RC4 密鑰，其中：

第一個密鑰用于加密從服務器向客戶端發出的媒體數據。

第二個密鑰用于加密向服務器發送的數據。

RTMP Proper: 是指使用 1935 端口、基于 TCP 的 RTMP 的別名。

RTMPT： RTMPT 建立在 HTTP 協議之上，是通過 HTTP 封裝后的 RTMP 協議。它允許 RTMP 信息穿過防火墻，封裝的信息可以是 RTMP Proper、RTMPS 或 RTMPE 數據包。

RTMFP: RTMPF 基于 UDP 協議（而非 TCP），而且沒有使用 RTMP Chunk Stream。RTMFP 設計用于直接在 P2P 之間進行低延遲、實時的音頻和視頻通信，而無需通過 RTMP 服務器。更多關于 RTMFP 的詳細信息，請閱讀： https://www.adobe.com/in/products/adobe-media-server-extended/rtmfp-faq.html 。

RTMP 中音頻和視頻的編解碼器支持

在繼續學習前，讓我們一起來看下 RTMP 中的編解碼器支持。頭部文件說明了對于下列編解碼器的支持：

音頻：AAC、MP3

視頻：H.264/AVC、FLV 容器中的 VP6

哪里支持 RTMP？

一些商業和開源編碼器以及流媒體引擎支持 RTMP，無論是拉流，或生成 RTMP 數據源（推流）。你可以使用：

OBS Studio, 免費的廣播和直播軟件，可以生成 RTMP 數據源

FFmpeg

Dacast.com

Bitmovin.com

Ant Media Server

Wowza

等其他更多的 RTMP 推拉流的解決方案。

RTMP 推流替代方案

由于 Adobe 結束了對于 Flash 的支持，RTMP 現在所面臨的是不太確定的未來。對于推流而言，你還可以考慮其他替代方案。

HLS 是可以替代 RTMP 的流行方案。HLS 是流媒體行業中的公認標準，從編碼器、打包器、加密（DRM）、CDN 到設備上的播放，它獲得了來自視頻生態的廣泛支持。

另一個選擇是 MPEG-DASH，它也是基于 HTTP 的視頻傳輸協議。和 HLS 一樣，DASH 也獲得了廣泛支持，也可以看作 RTMP 的替代方案。

基于 HTTP 的協議會存在一個問題，那就是它們會增加系統時延。通常情況下，在 HLS 和 DASH 中，必須先生成一定數量的視頻切片，才能創建 DASH 清單或者 HLS 播放列表。沒有播放列表或者清單，播放器便無法理解生成的視頻流。等待播放列表或者清單的過程增加了時延，通常情況下會對系統造成 45 秒～1 分鐘的延遲。

不過，人們正在開發低延遲的 DASH 和 HLS 協議，它們能夠減少基于 HTTP 的流媒體時延，并能夠緩解基于 HTTP 的流媒體協議所帶來的問題。

結語

我希望這篇關于 RTMP 的介紹性文章能對你有所幫助，在未來的文章中，我們將研究 RTSP、RTMP 和 RTSP 之間的區別，以及如何使用 OBS Studio 等流行工具來實現 RTMP 推拉流。

我們下次再見，保重，請繼續 Streaming！

致謝：

本文已獲得作者 Krishna Rao Vijayanagar 授權翻譯和發布，特此感謝。

原文鏈接：

https://ottverse.com/rtmp-real-time-messaging-protocol-encoding-streaming/

延伸閱讀：

Easy Tech：什么是 MPEG-DASH 協議

什么是 HLS（HTTP Live Streaming）?