物理的な距離はダウンロード速度に影響しますか?


22

私は同僚と議論したばかりで、これに関する専門家に手を差し伸べるだけだと思った。これがシナリオです。接続の速度を測定するWebサイトを使用していました。遠く離れたサーバーを使用してテストしました(マレーシアにあり、サーバーは米国にありました)。約2 Mbpsでした。その後、シンガポールのサーバーで試してみましたが、はるかに高速でした(約15 Mbps)。私の同僚は、物理的な距離のせいだと思っていましたが、それは重要ではないと思います。私の理解では、最初のハンドシェイクを完了し、データフローが開始されると、サーバーの場所は関係なく、結果はほぼ同じになります。ここに何かが足りませんか?どのように実際に機能しますか?


2
これはごく簡単に確認できます。サーバーにpingして遅延を取得します。その後、2Mbps * Latency == Window。実際のウィンドウサイズは、wiresharkで確認できます。しかし、ウィンドウのスケーリングがオンになっていないと仮定すると、64kB / 2Mbps = 256msなので、サーバーは256ms離れていると予測します。
ytti

2
@yttiは、BDP(帯域幅遅延製品)を間接的に説明します。これは、長い(遅延)、太い(帯域幅)ネットワークを完全に維持するのが難しく、潜在的なスループットから食い尽くすものに大体変換されます。en.wikipedia.org/wiki/Bandwidth-delay_productを参照してください。
generalnetworkerror

2
@ytti、Windows Vistaおよびそれ以降のバージョンにはデフォルトでオンにウィンドウスケーリングを持っている...私たちはOSと、Navidは、テストに使用しているかを知る必要があり
マイク・ペニントン

これによるとsupport.microsoft.com/kb/934430スケーリング(係数8)が、唯一の非HTTPのため、Vistaのデフォルトです。私は自分でWindowユーザーではないため、確認できません。
ytti

2
@ytti、それが関連するかどうかはわかりません。私はVistaを実行して、私はそのサポートページへの私のHTTP接続のスニッフィングを見ていて、TCP SYNは言う:「ウィンドウスケール:2(4倍乗算)」
マイク・ペニントン

回答:


23

私の同僚は、物理的な距離のせいだと思っていましたが、それは重要ではないと思います。私の理解では、最初のハンドシェイクを完了し、データフローが開始されると、サーバーの場所は関係なく、結果はほぼ同じになります。ここに何かが足りませんか?どのように実際に機能しますか?

二人とも歴史のある時点で正しかったのですが、あなたの理解はほとんど正しいです...今日:) 友人からの古い回答と、現在の機能との間で変化した要因がいくつかあります。

  • TCPウィンドウのスケーリング
  • ホストバッファチューニング

見た結果の違いは、次の影響を受けた可能性があります。

  • パケットロス
  • 並列TCP転送

TCPウィンドウスケーリング:帯域幅遅延効果

あなたの友人が言ったように、TCPの古い実装は、TCPヘッダーの元の16ビット受信ウィンドウサイズによって課せられる制限を受けました(RFC 793:セクション3.1を参照)。RWINは、1つのTCPソケットで未確認データがどれだけ待機できるかを制御します。16ビットRWIN値は、高帯域幅遅延製品を使用したインターネットパスを制限します(また、今日の高帯域幅インターネット接続の多くは16ビット値によって制限されます)。

RTT値が高い場合、非常に大きなRWINがあると便利です。たとえば、マレーシアから米国へのパスRTTが約200ミリ秒の場合、元のTCP RWINでは2.6 Mbpsに制限されます。

最大スループット= Rcv_Win / RTT

* 最大スループット= 65535 * 8 / 0.200 *

最大スループット= 2.6Mbps

RFC 1323は、これらの制限を克服するためにいくつかの「TCPオプション」を定義しました。これらのTCPオプションの1つは「ウィンドウスケーリング」です。完全な受信ウィンドウ値を取得するために、元のRWIN値を乗算するスケールファクターを導入します。ウィンドウスケーリングオプションを使用すると、1073725440バイトの最大RWINが許可されます。同じ計算を適用する:

最大スループット= Rcv_Win / RTT

* 最大スループット= 1073725440 * 8 / 0.200 *

最大スループット= 42.96Gbps

パケットの損失が問題にならない限り、TCPは転送中にRWINを徐々に増加させることに注意してください。高遅延接続で非常に大きな転送速度を確認するには、大きなファイルを転送する必要があります(したがって、TCPはウィンドウを大きくする時間があります)。接続のパケット損失は問題になりません。

パケットロス

太平洋のインターネット回線は、かなり混雑していることがあります。私の家族の一部は台湾に住んでおり、Google Talkを使用すると、日常的に問題に直面します。米国からDSL回線にpingを実行すると、パケット損失が0.5%を超えることがよくあります。「遅い」サーバーで0.5%の損失が発生した場合、単一のTCPソケットのスループットが非常に簡単に制限されます。

パラレルTCPストリーム

参考までに、一部の速度テストWebサイトでは、並列TCPストリームを使用してスループットを向上させています。これは、表示される結果に影響する可能性があります。これは、パスにパケット損失がある場合、パラレルTCPストリームがスループットを劇的に向上させるためです。4つのパラレルTCPストリームが、1%の一定のパケット損失に悩まされている5Mbpsケーブルモデムを完全に飽和させるのを見ました。通常、1%の損失は、単一のTCPストリームのスループットを低下させます。

ボーナス資料:ホストバッファーの調整

多くの古いOS実装には、限られたバッファを持つソケットがありました。古いOS(Windows 2000など)では、TCPが大量のデータを処理できるかどうかは問題ではありませんでした。ソケットバッファは、大きなRWINを利用するように調整されていませんでした。TCP転送で高性能有効にするために行われた多くの研究がありました。最新のオペレーティングシステム(この回答では、Windows Vista以降を「モダン」と呼ぶことができます)には、ソケットバッファーの実装により優れたバッファー割り当てメカニズムが含まれています。


4
副次的な注意事項として、ウィンドウスケーリングを禁止する古いスタイルのルーターがたくさんあり(毎日少なくなりますが、まだたくさんあります)、ゼロにリセットして、帯域幅を大幅に減らします。これらの壊れたルーターの1つにヒットする可能性は、宛先へのホップ数とともに増加しますが、最近ではほとんどのネットワークインフラストラクチャプロバイダーがこの問題を抱えることはありません。
クリスダウン

ルーターはL3デバイスです。TCPウィンドウのスケーリングはL4プロセスです。ルーターはパケットを転送するか転送しないかのいずれかであり、QoSメカニズムの使用を除いて、TCP、UDP、または他のプロトコルを区別しません。ルーターは最初のMSSネゴシエーションに確かに影響を及ぼします(またはICMP到達不能をドロップした場合に影響します)が、スライディングウィンドウアルゴリズムは純粋にエンドシステムのスタックの機能です。
rnxrx

2
@rnxrx同意しますが、ほとんどの場合、エッジFWがTCPオプションに腹を立てます。TCPウィンドウスケーリングオプションをマングリングするルーターについて聞いたことはありませんが、エッジルーターがTCP MSSオプションを転送中にマングルすることは珍しくないと考えて、誰かがそれを行ったベンダー/モデルを思いついたとしても、私は驚くことはありません、誰かがそれをfsckingすることを想像することはそれほど大きな飛躍ではありません。
ytti

3

簡単な答え:はい、距離は単一ストリームの帯域幅に影響します。

インターネットはその効果を制限する手段を進化させてきました...遅延ACK、ウィンドウスケーリング、その他のプロトコル:-)しかし、物理学は最終的に勝ちます。この場合、非常に多くのホップでの一般的なネットワーク輻輳である可能性がはるかに高くなります。TCPストリームを強制終了するのにドロップされたパケットは1つだけです。


1

これにはすでに優れた答えがありますが、私は付け加えます。いいえ、速度は必ずしも距離に影響されるわけではありません。そして、速度は距離に影響されることが非常に多いです。

何故ですか?

大幅に簡素化され、距離が長くなるほど、インターネット経由の「ホップ」が増えます。最大帯域幅は、最も遅いホップと並行トラフィックによって決まります。距離が長くなり、ホップ速度の分布がややランダムになると、全体的な速度が遅くなる可能性が高くなります。さらに、物理が邪魔になり、待ち時間が長くなるとリンクが遅くなる場合があります。

しかし、これは当たり前のことではありません。テクノロジーにより、ほぼすべての帯域幅を必要とする地球規模の接続を構築できます。ただし、帯域幅と距離は敵であり、どちらも接続のコストを劇的に増加させるため、今必要な接続だけに存在する可能性が低くなります。

もちろん、これは単純化されすぎていますが、実際には、この状況は非常に頻繁に見られるものです。そして、驚くほど高速な接続やすぐ近くにあるディストリビューションプロキシがある場合も、そうではありませんが、すべてが瞬時に行われるとき、インターネットの速度について考えることはほとんどありません...


-1

アンドリュー・マーティンによると、答えはイエスです

グラフ


リンクのみの回答は推奨されません。リンクされたWebページに依存せずに、この回答が役立つように詳細を入力してください。
テウンヴィンク

おい、それはリンクだけの答えではなく、統計付きの画像です
ジョナサン

私はあなたの男ではありません。また、この画像には、Y軸の内容と測定方法の説明がなければ意味がありません。そして、それでも、この画像がどのように質問に対する答えであるかを説明する必要があります。
Teun Vink

なぜあなたにとってそれが難しいのかわかりませんが、X軸とY軸にはラベルが付いています。「平均ダウンロード速度(Mbps)」
ジョナサン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.