☰

RTMP / TCP 数据包中有额外字节吗？

tag-icon • tag-icon tcp rtmp
RTMP / TCP 数据包中有额外字节吗？

我正在分析 RTMP（实时消息传递协议），发现了一些非常奇怪的东西。在捕获的一个数据包中，TCP 有效负载长度比预期的要长。这是 Wireshark 中的数据包： Wireshark TCP 负载视图

该C3字节使 RTMP 比预期的要长。令人惊讶的是，它消失了，出现在 RTMP 有效负载视图中：

Wireshark RTMP 有效负载视图

如您所见，该C3字节在 RTMP 视图中消失了。但它是 TCP 有效负载的一部分。我不知道为什么会发生这种情况，我怀疑：

  1. 一些更长的 UTF-8 字符？

    根据维基百科，AMF0 中的字符串被编码为 16 位 UTF-8。这意味着它可以是 8/16 位。但是，\u33C3和\uC32E都是韩文字符，第二张图片显示这不是我的情况。

  2. TCP 有效负载的填充/转义字符？

    不，我从来没听说过……

  3. 我对 TCP 有什么不了解的地方吗？

    以下是我发现的内容：

    a. 它不是 RTMP 消息的一个片段，TCP 数据包包含 RTMP 消息所需的一切。

    b. 校验和正确，一切似乎都很好。

    c. 数据包被对方正确确认（图中未显示）

    d. 通过使用流媒体软件 Wirecast，可以重现此过程

我是不是漏掉了什么？Wireshark 为什么能够正确解码有效载荷？Wireshark 为什么只是删除C3（这表明它与 AMF0 编解码器无关）？我好困惑。请帮忙 :'(

RTMP 协议规范在这里：https://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

答案1

哦，我终于明白了！根据 Adob​​e 的文档，

最大块大小默认为 128 字节

和

5.3.1.2.4. 类型 3
类型 3 块没有消息头...由完全相同大小、流 ID 和时间间隔的消息组成的流应该对类型 2 块之后的所有块使用此类型。

（块头，又称“块基本头”，不是消息头，它们是完全不同的！）

这里type 3指的是块头类型 3，它位于第一个字节的前两位，值为0b11xxxxxx。 而后六个字节的重置是流 ID（这里是 3，0bxx000011）。 这两个语句与我的问题的行为相符：在偏移量为 128 字节处（不包括消息头）新建一个块，块头type 3。 Wireshark 确实正确地解析了它。 有点令人困惑：他们不将块头视为消息的一部分，这是有道理的。 但他们确实将类型 0-2 块头视为消息的一部分（第一个0x03），这没有意义。

另外，我在这里找到了一个参考（搜索C3一下...你就明白了...）： https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol

相关内容