El Comité IETF (Internet Engineering Task Force), encargado del desarrollo de protocolos y arquitectura de Internet, ha completado la formación del RFC para el protocolo HTTP/3.0 y ha publicado las especificaciones relacionadas bajo los identificadores RFC 9114 (protocolo) y RFC 9204 (tecnología de compresión de encabezados QPACK para HTTP/3). La especificación HTTP/3.0 ha recibido el estatus de "Estándar Propuesto", tras lo cual comenzará el trabajo para otorgar al RFC el estatus de Estándar en Borrador (Draft Standard), lo que significa la estabilización completa del protocolo y la consideración de todos los comentarios recibidos. Al mismo tiempo, se han publicado versiones actualizadas de las especificaciones para los protocolos HTTP/1.1 (RFC 9112) y HTTP/2.0 (RFC 9113), así como documentos que definen la semántica de las solicitudes HTTP (RFC 9110) y los encabezados de control de caché HTTP (RFC 9111).
El protocolo HTTP/3 define el uso del protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP/2. QUIC es una capa sobre el protocolo UDP que admite la multiplexión de múltiples conexiones y proporciona métodos de cifrado equivalentes a TLS/SSL. El protocolo fue creado en 2013 por Google como una alternativa a la combinación TCP+TLS para la web, abordando problemas de tiempos altos de establecimiento y negociación de conexiones en TCP y eliminando retrasos por pérdida de paquetes durante la transmisión de datos.
Actualmente, el soporte para QUIC y HTTP/3.0 ya se ha implementado en todos los navegadores web populares (en Chrome, Firefox y Edge, el soporte para HTTP/3 está habilitado por defecto, mientras que en Safari se requiere activar la opción "Advanced > Experimental Features > HTTP/3"). En el lado del servidor, las implementaciones de HTTP/3 están disponibles para nginx (en una rama separada y como un módulo independiente), Caddy, IIS y LiteSpeed. La red de entrega de contenido Cloudflare también proporciona soporte para HTTP/3.
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%.
Entre los cambios en la especificación HTTP/1.1 se incluye la prohibición del uso aislado del carácter de retorno de carro (CR) fuera del cuerpo del contenido, es decir, en los elementos del protocolo, el carácter CR solo puede aplicarse junto con el carácter de salto de línea (CRLF). El algoritmo de segmentación de solicitudes chunked se ha mejorado para simplificar la separación de campos adjuntos y secciones de encabezados. Se han añadido recomendaciones sobre el manejo de contenido ambiguo para bloquear ataques de tipo 'HTTP Request Smuggling', que permiten inmiscuirse en el contenido de solicitudes de otros usuarios en el flujo entre el frontend y el backend.
En la actualización de la especificación HTTP/2.0, se define claramente el soporte para TLS 1.3. La categoría de esquema de priorización definida se ha trasladado a obsoleto, así como los campos asociados en los encabezados. Se ha declarado obsoleto un mecanismo de actualización de conexión que no se popularizó con HTTP/1.1. Se han reducido los requisitos para la verificación de nombres de campos y valores. Se han propuesto para su uso ciertos tipos de marcos y parámetros que anteriormente estaban reservados. Se han definido más claramente los campos de encabezado prohibidos relacionados con la conexión.
Fuente: opennet.ru
