两个代理能让一个文件下载得更快吗？

两个各有空闲带宽的代理出口，看起来像是把下载速度翻倍的简便方法。但普通代理池并不是这样工作的。

客户端通过一个选定的代理建立连接，再由该代理发起后续连接。往池子里再加入一个来自代理列表的地址，只是给未来的连接多一个选择；它并不会把第二个代理拼接进已经在传输的字节流中。

普通的基于连接的多 WAN 负载均衡也有类似的限制。它可以把不同的连接分散到各条链路上，从而提高总容量或减少争用。除非另一种机制明确提供多条路径，否则一条连接仍然只是一条连接。

并行下载是另一回事

客户端可以通过不同的连接请求文件的各个区间，再在本地拼装。如果客户端支持这种安排、服务器也允许这些请求，这确实能用上不止一条路由。

但它带来了一系列条件：各区间必须描述同一个表示，服务器的响应必须与请求的偏移量相符，对象的变化也不能产生混杂的文件。身份验证、服务器限制和每个出口的策略同样可能让并行区间请求变得不合适。十次完整下载并不等于一次下载的十个片段。

通向客户端的最后一段路径依然重要。几个快速出口无法通过一条已经饱和的接入链路送出超过该链路承载能力的数据。

多路径需要真正的支持

Multipath TCP 是一种明确的传输机制，当两端和网络布置都支持时，它可以用多条子流承载同一条连接。仅仅列出两个互不相关的 HTTP 或 SOCKS 代理，并不会把它启用。

面对缓慢的传输，先要判断瓶颈在客户端链路、代理、后续路由还是目标端。代理池适合分散连接。至于“让一个文件速度翻倍”的说法，应当视为需要独立机制和独立证据的另一项特性。