•以上这4种type其实是在传输过程中精细化管理的体现，比如type2，他剪掉了其他的属性，因为他前面的包和他的包，这些属性都是一样的，没必要再传，就省掉了，依次类推。
•当message比较大的时候会切分成多个chunk这个时候采用type3.
•当连续的message正好size, stream ID and spacing in time(时间间隔)都相同的时候就采用type2.
•需要注意两个名词timestamp，timestamp delta,这两个字段是不同的，timestamp指的是当前的时间戳，timestamp delta指的是和上一次相比多多少的值。
•分析他就看head data的字节数，11是type0,3是type2,0是type3.
•另外，上图的chunk里边第一个是type0,第二个是type2,剩下2个是type3,假如第二个的delta和第一个type0的时间戳的数字正好相等，那么第二个就不是type2而写成type0,因为可以省略delta了。
•协议控制消息，内容分为1,2,3,5,6,用于通知对方，4的时候是用户控制信息，此时的chunk stream ID的值必须是2, message stream id必须是0.
• 1表示：set chunk size
• type id是1，payload部分（也就是chunk data部分)保存的是要设置的值需要32位。
• 2 表示：Abort Message
• stream id保存在playload部分 需要32位
• 3 表示：Acknowledgement
• 当上次收到的bytes的个数正好等于最大的窗口数的时候，必须发送这个命令，代表已经拿到的字节数+1,类似于tcp里边的ack。
•5 Window Acknowledgement Size
•发送这个命令的时候，对方必须发送Acknowledgement，参数是32位
•6 Set Peer Bandwidth
•还有一些特殊的message types
•20（amf3）/17(amf0) Command Message
•包含：connect, createStream, publish, play, pause，onstatus, result
•Data Message (18, 15)
•Shared Object Message (19, 16)
•Audio Message (8)
•Video Message (9)
•Aggregate Message (22)
•以上18,15.。。。22看看文档就行了。
• 具体的参见官方文档
•用户控制信息：
• Payload 前16位保存事件，后边保存相关数据。
•message type 控制着play load内容的含义。
看到connect对象就不用看了下面的都知道。
