121 votes

Quelle est la latence réseau "typique" entre la côte est et la côte ouest des États-Unis ?

En ce moment, nous essayons de décider si nous devons déplacer notre centre de données de la côte ouest à la côte est.

Cependant, je constate des chiffres de latence inquiétants depuis mon emplacement sur la côte ouest vers la côte est. Voici un résultat d'exemple, en récupérant un petit fichier .png logo dans Google Chrome et en utilisant les outils de développement pour voir combien de temps prend la demande :

  • De la côte ouest à la côte est :
    215 ms de latence, 46 ms de temps de transfert, 261 ms au total
  • De la côte ouest à la côte ouest :
    114 ms de latence, 41 ms de temps de transfert, 155 ms au total

Il est logique que Corvallis, OR soit géographiquement plus proche de mon emplacement à Berkeley, CA, donc je m'attends à ce que la connexion soit un peu plus rapide.. mais je remarque une augmentation de la latence de +100ms lorsque je réalise le même test vers le serveur de NYC. Cela me semble .. excessif. D'autant plus que le temps passé à transférer les données réelles n'a augmenté que de 10%, alors que la latence a augmenté de 100%!

Cela semble... erroné... pour moi.

J'ai trouvé quelques liens ici qui ont été utiles (à travers Google qui plus est!) ...

... mais rien d'officiel.

Alors, est-ce normal? Ça ne semble pas normal. Quelle est la latence "typique" que je devrais m'attendre en déplaçant des paquets réseau de la côte est <--> côte ouest des États-Unis?

10 votes

Toute mesure effectuée sur des réseaux que vous ne contrôlez pas semble presque inutile. Trop souvent dans ce type de discussions sur les réseaux, nous oublions qu'il y a un composant temporel associé à chaque paquet. Si vous avez effectué le test de manière répétée 24 heures sur 24 et 7 jours sur 7 et que vous en avez tiré une conclusion, c'est une chose. Si vous avez fait le test deux fois, je vous suggère d'en faire davantage. Et pour ceux qui préconisent l'utilisation du ping comme mesure de performance, ne le faites pas. Sur chaque réseau majeur sur lequel j'ai travaillé, nous avons défini le trafic ICMP comme ayant la priorité la plus basse. Ping ne signifie qu'une chose, et ce n'est pas ;) à propos de la performance.

0 votes

De là où je vis, Jefferson City, MO, les heures sont similaires.

4 votes

En tant que note secondaire : la lumière prend elle-même environ 14 ms pour se rendre de NY à SF en ligne droite (en considérant la fibre tout du long).

124voto

Kyle Brandt Points 81077

Vitesse de la lumière:
Vous ne pouvez pas battre la vitesse de la lumière en tant que point académique intéressant. Ce lien calcule le trajet de Stanford à Boston en ~40ms au mieux possible. Lorsque cette personne a fait le calcul, il a décidé que l'internet fonctionne à environ "dans un facteur de deux de la vitesse de la lumière", donc il y a environ ~85ms de temps de transfert.

Taille de la fenêtre TCP:
Si vous rencontrez des problèmes de vitesse de transfert, vous devrez peut-être augmenter la taille de la fenêtre de réception TCP. Vous devrez peut-être également activer le redimensionnement de la fenêtre si vous avez une connexion à large bande avec une latence élevée (appelée un "Long Fat Pipe"). Donc, si vous transférez un gros fichier, vous devez avoir une fenêtre de réception suffisamment grande pour remplir le tuyau sans avoir à attendre les mises à jour de la fenêtre. J'ai expliqué en détail comment calculer cela dans ma réponse Tuning an Elephant.

Géographie et latence:
Un point faible de certains CDN (réseaux de distribution de contenu) est qu'ils assimilent latence et géographie. Google a fait beaucoup de recherches avec leur réseau et a trouvé des défauts à ce sujet, ils ont publié les résultats dans le document technique Moving Beyond End-to-End Path Information to Optimize CDN Performance:

Premièrement, même si la plupart des clients sont servis par un nœud CDN géographiquement proche, une fraction importante de clients subit des latences plusieurs dizaines de millisecondes plus élevées que d'autres clients dans la même région. Deuxièmement, nous constatons que les retards d'attente l'emportent souvent sur les avantages d'un client interagissant avec un serveur proche.

Faisceaux BGP:
De plus, si vous commencez à étudier BGP (protocole central de routage internet) et comment les FSI choisissent leurs faisceaux, vous verrez que cela concerne souvent plus les finances et la politique, vous pourriez donc ne pas toujours obtenir la 'meilleure' route vers certaines emplacements géographiques en fonction de votre FSI. Vous pouvez voir comment votre adresse IP est connectée à d'autres FSI (systèmes autonomes) en utilisant un routeur de miroir de BGP. Vous pouvez également utiliser un service spécial whois:

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | Nom AS
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

Il est également amusant d'explorer ces faisceaux avec un outil graphique comme linkrank, cela vous donne une image d'internet autour de vous.

1 votes

Je suis d'accord, la vitesse de la lumière est la meilleure estimation possible. Vraiment excellente réponse, c'est exactement ce que je cherchais. Merci.

4 votes

Pour les curieux, les mathématiques actuelles sont : 3000 mi / c = 16.1ms

15 votes

Dans le vide, un photon peut parcourir l'équateur en environ 134 ms. Le même photon dans du verre prendrait environ 200 ms. Un morceau de fibre de 3 000 miles a un retard de 24 ms sans aucun appareil.

49voto

EndangeredMassa Points 9532

Ce site suggérerait qu'une latence d'environ 70 à 80ms entre la côte Est et Ouest des États-Unis est typique (par exemple, de San Francisco à New York).

Chemin transatlantique NY 78 Londres Wash 87 Francfort

Chemin transpacifique SF 147 Hong Kong

Chemin transaméricain SF 72 NY

latence réseau par paires de villes du monde

Voici mes timings (je suis à Londres, Angleterre, donc mes temps de la côte Ouest sont plus élevés que ceux de la côte Est). J'obtiens une différence de latence de 74ms, ce qui semble soutenir la valeur de ce site.

NY - 108ms de latence, 61ms de transfert, total de 169
OR - 182ms de latence, 71ms de transfert, total de 253

Ces mesures ont été prises à l'aide des outils de développement de Google Chrome.

2 votes

Super graphique ! NY à SF est actuellement 71 ms dessus, donc tu as raison -- nous ne pouvons pas espérer faire mieux que ça.

0 votes

Merci. Ça m'a beaucoup aidé. C'est une autre source pour rechercher la latence du réseau entre différents endroits du monde - dotcom-monitor.com/WebTools/network_latency.aspx

10voto

Michael Gorsuch Points 2348

Mesurez d'abord avec ICMP si possible. Les tests ICMP utilisent généralement une charge utile très faible par défaut, n'utilisent pas de poignée de main en trois étapes, et n'ont pas besoin d'interagir avec une autre application plus haut dans la pile comme le fait HTTP. Quoi qu'il en soit, il est de la plus haute importance que les résultats HTTP ne soient pas mélangés avec les résultats ICMP. Ce sont des pommes et des oranges.

En suivant la réponse de Rich Adams et en utilisant le site qu'il a recommandé, vous pouvez voir que sur le réseau de AT&T, il faut 72 ms pour que le trafic ICMP se déplace entre leurs extrémités SF et NY. C'est un chiffre acceptable, mais gardez à l'esprit qu'il s'agit d'un réseau entièrement contrôlé par AT&T. Cela ne prend pas en compte la transition vers votre réseau domestique ou de bureau.

Si vous faites un ping contre careers.stackoverflow.com depuis votre réseau source, vous devriez voir quelque chose de pas trop loin de 72 ms (peut-être +/- 20 ms). Si c'est le cas, alors vous pouvez probablement assumer que le chemin réseau entre vous deux est correct et fonctionne dans des plages normales. Sinon, ne paniquez pas et mesurez depuis quelques autres endroits. Cela pourrait être votre Fournisseur d'Accès Internet.

En supposant que cela ait fonctionné, votre prochaine étape consiste à aborder la couche d'application et à déterminer s'il y a quelque chose qui ne va pas avec la surcharge supplémentaire que vous voyez avec vos requêtes HTTP. Cela peut varier d'une application à l'autre en raison du matériel, du système d'exploitation et de la pile d'application, mais comme vous avez à peu près le même équipement sur les côtes Est et Ouest, vous pourriez avoir les utilisateurs de la côte Est accéder aux serveurs de la côte Ouest et vice versa. Si les deux sites sont correctement configurés, je m'attendrais à voir tous les chiffres être plus ou moins égaux et donc démontrer que ce que vous voyez est à peu près normal.

Si ces temps de réponse HTTP ont une grande variance, je ne serais pas surpris s'il y avait un problème de configuration sur le site qui fonctionne plus lentement.

Maintenant, une fois arrivé à ce point, vous pouvez essayer d'optimiser plus agressivement du côté de l'application afin de voir si ces chiffres peuvent être réduits. Par exemple, si vous utilisez IIS 7, tirez-vous parti de ses capacités de mise en cache, etc ? Peut-être que vous pourriez gagner quelque chose là-bas, peut-être pas. Lorsqu'il s'agit d'ajuster des éléments de bas niveau comme les fenêtres TCP, je suis très sceptique quant à l'impact que cela pourrait avoir pour quelque chose comme Stack Overflow. Mais bon - vous ne le saurez pas avant d'essayer et de mesurer.

8voto

Dan Pritts Points 3091

Plusieurs des réponses ici utilisent le ping et le traceroute pour leurs explications. Ces outils ont leur place, mais ne sont pas fiables pour la mesure des performances du réseau.

En particulier, (au moins certains) routeurs Juniper envoient le traitement des événements ICMP vers le plan de contrôle du routeur. C'est BEAUCOUP plus lent que le plan de transfert, surtout dans un routeur de backbone.

Il y a d'autres circonstances où la réponse ICMP peut être beaucoup plus lente que les performances de transfert réelles d'un routeur. Par exemple, imaginez un routeur tout logiciel (pas de matériel de transfert spécialisé) qui est à 99% de capacité CPU, mais qui continue de faire passer le trafic correctement. Voulez-vous qu'il passe beaucoup de cycles à traiter les réponses de traceroute, ou à transférer le trafic ? Donc le traitement de la réponse est une priorité super basse.

En conséquence, le ping/traceroute vous donnent des limites supérieures raisonnables - les choses vont au moins aussi vite que ça - mais ne vous disent pas vraiment à quelle vitesse le trafic réel passe.

Quoi qu'il en soit -

Voici un exemple de traceroute de l'Université du Michigan (centre des États-Unis) à Stanford (côte ouest des États-Unis). (Il passe par Washington, DC (côte est des États-Unis), qui est à 500 miles dans la "mauvaise" direction.)

% traceroute -w 2 www.stanford.edu
traceroute vers www-v6.stanford.edu (171.67.215.200), 64 sauts max, 52 octets de paquets
 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

En particulier, notez la différence de temps entre les résultats de traceroute des routeurs wash et atla (sauts 7 & 8). Le chemin réseau passe d'abord par wash puis par atla. wash met 50-100ms à répondre, atla met environ 28ms. Clairement, atla est plus loin, mais ses résultats de traceroute suggèrent qu'il est plus proche.

Voir http://www.internet2.edu/performance/ pour beaucoup d'informations sur la mesure du réseau. (déni de responsabilité, je travaillais pour internet2). Voir aussi : https://fasterdata.es.net/

Pour ajouter une pertinence spécifique à la question initiale... Comme vous pouvez le voir, j'avais un temps de ping aller-retour de 83 ms jusqu'à Stanford, donc nous savons que le réseau peut au moins aller aussi vite que ça.

Remarquez que le chemin du réseau de recherche & éducation que j'ai pris sur ce traceroute est probablement plus rapide qu'un chemin internet de commodité. Les réseaux de R&E surprovisionnent généralement leurs connexions, ce qui rend peu probable le buffering dans chaque routeur. Notez également la longue distance physique, plus longue que la côte à côte, bien que clairement représentative du trafic réel.

Michigan -> Washington, DC -> Atlanta -> Houston -> Los Angeles -> Stanford

7voto

Scott Points 198

Je constate des différences constantes, et je suis en Norvège :

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

Cela a été mesuré avec la méthode scientifiquement précise et éprouvée en utilisant la vue des ressources de Google Chrome et en actualisant simplement chaque lien à plusieurs reprises.

Tracé de la route vers serverfault

Tracé de la route vers serverfault.com [69.59.196.212]
sur un maximum de 30 sauts :

  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]

Tracé terminé.

Tracé de la route vers careers

Tracé de la route vers careers.stackoverflow.com [64.34.80.176]
sur un maximum de 30 sauts :

  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     *        *        *     Délai d'attente de la demande.

Malheureusement, cela commence maintenant à entrer dans une boucle ou quelque chose du genre et continue à donner des étoiles et des délais d'attente jusqu'à 30 sauts pour ensuite terminer.

Remarque, les tracés de route sont effectués à partir d'un hôte différent des horaires au début, j'ai dû me connecter à distance à mon serveur hébergé pour les exécuter

1 votes

Droite, il est attendu que le centre de données de la côte est serait plus convivial pour notre public européen - vous voyez environ + 200 ms pour traverser la largeur des États-Unis. Ne devrait être que ~ 80 ms selon les autres réponses cependant?

0 votes

Il semble que cela reste constant autour de 200ms, j'ai rafraîchi environ 20 à 30 fois maintenant sur les deux sites (mais pas en même temps), et le site serverfault semble tourner autour de 200ms +/- plus que l'autre. J'ai essayé un traceroute, mais il affiche des étoiles sur tout, donc peut-être que nos administrateurs IT ont bloqué quelque chose.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X