Momentan versuchen wir zu entscheiden, ob unser Rechenzentrum von der Westküste an die Ostküste verlegt werden soll.

Von meinem Standort an der Westküste bis zur Ostküste sehe ich jedoch einige störende Latenzzeiten. Hier ist ein Beispielergebnis, bei dem eine kleine PNG-Logodatei in Google Chrome abgerufen und mithilfe der Entwicklungstools überprüft wird, wie lange die Anforderung dauert:

• Westküste bis Ostküste:
  215 ms Latenz, 46 ms Übertragungszeit, insgesamt 261 ms
• Westküste zu Westküste:
  114 ms Latenz, 41 ms Übertragungszeit, insgesamt 155 ms

Es ist sinnvoll, dass Corvallis, OR geografisch näher an meinem Standort in Berkeley, CA, liegt. Daher erwarte ich, dass die Verbindung etwas schneller hergestellt werden kann. Bei der Durchführung des gleichen Tests mit dem NYC ist jedoch eine Latenzerhöhung von + 100 ms zu verzeichnen Server. Das kommt mir ... übertrieben vor. Zumal der Zeitaufwand für die Übertragung der eigentlichen Daten nur um 10% gestiegen ist, die Latenz jedoch um 100%!

Das fühlt sich für mich ... falsch an.

Ich habe hier ein paar Links gefunden, die hilfreich waren (über Google nicht weniger!) ...

• Beeinträchtigt die Routing-Distanz die Leistung erheblich?
• Wie wirkt sich die Geografie auf die Netzwerklatenz aus?
• Latenz bei Internetverbindungen von Europa nach USA

... aber nichts Maßgebendes.

Also ist das normal? Es fühlt sich nicht normal an. Was ist die "typische" Latenz, die ich beim Verschieben von Netzwerkpaketen von der Ostküste <-> Westküste der USA erwarten sollte?

Lichtgeschwindigkeit:
Sie werden die Lichtgeschwindigkeit nicht als einen interessanten akademischen Punkt übertreffen. Über diesen Link gelangen Sie von Stanford nach Boston zur bestmöglichen Zeit (~ 40 ms). Als diese Person die Berechnung durchführte, entschied sie, dass das Internet ungefähr "innerhalb eines Faktors von zwei der Lichtgeschwindigkeit" betrieben wird, so dass eine Übertragungszeit von ungefähr 85 ms vorliegt.

TCP-Fenstergröße:
Wenn Sie Probleme mit der Übertragungsgeschwindigkeit haben, müssen Sie möglicherweise die TCP-Größe des Empfangsfensters erhöhen. Möglicherweise müssen Sie auch die Fensterskalierung aktivieren, wenn es sich um eine Verbindung mit hoher Bandbreite und hoher Latenz handelt ("Long Fat Pipe"). Wenn Sie also eine große Datei übertragen, benötigen Sie ein ausreichend großes Empfangsfenster, um die Pipe zu füllen, ohne auf Fensteraktualisierungen warten zu müssen. Ich ging in meiner Antwort Tuning an Elephant auf einige Details ein, wie man das berechnet .

Geografie und Latenzzeit:
Einige CDNs (Content Distribution Networks) weisen den Nachteil auf, dass sie Latenzzeit und Geografie gleichsetzen. Google eine Menge Forschung mit ihrem Netzwerk hat und fand Fehler in diesem veröffentlichten sie die Ergebnisse in dem Whitepaper Bewegen über End-to-End - Pfad Informationen CDN Leistung zu optimieren :

Obwohl die meisten Clients von einem geografisch nahe gelegenen CDN-Knoten bedient werden, treten bei einem beträchtlichen Teil der Clients Latenzen auf, die mehrere zehn Millisekunden höher sind als bei anderen Clients in derselben Region. Zweitens stellen wir fest, dass Warteschlangenverzögerungen häufig die Vorteile eines Clients außer Kraft setzen, der mit einem nahe gelegenen Server interagiert.

BGP-Peerings:
Auch wenn Sie anfangen, BGP (Core Internet Routing Protocol) zu studieren und wie ISPs Peerings wählen, werden Sie feststellen, dass es oft mehr um Finanzen und Politik geht, sodass Sie möglicherweise nicht immer die 'beste' Route zu bestimmten geografischen Standorten finden auf Ihrem ISP. Sie können mithilfe eines Spiegel-Routers überprüfen, wie Ihre IP-Adresse mit anderen ISPs (autonomen Systemen) verbunden ist . Sie können auch einen speziellen whois-Service nutzen :

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

Es macht auch Spaß, diese als Peerings mit einem GUI- Tool wie linkrank zu erkunden. Es gibt Ihnen ein Bild des Internets um Sie herum.

Diese Seite würde eine typische Latenz von ca. 70-80 ms zwischen der Ost- und Westküste der USA vermuten lassen (zum Beispiel von San Francisco nach New York).

Transatlantischer Pfad
NY 78 London
87 Frankfurt waschen

Transpazifischer Pfad
SF 147 Hong Kong

Trans-USA-Pfad
SF 72 NY

Hier sind meine Zeiten (ich bin in London, England, meine Westküstenzeiten sind also höher als in Ost). Ich erhalte einen Latenzunterschied von 74 ms, der den Wert dieser Site zu unterstützen scheint.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

Diese wurden mit Google Chrome-Entwicklungstools gemessen.

Messen Sie nach Möglichkeit zuerst mit ICMP. ICMP-Tests verwenden in der Regel standardmäßig eine sehr kleine Nutzlast, verwenden keinen Drei-Wege-Handshake und müssen nicht wie HTTP über den Stack mit einer anderen Anwendung interagieren. In jedem Fall ist es äußerst wichtig, dass HTTP-Ergebnisse nicht mit ICMP-Ergebnissen verwechselt werden. Sie sind Äpfel und Orangen.

Anhand der Antwort von Rich Adams und der von ihm empfohlenen Website können Sie erkennen, dass der ICMP-Verkehr auf dem Backbone von AT & T 72 ms benötigt, um sich zwischen den Endpunkten von SF und NY zu bewegen. Das ist eine faire Zahl, aber Sie müssen bedenken, dass dies in einem Netzwerk geschieht, das vollständig von AT & T kontrolliert wird. Der Übergang zu Ihrem Heim- oder Büronetzwerk wird nicht berücksichtigt.

Wenn Sie in Ihrem Quellennetzwerk einen Ping an careers.stackoverflow.com senden, sollten Sie etwas sehen, das nicht zu weit von 72 ms entfernt ist (möglicherweise +/- 20 ms). Wenn dies der Fall ist, können Sie wahrscheinlich davon ausgehen, dass der Netzwerkpfad zwischen Ihnen beiden in Ordnung ist und in normalen Bereichen ausgeführt wird. Wenn nicht, geraten Sie nicht in Panik und messen Sie an einigen anderen Orten. Es könnte Ihr ISP sein.

Angenommen, dies ist erfolgreich, besteht Ihr nächster Schritt darin, die Anwendungsschicht in Angriff zu nehmen und festzustellen, ob mit dem zusätzlichen Overhead, den Sie bei Ihren HTTP-Anforderungen sehen, etwas nicht stimmt. Dies kann von App zu App aufgrund von Hardware, Betriebssystem und Anwendungsstapel variieren. Da Sie jedoch an der Ost- und der Westküste über ungefähr identische Geräte verfügen, können Benutzer der Ostküste die Server der Westküste und Benutzer der Westküste die Ostküste treffen Küste. Wenn beide Sites richtig konfiguriert sind, würde ich erwarten, dass alle Zahlen weniger gleich sind und daher zeigen, dass das, was Sie sehen, ziemlich grob ist.

Wenn diese HTTP-Zeiten sehr unterschiedlich sind, würde ich mich nicht wundern, wenn auf der Website mit der langsameren Leistung ein Konfigurationsproblem auftritt.

Jetzt, wenn Sie an diesem Punkt angelangt sind, können Sie versuchen, eine aggressivere Optimierung auf der App-Seite durchzuführen, um zu sehen, ob diese Zahlen überhaupt reduziert werden können. Wenn Sie beispielsweise IIS 7 verwenden, nutzen Sie die Cache-Funktionen usw.? Vielleicht könntest du dort etwas gewinnen, vielleicht auch nicht. Wenn es darum geht, Elemente auf niedriger Ebene wie z. B. TCP-Fenster zu optimieren, bin ich sehr skeptisch, dass dies erhebliche Auswirkungen auf so etwas wie Stapelüberlauf haben würde. Aber hey - Sie werden es nicht wissen, bis Sie es versuchen und messen.

Einige der Antworten hier verwenden Ping und Traceroute für ihre Erklärungen. Diese Tools haben ihren Platz, sind jedoch für die Messung der Netzwerkleistung nicht zuverlässig.

Insbesondere senden (zumindest einige) Juniper-Router die Verarbeitung von ICMP-Ereignissen an die Steuerebene des Routers. Dies ist VIEL langsamer als die Weiterleitungsebene, insbesondere in einem Backbone-Router.

Unter anderen Umständen kann die ICMP-Antwort viel langsamer sein als die tatsächliche Weiterleitungsleistung eines Routers. Stellen Sie sich zum Beispiel einen All-Software-Router vor (keine spezialisierte Weiterleitungshardware), der 99% der CPU-Kapazität aufweist, aber dennoch den Datenverkehr in Ordnung bringt. Möchten Sie, dass es viele Zyklen mit der Verarbeitung von Traceroute-Antworten oder der Weiterleitung von Datenverkehr verbringt? Die Verarbeitung der Antwort hat daher eine sehr niedrige Priorität.

Infolgedessen gibt Ping / Traceroute Ihnen vernünftige Obergrenzen - die Dinge verlaufen zumindest so schnell - aber sie sagen Ihnen nicht wirklich, wie schnell der echte Verkehr läuft.

In jedem Fall -

Hier ist ein Beispiel für eine Route von der University of Michigan (Zentral-USA) nach Stanford (Westküste der USA). (Es passiert Washington, DC (Ostküste der USA), das 500 Meilen in der "falschen" Richtung ist.)

% 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

Insbesondere beachten Sie die Zeitdifferenz zwischen dem trace ergibt mich aus der Wasch Router und dem atla Router (Hops 7 & 8). der netzwerkpfad geht erst zum waschen und dann zum atla. Waschen dauert 50-100ms, um zu reagieren, atla dauert etwa 28ms. Atla ist eindeutig weiter weg, aber seine Traceroute-Ergebnisse deuten darauf hin, dass es näher ist.

Unter http://www.internet2.edu/performance/ finden Sie zahlreiche Informationen zur Netzwerkmessung. (Haftungsausschluss, ich habe für internet2 gearbeitet). Siehe auch: https://fasterdata.es.net/

Um der ursprünglichen Frage eine besondere Relevanz zu verleihen ... Wie Sie sehen, hatte ich eine Ping-Zeit von 83 ms nach Stanford, sodass wir wissen, dass das Netzwerk zumindest so schnell gehen kann.

Beachten Sie, dass der Pfad des Forschungs- und Bildungsnetzwerks, den ich auf dieser Traceroute eingeschlagen habe, wahrscheinlich schneller ist als ein Standard-Internetpfad. R & E-Netzwerke überlasten im Allgemeinen ihre Verbindungen, was eine Pufferung in jedem Router unwahrscheinlich macht. Beachten Sie auch den langen physischen Pfad, der länger ist als von Küste zu Küste, obwohl er eindeutig für den tatsächlichen Verkehr repräsentativ ist.

michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford

Ich sehe beständige Unterschiede und sitze in Norwegen:

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

Dies wurde mit der wissenschaftlich genauen und bewährten Methode gemessen, bei der die Ressourcenansicht von Google Chrome verwendet und jeder Link nur wiederholt aktualisiert wurde.

Traceroute zum Serverfehler

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.

Traceroute zu Karrieren

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.

Leider geht es jetzt in eine Schleife oder so und gibt weiterhin Sterne und Auszeit, bis 30 Hops und endet dann.

Beachten Sie, dass die Traceroutes von einem anderen Host stammen als zu Beginn. Ich musste RDP auf meinem gehosteten Server ausführen, um sie auszuführen

Ich sehe eine Latenz von ca. 80-90 ms auf gut geführten, gut gemessenen Verbindungen zwischen der Ost- und der Westküste.

Es wäre interessant zu sehen, wo Sie Latenz gewinnen - probieren Sie ein Werkzeug wie Layer-4-Traceroute (LFT). Die Chancen stehen gut, dass ein Großteil davon auf der "letzten Meile" (dh bei Ihrem lokalen Breitbandanbieter) gewonnen wird.

Es ist zu erwarten, dass die Übertragungszeit nur geringfügig beeinflusst wurde - Paketverlust und Jitter sind nützlichere Messwerte, um die Unterschiede der Übertragungszeit zwischen zwei Standorten zu untersuchen.

Nur zum Spaß, als ich das Onlinespiel Lineage 2 NA aus Europa heraus gespielt habe:

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

Der Unterschied scheint zu stützen, dass bis zu 100 ms in Anbetracht der unvorhersehbaren Natur des Internets in Ordnung sind.

Mit dem bewährten Chrome-Aktualisierungstest erhalte ich eine Dokumentladezeit, die sich von ungefähr 130 ms unterscheidet.

Jeder hier hat einen wirklich guten Punkt. und sind richtig in ihrer eigenen POV.

Und es kommt alles darauf an, dass es hier keine wirkliche exakte Antwort gibt, da es so viele Variablen gibt, dass jede Antwort immer als falsch erwiesen werden kann, wenn nur eine von hundert Variablen geändert wird.

Wie die 72-ms-Latenzzeit von NY zu SF ist die Latenzzeit von PoP zu PoP eines Trägers eines Pakets. Dies berücksichtigt keine der anderen wichtigen Punkte, auf die einige hier hingewiesen haben, wie zum Beispiel Überlastung, Paketverlust, Dienstgüte, Pakete in der falschen Reihenfolge oder Paketgröße oder Netzwerkumleitung zwischen der perfekten Welt von PoP und PoP .

Und dann, wenn Sie die letzte Meile (im Allgemeinen viele Meilen) vom PoP zu Ihrem tatsächlichen Standort innerhalb der beiden Städte addieren, in denen all diese Variablen viel flüssiger werden, eskalieren sie exponentiell aus vernünftigen Rätselraten heraus!

Als Beispiel habe ich einen Test zwischen NY City und SF im Laufe eines Geschäftstages durchgeführt. Ich habe dies an einem Tag getan, an dem es keine größeren "Zwischenfälle" auf der ganzen Welt gab, die eine Verkehrsspitze verursachen würden. Vielleicht war das in der heutigen Welt kein Durchschnitt! Trotzdem war es mein Test. Tatsächlich habe ich in diesem Zeitraum und während der normalen Geschäftszeiten jeder Küste von einem Geschäftsstandort zum nächsten gemessen.

Zur gleichen Zeit überwachte ich die Nummern der Schaltungsanbieter im Internet.

Die Ergebnisse waren Latenzzahlen zwischen 88 und 100 ms von Tür zu Tür der Geschäftsstandorte. Dies beinhaltete keine Inter-Office-Netzwerk-Latenznummern.

Die Netzwerklatenz des Dienstanbieters lag zwischen 70 und 80 ms. Das heißt, die Latenz der letzten Meile hätte zwischen 18 und 30 ms liegen können. Die genauen Spitzen und Tiefen zwischen den beiden Umgebungen habe ich nicht korreliert.

NYC Timings:

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

Verwenden von Chrome über eine Privatverbindung.

Verwenden von lft von einem VPS in einem Rechenzentrum in Newark, New Jersey:

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