手撕Rtmp协议细节（6）——connect后续三剑客
在讲解connect消息的时候，我们说过服务器收到connect消息之后，会向客户端发送Window Acknowledgement Size消息和Set Peer Bandwidth消息，这一篇就来介绍一下这两条消息。
1.概览
首先从抓包文件看一下：
示例中服务器ip地址是192.17.1.200，客户端ip地址是192.17.1.92，客户端向服务器发送connect消息之后，服务器向客户端发送了Window Acknowledgement Size和Set Peer Bandwidth消息。
2.Window Acknowledgement Size消息
Window Acknowledgement Size用来通知对端，如果收到该大小字节的数据，需要回复一个Acknowledgement消息，也就是ACK。本例中，设置的大小为500000，也就是服务端通知客户端如果收到了50000字节的数据，需要向服务端发送一个ACK的消息，而实际上一般情况一个会话中能达到如此大的数据量比较少，所以我们也看到会回复ACK消息的消息比较少，更多的只是看到设置接收窗口大小的消息（Window Acknowledgement Size），接下来我们看一下抓包。
消息格式比较简单，组织结构是RTMP Header + RTMP Body，Header的结构就不赘述了，参考前面的文章；Body中直接使用4个字节表示要设置的大小，此处为0x004c4b40=5000000。
3.Acknowlegement消息
Acknowlegement消息可以理解为Window Acknowlegement Size满足条件的触发消息，当一端收到的数据大小满足Window Acknowledgement Size设置的大小时，向对端发送Ack消息。
Acknowlegement消息，也按照RTMP Header + RTMP Body进行组织，其Body也直接使用4个字节，表示收到数据满足Window Acknowledgement Size的最后一个数据包的序列号。我们来看一个抓包文件：
该条消息表示，在序列号为2507670的时候，rtmp客户端已累计收到5000000个字节的数据，此时向服务端发送一个ACK。
另外我们也验证一下，交互过程中，更多的看到Window Acknowledgement Size消息，而很少看到Acknowlegement消息。
说明：wireshark中可以针对rtmp消息进行过滤
过滤Window Acknowledgement Size
rtmpt.header.typeid == 0x05
过滤Acknowledgement
rtmpt.header.typeid == 0x03
照猫画虎，可以对照下表进行过滤：
| typeID |
消息类型 |
说明 |
| 0x00 |
Unkown |
|
| 0x01 |
Set Chunk Size |
设置Chunk大小 |
| 0x02 |
Abort |
|
| 0x03 |
Window Acknowledgement Size |
|
| 0x04 |
User Control Message |
空户控制消息（如Stream Begin等） |
| 0x05 |
Acknowledgement |
|
| 0x06 |
Set Peer Bandwidth |
更多的关于wireshark抓包关于rtmp的过滤条件，参照：
https://www.wireshark.org/docs/dfref/r/rtmpt.html
4.Set Peer BandWidth消息
该消息里设置对端输出带宽，对端是通过设置Window Acknowledgement Size来实现流量控制的。超过Window Acknowledgement Size后未确认（不发送Acknowledgement）发送端将不再发送消息。所以对端收到set peer bandwidth后，如果之前发送的Window Acknowledgement Size和这里写的的Window Acknowledgement Size不一样，一般会发送一个Window Acknowledgement Size。
刚开始建立连接，服务器向客户端发送Set Peer Bandwidth消息，客户端第一次收到Set Peer Bandwidth消息，之前没有发送过Window Acknowledgement Size，所以在这里向服务端发送一次消息。
还是看抓包文件：
Set Peer Bandwidth消息还是按照RTMP Header + RTMP Body的格式组成。RTMP Body由两个字段组成，一个是Window acknowledgement size，占用4个字节；一个是limit type，表示限制的类型，可取的值为0（Hard），1（soft）, 2（Dynamic）。本例中采用的是Dynamic。
-
limity type表示了不同的限制策略：
-
Hard：收到消息的一端需要按照消息中设置的Window size进行限制；
-
Soft：收到消息的一端按照消息中设置的Window size或者已经生效的限制进行限制，以两者中较小的为准。
-
Dynamic：如果之前的类型为Hard，则此消息也为Hard类型，否则忽略该类型。
5.StreamBegin
服务端发送Set Peer Bandwidth消息之后，客户端向服务端发送Window Acknowledgement Size消息，服务端再向客户端发送一条用户控制消息StreamBegin。
wireshark中过滤StreamBegin消息的条件如下：
rtmpt.header.typeid == 0x04 and rtmpt.ucm.eventtype == 0x00StreamBegin属于用户控制类消息，header的typeid为0x04。而用户控制消息的类型的定义如下：
| type |
消息 |
说明 |
| 0x00 |
Stream Begin |
|
| 0x01 |
Stream EOF |
|
| 0x02 |
Stream Dry |
|
| 0x03 |
SetBufferLength |
|
| 0x04 |
StreamIsRecoreded |
|
| 0x06 |
PingRequest |
|
| 0x07 |
PringResponse |
如此，我们就得出了StreamBegin的过滤条件。接下来我们看看StreamBegin消息，还是先看一下抓包文件：
RTMP服务器发送StreamBegin以通知客户端流已经可以使用并且可以用于通信。默认情况下，从客户端成功接收到connect命令后，将在ID 0上发送StreamBegin。StreamBegin的数据字段占用4字节，其类型占用2个字节，所以RTMP Body部分总共占用6个字节（类型+数据）。其中数据字段代表已开始运行的流的流ID，此例中为1。
好了，这一篇就到这里了，下一篇我们继续手撕Rtmp协议细节，不要走远！
扫描二维码获取更多精彩
