La empresa Mozilla ha anunciado su intención de comenzar a habilitar progresivamente los protocolos HTTP/3 y QUIC en la versión 88 de Firefox, programada para el 19 de abril (originalmente, el lanzamiento estaba previsto para el 20 de abril, pero, según el cronograma, se ha retrasado un día). Al principio, el soporte para HTTP/3 se activará solo para un pequeño porcentaje de usuarios y, si no surgen problemas imprevistos, se implementará para todos a finales de mayo. En las compilaciones nocturnas y versiones beta, HTTP/3 se activó por defecto a finales de marzo.
Recordemos que la implementación de HTTP/3 en Firefox se basa en el proyecto neqo, desarrollado por la empresa 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 el lenguaje Rust. Para controlar la activación de HTTP/3 en about:config, existe la opción "network.http.http3.enabled". El soporte experimental para HTTP/3 también se ha agregado en Chrome y curl, y para servidores está disponible en nginx, así como en forma de módulo nginx y en un servidor de prueba de la empresa Cloudflare. En el lado de los sitios, el soporte para HTTP/3 ya está asegurado en los servidores de Google y Facebook.
El protocolo HTTP/3 se encuentra todavía en una etapa de borrador de especificación y no ha sido estandarizado en el IETF. Para utilizar HTTP/3, se requiere el soporte en el lado del cliente y del servidor de la misma versión del borrador estándar de QUIC y HTTP/3, que se indica en el encabezado Alt-Svc (Firefox admite borradores de especificación del 27 al 32).
HTTP/3 define el uso del protocolo QUIC como transporte para HTTP/2. El protocolo QUIC (Quick UDP Internet Connections) se ha desarrollado desde 2013 por Google como una alternativa al par TCP+TLS para la web, que resuelve problemas de alto tiempo de establecimiento y negociación de conexiones en TCP y elimina las demoras por pérdida de paquetes durante la transmisión de datos. QUIC es una capa adicional sobre el protocolo UDP, que admite la multiplexión de varias conexiones y proporciona métodos de cifrado equivalentes a TLS/SSL. Durante el desarrollo al estándar en IETF, se realizaron cambios en el protocolo, lo que resultó en la existencia de dos ramas que coexisten, una para HTTP/3 y la otra respaldada por Google (Chrome admite 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;
- Posibilidad de establecer conexión de inmediato (0-RTT, en aproximadamente el 75% de los casos, los datos se pueden transmitir inmediatamente después de enviar el paquete de establecimiento de conexión) y asegurar mínimas latencias 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;
- Incremento significativo en el rendimiento y la capacidad de transmisión en comparación con TCP. Para servicios de video como YouTube, la implementación de QUIC ha demostrado reducir las operaciones de rebuffering al ver videos en un 30%.
Fuente: opennet.ru
