HTTP/3.0 recibió el estado de «Estándar propuesto»

Hace poco el IETF (Grupo de Trabajo de Ingeniería de Internet), que desarrolla los protocolos y la arquitectura de Internet, dio a conocer la noticia de que completó la formación del RFC para el protocolo HTTP/3.0 y publicó las especificaciones relacionadas bajo los identificadores RFC 9114 y RFC 9204.

La especificación HTTP/3.0 recibió el estado de «Estándar propuesto», después de lo cual se comenzará a trabajar para darle a RFC el estado de un 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.

El protocolo HTTP/3 define el uso del protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP/2. QUIC es un complemento del protocolo UDP que admite la multiplexación de varias conexiones y proporciona métodos de cifrado equivalentes a TLS/SSL.

El protocolo fue creado en 2013 por Google como una alternativa a TCP + TLS para la Web, resolviendo el problema de la configuración de conexión prolongada y el tiempo de negociación en TCP y eliminando las demoras debido a la pérdida de paquetes durante la transferencia de datos.

Actualmente, la compatibilidad con QUIC y HTTP/3.0 ya está implementada en todos los navegadores web populares. Del lado del servidor, las implementaciones de HTTP/3 están disponibles para nginx (en una rama separada y en forma de un módulo separado), Caddy , IIS y LiteSpeed. HTTP/3 también es compatible con la red de entrega de contenido de Cloudflare.

Características principales 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 y garantizar demoras mínimas entre el envío de una solicitud y la recepción de una respuesta (RTT, tiempo de ida y vuelta)
• Usar un número de secuencia diferente al retransmitir un paquete, lo que le permite evitar la ambigüedad al determinar los paquetes recibidos y deshacerse de los tiempos de espera
• La pérdida de un paquete afecta la entrega de solo el 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 la pérdida de paquetes en la decodificación del contenido de los siguientes paquetes
• No hay problemas con el bloqueo de la cola TCP
• Soporte de identificación 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 tasas óptimas de envío de paquetes, evitando que se produzcan condiciones de congestión en las que se pierdan paquetes.
• Aumentos notables de rendimiento y rendimiento sobre TCP . Para servicios de video como YouTube, se ha demostrado que QUIC reduce las operaciones de almacenamiento en búfer de video en un 30 %.

Ademas de ello, tambien al mismo tiempo, se publicaron 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 almacenamiento en caché HTTP (RFC 9111).

De los cambios en la especificación HTTP/1.1, se puede notar la prohibición del uso separado del carácter de retorno de carro (CR) fuera del cuerpo con el contenido, es decir en elementos de protocolo, el carácter CR solo se puede utilizar junto con el carácter de nueva línea (CRLF).

El algoritmo de diseño de solicitudes fragmentadas se ha mejorado para simplificar la separación de campos adjuntos y secciones con encabezados. Se agregaron pautas para manejar contenido ambiguo para bloquear ataques de clase «Contrabando de solicitudes HTTP» que pueden entrometerse en el contenido de las solicitudes de otros usuarios en el flujo entre el frontend y el backend.

Una actualización de la especificación HTTP/2.0 define explícitamente la compatibilidad con TLS 1.3, se descartaron el esquema de priorización y los campos de encabezado relacionados y el mecanismo de actualización de conexión HTTP/1.1 obsoleto ha quedado obsoleto.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.