2つのプロキシで1つのファイルを速くダウンロードできるか

それぞれに余った帯域がある2つのプロキシ出口は、ダウンロード速度を倍にする簡単な方法に見える。しかし通常のプロキシプールはそうは動かない。

クライアントは選んだ1つのプロキシ経由で接続を開く。そのプロキシが次の接続を開く。プロキシ一覧から別のアドレスをプールに加えても、将来の接続に選択肢がもう1つ増えるだけで、進行中のバイトストリームに2つ目のプロキシを継ぎ足すわけではない。

通常の接続単位のマルチWAN負荷分散にも同じ限界がある。異なる接続を複数の回線に振り分けることはでき、総容量の向上や競合の軽減につながる。しかし別の仕組みが明示的に複数経路を用意しない限り、1つの接続は1つの接続のままだ。

並列ダウンロードが別の話になる場合

クライアントは1つのファイルの異なる範囲を別々の接続で要求し、手元で組み立てることができる。クライアントがこの構成を支え、サーバーが要求を許可すれば、複数の経路を使える。

そこには条件が伴う。範囲は同じ表現を記述していなければならず、サーバーの応答は要求したオフセットと一致し、オブジェクトの変更が混在したファイルを生んではならない。認証、サーバーの制限、出口ごとの方針も、並列の範囲要求を不適切にしうる。完全なダウンロード10回は、1回のダウンロードの10個の断片ではない。

クライアントまでの最終経路は依然として重要だ。複数の速い出口があっても、飽和した1本のアクセス回線が運べる以上のデータをその回線に流すことはできない。

マルチパスには実際の対応が必要

Multipath TCPは、端点とネットワーク構成が対応していれば複数のサブフローで1つの接続を運べる明示的なトランスポート機構だ。無関係なHTTPやSOCKSのプロキシを2つ並べただけで有効になるものではない。

遅い転送では、まず上限がクライアント回線、プロキシ、先の経路、宛先のどこにあるかを見極める。プールは接続の分散には役立つ。1つのファイルの速度が倍になるという主張は、独自の仕組みと証拠を必要とする別の機能として扱うべきだ。