¿Todavía es posible disminuir aún más la latencia mundial de Internet?

Einstein realmente nos jodió con toda esa cosa de la “velocidad de la luz”, ¿eh? Maldito sea.

Afortunadamente, tenemos una pequeña esperanza (aproximadamente un 50% más rápido). No porque podamos enviar cosas más rápido que la velocidad de la luz, sino por un hecho, me sorprende que más personas en este hilo no hayan mencionado:

La velocidad de la luz en fibra no es “c”.

La velocidad de la luz en la fibra es ~ (2/3) c, es decir, aproximadamente 200,000 km / seg. [*] Si podemos obtener fibra que permita que los fotones se acerquen a c, tendremos una latencia más baja:
Los investigadores crean una red de fibra que opera a una velocidad de luz del 99.7%, rompe los registros de velocidad y latencia | ExtremeTech

Por supuesto, todo el resto del material (hinchazón del búfer, CDN, enrutamiento de fibra más directo) también ayudará.

Ah, no estoy de acuerdo con Arpit Singh en que optimizar los protocolos ayudará. La latencia no es un artefacto de los protocolos. Podríamos obtener más rendimiento con mejores protocolos (aunque eso no es necesariamente cierto), pero la latencia no cambiará.

[*] Dato curioso: esto hace que las matemáticas sobre la latencia sean triviales. Específicamente, el RTT en una ruta de fibra de 100 km (200 km de ida y vuelta) es de 1 milisegundo, una milésima de segundo, que es el tiempo que lleva recorrer 200,000 km. Cuando busque la latencia, encuentre el camino entre A y B en kilómetros, divídalo entre 100 y tendrá un límite inferior en la latencia en milisegundos.

EDITAR: hizo el “[*] Dato curioso” un poco más claro.

EDIT2: Error corregido en “[*] Dato curioso”.

La latencia de Internet se ve afectada por la velocidad de la luz, sin embargo, la historia no termina allí. La latencia puede acumularse en las tuberías de red debido a una serie de otras razones. Congestión
construido en enrutadores de red es uno de esos ejemplos.

Otra razón es la forma en que el tráfico se enruta a través de Internet. Internet usa BGP para el enrutamiento entre dominios entre organizaciones del Sistema Autónomo (AS). Fue diseñado en los primeros días de Internet con un enfoque en el alcance y la estabilidad de la red, sin embargo, no es muy inteligente cuando se trata de enrutar el tráfico para optimizar
métricas relacionadas con el rendimiento como latencia y congestión. BGP hace enrutamiento
decisiones basadas en una serie de métricas que incluyen accesibilidad y AS_PATH
atributo. Esto se traduce básicamente en elegir rutas de red que son
accesible y tiene el menor número de saltos AS. El camino más corto a menudo
pasa a estar más congestionado y por lo tanto conduce a una mayor latencia.

Estoy de acuerdo con Arpit Singh en que la latencia de Internet se puede disminuir al optimizar los protocolos de enrutamiento de Internet. De hecho, Datapath.io, que es una reimplementación del BGP, ha logrado hacer exactamente eso. Datapath.io sondea más de 600,000 prefijos de red para datos de prueba relacionados con el rendimiento. Estos datos se utilizan para encontrar rutas alternativas para el tráfico de red con la menor latencia. Red
los ingenieros pueden optar por anular la mejor selección de ruta de la frontera
Protocolo de puerta de enlace. Eche un vistazo a la imagen a continuación para obtener una captura de pantalla de la plataforma en acción. Tenga en cuenta que la latencia de la red se ha reducido en casi un 60% en comparación con otros proveedores.

Eche un vistazo a esta publicación de blog de nuestro CEO DATAPATH.IO Sebastian Spies para obtener más información Cómo ejecutamos BGP sobre OpenFlow.

Sí, simplemente optimizando los protocolos.
Los protocolos de red se escribieron hace unos 20 años cuando el ancho de banda era muy bajo. Por lo tanto, tienen una suposición inherente de bajo ancho de banda.
Por ejemplo, podemos eliminar el inicio lento de tcp, que aumentará efectivamente la velocidad de datos sobre el mismo ancho de banda. Google lo ha hecho en sus servidores, por eso la página de inicio de Google se carga más rápido con resultados

Simplemente muchas otras formas, se puede hacer

EDIT1: parece que muchos expertos no parecen estar de acuerdo conmigo. Están hablando de latencia en términos de punto a punto, es decir, cuánto tiempo tarda un paquete en llegar desde el punto de salida de un sistema al punto de entrada de un sistema. Estoy hablando de latencia desde la perspectiva del usuario. Simplemente tomo esta pregunta, ¿podemos disminuir el tiempo de carga de la página web en mi sistema con el mismo ancho de banda? Me refiero a la experiencia del cliente, que es de suma importancia. Creo que, al optimizar los protocolos y su implementación, podemos reducir la latencia de manera efectiva. Observé que el tiempo que pasan los paquetes en pilas de red en hosts finales y dispositivos intermedios es mucho más que el tiempo que tardan los paquetes en viajar por cable. Al optimizar la búsqueda de rutas eliminando las comprobaciones innecesarias y el reenvío de hardware, la latencia se puede reducir en gran medida. Para respaldar mi reclamo, después de la introducción de Cisco CEF en los enrutadores Cisco, la latencia experimentada se ha reducido en gran medida en comparación con cualquier enrutador de la compañía

EDIT2: Stan Hanks Tony Li
Por favor vea la página en google.com
“Un argumento para aumentar la ventana de congestión inicial de TCP” Es un artículo famoso.
Después de trabajar en TCP durante años, creo firmemente que si Windows, Linux y el SO del enrutador (Cisco IOS, Juno OS) trabajan en cooperación y optimizan sus pilas, que incluyen el proceso de búsqueda de conexiones, la latencia de gestión de colas puede reducirse considerablemente extensión dentro del mismo ancho de banda

Debe tener una definición más nítida de “latencia”.

En particular, ¿de qué a qué? ¿Y cuál es el “a qué” estás accediendo?

La mayoría de las personas se quejan de la latencia cuando es lento llegar a lo que quieran acceder, sin darse cuenta de lo que eso significa.

Para las cosas de la distancia física pura, como Europa al sudeste asiático, no hay nada que pueda hacer al respecto. Puede que no te guste, pero

Como señala Tony Li, no siempre se trata de la longitud del camino físico. La ruina de la existencia de un ingeniero de redes senior es la congestión y el bloqueo del búfer: las dos cosas que toman lo que ópticamente parece ser una ruta rápida y lo convierten en un infierno de retraso de paquetes.

También hay otro elemento: las redes de entrega de contenido. En los años 90, descubrimos que hay una TONELADA de contenido que no se genera sobre la marcha, y que si te acercas tanto, mucho más al usuario final, la aparición de una latencia más baja se da cuenta, porque, bueno, ambos han distribuido la carga en muchos servidores, y porque literalmente han acercado el contenido al usuario.

Puede utilizar de manera muy efectiva la tecnología CDN para mover el contenido de la Cuenca del Pacífico a un nodo en la UE, lo que lo convierte en una experiencia mucho, mucho mejor. A menos que esté hablando de interacción uno a uno en tiempo real, en cuyo caso, oye, sigue siendo mejor que por satélite.

Sí, pero…

La latencia es el resultado de la distancia que debe recorrer el tráfico por la velocidad de la luz (en fibra). Obviamente, no estamos cambiando la distancia entre Europa y Asia en el corto plazo. Tampoco es probable que cambiemos la velocidad de la luz.

Lo que podemos hacer:

  • Encuentre lugares en la red donde haya congestión y agregue más ancho de banda. Esto es costoso. ¿Quién paga por esto?
  • Disminuciones menores en la distancia. Si podemos encontrar formas de ejecutar la fibra nueva más directamente, eso disminuirá la distancia. El camino de Europa al sur de Asia puede hacer un viaje alrededor de África. Eso agregaría muchas millas. Más fibra a lo largo del Suez sería útil.