5

我正在研究我所知道的两种不同 TCP 消息成帧方法的优缺点。

  1. Delimited：通过使用分隔符字节将 TCP 流分成非固定长度的消息。发送数据时，例程必须检查消息数据的分隔符并将其转义以确保消息帧的安全传输。接收数据时，例程必须通读流，寻找分隔符字节以将帧分解为消息。

EG: 用户 [用户名]\n密码 [密码]\n

  1. Length-Prefixed：通过使用 4 个字节的前缀来说明消息的长度，将 TCP 流分成预定大小的消息。接收数据时，例程将首先读取前缀以确定消息帧的长度。发送数据时，例程必须在传输前为消息添加长度前缀。

EG: [MessageLength]User [Username][MessageLength]Password [Password]

这两种方法都允许传输大小不同并包含要解释的字节流的消息帧。更高级别的消息结构或协议是不相关的。

因此，我将注意力集中在可扩展性和性能效率上。我发现自己需要运行基准测试，看看哪种方法可以在不涉及任何消息处理的情况下获得最大的效率吞吐量。

我目前的想法，无论如何我都不是专家。

定界消息帧在接收例程期间效率较低，因为需要检查流中的每个字节是否有消息帧定界符。长度前缀消息帧将始终读取前缀字节，并且消息帧流的其余部分将直接进入缓冲区而不进行处理，直到接收到整个消息帧。

其中长度前缀消息帧在发送例程期间作为消息前缀在消息本身之前传输的效率较低。

我能想到的其他因素可能包括：

  • 大量小消息帧将导致为长度前缀结构传输更多数据包。
  • 使用 Length-Prefixed 结构可以更有效地处理大量较大的消息帧，因为不会读取每个字节来检查分隔符。

这个主题的任何亮点都会很棒。我发现很难找到关于 TCP 消息帧结构之间差异的好的资源。

4

1 回答 1

7

根据我的经验，首选长度前缀，消息的解析代码往往更容易编写。

此外，对于消息分隔符，如果消息有效负载可能包含分隔符，您需要找出转义方案。

我遇到了与有效负载无关的第三种方案。它定义了具有已知格式的不同消息类型，消息的不同部分可以是固定长度或可变长度。（固定为简单类型和变量是数组和字符串）。该结构预先在客户端和服务器之间共享。发送消息时，消息以消息类型编号为前缀。从消息类型号接收部分可以推断出如何解析消息。LysKOM 消息系统的协议
就是一个例子。 该协议具有可用于生成解析器代码的正式规范。

于 2012-08-17T04:51:58.553 回答