アメリカ東海岸から西海岸までの「典型的な」ネットワーク遅延はどのくらいですか？
現時点では、データセンターを西海岸から東海岸に移動するかどうかを決定しようとしています。
ただし、私の西海岸の場所から東海岸まで、いくつかの迷惑な待ち時間の数値が表示されています。これはサンプルの結果です。Googleで小さな.pngロゴファイルを取得しますChromeおよび開発ツールを使用して、リクエストにかかる時間を確認します。
- 西海岸から東海岸：
レイテンシ215ミリ秒、転送時間46ミリ秒、合計261ミリ秒 - 西海岸から西海岸：
レイテンシ114ミリ秒、転送時間41ミリ秒、合計155ミリ秒
コーバリスORは地理的にカリフォルニア州バークレーの私の場所に近いので、接続は少し高速になると思います。.しかし、+ 100msの遅延が増加しているようです。 NYCサーバーに対して同じテストを実行すると、それは私には過度に思えます。特に以降、実際のデータの転送に費やされる時間は10％しか増加しませんでしたが、待ち時間は100％増加しました！
それは...間違っていると感じます...私にとって。
ここに役立つリンクがいくつか見つかりました（Googleを介しても同様です）...
...しかし信頼できるものは何もない。
それで、これは正常ですか？正常に感じません。 米国の東海岸<->西海岸からネットワークパケットを移動するときに期待する「典型的な」待ち時間はどのくらいですか？
光の速度：
興味深い学問として、光の速さを上回らないでしょう。 このリンク は、スタンフォードからボストンまで、可能な限り最高40msの時間で動作します。この人が計算を行ったとき、彼はインターネットが約「光速の2倍以内」で動作することを決定したので、約〜85msの転送時間があります。
TCPウィンドウサイズ：
転送速度の問題がある場合は、受信ウィンドウのtcpサイズを増やす必要があるかもしれません。これが高レイテンシの高帯域幅接続である場合は、ウィンドウスケーリングを有効にする必要がある場合もあります（「ロングファットパイプ」と呼ばれます）。したがって、大きなファイルを転送する場合は、ウィンドウの更新を待たずにパイプを満たすのに十分な大きさの受信ウィンドウが必要です。私は答えでそれを計算する方法についていくつかの詳細に行きました 象の調整 。
地理と待ち時間：
一部のCDN（コンテンツ配信ネットワーク）の欠点は、遅延と地理を同一視していることです。 Googleはネットワークで多くの調査を行い、この点に欠陥を見つけたため、結果をホワイトペーパーで公開しました エンドツーエンドのパス情報を超えて移動してCDNパフォーマンスを最適化する ：
まず、ほとんどのクライアントは地理的に近くのCDNノードからサービスを受けていますが、かなりの割合のクライアントが同じ地域の他のクライアントより数十ミリ秒高いレイテンシを経験しています。第2に、キューイングの遅延は、クライアントが近くのサーバーとやり取りするメリットを無効にすることがよくあります。
BGPピアリング：
また、BGP（コアインターネットルーティングプロトコル）とISPがピアリングを選択する方法を研究し始めた場合、それは多くの場合、金融と政治に関するものであることがわかります。 ISPによって異なります。 looking glass router を使用して、IPが他のISP（自律システム）にどのように接続されているかを確認できます。 特別なwhoisサービス を使用することもできます：
whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP | AS Name
25899 | 69.59.196.212 | LSNET - LS Networks
32869 | 69.59.196.212 | SILVERSTAR-NET - Silver Star Telecom, LLC
linkrank のようなGUIツールでピアリングとしてこれらを探索するのも楽しいです。それはあなたの周りのインターネットの写真を提供します。
このサイト は、米国の東海岸と西海岸の間におよそ70〜80ミリ秒の遅延があることを示唆しています（たとえば、サンフランシスコからニューヨーク）。
大西洋横断パス ニューヨーク78ロンドン ウォッシュ87フランクフルト
太平洋横断パス SF 147香港
アメリカ横断パス SF 72 NY
ここに私のタイミングがあります（私はイギリスのロンドンにいるので、私の西海岸時間は東よりも長いです）。 74ミリ秒のレイテンシの差があり、そのサイトの値をサポートしているようです。
NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total
これらは、Google Chrome開発ツールを使用して測定されました。
可能であれば、まずICMPで測定します。 ICMPテストは通常、デフォルトで非常に小さなペイロードを使用し、3ウェイハンドシェイクを使用せず、HTTPのようにスタックの上の別のアプリケーションと対話する必要はありません。いずれにしても、HTTPの結果がICMPの結果と混同されないことが最も重要です。リンゴとオレンジです。
Rich Adamsの回答 を使用し、 サイト を使用することをお勧めします。AT＆Tのバックボーンでは、ICMPトラフィックがSFとNYエンドポイント。これはかなりの数ですが、これはAT＆Tによって完全に制御されているネットワーク上にあることに注意してください。ホームネットワークまたはオフィスネットワークへの移行は考慮されていません。
ソースネットワークからのcareers.stackoverflow.comに対してpingを実行すると、72ミリ秒（おそらく+/- 20ミリ秒）を超えていないはずです。その場合は、おそらく2人の間のネットワークパスが正常で、正常な範囲内で実行されていると想定できます。そうでない場合は、慌てて、他のいくつかの場所から測定しないでください。それはあなたのISPかもしれません。
合格したと仮定すると、次のステップはアプリケーション層に取り組み、HTTPリクエストで見られる追加のオーバーヘッドに問題がないかどうかを判断することです。これは、ハードウェア、OS、およびアプリケーションスタックにより、アプリごとに異なる可能性がありますが、東海岸と西海岸の両方にほぼ同じ機器があるため、東海岸のユーザーが西海岸のサーバーに、西海岸のユーザーが東にヒットする可能性があります。海岸。両方のサイトが適切に構成されている場合は、すべての数値が等しくないことがわかり、したがって、表示されているものが大まかなものと同じであることを示します。
これらのHTTP時間に大きなばらつきがある場合、パフォーマンスの低いサイトで構成の問題があったとしても、私は驚かないでしょう。
さて、この時点で、これらの数を減らすことができるかどうかを確認するために、アプリ側でさらに積極的な最適化を試みることができます。たとえば、IIS 7を使用している場合、そのキャッシュ機能などを利用していますか？おそらく、そこで何かを獲得できるかもしれませんが、そうでないかもしれません。低レベルのアイテムの調整については、 TCP Windowsのように、それがスタックオーバーフローのようなものに大きな影響を与えるかどうかは非常に懐疑的です。しかし、ちょっと-試して測定するまでわかりません。
ここでの回答のいくつかは、説明のためにpingおよびtracerouteを使用しています。これらのツールは適切な場所にありますが、ネットワークパフォーマンスの測定には信頼できません。
特に、（少なくとも一部の）ジュニパーのルーターは、ICMPイベントの処理をルーターのコントロールプレーンに送信します。これは、フォワーディングプレーンよりもかなり遅く、特にバックボーンルータでは遅くなります。
ICMP応答がルータの実際の転送パフォーマンスよりもはるかに遅くなる可能性がある他の状況があります。たとえば、CPU容量の99％であるすべてのソフトウェアのルーター（特殊な転送ハードウェアはありません）が、トラフィックを正常に移動しているとします。 traceroute応答の処理またはトラフィックの転送に多くのサイクルを費やしますか？したがって、応答の処理は非常に低い優先度です。
結果として、ping/tracerouteは妥当な上限を提供します-物事は少なくともそれほど速く進んでいます-しかし、実際のトラフィックがどれだけ速いかは実際にはわかりません。
いかなる場合でも -
これは、ミシガン大学（米国中部）からスタンフォード（米国西海岸）へのtracerouteの例です。 （たまたまワシントン経由で行くDC（米国東海岸）、これは「間違った」方向に500マイルです）
% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 Hops max, 52 byte packets
1 * * *
2 * * *
3 v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130) 3.808 ms 4.225 ms 2.223 ms
4 l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131) 1.372 ms 1.281 ms 1.485 ms
5 l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8) 1.784 ms 0.874 ms 0.900 ms
6 v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69) 2.443 ms 2.412 ms 2.957 ms
7 v0x1004.rtr.wash.net.internet2.edu (192.122.183.10) 107.269 ms 61.849 ms 47.859 ms
8 ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6) 28.267 ms 28.756 ms 28.938 ms
9 xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112) 52.075 ms 52.156 ms 88.596 ms
10 * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96) 496.838 ms
11 hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133) 76.537 ms 78.948 ms 75.010 ms
12 svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38) 82.151 ms 82.304 ms 82.208 ms
13 hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62) 82.504 ms 82.295 ms 82.884 ms
14 boundarya-rtr.stanford.edu (171.66.0.34) 82.859 ms 82.888 ms 82.930 ms
15 * * *
16 * * *
17 www-v6.stanford.edu (171.67.215.200) 83.136 ms 83.288 ms 83.089 ms
特に、washルーターとatlaルーターからのtraceroute結果の時間差に注意してください（ホップ7および8）。ネットワークパスは最初に洗浄され、次にアトラに進みます。ウォッシュの応答には50〜100ミリ秒かかります。明らかにアトラはより遠くにありますが、そのtracerouteの結果はそれがより近いことを示唆しています。
ネットワーク測定に関する多くの情報については http://www.internet2.edu/performance/ を参照してください。 （免責事項、私は以前はInternet2で働いていました）。次も参照してください： https://fasterdata.es.net/
元の質問に特定の関連性を追加するには...ご覧のとおり、スタンフォードへの往復pingに83ミリ秒のping時間がありました。そのため、ネットワークは少なくともこれだけ高速に進むことができます。
このtracerouteで使用した研究と教育のネットワークパスは、一般的なインターネットパスよりも高速である可能性が高いことに注意してください。 R＆Eネットワークは通常、接続を過剰にプロビジョニングするため、各ルーターでのバッファリングは起こりません。また、実際のトラフィックを明確に表していますが、コーストからコーストまでの長い物理パスに注意してください。
ミシガン->ワシントン、dc->アトランタ->ヒューストン->ロサンゼルス->スタンフォード
私は一貫した違いを見ている、そして私はノルウェーに座っている：
serverfault careers
509ms 282ms
511ms 304ms
488ms 295ms
480ms 274ms
498ms 278ms
これは、Googleのリソースビューを使用する科学的に正確で実績のある方法で測定されましたChromeおよび各リンクを繰り返し更新するだけです。
Serverfaultへのtraceroute
Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 Hops:
1 <1 ms 1 ms <1 ms 81.27.47.1
2 2 ms 1 ms 1 ms qos-1.webhuset.no [81.27.32.17]
3 1 ms 1 ms 1 ms 81.27.32.10
4 1 ms 2 ms 1 ms 201.82-134-26.bkkb.no [82.134.26.201]
5 14 ms 14 ms 14 ms 193.28.236.253
6 13 ms 13 ms 14 ms TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
7 22 ms 21 ms 21 ms te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
8 21 ms 20 ms 20 ms sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
9 21 ms 21 ms 20 ms sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
10 107 ms 107 ms 107 ms 144.232.24.12
11 107 ms 106 ms 105 ms sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
12 106 ms 106 ms 107 ms sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
13 129 ms 135 ms 134 ms sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
14 183 ms 183 ms 184 ms sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
15 189 ms 189 ms 189 ms sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
16 193 ms 189 ms 189 ms 204.181.35.194
17 181 ms 181 ms 180 ms core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
18 182 ms 182 ms 182 ms sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
19 195 ms 195 ms 194 ms sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
20 197 ms 197 ms 197 ms ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
21 188 ms 187 ms 189 ms ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
22 198 ms 198 ms 198 ms vlan5-cvo-colo2.peak.org [69.59.218.226]
23 198 ms 197 ms 197 ms stackoverflow.com [69.59.196.212]
Trace complete.
キャリアへのトレースルート
Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 Hops:
1 1 ms 1 ms 1 ms 81.27.47.1
2 2 ms 1 ms <1 ms qos-1.webhuset.no [81.27.32.17]
3 1 ms 1 ms 1 ms 81.27.32.10
4 1 ms 1 ms 2 ms 201.82-134-26.bkkb.no [82.134.26.201]
5 12 ms 13 ms 13 ms 193.28.236.253
6 13 ms 14 ms 14 ms TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
7 21 ms 21 ms 21 ms ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
8 21 ms 20 ms 20 ms tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
9 116 ms 117 ms 122 ms xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
10 121 ms 122 ms 121 ms peer1-gw.ip4.tinet.net [77.67.70.194]
11 * * * Request timed out.
残念ながら、それは今やループに入るようになり、30ホップまで星とタイムアウトを与え続け、その後終了します。
トレースルートは最初のタイミングとは異なるホストからのものであることに注意してください。それらを実行するには、ホストされているサーバーにRDPする必要がありました
ここの誰もが本当に良い点を持っています。自分の視点で正しいです。
そして、すべてがここに本当の正確な答えはないということになります。なぜなら、非常に多くの変数があるからです。
72msのNYからSFまでのレイテンシは、パケットのキャリアのPoPからPoPまでのレイテンシです。これは、輻輳、パケット損失、サービス品質、順不同のパケット、またはパケットサイズ、またはPoPからPoPの完全な世界の間でのネットワークの再ルーティングについてここで指摘した他の優れた点を考慮していません。 。
そして、PoPからラストマイル（通常は数マイル）を2つの都市内の実際の場所に追加すると、これらすべての変数がより流動的になり、合理的な推測能力から指数関数的にエスカレートし始めます！
例として、私はニューヨーク市とSFの間で営業日のコースをテストしました。世界中でトラフィックの急上昇を引き起こす大きな「事故」が発生していなかった場合、私はこれを1日行いました。したがって、これは今日の世界では平均的ではなかったのかもしれません。しかし、それでもそれは私のテストでした。私は実際に、この期間中、および各海岸の通常の営業時間中に、ある事業所から別の事業所までを測定しました。
同時に、私はウェブ上で回線プロバイダー数を監視しました。
その結果、事業所の戸口から戸口までの待ち時間は88〜100 msでした。これには、オフィス間のネットワーク遅延の数値は含まれていません。
サービスプロバイダーのネットワーク遅延は70〜80ミリ秒です。ラストマイルのレイテンシは18〜30 msの範囲でした。 2つの環境間の正確なピークとローを相関させませんでした。
私は、東海岸と西海岸の間の適切に実行され、十分に測定されたリンクで約80〜90ミリ秒の遅延を確認しています。
レイテンシがどこで増えているかを確認するのは興味深いことです。レイヤー4トレースルート（lft）などのツールを試してください。多くの場合、「ラストマイル」（つまり、ローカルブロードバンドプロバイダー）で得られます。
転送時間にわずかな影響しか与えられなかったことが予想されます。2つの場所間の転送時間の違いを調査する場合、パケット損失とジッターはより有用な測定値です。
ちょうど楽しみのために、私がヨーロッパ内からオンラインゲームLineage 2 NAリリースをプレイしたとき：
Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms
この違いは、インターネットの予測不可能な性質を考慮すると、最大100ミリ秒が妥当な範囲内であることをサポートしているようです。
絶賛されたChrome更新テストを使用すると、ドキュメントの読み込み時間が約130ms異なります。
ニューヨークのタイミング：
NY OR
109ms 271ms
72ms 227ms
30ms 225ms
33ms 114ms
34ms 224ms
住宅用接続でのChromeの使用。
ニュージャージー州ニューアークのデータセンターでVPSからlftを使用する場合：
terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
1 207.192.75.2 0.4/0.5ms
2 vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
3 0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
4 nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
5 oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
6 216.187.115.145 2.7/2.2ms
7 64.34.60.28 2.3/1.8ms
8 [target open] 64.34.80.176:80 2.5ms
terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
1 207.192.75.2 36.4/0.6ms
2 vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
3 0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
4 nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
5 nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
6 nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
7 192.205.34.53 2.1/2.1ms
8 cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
9 cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10 cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11 cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12 gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13 12.118.177.74 82.9/82.8ms
14 sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15 sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16 ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
** [neglected] no reply packets received from TTLs 17 through 18
19 [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms