現在、データセンターを西海岸から東海岸に移動するかどうかを決定しようとしています。

しかし、西海岸の場所から東海岸まで、いくつかの不穏なレイテンシーが見られます。Google Chromeで小さな.pngロゴファイルを取得し、開発ツールを使用してリクエストにかかる時間を確認するサンプル結果を次に示します。

• 西海岸から東海岸へ：
  レイテンシ215ミリ秒、転送時間46ミリ秒、合計261ミリ秒
• 西海岸から西海岸へ：
  遅延114ミリ秒、転送時間41ミリ秒、合計155ミリ秒

オレゴン州コーバリスがカリフォルニア州バークレーの私の場所に地理的に近いことは理にかなっているので、接続が少し速くなると思います。サーバ。それは..私には過剰なようです。特に、実際のデータの転送に費やされる時間は10％しか増加しなかったため、レイテンシは100％増加しました！

それは...間違っている...私には感じています。

ここに役立ついくつかのリンクが見つかりました（Googleでも同様です）...

• ルーティング距離はパフォーマンスに大きく影響しますか？
• 地理はネットワーク遅延にどのように影響しますか？
• ヨーロッパからアメリカへのインターネット接続の遅延

...しかし、権威はありません。

それで、これは正常ですか？普通に感じません。米国の東海岸<->西海岸からネットワークパケットを移動するときに予想される「典型的な」レイテンシとは何ですか？

光の速度：
興味深い学術的ポイントとして、光の速度に勝るものはありません。 このリンクは、スタンフォード大学からボストンまでの最短40ミリ秒の時間で機能します。この人が計算を行ったとき、彼はインターネットが「光の速度の2倍以内」で動作することを決定したので、転送時間は約85ミリ秒です。

TCPウィンドウサイズ：
転送速度の問題がある場合は、受信ウィンドウのTCPサイズを増やす必要があります。また、これが高遅延の高帯域幅接続である場合は、ウィンドウスケーリングを有効にする必要がある場合があります（「Long Fat Pipe」と呼ばれます）。したがって、大きなファイルを転送する場合は、ウィンドウの更新を待たずにパイプを満たすために十分な大きさの受信ウィンドウが必要です。私の答え「象のチューニング」でそれを計算する方法についていくらか詳しく説明しました。

地理とレイテンシー：
一部のCDN（Content Distribtuion Networks）の欠点は、それらがレイテンシーと地理を同一視することです。Googleは自社のネットワークで多くの調査を行い、これに欠陥を発見し、CDNパフォーマンスを最適化するためのエンドツーエンドパス情報を超えて移動するホワイトペーパーに結果を公開しました。

まず、ほとんどのクライアントは地理的に近いCDNノードによって処理されますが、かなりの割合のクライアントが同じ地域の他のクライアントよりも数十ミリ秒高いレイテンシを経験します。第二に、キューイングの遅延は、クライアントが近くのサーバーと対話する利点をしばしば無効にすることがわかります。

BGPピアリング：
また、BGP（コアインターネットルーティングプロトコル）とISPがピアリングを選択する方法を勉強し始めると、多くの場合、財政と政治に関するものであることがわかります。 ISPで。グラスルーターを使用して、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

それはまたのようなGUIツールを使用して、ピアリングとしてこれらを探索するのも楽しいlinkrank、それはあなたの周りのインターネットの画像を提供します。

このサイトは、米国東海岸と西海岸の間で約70〜80ミリ秒の遅延が典型的であることを示唆しています（たとえば、サンフランシスコからニューヨークへ）。

大西洋横断パス
NY 78ロンドン
ウォッシュ87フランクフルト

太平洋横断パス
SF 147香港

アメリカ横断パス
SF 72ニューヨーク

ここに私のタイミングがあります（私はイギリスのロンドンにいるので、西海岸の時間は東よりも長いです）。遅延の差は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エンドポイント間を移動するのに72ミリ秒かかることがわかります。これは妥当な数字ですが、これはAT＆Tによって完全に制御されるネットワーク上にあることに留意する必要があります。ホームネットワークまたはオフィスネットワークへの移行は考慮されません。

ソースネットワークからcarriers.stackoverflow.comに対してpingを実行すると、72ミリ秒（+/- 20ミリ秒）からそれほど離れていないものが表示されるはずです。その場合は、2人の間のネットワークパスが正常であり、通常の範囲内で実行されていると想定できます。そうでない場合、パニックに陥らずに、他のいくつかの場所から測定します。ISPである可能性があります。

それが成功したと仮定すると、次のステップは、アプリケーション層に取り組み、HTTPリクエストで見られる追加のオーバーヘッドに問題がないかどうかを判断することです。これは、ハードウェア、OS、およびアプリケーションスタックによりアプリごとに異なる場合がありますが、東海岸と西海岸の両方にほぼ同じ機器があるため、東海岸のユーザーが西海岸のサーバーを攻撃し、西海岸のユーザーが東を攻撃する可能性があります海岸。両方のサイトが適切に構成されている場合、すべての数値がより平等になり、したがって、表示されているものが粗雑なものとほぼ同等であることを示すことが期待されます。

これらのHTTP時間に大きなばらつきがある場合、パフォーマンスの遅いサイトで構成の問題があったとしても驚かないでしょう。

この時点で、アプリ側でより積極的な最適化を試みて、これらの数をまったく減らすことができるかどうかを確認できます。たとえば、IIS 7を使用している場合、そのキャッシュ機能などを利用していますか？たぶん、あなたはそこで何かを勝ち取ることができたかもしれません。TCPウィンドウなどの低レベルの項目を微調整することになると、Stack Overflowのようなものに大きな影響を与えることに非常に懐疑的です。しかし、ちょっと-あなたがそれを試して測定するまで、あなたは知りません。

ここでの回答のいくつかは、説明にpingとtracerouteを使用しています。これらのツールには場所がありますが、ネットワークパフォーマンスの測定には信頼できません。

特に、（少なくとも一部の）Juniperルーターは、ICMPイベントの処理をルーターのコントロールプレーンに送信します。これは、特にバックボーンルータで、転送プレーンよりも非常に低速です。

ICMP応答がルーターの実際の転送パフォーマンスよりもはるかに遅くなる可能性がある他の状況があります。たとえば、CPU容量の99％にあるすべてのソフトウェアルーター（特殊な転送ハードウェアなし）を想像してください。traceroute応答の処理やトラフィックの転送に多くのサイクルを費やしたいですか？そのため、応答の処理は非常に低い優先度です。

その結果、ping / tracerouteは妥当な上限を提供します-少なくともその速度で進んでいます-しかし、実際のトラフィックの速度を実際には伝えません。

いずれにしても -

ミシガン大学（米国中部）からスタンフォード（米国西海岸）までのtracerouteの例を次に示します。（たまたま、「間違った」方向に500マイルのワシントンDC（米国東海岸）を経由します。）

% 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

特に、ウォッシュルーターとatlaルーター（ホップ7および8）からのtraceroute結果の時間差に注意してください。ネットワークパスは、最初にウォッシュ、次にatlaに進みます。ウォッシュは応答するのに50〜100msかかり、atlaは約28msかかります。明らかにatlaは遠くにありますが、tracerouteの結果は、より近いことを示唆しています。

ネットワーク測定に関する多くの情報については、http：//www.internet2.edu/performance/を参照してください。（免責事項、私はインターネット2で働いていました）。参照：https : //fasterdata.es.net/

元の質問に特定の関連性を追加するには...ご覧のように、スタンフォードへの往復のping時間は83ミリ秒でした。

このtracerouteで行った研究と教育のネットワークパスは、一般的なインターネットパスよりも高速である可能性が高いことに注意してください。R＆Eネットワークは通常、接続を過剰にプロビジョニングしているため、各ルーターでのバッファリングはほとんどありません。また、実際のトラフィックを明確に表していますが、海岸から海岸よりも長い物理パスに注意してください。

ミシガン州->ワシントン、DC->アトランタ->ヒューストン->ロサンゼルス->スタンフォード

私は一貫した違いを見ています、そして私はノルウェーに座っています：

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

これは、Google Chromeのリソースビューを使用し、各リンクを繰り返し更新する科学的に正確で実績のある方法で測定されました。

サーバー障害へのトレースルート

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して実行する必要がありました。

東海岸と西海岸の間の適切に実行され、よく測定されたリンクで約80〜90ミリ秒の遅延が発生します。

遅延が発生している場所を確認するのは興味深いでしょう。レイヤ4 traceroute（lft）などのツールを試してください。多くの場合、「ラストマイル」で（つまり、ローカルブロードバンドプロバイダーで）獲得できます。

転送時間への影響はごくわずかであることが予想されます。パケット損失とジッターは、2つの場所間の転送時間の差を調査する際に、より有用な測定値です。

楽しみのために、ヨーロッパからオンラインゲームLineage 2 NAリリースをプレイしたとき：

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

違いは、インターネットの予測不可能な性質を考慮して、最大100ミリ秒が妥当であることをサポートしているようです。

高く評価されているChrome更新テストを使用すると、ドキュメントの読み込み時間が約130ミリ秒異なります。

ここのみんなが本当に良い点を持っています。そして、彼ら自身のPOVで正しいです。

そして、すべての答えはここに本当の正確な答えがないことに帰着します。なぜなら、与えられた答えは100個の変数のうちの1つを変更するだけで常に間違っていると証明できる変数が非常に多いからです。

NYからSFへの72ミリ秒の遅延は、パケットのキャリアのPoPからPoPへの遅延です。これは、混雑、パケット損失、サービスの品質、パケットの順序、パケットサイズ、またはPoPからPoPの完璧な世界の間のネットワークの再ルーティングについてここで指摘した他の素晴らしい点を考慮していません。 。

そして、PoPからラストマイル（通常は何マイルも）を2つの都市内の実際の場所に追加すると、これらの変数がすべてより流動的になり、合理的な推測能力から指数関数的にエスカレートし始めます！

例として、私は営業日の間にニューヨーク市とSFの間でテストを実行しました。トラフィックの急増を引き起こすような主要な「インシデント」が世界中で発生していなかったので、私はこれを1日に行いました。したがって、これは今日の世界では平均的ではなかったかもしれません！しかし、それでも私のテストでした。この期間と各海岸の通常の営業時間中に、実際にある事業所から別の事業所までを測定しました。

同時に、Web上の回線プロバイダー番号を監視しました。

結果は、営業拠点のドアからドアへの88ミリ秒から100ミリ秒の間の遅延数でした。これには、オフィス内ネットワークの遅延数は含まれていません。

サービスプロバイダーのネットワーク遅延は70〜80ミリ秒の範囲でした。ラストマイル遅延の意味は、18〜30ミリ秒の範囲でした。2つの環境間で正確なピークとローを相関させませんでした。

NYCのタイミング：

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