Han pasado tres años y medio desde la adopción del estándar HTTP / 2: la especificación RFC 7540 se publicó en mayo de 2015, pero aún no se usa en todas partes. El protocolo se ha implementado en todos los navegadores desde finales de 2015 , y después de tres años, solo el 31,2% de los 10 millones de sitios de Internet más populares son compatibles con HTTP / 2. De los sitios más populares, Google, Youtube, Wikipedia, Twitter, Vk.com y otros han cambiado a él.

Sin embargo, el progreso no se detiene, y el trabajo ya está en marcha en la próxima versión de HTTP / 3. Como se supo ahora, los desarrolladores de dos opciones alternativas han logrado la compatibilidad, y el protocolo HTTP sobre QUIC ahora cambia su nombre y se llama oficialmente HTTP / 3 . En consecuencia, en una versión futura de HTTP, el transporte TCP será reemplazado por QUIC.

Confusión con diferentes opciones de QUIC

QUIC es un reemplazo de TCP que funciona sobre UDP. Inicialmente, esta tecnología fue creada por ingenieros de Google, como el protocolo SPDY anterior, que se convirtió en la base de HTTP / 2. Al principio, QUIC se llamaba "HTTP / 2-encrypted-over-UDP".

El desarrollo de QUIC se transfirió luego al IETF para su estandarización. Aquí se dividió en dos partes: transporte y HTTP. La idea es que el protocolo de transporte también se puede utilizar para transferir otros datos, y no solo exclusivamente para HTTP o protocolos similares a HTTP. Sin embargo, el nombre sigue siendo el mismo: QUIC. El protocolo de transporte es desarrollado por el Grupo de Trabajo QUIC del Consejo de Ingeniería de Internet (IETF).

Al mismo tiempo, Google continuó trabajando en su propia implementación, y la implementó en el navegador Chrome. Aunque las pruebas muestran que la implementación QUIC de Google es significativamente peor que TCP, si la red no garantiza la entrega de paquetes .


Diferencia de rendimiento entre QUIC con TCP (en porcentaje) en una red con 112 ms RTT y 10 ms jitter, fuente


Diferencia de rendimiento entre QUIC con TCP (en porcentaje) en una red con RTT 112 ms y jitter de 10 ms, que cambia el orden de los paquetes, fuente

Algunos desarrolladores generalmente llaman a cualquier versión de QUIC en UDP un "experimento más salvaje" .

La discordia en las versiones y nombres de QUIC es explicada por Daniel Stenberg, desarrollador líder de rizos en Mozilla que ha estado siguiendo esta historia durante mucho tiempo.

Según él, los nombres informales de las dos versiones de QUIC se han extendido entre los desarrolladores, ya que las opciones de IETF y Google varían significativamente en los detalles de implementación:

• iQUIC (versión IETF)
• gQUIC (versión de Google)

El protocolo para enviar HTTP a través de iQUIC (versión IETF) se llama desde hace tiempo "hq" (HTTP-over-QUIC).

En general, no había un nombre establecido para diferentes versiones. En el seminario del Taller QUIC, Mike Bishop asustó a todos con una diapositiva como si fuera un logotipo.


Diapositiva de la presentación de Mike Bishop

Los facilitadores del taller le pidieron a Mike que nunca lo vuelva a mostrar .

Sin embargo, el 7 de noviembre de 2018, uno de los principales desarrolladores del protocolo, Dmitry Tikhonov, anunció que LiteSpeed ​​Tech y Facebook habían logrado la compatibilidad del protocolo, y ahora el desarrollo continuará en la misma línea.

Mark Nottingham, uno de los ingenieros más influyentes de IETF, coautor de varios estándares web, propuso combinar iQUIC y gQUIC llamado HTTP / 3 en septiembre. Según él, esto ayudará a eliminar la confusión entre el transporte QIUC y el contenedor QUIC para HTTP.

Por lo tanto, HTTP / 3 es la nueva versión de HTTP que utilizará el transporte QUIC .

Transporte QUIC

¿Cuáles son las ventajas del protocolo de transporte QUIC sobre TCP? Hay muchas ventajas, y según el propio Mark Nottingham, la transición de TCP obsoleto a nuevos protocolos es simplemente inevitable, ya que ahora es obvio que TCP está sufriendo problemas de ineficiencia.

“Dado que TCP es un protocolo de entrega de paquetes en orden, la pérdida de un paquete puede interferir con la entrega de paquetes posteriores desde el búfer a la aplicación. En un protocolo multiplexado, esto puede conducir a una gran pérdida de rendimiento ”, explica Mark Nottingham. "QUIC está tratando de resolver este problema mediante la reconstrucción efectiva de la semántica de TCP (junto con algunos aspectos del modelo de flujo HTTP / 2) sobre UDP".



Además de cambiar una cantidad significativa de tráfico de TCP a UDP, tanto Google QUIC (gQUIC) como IETF QUIC (iQUIC) requieren cifrado: el QUIC no cifrado no existe en absoluto . iQUIC usa TLS 1.3 para configurar las claves de sesión y luego encriptar cada paquete. Pero como se basa en UDP, gran parte de la información de la sesión y los metadatos abiertos en TCP están encriptados en QUIC.

En el artículo "El futuro de los protocolos de Internet", Mark Nottingham habla sobre mejoras significativas de seguridad con el cambio a QUIC:

En realidad, el iQUIC de "encabezado corto" actual, que se usa para todos los paquetes, excepto para un apretón de manos, proporciona solo el número de paquete, el identificador de conexión opcional y el byte de estado, necesarios para procesos como cambiar las claves de cifrado y el tipo de paquete (que también se puede cifrar). Todo lo demás está encriptado, incluidos los paquetes ACK, lo que eleva enormemente el listón para los ataques con análisis de tráfico .

Además, se hace imposible evaluar pasivamente RTT y pérdida de paquetes simplemente monitoreando la conexión; No hay suficiente información para esto.

La falta de observabilidad causó serias preocupaciones entre algunos representantes de la comunidad de operadores de telecomunicaciones. Dicen que tales mediciones pasivas son críticas para depurar y analizar sus redes.

Una de las sugerencias para resolver este problema es la introducción de un bit de giro . Este es un bit en el encabezado que cambia su valor una vez en el viaje de ida y vuelta, para que el observador pueda evaluar el RTT. Dado que no está vinculado al estado de la aplicación, no debe producir ninguna información sobre los puntos finales, excepto una estimación aproximada de la ubicación de la red.

Quizás la adopción del estándar QUIC hubiera sucedido antes si Google no se hubiera apresurado a implementar su implementación en el navegador Chrome, por lo que ahora la versión propietaria de iQUIC representa más del 7% del tráfico de Internet.

Sin embargo, el progreso es inevitable, y en los próximos años, la estandarización y la implementación generalizada de varios protocolos de nueva generación, incluido HTTP / 3 en el transporte QUIC, ciertamente continuará.

---