Java 发送多个非常小的数据包还是更少的大数据包？

我目前正在开发一个简单的应用程序，可以跨套接字传输屏幕截图。我通过实例化并使用Robot类获得屏幕截图，如下所示：

private Robot robot;
public Robot getRobot(){
    if(robot == null){
        try{
            robot = new Robot();
        }catch(Exception e){}
    }
    return robot;
}

public BufferedImage screenshot(){
    return getRobot().createScreenCapture(getScreenRectangle());
}

public byte[] getBytes(BufferedImage image){
    byte[] data = null;
    try{
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ImageIO.write(img, "PNG", baos);
        data = baos.toByteArray();
        baos.close();
    }catch(IOException e){}
    return data;
}

---

然后，我使用上面的

getBytes

方法将

buffereImage

转换为字节数组，然后将其写入套接字输出流。图像平均为500KB。将这500KB拆分成更小的段（比如5KB）会更有效吗？还是将其保留在更大的块（比如30KB）中会更好。我这里的主要目标是交货的速度和准确性。我也很感激任何一种方法在这些方面比另一种更有效的原因。

网络数据包大小受所谓的限制，您不能发送比mtu大的数据包。从链接中可以看出，mtu没有那么大（我相信1500字节是以太网中更常见的mtu）。这是为了网络方面；在java端，决定段大小可能取决于并发传输的图像数量（如果并发发送100个图像，则分配了100个段）

我的建议是尝试一个段大小略小于MTU（我猜你正在使用TCP/IP，所以你必须考虑TCP和IP头大小），看看会发生什么。

编辑：一些评论（正确地）指出，从java角度来看，MTU不会影响数据的分块方式；这对于比MTU大的数据包是正确的，因为TCP/IP层以较小的单位分解较大的数据块；但海报想知道是否存在“最佳”缓冲区大小；响应是，在MTU上，增加java端的缓冲区大小没有任何好处（对于网络传输）

发送多个非常小的数据包还是更少的大数据包

这是应用程序中一个非常常见的问题，QoS起着重要作用。我认为没有一个正确的答案，只有一个更适合你的要求的实现

您可以考虑以下几个方面：

• 较大的数据包可减少数据开销的de%
• 当接收或发送数据（损坏的数据）时出错时，较大的数据包会产生较大的影响
• 较小的数据包应用于对用户提供更好响应的应用程序
• 在某些应用中，流量对于快速处理信息非常重要和必要，而不是为每个帧发送整个图像，应使用适当的协议发送图像的不同部分

---

关于为什么选择较大或较小的数据包，Melli在回答中有很好的理由。您基本上是在用吞吐量换取响应能力

我不同意没有正确的答案；至少在这种情况下，我认为有一个非常明显的更好的答案：如果你想让它尽快到达另一端，立刻发送它

• 发送数据的系统调用更少
• 减少开销，因为您发送的TCP数据包和冗余头更少
• 碎片化是网络堆栈较低级别的责任，而不是您的应用程序
• 生成的代码将简单得多

---

如果您使用的是TCP，则准确度不会成为问题。我认为选择一个接近TCP堆栈缓冲区大小的数据包是理想的。为什么不简单地用不同的大小来测试它？@SeanBright和TCP堆栈的缓冲区大小是多少？它依赖于系统吗？它依赖于系统，是的。如果您使用的是TCP，那么数据包的大小，或者更确切地说是数据段的大小，无论如何都完全超出了您的控制范围。就写吧。TCP将为您处理MTU和MSS。我感谢您的帮助。你能给我一些关于每个数据包的头大小的指导吗？是的，你可以看看这个答案，头的总和（以太网+ip+tcp）大约是64byte@rodit它大约是50-60个字节，不能更改。除非您的消息接近这个大小，否则这不是您应该担心的细节。从Java的角度来看，MTU是不相关的。TCP提供面向流的数据传输：只需写入套接字的流，套接字将负责缓冲和发送数据。没有实际理由将写入限制在略小于MTU猜测的大小，首先，没有办法实际控制TCP段的大小。这实际上是一个很好的答案。为什么会有人投反对票？不管怎样，我要投票表决，所以：）