互联网上最大的安全 UDP 数据包大小是多少
我读过很多关于 UDP 数据包大小的文章，但无法得出正确的结论。
许多服务将最大 UDP 数据包限制为 512 字节（如 dns）
给定最小 MTU 为 576 ，IPv4 标头大小为 20 字节，UDP 标头大小为 8 字节。 这留下了 548 字节可用于用户数据
我是否能够使用最大 548 字节的数据包而不产生数据包碎片？ 或者 DNS 的创建者是否知道什么，以及为什么他们将其限制为 512 字节。
我什至可以安全地超过 548 字节吗？
I've read a number of articles about UDP packet sizes but have been unable to come to a conclusion on whats correct.
A number of services restrict the largest UDP packet to 512 bytes (like dns)
Given the minimum MTU on the internet is 576 , and the size of the IPv4 header is 20 bytes, and the UDP header 8 bytes. This leaves 548 bytes available for user data
Would I be able to use packets up to the size of 548 without packet fragmentation? Or is there something the creators of DNS knew about, and that why they restricted it to 512 bytes.
Could I even go higher than 548 bytes safely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
确实，典型 IPv4 标头为 20 字节，而 UDP 标头为 8 字节。 然而，可以包含 IP 选项，这些选项可以将 IP 标头的大小增加到多达 60 字节。 此外，有时中间节点需要将数据报封装在另一个协议中，例如 IPsec（用于 VPN 等），以便将数据包路由到其目的地。 因此，如果您不知道特定网络路径上的 MTU，最好为您可能没有预料到的其他标头信息留出合理的余量。 通常认为 512 字节的 UDP 有效负载可以做到这一点，尽管即使这样也没有为最大尺寸的 IP 标头留下足够的空间。
It is true that a typical IPv4 header is 20 bytes, and the UDP header is 8 bytes. However it is possible to include IP options which can increase the size of the IP header to as much as 60 bytes. In addition, sometimes it is necessary for intermediate nodes to encapsulate datagrams inside of another protocol such as IPsec (used for VPNs and the like) in order to route the packet to its destination. So if you do not know the MTU on your particular network path, it is best to leave a reasonable margin for other header information that you may not have anticipated. A 512-byte UDP payload is generally considered to do that, although even that does not leave quite enough space for a maximum size IP header.
最大安全 UDP 有效负载为 508 字节。这是数据包大小 576（“最小最大重组缓冲区大小”）减去最大 60 字节 IP 标头和 8 字节 UDP 标头。
保证可以通过 IP 传送任何此大小或更小的 UDP 有效负载（尽管不保证传送）。 任何更大的东西都可以被任何路由器出于任何原因彻底丢弃。 仅限 IPv6 的路由除外，最大有效负载为 1,212 字节。 正如其他人提到的，在某些情况下可以添加额外的协议头。 可能会首选 300-400 字节左右的更保守的值。
最大可能的 UDP 负载为 67 KB，分为 45 个 IP 数据包，额外增加 900 字节的开销（IPv4、MTU 1500、最小 20 字节 IP 标头）。
任何 UDP 数据包都可能被分段。但这并不是太重要，因为丢失分段与丢失未分段的数据包具有相同的效果：整个数据包都会被丢弃。 对于 UDP，这两种情况都会发生。
IP 数据包包含片段偏移字段，该字段指示 UDP 片段相对于其 UDP 数据包的字节偏移。 该字段为 13 位，允许 8,192 个值，以 8 字节为单位。 因此，IP 数据包可以引用的此类偏移量的范围是 0...65,528 字节。 作为偏移量，我们为最后一个 UDP 片段添加 1,480，得到 67,008。 减去第一个片段中的 UDP 标头，我们得到了一个不错的 67 KB。
来源：RFC 791、RFC 1122、RFC 2460
The maximum safe UDP payload is 508 bytes. This is a packet size of 576 (the "minimum maximum reassembly buffer size"), minus the maximum 60-byte IP header and the 8-byte UDP header.
Any UDP payload this size or smaller is guaranteed to be deliverable over IP (though not guaranteed to be delivered). Anything larger is allowed to be outright dropped by any router for any reason. Except on an IPv6-only route, where the maximum payload is 1,212 bytes. As others have mentioned, additional protocol headers could be added in some circumstances. A more conservative value of around 300-400 bytes may be preferred instead.
The maximum possible UDP payload is 67 KB, split into 45 IP packets, adding an additional 900 bytes of overhead (IPv4, MTU 1500, minimal 20-byte IP headers).
Any UDP packet may be fragmented. But this isn't too important, because losing a fragment has the same effect as losing an unfragmented packet: the entire packet is dropped. With UDP, this is going to happen either way.
IP packets include a fragment offset field, which indicates the byte offset of the UDP fragment in relation to its UDP packet. This field is 13-bit, allowing 8,192 values, which are in 8-byte units. So the range of such offsets an IP packet can refer to is 0...65,528 bytes. Being an offset, we add 1,480 for the last UDP fragment to get 67,008. Minus the UDP header in the first fragment gives us a nice, round 67 KB.
Sources: RFC 791, RFC 1122, RFC 2460
UDP 数据包最大大小的理论限制（在 Windows 上）为 65507 字节。 这是记录在此处：
也就是说，大多数协议限制为更小的大小 - 通常为 512 或偶尔为 8192。您通常可以更高如果您使用的是可靠的网络，则比 548 安全 - 但如果您在整个互联网上进行广播，则规模越大，遇到数据包传输问题和丢失的可能性就越大。
The theoretical limit (on Windows) for the maximum size of a UDP packet is 65507 bytes. This is documented here:
That being said, most protocols limit to a much smaller size - usually either 512 or occasionally 8192. You can often go higher than 548 safely if you are on a reliable network - but if you're broadcasting across the internet at large, the larger you go, the more likely you'll be to run into packet transmission problems and loss.
576 是最小最大重组缓冲区大小，即每个实现必须能够至少重组该大小的数据包。 有关详细信息，请参阅 IETF RFC 1122。
576 is the minimum maximum reassembly buffer size, i.e. each implementation must be able to reassemble packets of at least that size. See IETF RFC 1122 for details.
本文介绍了最大传输单元 (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit。 它规定 IP 主机必须能够处理 IP 数据包的 576 字节。 然而，它指出最小值为 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数据报的重组。
我们指定可以重组的最大数据报大小
by EMTU_R（“接收的有效MTU”）； 这有时是
称为“重组缓冲区大小”。 EMTU_R 必须更大
大于或等于576
This article describes maximum transmission unit (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit. It states that IP hosts must be able to process 576 bytes for an IP packet. However, it notes the minumum is 68. RFC 791: "Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets."
Thus, safe packet size of 508 = 576 - 60 (IP header) - 8 (udp header) is reasonable.
As mentioned by user607811, fragmentation by other network layers must be reassembled.
https://www.rfc-editor.org/rfc/rfc1122#page-56
3.3.2 Reassembly
The IP layer MUST implement reassembly of IP datagrams.
We designate the largest datagram size that can be reassembled
by EMTU_R ("Effective MTU to receive"); this is sometimes
called the "reassembly buffer size". EMTU_R MUST be greater
than or equal to 576
IPv4 最小重组缓冲区大小为 576，IPv6 为 1500。从此处减去标头大小。 请参阅 W. Richard Stevens 的《UNIX 网络编程》 :)
IPv4 minimum reassembly buffer size is 576, IPv6 has it at 1500. Subtract header sizes from here. See UNIX Network Programming by W. Richard Stevens :)
我在这里读到了一些很好的答案； 然而，有一些小错误。 有人回答说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 标头。
I've read some good answers here; however, there are some minor mistakes. Some have answered that the Message Length field in the UDP header is a max of 65535 (0xFFFF); this is technically true. Some have answered that the actual maximum is (65535 - IPHL - UDPHL = 65507). The mistake, is that the Message Length field in the UDP Header includes all payload (Layers 5-7), plus the length of the UDP Header (8 Bytes). What this means is that if the message length field is 200 Bytes (0x00C8), the payload is actually 192 Bytes (0x00C0).
What is hard and fast is that the maximum size of an IP datagram is 65535 Bytes. This number is arrived at the sum total of the L3 and L4 headers, plus the Layers 5-7 payload. IP Header + UDP Header + Layers 5-7 = 65535 (Max).
The most correct answer for what is the maximum size of a UDP datagam is 65515 Bytes (0xFFEB), as a UDP datagram includes the UDP header. The most correct answer for what is the maximum size of a UDP payload is 65507 Bytes, as a UDP Payload does not include the UDP header.
512是你最好的选择。 它在其他地方使用，并且是一个很好的偶数（1024 的一半）。
512 is your best bet. It's used elsewhere and is a nice even number (half of 1024).
鉴于 IPV6 的大小为 1500，我断言运营商不会为 IPV4 和 IPV6 提供单独的路径（它们都是不同类型的 IP），迫使他们使用旧的、冗余的、维护成本更高的 ipv4 设备并且不太可靠。 这没有任何意义。 此外，这样做很容易被认为是对某些流量提供优惠待遇——根据他们可能不太关心的规则，不可以（除非他们被抓住）。
因此 1472 对于外部使用来说应该是安全的（尽管这并不意味着像 DNS 这样不了解 EDNS 的应用程序会接受它），如果您正在谈论内部网络，那么您更有可能知道您的网络布局，在这种情况下巨型数据包大小适用于非碎片数据包，因此为 4096 - 4068 字节，对于具有 9014 字节缓冲区的英特尔卡，数据包大小为 ...
等等...8086 字节，将是最大...巧合？ 窃笑
****更新****
各种答案给出了 1 个软件供应商允许的最大值或假设封装的各种答案。 用户没有要求尽可能的最小值（例如安全 UDP 大小的“0”），而是最大的安全数据包大小。
各个层的封装值可以包含多次。 因为一旦你封装了一个流——就没有什么可以禁止，比如说，在它下面的VPN层和在它上面的封装层的完全重复。
由于问题是关于最大安全值，我假设他们正在谈论可以接收的 UDP 数据包的最大安全值。 由于无法保证 UDP 数据包，因此如果您收到 UDP 数据包，最大安全大小将为 IPv4 上的 1 个数据包或 1472 字节。
注意 - 如果您使用 IPv6，则最大大小将为 1452 字节，因为 IPv6 的标头大小为 40 字节，而 IPv4 的标头大小为 20 字节（无论哪种方式，仍必须允许 UDP 标头使用 8 字节）。
Given that IPV6 has a size of 1500, I would assert that carriers would not provide separate paths for IPV4 and IPV6 (they are both IP with different types), forcing them to equipment for ipv4 that would be old, redundant, more costly to maintain and less reliable. It wouldn't make any sense. Besides, doing so might easily be considered providing preferential treatment for some traffic -- a no no under rules they probably don't care much about (unless they get caught).
So 1472 should be safe for external use (though that doesn't mean an app like DNS that doesn't know about EDNS will accept it), and if you are talking internal nets, you can more likely know your network layout in which case jumbo packet sizes apply for for non-fragmented packets so for 4096 - 4068 bytes, and for intel's cards with 9014 byte buffers, a package size of ...
wait...8086 bytes, would be the max...coincidence? snicker
****UPDATE****
Various answers give maximum values allowed by 1 SW vendor or various answers assuming encapsulation. The user didn't ask for the lowest value possible (like "0" for a safe UDP size), but the largest safe packet size.
Encapsulation values for various layers can be included multiple times. Since once you've encapsulated a stream -- there is nothing prohibiting, say, a VPN layer below that and a complete duplication of encapsulation layers above that.
Since the question was about maximum safe values, I'm assuming that they are talking about the maximum safe value for a UDP packet that can be received. Since no UDP packet is guaranteed, if you receive a UDP packet, the largest safe size would be 1 packet over IPv4 or 1472 bytes.
Note -- if you are using IPv6, the maximum size would be 1452 bytes, as IPv6's header size is 40 bytes vs. IPv4's 20 byte size (and either way, one must still allow 8 bytes for the UDP header).
UDP 并不“安全”，因此问题并不大 - 但是 -
如果发送 9217 或更多 (mac) 或 65508+ (linux/windows)，套接字发送函数将返回错误。
上面讨论碎片和 MTU 等问题的答案是题外话 - 所有这些都发生在较低级别，对您来说是“不可见的”，并且不会在很大程度上影响典型连接的“安全性”。
要回答实际问题的含义，尽管 - 不要使用 UDP - 使用原始套接字，这样你就可以更好地控制一切； 由于您正在编写游戏，因此无论如何您都需要深入研究标志以获得流量的优先级，因此您最好同时摆脱 UDP 问题。
UDP is not "safe", so the question is not great - however -
If you send 9217 or more (mac) or 65508+ (linux/windows), the socket send function returns with an error.
The above answers discussing fragmentation and MTU and so on are off topic - that all takes place at a lower level, is "invisible" to you, and does not affect "safety" on typical connections to a significant degree.
To answer the actual question meaning though - do not use UDP - use raw sockets so you get better control of everything; since you're writing a game, you need to delve into the flags to get priority into your traffic anyhow, so you may as well get rid of UDP issues at the same time.
没有一个。
我将完全搁置任何“UDP 是尽力而为”的推理，而只关注“最大安全 UDP 数据包大小”，其含义是“足够小以绝对避免路径上某处出现任何碎片”。
重要背景：
根据上面的答案，这是因为在这个长度下，IP 分片机制无法运行 - 它只能生成单个分片。
因此，任何大于互联网协议可能做到的最小的东西，实际上都可能会发现自己碎片化，因为它被“无形地”暂时封装到路径上某处的限制之上，即使您选择了最小 UDP 有效负载，这将是： 576 - 8（对于 UDP 标头） - 20 (IPv4) 或 40 (IPv6) = 528 的最小值（如果您不确定是否使用 v4 或 v6）。
您可能试图避免碎片的一个原因是，它确实增加了数据包整体丢失的可能性。 更多的数据包，仅仅由于更高的开销，就意味着更大的失败可能性，更不用说每个数据包（甚至是一个片段）都代表着另一个丢失的“机会”。 当然，如果它碰巧被传递到某个链接，该链接就会因为太大而将其丢弃...
操作系统级别的 TCP 实现会尝试在 TCP 层中选择最高安全的 MTU，包括处理它的动态变化有时，源和目标之间的路径部分可能因数据包而异。
对于 UDP，这整个问题也变成了你的问题：而且它并不像“使用最大的肯定不会碎片”那么简单。
RFC2460 第 5 节有这样的说法（关于 IPv6 的最小 MTU） 。
因此，碎片也可能发生在 IP 级别之下，其中沿路径的两个主机之间的特定链接决定将其碎片化，然后可能将碎片推入平行管道......将它们重新组装成一个数据包位于该链路的另一端。
如果这些片段出现乱序，则重新排序机制可能会错误地重新组装数据包，甚至没有意识到它对其中的一部分进行了重新排序。
当然，如果硬件遵循 IP 规范，它应该能够通过检查 IP 标头的片段偏移部分来注意到数据包乱序，但大多数链路协议只是按照收到的顺序重新组装片段，不用担心数据包接收乱序。
现在，如果“较低层”互连本身用作网络......例如在大型交换机的核心内，那么在重负载和许多并行路径下，这些碎片可能会脱离网络重新组装前订购。
这是超级邪恶的，但有时可能确实会发生，导致偶尔仍然传送但严重损坏的数据包，它仍然通过简单的基于异或的校验和测试......这恰好是 IP 校验和 。
TCP 只是设置“不分段”并处理它，但 UDP 保留了这一点...因此，如果您使用 UDP，您还应该假设您的字节流有时可能会重新排序，即使在数据包内也是如此。因此，您应该使用可以捕获重新排序的校验和方法来验证您的数据。
无论如何，大多数链路都会执行 1500 MTU，但链路层具有不同的最小和最大数据报大小：
（参考：IP 碎片已损坏
不幸的是，UDP 标头本身是 8 ...所以这意味着，可以肯定避免碎片的唯一大小是零（并且只能容纳尽可能小的 IPv6 数据包）。
字节 当然可能是对 UDP 数据报使用 512，并自行检查数据报中的数据是否无序，以及处理无序到达的数据包（即，不要依赖于 UDP 数据报）。全部在 IP 上，为您丢弃损坏的数据包）。
There isn't one.
I'm going to set aside entirely any 'UDP is best effort' reasoning, and just focus on 'maximum safe UDP packet size' taken as meaning 'small enough to absolutely avoid any fragmentation somewhere along the path'.
For important background:
According to the answer above, this is because at that length, the IP fragmentation mechanism cannot operate - it could only generate a single fragment anyway.
So anything bigger than the smallest the internet protocol could possibly do, could in fact find itself fragmented due to being 'invisibly' temporarily encapsulated to just above the limit somewhere along the path, even if you chose the minimum UDP payload, which would be: 576 - 8 (for UDP header) - 20 (IPv4) or 40 (IPv6) = min of 528 (in case you are not sure whether v4 or v6 will be used).
A reason you might be trying to avoid fragmentation, is that it does increase the likelyhood that the packet will go missing in it's entirety. More packets, just due to the higher overhead, would mean greater likelyhood of failure, let alone that each packet (even a fragment) represents another 'chance' to be lost. Of course, if it happens to be handed on to some link that just drops it for being too big...
TCP implementations at OS level do things to try to pick the highest safe MTU within the TCP layer, including dealing with it dynamically changing sometimes, as parts of the path between source and destination can differ packet-by-packet.
For UDP, this whole problem becomes yours also: And it's not so simple as just 'use the largest that will certainly not fragment'.
RFC2460 section 5 has this to say (about minimum MTU for IPv6).
Therefore fragmentation can also happen at beneath the IP level, where a particular link between two hosts along the path decides to fragment it, then may shove the fragments down parallel pipes... to have them reassembled into one packet at the other end of that one link.
If there is an out-of-ordering of those fragments, that reording mechanism might reassemble the packet incorrectly, without even realizing that it reordered part of it.
Of course, if the hardware was sticking to the IP specification, it should be able to notice that the packets got out of order by inspecting the fragment offset part of the IP header, but most link protocols just reassemble the fragments in the order received, without worrying about out-of-order packet reception.
Now if that 'lower level' interconnect is itself used as a network... such as within the core of a large switch, for instance, then it might be possible that under heavy loads and many parallel paths, such fragments might get out of order before reassembly.
This is super evil, but probably does happen sometimes, leading to the occasional still-delivered and yet badly-mangled packet, which still passes a simple xor-based checksum test... Which happens to be what the IP checksum is.
TCP just sets 'do not fragment' and deals with it, but UDP leaves that bit clear... so if you're using UDP, you should also assume it possible that your stream of bytes might sometimes get reordered even within packets... and so you should verify your data using a checksum method that will catch reordering.
Most links will do 1500 MTU anyway, but link layer have different minimum and maximum datagram sizes:
(ref: IP fragmentation is broken
Unfortunately, the UDP header itself is 8 bytes... so this means, that the only size UDP payload that could certainly avoid fragmentation... is zero! (and will only fit in the smallest possible IPv6 packet anyway).
The best / reasonable course is probably to use 512 for your UDP datagrams and do your own checks for data getting out of order within a datagram, as well as dealing packets arriving out of order. (I.E, don't rely at all on IP to drop broken packets for you).
我担心我会引起不安的反应，但尽管如此，为了澄清我是否错了，或者那些看到这个问题并对答案感兴趣的人：
我对 https://www.rfc-editor.org/rfc/rfc1122 其状态为“官方规范”，因此是本文中使用的术语的参考问题，既没有被另一个 RFC 取代，也没有勘误表与以下内容相矛盾：
理论上，即。 根据书面规范，UDP 如 https://www.rfc 给出-editor.org/rfc/rfc1122#section-4 没有“数据包大小”。 因此，答案可能是“不确定的”。
在实践中，这就是这个问题可能寻求的（并且可以针对当前正在使用的技术进行更新），这可能会有所不同，我不知道。
如果我引起了不安，我深表歉意。 https://www.rfc-editor.org/rfc/rfc1122#page- 8“互联网协议套件”和“架构假设”并没有让我清楚地了解我所依据的“假设”，根据我所听到的，各层是独立的。 IE。 UDP 层不必关心 IP 层（IP 层确实有重组、EMTU_R、碎片和 MMS_R 等功能（https://www.rfc-editor.org/rfc/rfc1122#page-56))
I fear i incur upset reactions but nevertheless, to clarify for me if i'm wrong or those seeing this question and being interested in an answer:
my understanding of https://www.rfc-editor.org/rfc/rfc1122 whose status is "an official specification" and as such is the reference for the terminology used in this question and which is neither superseded by another RFC nor has errata contradicting the following:
theoretically, ie. based on the written spec., UDP like given by https://www.rfc-editor.org/rfc/rfc1122#section-4 has no "packet size". Thus the answer could be "indefinite"
In practice, which is what this questions likely seeked (and which could be updated for current tech in action), this might be different and I don't know.
I apologize if i caused upsetting. https://www.rfc-editor.org/rfc/rfc1122#page-8 The "Internet Protocol Suite" and "Architectural Assumptions" don't make clear to me the "assumption" i was on, based on what I heard, that the layers are separate. Ie. the layer UDP is in does not have to concern itself with the layer IP is in (and the IP layer does have things like Reassembly, EMTU_R, Fragmentation and MMS_R (https://www.rfc-editor.org/rfc/rfc1122#page-56))
udp 有不同的最大值。 最终，你的选择限制了你认为足够安全。 注意：UDP 本身并不安全，因此您的数据包随时可能丢失。
注意：所有这些都有一个范围。 它实际上可以有多大，取决于您的 IP 选项。 一般来说，你可以这样计算：[上限]-[IP选项的长度，以字节为单位]。 这里列出的所有范围都不包括 UDP 标头（8 字节）
最小最大传输限制（或类似的东西，我忘记了实际名称，在任何地方都找不到它）：512-552 字节
这可能是最安全的大小。 IPv4 协议需要所有跳来传输此大小的数据包，较大的数据包可能随时被任何主机丢弃。
最大传输单元：1432-1472：
此大小的数据包可以在单个以太网帧中发送，而不会被分段。 任何一个片段的丢失都会导致整个数据包变得无用。 因此，当超过此限制时，由于碎片和单个碎片的潜在丢失，数据包变得无用的机会就会增加。
绝对限制：65467-65507：
任何数据包都不能超过此限制，因为在此限制下，IPv4 协议将充分发挥其潜力。 您无法发送更大的数据包。 这是因为 IPv4 协议仅保留 2 个字节（16 位）的总长度。 将所有这些位设置为 1，您将得到 65535。减去 IP（20-60 字节）和 UDP 标头（8 字节），您将得到此限制。 此大小的数据包将产生至少 44 个片段。 请记住，任何这些片段的丢失都将导致整个数据包变得无用。
There are different maximums for udp. In the End, it is your choice which limits you consider safe enough. Note: UDP in itself is not safe, therefore your packets could be lost at any moment.
Note: All of these have a range. How large it can actually be, depends on your IP Options. In general, you can calculate it like that: [upper maximum]-[length of IP-Options, in bytes]. All the ranges listed here exclude the UDP-Header(8 bytes)
Minimum Maximum Tranfer Limit(or something like that, i forgot the actual name and couldn't find it anywhere):512-552 bytes
This is probaly the safest size. The IPv4 protocol reqires all hops to transmit packets of this size, larger packets may be dropped by any host at any time.
Maximum Transfer Unit:1432-1472:
Packets of this size can be sent in a single ethernet frame without being fragmented. The loss of any fragment will result in the whole packet being useless. Therefore, when exceeding this limit, the chances of your packet becoming useless increase, due to fragmentation and potential loss of single fragments.
Absolute Limit: 65467-65507:
No Packet can exceed this limit, because at this limit, the IPv4 protocol reaches its full potential. you cannot send larger packets. This is because the IPv4 protocol reserves only 2 bytes(16 bit) for the total length. setting all these bits to 1, you get 65535. Subtracting the IP(20-60 bytes) and the UDP header(8 bytes), you get this limit. Packets of this size will result in at least 44 fragments. Keep in mind, the loss of any of these fragments will lead to the whole packet being useless.