免责声明 ：这不是一个“如何”的问题。 我想更多地了解，作为背景信息，实际使用的实际操作有何不同。
我们知道UDP没有像TCP这样的PMTU发现。 所以我看到几种避免使用UDP进行IP分片的方法：
最多发送512字节数据包（UDP方法） 重新实现一些PMTU（使用ICMP“需要碎片化”消息）。 依赖于本地MTU（但可靠性有多远，因为UDP不是连接协议，它如何知道其数据包将通过哪个接口？） 其他... ？那么我想要的是对当前UDP程序/协议正在使用哪些方法的“背景”概念，特别是关于流/ VoIP常见应用程序？
谢谢提前，
乔斯林
Disclaimer : this is not a "how to" question. I would more like to know, as a background information what are the different actual practices actually used.
We know that UDP does not have a PMTU discovery like TCP. So I see several approaches to avoid IP fragmentation with UDP :
Sending 512 bytes packets max (the UDP approach) re-implementing some PMTU (using ICMP "needs fragmentation" message). Relying on local MTU (but how far is it reliable, as UDP isn't a connected protocol, how can it knows which interface its packets are going to go through ?) others... ?So what I would like is to have a "background" idea of which approaches are being used by current UDP programs/protocols, especially regarding streaming/VoIP common applications ?
Thanks by advance,
Jocelyn
最满意答案
限制为576个字节非常常见。 大多数Internet协议（如DNS）都是这样做的。 大多数实时流媒体协议也使用较小的数据包，因为它具有提供较低的序列化延迟和在单个数据包丢失时影响较小的额外好处。
一些协议具有协商更大分组大小的方式，但通常不像PMTU发现那样健壮（DHCP，例如允许最大消息大小协商）。
还有一些默认为1500左右的东西，并允许用户在必要时降低它。 大多数SNMP的实现似乎都是这样的。
无论如何，DF位通常不会被设置，因此过于乐观的结果是碎片，而不是破碎。
Limiting to 576 bytes is very common. Most of the Internet protocols such as DNS do this. Most real-time streaming protocols also use smaller packets since it has the added benefit of providing lower serialization delay and less impact if a single packet is lost.
Some protocols have ways of negotiating a larger packet size, though often not in a way that's as robust as PMTU discovery (DHCP, for example allows a maximum message size negotiation).
There's also stuff that defaults to 1500 or so and lets the user lower it if necessary. Most implementations of SNMP seem to do something like this.
In any event, the DF bit isn't generally set, so the consequence of being overly optimistic is fragmentation, not brokenness.
更多推荐
发布评论