RTMP的工作原理

翻译：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）?