RTMP协议分析

理论

总体介绍

RTMP协议是应⽤层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。在基于传输层协议的链接建⽴完成后，RTMP协议也要客户端和服务器通过“握⼿”来建⽴基于传输层链接之上的RTMP Connection链接，在Connection链接上会传输⼀些控制信息，如SetChunkSize,SetACKWindowSize。其中CreateStream命令会创建⼀个Stream链接，⽤于传输具体的⾳视频数据和控制这些信息传输的命令信息。RTMP协议传输时会对数据做⾃⼰的格式化，这种格式的消息我们称之为RTMP Message，⽽实际传输的时候为了更好地实现多路复⽤、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是⼀个单独的Message，也可能是Message的⼀部分，在接受端会根据chunk中包含的data的⻓度，message id和message的⻓度把chunk还原成完整的Message，从⽽实现信息的收发。

介绍

RTMP(Real Time Messaging Protocol)是一个应用层协议，主要用于在Flash player和服务器之间传输视频、音频、控制命令等内容。该协议的突出优点是: 低延时。RTMP基于TCP, 默认使用端口1935。

RTMP 的主要特点如下:

实时性强:
- RTMP 采用 TCP 作为传输层协议,可以提供更可靠的实时数据传输。
- 通过分块传输和优先级控制等机制,可以最大限度地减少传输延迟。
可靠性高:
- RTMP 建立在 TCP 之上,能够保证数据传输的可靠性。
- 支持重传机制来弥补丢包对实时性的影响。
支持多种媒体格式:
- RTMP 可以传输 FLV、MP3、H.264 等常见的视频和音频格式。
- 还支持 ActionScript 对象等数据格式的传输。
广泛应用:
- RTMP 被广泛应用于直播、视频点播、在线教育等领域。
- 主要被 Adobe Flash/AIR 平台和 NGINX 服务器所支持。

总之, RTMP 是一种专门为实时流媒体传输而设计的开放协议,具有高实时性、高可靠性和多格式支持等特点,是当前互联网视频直播和点播领域的重要技术标准之一。

名词解释

为了方便后续阅读，先学习主要的名词解释:
1. Payload: 数据包中包含的数据,例如音频样本或压缩视频数据。
2. Packet: 由固定的头部和载荷数据组成的数据包。
3. Port: 传输协议用于区分主机内部多个目的地的抽象。
4. Transport address: 网络地址和端口的组合,标识传输层端点。
5. Message stream/stream id: 消息流动的逻辑通信通道。
6. Message stream ID: 每个消息都有一个ID,用于标识消息所属的消息流。
7. Chunk (块): 消息的一个片段,消息被分成较小的部分并交错发送。
8. Chunk stream(块流): 允许块在特定方向流动的逻辑通信通道。
9. Chunk stream ID: 每个块都有一个ID,用于标识块所属的块流。
10. Multiplexing: 将独立的音频/视频数据合成为一个连贯的音频/视频流的过程。
11. DeMultiplexing: 多路复用的反向过程,将交错的音频和视频数据组装成原始的音频和视频数据。
12. Remote Procedure Call (RPC): 允许客户端或服务器调用对端子程序或过程的请求。
13. Metadata: 对数据的描述,如电影标题、时长、创作日期等。
14. Application Instance: 客户端连接的服务器上的应用程序实例。
15. Action Message Format (AMF): 用于序列化ActionScript对象图的紧凑二进制格式。

RTMP播放基本流程

往后我们通过wireshark抓包方式，来检验。

Step 1:tcp三次握手

Step 2:rtmp握⼿

RTMP握手主要分为: 简单握手和复杂握手

简单握手

建⽴⼀个有效的RTMP Connection链接，⾸先要“握⼿”:客户端要向服务器发送C0,C1,C2（按序）三个 chunk，服务器向客户端发送S0,S1,S2（按序）三个chunk，然后才能进⾏有效的信息传输。

RTMP协议的实现者需要保证这⼏点：

客户端要等收到S1之后才能发送C2
客户端要等收到S2之后才能发送其他信息（控制信息和真实⾳视频等数据）
服务端要等到收到C0之后发送S1
服务端必须等到收到C1之后才能发送S2
服务端必须等到收到C2之后才能发送其他信息（控制信息和真实⾳视频等数据）

实际实现中为了在保证握⼿的身份验证功能的基础上尽量减少通信的次数，⼀般的发送顺序是这样的，这⼀点可以通过wireshark抓ffmpeg推流包进⾏验证

握手包分析

Time (4 bytes): 这个字段包含一个时间戳,这个时间戳应该被用作此端点发送的所有未来块的时间戳的起点
Zero (4 bytes): 这个字段必须全为 0。
Random data (1528 bytes): 这个字段可以包含任何任意值。由于每个端点都必须区分它发起的握手的响应和它的对等端发起的握手,因此这些数据应该足够随机。但不需要加密安全的随机性或动态值。

交互流程

复杂握手

复杂握手主要是增加了更严格的验证。
主要是将简单握手中1528Bytes随机数的部分平均分成两部分，一部分764Bytes存储public key(公共密钥)，另一部分764Bytes存储digest(密文，32字节)。
另外，复杂握手还有一个明显的特征就是: Version部分不为0，服务器端可根据这个来判断是否简单握手或复杂握手。

Step 3: connect(连接)

这里也叫连接，连接的是什么呢? 这里必须明白RTMP中一个很重要的概念: Application Instance。连接的是rtmp://192.168.126.129/live/36
其中live就是Application Instance（sport, music）不同的 Application Instance可根据功能等进行区分，比如直播可以用live来表示，点播回放可以用vod来表示。
播放该流时，connect的地址就是rtmp://192.168.126.129/live/36

流程

客户端发送 connect 命令消息给服务器:这个命令消息包含一些连接参数,如应用程序名称、客户端版本、认证信息等。

服务器处理 connect 命令:服务器验证客户端提供的连接参数是否有效。如果验证通过,服务器会建立一个新的 NetConnection 对象,并返回一个 _result 响应给客户端。
这个 _result 响应包含一些连接元数据,如服务器版本、服务器时间等信息。
客户端处理服务器的 _result 响应:客户端可以根据 _result 响应中的信息,确认连接是否成功建立。

Step 4: createStream(创建流)

创建逻辑通道createStream命令用于创建逻辑通道，该通道用于传输视频、音频、
metadata。
在服务器的响应报文中会返回，用于唯一的标示该Stream。
注：Message ID和Stream ID的区别

客户端发送 createStream 命令消息给服务器:它的作用是在服务器端创建一个新的消息流。
服务器处理 createStream 命令:服务器会创建一个新的 NetStream 对象,并返回一个 _result 响应给客户端。这个 _result 响应包含了新创建的 NetStream 对象的流 ID。
客户端处理服务器的 _result 响应:客户端接收到服务器的 _result 响应后,就获得了新创建流的流 ID。客户端可以使用这个流 ID 来标识后续发送到服务器的消息流。

举例可看出返回的Stream ID为1。后续的视频或音频的Stream ID就是1