实时消息协议- 流的分块 Adobe Systems Inc 实时消息协议-流的分块 版权声明： 版权（c）2009 Adobe 系统有限公司。全权所有。 摘要： 本备忘录描述实时消息协议块流。块流是一种应用层协议，主要用于通过一种合适的 传输层协议（例如 TCP）复用、打包多媒体数据流（音频，视频和交互数据） 。 目录： 1. 简介 1.1 术语 2. 定义 3. 字节序、对齐和时间格式 4. 消息格式 5. 握手 5.1 握手序列 5.2 C0 和 S0 格式 5.3 C1 和 S1 格式 5.4 C2 和 S2 格式 5.5 握手示意图 6. 块 6.1 块格式 6.1.1 块基本头 6.1.2 块消息头 6.1.2.1 类型 0 6.1.2.2 类型 1 6.1.2.3 类型 2 6.1.2.4 类型 3 6.1.3 扩展时间格式 6.2 示例 6.2.1 示例 1 6.2.2 示例 2 7. 协议控制消息 7.1 设置块的大小 7.2 关于消息 8. 参考 8.1 规范参考 8.2 信息参考 9. 确认（致谢）实时消息协议- 流的分块 Adobe Systems Inc 1. 简介 本文档规定实时消息协议块流（RTMP 块流） 。分块为更高层的多媒体流协议提供 复用和分组服务。 虽然 RTMP 块流是为协同 RTMP 协议工作而设计的，但是它任然可以处理任何发送 消息流的协议。每个消息包含时间戳和负载类型标志。RTMP 块流和 RTMP 共同适用于 各种形式的音视频应用，从点到点和点到多的实时直播，到 vod 服务，到交互式视频 会议。 当配合像TCP这样的可靠传输协议使用时，RTMP 块流保证跨流的所有消息按时间 戳序列一个接一个地传输。RTMP 块流不提供优先级或类似的控制，但是可以通过更高 层的协议提供类似的服务。例如，视频直播服务可以基于每个消息的发送时间和答复 时间选择丢弃视频消息，使慢的客户端能及时接受到音频消息。 RTM 块流包含自己的带内协议控制消息，并且提供了让更高层的协议嵌入用户控 制消息的机制。 1.1 术语 本文档中的关键词”必须” 、 ”一定不”、 ”要求”、 ” 可以”、 ” 不可以”、 ”应该” 、 ”不应该” 、 ” 建议” 、 ” 可能”和” 可选” 的解释参考文档BCP14RFC2119。 2. 定义 负载： 分组中所包含的数据。例如音频样本和压缩视频数据。负载格式和解释不在本文 档的描述范围之内。分组: 一个数据分组由固定的头和负载数据组成。一些底层协议可能需要定义分组的封 装。 端口: 在一个给定计算机中区分不同目标的抽象。在 TCP/IP 协议中用一个小的整数来表 示端口。OSI 中的传输选择器等同于端口的概念。 传输地址:用于表示一个传输层终端的网络地址和端口的组合。例如 IP 地址和 TCP 端口。分 组从源地址传输到目标地址。 消息流:允许消息流动的逻辑上的通讯通道。 消息流 ID:每个消息所关联的 ID ，用于区分其所在的消息流。 块:一个消息片段。消息通常在被放到网络上传输之前被分成小的部分并且被交错存 取。分块确保跨流的所有消息按时间戳顺序被不断的传输。 块流:允许块按照某一方向流动的逻辑上的通讯通道。块流可以从客户端流向服务端， 也可以从服务端流向客户端。 块流 ID:每个块所关联的用于区分其所在块流的 ID 。 复用:把分开的音视频数据整合到一个数据流，让多个音视频流可以同步地传输的过程。实时消息协议- 流的分块 Adobe Systems Inc 解复用:复用的反向过程。交互的音视频数据被收集成原始的音频数据和视频数据。 3. 字节序、对齐和时间格式所有完整的字段都是按网络字节序被承载的，即，零字节是第一个字节，零位是 一个字或字段中最显著的位。这种字节序就是所谓的”big-endian” 。这种传输顺序的详 细描述见STD5。除非另行说明，本文档中的数字都是十进制数。在没有特别说明的情况下 RTMP 块流中的所有数据都是按字节对齐的。例如，一个 16 位字段可能在奇数字节偏移的位置。在标有延拓的地方，延拓字节应赋予零值。RTMP 块流中的时间戳是用整数表示的，以毫秒为单位的相对时间，相对于一个未 规定的起始时间。一般，每个块流的时间戳都从 0 开始，但是只要通讯的双方用统一 的起始时间，可以不使用这种方法。要注意的是，这样跨多个块流（特别是不同主机 之间）的同步需要用另外的机制来实现。时间戳必须是单调递增的，并且是线性增长的。这样可以使应用程序处理同步，测 量带宽，注入检测和进行流控制。因为时间戳只有 32 位长，所以只能在 50 天以内循环。但是，因为流是可以不断的 运行的，潜在地可以多年才结束？，所以 RTMP 块流应用程序必须对减法和比较使用 模运算，并且能够处理这种回绕。只要通讯双方一致，任何合理的方法都可使用。例 如，一个应用程序可以假设，相邻的时间戳是 231 毫秒，那么 1000 在 4000000000 之后，3000000000 在 4000000000 之前。时间戳增量也是以毫秒为单位的无符号整数。时间戳增量可以是 24 位或 32 位长。 4. 消息格式(可以参考消息格式文档的第 4 节)消息格式依赖于上层协议，可以被分成多个块以支持复用。但是消息格式必须包含 下面这些创建块所必须的字段。时间戳： 消息时间戳，占 4 个字节。长度： 消息负载的长度，如果消息头无法被消减的话，应该包含在长度里，这个字段在 块头中占 3 个字节。类型 ID ：一些类型 ID 是为消息控制协议保留的。这些 ID 繁衍供 RTMP 块流协议和高层协议 使用的信息。所有其他的 ID 都用于更高层协议。RTMP 块流协议对这些 ID 做不透明处 理。事实上，RTMP 块流协议不需要用本字段的值来区分类型；所有消息可以是同类 型的，或者应用可以使用本字段来区分同步轨道而不是区分类型。本字段占一个字节。消息流 ID ：消息流 ID 可以是任何的值。被复用到相同的块流的消息流依靠其消息 ID 来解复用。 除此之外，对于 RTMP 块流协议来说，这个值是不透明的。这个值在块头中占 4 个字 节，并且使用小字节序。 5.握手一个 RTMP 连接以握手开始。这里的握手和其他协议的握手不一样。这里的握手由 三个固定大小的块组成，而不是可变大小的块加上头。客户端（发起连接的一方）和服务端各自发送三个相同的块。这些块如果是客户端 发送的话记为 C0，C1 和 C2 ，如果是服务端发送的话记为 S0，S1 和 S2。 5.1 握手队列 实时消息协议- 流的分块 Adobe Systems Inc握手开始于客户端发送 C0，C1 块。在发送 C2 之前客户端必须等待接收 S1 。在发送任何数据之前客户端必须等待接收 S2。 服务端在发送 S0 和 S1 之前必须等待接收 C0 ，也可以等待接收 C1 。服务端在发送 S2 之前必须等待接收 C1。服务端在发送任何数据之前必须等待接收 C2。 5.2 C0 和 S0 消息格式 C0 和 S0 是单独的一个字节 。下面是 C0 和 S0 包的字段说明。 版本：8 位 在 C0 中这个字段表示客户端要求的 RTMP 版本 。在 S0 中这个字段表示服务器 选择的 RTMP 版本。本规范所定义的版本是 3；0-2 是早期产品所用的，已被丢弃； 4-31 保留在未来使用 ；32-255 不允许使用 （为了区分其他以某一字符开始的文本 协议） 。如果服务无法识别客户端请求的版本，应该返回 3 。客户端可以选择减到 版本 3 或选择取消握手。 5.3 C1 和 S1 消息格式 C1 和 S1 消息有 1536 字节长，由下列字段组成。 时间：4 字节本字段包含时间戳。该时间戳应该是发送这个数据块的端点的后续块的时间起始 点。可以是 0，或其他的任何值。为了同步多个流，端点可能发送其块流的当前值。 零：4 字节 本字段必须是全零。 随机数据：1528 字节。 本字段可以包含任何值。因为每个端点必须用自己初始化的握手和对端初始化的 握手来区分身份，所以这个数据应有充分的随机性。但是并不需要加密安全的随机值， 或者动态值。5.4 C2 和 S2 消息格式 实时消息协议- 流的分块 Adobe Systems Inc C2 和 S2 消息有 1536 字节长。只是 S1 和 C1 的回复。本消息由下列字段组成。时间：4 字节本字段必须包含对等段发送的时间（对 C2 来说是 S1，对 S2 来说是 C1 ） 。 时间 2：4 字节本字段必须包含先前发送的并被对端读取的包的时间戳。 随机回复：1528 字节本字段必须包含对端发送的随机数据字段（对 C2 来说是 S1，对 S2 来说是 C1 ） 。 每个对等端可以用时间和时间 2 字段中的时间戳来快速地估计带宽和延迟。但这样做 可能并不实用。 5.5 握手示意图Figure 4 Pictorial Representation of Handshake下表描述握手中的状态机。状态 描述实时消息协议- 流的分块 Adobe Systems Inc 未初始化 在这个状态中发送双方的版本 。此时客户 端和服务端都未初始化。客户端在 C0 包中 发送版本号。如果服务端支持那个版本，则 发送 S0 和 S1 作为响应，否则，服务端采用 适当的行为作为响应。在 RTMP 规范中应终 止连接 。 版本已发送 在未初始化状态之后客户端和服务端都进入 版本已发送状态。客户端等待 S1 包，服务 端等待 C1 包。在接收到所等待的包后客户 端发送 C2 包，服务端发送 S2 包。进入发送 确认状态。 确认发送 客户端和服务端依次等待 S2 和 C2。 握手完成 客户端和服务端发送消息。 6. 分块握手之后，连接开始复用一个或多个块流。每个块流承载来自一个消息流的一类消 息。每个被创建的块都关联到一个唯一的块流 ID 。所有的块都通过网络传输。在传输过 程中，必须一个块发送完之后再发送下一个块。在接收端，每个块都根据块 ID 被收集成 消息。分块使高层协议的大消息分割成小的消息，保证大的低优先级消息不阻塞小的高优 先级消息。分块把原本应该消息中包含的信息压缩在块头中减少了小块消息发送的开销。块大小是可配置的。这个可以在 7.1 节中描述的块消息中完成。最大块是 65535 字 节，最小块是 128 字节。块越大 CPU 使用率越低，但是也导致大的写入，在低带宽下产生 其他内容的延迟。块大小对每个方向都保持独立。 6.1 块格式块由头和数据组成。块头由三部分组成：块基本头：1 到 3 字节 本字段包含块流 ID 和块类型。块类型决定编码的消息头的格式。长度取决于块流 ID。块流 ID 是可变长字段。 块消息头：0，3，7 或 11 字节。本字段编码要发送的消息的信息。本字段的长度，取决于块头中指定的块类型。 扩展时间戳：0 个或 4 字节 本字段必须在发送普通时间戳（普通时间戳是指块消息头中的时间戳）设置为 0xffffff 时发送，正常时间戳为其他值时都不应发送本值。当普通时间戳的值小于 0xffffff 时，本字段不用出现，而应当使用正常时间戳字段。 6.1.1 块基本头块基本头编码块流 ID 和块类型（在下图中用 fmt 表示） 。块类型决定编码消息头 的 格式。块基本头字段可能是 1，2 或 3 个字节。这取决于块流 ID。