Rtmp协议中文介绍.doc

RTMP（real time messaging protocol）协议
1， 介绍
这篇文档详细说明了RTMP消息块流，它位高层多媒体流协议提供多路技术和包服务
RTMP消息块流是为RTMP协议设计的，他可以处理任何传送消息流的协议，每一个消息包含时间戳合有效负载类型标示，RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。
当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。
RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。
2.定义
有效负载：
包含在包中的数据，就像音频样本或者压缩的视频数据。
包：
一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。
端口：
在TCP/ＩP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于OSI传输层的传输选择（TSEL）就是端口。
传输地址：
网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。
消息流：
一个通信的逻辑通道，允许消息流通。
消息流ID：
每一个消息拥有一个分配的ID识别跟随的消息流。
消息块：
消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。
消息块流：
一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。
消息块流ID：
每一个消息块有一个分配的ID用于识别更随的消息块流。
复合技术：
把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。
逆复合技术：
复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据
3． 字节顺序，列队和时间格式
所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。
所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）.
在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特别是分散的主机）在RTMP消息块流之外需要一些而外的机制。
时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。
因为时间戳一般是只有32字节的长度，他们周期小于50天，因为六流是允许不停地流动的，最终可以运行几年，一个RTMP消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致，一个应用可以假设，例如，所有相近的时间戳在2的31次方以内，所以10000在4000000000后面，3000000000在4000000000前面。
时间戳delta作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta可以是24字节或者是32字节的长度。
4． 消息格式
一个消息的格式可以分裂成消息块以支持复用，依靠高层协议，消息格式应该包含创造消息块的必须字段。
时间戳：
消息的时间戳，这个字段可以传输4个字节。
长度：
消息的有效负载的长度，如果消息头不能被省略，他应该包含在长度中，这个字段在消息块包头中占有3个字节。
类型ID：
协议控制消息的类型字段的范围是被保留的，这些传播信息的消息被RTMP消息块和高层协议处理，所有其他的类型ID可被高层协议使用，被RTMP消息块当做不透明的值，事实上，在RTMP消息块中需要这些值当做类型的是没有的，所有的消息可以成为通一种类型，或者应用程序用这个字段区分同步迹象而不是类型，这个字段占用1个字节。
消息流ID:
消息流ID可以是任意值，不同的消息复合依靠的同样的消息块流是基于他们的消息流ID被逆复合而成的，在此之上，直到RTMP消息块被关注，这是一个不透明的值，这个字段在包头中占用4个字节。
5． 握手
一个RTMP通信以握手开始，握手不像其他的协议，他包含三个固定长度的消息块。
客户（初始化通信的终端）和服务器每放发送同样的三个消息块，说明一下，被客户段发送的消息块被指定为C0，C1，C2，被服务器端发送的消息被指定为S0，S1，S2。
5.1．握手的顺序
握手以客户端发送C0和C1消息块位开始，客户端必须等到S1到达在发送C2。客户端必须等到S2接收到才可以发送其他的数据；服务端必须等到C0到达才发送S0和S1，在C1之后也会等待。服务端必须等到C1到达才发送S2，服务端必须等到C2到达后才发送其他数据。
5.2．C0和S0格式
C0也S0包长8个字节

版本：8比特
在C0中，这个字段识别客户端需求的RTMP的版本，在S0中，这个字段识别服务器端选择的RTMP的版本，被定义的是版本3，0到2是被早前的版本使用的，4到31保留被用作未来的用途，32到255还没有被允许。不能区分客户的请求的版本的服务应该以3返回，客户端或许会选择3一下的版本，或者放弃握手。
5.3．C1和S1的格式：
C1和S1的数据包有1536个字节长，由以下几个字段组成。

时间：4个字节
这个字段包含时间戳，被当做以后消息块从终端发送的时间点，也许是0，或者一些任意的值，用来同步多重的消息块流，终端或许希望发送其他消息块流的时间戳的当前值。
0：4各个字节
这个字段必须全0。
随即数据：1528个字节
这个字段可以包含任何任意的值，因为每个终端必须区分自己初始化的握手的返回数据和对方初始化的握手的返回数据，这个数据应该发送一些随机数。但是没有必要密码保护随机数和动态值。
5.4．C2和S2的格式
C2和S2数据吧有1536字节长度，近似S1和C1的回声，由一下几个字段组成。

时间：4个字节
这个字段必须包含由每方发送的S1（对应C2）或者C1（对应S2）的时间戳.
时间2：4个字节
这个字段必须包含先前的由每一方发送数据包（S1或者C1）被读到的时间戳。
随机返回：1528个字节
这个字段必须包含在每方发送的S1（对应C2）或者S2（对应C1）的随机数据字段。每一方可以利用时间和时间2字段和当前时间戳组成作为连接的带宽或者延迟的评估。但是似乎没有用。
5.5．握手过程

下面的表格表述了提到了在握手阶段的状态
阶段
描述
未初始化
协议版本在这个阶段中被发送，客户端个服务端没有初始化，客户端在C0中发送协议版本，如果服务端支持版本，就在回应中发送S0和S1，如果不能，服务端通过适当的行为进行恢复，在RTMP中，这个行为是连接结束
版本发送
在未初始化阶段以后客户端个服务端在版本发送阶段，客户端等待S1包，服务端等待C1包，当接收到想要的包，客户端发送C2，服务端发送S2，此时阶段变成了ACK的发送。
ACK发送
客户端和服务端分别等待S2和C2
握手完成

客户端和服务交换消息。
6.消息分块
在握手以后，连接复合一个或者多个消息块，每个消息块流负载一个消息流中的类型，每一个消息块的创造有一个唯一分配的ID，被称为消息块流ID，消息块流在网络上传输。传输的时候每一个消息块在下一个消息块之前必须完全被发送，当接收结束，消息块基于消息块流ID被组装成消息。
消息分块允许高层协议的大的消息被分割成小的消息，例如，阻止大的低优先级消息模块化位高优先级的消息。
消息分块也允许小的消息被传送时带有小的包头，消息块的包头包含了信息的压缩表示，另外这下信息必须在消息自身中包含。
6.1．消息块格式：
每一个消息块有包头和数据组成，包头自身可以被分割成三个部分，
消息块的基本头：1到3个字节
这个字段编码了消息块流的ID和消息块的类型，消息块类型决定了消息包头的编码格式，长度完全取决于可变长的消息块流ID。
消息块消息头：0，3，7，或者11个字节
这个字段编码正在传送的消息的信息，长度可以利用在消息块头中详细的消息块类型来决定。
扩展时间戳：0或者4个字节
这个字段必须在普通时间戳被设置为0xf f f f f f时发送，在普通时间戳被设置成任何其他时不能不能传送。所以对于值比0xf f f f f f小的，普通时间戳字段应该用在扩展时间戳没有被呈现的案例中。对于值大于或者等于0xf f f f f f普通时间戳不能被利用，不ixuba值设置成0xf f f f f f，扩展时间戳要被发送。
6.1.1．消息块基本头：
消息块基本时间头对消息块流的ID和消息块的类型进行编码，（在下面的图表中用fmt表示），消息块类型决定了编码的消息头的格式，消息块基本头字段可以是１，２，或者３个字节长，决定于消息块流ＩＤ。
协议支持超过６５５９７个流，ＩＤ范围3-65599，ID 0，1和2是被保留的，值0代表了在64到319的ID，值1代表了在64到65599的ID，值2代表了底层协议消息。对于流ID没有额外增加的字节表示，值3到63表示完成的流ID，没有额外的字节用来表示。
在消息块基本头中0-5比特(最不重要的)代表了消息块流ID
消息块流ID 2-63可以被编码成这个字段的一个字节的版本号。

消息块流ID 64到319在这个字段中可以被编码成2个字节的版本号（第2个字节加64）。
消息块流ID 64到65599在这个字段中可以被编码成3个字节的版本号（第三个字节*256+第二个字节+64）。

Cs id：6比特
这个字段包含了消息块流ID，值从2到63，值0和1用于代表这个字段的2个或者3个字节的版本号。
Fmt：2比特
这个字段标示了一个或者4个被消息块消息头使用的格式。
Cs id -64：8或者6个比特
这个字段包含了消息块流ID减64，例如ID365在CS id段用1表示，在cs id -64段用301表示。
值为64到319的消息块流ID可以被2字节或者3字节的版本号来表示。
6.1.2．消息块消息头
在消息块消息头中有四种不同的个格式，由消息块基本头的fmt字段选择。
一次执行应该使用最简洁的表达方式表示每一个消息块消息头。
6.1.2.1．类型0：
类型0的消息块有11个字节长们这个类型必须在消息块流开始时使用，只要消息流的时间戳回溯。
时间戳（timestamp）：3个字节
对于类型0的消息块，消息的完全的时间戳放在这里，如果时间戳比16777215大或者相等（16精制0x00ffffff），这个值必须是16777215，扩展的时间戳头被发送，另外，这个值必须是完整的时间戳。
6.1.2.2．类型1
类型1的消息块有7个字节长，消息流ID没有被包含，这个消息块得到和先前消息块同样的流ID，带有可变长的消息的流（例如许多视频格式）在类型0消息块后应该使用这种格式作为每一个消息的第一个消息块。

6.1.2.3．类型2
类型2消息块有3个字节长，流ID和消息长度都没有被包含，这个消息块和之前的消息块有相同流ID和消息长度，带有不变长的消息的流（例如一些音频格式）在类型0消息块后应该利用这种格式作为每一个消息的第一个消息块

6.1.2.4．类型3
类型3 的消息块没有头，流ID，消息长度时间戳delta，这个类型的消息块在之前的消息块中取值，当单一的消息被分裂成消息块，所有的消息块除了第一个，应该使用这种类型，流由同样大小的消息组成。

时间戳delta（timestamp delta）：3个字节
对于类型1和类型2的消息块，先前的消息块的时间戳和当前的消息块的时间戳的不同点可以在这里看到，如果delta的值比16777215大或者相同，这个值必须是16777215，扩展的时间戳被呈现，另外，这和值必须是完整的delta。
消息长度（message length）：3个字节
对于类型0和类型1的消息块，消息的长度会出现在这里。注意这一般和消息块有效负载长度是不一样的。消息块的有效负载长度是出了最后一个消息块的所有消息块的最大的长度。
消息类型 id（message type id）：一个字节
对于类型0和类型1的消息块，消息的类型被表示在这里。
消息流ID（message stream id）：4个字节
对于类型0的消息块，消息流ID会被储存，消息流ID在很小的比特中被存储，代表性的，所有的相同消息块流的消息来自同一个消息流。然而使把分散的消息流复合成同一个消息块流成为可能，就不用所有的头压缩。然而，如果一个消息流被关，另一个更随的是开着的，就没有理由通过发送一个新的类型0的消息块让一个存在的消息块流不能再生。
6.1.3．扩展时间戳（extend timestamp）：
当消息头中的普通的时间戳是0x00ffffff这个字段就会被传送，如果普通时间戳的值小于0x00ffffff，这个字段就不会被呈现，如果时间戳字段没有被呈现这个字段不能被呈现，类型3的消息块没有这个字段。如果这个字段被传送会在消息块头之后，消息块数据之前被立刻定位。

Chunk format
6.2.1．例1：例一给出一个简单的音频消息流，这个例子示范了信息的冗余。

下一个表格展示了消息块在流中被创造，从消息3向前，数据的传输是最优化的，每个消息只有1个字节

6.2.2．例二：例二举例说明一个很长的消息被分割成很多消息块

这里是分割出来的消息块

消息块1的包头数据详细介绍了307个字节的消息的全部。注意这两个例子，类型3消息块可以有用作两个不同的方式，第一种是指定一则消息的延续，第二种是指定新消息的开始，这个新消息可以从已经存在的数据中衍生出来。
7．协议控制消息
Rtmp消息块流支持一些协议控制消息，这些消息包含RTMP消息块流协议需求的信息，不会用于高层的传播，现有两种协议消息使用在RTMP消息块流中，一个协议消息用来设置消息块大小，另外一种用于中断消息，由于没残余的消息块没有被利用。
协议控制消息应该有消息流ID 0（被称为控制流）和消息块流ID 2，带有最高的优先级被发送。每一个协议控制消息类型有一个固定大小的负载，通常在一个单一的消息块中被发送。
7.1．设置消息块大小：
协议控制消息1，设置消息块大小，用来通知对方新的最大的消息块大小。
消息块的大小可以被设置成一个默认的值，但是客户端或者服务端可以改变这个值，可以给对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成131字节，那么客户端就可以用一个消息块发送音频数据。
最大的消息块大小可以是65536个字节，消息块的大小在每一个方向上是维持不变的。
7.2．中断消息：
这个协议控制消息用来通知对方如果他等待消息块完成一个消息，然后丢弃部分收到的消息。对方受到消息块流ID作为这个协议消息的有效负载。一个应用程序为了表示未来的消息处理过程是不需要的时候或许会送这个消息。

RTMP消息格式
1.介绍：
这段文字详细介绍了RTMP，详细介绍了在网络上使用底层传输协议的实体调动的消息的格式。RTMP是设计和RTMP消息块流协议一起工作的，它可以利用任何其他的传输协议发送消息，RTMP消息块协议和RTMP一起适用于多样性的音视频应用程序，从一对一，一对多的向视频点播服务器的直接广播到交互式的回忆应用程序。
2.定义：
消息流：
一个通信的逻辑通道，允许消息流通。
消息流ID：
每一个消息拥有一个分配的ID识别跟随的消息流。
有效负载：
包含在数据包中的数据，例如音频样本或者压缩的视频数据。
数据包：
一个数据包由固定的包头和有效负载数据组成，一些底层的协议或许会需要定义的数据包来封装。
3. 字节顺序，列队和时间格式
所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。
所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）.
在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特别是分散的主机）在RTMP消息块流之外需要一些而外的机制。
时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。
因为时间戳一般是只有32字节的长度，他们周期小于50天，因为六流是允许不停地流动的，最终可以运行几年，一个RTMP消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致，一个应用可以假设，例如，所有相近的时间戳在2的31次方以内，所以10000在4000000000后面，3000000000在4000000000前面。
时间戳delta作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta可以是24字节或者是32字节的长度。
4.RTMP消息格式：
服务端和客户端在网路上发送发送RTMP消息给彼此，消息尅包含音频，视频，数据或者其他消息。
RTMP消息包含两个部分，包头和有效负载。
消息头：
消息包头包含以下：
消息类型：
一个字节的字段用来表示消息类型。1-7类型范围内的ID是被保留用于协议控制消息。
长度：
3个字节的字段用来表示有效负载的长度。
时间戳：
四个字节的长度包含了消息的时间戳，这四个字节被包在一个大比特序列中。
消息流ID：
三个字节的字段标示消息的流，这些字段被设置在一个大比特格式中。

消息有效负载：
有效负载是包含在消息中的实际数据，例如：它可以是一些音频样本或者压缩的视频数据。
协议控制消息：
RTMP位协议控制消息保留了0-7的类型ID，这些消息包含RTMP消息块流协议或者RTMP本生需要的信息。ID是1和2的协议消息被保留用作RTMP消息块流协议的使用，ID是3-6的协议消息被保留用作RTMP的使用，ID是7的协议消息被用在边缘服务和原电服务之间。
协议控制消息必须有消息流ID0（称为控制流）和消息块流ID2，发送时带有最高优先级。
5.设置消息块大小
协议控制消息1，设置消息块大小，用来通知对方新的可供利用的最大的消息块的大小。
消息块大小的值可以负载4个字节的消息负载。消息块的大小可以被设置成一个默认的值，但是客户端或者服务端可以改变这个值，可以给对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成131字节，那么客户端就可以用一个消息块发送音频数据。
最大的消息块大小可以是65536个字节，消息块的大小在服务端与客户端的通信以及客户端到服务端的通信是维持不变的。

中断消息：
协议控制消息2，中断消息，用来向通知对方是否在等待消息块完成一则消息，然后丢弃部分接收到的消息，放弃消息的处理过程，对方接收到要被丢弃的消息的消息块流ID作为协议消息的有效负载，这个消息在发送方已经发送部分消息后发送，但是想要告诉接收方余下的消息不用发送。

消息块流ID（chunk stream id）：32字节
这个字段持有要被丢弃的消息的消息块流ID。
确认（ACK）：
客户端或者服务端当接收到的字节和窗口大小一样时发送确认给对方，窗口大小是发送方发送的在没有从接收方收到确认之前的最大字节数，服务端在应用程序接通后给客户端发送窗口大小，这个消息指定了序号，就是目前为止收到的字节数。

序号（sequence number）：32比特
这个字段是有到目前为止收到的字节的数量。
5.4.用户控制
客户端或者服务端发送这个消息用来通知对方用户控制事件，这个消息负载事件类型和事件数据，
头两个字节用来标示事件类型，事件数据跟随在事件类型后面，事件数据字段的大小事可变的。
5.5 窗口确认大小
客户端或者服务端在发送确认时发送这个消息来告知对方使用的窗口大小。例如：一个服务端期望在服务端发送的字节数和窗口大小一样时每时每刻都收到客户端的确认，服务端在成功处理客户端请求的连接后向客户端更新自己的窗口大小。

5.6设置带宽
客户端或者服务端发送这个消息用来更新对方的输出带宽，输出带宽的值和对方大小一样。如果自己当前窗口大小和消息中接收到得不一样，对方发送“窗口确认大小“。

发送标记硬（0），软（1），或者动态（2）消息利用有限的类型字段，在硬（0）请求中，对方必须在提供的带宽上发送数据，在软（1）请求中，带宽在于双发的判断，发送方可以限制带宽，在动态（2）请求中，带宽可以是硬的或者是软的。

RTMP命令消息
1. 介绍
服务端和客户端交换的消息的不同类型包括用于发送音频数据的音频消息，发送视频的数据的视频消息，发送用户数据的数据消息，共享对象消息，和命令消息。共享对象消息一般提供在多个的客户和一个服务段之间管理分布式数据的方法。
命令消息负载客户端跟服务端AMF编码命令，一个客户端或者服务端可以在使用命令消息于彼此通信的流觞请求远程调用。
2. 定义
消息流：
消息更随的用于通信的逻辑的通道。
消息流ID：
每一个消息有一个分配的ID用来识别此消息属于的消息流。
远程调用（RPC）
一个允许客户端或者服务端调用一个子程序或者进程的请求。
元数据：
关于数据的表述，影片的元数据包括影片标题，持续时间，创造的数据等等。
应用实例：
客户端通过发送连接请求连接服务器的应用程序的实例。
动作消息格式（AMF）
一种简洁的2进制编码用来连续化ActionSctipt对象。
3. 消息类型
客户端和服务端在网络上发送消息和彼此通信，这些消息可以使任何类型，包括音频消息，视频消息，命令消息，共享对象消息，数据消息，和用户控制消息。
3.1．命令消息
命令消息负载了在客户端和服务端的AMF编码命令，这些消息在AMF0中被分配的类型值是20，在AMF3中的值是17.这些消息发送用来运行操作诸如：连接，创造流，发布，播放，暂停。像onstatus,result这样的命令用来通知发送方需求命令的状态，一个命令消息由命令名称，处理ID和命令对象，一个客户端或者服务端可以通过命令消息通信的流请求远程进程调用（RPC）。
3.2.数据消息
客户端或者服务端发送这些消息用来发送元数据和任何给对方的数据，元数据包括数据（音频，视频等）的详细资料诸如：创造时间，持续时间，主题等等，在AMF0中这些消息被分配的消息类型值是18，在AMF3中式15.
3．3.共享对象消息
一个共享对象就是一个同步的穿过多个客户、实体等的flash对象，AMF0小红消息类型 kMsgContainer=19，在AMF3中该值为16，这些值被共享对象事件保留。每一个消息可以包含多个事件。

支持一下时间类型
3.4.音频消息
客户端或者服务端发送这个消息来发送音频数据给对方，音频消息的消息类型值为8是被保留的。
3.5.视频消息
客户端或者服务端发送这个消息来发送视频数据，视频消息的消息类型值为9是被保留的。这些很大会延迟其他类型消息的发送。为了阻止如此的情形，视频消息被分配位最低的优先级。
3.6.聚合消息
一个聚合消息是一个单一的包含一队子消息的消息。消息类型是22是被保留的。

The aggregate message formate

后点（back pointer）包括了在自己包头中包含的先前消息的大小。用来匹配FLV文件的格式和回溯搜索。
利用聚合消息会有一些性能上的优势
消息块流可以在一个消息块中发送至少一个完整的消息，这样增加了消息块的大小，利用聚合消息减少了消息块发送的数量。
子消息在内存中连续的存储，当制造系统（making system）呼叫在网络上发送数据时这就显得非常有效率。
3.7.用户控制消息
客户端或者服务端发送这个消息来通知对方用户控制事件。
以下是支持的控制事件类型

4. 命令的类型
客户端跟服务端交换的命令式用AMF编码的，发送方发送的命令消息由命令名称，处理ID和包含了相对参数的命令对象组成。例如:连接命令包含’app’参数，告诉服务端客户端连接的应用程序的名字。接收到的进程会以相同的处ID发回应答，回应字符可以是_result,_error,_或者一个方法名称（verifyClient 或者contactExternalServer）中的一种.
一个_result或者_error命令字符串发送回应信号，处理ID指示了回应消息中突出的命令，就像IMAP和许多其他的协议中的标签（tag）一样。在命令字符串中的方法名称代表了发送方试图在接收端运行一个方法（或动作）。
下面的总类对象用来发送多样性命令
NetConnection---一个高层表示在服务端和客户端连接的高层协议。
NetStream---一个表述音视频或者其他流的通道的对象，我们还发送命令像play, pause等等用来控制数据的流通。
4.1NetConnection命令
Netconnection在在客户端应用程序和服务端之间的双向连接，另外，他支持异步远程方法调用。
下面的命令可以再Netconnection中发送
Connect、call、close、creatStream
4.1.1 connect
客户端向服务端发送连接（connect）命令请求连接一个服务应用实例。以下为命令的结构
以下为在connect命令中用到的name-value pairs（名称值对）的表述。

音频编码的特性值

视频编码特性值

视频功能特性值

对象编码特性值

以下是服务端到客户端命令的结构

在命令执行过程中消息的流通过程：
客户端向服务端发送连接命令请求与服务端应用实例的连接。
当接收到连接命令后，服务端给客户端发送协议消息“窗口确认大小“，服务端也连接在连接命令中提及到得应用程序。
服务端向客户端发送协议消息“设置同行带宽“。
客户端在受到“设置同行带宽“后向服务端发送“窗口确认大小”。
服务端向客户端发送（streamBegin）。
服务端发送result命令消息向客户端提供链接状态的情报（失败或者成功），这个命令明确了处理ID（对于连接（connect）命令来说等同于1），这个消息也明确了一些特性，比如Flash medial
Server的版本，扩展其他连接的能力，级别的信息，编码，表述，对象编码等等。
4.1.2．call
Call方法在接收方运行远程进程，被呼叫的远程进程调用作为call命令的一个参数。
从发送方到接收方的命令格式如下:

回应的命令格式如下：

4.1.3.createStream（创造流）
客户端向服务端发送这个消息来创造一个逻辑的通道以供消息通信，音视频的发布，元数据在使用createStream命令创建的流通道上实现。
以下是客户端到服务端的发送的命令格式

以下是从服务端到客户端发送的命令格式

4.2.Netstream命令
Netstream定义了流视频，音频和数据消息可以流通的的通道，一个NetConnection对象可以支持许多数据流的NetStream。
以下命令可以再NetStream中发送
Play、play2、deletestream、closeStream、ReceiveAudio、receiveVideo、publish、seek、pause
Play：
客户端向服务端发送这个命令来播放流，一个播放列表也可以使用这个命令被创建。如果你想创造动态的在不同直播或者录制的流中交换的播放列表，调用play多次，每次给reset传递false。如果你想立刻播放确定的流，清除其他任何排列播放的流，给reset传递true。
以下从客户端到服务端发送的命令结构

以下是从服务端到客户端发送的命令结构

在命令执行时的消息流通过程：
。客户端在接收到创造流的result后发送播放命令。
。当接收到播放命令，服务端发送一个协议消息来设置消息块大小。
。服务端发送另一个协议消息（用户控制）来确定“StreamIsRecorded“事件和在消息这个消息中的流ID，消息在前两个字节中负载有事件类型，最后四个字节中负载有流ID。
。服务端发送另一个协议消息确定事件“StreamBegin“，用来标示对客户端流的开始。
。如果由客户端发送的play命令成功，服务端发送OnStatus命令消息NetStream.Play.Start和NetStream.Play.Reset，在客户端发送的Play命令已经设置了reset标签服务端只发送NetStream.Play.Reset。
。在这之后，服务端发送客户端播放的音视频数据。
4.2.2．Play2
与play命令不一样，play2可以再不改变播放内容时间线的情况下交换成一个不同的比特率流。服务端为支持的比特率保持多个文件，客户端可以在play2中请求。
以下是从客户端发送到服务端的命令结构

以下图示展示了命令消息的流通过程

4.2.3．删除流（deleteStream）
NetStream在NetStream对象被毁坏后发送删除流命令
以下是从客户端到服务端发送的命令的结构

服务端没有发送任何回应。
4.2.4．receiveAudio
NetStream发送接收音频消息来通知服务端是否发送或者不发送音频给客户端。
以下是从客户端发送到服务端的命令的结构

服务端不发送任何回应
4.2.5．receiveVideo
NetStream发送接收视频消息来通知服务端是否发送视频给客户端。
以下是从客户端发送到服务端的命令的结构

服务端不发送任何回应
4.3.6．发布（publish）
客户端发送发布命令向服务端发布命名的流，使用这个命名的名称，任何客户可以播放这个流，接收发布的音频、视频和数据消息。
以下是从客户端发送到服务端的命令的结构

服务端用OnStatus命令回应标记发布的开始。
4.2.7．搜寻（seek）
客户端发送搜寻命令搜寻在媒体文件或者播放列表中的偏移量（毫秒为单位）。
以下是从客户端发送到服务端的命令的结构

当搜寻成功后服务端发送一个状态消息NetStream．Seek．Notify，如果失败了，就返回一个_error消息。
4.2.8．暂停（pause）
客户端发送pause命令告诉服务端暂停或者开始播放。
以下是从客户端发送到服务端的命令的结构

当流暂停时服务端发送一个状态消息NetStream.Pause.Notify，当流没有被暂停
NetStream.Unpause.Notify会被发送。失败的情况下，会返回一个_error消息。
5. 消息交换例子
这有一些例子解释使用RTMP的消息交换。
5．1．发布录制的视频
这个例子图示一个发布方如何发布一个流然后如何在服务端把视频变为视频流，其他的客户端可以订阅这个发布的流和播放视频。

5.2．广播一个共享对象消息。
这个例子图示了在创造和改变共享对象的过程中消息的交换，也是共享对象广播的过程。

5.3．从录制的流中发布元数据
这个例子表述了发布元数据时的消息交换。