HTTP下载和多线程
这可能是重复的，但我还没有看到这个问题得到充分回答。
使用线程时 HTTP 下载吞吐量会增加吗？ 我的想法是，当服务器上的 TCP 堆栈在发送下一个数据块之前等待来自接收器的确认时，另一个线程正在发送数据请求，然后提供服务，从而导致吞吐量增加。
这是正确的吗？
This may be a duplicate but I have not seen this being fully answered.
Does HTTP download throughput increase when using threads?
My thinking is that when the TCP stack on the server is waiting for a ack from the receiver before sending the next chunk of data, another thread is sending out a request for data which is then serviced, leading to an increase in throughput.
Is this correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，这非常正确。线程化 HTTP 请求会增加吞吐量，直到服务器上达到最大连接数，然后这种增加将趋于稳定。当然，性能的提高将仅限于服务器和客户端计算机的线程能力。
Yes, that is pretty much correct. Threading HTTP requests would increase throughput, up until the maximum number of connections was met on the server, and then this increase would plateau. The performance increase would be limited to both the server and the client computers threading abilities, of course.
它仅在启动时正确，在传输过程中，TCP 有一个动态数据窗口，可以在不接收 ACK 的情况下发送数据。
因此，在数据传输进行时，在大多数情况下，可以发送的每个数据块都会被发送，从而实现最大吞吐量。
当您使用多个线程时，您可以减少 TCP 握手中的停滞时间。
如果您必须从不同的服务器下载文件或者服务器限制每个连接的带宽，它也很有用。
It's correct only at the startup, during the transfer TCP has a dynamic window of data that can be sent without receiving an ACK.
So while the data transfer is going on, in most situations every chunk of data that can be sent is sent, resulting in maximum throughput.
When you use multiple threads you reduce the dead time in the TCP handshaking.
It can also be useful if you have to download files froms different servers or if the server limits the bandwidth per connection.