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

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《通过使用侦听多个 UDP 套接字来避免数据包类型检查》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

简介

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

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

已知解决方案

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

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

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

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

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

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

建议的解决方案

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

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

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

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

已知限制/假设

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

问题

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

解决方案

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

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

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《通过使用侦听多个 UDP 套接字来避免数据包类型检查》文章吧，也可关注golang学习网公众号了解相关技术文章。