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

sep*_*sep 38 c++ linux windows udp network-programming

我需要通过可能有损的网络将数据包从一个主机发送到另一个主机.为了最小化数据包延迟,我不考虑TCP/IP.但是,我希望最大化吞吐量uisng UDP.应该使用的UDP数据包的最佳大小是多少?

以下是我的一些注意事项:

  • 网络中交换机的MTU大小为1500.如果我使用大数据包,例如8192,则会导致碎片.丢失一个片段会导致丢失整个数据包,对吧?

  • 如果我使用较小的数据包,我将产生UDP和IP头的开销

  • 如果我使用一个非常大的数据包,我可以使用的最大数据包是多少?我读到最大的数据报大小是65507.我应该使用什么缓冲区大小来发送这样的大小?这有助于提高我的吞吐量吗?

  • 常见操作系统(例如Windows,Linux等)支持的典型最大数据报大小是多少?

更新:

数据的一些接收器是未实现TCP/IP堆栈的嵌入式系统.

我知道这个地方到处都是那些非常喜欢使用可用内容的人.但我希望能得到更好的答案,而不仅仅关注MTU.

Ces*_*arB 19

替代答案:小心不要重新发明轮子.

TCP是数十年网络经验的产物.每一件事或几乎每件事都有共鸣.它有几种大多数人不经常考虑的算法(拥塞控制,重传,缓冲管理,处理重新排序的数据包等).

如果你开始重新实现所有的TCP算法,那么你最终可能会遇到一个(paraphasing Greenspun的第十条规则)"临时的,非正式指定的,错误的,慢速的TCP实现".

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

  • 这是对问题的评论,而不是对问题的回答.有时,您只需要执行此操作,例如出于历史原因:应用程序已使用UDP数十年,并且使用范围正在发生变化,您需要使UDP通信适应新的需求.你不想失去你的团队在应用程序协议中花费数十年的经验,所以它可能看起来像是重新实现了对外界的轮子,而它只是让已经存在的轮子变得更聪明. (11认同)
  • 不是答案."我怎么做A?" - "做B." 我鄙视这种行为. (6认同)
  • @CesarB“某些数据接收器是未实现 TCP/IP 堆栈的嵌入式系统。” 没有可用的锤子。假设如果有人问这样的问题,他们已经仔细考虑了替代方案,并且只有提出的解决方案可用。无视问题的限制是完全不尊重的。 (3认同)

Ces*_*arB 14

找到理想数据报大小的最佳方法是完成TCP本身的工作,以找到理想的数据包大小:路径MTU发现.

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

  • PMTUD的下行是过度热心和不明信息的系统管理员通过禁用其防火墙上的所有ICMP来打破它. (2认同)

Rob*_*nes 5

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


Tim*_*and 1

即使交换机上的 MTU 为 1500,您也可能会遇到在数据包周围包裹一些额外标头的情况(例如通过 VPN 建立隧道) - 您最好稍微减少它们,并将其设置为 1450 左右。

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