マルチスレッドのダウンロードがシングルスレッドよりも速いのはなぜですか?


13

サーバーに1つの大きなファイルがあります。マルチスレッドのダウンロードで20Mbsを取得できますが、シングルスレッドで10Mbpsを取得できます。


同じTCP接続を処理する複数のスレッド、またはそれぞれが個別のTCP接続を持つ複数のスレッド?また、サーバーがマルチスレッドである、クライアントがマルチスレッドである、またはその両方であると言っていますか?
11

回答:


14

通常、これは、あなたと他のサーバーの間に、各HTTPストリームを10 Mbpsに制限するファイアウォールがあるためです。マルチスレッドを使用すると、2x 10Mb(各スレッドに1つ)を取得します。


1
私は、FTPを使用して、何も私のサーバー上の制限はありません
なぜ

@理由:各接続を10 Mbpsに制限しているのはISPでしょうか?スピードテスターでそれ以上のものを入手できますか?
アンドレパラメス

4

これは、ユーザーとサーバー間のpingおよびダウンロードソフトウェアで使用されるパケットサイズ/ tcpipウィンドウサイズによるものです。

基本的に、サーバーへの100ミリ秒のpingがあり、100 kbのパケットを要求する場合、インターネット速度が無限であっても、1つの接続を使用して1秒あたり10パケットしか取得できません。


受信者が適切なレートでバッファを空にしている限り、各パケットにACKを送信する必要はありません。送信者は継続的にそれらをポンプできる必要があります。
アンドレパラメス

そのとおり。ただし、
256 kbの

3

TCPは、「パイプを一杯に保つ」ときに最適に機能します。送信側アプリが、送信側TCPスタックに常にデータを供給できるように十分な速さでバッファを送信し続けるため、アプリは、受信側TCPウィンドウがいっぱいにならないように、受信側TCPスタックからの読み取りを高速で続けます(繰り返しますが、送信側TCPスタックは常にネットワーク上で「飛行中」のデータを保持できます)。

1つのバッファーをTCPスタックに渡し、完全にAckedされたことを待機してから、別のバッファーを渡す、不十分な記述のシングルスレッド送信アプリを想像できます。つまり、最初のバッファの終わりがネットワーク上で「飛行中」になると、送信するTCPスタックは送信するデータが不足します。つまり、パイプが流出し、Ackが戻って送信アプリが戻るまで補充されません。新しいバッファを渡します。

また、受信TCPスタックから十分な速度で読み取りを行わず、TCPスタックのバッファーがいっぱいになる、つまりTCPウィンドウがいっぱいになり、送信TCPスタックがウィンドウが開くまで送信を停止します。受信者のTCPウィンドウサイズを大きくすることは少し役立つかもしれませんが、この目的での実際の解決策は、データをより速く読み取ることです。


それで、シングルスレッドであることとは何の関係もないのでしょうか?
Ape-in​​ago

@ Ape-in​​ago確かに、適切に作成されたシングルスレッドアプリは、パイプをいっぱいに保つことができます。
11

2

それはおそらく、1つの接続で転送できるのは大量のデータだけだからでしょう。ただし、マルチスレッドプログラムでは、2つの接続で同時にデータを受信し、取得できる情報量を2倍にすることができます。たとえば、ダウンロード元のサーバーの速度など、これにはいくつかの制限があります。


1
なぜそんなに難しいのですか?各スレッドに個別のセクションを割り当て、結果ファイルの適切なセクションに書き込むようにするだけです。アクセルのソースは、私にはかなり簡単に思えます。
アンドレパラメス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.