Rtmp协议中chunksize与message长度的问题

在实现RTMP客户端的时候,出现一个诡异的问题,有时候可以连接上服务器,有时候却连接不上。在Wireshark里面找了很久,也没发现原因。

经过各种测试,发现只有在Message的长度大于128的时候,才会出现连接不上的情况。然后以”RTMP 128”为关键词搜索,没想到还真发现了问题的所在。 是因为Chunk的长度默认只有128,数据太长时,需要进行分割,也就是将一个Message分割成多个Chunk。

第一个Chunk的fmt为0,后续的Chunk的fmt为3

原始Message:

0000   03 a8 a3 c0 00 00 ed 14  00 00 00 00 02 00 07 63  ...............c
0010   6f 6e 6e 65 63 74 00 3f  f0 00 00 00 00 00 00 03  onnect.?........
0020   00 0c 63 61 70 61 62 69  6c 69 74 69 65 73 00 40  ..capabilities.@
0030   6d e0 00 00 00 00 00 00  04 66 70 61 64 01 00 00  m........fpad...
0040   05 74 63 55 72 6c 02 00  14 72 74 6d 70 3a 2f 2f  .tcUrl...rtmp://
0050   65 32 65 74 2e 63 6f 6d  2f 6c 69 76 65 00 06 73  e2et.com/live..s
0060   77 66 55 72 6c 06 00 08  66 6c 61 73 68 56 65 72  wfUrl...flashVer
0070   02 00 10 4d 41 43 20 31  31 2c 35 2c 35 30 32 2c  ...MAC 11,5,502,
0080   31 31 30 00 0b 76 69 64  65 6f 43 6f 64 65 63 73  110..videoCodecs
0090   00 40 6f 80 00 00 00 00  00 00 0e 6f 62 6a 65 63  .@o........objec
00a0   74 45 6e 63 6f 64 69 6e  67 00 40 08 00 00 00 00  tEncoding.@.....
00b0   00 00 00 07 70 61 67 65  55 72 6c 06 00 0d 76 69  ....pageUrl...vi
00c0   64 65 6f 46 75 6e 63 74  69 6f 6e 00 3f f0 00 00  deoFunction.?...
00d0   00 00 00 00 00 03 61 70  70 02 00 04 6c 69 76 65  ......app...live
00e0   00 0b 61 75 64 69 6f 43  6f 64 65 63 73 00 40 ab  ..audioCodecs.@.
00f0   ee 00 00 00 00 00 00 00  09                       .........

分割后的Chunks

0000   03 a8 a3 c0 00 00 ed 14  00 00 00 00 02 00 07 63  ........ .......c
0010   6f 6e 6e 65 63 74 00 3f  f0 00 00 00 00 00 00 03  onnect.? ........
0020   00 0c 63 61 70 61 62 69  6c 69 74 69 65 73 00 40  ..capabi lities.@
0030   6d e0 00 00 00 00 00 00  04 66 70 61 64 01 00 00  m....... .fpad...
0040   05 74 63 55 72 6c 02 00  14 72 74 6d 70 3a 2f 2f  .tcUrl.. .rtmp://
0050   65 32 65 74 2e 63 6f 6d  2f 6c 69 76 65 00 06 73  e2et.com /live..s
0060   77 66 55 72 6c 06 00 08  66 6c 61 73 68 56 65 72  wfUrl... flashVer
0070   02 00 10 4d 41 43 20 31  31 2c 35 2c 35 30 32 2c  ...MAC 1 1,5,502,
0080   31 31 30 00 0b 76 69 64  65 6f 43 6f c3 64 65 63  110..vid eoCo.dec
0090   73 00 40 6f 80 00 00 00  00 00 00 0e 6f 62 6a 65  s.@o.... ....obje
00A0   63 74 45 6e 63 6f 64 69  6e 67 00 40 08 00 00 00  ctEncodi ng.@....
00B0   00 00 00 00 07 70 61 67  65 55 72 6c 06 00 0d 76  .....pag eUrl...v
00C0   69 64 65 6f 46 75 6e 63  74 69 6f 6e 00 3f f0 00  ideoFunc tion.?..
00D0   00 00 00 00 00 00 03 61  70 70 02 00 04 6c 69 76  .......a pp...liv
00E0   65 00 0b 61 75 64 69 6f  43 6f 64 65 63 73 00 40  e..audio Codecs.@
00F0   ab ee 00 00 00 00 00 00  00 09                    ........ ..

就在008c的位置,出现了一个c3(11000011),这里就是第二个包的BasicHeader。 这次,服务器就可以正确地处理这个连接请求了

Published: November 18 2012