UDP数据包大小和数据包丢失
我一直在写一个程序，它使用UDP上的停止和等待协议通过局域网和广域网发送数据包。我最近一直在测试我的程序，并注意到较大的数据包（接近64k字节）的丢包率更高。直觉上这是有道理的，但实际原因是什么？
共有3个答案
这一切都是关于IP碎片和碎片整理。超过MTU的数据包将被碎片化，必须在最终主机上进行碎片化，碎片在路径上再次碎片化的可能性也会增加延迟。有时，如果为第4层过滤配置了一些N/W元素，那么它会进行碎片整理（而不是最终的主机）并应用规则，然后再次进行碎片整理和转发。这就是为什么需要性能的应用程序总是尝试发送大小相同的数据
那么,数据网络还很不可靠,；数据包总是被丢弃。路由器过载、缓冲区满和数据包损坏是部分原因。由于UDP没有流量控制功能，因此如果接收端过载，它就不能减慢速度。
正如杰里米解释的那样，有效载荷越大，它将被分成的数据包就越多，因此丢失其中一些数据包的可能性就越大。
UDP用于这样的情况：此处丢弃的数据包不会影响任何东西，或者您需要一些东西才能及时到达或根本不需要。（VOIP、流媒体视频等）
大于承载它们的网络MTU大小的UDP数据包将被自动拆分成多个数据包，然后由接收者重新组装。如果这些多个子数据包中的任何一个被丢弃，那么接收器也将丢弃其余的子数据包。
例如，如果您发送一个63k UDP数据包，它通过以太网传输，它将被分成47个较小的“片段”数据包（因为以太网的MTU是1500字节，但其中一些用于UDP报头等，因此UDP数据包中可用的用户数据空间量小于此值）。只有当所有47个片段数据包都顺利通过时，接收方才会“看到”该UDP数据包。如果只有一个片段数据包被丢弃，整个操作就会失败。
-
我正在使用在我的客户端应用程序中执行以及 最大数据包大小限制也存在于中，即？但是我可以使用中的发送大于最大数据包大小的数据块 这是怎么运作的？这是因为是基于流的，负责在较低层创建数据包吗？有什么方法可以增加UDP中的最大数据包大小吗？ 当我在客户端读取时，我从服务器端发送的UDP数据包的一些字节是否可能丢失？如果是，那么有没有办法只检测UDP客户端的损失？
-
我编写了一个简单的UDP服务器程序来了解更多可能的网络瓶颈。 UDP客户端：我使用hping如下所示： HPING 3 192.168.1.2-UDP-P 9996--洪水-D 100 当我以每秒100个数据包的速度发送udp数据包时，我没有发现任何udp数据包丢失。但是当我泛洪udp数据包时（如上面的命令所示），我会看到大量的数据包丢失。 因此，为了减少数据包丢失，我尝试了以下操作: -使用re
-
在实验运行在esp32上的UDP服务器时，我发现接收到的数据包的大小限制在1500字节： 20（IP头）8（UDP头）1472（数据），（尽管理论上UDP好像可以支持数据包64K）。这意味着，为了传输更大量的数据，客户端必须将其拆分成若干块并依次发送，而在服务器端，这些数据将需要恢复。我认为这种解决方案的管理费用将相当高。我还知道TOIT提供TCP/IP连接。自然，分组大小在TCP/IP的情况下也
-
好的，我正在为我的网络课程编程，我必须使用UDP在Java中实现一个项目。我们正在实现一个HTTP服务器和客户端以及一个“gremlin”函数，该函数以指定的概率破坏数据包。HTTP服务器必须在应用层将一个大文件分成多个段，然后通过UDP发送到客户端。客户端必须在应用层重新组装接收到的段。然而，我想知道的是，如果UDP根据定义是不可靠的，为什么我必须在这里模拟不可靠？ 我的第一个想法是，也许这仅仅
-
通过UDP发送大量的小数据包会占用更多的资源（cpu、zlib压缩等）。我在这里读到，通过UDP发送一个大的~65kBYTEs数据包可能会失败，所以我认为发送许多较小的数据包会更频繁地成功，但是随之而来的是使用更多处理能力的计算开销（或者至少这是我假设的）。问题基本上是这样的：发送最大成功数据包并将计算保持在最低限度的最佳方案是什么？有没有一个特定的尺寸在大部分时间都有效？我使用Erlang作为服
-
我总共有96个视频。我已经使用ffmpeg转换了大部分视频，但对于某些视频，它会给我带来一些错误。作为第一步，我使用以下命令将视频逐行扫描： 我得到以下错误： [rawvideo@0x7fa144008c00]缓冲区大小无效，数据包大小2073600 当我试图获取有关视频的信息（）时，我得到以下信息： [IMGUTILS@0x7fff5bac8140]图片大小0x0无效 [IMGUTILS@0x7