Pregunta ¿Cuánta latencia de red es "típica" para la costa este - oeste de EE. UU.?


En este momento estamos tratando de decidir si mover nuestro centro de datos de la costa oeste a la costa este.

Sin embargo, estoy viendo algunos números de latencia inquietantes desde mi ubicación en la costa oeste hasta la costa este. Este es un resultado de muestra, recuperando un pequeño archivo con el logotipo .png en Google Chrome y usando las herramientas de desarrollo para ver cuánto tarda la solicitud:

  • Costa oeste a costa este:
    215 ms de latencia, 46 ms de tiempo de transferencia, 261 ms en total
  • Costa oeste a costa oeste:
    Latencia de 114 ms, tiempo de transferencia de 41 ms, total de 155 ms.

Tiene sentido que Corvallis, OR esté geográficamente más cerca de mi ubicación en Berkeley, CA, por lo que espero que la conexión sea un poco más rápida ... pero veo un aumento en la latencia de + 100 ms cuando realizo la misma prueba en la Ciudad de Nueva York. servidor. Eso me parece excesivo. Particularmente desde el tiempo dedicado a transferir los datos reales solo aumentó un 10%, ¡pero la latencia aumentó un 100%!

Eso se siente ... mal ... para mí.

Encontré algunos enlaces aquí que fueron útiles (¡a través de Google, no menos!) ...

... pero nada autoritario.

Entonces, ¿esto es normal? No se siente normal. ¿Cuál es la latencia "típica" que debo esperar al mover paquetes de red desde la costa este <--> costa oeste de los Estados Unidos?


99
2018-04-30 11:26


origen


Cualquier medida a través de redes que no controles parece casi inútil. Demasiado a menudo, en este tipo de discusiones en la Red, parece que olvidamos que hay un componente temporal asociado con cada paquete. Si ejecutó la prueba repetidamente 24 x 7 y llegó a una conclusión, eso es una cosa. Si ejecutó la prueba dos veces, le sugiero que la ejecute un poco más. Y para aquellos que abogan por el uso del ping como una medida del rendimiento, no lo hagan. En todas las redes principales en las que he trabajado, configuramos el tráfico ICMP con la prioridad más baja. Ping significa solo una cosa, y no es;) sobre el rendimiento. - dbasnett
Desde donde vivo, Jefferson City, MO, los tiempos son similares. - dbasnett
Como nota al margen: la luz en sí toma ~ 14 ms para viajar de NY a SF en línea recta (considerando la fibra hasta el final). - Shadok
La luz en la fibra viaja con un factor de velocidad de .67 (equivalente al índice de refracción) ~ 201,000 km / s, por lo que es de al menos 20 ms. - Zac67


Respuestas:


Velocidad de la luz:
  No vas a superar la velocidad de la luz como un punto académico interesante. Este enlace funciona Stanford a Boston en ~ 40 ms el mejor tiempo posible. Cuando esta persona hizo el cálculo, decidió que Internet funciona aproximadamente a "dentro de un factor de dos de la velocidad de la luz", por lo que hay un tiempo de transferencia de aproximadamente ~ 85 ms.

Tamaño de la ventana TCP:
Si tiene problemas con la velocidad de transferencia, es posible que deba aumentar el tamaño del PCT de la ventana de recepción. También es posible que deba habilitar la escala de la ventana si se trata de una conexión de gran ancho de banda con alta latencia (denominada "Long Fat Pipe"). Entonces, si está transfiriendo un archivo grande, necesita tener una ventana de recepción lo suficientemente grande como para llenar la tubería sin tener que esperar las actualizaciones de la ventana. Entré en algunos detalles sobre cómo calcular eso en mi respuesta Tuning un elefante.

Geografía y latencia:
Un punto de falla de algunos CDN (redes de distribución de contenido) es que igualan la latencia y la geografía. Google hizo mucha investigación con su red y encontró fallas en esto, publicaron los resultados en el documento técnico. Ir más allá de la información de ruta de extremo a extremo para optimizar el rendimiento de CDN:

En primer lugar, a pesar de que la mayoría de los clientes son   Servido por un CDN geográficamente cercano   nodo, una fracción considerable de clientes   experimentar latencias varias decenas de   milisegundos más alto que otros clientes   En la misma región. Segundo, encontramos   que los retrasos en la cola a menudo se anulan   Los beneficios de un cliente interactuando.   con un servidor cercano.

BGP Peerings:
Además, si comienza a estudiar BGP (protocolo de enrutamiento de Internet principal) y cómo los ISP eligen pares, a menudo encontrará más información sobre finanzas y política, por lo que es posible que no siempre obtenga la "mejor" ruta a ciertas ubicaciones geográficas según su ISP. . Puede ver cómo su IP está conectada a otros ISPs (Sistemas Autónomos) usando un enrutador de cristal. También puedes usar un servicio especial de 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

También es divertido explorar estos como pares con una herramienta de interfaz gráfica de usuario como linkrank, te da una imagen de internet a tu alrededor.


108
2018-04-30 12:03



de acuerdo, la velocidad de la luz como la mosca del cuervo es lo mejor que puedes hacer. Una respuesta realmente excelente, por cierto, esto es exactamente lo que estaba buscando. Gracias. - Jeff Atwood
Para los curiosos, el cálculo real es: 3000 mi / c = 16.1ms - tylerl
En el vacío, un fotón puede recorrer el ecuador en aproximadamente 134 ms. El mismo fotón en vidrio tomaría alrededor de 200 ms. Una pieza de fibra de 3,000 millas tiene 24 m. De retraso sin ningún tipo de dispositivos. - dbasnett
Esto me recuerda a El caso del correo electrónico de 500 millas.. - bahamat


Este sitio sugeriría que la latencia entre 70-80 ms entre la costa este y oeste de EE. UU. es típica (de San Francisco a Nueva York, por ejemplo).

Camino transatlántico
NY 78 Londres
Lavado 87 Francfort
Camino transpacífico
SF 147 Hong Kong
Ruta trans-usa
SF 72 NY

network latency by world city pairs

Aquí están mis horarios (estoy en Londres, Inglaterra, por lo que mis tiempos en la costa oeste son más altos que en el este). Obtengo una diferencia de latencia de 74 ms, que parece apoyar el valor de ese sitio.

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

Estos se midieron utilizando las herramientas de desarrollo de Google Chrome.


41
2018-04-30 11:45



gráfico genial! NY a SF es actualmente 71 ms en eso, tienes razón, no podemos esperar hacerlo mejor que eso. - Jeff Atwood
Gracias. Me ayudó mucho. Esta es otra fuente para buscar la latencia de la red entre diferentes lugares del mundo: dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


Mida con ICMP primero si es posible. Las pruebas de ICMP suelen utilizar una carga útil muy pequeña de forma predeterminada, no usan un protocolo de enlace de tres vías y no tienen que interactuar con otra aplicación en la pila como lo hace HTTP. En cualquier caso, es de suma importancia que los resultados de HTTP no se mezclen con los resultados de ICMP. Son manzanas y naranjas.

Pasando por el respuesta de Rich Adams y usando el sitio que él recomendó, se puede ver que en la red troncal de AT&T, toma 72 ms para que el tráfico ICMP se mueva entre sus puntos finales de SF y NY. Ese es un número razonable para pasar, pero debe tener en cuenta que se trata de una red que está completamente controlada por AT&T. No tiene en cuenta la transición a la red de su hogar u oficina.

Si realiza un ping contra careers.stackoverflow.com desde su red de origen, debería ver algo que no esté muy lejos de 72 ms (tal vez +/- 20 ms). Si ese es el caso, entonces probablemente pueda suponer que la ruta de la red entre los dos está bien y se está ejecutando dentro de los rangos normales. Si no, no se asuste y mida desde algunos otros lugares. Podría ser tu ISP.

Suponiendo que haya pasado, su próximo paso es abordar la capa de aplicación y determinar si hay algún problema con la sobrecarga adicional que está viendo con sus solicitudes HTTP. Esto puede variar de una aplicación a otra debido al hardware, el sistema operativo y la pila de aplicaciones, pero como tiene equipos casi idénticos en las costas Este y Oeste, podría hacer que los usuarios de la costa este golpeen los servidores de la costa oeste y los usuarios de la costa oeste golpeen el este costa. Si ambos sitios están configurados correctamente, esperaría ver que todos los números fueran menos iguales y, por lo tanto, demostrar que lo que está viendo es bastante parejo.

Si esos tiempos de HTTP tienen una gran variación, no me sorprendería si hubiera un problema de configuración en el sitio de rendimiento más lento.

Ahora, una vez que esté en este punto, puede intentar realizar una optimización más agresiva en el lado de la aplicación para ver si esos números pueden reducirse en absoluto. Por ejemplo, si está utilizando IIS 7, ¿está aprovechando sus capacidades de almacenamiento en caché, etc.? Tal vez podrías ganar algo allí, tal vez no. Cuando se trata de ajustar elementos de bajo nivel como las ventanas TCP, soy muy escéptico de que tendría un gran impacto para algo como el desbordamiento de pila. Pero oye, no lo sabrás hasta que lo pruebes y midas.


10
2018-04-30 17:34





Varias de las respuestas aquí están usando ping y traceroute para sus explicaciones. Estas herramientas tienen su lugar, pero no son confiables para la medición del rendimiento de la red.

En particular, (al menos algunos) los enrutadores Juniper envían el procesamiento de eventos ICMP al plano de control del enrutador. Esto es MUCHO más lento que el plano de reenvío, especialmente en un enrutador backbone.

Existen otras circunstancias en las que la respuesta ICMP puede ser mucho más lenta que el rendimiento real de reenvío de un enrutador. Por ejemplo, imagine un enrutador de software completo (sin hardware de reenvío especializado) que se encuentre al 99% de la capacidad de la CPU, pero que aún esté moviendo la multa de tráfico. ¿Desea que se pasen muchos ciclos procesando respuestas de tracerout o reenviando tráfico? Entonces, procesar la respuesta es una súper baja prioridad.

Como resultado, ping / traceroute le da razonable limites superiores - las cosas van al menos tan rápido - pero realmente no te dicen qué tan rápido va el tráfico real.

En cualquier evento -

Aquí hay un ejemplo de ruta de la Universidad de Michigan (centro de los Estados Unidos) a Stanford (costa oeste de los Estados Unidos). (Sucede que pasa por Washington, DC (costa este de EE. UU.), Que está a 500 millas en la dirección "incorrecta".)

% 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

En particular, tenga en cuenta la diferencia de tiempo entre los resultados de traceroute del lavar enrutador y el atla enrutador (saltos 7 y 8). la ruta de la red va primero a lavar y luego a atla. el lavado tarda 50-100ms en responder, atla toma aproximadamente 28ms. Claramente, atla está más lejos, pero los resultados de su búsqueda sugieren que está más cerca.

Ver http://www.internet2.edu/performance/ para un montón de información sobre la medición de la red. (Descargo de responsabilidad, solía trabajar para internet2). Ver también: https://fasterdata.es.net/

Para agregar alguna relevancia específica a la pregunta original ... Como puede ver, tuve un tiempo de ping de ida y vuelta de 83 ms en Stanford, por lo que sabemos que la red puede ir al menos tan rápido.

Tenga en cuenta que la ruta de la red de investigación y educación que tomé en este traceroute es probable que sea más rápida que la ruta de Internet de productos básicos. Las redes R&E generalmente proveen en exceso sus conexiones, lo que hace que el almacenamiento en búfer en cada enrutador sea poco probable. Además, tenga en cuenta el largo camino físico, más largo que el de costa a costa, aunque claramente representativo del tráfico real.

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


7
2017-08-15 15:46





Veo diferencias constantes, y estoy sentado en Noruega:

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

Esto se midió con el método científico, preciso y comprobado, de utilizar la vista de recursos de Google Chrome y simplemente actualizar repetidamente cada enlace.

Traceroute a serverfault

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 a las carreras

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.

Desafortunadamente, ahora comienza a entrar en un bucle o lo que sea y continúa dando estrellas y tiempo de espera hasta 30 saltos y luego termina.

Tenga en cuenta que los traceroutes son de un host diferente al de los tiempos iniciales, tuve que hacer RDP a mi servidor alojado para ejecutarlos.


6
2018-04-30 11:43



a la derecha, se espera que el centro de datos de la costa este sea más amigable para nuestras audiencias europeas; está viendo aproximadamente 200 ms de tiempo para atravesar el ancho de los EE. UU. ¿Sin embargo, solo debería ser ~ 80ms por las otras respuestas? - Jeff Atwood
parece que es consistente a unos 200 ms, he actualizado la actualización unas 20 a 30 veces en ambos (aunque no al mismo tiempo), y el sitio serverfault parece que oscila alrededor de 200 ms +/- más que el otro . Intenté un traceroute, pero aparece estrellas en todo, así que quizás nuestros administradores de TI hayan bloqueado algo. - Lasse Vågsæther Karlsen


Veo aprox. 80-90ms de latencia en enlaces bien manejados y bien medidos entre las costas este y oeste.

Sería interesante ver dónde está ganando latencia: pruebe una herramienta como traceroute (lft) de capa cuatro. Hay muchas posibilidades de que se gane en la "última milla" (es decir, en su proveedor de banda ancha local).

Es de esperar que el tiempo de transferencia solo se haya visto ligeramente afectado: la pérdida de paquetes y la inestabilidad son medidas más útiles que se deben tener en cuenta al investigar las diferencias de tiempo de transferencia entre dos ubicaciones.


2
2018-04-30 11:42





Solo por diversión, cuando jugué el juego en línea Lineage 2 NA de Europa:

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

La diferencia parece admitir que hasta 100 ms está dentro de lo razonable, teniendo en cuenta la naturaleza impredecible de Internet.

Al utilizar la aclamada prueba de actualización de Chrome, obtengo un tiempo de carga de documentos que difiere en aproximadamente 130 ms.


2
2018-04-30 12:52