翻譯：Alex

技術(shù)審校：章琦

本文來(lái)自 OTTVerse，作者為 Krishna Rao Vijayanagar。

▲掃描圖中二維碼了解音視頻技術(shù)大會(huì)更多信息▲

Easy-Tech #028#

什么是 RTMP？

RTMP（Real-Time Messaging Protocol，實(shí)時(shí)消息傳輸協(xié)議）是一種用于低延遲、實(shí)時(shí)音視頻和數(shù)據(jù)傳輸?shù)碾p向互聯(lián)網(wǎng)通信協(xié)議，由 Macromedia（后被 Adobe 收購(gòu)）開(kāi)發(fā)。RTMP 的工作原理是：通過(guò)建立和維護(hù) RTMP 客戶端和 RTMP 服務(wù)端之間的通信路徑來(lái)實(shí)現(xiàn)快速、可靠的數(shù)據(jù)傳輸。

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

在現(xiàn)代視頻傳輸場(chǎng)景中，RTMP 依然占據(jù)一席之地，尤其在與轉(zhuǎn)碼器協(xié)同工作方面，這得益與 RTMP 所具有的低延遲和實(shí)時(shí)傳輸屬性。

大部分具備行業(yè)標(biāo)準(zhǔn)的編碼器（如 encoding.com、Bitmovin、Harmonic 和 AWS Elemental 等）都能夠生產(chǎn) RTMP 數(shù)據(jù)源。同樣，Twitch、YouTube、Facebook Live 等流媒體服務(wù)和 Dacast、Ant Media、Wowza 等直播平臺(tái)都能接收 RTMP 推流。

本篇文章將深入了解：

RTMP 的歷史

RTMP 的工作原理

如何建立 RTMP 連接

RTMP 的替代方案

RTMP 的優(yōu)點(diǎn)和缺點(diǎn)

事不宜遲，讓我們先來(lái)了解 RTMP 協(xié)議的歷史。

RTMP 的歷史

RTMP 由 Adobe 推出，用于超級(jí)流行的 Adobe Flash 播放器中，數(shù)百萬(wàn)網(wǎng)站曾使用這款播放器向用戶展示視頻。在鼎盛時(shí)期，大約超過(guò) 90~95% 有視頻內(nèi)容的網(wǎng)站上都使用 Adobe Flash 播放器來(lái)播放視頻。

Adobe 對(duì) RTMP 的定義如下：

RTMP （實(shí)時(shí)信息傳輸協(xié)議）用于在 Adobe Flash 平臺(tái)技術(shù)（包括 Adobe Flash 播放器和 Adobe AIR）間實(shí)現(xiàn)音頻、視頻和數(shù)據(jù)的高性能傳輸?，F(xiàn)在，作為一種開(kāi)放規(guī)范，RTMP 可用于創(chuàng)建實(shí)現(xiàn)與 Adobe Flash 播放器兼容的 AMF、SWF、FLV 和 F4V 等開(kāi)放格式的音頻、視頻和數(shù)據(jù)傳輸?shù)漠a(chǎn)品和技術(shù)?！狝dobe

然而，隨著 Flash 的棄用，RTMP 不再用于向 Adobe Flash 播放器傳輸視頻，同時(shí)還要面臨與基于 HTTP 的視頻傳輸協(xié)議 MPEG-DASH 和 HLS 的競(jìng)爭(zhēng)。但是，RTMP 仍然在向編碼器傳輸視頻的過(guò)程中發(fā)揮著重要作用，我們?cè)谙挛膶?huì)講到。

RTMP 的工作原理

正如我們?cè)谏衔闹兴私獾降模琑TMP 是一種基于 TCP 的、用于數(shù)據(jù)、音頻和視頻傳輸?shù)碾p向通信協(xié)議。

RTMP 的工作原理是：通過(guò)建立和維護(hù) RTMP 客戶端和 RTMP 服務(wù)端之間的通信路徑來(lái)實(shí)現(xiàn)快速、可靠的數(shù)據(jù)傳輸。

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

傳統(tǒng)觀點(diǎn)認(rèn)為切片尺寸不應(yīng)太大，也不應(yīng)太小。較大的切片在寫(xiě)入操作中引起延遲，而太小的切片則會(huì)增加 CPU 的負(fù)載。

圖片來(lái)源: Wikipedia

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

RTMP 連接設(shè)置：握手、連接、推拉流

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

讓我們分別看下這三個(gè)步驟。

第一步：握手

RTMP 中的握手過(guò)程相對(duì)簡(jiǎn)單，在建立 TCP 連接后進(jìn)行。在此握手過(guò)程中，每一方（客戶端和服務(wù)端）發(fā)送三個(gè)數(shù)據(jù)包，分別為 C0、C1、C2 （客戶端）和 S0、S1 、S2（服務(wù)端）。

下面是對(duì) RTMP 握手過(guò)程的解釋：

客戶端向服務(wù)器發(fā)送 C0 數(shù)據(jù)包，數(shù)據(jù)包中包含客戶端請(qǐng)求的 RTMP 版本。

然后客戶端在沒(méi)有等到服務(wù)器表示已接收到 C0 的情況下，發(fā)送包含了 1536 字節(jié)隨機(jī)數(shù)據(jù)的 C1。

此時(shí)，服務(wù)器必須等到它收到 C0 才能響應(yīng) S0 和 S1（可選）。在這個(gè)階段，服務(wù)器知道客戶端所請(qǐng)求的 RTMP 版本。服務(wù)器響應(yīng) S0 和 S1—— 它們本質(zhì)上是 C0 和 C1 的副本。

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

圖片來(lái)源: Wikipedia

第二步：連接

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

AMF 代表 Action Message Format，用于在 Adobe Flash 客戶端和 Flash 媒體服務(wù)器之間發(fā)送信息?；蛘撸绦騿T可以使用 AFM 序列化 ActionScript 和 XML 的對(duì)象圖。AMF 在 RTMP 流傳輸中用于客戶端和服務(wù)器之間的通信，表明信息類(lèi)型和內(nèi)容。更多關(guān)于 AMF 的信息，可以在這里閱讀：https://en.wikipedia.org/wiki/Action_Message_Format 。

下面的示例顯示了由客戶端向 RTMP 服務(wù)器發(fā)出的信息。其中使用了連接 URL、音頻編解碼器、視頻編解碼器和所使用的 AMF 版本號(hào)。在此示例中，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 服務(wù)器的響應(yīng)信息：

(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 }

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

第三步：推拉流

在 RTMP 握手和連接步驟后，RTMP 客戶端和 RTMP 服務(wù)器之間的連接已經(jīng)建立，現(xiàn)在就可以傳送數(shù)據(jù)了。為了實(shí)現(xiàn)數(shù)據(jù)的傳輸，RTMP 規(guī)范定義了下面幾個(gè)命令：

createStream

play

play2

deleteStream

closeStream

receiveAudio

receiveVideo

publish

seek

pause

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

現(xiàn)在你對(duì) RTMP 連接的工作原理已經(jīng)有了基本的理解，接下來(lái)讓我們了解一些常用的 RTMP 變體。

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

在這一部分，我們將簡(jiǎn)單介紹用于特定目的的 RTMP 變體，讓我們從 RTMPS 開(kāi)始。

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

RTMPE： RTMPE 使用了包含 Diffie–Hellman key exchange 和 HMACSHA256 的行業(yè)標(biāo)準(zhǔn)加密。它生成了一對(duì) RC4 密鑰，其中：

第一個(gè)密鑰用于加密從服務(wù)器向客戶端發(fā)出的媒體數(shù)據(jù)。

第二個(gè)密鑰用于加密向服務(wù)器發(fā)送的數(shù)據(jù)。

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

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

RTMFP: RTMPF 基于 UDP 協(xié)議（而非 TCP），而且沒(méi)有使用 RTMP Chunk Stream。RTMFP 設(shè)計(jì)用于直接在 P2P 之間進(jìn)行低延遲、實(shí)時(shí)的音頻和視頻通信，而無(wú)需通過(guò) RTMP 服務(wù)器。更多關(guān)于 RTMFP 的詳細(xì)信息，請(qǐng)閱讀： https://www.adobe.com/in/products/adobe-media-server-extended/rtmfp-faq.html 。

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

在繼續(xù)學(xué)習(xí)前，讓我們一起來(lái)看下 RTMP 中的編解碼器支持。頭部文件說(shuō)明了對(duì)于下列編解碼器的支持：

音頻：AAC、MP3

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

哪里支持 RTMP？

一些商業(yè)和開(kāi)源編碼器以及流媒體引擎支持 RTMP，無(wú)論是拉流，或生成 RTMP 數(shù)據(jù)源（推流）。你可以使用：

OBS Studio, 免費(fèi)的廣播和直播軟件，可以生成 RTMP 數(shù)據(jù)源

FFmpeg

Dacast.com

Bitmovin.com

Ant Media Server

Wowza

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

RTMP 推流替代方案

由于 Adobe 結(jié)束了對(duì)于 Flash 的支持，RTMP 現(xiàn)在所面臨的是不太確定的未來(lái)。對(duì)于推流而言，你還可以考慮其他替代方案。

HLS 是可以替代 RTMP 的流行方案。HLS 是流媒體行業(yè)中的公認(rèn)標(biāo)準(zhǔn)，從編碼器、打包器、加密（DRM）、CDN 到設(shè)備上的播放，它獲得了來(lái)自視頻生態(tài)的廣泛支持。

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

基于 HTTP 的協(xié)議會(huì)存在一個(gè)問(wèn)題，那就是它們會(huì)增加系統(tǒng)時(shí)延。通常情況下，在 HLS 和 DASH 中，必須先生成一定數(shù)量的視頻切片，才能創(chuàng)建 DASH 清單或者 HLS 播放列表。沒(méi)有播放列表或者清單，播放器便無(wú)法理解生成的視頻流。等待播放列表或者清單的過(guò)程增加了時(shí)延，通常情況下會(huì)對(duì)系統(tǒng)造成 45 秒～1 分鐘的延遲。

不過(guò)，人們正在開(kāi)發(fā)低延遲的 DASH 和 HLS 協(xié)議，它們能夠減少基于 HTTP 的流媒體時(shí)延，并能夠緩解基于 HTTP 的流媒體協(xié)議所帶來(lái)的問(wèn)題。

結(jié)語(yǔ)

我希望這篇關(guān)于 RTMP 的介紹性文章能對(duì)你有所幫助，在未來(lái)的文章中，我們將研究 RTSP、RTMP 和 RTSP 之間的區(qū)別，以及如何使用 OBS Studio 等流行工具來(lái)實(shí)現(xiàn) RTMP 推拉流。

我們下次再見(jiàn)，保重，請(qǐng)繼續(xù) Streaming！

致謝：

本文已獲得作者 Krishna Rao Vijayanagar 授權(quán)翻譯和發(fā)布，特此感謝。

原文鏈接：

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

延伸閱讀：

Easy Tech：什么是 MPEG-DASH 協(xié)議

什么是 HLS（HTTP Live Streaming）?