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

Question

简介

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

这些数据包(或消息)的编码是使用 Protocol Buffer 完成的。

已知解决方案

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

Protocol buffers detect type from raw message

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

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

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

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

建议的解决方案

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

For UDP, the socket API allows one socket to receive from many endpoints, and to send to many endpoints - so many servers use just one socket since there isn't any need for more. > Why a single socket in UDP servers?

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

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

已知限制/假设

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

问题

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

Answer 1

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

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