Frage Wie viel Netzwerklatenz ist typisch für die Ost - West - Küste der USA?


Im Moment versuchen wir zu entscheiden, ob wir unser Rechenzentrum von der West- zur Ostküste verlegen sollen.

Allerdings sehe ich einige beunruhigende Latenzzahlen von meinem Standort an der Westküste bis zur Ostküste. Hier ist ein Beispielergebnis, das eine kleine .png-Logo-Datei in Google Chrome abruft und die Dev-Tools verwendet, um zu sehen, wie lange die Anfrage dauert:

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

Es macht Sinn, dass Corvallis, OR geografisch näher an meinem Standort in Berkeley, CA ist, also erwarte ich, dass die Verbindung ein bisschen schneller ist. Aber ich sehe eine Erhöhung der Latenz von +100ms, wenn ich den gleichen Test für NYC mache Server. Das scheint mir übertrieben. Besonders seit Die Zeit, die für die Übertragung der eigentlichen Daten aufgewendet wurde, stieg nur um 10%, die Latenzzeit stieg jedoch um 100%!

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

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

... aber nichts autoritatives.

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


99
2018-04-30 11:26


Ursprung


Jede Messung in Netzwerken, die Sie nicht kontrollieren, erscheint nahezu sinnlos. Zu oft wird bei diesen Arten von Netzwerkdiskussionen vergessen, dass jedem Paket eine zeitliche Komponente zugeordnet ist. Wenn Sie den Test wiederholt 24 x 7 und zu einem Schluss kommen, ist das eine Sache. Wenn Sie den Test zweimal durchgeführt haben, schlage ich vor, dass Sie ihn noch einmal ausführen. Und für diejenigen, die die Verwendung von Ping als ein Maß für die Leistung befürworten, nicht. In jedem größeren Netzwerk, an dem ich je gearbeitet habe, haben wir den ICMP-Verkehr auf die niedrigste Priorität gesetzt. Ping bedeutet nur eine Sache, und es ist nicht;) über die Leistung. - dbasnett
Von wo ich lebe, Jefferson City, MO, die Zeiten sind ähnlich. - dbasnett
Als Randnotiz: Licht selbst benötigt ~ 14ms, um von NY nach SF in gerader Linie (unter Berücksichtigung der Faser) zu reisen. - Shadok
Licht in der Faser bewegt sich mit einem Geschwindigkeitsfaktor von .67 (entspricht dem Brechungsindex) ~ 201.000 km / s, also mindestens 20 ms. - Zac67


Antworten:


Lichtgeschwindigkeit:
  Sie werden nicht die Geschwindigkeit des Lichts als einen interessanten akademischen Punkt schlagen. Dieser Link arbeitet Stanford nach Boston in ~ 40ms bestmöglicher Zeit. Als diese Person die Berechnung durchführte, entschied er, dass das Internet etwa "innerhalb eines Zweifachen der Lichtgeschwindigkeit" arbeitet, also etwa 85 ms Übertragungszeit.

TCP-Fenstergröße:
Wenn Sie Probleme mit der Übertragungsgeschwindigkeit haben, müssen Sie möglicherweise die TCP-Empfangsgröße des Empfangsfensters erhöhen. Sie müssen möglicherweise auch die Fensterskalierung aktivieren, wenn es sich um eine Verbindung mit hoher Bandbreite und hoher Latenz handelt (als "Long Fat Pipe" bezeichnet). 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 darauf ein, wie ich das in meiner Antwort berechnen soll Einen Elefanten abstimmen.

Geografie und Latenz:
Ein Fehlerpunkt einiger CDNs (Content Distributions Network) besteht darin, dass sie Latenz und Geografie gleichsetzen. Google hat viel mit seinem Netzwerk recherchiert und Fehler gefunden, die Ergebnisse wurden im White Paper veröffentlicht Über die End-to-End-Pfadinformationen hinausgehen, um die CDN-Leistung zu optimieren:

Erstens, obwohl die meisten Kunden sind   von einem geografisch nahe gelegenen CDN bedient   Knoten, ein beträchtlicher Anteil von Clients   Latenzen einige zehn   Millisekunden höher als bei anderen Clients   in der gleichen Region. Zweitens finden wir   Diese Warteschlangenverzögerungen überschreiben oft   die Vorteile eines Kunden interagieren   mit einem nahe gelegenen Server.

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, so dass Sie nicht immer die "beste" Route zu bestimmten geografischen Standorten bekommen . Sie können sich ansehen, wie Ihre IP mit anderen ISPs (Autonome Systeme) verbunden ist Glas-Router. Sie können auch ein spezieller Whois-Service:

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 zu erkunden linkrankEs gibt dir ein Bild des Internets um dich herum.


108
2018-04-30 12:03



stimme zu, Lichtgeschwindigkeit in der Luftlinie ist das Beste, was du tun kannst. Wirklich ausgezeichnete Antwort übrigens, genau das habe ich gesucht. Vielen Dank. - Jeff Atwood
Für die Neugierigen ist die tatsächliche Mathematik: 3000 mi / c = 16,1ms - tylerl
Im Vakuum kann ein Photon den Äquator in etwa 134 ms durchqueren. Das gleiche Photon im Glas würde etwa 200 ms benötigen. Ein 3000 Meilen langes Stück Faser hat 24 ms. der Verzögerung ohne irgendwelche Geräte. - dbasnett
Das erinnert mich an Der Fall der 500 Meilen E-Mail. - bahamat


Diese Seite würde vorschlagen, dass etwa 70-80 ms Latenz zwischen Ost- / Westküste USA typisch ist (San Francisco bis New York zum Beispiel).

Transatlantischer Pfad
NY 78 London
Wash 87 Frankfurt
Transpazifischer Pfad
SF 147 Hongkong
Trans-USA-Pfad
SF 72 NY

network latency by world city pairs

Hier sind meine Timings (Ich bin in London, England, also sind meine Westküstenzeiten höher als der Osten). Ich erhalte einen 74ms Latenz-Unterschied, der den Wert von dieser Seite zu unterstützen scheint.

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

Diese wurden mithilfe der Google Chrome-Entwicklungstools gemessen.


41
2018-04-30 11:45



coole Tabelle! NY zu SF ist zZ 71 ms darauf hast du Recht - wir können nicht erwarten, dass wir es besser machen. - Jeff Atwood
Vielen Dank. Es hat mir sehr geholfen. Dies ist eine weitere Quelle, um nach Netzwerklatenz zwischen verschiedenen Orten der Welt zu suchen - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Wenn möglich mit ICMP messen. ICMP-Tests verwenden normalerweise nur sehr kleine Nutzdaten, verwenden keinen Dreiweg-Handshake und müssen nicht wie HTTP mit einer anderen Anwendung im Stapel interagieren. In jedem Fall ist es von größter Wichtigkeit, dass HTTP-Ergebnisse nicht mit ICMP-Ergebnissen verwechselt werden. Sie sind Äpfel und Orangen.

Gehen durch die Antwort von Rich Adams und verwenden der Standort das er empfohlen hat, können Sie sehen, dass es auf dem Rückgrat von AT & T 72 ms dauert, damit sich ICMP-Verkehr zwischen ihren Endpunkten SF und NY bewegt. Das ist eine gute 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 einen Ping gegen careers.stackoverflow.com aus Ihrem Quellnetzwerk durchführen, sollten Sie etwas nicht zu weit von 72 ms (vielleicht +/- 20 ms) sehen. Wenn das der Fall ist, dann können Sie wahrscheinlich annehmen, dass der Netzwerkpfad zwischen Ihnen beiden in Ordnung ist und innerhalb normaler Bereiche läuft. Wenn nicht, nicht in Panik geraten und von einigen anderen Orten messen. Es könnte Ihr ISP sein.

Unter der Annahme, dass dies der Fall ist, besteht Ihr nächster Schritt darin, die Anwendungsebene anzugehen und festzustellen, ob etwas mit dem zusätzlichen Overhead, den Sie mit Ihren HTTP-Anfragen sehen, nicht stimmt. Dies kann von App zu App aufgrund von Hardware, Betriebssystem und Anwendungsstapel variieren, aber da Sie sowohl an der Ost- als auch an der Westküste über nahezu identische Geräte verfügen, könnten Ostküstenbenutzer die Westküstenserver und Westküstenbenutzer den Osten erreichen Küste. Wenn beide Seiten richtig konfiguriert sind, würde ich erwarten, dass alle Zahlen weniger gleich sind und daher zeigen, dass das, was Sie sehen, ziemlich gleichrangig ist.

Wenn diese HTTP-Zeiten eine große Varianz aufweisen, wäre ich nicht überrascht, wenn es auf der Website mit der langsameren Leistung ein Konfigurationsproblem gäbe.

Wenn Sie jetzt an diesem Punkt 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, Low-Level-Elemente wie TCP-Fenster zu optimieren, bin ich sehr skeptisch, dass es einen großen Einfluss auf etwas wie Stack Overflow haben würde. Aber hey - Sie werden es nicht wissen, bis Sie es versuchen und messen.


10
2018-04-30 17:34





Einige der Antworten hier verwenden ping und traceroute für ihre Erklärungen. Diese Tools haben ihren Platz, aber sie sind nicht zuverlässig für die Messung der Netzwerkleistung.

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

Es gibt andere Umstände, unter denen die ICMP-Antwort viel langsamer sein kann als die tatsächliche Weiterleitungsleistung eines Routers. Stellen Sie sich zum Beispiel einen All-Software-Router (keine spezialisierte Weiterleitungshardware) vor, der 99% der CPU-Kapazität ausmacht, aber dennoch den Verkehr in Ordnung bringt. Möchten Sie, dass viele Zyklen Traceroute-Antworten verarbeiten oder Traffic weiterleiten? Die Verarbeitung der Antwort hat also eine sehr niedrige Priorität.

Als Ergebnis geben Ping / Traceroute Ihnen Angemessenheit Obergrenzen - Die Dinge laufen mindestens so schnell - aber sie sagen nicht wirklich, wie schnell der reale Verkehr wird.

In jedem Fall -

Hier ist ein Beispiel einer Traceroute von der University of Michigan (Zentral-USA) nach Stanford (Westküste der USA). (Es passiert zufällig über Washington, DC (Ostküste USA), das ist 500 Meilen in die "falsche" Richtung.)

% 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

Beachten Sie insbesondere den Zeitunterschied zwischen den Traceroute-Ergebnissen von waschen Router und der atla Router (Hopfen 7 & 8). Der Netzwerkpfad wird zuerst gewaschen und dann zu atla. Waschen dauert 50-100ms, um zu reagieren, atla dauert etwa 28ms. Offensichtlich ist Atla weiter weg, aber seine Ergebnisse zeigen, dass es näher ist.

Sehen http://www.internet2.edu/performance/ für viele Informationen zur Netzwerkmessung. (Haftungsausschluss, ich arbeitete für Internet2). Siehe auch: https://fasterdata.es.net/

Um der ursprünglichen Frage eine gewisse Relevanz hinzuzufügen ... Wie Sie sehen können, hatte ich eine Ping-Zeit von 83 ms nach Stanford, also wissen wir, dass das Netzwerk so schnell gehen kann.

Beachten Sie, dass der Netzwerkpfad für Forschung und Bildung, den ich auf diesem Traceroute genommen habe, wahrscheinlich schneller ist als ein Standard-Internetpfad. R & E-Netzwerke überbieten ihre Verbindungen im Allgemeinen zu sehr, 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


7
2017-08-15 15:46





Ich sehe konstante Unterschiede, und ich 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 der Verwendung der Ressourcenansicht von Google Chrome und der wiederholten Aktualisierung jedes Links gemessen.

Traceroute zu 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 fängt es jetzt an, in eine Schleife oder Ähnliches zu gehen und gibt weiterhin Sterne und Timeout bis 30 Hops und endet dann.

Beachten Sie, dass die Tracerouten von einem anderen Host stammen als die Timings beim Start. Ich musste RDP auf meinem Hostserver ausführen, um sie auszuführen


6
2018-04-30 11:43



Richtig, es wird erwartet, dass das Rechenzentrum an der Ostküste freundlicher für unser europäisches Publikum sein würde - Sie sehen etwa + 200 ms Zeit, um die Breite der USA zu durchqueren. Sollte nur ~ 80ms für die anderen Antworten sein? - Jeff Atwood
es sieht so aus, als ob es bei ungefähr 200ms konsistent ist, ich habe jetzt ungefähr 20-30 Mal auf beide aktualisiert (nicht zur selben Zeit), und die Serverfault-Seite sieht aus, als ob sie um 200ms +/- mehr schwebt als die andere . Ich habe eine Traceroute ausprobiert, aber es hat Sterne in allem, also haben vielleicht unsere IT-Administratoren etwas blockiert. - Lasse Vågsæther Karlsen


Ich sehe ca. 80-90ms Latenz auf gut laufenden, gut gemessenen Verbindungen zwischen Ost- und Westküste.

Es wäre interessant zu sehen, wo Sie Latenz gewinnen - versuchen Sie ein Werkzeug wie Layer-Four-Traceroute (lft). Die Chancen sind eine Menge davon auf der "letzten Meile" (d. H. In Ihrem lokalen Breitbandanbieter) gewonnen.

Dass die Übertragungszeit nur geringfügig beeinflusst wurde, ist zu erwarten - Paketverlust und Jitter sind bei der Untersuchung von Übertragungszeitunterschieden zwischen zwei Standorten hilfreichere Messgrößen.


2
2018-04-30 11:42





Nur zum Spaß, als ich das Online-Spiel Lineage 2 NA aus Europa gespielt habe:

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

Der Unterschied scheint zu bestätigen, dass bis zu 100ms in Anbetracht der unvorhersehbaren Natur des Internets vernünftig sind.

Mit dem umjubelten Chrome-Aktualisierungstest erhalte ich eine Dokumentladezeit, die sich mit ungefähr 130 ms unterscheidet.


2
2018-04-30 12:52