为了获得最大吞吐量,UDP数据包的最佳大小是多少?

备选答案:小心不要重新发明轮子。

TCP是数十年网络经验的产物。它所做的每一件或几乎每一件事都有其原因。它有几种大多数人不常想到的算法(拥塞控制、重传、缓冲区管理、处理重新排序的数据包等等)。

如果你开始重新实现所有的TCP算法,你就有可能以(准相位)结束 Greenspun's Tenth Rule )“临时的、非正式指定的、充满漏洞的、缓慢的TCP实现”。

如果您还没有这样做,那么不妨看看TCP/UDP的一些最新替代方案,比如SCTP或DCCP。它们是为TCP和UDP都不是很好匹配的领域而设计的,正是为了让人们使用已经“调试”好的协议,而不是为每一个新的应用重新发明轮子。

找到理想数据报大小的最佳方法是完全按照TCP本身的方法来找到理想的数据包大小: Path MTU discovery .

TCP还有一个广泛使用的选项,双方都告诉对方他们的MSS(基本上是MTU减去头)是什么。

在c#中查找mtu最简单的解决方法是发送dontfragment标志设置为true的udp数据包。如果它抛出异常,请尝试减小数据包大小。执行此操作,直到没有引发异常为止。你可以从1500个数据包开始。

另一件需要考虑的是一些网络设备不能很好地处理碎片。我们已经看到许多路由器丢弃碎片化的UDP数据包或太大的数据包。建议 CesarB 使用路径MTU是一个好方法。

最大吞吐量不仅取决于数据包大小(当然这也是原因之一)。最小化延迟和最大化吞吐量往往是相互矛盾的。在TCP中,你可以使用Nagle算法,它的设计(部分)是为了提高整体吞吐量。然而,一些协议(例如telnet)通常会禁用Nagle(即设置无延迟位),以改善延迟。

你对数据有实时限制吗?流式音频与推送非实时数据(例如日志信息)不同,前者从低延迟中获益更多,而后者则从提高吞吐量和可靠性中获益。是否有可靠性要求?如果您不能错过数据包,并且必须有一个协议来请求重新传输,这将降低总体吞吐量。

还有很多其他因素会影响到这一点(正如在另一个回复中所建议的),在某个时候,你会得到一个糟糕的TCP实现。这就是说,如果您希望实现低延迟,并且可以使用UDP容忍丢失,并且将总数据包大小设置为路径MTU(确保将有效负载大小设置为考虑报头),则可能是最佳解决方案(尤其是如果您可以确保UDP可以从一端传输到另一端)。

我有一个非MTU的答案给你。使用已连接的UDP套接字可以加快速度。在UDP套接字上调用connect有两个原因。首先是效率。在未连接的UDP套接字上调用sendto时,内核会临时连接套接字,发送数据,然后断开连接。我读到一项研究表明,在发送时,这会占用近30%的处理时间。调用connect的另一个原因是,您可以获取ICMP错误消息。在未连接的UDP套接字上,内核不知道向哪个应用程序传递ICMP错误,因此它们被丢弃。

IP头是>=20字节,但大部分为20字节,UDP报头为8字节。这将为您的数据留下1500-28=1472字节。路径MTU发现在到达目的地的途中找到尽可能最小的MTU。但这并不一定意味着,当你使用最小的MTU时,你将获得最好的性能。我认为最好的方法是做一个基准测试。或者你根本不应该关心路上最小的MTU。网络设备可以很好地使用小型MTU,也可以非常快速地传输数据包。它的价值在未来很可能会发生变化。所以你不能发现它并将其保存到某个地方供以后使用,你必须定期这样做。如果我是你,我会将MTU设置为1440,并对应用程序进行基准测试。。。

即使交换机上的MTU为1500,也可能会出现一些情况(比如通过VPN进行隧道传输),在数据包周围包裹一些额外的报头——你最好稍微减少它们,然后在1450左右。

你能模拟网络并测试不同数据包大小的性能吗?