rtmp协议

RTMP：Real Time Messaging Protocol 实时消息传送协议

字节序：大端

Message Format：

Timestamp：4 bytes

Length：3 bytes

Type ID：1 bytes

Message Stream ID：4 bytes 小端

Handshake

three static_sized chunks

client：C0 C1 C2

server：S0 S1 S2

simple handshake：

handshake sequence

握手开始于客户端发送C0、C1块

客户端在发送C2块之前必须等待直到S1块被接收

客户端在发送任何其他数据之前必须等待直到S2块被接收

服务器在发送S0、S1之前必须等待直到C0被接收或是C1被接收服务器在发送S2之前必须等待直到C1被接收

服务器在发送任何其他数据之前必须等待直到C2被接收

C0和S0格式

一个字节（8bits）

本版本是3

C1和S1格式

1536个字节

C2和S2格式

1536个字节，是C1和S1的回复响应

time：必须包含对等段发送的时间戳（对C2来说是S1，对S2来说是C1）time2：必须包含先前发送的被对端读取的包（S1或C1）的时间戳

handshake diagram

Complete handshake

Chunking

Chunk format

A header and data

+--------------+----------------+--------------------+----------+ | Basic Header | Message Header | Extended Timestamp | Chunk Data| +--------------+----------------+--------------------+----------+ | |

|<------------------- Chunk Header ----------------->|

Chunk Format

Basic header：1-3bytes，chunk stream ID and chunk type(fmt) 长度可变type depend on the format of the encoded message header

the length depend on the chunk stream ID

ID:3-65599,0\1\2 reserved

0:2bytes,ID range 64-319 (the second byte+64)

1:3bytes,ID range 64-65599(the third byte*256+the second byte+64)

2:low-level protocol

2-63:

64-319:

64-65599:

Cs id:6bits 表示2-63的块流ID，0和1表示本字段2或3字节版本

Fmt：2bits 表示4种types

Cs id-64：块流ID-64的值

Message header：0, 3, 7, or 11 bytes ，长度取决于chunk type（fmt）four different formats

Type 0：11bytes，块流开始和时间戳返回时必须有这种块

Timestamp：3bytes，消息的绝对时间戳在这里发送。如果时间戳大于或等于

16777215（16进制0x00ffffff），该值必须为16777215，并且扩展时间戳

必须出现。

Message length：3bytes，数据大小

Message type id：1bytes，数据类型

Message stream id：4bytes，流ID

Message type:

Type 1：7bytes，具有可变大小消息的流（many video

formats），在第一个消息之后的每个消息的第一个块应该使用这个格式。

Type 2:3bytes，具有固定大小消息的流（some audio and data formats），在第一个消息之后的每个消息的第一个块应该使用这个格式。

Type 3：块没有头。流ID，消息长度，时间戳都不出现。

如果第一个消息和第二个消息的时间增量与第一个消息的时间戳相同，那么0类型的块之后必须是3类型的块而，不需要类型2的块来注册时间增量。如果类型3的块在类型0的块之后，那么类型3的时间戳增量与0类型的块的时间戳相同。

Timestamp delta：3bytes，对于类型1的块和类型2的块，本字段表示先前块的时间戳与当前块的时间戳的差值。如果增量大于等于1677215（16进制0x00ffffff），这个值必须是16777215 ，并且扩展时间戳必须出现。否则这个值就是整个的增量。

Message length：3bytes，对于类型0或类型1的块本字段表示消息的长度。

注意，这个值通常与负载长度是不相同的。

Message type id：1bytes，对于0类型和1类型的块，本字段发送消息类型。

Message stream id：4bytes，对于0类型的块，本字段存储消息流ID Extended timestamp：0-4bytes，

只有当块消息头中的普通时间戳设置为0x00ffffff时，本字段才被传送。如果普通时间戳的值小于0x00ffffff，那么本字段一定不能出现。如果时间戳字段不出现本字段也一定不能出现。类型3的块一定不能含有本字段。

Chunk data：

默认长度为128bytes，块的大小可配置，最大65535bytes，最小128bytes，块越大CPU使用率越低，但是也导致大的写入，在低带宽下产生其他内容的延迟。

总结：

RTMP协议由包头和包体（数据）组成，包头可以是四种长度：12、8、4、1bytes，即basic header + message header。

Basic header：1bytes（官方文档即上面说可能不止1byte，但实际情况只用1byte 就够了，原因：chunk basic head的长度为1~3个字节，具体长度主要是依赖chunk stream ID的长度，所谓chunk stream ID是flash server用来管理连接的客户端的信令交互的标识，在red5的文档中称之为channel ID，协议最大支持65597个streamID 从3~65599。ID 0，1，2为协议保留，0代表ID是64~319（第二个byte + 64）；1代表chunk stream ID为64~65599（（第三个byte）* 256 + 第二个byte + 64）（小端表示）；2代表该消息为低层的协议（在RTMP协议中控制信令的chunk stream ID都是2）。3~63的chunk stream ID就是该byte的值。没有附加的字段来标识chunk stream streamID。在这里要指出的是虽然RTMP 的chunk stream ID理论是可以达到65599，但是目前使用的chunk stream ID 很少，2~7都是约定的，8是用来传输publish play等命令，其他的chunk stream ID目前好像没有使用，所以目前chunk basic head的长度一般为1个字节），由chunk type和chunk channel ID组成。Chunk type占据前两个bit，决定message header的大小，即type0，type1，type2，type3，分别为11,7,3,0bytes，它可以用掩码0xC0进行与运算。Chunk channel id占据后面6个bits，Stream ID和Channel ID对应关系为：

StreamID=(ChannelID-4)/5-1

其可以为以下内容：

02 ping和ByteRead通道

03 invoke通道，我们的connect() publish()和自字写的

NetConnection.Call() 数据都是在这个通道的

04 audio和vedio通道

05、06、07 服务器保留，经观察FMS2用这些channel也用来传送音频或

视频

在rtmp包中经常看见的0xC2，就表示type为type3，channel Id为2。

Message header：(11,7,3,0bytes)

Timestamp:3bytes

Length：3bytes，数据实际长度，可超过最大长度128bytes，如果超过128bytes，那么由多个后续RTMP封包组合，每个后续的RTMP封包头只占1bytes，一般以0xC？开头。

Type ID：1bytes

Stream ID：4bytes，little-endian,是音视频流的ID，如果TypeID!=0x08或!=0x09，那么streamID为0。

streamID与ChannelID之间计算公式为：

streamID=(channelID-4)/5+1;

前面说包头有几种长度，第一个长度是12bytes，包含了全部的头信息，第一个数据流也就是流的开始必须是这个长度。

第二种8bytes的包，没有了streamID，发这种包，对方就默认此streamID和上次相同，一个视频数据在第一个流之后都可以使这种格式，比如一个1M的视频，第一次发128bytes用12bytes的包，之后每次发的数据都应该用8bytes的包。当然如果每次都用12bytes也没有问题。

第三种为4bytes，只有chunk_type和时间戳，缺少的对方认为与之前的一样，实际应用中很难出现。

第四中就只有chunk_type一个byte。如果一次数据超过了长度（默认是128bytes），就要分块，第一个块是12bytes或者8bytes的，之后的块就是1byte。因为分的N 块，每一块的信息都是一样的，所以只需要告诉对方此次包的长度就行了。

RTMP message format

有两部分：

a header and payload（message data）

Message header：

Message type：1bytes，1-6用于protocol control message

Length：3bytes，payload的大小，大端

Timestamp：4bytes，大端

Message stream ID：3bytes，大端

Payload：message data

Protocol control message

Message stream ID 必须为0，chunk stream ID必须为2。

Message type ID为1、2、3、5、6。

Set chunk size（1）：

Default：128bytes

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| chunk size (31 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload for the …Set Chunk Size? protocol message

Valid size：1-2147483647(0x7FFFFFFF),但是message length为

3bytes，块大小<=消息大小，所以最大size为16777215(0xFFFFFF，2^24),

所以可以设置为128-16777215。

Abort message（2）：

Chunk stream id：要abort的ID号

Acknowledge（3）：

当receiving bytes=window size时，发送这个消息。Window size是sender 在没有从receiver接收到acknowledge时发送的最大字节数。服务器在建立连接后发送窗口大小。

Sequence number：到当前时间为止接收到的字节数

User control message（4）：

Window acknowledgement size（5）：

Set peer bandwidth（6）：

Command message

Type of message

Command message（20、AMF0,17、AMF3）

Data message（18,15）

Shared object message（19，16）：每个消息可以包含多个事件。

Event types

Audio message（8）

Video message（9）

Aggregate message（22）：

Format：即Aggregate Message format采用上面message format。

aggregate message的格式为

此处header0就相当于上面的header，message data就相当于上面的payload

Back pointer：前一个消息的大小（包含头）

User control message(4):

是协议控制消息的一种，格式跟协议控制消息中的一样。

Type of commands

Command message：command name、transaction ID、command object。

下面的类对象用于发送各种命令：

NetConnection：管理服务端和客户端之间的双路连接。另外，它还支持

异步远程方法调用。

Connect：客户端向服务器发送一个连接命令请求连接到服务应用实例。

命令执行过程中的消息流是：

1.客户端发送连接命令到服务端，请求与一个服务应用实例建立连接。

2.接收到连接命令后，服务端发送”window acknowledgement size”到客户端。服务端同时连接到连接命令中提到的应用。

3.服务端发送”set peer bandwidth”协议消息到客户端。

4.在处理完”set peer bandwidth”消息后，客户端发送”window acknowledgement size”消息到服务端。

5.服务端发送用户控制消息中的流开始消息到客户端。

6.服务端发送结果命令消息通知客户端连接状态。该命令指定传输ID（对于连接命令总是1）。同时还指定一些属性，例如，Flash media server 版本（字符串），能力（数字），以及其他的连接信息，例如，层（字符串），代码（字符串），描述（字符串），对象编码（数字）等。

Call：对象的调用方法在接收端运行远程过程调用。远程方法的名作为调用命令的参数。

Close：

CreateStream：

客户端发送本命令到服务端创建一个消息通讯的逻辑通道。音频，视频和元数据的发布是由创建流命令建立的流通道承载的。

NetConnection本身是默认的流通道，具有流ID 0 。协议和一少部分命令消息，包括创建流，就使用默认的通讯通道。

客户端到命令端的命令结构：

NetStream：基于连接客户端和服务端的NetConnection对象的，可以使

音频流，视频流和数据消息传输的通道。

客户端到服务器的命令：

Play：

客户端发送本命令到服务端播放一个流。使用本命令多次也可以创建一个播放列表。如果想创建一个可以在不同的直播流或录制流间切换的动态播放列表，可以多次使用播放命令，并且将重设设为假。相反，如果想立即播放一个流。

清楚队列中正在等待的其它流，将重设设为真。

响应状态消息。

执行命令的消息流：

1. 客户端从服务端接收到流创建成功消息，发送play命令到服务端。

2. 接收到播放命令后，服务端发送协议消息设置块大小。

3. 服务端发送另一个协议消息（用户控制消息），并且在消息中指定事件”streamisrecorded”和流ID。消息承载的头2个字，为事件类型，后4个字节为流ID。

4.服务端发送事件”streambegin”的协议消息（用户控制），告知客户端流ID。

5. 服务端发送响应状态命令消息NetStream.Play.Start&NetStream.Play.reset，如果客户端发送的播放命令成功的话。只有当客户端发送的播放命令设置了reset命令的条件下，服务端才发送NetStream.Play.reset消息。如果要发送的流没有找的话，服务端发送NetStream.Play.StreamNotFound消息。

在此之后服务端发送客户端要播放的音频和视频数据。

Play2：

和play命令不同，play2命令可以切换到不同的码率，而不用改变已经播放的内容的时间线。服务端对play2命令可以请求的多个码率维护多个文件。从客户端到服务端的命令结构如下：

命令的消息流如下所示

deleteStream：

从客户端到服务端的命令结构如下：

服务端不返回任何响应。

closeStream：

receiveAudio：

从客户端到服务端的命令结构如下：

receiveVideo：

从客户端到服务端的命令结构如下：

服务端不返回任何响应。

publish：

客户端发送一个发布命令，发布一个命名流到服务端。使用这个名字，任何客户端可以播放该流并且接收音频，视频，和数据消息。

从客户端到服务端的命令如下：