rtmp协议（rtmp协议详解中文版）

简介

RTMP 在可靠流式传输（TCP）的基础上提供了双向的消息多路复用服务，在通讯双方之间传输与时间相关的并行流数据，如音频，视频和数据消息。协议实现方通常为不同的消息类型指定不同的优先级，这样在网络带宽受限时能改变底层传输顺序。

定义负载：包中所承载的数据。例如音频或视频数据。包：一个数据包由固定头部和所承载的数据组成。一些底层协议可能需要定义数据包的封装格式。端口：在一个计算机中用于区分不同目标的抽象定义。在 TCP/IP 协议中用一个小的正整数来表示端口。OSI 传输层的传输选择器就相当于端口。传输地址：标识一个传输终端的网络地址和端口的组合，例如 IP 地址和 TCP 端口的组合。消息流：允许消息传播的逻辑通道。消息流 ID：每个消息都会有一个对应的 ID，用于标识其所在的消息流。块：消息的一个片段。消息在传输之前会被分割成更小的片段，因为每一块都很小，以至于可以给不同的块指定各自的优先级，通过这种方式保证多个流中数据可以按照时间戳的顺序传输。块流：块向某一确定方向传播的逻辑通道。可以是客户端到服务端，也可以是服务端到客户端。块流 ID：每个块都会有一个对应的 ID，用于标识其所在的块流。复用：将独立的音频 / 视频数据整合为统一的音视频流，可以使多个音视频流同步传输。复用分离：复用的逆向过程。将合并的音视频数据分离为原始的音频和视频数据。远程过程调用：客户端或服务端调用另一端的功能。元数据：媒体数据的描述信息。应用实例：服务器上可以和 Client 建立连接的应用。动作消息格式：一个可用于序列化 ActionScript 对象图的紧凑的二进制格式。字节序：字节的顺序，即多字节类型的数据在内存中的存放顺序。TCP/IP 各层协议将字节序定义为大端字节序，因此 TCP/IP 协议中使用的字节序通常称之为网络字节序。大字节序：高位字节排放在内存的低地址，低位字节排放在内存的高地址。小字节序：低位字节排放在内存的低地址，高位字节排放在内存的高地址。字节序，校准，时间格式

所有整数都是以网络字节序来表示的。除非另行说明，本文中的所有数字都是十进制数。

在没有特殊说明的情况下，RTMP 中的数据都是字节对齐的。如果有填充的话，填充字节应该用 0。

RTMP 中的时间戳是用一个整数来表示的，代表相对于一个起始时间的毫秒数。通常每个流的时间戳都从 0 开始，但这不是必须的，只要通讯双方使用统一的起始时间就可以了。要注意的是，跨流的时间同步（不同主机之间）需要额外的机制来实现。

由于时间戳的长度只有 32 位，所以只能在 50 天内循环（49 天 17 小时 2 分钟 47.296 秒）。而流是可以不断运行的，可能多年才会结束。所以 RTMP 应用在处理时间戳是应该使用连续的数字算法，并且应该支持回环处理。例如：一个应用可以假设所有相邻的时间戳间隔不超过 2^31-1 毫秒，在此基础上，10000 在 4000000000 之后，3000000000 在 4000000000 之前。

时间戳增量也是以毫秒为单位的无符号整数。时间戳增量可能会是 24 位长度也可能是 32 位长度。

RTMP 块流

块流为上层流媒体协议提供复用和分包的功能。RTMP 块流是为配合 RTMP 协议而设计，但它可以使用在任何发送消息流的协议中。每个消息包含时间戳和负载类型信息。RTMP 块流和 RTMP 协议组合可以适用于多种音视频应用，从一对一或一对多直播到视频会议都能很好的满足。

当使用可靠传输协议（如 TCP）时，RTMP 块流为所有消息提供了可靠的跨流端对端按时间戳顺序发送的机制。RTMP 块流不提供优先级控制，但是可以由上层协议提供这样的优先级。例如：当某个客户端网络比较慢时，可能会选择抛弃一些视频消息来保证声音消息能够及时接收。

RTMP 块流除自身内置的协议控制消息外，还为上层协议提供了用户控制消息的机制。

消息格式

消息格式由上层协议定义，消息可以被分成多个块以支持多路复用。消息应该包含分块功能所需的所有字段，具体内容如下：

时间戳（4-byte)：消息的时间戳。长度（3-byte）：消息有效负载的长度，如果消息头不能被省略，则消息头的长度也应该包含在长度中。类型 ID（1-byte）：消息类型 ID。一些类型 ID 是为协议控制消息保留的，这些消息所表示的信息同时供 RTMP 块流协议和上层协议使用。所有其他类型 ID 都用于上层协议，RTMP 块流对这些 ID 做不透明处理。实际上，RTMP 块流不需要用这些值来区分类型，所有消息都可以是相同的类型，应用也可以用本字段来区分同步轨道而不是区分类型。消息流 ID（4-byte)：消息流 ID 可以是任意值。被复合到同一个块流的消息流，依据消息流 ID 进行分离。另外，就相关的块流而言，这个值是不透明的。这个字段使用小字节序。握手

RTMP 连接以握手开始，它的握手过程可能和其他协议不同，这里的握手由 3 个固定大小的块组成，而不是可变大小的块加上固定大小的头。

握手流程

握手由客户端发送 C0 和 C1 块开始。

客户端必须等接收到 S1 之后才可以发送 C2。客户端必须等接收到 S2 之后才可以发送其他数据。

服务器必须等接收到 C0 之后才可以发送 S0 和 S1，也可能接收到 C1 之后发送。服务器必须等接收到 C1 之后才可以发送 S2。服务器必须等接收到 C2 之后才可以发送其他数据。

C0 和 S0 格式

C0 和 S0 是单独的一个字节，可以当做一个 8bit 的整数字段来对待。

握手流程示意图

上图提到的状态的解释如下：

Uninitialized：未初始化状态。在该阶段发送协议版本。客户端在 C0 包中发送 RTMP 协议版本，如果服务器支持此版本，服务器将在响应中发送 S0 和 S1。如果不支持，服务器采用适当的行为作为响应，在 RTMP 规范中是终止连接。Version Send：版本已发送状态。在未初始化状态之后客户端和服务端都进入版本已发送状态。客户端等待接收 S1 包，服务端等待接收 C1 包。收到所等待的包后，客户端发送 C2 包，服务端发送 S2 包。之后状态进入发送确认状态。Ack Send：客户端和服务端等待接收 S2 和 C2 包，收到后进入握手完成状态。Handshake Done：握手完成， 客户端和服务端开始交换消息。分块

握手完成后，一个或多个块流可能会复用同一个连接，每个块流承载来自同一个消息流的同一类消息。每个块都有一个唯一的块流 ID，这些块通过网络进行传输。在传输过程中，必须一个块发送完毕之后再发送下一个块。在接收端，将所有块根据块中的块流 ID 组装成消息。

分块将上层协议的大消息分割成小的消息，保证大的低优先级消息（比如视频）不阻塞小的高优先级消息（比如音频或控制消息）。

分块还能降低消息发送的开销，它在块头中包含了压缩的原本需要在消息中所包含的信息。

块大小是可配置的，这个可以通过一个设置块大小控制消息进行设定修改。越大的块 CPU 使用率越低，但是在低带宽的情况下，大的写入会阻塞其他内容的写入。而小一些的块不适合高比特率的流。

块格式

每个块由块头和数据组成，块头包含 3 部分：基本头、消息头和扩展时间戳。

64-319 范围内的块流 ID 用 2 个字节来编码，块流 ID 为计算所得，公式为：第二个字节值 64：

timestamp (3 字节)：对于 0 类型的消息块，消息的绝对时间戳在这里发送。 如果时间戳大于或等于 16777215 (0xFFFFFF)，改字段值必须为 16777215，并且必须设置扩展时间戳来共同编码 32 位的时间戳。否则该字段就是完整的时间戳。message length (3 字节): 消息长度，类型 0 和类型 1 的块包含此字段，表示消息的长度。要注意的是，通常消息长度与块长度并不相同。块长度除了最后一个块之外，都与块最大长度相同。message type id (3 字节): 消息类型 id，类型 0 和类型 1 的块包含此字段，表示消息的类型。message stream id (4 字节): 消息流 ID，类型 0 的块包含此字段，表示消息流 ID。消息流 ID 以小字节序存储。通常，相同块流中的消息属于用一个消息流。虽然，不同的消息流复用相同的块流会导致消息头无法有效压缩，但是当一个消息流已关闭，准备打开另外一个消息流时，就可以通过发送一个新的 0 类型块来实现复用。

类型 1

1 类型的块消息头占用 7 个字节长度，不包含消息流 ID，该块沿用上一个消息的消息流 ID。对于传输大小可变消息的流（如多数视频格式），在发送第一个消息之后的每个消息都应该使用该类型格式。

timestamp delta (3 字节): 时间戳增量。类型 1 和类型 2 的块包含此字段，表示前一个块的 timestamp 字段和当前块 timestamp 间的差值。 如果时间戳增量大于或等于 16777215 (0xFFFFFF)，该字段必须为 16777215，并且必须设置扩展时间戳，来共同表示 32 位的时间戳增量，否则该字段值就是实际的时间戳增量。

类型 2

2 类型的块消息头占用 3 个字节长度，不包含消息流 ID 和消息长度，沿用上一个块的消息流 ID 和消息长度。对于传输固定大小消息的流（如音频和数据格式），在发送第一个消息之后的每一个消息都应该使用该类型格式。

下图展示该消息流以块流形式发送。从 3 类型块开始了数据传输优化，之后的块只附加了一个字节。

示例 2

该示例展示了一个超过 128 字节长度的消息，消息被分割成了数个块。

第一个块的头信息指明了消息总大小为 307 字节。

注意这两个示例，3 类型块可以在两种情况下使用。第一种情况是消息拆分成多个块，另一种情况是新消息复用上一个消息的所有头部内容。

协议控制消息

RTMP 块流用消息类型 1，2，3，5 和 6 来作为协议控制消息，这些消息包含 RTMP 块流协议所需要的信息。

这些协议控制消息必须用 0 作为消息流 ID (控制流 ID)，并在 ID 为 2 的块流中发送。协议控制消息收到后立即生效，它们的时间戳信息是被忽略的。

设置块大小

协议控制消息类型 1：设置块大小，用于通知另一端新的最大块大小。

最大块大小默认为 128 字节，客户端或服务端可以修改此值，并用该消息通知另一端。例如，假设一个客户端想要发送 131 字节的音频数据，而最大块大小为 128。在这种情况下，客户端可以向服务端发送该消息，通知它最大块大小被设置为了 131 字节。这样客户端只用一个块就可以发送这些音频数据。

最大块大小不能小于 1 字节，通常应该不低于 128 字节。每个方向上的最大块大小是独立的。

0 (1 位): 该位必须为 0.chunk size (31 位): 该字段以字节形式保存新的最大块大小，该值将用于后续的所有块的发送，直到收到新的通知。该值可取值范围为 1-2147483647 (0x7FFFFFFF)，但是所有大于 1677215 (0xFFFFFF) 的值都是视作是 16777215，因为任何块不可能比消息大，而消息长度不能大于 16777215 字节。终止消息

协议控制消息类型 2：终止消息，通知正在等待消息后续块的另一端，可以丢弃指定块流接收到的数据，块流 ID 为该消息的载荷。应用可能在关闭的时候发送该消息，用来表明后面的消息没有必要继续处理了。

Limit Type（限制类型）有以下值：

0 – Hard: 应该将输出带宽限制为指定视窗大小。1 – Soft: 应该将输出带宽限制为指定视窗大小和当前视窗大小中较小的值。2 – Dynamic: 如果上一个消息的限制类型为 Hard，则该消息同样为 Hard，否则抛弃该消息。RTMP 消息格式

虽然 RTMP 被设计成使用 RTMP 块流传输，但是它也可以使用其他传输协议来发送消息，在这种情况下 RTMP 消息的格式如下所示。值得一提的是，RTMP 块流协议和 RTMP 协议配合时，非常适合音视频应用，包括单播、一对多实时直播、视频点播和视频会议等。

格式

服务端和客户端通过在网络上发送 RTMP 消息实现之间的交互，消息包括音频、视频、数据等。

RTMP 消息包含两部分，消息头和有效负载。

RTMP 消息头

消息头包含以下信息：

Message Type: 消息类型，占用 1 个字节。1-6 的消息类型 ID 是为协议控制消息保留的。Length: 有效负载的字节数，占用 3 个字节。该字段是用大端序表示的。Timestamp: 时间戳，占用 4 个字节，用大端序表示。Message Stream Id: 消息流 ID，标识消息所使用的流，用大端序表示。

组合消息的消息流 ID 会覆盖其中子消息的消息流 ID。

组合消息的时间戳和其中第一个子消息的时间戳的差值，是用来将所有子消息的时间戳重整为流时间的位移量。位移量会加到每一个子消息的时间戳上来换算出正常的流时间。第一个子消息的时间戳应该与组合消息的时间戳相同，所以位移量应该为 0。

Back Pointer (反向指针) 包含前一个消息的长度（包括消息头），这样符合 flv 文件格式，可用于进行后退操作。

使用组合消息有以下好处：

块流协议中，一个块最多只能发送一个消息，这样就使用组合消息，加大块大小，从而降低发送的块数量。子消息在内存中连续存放，这样系统调用网络发送数据的性能更高。

用户控制消息事件

客户端或服务器通过该消息发送用户控制事件。

用户控制消息支持以下事件：

流开始（0）：服务端发送该事件，用来通知客户端一个流已经可以用来通讯了。默认情况下，该事件是在收到客户端连接指令并成功处理后发送的第一个事件。事件的数据使用 4 个字节来表示可用的流的 ID。流结束（1）：服务端发送该事件，用来通知客户端其在流中请求的数据已经结束了。如果没有额外的指令，将不会再发送任何数据，而客户端会丢弃之后从该流接收到的消息。事件数据使用 4 个字节来表示回放完成的流的 ID。流枯竭（2）：服务端发送该事件，用来通知客户端流中已经没有更多的数据了。如果服务端在一定时间后没有探测到更多数据，它就可以通知所有订阅该流的客户端，流已经枯竭。事件数据用 4 个字节来表示枯竭的流的 ID。设置缓冲区大小（3）：客户端发送该事件，用来告知服务端用来缓存流中数据的缓冲区大小 (单位毫秒)。该事件在服务端开始处理流数据之前发送。事件数据中，前 4 个字节用来表示流 ID，之后的 4 个字节用来表示缓冲区大小（单位毫秒）。流已录制（4）：服务端发送该事件，用来通知客户端指定流是一个录制流。事件数据用 4 个字节表示录制流的 ID。ping 请求（5）：服务端发送该事件，用来探测客户端是否处于可达状态。事件数据是一个 4 字节的时间戳，表示服务端分发该事件时的服务器本地时间。客户端收到后用 ping 响应回复服务端。ping 响应（6）：客户端用该事件回复服务端的 ping 请求，事件数据为收到的 ping 请求中携带的 4 字节的时间戳。指令类型

客户端和服务器交换 AMF 编码的指令。发送端发送一条指令消息，其中包含了指令名称、处理 ID、以及含有相关参数的指令对象。例如，连接指令消息包含了’app’ 参数，以告知服务器客户端希望连接的目标程序。接收端处理这条指令并回复含有同样处理 ID 的响应。回复的字符串可能为_result、_error 或方法名。如 verifyClient 或 contactExternalServer.

_result 或_error 的指令字符代表一条响应，处理 ID 则表明回复是针对哪条指令的，这在 IMAP 或其他协议中是完全相同的。指令字符串中的方法名表明发送端希望运行接收端上的一个方法。

指令消息可分为如下两类：

NetConnection：一个服务器和客户端之间连接的高层表现对象。NetStream：一个音频流、视频流及其他相关数据传输流，我们会发送如播放、暂停等指令来控制数据流动。

NetConnection 指令

NetConnection 管理着一个客户端程序和服务器之间的双向连接，除此之外，它还提供了对异步远程方法调用的支持。

下列指令可通过 NetConnection 进行发送：

ConnectCallCloseCreateStream

Connect

客户端发送 connect 指令至服务器端以请求连接至某一服务器程序实例。

指令结构如下：

音频编码：

视频编码：

对象编码：

指令执行流程：

指令执行的消息流如下：

客户端发送 connect 指令至服务器以请求连接至服务器端程序实例。在收到连接指令后，服务器端发送协议消息 ‘Window Acknowledgement Size’ 给客户端。同时，服务器端还会连接 connect 指令中提到的应用。服务器端发送协议消息‘Set Peer Bandwidth’至客户端。客户端成功处理‘Set Peer Bandwidth’后发送协议消息‘Window Acknowledgement Size’ 给服务器端。服务器端发送用户控制消息（StreamBegin）协议消息给客户端。服务器端发送指令消息以通知客户端连接状态（success/fail）。该指令中含有处理 ID (与 1 中收到相同)，该消息同时还制定了部分属性，如 Flash Media Server 版本（string）。除此之外，它还指定了连接响应相关的信息如 level (string)，code (string)，description (string)，object-encoding (number) 等。

Call

NetConnection 对象的 call 方法用于远程调用接收端上的程序。需要远程调用的程序名称通过一个参数传递给 call 指令。

发送指令结构如下：

响应指令结构如下：

NetStream 指令

基于 NetConnection 的客户端至服务器间连接，NetStream 定义了一条可以传递音频流、视频流以及消息流的通道。NetConnection 对象支持多个 NetStreams 以传输多个数据流。

客户端可在 NetStream 中发送下列指令至服务器：

PlayPlay2DeleteStreamCloseStreamReceiveAudioReceiveVideoPublishSeekPause

服务器端通过 “onStatus” 将 NetStream 的状态更新至客户端：

流程图如下：

指令执行期间的消息流如下:

客户端在接收到来自服务器的 createStream 指令的成功结果后发送 play 指令。在接收到 play 指令后，服务器发送协议数据来设置块大小。服务器发送一些另外一个协议数据 (用户控制)，在这个消息里包含事件 “StreamIsRecord” 和流 ID。这个消息的前 2 个字节是事件类型随后的 4 字节是流 ID。服务器向客户端发送另外一个协议消息 (用户控制)，这个消息指示了 “StreamBegin” 事件，表示流开始了。如果客户端向服务器发送的 play 指令成功执行了，服务器会发送 onStatus 指令消息包含 NetStream.Play.Start 或 NetStream.Play.Reset。仅当客户端发送的 play 指令中的设置了 reset 标志 NetStream.Play.Reset 才会被发送。如果播放的流不存在，服务器会在发送 onStatus 消息中包含 NetStream.Play.StreamNotFound。随后，服务器就发送客户端播放的音频和视频数据。

Play2

不同于 play 指令，play2 可以切换码率而不改变播放内容的时间轴。服务器为客户端可以在 play2 中请求的所有支持的码率维护多个字段。

客户端发送的指令结构如下：

DeleteStream

当 NetStream 对象将要被销毁时，它发送该 deleteStream 指令。

客户端发送的指令结构如下：

?如果 receiveVideo 指令发送带有 flase 的 bool flag，服务器不发送任何响应。如果这个标志被设置为 true，服务器应答 NetStream.Seek.Notify 和 NetStream.Play.Start 的状态消息。

Publish

客户端发送 publish 指令将已命名的流发布到服务器上。使用这个名称，任何客户端都可以播放此流，并接收已发布的音频、视频和数据消息。

客户端发送的指令结构如下：

发布媒体流元数据

这个例子描述了发布元数据的消息交换。