通过多个套接字传输文件是否比仅使用一个套接字更快? [英] Is transmitting a file over multiple sockets faster than just using one socket?

问题描述

在这个旧的项目(从 2002 年开始)，它说如果你将一个文件分成多个块，然后使用不同的套接字传输每个块，它到达的速度会比使用一个套接字作为一个整体传输它要快得多.我还记得(很多年前)读过一些下载管理器也使用这种技术.这有多准确?

In this old project (from 2002), It says that if you split a file into multiple chunks and then transmit each chunk using a different socket, it will arrive much faster than transmitting it as a whole using one socket. I also remember reading (many years ago) that some download manager also uses this technique. How accurate is this?

推荐答案

鉴于具有大窗口或小 RTT 的单个 TCP 连接可以使任何网络链接饱和，我看不出您期望从多个 TCP 会话中获得什么好处.每个新部分都以慢启动开始，因此传输速率低于已建立的连接.

Given that a single TCP connection with large windows or small RTT can saturate any network link, I don't see what benefit you expect from multiple TCP sessions. Each new piece will begin with slow-start and so have a lower transfer-rate than an established connection would have.

TCP 已经有高吞吐量、高延迟连接的代码("窗口缩放选项") 和处理丢包.尝试使用并行连接对此进行改进通常会产生负面影响，因为它会导致更多失败案例和更多数据包丢失(由于单个连接上的 TCP 可以管理拥塞).

TCP already has code for high-throughput, high-latency connections ("window scale option") and dealing with packet loss. Attempting to improve upon this with parallel connections will generally have a negative effect by having more failure cases and increased packet loss (due to congestion which TCP on a single connection can manage).

多个 TCP 会话仅在您从 不同 对等方同时进行提取并且网络瓶颈在本地网络之外(如 bittorrent)或服务器对每个连接进行带宽限制(在这一点您正在优化服务器，而不是 TCP 或网络).

Multiple TCP sessions is only beneficial if you're doing simultaneous fetches from different peers and the network bottleneck is outside your local network (like bittorrent) or the server is doing bandwidth limitations per connection (at which point you're optimizing for the server, not TCP or the network).

这篇关于通过多个套接字传输文件是否比仅使用一个套接字更快?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！