20 世纪 90 年代，Macromedia 推出实时消息传输协议（RTMP），作为 Flash 的支柱，奠定了此后 20 多年互联网多媒体流媒体传输的通用标准。虽然 HLS 和 MPEG-DASH 等较新的流媒体协议现在用于流媒体管道的内容分发阶段，但 RTMP 仍在后端发挥着重要作用。
随着 Flash 支持的逐渐减少以及传统 Web 浏览器之外的流媒体平台（包括移动和桌面原生应用、智能电视以及一些物联网设备）的兴起，这些较新的协议开始流行起来。如今的开发人员可能不需要了解构建传统 RTMP 流（从初始采集到播放）的每个细节，但要构建和维护任何旨在向终端用户交付同步音频、视频和数据的现代应用程序或平台，就必须对 RTMP 框架的功能有一个高层次的了解。所有这些平台都依赖于 RTMP 标准化的基础流媒体架构和概念，因此在开始构建直播平台之前，有必要回顾一下这些概念。
想要更专业的代码教程？查看我们的分步指南，了解如何使用 ZEGO SDK 快速实现超低延迟直播。
什么是 RTMP 协议？
RTMP 即 Real-Time Messaging Protocol(实时信息传输协议)是一套标准化的规范，用于通过互联网将流式音频、视频和数据从源传输到用户的播放设备，具有同步定时和低延迟的特点。
RTMP 从输入到交付的延迟时间约为 3-5 秒，即使以当今的标准来看，也是较快的。对于双向视频通话等要求即时响应的用途来说，这样的速度可能不够快，但对于托管内容的交付，甚至对于大多数单向直播来说，已经足够了。网络连接、视频分辨率、添加的音频层、转码服务器的速度以及播放设备的下载速度等因素都会影响 RTMP 流的延迟。
无论总延迟时间长短如何，RTMP 都能提供流畅的播放体验，并将音频和视频并行输出同步到相同的时间信息。开发者有时会为不同的消息类别分配不同的优先级，以便在网络连接不佳的情况下，数据流中最重要的部分仍能传输（例如，如果视频传输出现问题，音频仍能播放）。
RTMP 和 Flash Player 的历史
大多数人仍然将 RTMP 与Flash Player联系在一起，后者已于 2020 年终止服务。但 RTMP 的用例和实现范围实际上远远超出了 Flash，而且该协议本身仍然非常活跃。快速回顾一下 RTMP 和 Flash 的历史，就能明白两者之间既有关联，又不尽相同。
Flash Player 于 1996 年首次亮相，由 Macromedia 开发的 RTMP 提供支持。Adobe 于 2005 年收购了 Macromedia，并暂时保留了更名后的 Adobe Flash Player 和 RTMP 的专有权。但在 2012 年，Adobe 将 RTMP 作为开放规范向公众发布，允许任何人构建用于传输视频、音频和数据的产品和技术。随着协议的开放，许多新的解决方案可以使用 RTMP 来开发全部或部分传输过程，而无需依赖 Flash。这也是为什么即使在 Flash 停产后，RTMP 仍然可以使用的原因之一。
Adobe 于 2017 年宣布 Flash 的 EOL 终止，内容提供商有三年时间迁移到 HLS、MPEG-DASH、HTML5、WebGL 和 WebAssembly 等较新的协议。这些较新的开放标准更加安全，并且基于 Web，因此用户无需下载和安装插件。许多现代流媒体仍然使用 RTMP 作为传输管道的一部分，但不像 Flash 那样涵盖内容从源到播放的整个过程。
RTMP 协议如何工作？
RTMP 背后的基本思想是在播放设备和信号源之间建立并保持持久的网络连接，中间还有一些额外的步骤。连接遵循传输控制协议（TCP），该协议控制着终端如何在互联网上建立联系并交换消息。
建立安全连接
要发起 RTMP 连接，两个端点首先要进行握手，然后才能交换任何数据。RTMP 握手本身无法提供与现代证书和加密相同的安全性，因此建议采取额外的保护措施。RTMP 的安全变体包括 RTMPS（增加了传输层安全性，即 TLS，以前称为 SSL）和 RTMPE（Adobe 的专有加密方法）。
开放的 RTMP 规范并不要求开发人员使用 Adobe 的安全措施（或任何特定的措施），从而允许开发人员自由地根据需要保护连接，并调整 RTMP 以适应未来不断发展的安全实践。
多路复用和分包
一旦 RTMP 握手完成并建立持久连接，即可传输流媒体内容。RTMP 用于复用和打包音频和视频数据的标准对于提供流畅的媒体流体验至关重要。
多路复用技术将独立的音频和视频数据（以及用户聊天消息等互动内容数据）合并为一个可同时传输的音视频流。如果您曾经使用过视频或音频编辑软件，您可以将此过程想象成（尽管并不等同于）将多轨项目混音并导出为一个媒体文件。理论上，多路复用技术允许组合无限数量的音频和视频数据流，但实际上，通常每个数据流只有一两个。接收到交错数据后，必须对其进行分解或解复用，才能播放原始音频和视频数据。
与许多计算机功能一样，数据包化将大数据文件分解成更小的块（或数据包），以便更轻松地传输。当它们到达目的地时，数据包会被重新组合成之前更大的形式。压缩和解压缩在确保音频和视频数据（原始格式会生成庞大的文件）能够顺畅地在互联网上传输方面也发挥着关键作用。
RTMP 流媒体管道中的步骤
以下是上述流程如何协同工作，将多媒体流从源或摄像机输入端传输到最终用户的播放设备。
1. 摄像头采集
摄像头负责采集光线和声音，并将这些模拟输入转换为原始（未压缩）数字格式。以音频为例，麦克风捕捉声音波形，并发出与波形类似的电流。采集设备中的模数转换器将电信号绘制在图表上，并将波形上每个可感知的独特点记录为数字有序对。如上所述，这种原始数字数据会产生非常大的文件，因此必须在流媒体播放前进行压缩（编码）。
对于非直播的托管媒体（但仍通过互联网进行流式传输以便在用户设备上进行近乎实时的播放），相应的步骤是上传媒体文件。与来自直播摄像头的原始数据不同，此文件已经过编码。根据托管和分发平台的不同，它可能仍会被转码为不同的格式和分辨率，基本遵循此处概述的相同步骤，或者可能会跳过其中的一些步骤。
2. 编码
编解码器将原始音频和视频数据压缩成更小、更易于处理的文件大小，理想情况下不会有任何明显的质量损失。在直播中，编码通常由采集设备处理，而托管媒体通常在从视频编辑软件导出时进行编码。H.264是当今最流行的视频编码格式，部分原因在于它在质量和压缩率之间实现了优化的平衡。
3. 分发（上传）
现在必须将编码媒体分发到媒体服务器，这就是 RTMP 的用武之地。RTMP 在采集和编码设备与服务器之间建立持久连接，从而允许快速上传数据。
4. 媒体服务器（转码和解复用）
无论用户使用什么类型的设备、设备运行什么操作系统、或者他们的互联网连接是良好还是一般，他们都希望获得合理的媒体播放体验。
媒体服务器在后台执行重要的转码工作，以实现这种流畅的跨平台体验。在这个称为“转码”的过程中，服务器将原始媒体重新打包成许多不同分辨率、质量和比特率的版本，甚至输出多种传输协议，例如 HLS、m3U8 和 VP8，以满足不同播放设备的需求。例如，当您在观看 YouTube 视频时从 480p 切换到 720p 时，您实际上是在要求 YouTube 服务器播放以不同分辨率编码的（同一视频的）另一个文件。
5. 内容分发网络（CDN）
然后，必须将正确版本的编码媒体从媒体服务器发送到播放设备。CDN 并非必不可少，但它确实可以减少延迟和流媒体服务器的负载，尤其是对于需要从源头长途传输的媒体。CDN 的工作原理是将流媒体数据镜像到全球各地的众多服务器，从而按区域处理最终用户的需求。
传统上，从媒体服务器或 CDN 到用户设备的最后一英里连接由 RTMP 处理，并由 Flash Player 负责播放。此过程本质上是上述步骤 3 的逆过程。然而，如今，更先进的协议已经取代了 RTMP，以实现更快、更安全的“最后一英里”媒体传输。
6. 播放
在接收端，用户的播放设备解码传入的数据，并将数据片段发送到相应的硬件。对于音频，数模转换器将音频文件中有序的数字对转换回模拟电信号，然后放大后驱动设备的扬声器锥盆。类似的过程将视频数据转换为我们在屏幕上看到的彩色像素阵列。
RTMP 规范一览
以下是您需要了解的最重要的 RTMP 规范。如需完整文档，您可以直接从 Adobe 下载RTMP规范PDF。
支持的视频格式： H.264（首选）和 VP8 最受欢迎，但也支持其他编解码器，如 Screen Video v2 和 AMF、SWF、FLV 和 F4V。
支持的音频格式： AAC（首选）、mp3、AAC-LC 和 HE-AAC
RTMP 的替代版本：
- RTMPS使用传输层安全性 (TLS)（以前称为安全套接字层或 SSL）进行连接。
- RTMPT 将数据封装在 HTTP 请求中。
- RTMPE 使用 Adobe 的专有加密。
- RTMFP 通过用户数据报协议（UDP）进行传输，该协议不需要建立一致的连接，而不是 TCP。
RTMP 直播的现状
前面我们已经了解了传统 RTMP 流的基本工作原理，现在来探讨一下该协议如今的使用情况、新的协议如何取代它，以及这些变化发生在管道的哪个环节。
RTMP 仍然广泛用于内容流式传输旅程的第一阶段（上文第 3 步），即将内容从源传输到服务器。但它不再被认为是将同一内容最后一公里交付给用户（上文第 5 步和第 6 步）的安全或高效之选。
目前，最流行的客户端内容交付 RTMP 替代方案是 Apple 的HTTPS Live Streaming（HLS 协议）。Apple 没有在 iOS 上构建对 Flash 以及 JW Player 和 Flowplayer 等播放器的支持，而是创建了自己的前端内容分发协议。HLS 已获得大多数现代设备、浏览器和应用程序的支持，包括 Google Chrome、Android、Mac、Linux 和 Windows，以及电视播放设备和智能电视。
与 RTMP 不同，HLS 不会在客户端和服务器之间建立持续的双向连接。这意味着它实际上并非以传统意义上的方式创建流。HLS 使用 HTTP 逐步下载数据包，其工作方式更类似于“常规”的 Web 内容交付。HLS 的一大优势是延迟更低：最新版本的协议可以将延迟时间控制在两秒以内。
MPEG-DASH 的工作原理与 HLS 类似，是 RTMP 的最后一公里传输的另一种首选替代方案。在数据采集方面，SRT 和WebRTC等协议正在逐渐普及，并可能最终取代 RTMP。
而像 ZEGO 这样专业的实时互动服务商，为满足用户更高需求，在直播协议方面会采用自研方式进行优化，详细可阅读：ZEGO 超低延迟直播和其他 RTMP + CDN 直播技术有什么区别？
