¿Cuánto tiempo (en milisegundos) le tomaría a un paquete de datos viajar por todo el mundo en Internet desde Nueva York?

Esto es difícil de fabricar, ya que el enrutamiento normal no lo permitiría. Sería un bucle de reenvío, y Border Gateway Protocol lo evita. Sin embargo, desde una perspectiva teórica, podemos resolver esto.

Comencemos con algunos datos: Herramienta de prueba de latencia de red de red troncal de Internet

Trabajaremos sumando algunas piernas juntas para obtener un circuito completo:

NY, EE. UU. -> Frankfurt, Alemania: 88ms

Frankfurt -> Tel Aviv: 60ms

Tel Aviv -> Mumbai: 192 ms

Mumbai -> Tokio: 135 ms

Tokio -> WA, EE. UU .: 117 ms

WA -> NY: 60ms

Total: 652 ms

Esto está bastante de acuerdo, ya que uno de mis puntos de referencia de fondo es San José -> Estocolmo: 200 ms, y eso es aproximadamente un tercio del camino.

Tenga en cuenta que los lugares que he elegido pueden no ser óptimos y también pueden incluir algunas rutas hacia atrás. Pero esto debería darte un estadio decente.

Lo siento, Julien, con tantas variables es imposible descubrirlo. Ejemplo perfecto: el viaje de ida y vuelta de un ping proveniente de un viejo frame relay sobre la interfaz ATM (FRATM) en uno de mis enrutadores hablando con un enrutador a 450 millas de distancia me da una respuesta de 48 ms. En ese mismo enrutador, obtener un ping de una red MPLS que habla con ese mismo enrutador a 450 millas de distancia me da una respuesta de 22Mseg. Ninguno de mis circuitos retrocede fuera del estado, por lo que los caminos son algo idénticos. El búfer podría ser el culpable, pero estoy relativamente seguro de que los búferes de mis enrutadores no son los culpables.

Además, un protocolo de enrutamiento popular obliga a los paquetes a utilizar una ruta abierta más corta primero (OSPF). Por lo tanto, tendría que configurar manualmente las rutas para que el paquete viaje a fin de enviar el paquete a todo el mundo. Al hacerlo, si alguna parte de ese camino está congestionada, su paquete pobre sufrirá las consecuencias.

Otra técnica que los administradores de red usarían para obstaculizar su paquete es a través de una técnica llamada Weighted Fair Queuing. WFQ / FQ básicamente prioriza la entrega de paquetes. Los administradores de la red podrían poner fácilmente el kibosh en ese paquete pobre. Heck, incluso las técnicas de enrutamiento de origen podrían arrojar su paquete a una interfaz o circuito atascado de registro.

Redes definidas por software es una cosa si el futuro cercano. Con él, los administradores de red crean perfiles que se superponen en una red. Por lo tanto, los administradores de la red pueden cambiar rápidamente sus rutas y usted no lo sabría.

Un montón de otras variables también …

Lo siento. No vale la pena que las células cerebrales explotadas intenten averiguarlo.

Puede tener una idea utilizando la herramienta gratuita trace route. Está incrustado en el símbolo del sistema de Windows como “tracert”. Elija un sitio web del otro lado del mundo, probablemente Japón o China, y emita “tracert website.jp”.

Le mostrará la distancia desde todos los saltos intermedios hasta el destino, y el RTT (tiempo de ida y vuelta) desde su computadora al destino y de regreso a su computadora.

Ping también haría el truco, pero deberías asegurarte de que el sitio no esté alojado en otro lugar, lo que puedes hacer fácilmente con la ruta de rastreo porque conocerás cada paso en el camino.

En mi teléfono no muestra el RTT pero sí en Windows, Linux o Mac.

Si echa un vistazo al Mapa de latencia global aquí, puede jugar con diferentes latencias en todo el mundo.

Border Gateway Protocol fluctuará las latencias si hay alguna congestión en el camino que podría retrasar el viaje.