121 votes

Combien de latence réseau est "typique" pour la côte est - 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 perturbants de 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 de logo .png dans Google Chrome et en utilisant les outils de développement pour voir combien de temps prend la requête :

  • 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 constate une augmentation de la latence de +100ms lorsque je fais le même test vers le serveur à NYC. Cela me semble.. excessif. Particulièrement puisque le temps passé à transférer les données réelles n'a augmenté que de 10%, pourtant la latence a augmenté de 100%!

Cela me semble... incorrect..

J'ai trouvé quelques liens ici qui ont été utiles (via 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 attendre en déplaçant des paquets réseau de la côte est <--> la côte ouest des USA?

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, il semble que 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 avez tiré une conclusion, c'est une chose. Si vous avez fait le test deux fois, je suggère d'en faire plus. Et pour ceux qui préconisent l'utilisation du ping comme mesure de performance, ne le faites pas. Sur tous les réseaux importants sur lesquels j'ai travaillé, nous avons défini le trafic ICMP comme étant de priorité la plus basse. Ping ne signifie qu'une seule chose, et ce n'est pas ;) concernant la performance.

0 votes

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

4 votes

En tant que note supplémentaire: la lumière elle-même prend environ 14ms pour se rendre de New York à San Francisco en ligne droite (en considérant que c'est de la fibre tout le chemin).

124voto

Kyle Brandt Points 81077

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

Taille de fenêtre TCP :
Si vous rencontrez des problèmes de vitesse de transfert, vous devrez peut-être augmenter la taille de la fenêtre TCP de réception. Vous devrez peut-être également activer le redimensionnement de la fenêtre si c'est une connexion à large bande avec une latence élevée (appelée un "long tuyau gras"). 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 fenêtre. J'ai expliqué en détail comment calculer cela dans ma réponse sur l'ajustage d'un Éléphant.

Géographie et latence :
Un point d'échec de certains CDN (réseaux de distribution de contenu) est qu'ils assimilent la latence et la géographie. Google a réalisé de nombreuses recherches avec leur réseau et a trouvé des failles à ce sujet, ils ont publié les résultats dans le document blanc Au-delà de l'information de chemin de bout en bout pour optimiser les performances du CDN:

Tout d'abord, bien que la plupart des clients soient desservis par un nœud CDN géographiquement proche, une fraction considérable de clients connaissent des latences plusieurs dizaines de millisecondes plus élevées que d'autres clients de 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.

Interconnexions BGP :
Aussi, si vous commencez à étudier le BGP (protocole de routage Internet de base) et comment les FAI choisissent leurs interconnexions, vous constaterez que c'est souvent plus une question financière et politique, donc vous pourriez ne pas toujours obtenir la meilleure route vers certaines localisations géographiques en fonction de votre FAI. Vous pouvez consulter comment votre IP est connectée à d'autres FAI (systèmes autonomes) en utilisant un routeur de consultation. Vous pouvez également utiliser un service whois spécial:

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

C'est également amusant d'explorer ces interconnexions avec un outil gui comme linkrank, cela vous donne une idée de l'internet autour de vous.

1 votes

D'accord, la vitesse de la lumière en ligne droite est la meilleure chose que vous puissiez faire. Vraiment excellente réponse au fait, c'est exactement ce que je cherchais. Merci.

4 votes

Pour les curieux, les mathématiques réelles 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 24 ms de retard sans aucun appareil.

49voto

EndangeredMassa Points 9532

Ce site suggérerait qu'une latence d'environ 70 à 80ms entre la côte Est et la côte 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 trans-américain SF 72 NY

latence réseau par paires de villes du monde

Voici mes mesures (je suis à Londres, en Angleterre, donc mes temps pour la côte Ouest sont plus élevés que pour la côte Est). Je constate une différence de latence de 74ms, ce qui semble confirmer la valeur de ce site.

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

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

2 votes

Super graphique ! De NY à SF est actuellement 71 ms dessus, donc vous avez raison - nous ne pouvons pas nous attendre à mieux que ça.

0 votes

Merci. Cela m'a beaucoup aidé. Voici 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 l'ICMP si possible. Les tests ICMP utilisent généralement une charge utile très petite par défaut, n'utilisent pas de poignée de main en trois étapes et n'ont pas à interagir avec une autre application en amont comme le fait HTTP. Dans tous les cas, 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 vous basant sur la réponse de Rich Adams et en utilisant le site qu'il a recommandé, vous pouvez voir que sur le backbone d'AT&T, il faut 72 ms pour que le trafic ICMP se déplace entre leurs points d'extrémité SF et NY. C'est un chiffre assez représentatif, mais vous devez garder à l'esprit que c'est sur 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 qui n'est pas trop éloigné de 72 ms (peut-être +/- 20 ms). Si c'est le cas, vous pouvez probablement supposer 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 FAI.

En supposant que cela soit passé, votre prochaine étape est de vous attaquer à la couche applicative et de déterminer s'il y a quelque chose qui cloche avec la surcharge supplémentaire que vous constatez avec vos requêtes HTTP. Cela peut varier d'une app à l'autre en raison du matériel, du système d'exploitation et de la pile d'applications, mais comme vous avez à peu près le même équipement sur les côtes Est et Ouest, vous pourriez avoir des utilisateurs de la côte Est sur les serveurs de la côte Ouest et des utilisateurs de la côte Ouest sur la côte Est. Si les deux sites sont configurés correctement, je m'attendrais à voir tous les chiffres plus ou moins égaux et donc à démontrer que ce que vous voyez est à peu près dans la moyenne.

Si ces temps HTTP ont une large variance, il ne serait pas surprenant qu'il y ait un problème de configuration sur le site qui fonctionne plus lentement.

Maintenant, une fois arrivé à ce point, vous pouvez essayer d'optimiser un peu 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, profitez-vous de ses capacités de mise en cache, etc.? Peut-être pourriez-vous y gagner quelque chose, peut-être pas. Quand il s'agit de ajuster des éléments de bas niveau tels que les fenêtres TCP, je suis très sceptique que cela aurait un impact significatif pour quelque chose comme Stack Overflow. Mais bon, vous ne le saurez pas tant que vous n'avez pas essayé et mesuré.

8voto

Dan Pritts Points 3091

Plusieurs des réponses ici utilisent ping et traceroute pour leurs explications. Ces outils ont leur place, mais ils 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. Cela 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 réelles de transfert d'un routeur. Par exemple, imaginez un routeur tout logiciel (pas de matériel de transfert spécialisé) qui est à 99% de sa capacité CPU, mais qui continue de déplacer le trafic correctement. Voulez-vous qu'il passe beaucoup de cycles à traiter les réponses traceroute, ou à transférer du trafic? Donc, le traitement de la réponse est une très basse priorité.

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

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 du routeur wash et du routeur atla (sauts 7 & 8). Le chemin du 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.

Consultez http://www.internet2.edu/performance/ pour beaucoup d'informations sur la mesure des performances du réseau. (désistement, je travaillais pour Internet2). Voir aussi: https://fasterdata.es.net/

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

Remarquez que le chemin du réseau de recherche et d'éducation que j'ai pris sur ce traceroute est susceptible d'être plus rapide qu'un chemin internet grand public. Les réseaux R&E surdimensionnent généralement leurs connexions, ce qui rend peu probable la mise en mémoire tampon dans chaque routeur. Notez également le long chemin physique, plus long que d'une côte à l'autre, bien que clairement représentatif 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       carrières
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

Cela a été mesuré avec la méthode scientifiquement précise et éprouvée d'utiliser la vue des ressources de Google Chrome et de rafraîchir chaque lien de manière répétée.

Tracé de routage 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]

Traçage terminé.

Tracé de routage vers carrières

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     *        *        *     Demande temporisée.

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, puis se termine.

Remarque, les tracés de routage proviennent d'un hôte différent des délais au début, j'ai dû me connecter à distance sur mon serveur hébergé pour les exécuter

1 votes

Droite, on s'attend à ce que le centre de données de la côte est soit plus convivial pour notre public européen -- vous constatez environ +200 ms de temps nécessaire pour traverser la largeur des États-Unis. Cependant, cela ne devrait être que ~80 ms selon les autres réponses?

0 votes

Il semble que la vitesse se maintient autour de 200ms, j'ai rafraîchi la page environ 20 à 30 fois maintenant sur les deux sites (mais pas en même temps), et le site serverfault semble osciller autour de 200ms +/- plus que l'autre. J'ai essayé un traceroute, mais il affiche des étoiles partout, 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