En las versiones nocturnas de Firefox, así como en la beta, el soporte para el protocolo HTTP/3 está habilitado por defecto. La activación de HTTP/3 en la versión estable está programada para el lanzamiento de Firefox 88, previsto para el 20 de abril. En Chrome, la activación selectiva de HTTP/3 comenzó en octubre de 2020.
El soporte para HTTP/3 en Firefox se basa en el proyecto neqo, desarrollado por Mozilla, que proporciona la implementación del cliente y servidores para el protocolo QUIC. El código de los componentes para el soporte de HTTP/3 y QUIC está escrito en Rust. Para gestionar la activación de HTTP/3 en about:config, hay una opción llamada «network.http.http3.enabled». El soporte experimental para HTTP/3 también se ha añadido en Chrome y curl, y para servidores está disponible en nginx, así como en forma de módulo de nginx y un servidor de pruebas de Cloudflare. Se han lanzado varios sitios de prueba para comprobar el funcionamiento de los clientes de HTTP/3.
El protocolo HTTP/3 todavía está en fase de borrador y no ha sido estandarizado de manera definitiva en la IETF. HTTP/3 define el uso del protocolo QUIC como transporte para HTTP/2. El protocolo QUIC (Quick UDP Internet Connections) ha sido desarrollado por Google desde 2013 como una alternativa a la combinación TCP+TLS para la web, solucionando problemas de largos tiempos de establecimiento y negociación de conexiones en TCP y eliminando retrasos por pérdida de paquetes durante la transmisión de datos. QUIC es una superestructura sobre el protocolo UDP que soporta la multiplexión de múltiples conexiones y proporciona métodos de cifrado equivalentes a TLS/SSL. Durante el desarrollo del estándar en la IETF, se realizaron cambios en el protocolo, lo que llevó a la existencia de dos ramas paralelas, una para HTTP/3 y otra respaldada por Google (Chrome soporta ambas versiones).
Características principales de QUIC:
- Alta seguridad, similar a TLS (de hecho, QUIC permite el uso de TLS sobre UDP);
- Control de integridad del flujo, previniendo la pérdida de paquetes;
- La posibilidad de establecer una conexión de inmediato (0-RTT, en aproximadamente el 75% de los casos los datos se pueden transmitir inmediatamente después del envío del paquete de establecimiento de conexión) y asegurar una latencia mínima entre el envío de la solicitud y la recepción de la respuesta (RTT, Round Trip Time);
- El uso de un número de secuencia diferente al retransmitir un paquete, lo que permite evitar ambigüedades al determinar los paquetes recibidos y eliminar los tiempos de espera;
- La pérdida de paquetes afecta solo a la entrega de la corriente asociada y no detiene la entrega de datos en las corrientes que se transmiten en paralelo a través de la conexión actual;
- Mecanismos de corrección de errores que minimizan la latencia debido a la retransmisión de paquetes perdidos. Uso de códigos especiales de corrección de errores a nivel de paquete para reducir situaciones que requieren la retransmisión de datos de un paquete perdido.
- Los límites de los bloques criptográficos están alineados con los límites de los paquetes QUIC, lo que reduce el impacto de la pérdida de paquetes en la decodificación del contenido de los siguientes paquetes;
- Ausencia de problemas de bloqueo de la cola TCP;
- Soporte para un identificador de conexión que permite reducir el tiempo de establecimiento de una nueva conexión para clientes móviles;
- Capacidad de conectar mecanismos avanzados de control de congestión de la conexión;
- Uso de técnicas de predicción de ancho de banda en cada dirección para asegurar la intensidad óptima de envío de paquetes, evitando caer en un estado de congestión donde se observa la pérdida de paquetes;
- Un notable incremento en el rendimiento y el ancho de banda en comparación con TCP. Para servicios de video como YouTube, el uso de QUIC ha mostrado una reducción del 30% en las operaciones de rebuffers al ver videos.
Fuente: opennet.ru
