消息框架方法在.NET中的优缺点

Question

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

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

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

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

EG：[MessageLength]用户[用户名] [MessageLength]密码[密码]

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

---

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

---

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

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

如果长度前缀消息帧在发送例程期间的效率较低，则消息前缀将在消息本身之前传输。

---

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

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

---

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

Answer 1

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

此外，如果消息有效负载可能包含分隔符，则需要使用消息分隔符来计算转义方案。

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