RTMP协议规范1.0

RTMP协议规范1.0

译注

本文档主要翻译于http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf。

绝大部分使用直译，小部分使用意译。专有名词基本不翻译，既保留规范的原意，又不会感觉翻译起来怪怪的。

1. Introduction

Adobe’s Real Time Messaging Protocol (RTMP)通过一个可靠的流传输通道提供双向的消息复用服务，流传输通道类似于TCP [RFC0793]，目的是在通信双方之间并行传输带有关联时间信息的音视频流和数据消息。实现通常按不同类型的消息分配不同的优先级，从而在传输带宽受限时可以影响消息在底层流传输通道的入队顺序。

本文档描述了实时消息传递协议的语法和操作。

1.1. Terminology

本文档中的关键词，"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、

"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"和"OPTIONAL"，都在[RFC2119]中解释描述。

2. Contributors

Rajesh Mallipeddi，Adobe System原成员，起草了本文档原始规范，并提供大部分的原始内容。

Mohit Srivastava，Adobe System成员，推动了本规范的发展。

3. Definitions

Payload：包含在一个包中的数据，比如音频采样数据或者视频压缩数据。有效载荷的格式和解释超出了本文档的范围。

Packet：一个数据包由固定头header和payload数据组成。一些底层的协议可能需要定义该数据包的封装。

Port：传输协议用来区分在一个给定的主机内的多个目的地的抽象。TCP/IP协议使用小正整数来识别端口。OSI传输层使用的传输选择器（TSEL）相当于端口。

Transport address：网络地址和端口的组合用来识别一个传输层级别的端点，比如一个IP地址和TCP端口。包从源Transport address传输到目标的Transport address。

Message stream：消息流的逻辑传输通道。

Message stream ID：每个消息都有一个与它相关联的ID，以确定它的流在哪个消息流中。

Chunk：一段消息。消息被拆分成小的部分并且它们在网络发出去之前被转换。

Chunk stream：允许在一个特定方向上chunk流动的通信的逻辑通道。chunk stream可以从客户端传输到服务器或者反过来传输。

Chunk stream ID：每一块chunk都有一个与它关联的ID，以标识它所在的chunk stream。

Multiplexing：使单独的音频/视频数据转换成一个连贯的音频/视频流的过程，使得有可能同时传输多个视频和音频。

DeMultiplexing：复用的反向过程，其中交错的音频和视频数据被组装成原始的音频和视频数据。

Remote Procedure Call (RPC)：允许客户端或服务器在对等端调用子程序或过程的请求。

Metadata：关于数据的描述。视频的元数据包括视频名称、持续时间、创作日期等。

Application Instance：服务器上的应用程序实例，客户端连接通过它来发送连接请求。

Action Message Format (AMF)：一个紧凑的二进制格式，用于序列化的ActionScript对象图。AMF有两种版本：AMF 0 [AMF0]和AMF 3 [AMF3]。

4. Byte Order, Alignment, and Time Format

所有的整型字段都使用网络字节序传输，字节0为第一个字节，第0位在一个字或字段中是最重要的位。这种字节顺序俗称为大端模式。这种传输顺序在IP协议[RFC0791]中详细描述。如果没有另外说明，本文档中的数字常量都是十进制。

除非另有规定，RTMP的所有数据都是字节对齐的；例如，一个16位的字段可能在一个奇数的字节偏移上。该位置如果指定填充，则填充字节值应该为零。

 时间戳在RTMP是作为一个相对于未知时期的毫秒整数。通常，每个流将以时间戳0作为开始，但这不是必需的，只要两端在时间基准能达成一致即可。注意，这意味着任何在多个流的同步（尤其是独立的主机）需要一些RTMP之外的机制协助。

因为时间戳是32位长，他们每过49天，17小时，2分钟，47.296秒就会轮转。因为数据流允许连续地，甚至可能多年不断地运行，一个RTMP应用在处理时间戳时应该使用序列号算法[RFC1982]，并且应该能够环绕式处理。 例如，一个应用程序假定所有相邻的时间戳在2 ^ 31 - 1毫秒内都是彼此相邻的，所以10000在4000000000后面，3000000000在4000000000的前面。

相对之前提到的时间戳，时间戳增量也可以表示为无符号整数的毫秒。时间戳增量可能是24或32位长。

5. RTMP Chunk Stream

本节详述实时消息协议块流（RTMP流块）。它为更高层次的多媒体流协议提供了复用和打包服务。

虽然RTMP块流设计工作于实时消息协议（第6节），但它可以处理任何发送一个消息流的协议。每个消息包含时间戳和payload类型识别。RTMP Chunk Stream和RTMP是适合多种音视频应用，包括一对一和一对多的直播点播服务，交互式视频会议应用。

当使用一个可靠的传输协议如TCP [RFC0793]，RTMP Chunk Stream提供有保障的，按时间戳顺序的，端到端的，跨多个流的所有消息传输。RTMP Chunk Stream不提供任何优先级控制或类似的形式，但可以通过更高级别的协议提供这样的优先级顺序。例如，基于每一个消息的发送或确认时间，一个实时视频服务器可能会选择放弃一个缓慢的客户端视频消息，以确保音频消息是及时收到的。

RTMP Chunk Stream包括自带的协议控制信息，并且还为更高级别的协议嵌入用户控制消息提供了一种机制。

5.1. Message Format

消息可以分割成多个chunk的格式，以支持取决于一个更高级别协议的复用。然而，消息格式应该包含用于创建chunk的以下字段。

Timestamp：消息的时间戳。这个字段可以传输4个字节。

Length：消息payload的长度。如果消息头不能省略，它应该包括在该长度中。此字段在chunk header中占用3个字节。

Type Id：一系列的类型ID被保留用于协议控制消息。这些传播信息的消息通过RTMP Chunk Stream协议和高层协议处理。所有其他类型的ID对高级别的协议是可用的，并被RTMP Chunk Stream视为不透明数值。事实上，在RTMP Chunk Stream中没有要求这些值被用来作为一个类型；所有（非协议）消息可能是同一类型，或应用程序可以使用此字段来区分同步轨道而不是类型。此字段占用chunk header中的1个字节。

Message Stream ID：消息流ID可以是任意的值。同一Chunk Stream上的不同的多路复用消息流是基于它们的消息流ID进行多路解码的。除此之外，据RTMP Chunk Stream而言，这是一个不透明的值。这个字段以小端格式在chunk header中占用4个字节。

5.2. Handshake

RTMP连接以握手为开始。握手不同于协议的其余部分，它由三个静态大小的chunk，而不是由可变大小的带有头的chunk组成。

客户端（已启动连接的端点）和服务器每方都分别发送相同的三个chunk。为了方便表达，当由客户端发送时，这些chunk将被命名为C0，C1和C2；当由服务器发送时，它们被命名为S0，S1，S2。

5.2.1. Handshake Sequence

握手开始，客户端发送C0，C1 chunk。

客户端必须等到S1收到之后才能发送C2。

客户端必须等到S2收到之后才能发送其他数据。

 

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

5.2.2. C0 and S0 Format

C0和S0包是一个单字节，视为一个单一的8位整数字段：

 

以下是C0/S0包的字段：

Version（8位）：在C0，此字段标识客户端所请求的RTMP协议版本。在S0，此字段标识服务器选择的RTMP协议版本。本规范定义的版本号为3。值0-2由先前专有产品使用，现已弃用；4-31留待将来实现；32-255不允许使用（以区分RTMP和文本协议，因为它总是以一个可打印字符为开始）。当识别不出客户端请求的版本时，服务器应该响应版本号3。客户端可能会选择降级到版本3，或放弃握手。

5.2.3. C1 and S1 Format

C1和S1包都是1536个字节长，包括以下字段：

 

Time （4字节）：本字段包含一个时间戳，这应该作为未来从这个端点发出的所有块的时间基准。这可能是0，或一些任意的值。为了同步多个chunkstream，此端点可能要发送其他chunkstream的时间戳的当前值。

Zero（4个字节）：这个字段必须都是0。

Random data （1528个字节）：此字段可以包含任何任意值。由于每个端点必须区分它发起的握手的应答和对端发起的握手，这个数据应该发送足够随机的东西。但不需要加密的安全性，甚至不需要动态值。

5.2.4. C2 and S2 Format

C2和S2包都是1536个字节长，几乎是S1和C1的复制（分别地），它们包括以下字段：

 

Time（4个字节）：该字段必须包含对方包内的发送时间戳，它分别在S1（对于C2）或C1（对于S2）。

Time2（4个字节）：该字段必须包含对方前面的包（S1或C1）被读取的时间戳。

Random echo（1528个字节）：该字段必须包含对方发送的包（S1或C1）的随机数字段，分别在S1（对于C2）和C1（对于S2）。每个端都可以使用time和time2字段与当前时间戳作为连接的带宽和/或延迟的快速评估，但这不太可能有用。

5.2.5. Handshake Diagram

下面介绍握手图中所提到的状态：

Uninitialized：协议版本号在这个阶段中发送。客户端和服务器都是未初始化。该客户端在C0包发送协议版本号。如果服务器支持该版本，它将应答S0和S1。如果没有，服务器响采取适当的行为应答。在RTMP，这个动作是终止连接。

Version Sent：在未初始化状态之后，客户端和服务器都处在发送版本号的状态。客户端正在等待包S1，而服务器等待包C1。在收到期待的包之后，客户端发送数据包C2而服务器发送数据包S2。然后状态就变成Ack Sent。

Ack Sent：客户端和服务端分别等待S2和C2。

Handshake Done：客户端和服务器可以交换消息的状态。

5.3. Chunking

在握手之后，连接多路复用一个或多个chunk stream。每个chunk stream都从一个消息流中传送一个类型的消息。创建的每个chunk都有一个与它关联的唯一标识，称为块流标识（