RTMP协议

RTMP协议

　　Real Time Messaging Protocol（实时消息传送协议协议)概述
　　实时消息传送协议是Adobe Systems公司为 Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种：
　　1)工做在 TCP之上的明文协议，使用端口 1935；
　　2)RTMP T封装在 HTTP请求之中，可穿越防火墙；
　　3)RTMP S相似RTMPT， 但使用的是HTTPS链接；
　　介绍:
　　RTMP协议是被Flash用于对象,视频,音频的传输.该协议创建在TCP协议或者轮询HTTP协议之上.
　　RTMP协议就像一个用来装数据包的容器,这些数据 能够是AMF格式的数据,也能够是FLV中的视/音频数据.
　　一个单一的链接能够经过不一样的通道传输多路网络流.这些通道中的包都是按照 固定大小的包传输的.
　　网络链接(Connection)
　　一个Actionscript链接并播放一个流的简单代码:
　　

代码

　　var videoInstance:Video  =  your_video_instance;
　　var nc:NetConnection  =   new  NetConnection();
　　var connected:Boolean  =  nc.connect( " rtmp:/localhost/myapp " );
　　var ns:NetStream  =   new  NetStream(nc);
　　videoInstance.attachVideo(ns);
　　ns.play( " flvName " );

 

　　默认端口为1935
　　握手
　　Client → Server :向服务器发出握手请求. 这不属于协议包一部分,该握手请求第一个字节为(0×03),其后跟着1536个字节.经管看上去这部分的内容对于RTMP协议来讲并非相当重要的,但也不可随意对待.
　　Server → Client :服务器向客户端回应握手请求.这部分的数据仍然不属于RTMP协议的部分.该回应的其实字节仍然为(0x03),可是后边跟着个长度为1536个字节 (一共为3072 )的包块.第一个1536块看上去彷佛能够是任意内容,甚至好像能够是Null都没有关系.第二个1536的代码块,是上一步客户端向服务器端发送的握手 请求的内容.
　　Client→Server:把上一步服务器向客户端回应的第二块1536个字节的数据块.
　　至此客户端与服务器端的握手结束,下面将发送RTMP协议的包内容.
　　Client → Server :向服务器发送链接包.
　　Server → Client :服务器回应.
　　... .... 等等... ...
　　RTMP 数据类型
　　0×01 Chunk Size changes the chunk size for packets
　　0×02 Unknown anyone know this one?
　　0×03 Bytes Read send every x bytes read by both sides
　　0×04 Ping ping is a stream control message, has subtypes
　　0×05 Server BW the servers downstream bw
　　0×06 Client BW the clients upstream bw
　　0×07 Unknown anyone know this one?
　　0×08 Audio Data packet containing audio
　　0×09 Video Data packet containing video data
　　0x0A - 0×11 Unknown anyone know?
　　0×12 Notify an invoke which does not expect a reply
　　0×13 Shared Object has subtypes
　　0×14 Invoke like remoting call, used for stream actions too.
　　Shared Object 数据类型
　　0×01 Connect
　　0×02 Disconnect
　　0×03 Set Attribute
　　0×04 Update Data
　　0×05 Update Attribute
　　0×06 Send Message
　　0×07 Status
　　0×08 Clear Data
　　0×09 Delete Data
　　0x0A Delete Attribute
　　0x0B
　　Initial Data
　　RTM P包结构
　　RTMP包 包含一个固定长度的包头和一个最长为128字节的包体.包头能够是下面4种长度的任意一种:12, 8, 4, or 1 byte(s).
　　第一个字节的前两个Bit很重要,它决定了包头的长度.它能够用掩码0xC0进行"与"计算.下面的表格罗列了可能的包头长度:Bits Header Length
　　00 12 bytes
　　01 8 bytes
　　10 4 bytes
　　11 1 byte
　　咱们在这里讨论关RTMP包结构的问题并非很是的详细.咱们在之后有时间会讨论关于AMF的问题(敬请期待...:loveliness:),其实RTMP包结构就是使用了AMF格式.
　　流
　　关于流的操做咱们须要进一步研究,在论坛中的http://www.openred5.com /bbs/viewthread.php?tid=175&extra=page%3D1这篇文章研究的仍是不错的,你们能够参考.不过下面能够 列一个关于客户端向服务器端发送流的流程:
　　Client→Server :发送一个建立流的请求.
　　Server→Client :返回一个表示流的索引号.
　　Client→Server :开始发送.

　　Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来惟一标识).

 

 

 一、协议研究概述
   协议设计和分析一直都是在工做遇到，正好在这里总结一下，说到协议，在这个网络的时代，没有人能够离开它了。他存在咱们生活中的任何角落，只不过咱们平 时，并无注意到它的存在，能够这么说若是没有协议，咱们生活和平常的工做生产都不能进行。若是仔细想一想你生活中用到的全部东西，协议已经包含其中。那到 底什么是协议呢？说的简单一点就是双方达成的共识，以便更好的交流，理论上协议是什么呢？若是学过《信号与系统》的人都知道有个简单的道理，就是信息在经 过一个管道的符号集，到另外一个符号集时信息不会丢失。

    任何复杂的事物都有个最简单的本质，网络上的协议也是这样，有个最基本的本质。除去上下层的概念，协议就只剩下通讯双方实体的规则。

   通常的协议都包含最基本的协议头，不论是物理层、链路层、仍是网络层，这个头就构成了协议的本质东西。一般协议头要包含如下最基本的三项信息：

　　　　1> 双方实体的惟一标示，用来标示通讯双方的实体。
　　　　2> 类型描述或者是净核描述，标志净核的内容。
　　　　3> 协议净核的长度，用来在萃取净核的内容应用。
   其中，前两项是必需要有的，没有他们，通讯双方的交互根本得不到保证，第三项在不太灵活的通讯中能够去掉，而有第二项的类型推出。

    协议的丰富性，有净核的多样性体现。

   协议头除了以上的三项，还能够增长更多的信息（好比控制信息、时间信息等），取决于具体的应用。找到这些基本的东西，再去看协议的时候，可以更好的抓住协议的主体进行分析和设计了。

2 RTMP 协议概述
   RTMP 协议是被 Flash 用于对象、视频、音频的传输。该协议创建在 TCP 协议或者轮询 HTTP 协议之上， RTMP 协议就像一个用来装数据包的容器，这些数据能够是 AMF 格式的数据，也能够是 FLV 中的视 / 音频数据。一个单一的链接能够经过不一样的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的 .

3 RTMP 协议部分
3.1 协议头

 

代码

struct  RTMP_HEAD 

{ 

       char  cChannelid :  6 ; //  第一个字节的后 6 位 

       char  cCheadsize ;  //  第一个字节的头两位 

       char  cTimer[ 3 ];   //  三个字节表示的时间信息 

       char  cLength[ 3 ];  //  三个字节表示的长度 

       char  cDatatype;  //  数据类型 

       char  sStreamid[ 4 ];  //  流标识 

}; 

 

　　这里有三个最基本的元素（惟一标示 ）、（类型 ）和（净核的长度 ）分别是： cChannelid 、 cDatatype 和 cLength 。

3.2 数据类型
　　数据类型 决定了协议上层能够作的具体的事情，和使用协议的人必须遵循的规则。

　　同时数据类型 说明了净核 的基本内容。

　　RTMP 数据类型：

0×01  Chunk Size  changes the chunk size for packets 
0×02  Unknown  anyone know this one? 
0×03  Bytes Read  send every x bytes read by both sides 
0×04  Ping  ping is a stream control message, has subtypes 
0×05  Server BW  the servers downstream bw 
0×06  Client BW  the clients upstream bw 
0×07  Unknown  anyone know this one? 
0×08  Audio Data  packet containing audio 
0×09  Video Data  packet containing video data 
0x0A - 0×11  Unknown  anyone know? 
0×12  Notify  an invoke which does not expect a reply 
0×13  Shared Object  has subtypes 
0×14  Invoke  like remoting call, used for stream actions too. 

3.3 协议的净核
   RTMP 的协议净核是用 AMF 格式来 描述， AMF 格式自己的产生就是为了 RTMP 协议服务的，最初的 RTMP 采用 XML 的形式传输数据，但 XML 只是字符形式的值对的格式传输数据，而随着应用的普及这彻底不能知足要求了，好比对象、结构、数组，甚至能够是数据集，配合 DataGrid 组件能够很方便地显示数据。
为了处理复杂数据类型，采用一种独有的方式使 Flash 与应用服务器间能够来回传送数据势在必行。因而 AMF 应运而生。

　　AMF 是 Adobe 独家开发出来的通讯协议，它采用二进制压缩，序列化、反序列化、传输数据，从而为 Flash 播放器与 Flash Remoting 网关通讯提供了一种轻量级的、高效能的通讯方式。 
 
　AMF 最大的特点在于可直接将 Flash 内置对象，例如 Object, Array, Date, XML ，传回服务器端，而且在服务器端自动进行解析成适当的对象，这就减轻了开发人员繁复工做，同时也更省了开发时间。因为 AMF 采用二进制编码，这种方式能够高度压缩数据，所以很是适合用 来传递大量的资料。数据量越大， Flash Remoting 的传输效能就越高，远远超过 Web Service 。至于 XML, LoadVars 和 loadVariables() ，它们使用纯文本的传输方式，效能就更不能与 Flash Remoting 相提并论了。
　 　注意： Flash Remoting 须要浏览器支持 Binary POST ， Flash 播放器在 Netscape 6.x. 环境下运行 Flash Remoting 会不起做用（ Flash Remoting 调用没有效果也不返回错误）， Netscape 7 已经纠正了这个 bug 。对于早期 Safari 和 Chimera 版的苹果机也有这个问题。
　　一样是轻量级数据交换协议，一样是经过调用远程服务，一样是基于标准的 HTTP 和 HTTPS 协议， Flash Remoting 为何选择了使用 AMF 而放弃了 SOAP 与 Flash 播放器通讯呢  有以下缘由：
 
SOAP 将数据处理成 XML 格式，相对于二进制的 AFM 太冗长了； 
AMF 能更有效序列化数据；由于 AMF 的初衷只是为了支持 Flash ActionScript 的数据类型，而 SOAP 却致力于提供更普遍的用途； 
AMF 支持 Flash 播放器 6 只须要浏览器增长 4 KB 左右（压缩后）的大小，而 SOAP 就大多了； 
SOAP 的一些头部文件请求在 Flash 播放器 6 不支持。那 Flash 播放器 6 为何能访问基于 SOAP 的 Web 服务呢？原来 Flash Remoting 网关将 SOAP 请求在服务器端与转换成 AFM 格式，而后利用 AFM 与 Flash 播放器通讯。另外， AMF 包中包含 onResult 事件（好比说 response 事件）和 onStatus 事件（好比说 error 事件），这些事件对象在 Flash 中能够直接使用。 
AMF 从 Flash MX 时代的 AMF0 发展到如今的 AMF3 。 AMF3 用做 Flash Playe 9 的 ActionScript 3.0 的默认序列化格式，而 AMF0 则用做旧版的 ActionScript 1.0 和 2.0 的序列化格式。 在网络传输数据方面， AMF3 比 AMF0 更有效率。 AMF3 能将 int 和 uint 对象做为整数（ integer ）传输，而且能序列化 ActionScript 3.0 才支持的数据类型 , 好比 ByteArray ， XML 和 Iexternalizable 。

      AMF 很好的解决了内容的丰富性。（具体 AMF 格式参考附件格式文档）

3.3.1 AMF中的数据类型Data Types
AMF0 supports the following data types (with their type field values):

NUMBER = 0x00
BOOLEAN = 0x01
STRING = 0x02
OBJECT = 0x03
MOVIECLIP = 0x04
NULL_VALUE = 0x05
UNDEFINED = 0x06
REFERENCE = 0x07
ECMA_ARRAY = 0x08
OBJECT_END = 0x09
STRICT_ARRAY = 0x0a
DATE = 0x0b
LONG_STRING = 0x0c
UNSUPPORTED = 0x0d
RECORD_SET = 0x0e
XML_OBJECT = 0x0f
TYPED_OBJECT = 0x10
Binary Format
AMF format for a value/object consists of a type byte (see above) followed by zero or more bytes. This section describes the bytes following the type byte for various types.

NUMBER (type byte: 0x00)
Numbers are stored as 8 byte (big endian) float double. On x86 you can just byteswap a double to encode it correctly.

BOOLEAN (type byte: 0x01)
A boolean is encoded in one byte. FIXME: is true sent as 0xff? 0x01?

STRING (type byte: 0x02)
A string is encoded as a 2 byte (big endian) count (number of bytes) followed by that many bytes of text. Note: there is no null terminator.

I think the text is assumed to be UTF-8. Can someone double check me on this?

NULL_VALUE (type byte: 0x05)
A null has zero bytes following the type byte

UNDEFINED (type byte: 0x06)
A undefined has zero bytes following the type byte

OBJECT (type byte: 0x08)
An object is encoded as a series of key/value pairs. The key is encoded as a STRING (above) WITH NO TYPE BYTE, and the value is any AMF value.

The object encoding is terminated by 0x000009 (that is a zero length string key, followed by the OBJECT_END type byte described below.

OBJECT_END (type byte: 0x09)
This is not really a value, but a marker for the end of an OBJECT. See above.

STRICT_ARRAY (type byte: 0x0a)
This is the encoding for arrays such as ["foo", "bar", 1, 2, 3]. For a hash (a set of key/value pairs) you'll need to use OBJECT above.

An array is encoded as 4 byte (big endian) integer which is the number of elements in the array, followed by that many AMF values.

That's it. There's no terminator of any kind.

Use in shared object files
While most AMF objects are just a value, there is a special variation used by shared object files for properties. Rather than start with the type field, followed by the length, it starts with a byte count, then the name, and then the regular AMF type field, the length, and then the data.

3.4 客户端和服务器的链接过程
3.4.1客户和服务器的握手
 

   Flash Player 以系统时间做为种子经过某种算法生成的数字签名，大小是 1537 字节向服务器发起第一次握手，服务器根据客户端的数字签名产生一个 3073 字节的验证包，给客户端，客户端在接受到服务器的回应之后会发送一个 1536 字节的回复。

具体的流程：

发送第一次握手包 handshark1
接收第二次握手包 handshark2
发送的三次握手包 handshark3
第 一个握手包 handshark1 和服务器的回复握手包 handshark2 都是以 0X03 开头。这三次握手不是 RTMP 协议自己的内容，因此在这并无包含 RTMP  的协议头。是服务器的厂家本身产品作验证用的，严格的说就是你必须用  Adobe 的客户端和服务器才能使用个人协议。

3.4.2客户和服务器通讯
   具体链接和请求视频的过程

发送 rtmp_connect 命令
. 发送本地带宽消息 . 默认是 125000
服务器返回服务器带宽信息
服务器返回本地带宽信息
服务器返回链接成功消息 "NetConnection.Connect.Success"
客户端发送建立流请求 encodeCreateStreamPacket
服务器返回建立流成功消息
客户端发送播放文件消息 Rtmp_Play
服务器返回 TYPE_CHUNK_SIZE 消息
服务器返回开始播放消息 "NetStream.Play.Start"
服务器返回视频信息 (TYPE_STREAM_METADATA) ，包括大小，宽高，速率等等信息－－文件长度能够在这里推算出来
RTMP 的净核决定了内容服务， adobe 的服务器采用的 AMF 格式的字串命令来控制视频的传输和播放，具体的字串命令信息以下：（注：字串的定义有厂家（ adobe ）本身定义，只要知足 AMF 的格式就能够）
NetConnection.Call.Failed
NetConnection.Call.BadVersion 
NetConnection.Connect.AppShutdown
NetConnection.Connect.Closed
NetConnection.Connect.Rejected
NetConnection.Connect.Success
NetStream.Clear.Success
NetStream.Clear.Failed
NetStream.Publish.Start
NetStream.Publish.BadName
NetStream.Failed
NetStream.Unpublish.Success
NetStream.Record.Start
NetStream.Record.NoAccess
NetStream.Record.Stop
NetStream.Record.Failed
NetStream.Play.InsufficientBW
NetStream.Play.Start
NetStream.Play.StreamNotFound
NetStream.Play.Stop
NetStream.Play.Failed
NetStream.Play.Reset
NetStream.Play.PublishNotify
NetStream.Play.UnpublishNotify
NetStream.Data.Start
Application.Script.Error
Application.Script.Warning
Application.Resource.LowMemory
Application.Shutdown
Application.GC
Play
Pause
demoService.getListOfAvailableFLVs
getStreamLength
connect
app
flashVer
swfUrl
tcUrl
fpad
capabilities
audioCodecs
audioCodecs
videoCodecs
videoFunction
pageUrl
createStream
deleteStream
duration
framerate
audiocodecid
audiodatarate
videocodecid
videodatarate
height
width
3.4.2数据的萃取
      在服务器返回开始播放消息 "NetStream.Play.Start" 以后，服务器就会开始给客户端传输数据了，通常数据的萃取都是先解析协议的头，而后根据协议头中数据类型和净核长度就能够把数据部分取出， RTMP 协议也是这样。

 

代码

struct  RTMP_HEAD 

{ 

       char  cChannelid :  6 ; //  第一个字节的后 6 位 

       char  cCheadsize ;  //  第一个字节的头两位 

       char  cTimer[ 3 ];   //  三个字节表示的时间信息 

       char  cLength[ 3 ];  //  三个字节表示的长度 

       char  cDatatype;  //  数据类型 

       char  sStreamid[ 4 ];  //  流标识 

} 

 

 

      首先判断 cDatatype 是那种类型，而后根据不一样的类型进行萃取数据部分，进行不一样的处理，获取视频的数据的方式先看是不是一下的类型：

0×08  Audio Data  packet containing audio 
0×09  Video Data  packet containing video data 

  根据净核的长度读取出内存中的音视频数据，这里的音视频数据是有必定编码格式的数据，这个取决于应用的具体配置， Flash play 使用的是 FLV 的格式。要对这部分数据进行存取，还有作一部分工做，对 FLV 的视频数据进行去壳，取出数据保存文件就能够了。