[RTMP协议]实时消息传输协议 (RTMP) 常识性介绍

        Adobe 公司的实时消息传输协议 (RTMP) 通过一个可靠地流传输提供了一个双向多通道消息服务，比如 TCP [RFC0793]，意图在通信端之间传递带有时间信息的视频、音频和数据消息流。实现通常对不同类型的消息分配不同的优先级，当运载能力有限时，这会影 响等待流传输的消息的次序。
        本文档将对实时流传输协议 (Real Time Messaging Protocol) 的语法和操作进行描述。
        1.1. 术语
        本文档中出现的关键字，"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 、"OPTIONAL"，都将在 [RFC2119] 中进行解释。
        2. 贡献者
        Rajesh Mallipeddi，Adobe Systems 原成员，起草了本文档原始规范，并提供大部分的原始内容。
        Mohit Srivastava，Adobe Systems 成员，促成了本规范的开发。
        3. 名词解释
        Payload (有效载荷)：包含于一个数据包中的数据，例如音频采样或者压缩的视频数据。payload 的格式和解释，超出了本文档的范围。
        Packet (数据包)：一个数据包由一个固定头和有效载荷数据构成。一些个底层协议可能会要求对数据包定义封装。
        Port (端口)："传输协议用以区分开指定一台主机的不同目的地的一个抽象。TCP/IP 使用小的正整数对端口进行标识。" OSI 传输层使用的运输选择器 (TSEL) 相当于端口。
        Transport address (传输地址)：用以识别传输层端点的网络地址和端口的组合，例如一个 IP 地址和一个 TCP 端口。数据包由一个源传输地址传送到一个目的传输地址。
        Message stream (消息流)：通信中消息流通的一个逻辑通道。
        Message stream ID (消息流 ID)：每个消息有一个关联的 ID，使用 ID 可以识别出流通中的消息流。
        Chunk (块)：消息的一段。消息在网络发送之前被拆分成很多小的部分。块可以确保端到端交付所有消息有序 timestamp，即使有很多不同的流。
        Chunk stream (块流)：通信中允许块流向一个特定方向的逻辑通道。块流可以从客户端流向服务器，也可以从服务器流向客户端。
        Chunk stream ID (块流 ID)：每个块有一个关联的 ID，使用 ID 可以识别出流通中的块流。
        Multiplexing (合成)：将独立的音频/视频数据合成为一个连续的音频/视频流的加工，这样可以同时发送几个视频和音频。
        DeMultiplexing (分解)：Multiplexing 的逆向处理，将交叉的音频和视频数据还原成原始音频和视频数据的格式。
        Remote Procedure Call (RPC 远程方法调用)：允许客户端或服务器调用对端的一个子程序或者程序的请求。
        Metadata (元数据)：关于数据的一个描述。一个电影的 metadata 包括电影标题、持续时间、创建时间等等。
        Application Instance (应用实例)：服务器上应用的实例，客户端可以连接这个实例并发送连接请求。
        Action Message Format (AMF 动作消息格式协议)：一个用于序列化 ActionScript 对象图的紧凑的二进制格式。AMF 有两个版本：AMF 0 [AMF0] 和 AMF 3 [AMF3]。
        4. 字节序、对齐和时间格式
        所有整数型属性以网络字节顺序传输，字节 0 代表第一个字节，零位是一个单词或字段最常用的有效位。字节序通常是大端排序。关于传输顺序的更多细节描述参考 IP 协议 [RFC0791]。除非另外注明，本文档中的数值常量都是十进制的 (以 10 为基础)。
        除非另有规定，RTMP 中的所有数据都是字节对准的；例如，一个十六位的属性可能会在一个奇字节偏移上。填充后，填充字节应该有零值。
        RTMP 中的 Timestamps 以一个整数形式给出，表示一个未指明的时间点。典型地，每个流会以一个为 0 的 timestamp 起始，但这不是必须的，只要双端能够就时间点达成一致。注意这意味着任意不同流 (尤其是来自不同主机的) 的同步需要 RTMP 之外的机制。
        因为 timestamp 的长度为 32 位，每隔 49 天 17 小时 2 分钟和 47.296 秒就要重来一次。因为允许流连续传输，有可能要多年，RTMP 应用在处理 timestamp 时应该使用序列码算法 [RFC1982]，并且能够处理无限循环。例如，一个应用假定所有相邻的 timestamp 都在 2^31 - 1 毫秒之内，因此 10000 在 4000000000 之后，而 3000000000 在 4000000000 之前。
        timestamp 也可以使用无符整数定义，相对于前面的 timestamp。timestamp 的长度可能会是 24 位或者 32 位。
        5. RTMP 块流
        本节介绍实时消息传输协议的块流 (RTMP 块流)。 它为上层多媒体流协议提供合并和打包的服务。
        当设计 RTMP 块流使用实时消息传输协议时，它可以处理任何发送消息流的协议。每个消息包含 timestamp 和 payload 类型标识。RTMP 块流和 RTMP 一起适合各种音频-视频应用，从一对一和一对多直播到点播服务，到互动会议应用。
        当使用可靠传输协议时，比如 TCP [RFC0793]，RTMP 块流能够对于多流提供所有消息可靠的 timestamp 有序端对端传输。RTMP 块流并不提供任何优先权或类似形式的控制，但是可以被上层协议用来提供这种优先级。例如，一个直播视频服务器可能会基于发送时间或者每个消息的确认时间丢 弃一个传输缓慢的客户端的视频消息以确保及时获取其音频消息。
        RTMP 块流包括其自身的带内协议控制信息，并且提供机制为上层协议植入用户控制消息。
        5.1 消息格式
        可以被分割为块以支持组合的消息的格式取决于上层协议。消息格式必须包含以下创建块所需的字段。
        Timestamp：消息的 timestamp。这个字段可以传输四个字节。
        Length：消息的有效负载长度。如果不能省略掉消息头，那它也被包括进这个长度。这个字段占用了块头的三个字节。
        Type Id：一些类型 ID 保留给协议控制消息使用。这些传播信息的消息由 RTMP 块流协议和上层协议共同处理。其他的所有类型 ID 可用于上层协议，它们被 RTMP 块流处理为不透明值。事实上，RTMP 块流中没有任何地方要把这些值当做类型使用；所有消息必须是同一类型，或者应用使用这一字段来区分同步跟踪，而不是类型。这一字段占用了块头的一个字节。
        Message Stream ID：message stream (消息流) ID 可以使任意值。合并到同一个块流的不同的消息流是根据各自的消息流 ID 进行分解。除此之外，对 RTMP 块流而言，这是一个不透明的值。这个字段以小端格式占用了块头的四个字节。

        5.2 握手

        一个 RTMP 连接以握手开始。RTMP 的握手不同于其他协议；RTMP 握手由三个固定长度的块组成，而不是像其他协议一样的带有报头的可变长度的块。
        客户端 (发起连接请求的终端) 和服务器端各自发送相同的三块。便于演示，当发送自客户端时这些块被指定为 C0、C1 和 C2；当发送自服务器端时这些块分别被指定为 S0、S1 和 S2。