互联网上最大的安全UDP包大小是多少

512是您最好的选择。它在其他地方也被使用，是一个不错的偶数(1024的一半)。

UDP报文的最大大小的理论限制(Windows)是65507字节。这是记录在这里:

正确的UDP消息最大大小是65507，由以下公式确定: 0xffff -(sizeof(IP报头)+ sizeof(UDP报头))= 65535-(20+8)= 65507

也就是说，大多数协议限制的大小要小得多——通常是512或偶尔是8192。如果你在一个可靠的网络上，你通常可以安全地超过548，但如果你在整个互联网上广播，你的频率越大，你就越有可能遇到数据包传输问题和丢失。

的确，一个典型的 IPv4报头是20个字节，而UDP报头是8个字节。但是，可以包含IP选项，可以将IP头的大小增加到60字节。此外，有时中间节点需要将数据报封装在另一个协议中，如IPsec(用于vpn等)，以便将数据包路由到目的地。因此，如果你不知道特定网络路径上的MTU，最好为其他你可能没有预料到的头信息留出合理的余地。512字节的UDP有效负载通常被认为是这样做的，尽管即使这样也没有为最大大小的IP报头留下足够的空间。

IPv4 最小的重组缓冲区大小是576,IPv6是1500。从这里减去标题大小。参见由W. Richard Stevens编写的UNIX网络编程:)

576是最小最大重组缓冲区大小，即每个实现必须能够重新组装该大小的至少包。详见Ietf RFC 1122。

考虑到IPV6的大小为1500，我认为运营商不会为IPV4和IPV6提供单独的路径(它们都是不同类型的IP)，迫使它们使用旧的、冗余的、维护成本更高、可靠性更低的IPV4设备。这没有任何意义。此外，这样做可能很容易被认为是为某些流量提供优惠待遇——在他们可能不太关心的规则下(除非他们被抓住)，这是不允许的。

* * * * * * * *更新

各种答案给出软件供应商允许的最大值或假设封装的各种答案。用户并没有要求尽可能低的值(比如安全的UDP大小为“0”)，而是要求最大的安全数据包大小。

各个层的封装值可以被多次包含。因为一旦封装了一个流，就没有什么可以禁止的了，比如说，在它下面有一个VPN层，在它上面有一个完全复制的封装层。

由于这个问题是关于最大安全值的，我假设他们谈论的是可以接收的UDP数据包的最大安全值。由于没有UDP数据包是保证的，如果你收到一个UDP数据包，最大的安全大小将是IPv4上的1个数据包或1472字节。

注意——如果你使用IPv6，最大大小将是1452字节，因为IPv6的报头大小是40字节，IPv4是20字节(无论哪种方式，仍然必须允许8字节的UDP报头)。

本文描述了最大传输单元(MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit。它规定IP主机必须能够处理576字节的IP数据包。然而，它指出，最低是68。RFC 791:“每个互联网模块必须能够转发一个68字节的数据报，而不需要进一步的分片。这是因为一个互联网头可能高达60个字节，而最小的片段是8个字节。

因此，安全数据包大小508 = 576 - 60 (IP头)- 8 (udp头)是合理的。

正如user607811所提到的，其他网络层的碎片必须重新组装。 https://www.rfc-editor.org/rfc/rfc1122#page-56 3.3.2重新组装 IP层必须实现IP数据报的重组。 我们指定可以重新组合的最大数据报大小 通过EMTU_R ("有效MTU接收");有时候 称为“重组缓冲区大小”。EMTU_R必须更大 大于或等于576

UDP最大安全负载是508字节。这是一个576的包大小(“最小最大重组缓冲区大小”)，减去最大60字节的IP头和8字节的UDP头。

任何这种大小或更小的UDP有效载荷都保证可以通过IP传递(尽管不保证传递)。任何更大的值都允许被任何路由器以任何理由直接丢弃。只有ipv6路由例外，ipv6路由最大负载为1212字节。正如其他人所提到的，在某些情况下可以添加额外的协议头。更保守的大约300-400字节的值可能是首选的。

最大可能的UDP负载是67 KB，分成45个IP包，增加额外的900字节的开销(IPv4, MTU 1500，最小20字节的IP头)。

任何UDP报文都可能被分片。但是这不是很重要，因为丢失一个片段和丢失一个未碎片的数据包的影响是一样的:整个数据包被丢弃。使用UDP，这将发生任何一种方式。

^{_{IP报文中包含一个分片偏移字段，表示UDP分片相对于其UDP报文的字节偏移量。该字段是13位的，允许8192个值，这些值以8字节为单位。所以IP包可以引用的偏移量范围是0…65528字节。作为偏移量，我们为最后一个UDP片段添加1480，得到67,008。减去第一个片段中的UDP报头，我们得到了一个漂亮的67 KB}}

来源:RFC 791, RFC 1122, RFC 2460

我在这里读到了一些不错的答案;然而，有一些小错误。有些人回答说，UDP报头中的消息长度字段最大为65535 (0xFFFF);这在技术上是正确的。一些人回答说实际的最大值是(65535 - IPHL - UDPHL = 65507)。错误，是UDP报头中的消息长度字段包括所有有效负载(5-7层)，加上UDP报头的长度(8字节)。这意味着如果消息长度字段是200字节(0x00C8)，有效负载实际上是192字节(0x00C0)。

固定不变的是IP数据报的最大大小是65535字节。这个数字是L3和L4报头加上5-7层有效载荷的总和。IP头+ UDP头+层5-7 = 65535(最大)。

UDP数据报的最大大小最正确的答案是65515字节(0xFFEB)，因为UDP数据报包括UDP头。UDP有效载荷最大大小的最正确答案是65507字节，因为UDP有效载荷不包括UDP头。

我担心我会引起不安的反应，但尽管如此，为了澄清我是否错了，或者那些看到这个问题并对答案感兴趣的人:

我对https://www.rfc-editor.org/rfc/rfc1122的理解，它的地位是“官方规范”。这就是本问题中使用的术语的参考，它既没有被另一个RFC所取代，也没有与以下内容相矛盾的勘误表:

从理论上讲,ie。基于书面规范，像https://www.rfc-editor.org/rfc/rfc1122#section-4所给出的UDP没有“数据包大小”。因此，答案可能是“不确定”;

在实践中，这就是这个问题可能寻求的(以及可以根据当前的技术进行更新)，这可能是不同的，我不知道。

如果我造成了困扰，我道歉。https://www.rfc-editor.org/rfc/rfc1122#page-8“Internet Protocol suite”;和“建筑假设”;别跟我说什么“假设”。我是在，根据我所听到的，层是分开的。Ie。UDP所在的层不必关心IP所在的层(IP层确实有像重组、EMTU_R、碎片和MMS_R (https://www.rfc-editor.org/rfc/rfc1122#page-56)这样的东西)

UDP不是“安全”的，所以问题不是很大-然而-

• 如果你使用的是Mac，默认情况下你可以发送的最大大小是9216字节。
• 如果你在Linux (CentOS/RedHat)或Windows 7上，最大是65507字节。

如果你发送9217或更多(mac)或65508+ (linux/windows)，套接字发送函数返回一个错误。

上面讨论碎片和MTU等问题的答案都离题了——所有这些都发生在较低的水平上，是“看不见的”。对你，不影响“安全”;对典型连接的影响很大。

要回答实际的问题意义 -不要使用UDP -使用原始套接字，这样你就可以更好地控制一切;因为你是在编写一款游戏，所以你需要深入研究标志以获得流量的优先级，所以你也可以同时摆脱UDP问题。

根本没有。

我将完全撇开任何“UDP是最好的努力”的推理，只关注“最大安全UDP数据包大小”，这意味着“小到足以完全避免路径上的任何碎片”。

重要背景:

在没有分片的情况下，你唯一可以依赖的可传输的数据包大小是IPv4的24字节和IPv6的56字节，因为一个分片的最小IP头是20/48字节(v4/v6)，并且一个分片必须至少有4/8字节(v4/v6)的有效载荷数据。因此，IP层以下的传输系统不能传输至少这些大小的数据包，不能用于传输IP流量。——回答“UDP中的MTU 65507如何?”。

根据上面的答案，这是因为在这样的长度下，IP分片机制无法运行——它只能生成单个分片。

．.． IP标准要求每个IP主机能够接收总大小为576字节的IP数据包....然而，请注意，标准并没有说576没有分片，因此即使是576字节的IP数据包也可能在两台主机之间(源和目的地之间路径的某个位置)发现自己被分片了。

因此，任何比互联网协议可能做的最小值更大的东西，实际上可能会发现自己被“无形地”临时封装到路径上的某个地方，仅仅高于限制，即使你选择了最小的UDP有效载荷，这将是:576 - 8 (UDP报头)- 20 (IPv4)或40 (IPv6) = 528的min(以防你不确定是v4还是v6将被使用)。

您可能试图避免碎片化的一个原因是，它确实增加了数据包完整丢失的可能性。更多的数据包，仅仅是由于更高的开销，就意味着更大的失败可能性，更不用说每个数据包(甚至是一个片段)代表着另一个丢失的“机会”。当然，如果它碰巧被传递给某个链接，因为它太大而丢弃它……

操作系统级别的TCP实现尝试在TCP层中选择最高的安全MTU，包括有时动态地处理它，因为源和目的地之间的部分路径可能逐包不同。

对于UDP，这整个问题也变成了你的:它不是那么简单，只是“使用最大的，肯定不会碎片”。

RFC2460第5节是这么说的(关于IPv6的最小MTU)。

IPv6要求internet上的每条链路的MTU值为1280 八位或更大。在任何不能传输1280字节的链路上 数据包在一块，链路特定的碎片和重组必须

因此碎片也可以发生在IP级别下，在路径上的两个主机之间的特定链接决定将其碎片化，然后可能将碎片推到平行管道中…在这条链路的另一端把它们重新组装成一个数据包。

如果这些片段的顺序不正确，那么记录机制可能会错误地重新组装数据包，甚至没有意识到它重新排序了其中的一部分。

当然，如果硬件坚持IP规范，它应该能够通过检查IP报头的片段偏移部分来注意到数据包无序，但是大多数链路协议只是按照接收的顺序重新组装片段，而不担心无序的数据包接收。

现在，如果“较低水平”的互连本身被用作网络……例如，在一个大型开关的核心内部，那么在重载和许多并行路径下，这些碎片可能在重新组装之前就失去了秩序。

这是超级邪恶的，但可能有时确实会发生，导致偶尔仍然交付，但严重损坏的数据包，仍然通过简单的基于xor的校验和测试……这恰好是IP校验和是。

TCP只是设置“不分片”并处理它，但UDP留下了清晰的bit…所以如果你使用UDP，你也应该假设你的字节流有时可能会被重新排序，甚至在数据包中…所以你应该使用校验和方法来验证你的数据，这个方法可以捕捉到重新排序。

大多数链路无论如何都会做1500 MTU，但链路层有不同的最小和最大数据报大小:

• 以太网:64到1500(或更高，具有更高的MTU能力)
• ATM: 53字节/数据报
• 帧中继:46 ~ 4470字节 李(ref: IP分片被打破 < / >

不幸的是，UDP头本身是8字节…所以这意味着，唯一大小的UDP有效载荷可以当然避免碎片…是零!(并且无论如何只适合最小的IPv6数据包)。

最好的/合理的过程可能是使用512为你的UDP数据报而且做你自己的检查数据报中的数据无序，以及处理数据包到达无序。(也就是说，完全不依赖IP为你丢弃坏掉的数据包)。

udp有不同的最大值。最后，这是你的选择，你认为足够安全的限制。注意:UDP本身是不安全的，因此您的数据包可能在任何时候丢失。

注意:所有这些都有一个范围。具体有多大取决于你的IP选项。一般情况下，可以这样计算:[upper maximum]-[IP-Options长度，以字节为单位]。这里列出的所有范围都不包括UDP-Header(8字节)

最小最大传输限制(或类似的东西，我忘记了实际的名称，在任何地方都找不到它):512-552字节

这可能是最安全的尺寸。IPv4协议要求所有跳来传输这个大小的数据包，更大的数据包可能在任何时间被任何主机丢弃。

最大传输单元:1432-1472:

这种大小的数据包可以在单个以太网帧中发送，而不会被分割。任何一个片段的丢失都会导致整个数据包无用。因此，当超过这个限制时，由于单个片段的碎片和潜在损失，您的数据包变得无用的机会增加。

绝对限制:65467-65507:

没有数据包可以超过这个限制，因为在这个限制下，IPv4协议达到了它的全部潜力。不能发送更大的数据包。这是因为IPv4协议只保留2个字节(16位)作为总长度。将所有这些位都设置为1，就得到65535。减去IP(20-60字节)和UDP头(8字节)，就得到了这个限制。这种大小的数据包将导致至少44个片段。请记住，这些片段中的任何一个丢失都会导致整个包无用。