«Osificación» de internet. El protocolo QUIC – 1/3

Este post es el detalle de la presentación que hice en el Esnog31 en Madrid. Si quieres acceder a la misma tienes dos opciones:


Quién a estas alturas del siglo XXI no haya oído la palabra “TCP/IP”, aunque no la entienda, es probable que sea un eremita residente en una cabaña en el Mato Grosso. El protocolo TCP tomó forma de RFC del IETF en septiembre de 1981.

Nada menos que 43 años contemplan a TCP, el que todavía hoy sigue siendo el protocolo de transporte dominante en una internet que en nada se parece a la de 1981.

Seguro que para todos nosotros es conocido el “reloj de arena” de internet:

En él destaca cómo se han incorporado nuevas tecnologías que han habilitado nuevas capas físicas portadoras o cómo las nuevas tecnologías en capa de enlace han evolucionado en consonancia con éstas siendo hoy ethernet la tecnología dominante en redes fijas y PPP en redes móviles. De igual modo múltiples protocolos en capa de aplicación han surgido y desaparecido y todo ello siempre sobre un protocolo IP inmutable. Sin embargo, ¿qué ha pasado con los protocolos de transporte? Tal vez no seamos conscientes, pero las iniciativas han sido múltiples:

Por destacar un par de estos intentos de evolución:

  • TCP Fast Open buscaba reducir los “round-trips” para el establecimiento de sesión TCP en las sesiones sucesivas entre cliente y servidor a partir de la compartición de una “cookie” criptográfica.
  • MultiPath TCP o MPTCP buscaba favorecer la migración de conexión, por ejemplo, de una red fija a la red móvil sin necesidad de restablecimiento de sesión TCP e incluso el uso de ambas conexiones de manera simultánea entre cliente y servidor.

Sin embargo, el fracaso de todas estas iniciativas ha sido absoluto. La razón fundamental es lo que podemos llamar la “osificación de internet”. ¿Qué es esto? Los protocolos de transporte están implementados no sólo en el “kernel“ de los sistemas operativos de los clientes y servidores de internet (Windows, MacOS, Linux, Android, IOS y demás sistemas operativos de dispositivos de toda naturaleza como los de IoT), sino en los de un número infinito de “middleboxes” que leen y en ocasiones manipulan estos protocolos de transporte:

  • Firewalls e IDS/IPS que aplican restricciones basadas en campos de las cabeceras de estos protocolos. Equipos a veces ubicados en empresas y particulares en internet y otras en forma de firewalls de país que evita el libre acceso de sus ciudadanos a internet
  • Dispositivos de CGNAT que realizan traducción de direccionamiento privado a público y viceversa
  • Aceleradores y compresores de tráfico TCP típicamente usados en conexiones de elevado coste y alta latencia como, por ejemplo, las apoyadas en satélites geoestacionarios o rutas submarinas de larga distancia
  • Balanceadores de carga que reparten sesiones entre múltiples servidores finales de acuerdo a criterios de capa 3 y capa 4
  • Routers y proxies de toda naturaleza en que se aplican reglas de “capa 4” (¿quién no ha manipulado alguna vez el “maximum segment size” de TCP para controlar la MTU de las sesiones y evitar fragmentación?)

Podemos definir los “middleboxes” tomando como referencia la RFC3234 “Middleboxes: Taxonomy and Issues” como: “defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host

Estas “cajas” intermedias restan flexibilidad a internet, lo “osifican”, al hacer asunciones erróneas acerca de campos dentro de los diferentes protocolos de modo que cualquier cambio en ellos puede suponer tráfico tirado (sí, iba a decir «dropado»); o, al depender de dichos campos para poder llevar a cabo su labor, una modificación en los mismos les hace perder eficiencia.

¿Por qué no hacer un nuevo TCP desde cero para mejorar sus prestaciones?  Lo primero sería pedir en el IANA un nuevo número de protocolo a introducir en la cabecera IP. El 146 es el primero sin usar (TCP es el 6, UDP el 17, …)…

Este planteamiento roza el imposible. Pensemos en todos los firewalls de internet procesando un nuevo protocolo (lo primero sería aplicarle una regla de “drop”) o múltiples filtros de capa 4 en routers de internet que no tienen contemplada la opción del “protocolo 146”.

Cualquier evolución de TCP y UDP, bien parcial, bien en forma de nuevo protocolo alternativo, es absolutamente imposible extenderla fuera de un entorno controlado, ya que la actualización software de todos los hosts y servidores y, sobre todo la de los “middleboxes” junto con sus configuraciones podemos considerarla próxima a la ciencia ficción.

Considerando esta situación, ¿cuál es el mix de tráfico que tenemos hoy en internet?

Internet en 2024

Si observamos los datos de Cloudflare Radar, entre un 65% y un 75% del tráfico de internet es el llamado tráfico web o basado en HTTP/HTTPS.

Si vamos un poco más allá en la información de Cloudflare Radar, vemos cómo este tráfico ya está masivamente securizado con una capa TLS sobre HTTP:

Y, si observamos las diferentes versiones de HTTP, vemos aún el dominio de HTTP/2 y cómo las versiones HTTP/1.0 y HTTP/1.1 son cosa del pasado. Además, HTTP/3 tiene un peso creciente próximo al 28% del tráfico HTTP.

HTTP/3 se fundamenta en QUIC y así a día de hoy estos navegadores utilizan QUIC por defecto: Google Chrome, Mozilla Firefox, Microsoft Edge, Opera, Apple Safari, Android WebView, Brave, Vivaldi, … Si el intento de conexión por medio de QUIC no tiene éxito, el navegador hace un “fallback” a HTTP/2 sobre TCP.

¿En qué se diferencian estas versiones de HTTP y cómo han evolucionado en el tiempo?

Google y la mejora de la experiencia de usuario

Es innegable la aportación de Google a la evolución de internet desde un punto de vista técnico, sin querer entrar en ninguna teoría de la conspiración sobre los motivos de este interés.

Veamos la estrategia seguida por Google en su objetivo de minimizar la latencia requerida para el acceso a contenidos por los usuarios, visto desde el punto de vista del reloj de arena de internet:

Google intentó atacar todas las capas:

  • La capa de aplicación por medio de su navegador Google Chrome y los servidores de servicios tan populares como YouTube
  • Las capas inferiores por medio de despliegue de infraestructura de fibra propia y acercando los contenidos por medio de la Google CDN
  • Como veremos más adelante, promoviendo el desarrollo de HTTP con protocolos como SPDY, precursor de HTTP/2 y, por supuesto, HTTP/3

Pero, ¿cómo mejorar los protocolos de transporte? Como hemos visto, la “osificación” de internet lo impedía. ¿Cómo lo resolvieron?

De HTTP/1.x a HTTP/3

HTTP/1.0 fue finalizado en 1996, en los inicios de la expansión de internet y se caracterizaba porque cada petición al mismo servidor requería de una sesión TCP diferenciada, luego un nuevo “handshaking”.

HTTP/1.1 estableció ya en 1999 las conexiones persistentes que reutilizaban la sesión TCP entre cliente y servidor para las diferentes peticiones de objetos. Esto reducía la latencia notablemente a causa de la eliminación de múltiples handshakings con páginas web con un número creciente de objetos incrustados en las mismas. Sin embargo, no era posible resolver el “Head of Line Blocking” debido a TCP.

Aunque HTTP/1.1 habilitó el “pipelining”, donde se podían enviar múltiples solicitudes sin esperar cada respuesta, las respuestas en capa de aplicación aún tenían que ser procesadas y enviadas en el orden en que se recibieron las solicitudes. Este requisito de orden causaba el llamado “head of line blocking”: si la primera solicitud tardaba mucho tiempo, todas las solicitudes posteriores tenían que esperar.

HTTP/2 (2015) surgió como la evolución en el IETF del protocolo SPDY de Google, como antes hemos comentado, e introdujo los flujos HTTP – una abstracción que permite multiplexar diferentes intercambios HTTP en la misma conexión TCP. Los flujos no necesitaban ser enviados en orden. Esto eliminaba el “head of line blocking” en la capa de aplicación. Sin embargo, éste todavía existía en la capa de transporte TCP.

Finalmente, el borrador de HTTP/3 se publicó en 2020 y se convirtió en la RFC9114 del IETF en 2022. Utiliza QUIC en lugar de TCP como el protocolo de transporte, eliminando el “head of line blocking” en la capa de transporte de HTTP/2 al permitir el transporte de “flujos” o “streams” independientes sobre la misma conexión QUIC.

Veamos el detalle de qué es QUIC.

QUIC – ¿el fin de la ”osificación”?

El “head-of-line blocking” en TCP de HTTP/2 llevó a Google a continuar su particular cruzada por minimizar la latencia HTTP y así comenzar en 2012 su iniciativa gQUIC o Google QUIC para HTTP, que desplegó en Chrome y en sus servicios propios en 2014. En el año 2017 llegó a suponer un 7% del tráfico total de internet.

En 2016 Google compartió su gQUIC con el IETF en el QUIC Working Group y esto es lo que ha dado pie al protocolo que hoy conocemos como QUIC, evolucionado respecto del que fue el gQUIC original. Desde 2016 este grupo ha desarrollado y desarrolla las principales especificaciones asociadas a QUIC. QUIC nació asociado al transporte de HTTP, pero es realmente un protocolo de transporte agnóstico del protocolo/aplicación de nivel superior al que da servicio. Vamos a analizarlo asociado a HTTP ya que la optimización de este, pero después veremos su aplicación con otros protocolos.

Las especificaciones “core” de QUIC se publicaron en 2021 y son:

QUIC se especificó teniendo en cuenta muchos de los objetivos que las evoluciones frustradas de TCP tuvieron:

  • Protocolo evolucionable sin dependencia de la “osificación” de internet
  • Baja latencia en el establecimiento de conexión, minimizando los “round-trips” necesarios
  • Terminar con el “head-of-line blocking” de HTTP/2 debido a TCP
  • Mejorar los mecanismos de control de congestión y de retransmisión de paquetes perdidos
  • Simplificar la migración de conexión (i.e. paso dinámico de una conexión fija a una conexión móvil sin necesidad de restablecer conexión con el servidor)

¿Cómo se desarrolló QUIC para conseguir estos objetivos?

Esto lo veremos en la segunda parte de este post… ;-)

¡¡¡No te pierdas nuevas entradas del blog!!!

¡No hago spam! Sólo recibirás un correo cuando haya una nueva entrada en el blog.


Publicado

en

por

Etiquetas:

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *