通过监听多个 UDP 套接字来避免数据包类型检查

Question

介绍

我有一个基本的服务器/客户端 UDP 设置。 我希望能够通过避免在有效负载中发送数据包类型（字节大小优化）来优化两个端点上每个数据包的编组，并进行额外检查以确定它是哪种类型的数据包，因此它知道要解组哪种类型（计算优化）。

这些数据包（或消息）的编组是使用协议缓冲区完成的。

已知解决方案

这个问题的公认答案提出了三种解决方案，我目前正在使用其中一种：

协议缓冲区从原始消息中检测类型

然而，数据包将以高频率流式传输网络，我觉得额外的检查和有效负载将变得昂贵。

为了详细说明为什么数据包大小优化可能是值得的，这里是 my.proto 文件中定义的消息。

message Packet {
    OpCode opCode = 1;
    google.protobuf.Any data = 2;
}

所以OpCode是定义数据包类型的变量， Any是一个通用对象，可以是任何东西。 因此，当我解组这样一个数据包时，我基本上做了两次。 一次用于基本消息，一次用于基于OpCode的Any 。 这也意味着我需要始终确定整个数据包的缓冲区大小。 如果我可以避免嵌套的通用对象并直接发送已知类型，它可能会大大减少数据包大小（取决于 protobuf 在幕后实际执行的操作）。

建议的解决方案

我最初的想法来自以下几点：

对于 UDP，套接字 API 允许一个套接字从多个端点接收数据，并向多个端点发送数据——因此许多服务器只使用一个套接字，因为不需要更多。 > 为什么在 UDP 服务器中使用单个套接字？

这让我想到我可以让服务器打开多个 UDP 套接字，一个用于将遍历网络的每种类型的数据包，但仍然能够与许多客户端通信。

这允许每个套接字始终知道要解组的数据包类型，并有一个固定的缓冲区大小来填充（避免必须检查数据包的长度）。

已知限制/假设

据我了解，操作系统确实限制了可以打开的套接字数量。 但是我怀疑这会影响我，因为我最多只需要 18 个，因为这是我的目标数据包类型。

题

那么在较低的网络层面上，由于会打开多个UDP套接字，那么这些打开的套接字将如何处理呢？ 每个套接字是否会同时处理传入/传出数据包，给我额外的优化？ 或者当我将数据包发送到 18000 个端点时它是否会成为瓶颈，因为它仍然是这个“单个 UDP 实体”，可能使我尝试优化，而不是优化......

Answer 1

每个套接字都独立于其他套接字，即有自己的发送和接收缓冲区，操作系统内核可能会并行处理这些套接字。 这也意味着消息的处理顺序可能与发送或接收的顺序不同，但这在您的情况下可能不是问题（对于 UDP，您已经需要意识到可能会发生数据包丢失、重复和重新排序） . 每个套接字还需要绑定到不同的<ip,port>元组（通常只有端口不同），如果您需要处理发送方和接收方之间的防火墙，这可能会使它变得更加复杂。

总的来说，我不确定这种优化是否真的值得。 对于 18 种类型，您最多需要 1 个字节来编码有效负载开头的类型，这与协议开销的其余部分相比是微不足道的：封装到以太网、IP、UDP 中已经用 IPv4 增加了 54 个字节，然后你也有有效载荷。