¿Qué está haciendo Google para acelerar la latencia de TCP y ampliar los límites de TCP / IP?

En realidad, hubo una publicación de blog sobre este tema hace un año en el blog oficial de Google Code

El Protocolo de Control de Transmisión (TCP), el caballo de batalla de Internet, está diseñado para entregar todo el contenido de la Web y operar en una amplia gama de tipos de red. Para entregar contenido de manera efectiva, los navegadores web suelen abrir varias docenas de conexiones TCP paralelas antes de realizar solicitudes reales. Esta estrategia supera las limitaciones TCP inherentes, pero da como resultado una alta latencia en muchas situaciones y no es escalable.

Nuestra investigación muestra que la clave para reducir la latencia es ahorrar viajes de ida y vuelta. Estamos experimentando con varias mejoras a TCP. Aquí hay un resumen de algunas de nuestras recomendaciones para acelerar el TCP:

1. Aumente la ventana de congestión inicial de TCP a 10 (IW10). La cantidad de datos enviados al comienzo de una conexión TCP es actualmente de 3 paquetes, lo que implica 3 viajes de ida y vuelta (RTT) para entregar un pequeño contenido de 15 KB. Nuestros experimentos indican que IW10 reduce la latencia de red de las transferencias web en más del 10%.

2. Reduzca el tiempo de espera inicial de 3 segundos a 1 segundo. Un RTT de 3 segundos fue apropiado hace un par de décadas, pero el Internet de hoy requiere un tiempo de espera mucho menor. Nuestra justificación de este cambio está bien documentada aquí.

3. Utilice TCP Fast Open (TFO). Para el 33% de todas las solicitudes HTTP, el navegador primero debe gastar un RTT para establecer una conexión TCP con el par remoto. La mayoría de las respuestas HTTP caben en la ventana de congestión TCP inicial de 10 paquetes, duplicando el tiempo de respuesta. TFO elimina esta sobrecarga al incluir la solicitud HTTP en el paquete TCP SYN inicial. Hemos demostrado que TFO reduce el tiempo de carga de la página en un 10% en promedio y más del 40% en muchas situaciones. Nuestro trabajo de investigación y el borrador de Internet abordan inquietudes tales como paquetes descartados y ataques de DOS al usar TFO.

4. Utilice la reducción de velocidad proporcional para TCP (PRR). Las pérdidas de paquetes indican que la red está en desorden o está congestionada. PRR, un nuevo algoritmo de recuperación de pérdidas, retransmite sin problemas para recuperar pérdidas durante la congestión de la red. El algoritmo es más rápido que el mecanismo actual al ajustar la velocidad de transmisión de acuerdo con el grado de pérdidas. PRR ahora es parte del kernel de Linux y está en proceso de convertirse en parte del estándar TCP.

Además, estamos desarrollando algoritmos para recuperar más rápido en redes móviles ruidosas, así como una entrega garantizada de 2-RTT durante el inicio. Todo nuestro trabajo en TCP es de código abierto y está disponible públicamente. Difundimos nuestras innovaciones a través del kernel de Linux, propuestas de estándares IETF y publicaciones de investigación. Nuestro objetivo es asociarnos con la industria y la academia para mejorar el TCP en toda Internet. Mire este blog y Make the Web Faster para obtener más información.

Y hace unos dos años, alguien descubrió cómo Google y Microsoft engañan en Slow-Start. ¿Deberías ?:

Conclusión:

  1. El ayuno es bueno. Estoy emocionado de ver que son posibles cargas de página inferiores a 100 ms, y es una pena no poder aprovechar al máximo las redes modernas debido a las limitaciones del protocolo (http es el protocolo limitante, por cierto).
  2. No cumplir con los estándares de una manera que privilegia sus flujos en relación con otros parece más que un poco hipócrita por parte de una compañía que está haciendo tanto escándalo por la neutralidad de la red.
  3. No estoy realmente calificado para emitir un juicio sobre si IW10 es un resultado positivo neto, pero después de leer la discusión (y considerando que Internet no se ha derrumbado), me inclino a pensar que sí.
  4. Estoy bastante seguro de que desactivar el inicio lento por completo, como parece estar haciendo Microsoft en mi seguimiento, es algo muy malo (tal vez incluso un error).

4. Utilice la reducción de velocidad proporcional para TCP (PRR). Las pérdidas de paquetes indican que la red está en desorden o está congestionada. PRR, un nuevo algoritmo de recuperación de pérdidas, retransmite sin problemas para recuperar pérdidas durante la congestión de la red. El algoritmo es más rápido que el mecanismo actual al ajustar la velocidad de transmisión de acuerdo con el grado de pérdidas. PRR ahora es parte del kernel de Linux y está en proceso de convertirse en parte del estándar TCP.