Java DatagramPacket (UDP) 最大发送/接收缓冲区大小
在 Java 中使用 DatagramPacket
假设你有一个 byte[1024*1024]
缓冲区.如果您只是在发送/接收时将它传递给 DatagramPacket,那么 Java 会接收 DatagramPacket 块的调用,直到它读取整个兆字节?
In Java when using DatagramPacket
suppose you have a byte[1024*1024]
buffer. If you just pass that for the DatagramPacket when sending/receiving will a Java receive call for the DatagramPacket block until it has read the entire megabyte?
我在问 Java 是否会将它拆分,或者只是尝试发送整个被丢弃的东西.
I'm asking if Java will split it up or just try to send the entire thing which gets dropped.
通常情况下,UDP 数据包的大小限制约为 64KB,但我想知道 Java 的 API 是否允许字节数组,如果这是一个限制,并且超大的东西会被丢弃或拆分并为您重新组装.
Normally the size limit is around 64KB for a UDP packet, but I wondered since Java's API allow for byte arrays if that is a limit and something super huge is dropped or split up and reassembled for you.
如果它被丢弃,哪个 API 调用会告诉我可以在 Java 调用中使用的最大数据负载?我听说 IPv6 也有巨型帧,但 DatagramPacket (或 DatagramSocket
) 支持,因为 UDP 定义了标头规范?
If it is dropped what API call would tell me the maximum data payload I can use in the Java call? I've heard that IPv6 also has jumbo frames, but does DatagramPacket (or DatagramSocket
) support that since UDP defines the header spec?
推荐答案
DatagramPacket
只是基于 UDP 的套接字的包装器,因此适用通常的 UDP 规则.
DatagramPacket
is just a wrapper on a UDP based socket, so the usual UDP rules apply.
64 KB 是完整 IP 数据报的理论最大大小,但只能保证路由 576 字节.在任何给定的网络路径上,具有最小最大传输单元的链路将确定实际限制.(1500 字节,较少的标头是常见的最大值,但无法预测会有多少标头,因此将消息限制在 1400 字节左右是最安全的.)
64 kilobytes is the theoretical maximum size of a complete IP datagram, but only 576 bytes are guaranteed to be routed. On any given network path, the link with the smallest Maximum Transmit Unit will determine the actual limit. (1500 bytes, less headers is the common maximum, but it is impossible to predict how many headers there will be so its safest to limit messages to around 1400 bytes.)
如果您超过 MTU 限制,IPv4 将自动将数据报分解成片段并在最后重新组合它们,但最多只能达到 64 KB,并且只有在所有片段都能通过的情况下.如果任何片段丢失,或者任何设备决定它不喜欢片段,那么整个数据包都会丢失.
If you go over the MTU limit, IPv4 will automatically break the datagram up into fragments and reassemble them at the end, but only up to 64 kilobytes and only if all fragments make it through. If any fragment is lost, or if any device decides it doesn't like fragments, then the entire packet is lost.
如上所述,不可能事先知道路径的 MTU 是多少.有多种算法可供尝试找出答案,但许多设备没有正确实施(或故意忽略)必要的标准,所以这一切都归结为反复试验.或者您可以只猜测每条消息 1400 个字节.
As noted above, it is impossible to know in advance what the MTU of path will be. There are various algorithms for experimenting to find out, but many devices do not properly implement (or deliberately ignore) the necessary standards so it all comes down to trial and error. Or you can just guess 1400 bytes per message.
至于错误,如果您尝试发送的字节数超过操作系统配置允许的字节数,您应该会收到 EMSGSIZE
错误或其等效错误.如果您发送的数量少于该数量但超出网络允许的数量,则该数据包将消失.
As for errors, if you try to send more bytes than the OS is configured to allow, you should get an EMSGSIZE
error or its equivalent. If you send less than that but more than the network allows, the packet will just disappear.
相关文章