feat: deliver UDP packets from same connection in receiving order #1540
Conversation
|
暂时不打算接受这个修改，作为udp应用应该有正常处理乱序数据包的能力，不应该依赖接收顺序 从代码上说，Metadata中的 |
从概念上讲，确实是这样。但：
在从 Wireguard 客户端经 iperf3 单线程 TCP 上行跑流到 Wireguard 服务端的测试中，在 59a2b24 提交处编译的 mihomo 能够跑到 880Mbps 的性能，在前述提交的基础上带本 PR 以后，则是跑到 1.02Gbps. 每个 mihomo 版本测试至少三次，并来回切换 mihomo 版本，均可稳定复现此数据。 我认为 Wireguard 已经是比较规范的 UDP 应用，该数据能够证明乱序问题有切实的影响。
代码的问题我会按前述意见修改。关于是否接纳本提交的问题，还希望能得到重新评估。 |
All UDP packets are queued into a single channel, and multiple workers are launched to poll the channel in current design. This introduces a problem where UDP packets from a single connection are delivered to different workers, thus forwarded in a random order if workers are on different CPU cores. Though UDP peers normally have their own logic to handle out-of-order packets, this behavior will inevitably cause significant variance in delay and harm connection quality. Furthermore, this out-of-order behavior is noticeable even if the underlying transport could provide guaranteed orderly delivery - this is unacceptable. This commit takes the idea of RSS in terms of NICs: it creates a distinct queue for each worker, hashes incoming packets, and distribute the packet to a worker by hash result. The tuple (SrcIP, SrcPort, DstIP, DstPort, Proto) is used for hashing (Proto is always UDP so it's dropped from final implementation), thus packets from the same connection can be sent to the same worker, keeping the receiving order. Different connections can be hashed to different workers to maintain performance. Performance for single UDP connection is not affected, as there is already a lock in natTable that prevents multiple packets being processed in different workers, limiting single connection forwarding performance to 1 worker. The only performance penalty is the hashing code, which should be neglectable given the footprint of en/decryption work.
HamsterReserved
force-pushed
the
udp-order
branch
from
0a08e49 to
447e8a7
Compare
当前 UDP 转发的实现是，将 UDP 报文收到一个 channel 内，然后启动多个 worker 一并 poll 该 channel. 这样一来，同一条 UDP 连接的包可能被不同的 worker 收走，worker 内又没有保序机制，由于 worker 的异步特性，最终导致发出的 UDP 包乱序。
虽然说 UDP 不提供任何顺序保证，但乱序还是会不可避免地导致上层感受到的延迟经常跳动，还是会影响使用体验。因此，能够避免的乱序还是最好要避免。特别是，即便专门采用了能够保证底层有序的传输通道，这里的问题会导致发出的包仍然乱序，这样也是比较难接受的。
本提交参考网卡的 RSS 机制，将 queue 分为每个 worker 一个，将传入的包的 IP 地址、端口、协议进行哈希（实际因为都是 UDP，所以不再计算协议），然后根据哈希结果将包分配到一个 queue、一个 worker 去处理，这样对于同一条连接的包就可以保证都在一个 worker 中处理，借此解决乱序问题。
性能方面我预计是没有明显影响的，因为以前 natTable 里面每条连接也有锁，导致以前的单连接转发性能也有单 worker 瓶颈。多连接性能至少是不受影响，且因为锁的争抢减少乃至消失，甚至还可能有提升。新引入的哈希代码会有一些开销，但是相比后面的加解密部分，这里的开销应当可以忽略不计。
这基本上算是我第一次接触 Go 语言，如有问题，请不吝赐教。谢谢！