windows 最大限度地提高 udp 的性能
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3309854/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Maximizing performance on udp
提问by EricBenDavid
im working on a project with two clients ,one for sending, and the other one for receiving udp datagrams, between 2 machines wired directly to each other.
each datagram is 1024byte in size, and it is sent using winsock(blocking).
they are both running on a very fast machines(separate). with 16gb ram and 8 cpu's, with raid 0 drives.
im looking for tips to maximize my throughput , tips should be at winsock level, but if u have some other tips, it would be great also.
currently im getting 250-400mbit transfer speed. im looking for more.
thanks.
我正在处理一个有两个客户端的项目，一个用于发送，另一个用于接收 udp 数据报，在两台直接相互连接的机器之间。每个数据报大小为 1024 字节，使用 winsock（阻塞）发送。他们都在非常快的机器上运行（单独的）。带有 16GB 内存和 8 个 CPU，带有 RAID 0 驱动器。
我正在寻找最大化我的吞吐量的技巧，技巧应该在 winsock 级别，但如果你有其他一些技巧，它也会很棒。
目前我获得了 250-400mbit 的传输速度。我正在寻找更多。
谢谢。
回答by nategoose
Since I don't know what else besides sending and receiving that your applications do it's difficult to know what else might be limiting it, but here's a few things to try. I'm assuming that you're using IPv4, and I'm not a Windows programmer.
由于我不知道除了发送和接收您的应用程序之外还有什么，所以很难知道还有什么可能会限制它，但这里有一些事情可以尝试。我假设您使用的是 IPv4，而且我不是 Windows 程序员。
Maximize the packet size that you are sending when you are using a reliable connection. For 100 mbs Ethernet the maximum packet is 1518, Ethernet uses 18 of that, IPv4 uses 20-64 (usually 20, thought), and UDP uses 8 bytes. That means that typically you should be able to send 1472 bytes of UDP payload per packet.
当您使用可靠连接时，最大化您发送的数据包大小。对于 100 mbs 以太网，最大数据包为 1518，以太网使用其中的 18 个，IPv4 使用 20-64（通常为 20，认为），UDP 使用 8 个字节。这意味着通常您应该能够为每个数据包发送 1472 字节的 UDP 有效负载。
If you are using gigabit Ethernet equiptment that supports it your packet size increases to 9000 bytes (jumbo frames), so sending something closer to that size should speed things up.
如果您使用支持它的千兆以太网设备，您的数据包大小会增加到 9000 字节（巨型帧），因此发送更接近该大小的内容应该会加快速度。
If you are sending any acknowledgments from your listener to your sender then try to make sure that they are sent rarely and can acknowledge more than just one packet at a time. Try to keep the listener from having to say much, and try to keep the sender from having to wait on the listener for permission to keep sending.
如果你从你的听众向你的发件人发送任何确认，那么试着确保它们很少被发送，并且一次可以确认不止一个数据包。尽量让听者不必说太多，并尽量让发送者不必等待听者的许可才能继续发送。
On the computer that the sender application lives on consider setting up a static ARP entry for the computer that the receiver lives on. Without this every few seconds there may be a pause while a new ARP request is made to make sure that the ARP cache is up to date. Some ARP implementations may do this request well before the ARP entry expires, which would decrease the impact, but some do not.
在发送方应用程序所在的计算机上，考虑为接收方所在的计算机设置静态 ARP 条目。如果不这样做，每隔几秒钟可能会暂停，同时发出新的 ARP 请求以确保 ARP 缓存是最新的。一些 ARP 实现可能会在 ARP 条目过期之前很好地执行此请求，这会减少影响，但有些则不会。
Turn off as many users of the network as possible. If you are using an Ethernet switch then you should concentrate on the things that will introduce traffic to/from the computers/network devices on which your applications are running reside/use (this includes broadcast messages, like many ARP requests). If it's a hub then you may want to quiet down the entire network. Windows tends to send out a constant stream of junk to networks which in many cases isn't useful.
关闭尽可能多的网络用户。如果您使用的是以太网交换机，那么您应该专注于将流量引入/来自您的应用程序运行所在/使用的计算机/网络设备的事情（这包括广播消息，如许多 ARP 请求）。如果它是一个集线器，那么您可能希望使整个网络安静下来。Windows 倾向于向网络发送源源不断的垃圾信息，这在许多情况下是无用的。
There may be limits set on how much of the network bandwidth that one application or user can have. Or there may be limits on how much network bandwidth the OS will let it self use. These can probably be changed in the registry if they exist.
一个应用程序或用户可以拥有多少网络带宽可能会受到限制。或者，操作系统将允许其自行使用的网络带宽可能会受到限制。如果它们存在，这些可能可以在注册表中更改。
It is not uncommon for network interface chips to not actually support the maximum bandwidth of the network all the time. There are chips which may miss packets because they are busy handling a previous packet as well as some which just can't send packets as close together as Ethernet specifications would allow. Additionally the rest of the system might not be able to keep up even if it is.
网络接口芯片实际上并不一直支持网络的最大带宽并不少见。有些芯片可能会因为忙于处理先前的数据包而错过数据包，还有一些芯片无法像以太网规范所允许的那样紧密地发送数据包。此外，系统的其余部分即使是这样也可能无法跟上。
回答by Nikolai Fetissov
Some things to look at:
需要注意的一些事项：
- Connected UDP sockets(some info) shortcut several operations in the kernel, so are faster (see Stevens UnP book for details).
- Socket send and receive buffers- play with
SO_SNDBUFandSO_RCVBUFsocket options to balance out spikes and packet drop - See if you can bump up link MTUand use jumbo frames.
回答by ariso
use 1Gbps network and upgrade your network hardware...
使用 1Gbps 网络并升级您的网络硬件...
回答by Steve-o
Test the packet limit of your hardware with an already proven piece of code such as iperf:
使用已经验证过的代码段（例如 iperf）测试硬件的数据包限制：
http://www.noc.ucf.edu/Tools/Iperf/
http://www.noc.ucf.edu/Tools/Iperf/
I'm linking a Windows build, it might be a good idea to boot off a Linux LiveCD and try a Linux build for comparison of IP stacks.
我正在链接 Windows 版本，启动 Linux LiveCD 并尝试 Linux 版本以比较 IP 堆栈可能是个好主意。
More likely your NIC isn't performing well, try an Intel Gigabit Server Adapter:
更可能是您的 NIC 性能不佳，请尝试使用英特尔千兆服务器适配器：
http://www.intel.com/network/connectivity/products/server_adapters.htm
http://www.intel.com/network/connectivity/products/server_adapters.htm
回答by Len Holgate
As well as Nikolai's suggestion of send and recv buffers, if you can, switch to overlapped I/O and have many recvs pending, this also helps to minimise the number of datagrams that are dropped by the stack due to lack of buffer space.
除了 Nikolai 的 send 和 recv 缓冲区的建议，如果可以，切换到重叠 I/O 并有许多 recvs 挂起，这也有助于最大限度地减少由于缺乏缓冲区空间而被堆栈丢弃的数据报数量。
If you're looking for reliable data transfer, consider UDT.
如果您正在寻找可靠的数据传输，请考虑UDT。
回答by Amardeep AC9MF
For TCP connections it has been shown that using multiple parallel connections will better utilize the data connection. I'm not sure if that applies to UDP, but it might help with some of the latency issues of packet processing.
对于 TCP 连接，已经表明使用多个并行连接将更好地利用数据连接。我不确定这是否适用于 UDP，但它可能有助于解决数据包处理的一些延迟问题。
So you might want to try multiple threads of blocking calls.
所以你可能想尝试多线程阻塞调用。
