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

【问题标题】：Avoiding packet type check by using listening over multiple UDP sockets通过侦听多个 UDP 套接字来避免数据包类型检查
【发布时间】：2020-03-25 21:13:18
【问题描述】：

简介

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

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

已知解决方案

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

Protocol buffers detect type from raw message

但是数据包将以高频率在网络中传输，我觉得额外的检查和负载会变得很昂贵。

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

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

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

建议的解决方案

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

对于 UDP，套接字 API 允许一个套接字从多个端点接收，并发送到多个端点——因此许多服务器只使用一个套接字，因为不需要更多。 > Why a single socket in UDP servers?

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

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

已知限制/假设

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

问题

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

【问题讨论】：

标签： sockets go udp protocol-buffers marshalling

【解决方案1】：

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

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

【讨论】：

将套接字映射到类型也有一些浪费。并非所有消息类型都以相同的频率生成。一些套接字将大部分未使用，而另一些套接字将被更多使用。
@mh-cbon：与对所有消息使用单个 UDP 套接字相比，这应该不是问题。与为所有类型使用多个套接字以更好地扩展相比，这可能是一个问题。
@SteffenUllrich 我注意到您说“操作系统内核可能会并行处理这些套接字”。您能否详细说明一下，以便我可以调查这可能有多大的限制？您提出了一个优化是否值得的好观点，我会考虑并分享我在基准测试后发现的内容。
@FanusduToit：因为这些是具有独立发送和接收缓冲区的独立套接字，内核可以从这些缓冲区中读取或并行填充这些缓冲区（假设现在很常见的多核 CPU）。如果您为不同的客户端使用不同的套接字（即客户端不同而不是类型不同）或使用多个套接字的其他方式，也会出现这种情况。
@SteffenUllrich 这完全有道理，谢谢。我还稍微更新了我的问题，以解释数据包大小如何值得优化。