El IETF (Internet Engineering Task Force), que es responsable del desarrollo de protocolos y arquitectura de Internet, ha completado la formación de un RFC para el protocolo HTTP/3.0 y ha publicado 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 estado de "Estándar Propuesto", después de lo cual se comenzará a trabajar para darle al RFC el estado de borrador de estándar (Draft Standard), lo que en realidad significa una estabilización completa del protocolo y teniendo en cuenta todos los comentarios realizados. Al mismo tiempo, se publicaron versiones actualizadas de las especificaciones de 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 almacenamiento en 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 extensión del protocolo UDP que admite la multiplexació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, resolviendo problemas con largos tiempos de configuración y negociación de conexiones en TCP y eliminando retrasos cuando los paquetes se pierden durante la transferencia de datos.
Actualmente, la compatibilidad con QUIC y HTTP/3.0 ya está implementada en todos los navegadores web populares (en Chrome, Firefox y Edge, la compatibilidad con HTTP/3 está habilitada de forma predeterminada, y en Safari requiere la configuración "Avanzado > Funciones experimentales > HTTP/3" para ser habilitado). En el lado del servidor, las implementaciones HTTP/3 están disponibles para nginx (en una rama separada y en forma de módulo separado), Caddy, IIS y LiteSpeed. La red de entrega de contenido Cloudflare también proporciona soporte HTTP/3.
Características clave de QUIC:
- Alta seguridad, similar a TLS (de hecho, QUIC brinda la capacidad de usar TLS sobre UDP);
- Control de integridad de transmisión para evitar la pérdida de paquetes;
- La capacidad de establecer una conexión instantáneamente (0-RTT, en aproximadamente el 75% de los casos los datos se pueden transmitir inmediatamente después de enviar el paquete de configuración de la conexión) y proporcionar retrasos mínimos entre el envío de una solicitud y la recepción de una respuesta (RTT, Round Trip Time);
- Usar un número de secuencia diferente al retransmitir un paquete, lo que evita la ambigüedad en la identificación de los paquetes recibidos y elimina los tiempos de espera;
- La pérdida de paquetes solo afecta la entrega del flujo asociado con él y no detiene la entrega de datos en flujos transmitidos en paralelo a través de la conexión actual;
- Herramientas de corrección de errores que minimizan los retrasos debidos a la retransmisión de paquetes perdidos. Uso de códigos especiales de corrección de errores a nivel de paquete para reducir las situaciones que requieren la retransmisión de datos de paquetes perdidos.
- 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 las pérdidas de paquetes en la decodificación del contenido de los paquetes posteriores;
- No hay problemas con el bloqueo de la cola TCP;
- Soporte de ID de conexión para reducir el tiempo de reconexión para clientes móviles;
- Posibilidad de conectar mecanismos avanzados para control de sobrecarga de conexión;
- Usar técnicas de predicción de ancho de banda en cada dirección para garantizar la intensidad óptima de envío de paquetes, evitando caer en un estado de congestión, en el que hay una pérdida de paquetes;
- Aumento significativo en el rendimiento y el rendimiento en comparación con TCP. Para servicios de vídeo como YouTube, se ha demostrado que QUIC reduce las operaciones de almacenamiento en búfer al mirar vídeos en un 30 %.
Entre los cambios en la especificación HTTP/1.1, se puede destacar la prohibición del uso aislado del carácter de retorno de carro (CR) fuera del cuerpo con contenido, es decir En los elementos de protocolo, el carácter CR solo se puede utilizar junto con el carácter de avance de línea (CRLF). Se ha mejorado el algoritmo de diseño de solicitudes fragmentadas para simplificar la separación de campos adjuntos y secciones con encabezados. Se agregaron recomendaciones para manejar contenido ambiguo para bloquear ataques de "contrabando de solicitudes HTTP", que nos permiten introducirnos en el contenido de las solicitudes de otros usuarios en el flujo entre el frontend y el backend.
La actualización de la especificación HTTP/2.0 define explícitamente la compatibilidad con TLS 1.3. Se desaprobó el esquema de priorización y los campos de encabezado asociados. El mecanismo no utilizado para actualizar la conexión con HTTP/1.1 ha sido declarado obsoleto. Requisitos reducidos para verificar nombres y valores de campos. Se propone el uso de algunos tipos de tramas y parámetros previamente reservados. Los campos de encabezado prohibidos relacionados con la conexión están definidos con mayor precisión.
Fuente: opennet.ru