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

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

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

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

• 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以降を「モダン」と呼ぶことができます）には、ソケットバッファーの実装により優れたバッファー割り当てメカニズムが含まれています。

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

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

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

何故ですか？

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

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

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

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