Hoy proseguiremos con la cadena de artículos sobre el protocolo HTTP/3, tratando la definición del protocolo y sus principales características.
El objetivo principal del protocolo QUIC es convertirse en el equivalente a una conexión TCP independiente, pero con una latencia mucho más reducida, es decir, busca como objetivo 0 RTT en el establecimiento de la conexión, así como mejorar el multiplexado implementado en SPDY y, por consiguiente, en HTTP 2.
Establecimiento de conexión
Uno de los mayores puntos fuertes de QUIC es el método seguido para lograr 0 RTT en el establecimiento de las sesiones y en cómo se gestionan las debilidades conocidas de UDP. Una sesión establecida a través de QUIC se basa en que durante la primera petición, el cliente almacena la información sobre el servidor, permitiéndole en conexiones posteriores, establecer una conexión cifrada sin intercambio de mensajes previos. Algunas debilidades a nivel de UDP son resueltas con QUIC, destacando los problemas de spoofing de direcciones IP y los ataques de replay:
En resumen, la primera vez que un cliente QUIC se conecta a un servidor, el cliente debe realizar un intercambio de mensajes enviando un mensaje “hello” (CHLO) vacío y el servidor envía entonces una respuesta de rechazo (REJ) con la información del token y los certificados del servidor. Las próximas veces que el cliente envíe un CHLO, puede hacer uso de las credenciales cacheadas de la conexión anterior para mandar inmediatamente las peticiones cifradas al servidor, estableciendo una sesión en 0 RTT.
Autenticación, cifrado de las cabeceras y carga útil de un paquete
Por definición, los paquetes de QUIC se encuentran siempre cifrados, aunque algunas partes de la cabecera del paquete no lo estén. Pero, solamente los paquetes de tipo PUBLIC_RESET, cuya función es resetear una conexión, no están autenticados, lo que impide que exista capacidad de inyección o de manipulación de datos por obra de terceros.
Corrección de errores y pérdida de paquetes
Al estar basado sobre UDP, no existe un control del flujo de los paquetes, lo que permite que unos paquetes lleguen antes que otros o que haya paquetes que se pierdan. Para recuperar estos paquetes sin necesidad de una retransmisión uno por uno, QUIC utiliza un esquema de “Forward Error Correction” (FEC). Si uno de los paquetes del grupo se pierde, el contenido de este se puede recuperar mediante el análisis del paquete FEC y del resto de paquetes del grupo.
Migración de conexión
Uno de los puntos más importantes de QUIC, reside en la capacidad de resiliencia a cambios de IP y a cambios de traducciones de NAT durante el transcurso de la sesión, debido a que las conexiones están identificadas por un ID de conexión de 64 bits, generado de forma aleatoria por el cliente y el cual continúa siendo igual durante estas migraciones.
El objetivo principal del protocolo QUIC es convertirse en el equivalente a una conexión TCP independiente, pero con una latencia mucho más reducida, es decir, busca como objetivo 0 RTT en el establecimiento de la conexión, así como mejorar el multiplexado implementado en SPDY y, por consiguiente, en HTTP 2.
Establecimiento de conexión
Uno de los mayores puntos fuertes de QUIC es el método seguido para lograr 0 RTT en el establecimiento de las sesiones y en cómo se gestionan las debilidades conocidas de UDP. Una sesión establecida a través de QUIC se basa en que durante la primera petición, el cliente almacena la información sobre el servidor, permitiéndole en conexiones posteriores, establecer una conexión cifrada sin intercambio de mensajes previos. Algunas debilidades a nivel de UDP son resueltas con QUIC, destacando los problemas de spoofing de direcciones IP y los ataques de replay:
- Spoofing de la dirección IP: Este problema es solucionado por QUIC de forma que el servidor envía un token que contiene, al menos, la dirección IP del cliente y una marca temporal por el servidor, el equivalente al número de secuencia en una conexión TCP. De esta manera, mientras la dirección IP no varíe o el token no caduque, éste podrá seguir siendo utilizado de forma válida para el intercambio de información.
- Ataques de Replay: Este problema es solventado mediante el envío de un número aleatorio (nonce) junto con la derivación de las claves, al igual que lo hace TLS. Pero esto solo es posible una vez se ha realizado el intercambio de claves en el establecimiento de sesión.
En resumen, la primera vez que un cliente QUIC se conecta a un servidor, el cliente debe realizar un intercambio de mensajes enviando un mensaje “hello” (CHLO) vacío y el servidor envía entonces una respuesta de rechazo (REJ) con la información del token y los certificados del servidor. Las próximas veces que el cliente envíe un CHLO, puede hacer uso de las credenciales cacheadas de la conexión anterior para mandar inmediatamente las peticiones cifradas al servidor, estableciendo una sesión en 0 RTT.
Autenticación, cifrado de las cabeceras y carga útil de un paquete
Por definición, los paquetes de QUIC se encuentran siempre cifrados, aunque algunas partes de la cabecera del paquete no lo estén. Pero, solamente los paquetes de tipo PUBLIC_RESET, cuya función es resetear una conexión, no están autenticados, lo que impide que exista capacidad de inyección o de manipulación de datos por obra de terceros.
Corrección de errores y pérdida de paquetes
Al estar basado sobre UDP, no existe un control del flujo de los paquetes, lo que permite que unos paquetes lleguen antes que otros o que haya paquetes que se pierdan. Para recuperar estos paquetes sin necesidad de una retransmisión uno por uno, QUIC utiliza un esquema de “Forward Error Correction” (FEC). Si uno de los paquetes del grupo se pierde, el contenido de este se puede recuperar mediante el análisis del paquete FEC y del resto de paquetes del grupo.
Migración de conexión
Uno de los puntos más importantes de QUIC, reside en la capacidad de resiliencia a cambios de IP y a cambios de traducciones de NAT durante el transcurso de la sesión, debido a que las conexiones están identificadas por un ID de conexión de 64 bits, generado de forma aleatoria por el cliente y el cual continúa siendo igual durante estas migraciones.
HTTP over QUIC/HTTP 3 vs HTTP 2
El protocolo QUIC se ha diseñado para mejorar los servicios web, aunando las mejores soluciones de HTTP, TLS y TCP, con la sencillez de la capa de transporte UDP. Es reseñable la mejora en rendimiento que hace HTTP sobre QUIC como método de transporte, en comparación con el nuevo estándar HTTP 2.
No obstante, al igual que ocurre con HTTP 2, es una mejora considerable con respecto a casi cualquier conexión HTTP 1.1 sin multiplexación, exceptuando aquellas páginas con un número muy limitado de recursos, las cuales tienen un tiempo muy bajo de respuesta de base.
Eso es todo por hoy, en el próximo artículo de la cadena continuaremos hablando sobre los principales puntos de análisis del protocolo.
Saludos!
No hay comentarios:
Publicar un comentario