提高UDP可靠性

Question

我正在建立一个小型的基于UDP的服务器。服务器是基于.Net的，并使用它自己的Socket类。我正在通过ReceiveMessageFromAsync和异步发送使用完成端口。

我的问题是我失去了大约5%-10%的流量。现在我知道这是正常的，但是有什么方法可以改善这个统计数据吗？

Answer 1

在把自己的可靠性层放在UDP之上之前，你可能想看看这个问题的答案……What do you use when you need reliable UDP?

或者，您可以尝试在开始recv之前设置适当的套接字选项，通过使套接字的send和recv缓冲区尽可能大来增加通过的数据量。

Answer 2

确保发送的UDP数据报不要大于路径MTU (通常不超过~1400字节，有时甚至更少)。这样的数据包将被分割成多个IP数据包，并在目的地重新组装-如果这些片段中的任何一个丢失，则整个UDP数据报将被丢弃。

这对丢包率有放大作用-此表显示了UDP数据报丢失率如何随着用于承载它的片段数量的增加而急剧上升：

Underlying Fragment Loss Rate: 1.00%

Fragments   UDP Datagram Loss Rate
--------------------------------------
1           1.00%
2           1.99%
3           2.97%
4           3.94%
5           4.90%
6           5.85%
7           6.79%
8           7.73%
9           8.65%
10          9.56%
15          13.99%
20          18.21%
30          26.03%
40          33.10%

Answer 3

套接字的Windows体系结构似乎不利于良好的UDP性能，因为从内核通过协议处理程序多次复制数据包缓冲区到应用程序。如果开发人员想要合理的数据报性能，比如实现可靠的Winsock Kernel协议，MSDN似乎更喜欢将开发人员指向Transport Driver Interface (WSK)，取代以前的TDI (TDI)。

然而，它可能只是你的NIC硬件的非优秀的Windows驱动程序，因为我在使用Broadcom硬件的Linux上看到了很好的性能，但在Windows中的性能还不到25%。我可以看到其中的一些原因是由于缺乏传输中断合并，Windows性能监控总是报告0个传输合并，但一个可变范围的接收。在Linux上，我可以调优合并，并看到明显的性能变化。Broadcom的驱动程序软件似乎仅在更高的硬件版本上支持传输合并。

合并意味着数据包成批地传入和传出NIC，批处理数据包通常意味着更低的CPU使用率和由于满缓冲区或其他系统活动而丢弃的机会。

因此，虽然看起来改变操作系统是不切实际的，但你可以尝试不同的硬件来最小化有限驱动程序的影响。