流媒体协议（二）：RTMP协议

时间 2019-11-06

标签媒体协议 rtmp 繁體版

原文原文链接

1、概念与摘要

RTMP协议从属于应用层，被设计用来在适合的传输协议（如TCP）上复用和打包多媒体传输流（如音频、视频和互动内容）。RTMP提供了一套全双工的可靠的多路复用消息服务，相似于TCP协议[RFC0793]，用来在一对结点之间并行传输带时间戳的音频流，视频流，数据流。一般状况下，不一样类型的消息会被分配不一样的优先级，当网络传输能力受限时，优先级用来控制消息在网络底层的排队顺序。服务器

2、RTMP块流

实时消息传递协议块流(RTMP块流)。它做为一款高级多媒体流协议提供了流的多路复用和打包服务。RTMP块流被设计用来传输实时消息协议，它可使用任何协议来发送消息流。每一个消息都包含时间戳和有效类型标识。RTMP块流和RTMP适用于各类视听传播的应用程序，包括一对一的，和一对多的视频直播、点播服务、互动会议应用程序。网络

当使用一个可靠的传输协议如TCP[RFC0793]时，RTMP块流提供了一种能够在多个流中，基于时间戳的端到端交付全部消息的方法。RTMP块流不提供任何优先级或相似形式的控制，但可使用更高级别的协议来提供这样的优先级。例如，一个视频服务器能够根据发送的时间或确认每一个消息的时间，来决定为一个网络差的用户丢弃视频信息，以确保音频信息的及时接收。dom

RTMP块流不只包含了本身的协议控制信息，同时也提供了一个更高级别的协议机制，用来嵌入用户控制信息。加密

消息格式

消息格式能够被分割成多个块，用来在更高的协议中支持多路复用。在建立块消息格式时，应该包含如下字段:设计

时间戳
消息的时间戳。这个字段占用4字节。视频

长度
消息的有效长度。若是消息头不能被忽略，它应该包括长度。这个字段在块头中占用3字节。blog

类型ID
各类类型的协议控制消息的ID。这些消息使用RTMP块流协议和更高级别的协议来传输信息。全部其余类型的ID能够用在高级协议，这对于RTMP块流来讲，是不透明的。事实上，RTMP块流中没有要求使用这些值做为类型；全部(无协议的)消息多是相同的类型，或者应用程序使用这个字段来区分多个链接，而不是类型。这个字段在块头中占用1字节。文档

消息流ID
消息流ID能够是任意值。当同一个块流被复用到不一样的消息流中时，能够经过消息流ID来区分它们。另外，对于RTMP块流而言，这是一个不透明值。该字段占用4字节，使用小端序。同步

握手

RTMP链接从握手开始。它包含三个固定大小的块，不像其余的协议，是由头部大小可变的块组成的。直播

客户端（初始化链接的一端）和服务端发送一样的三个块。为了方便描述，客户端发送的三个块命名为C0，C1，C2；服务端发送的三个块命名为S0，S1，S2。　　

握手序列

客户端经过发送C0和C1消息来启动握手过程。客户端必须接收到S1消息，而后发送C2消息。客户端必须接收到S2消息，而后发送其余数据。

服务端必须接收到C0或者C1消息，而后发送S0和S1消息。服务端必须接收到C1消息，而后发送S2消息。服务端必须接收到C2消息，而后发送其余数据。

C0和S0格式

C0和S0包由一个字节组成，下面是C0/S0包内的字段:

                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |   version     |
                             +-+-+-+-+-+-+-+-+
                              C0 and S0 bits

版本(8比特)
在C0包内，这个字段表明客户端请求的RTMP版本号。在S0包内，这个字段表明服务端选择的RTMP版本号。此文档使用的版本是3。版本0-2用在早期的产品中，如今已经被弃用；版本4-31被预留用于后续产品；版本32-255（为了区分RTMP协议和文本协议，文本协议一般以可打印字符开始）不容许使用。若是服务器没法识别客户端的版本号，应该回复版本3。客户端能够选择下降到版本3，或者停止握手过程。

C1和S1格式

C1和S1包长度为1536字节，包含如下字段:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        time (4 bytes)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        zero (4 bytes)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        random bytes                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         random bytes                          |
     |                            (cont)                             |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              C1 and S1 bits

时间(4字节)
本字段包含一个时间戳，客户端应该使用此字段来标识全部流块的时刻。时间戳取值能够为零或其余任意值。为了同步多个块流，客户端可能但愿多个块流使用相同的时间戳。

零(4字节)
本字段必须为零。

随机数据(1528字节)
本字段能够包含任意数据。因为握手的双方须要区分另外一端，此字段填充的数据必须足够随机(以防止与其余握手端混淆)。不过不必为此使用加密数据或动态数据。

C2和S2格式

C2和S2包长度为1536字节，做为C1和S1的回应，包含如下字段:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        time (4 bytes)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       time2 (4 bytes)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        random echo                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         random echo                           |
     |                            (cont)                             |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              C2 and S2 bits

时间(4字节)
本字段必须包含对端发送的时间戳。

时间(4字节)
本字段必须包含时间戳，取值为接收对端发送过来的握手包的时刻。

随机数据(1528字节)
本字段必须包含对端发送过来的随机数据。握手的双方可使用时间1和时间2字段来估算网络链接的带宽和/或延迟，可是不必定有用。

3、RMTP握手

握手过程示意图

+-------------+                           +-------------+
|    Client   |       TCP/IP Network      |    Server   |
+-------------+            |              +-------------+
      |                    |                     |
Uninitialized              |               Uninitialized
      |          C0        |                     |
      |------------------->|         C0          |
      |                    |-------------------->|
      |          C1        |                     |
      |------------------->|         S0          |
      |                    |<--------------------|
      |                    |         S1          |
 Version sent              |<--------------------|
      |          S0        |                     |
      |<-------------------|                     |
      |          S1        |                     |
      |<-------------------|                Version sent
      |                    |         C1          |
      |                    |-------------------->|
      |          C2        |                     |
      |------------------->|         S2          |
      |                    |<--------------------|
   Ack sent                |                  Ack Sent
      |          S2        |                     |
      |<-------------------|                     |
      |                    |         C2          |
      |                    |-------------------->|
 Handshake Done            |               Handshake Done
      |                    |                     |
          Pictorial Representation of Handshake
                     握手示意图

下面是握手示意图中提到的状态:

未初始化
协议版本号在此阶段发送。客户端和服务器均处于未初始化状态。客户端发送携带协议版本号的C0包。若是服务器支持此版本，回复S0和S1包。若是服务器不支持此版本，使用适当的动做回复。在RTMP协议中，此动做是停止链接。
注: 在”C0和S0格式”章节中说起,若是服务器不支持客户端的版本号,能够选择降到版本3或停止。

发送版本
客户端和服务器双方在未初始化状态后，会进入发送版本状态。以后，客户端等待S1包，服务器等待C1包。待接收到数据包，客户端发送C2包，服务器发送S2包。而后，双方都进入答复状态。客户端等待C2的答复，服务器等待S2的答复。

握手完成客户端和服务器交换消息。