通过 TCP socket/s 传输多个图像答案

【问题标题】：Transfer multiple images through TCP socket/s通过 TCP socket/s 传输多个图像
【发布时间】：2011-10-24 17:57:00
【问题描述】：

我尝试用 Java 创建一个应用程序，我有一个图像网格。每个图像都必须通过 TCP 连接从远程服务器加载。

我的问题是哪种方法最好？使用一个 TCP 套接字并通过这个请求所有的图像，还是为每个图像请求打开一个新的套接字？

----- 更新 -----

谢谢大家的回复。

我更新了帖子以写一些额外的信息来回答你的一些问题。

我的想法是，如果使用单个套接字，我必须将图像大小、图像名称分开，所以我必须为每个图像发送一个带有名称的字符串，以及一个长的大小。抛出单个套接字最好在连接开始时一起请求图像，然后以串行方式一对一发送所有图像，或者在请求第二个图像后抛出单个套接字发送图像请求获取图像回复并获得第二个回复。

如果我使用多个套接字，每个图像请求一个套接字我想拥有最大数量的打开套接字，我可以使用线程池并使用一个可运行的来管理一个图像传输抛出一个套接字吗？

再次感谢您。

【问题讨论】：

【解决方案1】：

我只想指出，那些强调一个连接比多个连接更有效或更快的答案......或者反之亦然......缺少几个重要问题：

最佳解决方案取决于许多因素，例如：
- 图像的大小（以要传输的字节计），
- 客户端和服务器之间路由的网络带宽和延迟（可能会发生变化）
- 网络拥塞
- 服务器负载/过载
您还需要决定是针对单个客户端进行优化，还是针对使用同一应用程序的多个客户端进行优化；即您是否“在乎”您的应用程序对服务的其他用户的影响。

我的直觉是，通过几个连接而不是一个连接，您可能会获得更好的吞吐量。但是，由于网络拥塞和各种客户端/服务器端负载问题的结合，打开更多连接实际上会降低吞吐量。在所有条件下尽可能快地完成这项工作真的非常困难。

【讨论】：

【解决方案2】：

如果带宽和服务器容量允许，使用多个套接字将允许并行执行多个传输。

对所有传输使用单个套接字的另一个缺点是您必须找到某种方法让客户端检测每个文件的结尾。每个文件使用一个套接字可以简化这一点，因为远程服务器可以在每个文件之后简单地关闭连接。

除了 TCP 套接字的设置时间可能可以忽略不计的减少之外，我想不出使用单个套接字的任何特殊优势。

所以总的来说，我会为每个文件选择一个套接字。

我还注意到，HTTP 使用了两者的组合——并行连接和每个套接字的多个下载。然而，后一种优化在传输大量小文件时最有用，在传输 100k+ 图像文件时不太可能有用。

【讨论】：

与 HTTP 相同的问题，在服务器上使用更多资源，并且对于如此多的短期连接而言，连接时间可能并不重要。通常对于内部应用程序，如果不使用 3rd 方中间件，更容易的开发时间可能会更优惠。
我确实说“如果服务器容量允许”。

【解决方案3】：

我认为使用一个 TCP 套接字更好，因为你有一个图像网格，如果你想为每个图像打开一个套接字，套接字的数量将会增加，并且可能会导致问题。可以让socket对所有图片传输保持打开，然后关闭，管理更方便。

【讨论】：

另外，如果你想变得非常棘手，你甚至可以实现一种多路复用图像传输。从每个图像串行传输一个数据块。然后在接收端将块存储到相应的图像中。这种方法有两个问题。首先当然是您需要能够控制发送代码。其次是您需要创建一个“协议”，首先发送每个图像的元数据，例如文件名、格式和长度。这会产生您可能不想要的额外复杂性。但是，通过使用它，您可以有效地并行传输 N 张图片。

【解决方案4】：

如果您同时负责服务器和客户端，则没有理由不使用单个连接一次加载多个（全部）图像。当然会更有效率。

【讨论】：

在 Web 服务器中，如果某些图像在磁盘缓存中而其他图像不在，则多个连接可能是有益的。这完全取决于通道是像单个分块 HTTP 连接一样简单，还是像多流 SPDY 甚至 SCTP 一样复杂。更有可能不需要此类微优化。
我会严重质疑“更高效”。当然，它避免了多次 TCP 握手，但在大传输中，这些握手在传输时间中可以忽略不计。它还防止并行下载，这绝对更有效率。
如果在 TCP 握手中损失更多带宽，如何提高效率？这不像有两个并行传输会神奇地使您的带宽翻倍。而且 TCP 使用了慢启动（en.wikipedia.org/wiki/Slow-start），更加降低了多连接选项的速度。