RTMP协议（Real-Time Messaging Protocol） 2024-05-30 作者 C3P00 RTMP协议（Real-Time Messaging Protocol）是一种用于在互联网上流式传输音频、视频和数据的通信协议[1]。最初由Macromedia开发为Flash Player和Flash Communication Server之间的流媒体传输的专有协议，后来被Adobe（收购了Macromedia）发布了该协议的不完整版本供公众使用[1]。 RTMP协议有多个变种： RTMP：在Transmission Control Protocol（TCP）之上工作的“纯”协议，默认使用1935端口号。 RTMPS：在Transport Layer Security（TLS/SSL）连接上的RTMP。 RTMPE：使用Adobe自己的安全机制对RTMP进行加密。虽然实现的细节是专有的，但该机制使用行业标准的加密原语[1]。 RTMPT：封装在HTTP请求中以穿越防火墙。RTMPT通常使用TCP端口80和443上的明文请求来绕过大多数企业流量过滤。封装的会话可以在内部携带纯RTMP、RTMPS或RTMPE数据包[1]。 RTMFP：在User Datagram Protocol（UDP）上的RTMP，取代了RTMP Chunk Stream。Secure Real-Time Media Flow Protocol套件由Adobe Systems开发，使终端用户能够直接连接和通信（P2P. ✅[1]。 RTMP的基本操作是基于TCP的，它维持持久连接并允许低延迟通信。为了平稳地传输流并尽可能多地传输信息，它将流分割成片段，并且片段的大小在客户端和服务器之间动态协商。有时，片段的大小保持不变；音频数据的默认片段大小为64字节，视频数据和大多数其他数据类型的默认片段大小为128字节。来自不同流的片段可以交错和多路复用到单个连接上。由于较长的数据块，该协议每个片段仅携带一个字节的头部，因此开销非常小。然而，在实践中，通常不会交错单个片段。相反，交错和多路复用是在数据包级别上完成的，以确保每个通道满足其带宽、延迟和其他服务质量要求。以这种方式交错的数据包被视为不可分割的，不会在片段级别上交错[1]。 RTMP定义了几个虚拟通道，可以在这些通道上发送和接收数据包，并且这些通道彼此独立运行。例如，有一个用于处理RPC请求和响应的通道，一个用于视频流数据的通道，一个用于音频流数据的通道，一个用于带外控制消息（片段大小协商等）的通道等。在典型的RTMP会话期间，多个通道可能同时处于活动状态。当对RTMP数据进行编码时，会生成一个数据包头部。数据包头部指定了要发送的通道的ID、生成时间戳（如果需要）以及数据包有效载荷的大小。然后，在将其发送到连接上之前，将其实际有效载荷内容（媒体数据）根据当前协商的片段大小进行分段。数据包头部本身永远不会被分段，其大小不计入数据包的第一个片段中的数据。换句话说，只有实际的数据包有效载荷（媒体数据）会被分段[1]。 在更高的层次上，RTMP封装了MP3或AAC音频和FLV1视频多媒体流，并可以使用Action Message Format进行远程过程调用（RPC）。所需的任何RPC服务都是异步进行的，使用单个客户端/服务器请求/响应模型，因此不需要实时通信[2]。 RTMP会话可以使用以下两种方法进行加密： 使用行业标准的TLS/SSL机制。底层的RTMP会话只是包装在正常的TLS/SSL会话中。 使用RTMPE，在RTMP会话中包装一个轻量级的加密层。 在RTMP Tunneled（RTMPT）中，RTMP数据通过HTTP进行封装和交换，客户端（媒体播放器）的消息被发送到服务器上的80端口（HTTP的默认端口）[1]。RTMPT中的消息由于HTTP头部的原因比等效的非隧道化RTMP消息要大，但在客户端位于阻止非HTTP和非HTTPS出站流量的防火墙后，RTMPT可能有助于使用RTMP的场景，否则将无法使用非隧道化的RTMP。 RTMP协议的数据包结构如下： 数据包通过TCP连接发送，首先在客户端和服务器之间建立连接。 数据包包含一个头部和一个主体，在连接和控制命令的情况下，主体使用Action Message Format（AMF）进行编码。 头部分为基本头部（从图表中分离出来）和块消息头部。基本头部是数据包的唯一固定部分，通常由一个复合字节组成，其中最高的两个有效位是块类型（在规范中称为fmt），其余部分形成流ID。根据前者的值，可以省略消息头部的某些字段，并且可以从先前的数据包中派生它们的值，而根据后者的值，基本头部可以扩展为一个或两个额外的字节。如果基本头部的剩余六个位（最低有效位）的值为0，则基本头部为两个字节，表示从流ID 64到319（64+255）；如果值为1，则基本头部为三个字节（最后两个字节编码为16位小端），表示从流ID 64到65599（64+65535）；如果值为2，则基本头部为一个字节，保留用于低级协议控制消息和命令。块消息头部包含元数据信息，例如消息大小（以字节为单位）、时间戳增量和消息类型。最后一个值是一个字节，定义数据包是音频、视频、命令还是“低级”RTMP数据包，例如RTMP Ping[1]。 Learn more: Real-Time Messaging Protocol – Wikipedia RTMP协议深度显示内容解析：从原理到实践，掌握实时流媒体传输技术-阿里云开发者社区 实时消息协议 – 维基百科，自由的百科全书
RTMP协议（Real-Time Messaging Protocol）是一种用于在互联网上流式传输音频、视频和数据的通信协议[1]。最初由Macromedia开发为Flash Player和Flash Communication Server之间的流媒体传输的专有协议，后来被Adobe（收购了Macromedia）发布了该协议的不完整版本供公众使用[1]。
RTMP协议有多个变种：
RTMP的基本操作是基于TCP的，它维持持久连接并允许低延迟通信。为了平稳地传输流并尽可能多地传输信息，它将流分割成片段，并且片段的大小在客户端和服务器之间动态协商。有时，片段的大小保持不变；音频数据的默认片段大小为64字节，视频数据和大多数其他数据类型的默认片段大小为128字节。来自不同流的片段可以交错和多路复用到单个连接上。由于较长的数据块，该协议每个片段仅携带一个字节的头部，因此开销非常小。然而，在实践中，通常不会交错单个片段。相反，交错和多路复用是在数据包级别上完成的，以确保每个通道满足其带宽、延迟和其他服务质量要求。以这种方式交错的数据包被视为不可分割的，不会在片段级别上交错[1]。
RTMP定义了几个虚拟通道，可以在这些通道上发送和接收数据包，并且这些通道彼此独立运行。例如，有一个用于处理RPC请求和响应的通道，一个用于视频流数据的通道，一个用于音频流数据的通道，一个用于带外控制消息（片段大小协商等）的通道等。在典型的RTMP会话期间，多个通道可能同时处于活动状态。当对RTMP数据进行编码时，会生成一个数据包头部。数据包头部指定了要发送的通道的ID、生成时间戳（如果需要）以及数据包有效载荷的大小。然后，在将其发送到连接上之前，将其实际有效载荷内容（媒体数据）根据当前协商的片段大小进行分段。数据包头部本身永远不会被分段，其大小不计入数据包的第一个片段中的数据。换句话说，只有实际的数据包有效载荷（媒体数据）会被分段[1]。
在更高的层次上，RTMP封装了MP3或AAC音频和FLV1视频多媒体流，并可以使用Action Message Format进行远程过程调用（RPC）。所需的任何RPC服务都是异步进行的，使用单个客户端/服务器请求/响应模型，因此不需要实时通信[2]。
RTMP会话可以使用以下两种方法进行加密：
在RTMP Tunneled（RTMPT）中，RTMP数据通过HTTP进行封装和交换，客户端（媒体播放器）的消息被发送到服务器上的80端口（HTTP的默认端口）[1]。RTMPT中的消息由于HTTP头部的原因比等效的非隧道化RTMP消息要大，但在客户端位于阻止非HTTP和非HTTPS出站流量的防火墙后，RTMPT可能有助于使用RTMP的场景，否则将无法使用非隧道化的RTMP。
RTMP协议的数据包结构如下：
Learn more: