O IETF (Internet Engineering Task Force), que é responsable do desenvolvemento de protocolos e arquitectura de Internet, finalizou o RFC para o protocolo HTTP/3.0 e publicou especificacións relacionadas cos identificadores RFC 9114 (protocolo) e RFC 9204 (compresión de cabeceira QPACK). tecnoloxía para HTTP/3). A especificación HTTP/3.0 recibiu o estado de "Estándar proposto", tras o cal comezará a traballar para darlle ao RFC o estado de borrador de estándar (Draft Standard), o que en realidade significa unha estabilización completa do protocolo e tendo en conta todos os comentarios realizados. Ao mesmo tempo, publicáronse versións actualizadas das especificacións dos protocolos HTTP/1.1 (RFC 9112) e HTTP/2.0 (RFC 9113), así como documentos que definen a semántica das solicitudes HTTP (RFC 9110) e as cabeceiras de control de caché HTTP. (RFC 9111).
O protocolo HTTP/3 define o uso do protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP/2. QUIC é unha extensión do protocolo UDP que admite a multiplexación de varias conexións e proporciona métodos de cifrado equivalentes a TLS/SSL. O protocolo foi creado en 2013 por Google como unha alternativa á combinación TCP+TLS para a Web, resolvendo problemas con longos tempos de configuración de conexión e negociación en TCP e eliminando os atrasos cando se perden paquetes durante a transferencia de datos.
Actualmente, a compatibilidade con QUIC e HTTP/3.0 xa está implementada en todos os navegadores web populares (en Chrome, Firefox e Edge, a compatibilidade con HTTP/3 está activada de forma predeterminada, e en Safari require a configuración "Avanzado > Funcións experimentais > HTTP/3" para ser habilitado). No lado do servidor, as implementacións HTTP/3 están dispoñibles para nginx (nunha rama separada e en forma de módulo separado), Caddy, IIS e LiteSpeed. A rede de entrega de contido de Cloudflare tamén ofrece soporte HTTP/3.
Características principais de QUIC:
- Alta seguridade semellante a TLS (esencialmente QUIC ofrece a posibilidade de usar TLS sobre UDP);
- Control de integridade do fluxo, evitando a perda de paquetes;
- A capacidade de establecer unha conexión instantáneamente (0-RTT, en aproximadamente o 75% dos casos os datos pódense transmitir inmediatamente despois de enviar o paquete de configuración da conexión) e proporcionar atrasos mínimos entre o envío dunha solicitude e a recepción dunha resposta (RTT, Tempo de ida e volta);
- Usar un número de secuencia diferente ao retransmitir un paquete, o que evita a ambigüidade na identificación dos paquetes recibidos e elimina os tempos de espera;
- A perda dun paquete afecta só á entrega do fluxo asociado a el e non detén a entrega de datos en fluxos paralelos transmitidos a través da conexión actual;
- Funcións de corrección de erros que minimizan os atrasos debidos á retransmisión de paquetes perdidos. Uso de códigos especiais de corrección de erros a nivel de paquetes para reducir as situacións que requiren a retransmisión de paquetes de datos perdidos.
- Os límites dos bloques criptográficos están aliñados cos límites dos paquetes QUIC, o que reduce o impacto das perdas de paquetes na decodificación do contido dos paquetes posteriores;
- Non hai problemas co bloqueo da fila TCP;
- Soporte para o identificador de conexión, que reduce o tempo necesario para establecer unha reconexión para os clientes móbiles;
- Posibilidade de conectar mecanismos avanzados de control de conxestión da conexión;
- Utiliza técnicas de previsión de rendemento por dirección para garantir que os paquetes se envían a velocidades óptimas, evitando que se conxestionen e causen a perda de paquetes;
- Aumento significativo do rendemento e do rendemento en comparación co TCP. Para servizos de vídeo como YouTube, demostrouse que QUIC reduce nun 30 % as operacións de rebuffer ao ver vídeos.
Entre os cambios na especificación HTTP/1.1, pódese sinalar a prohibición do uso illado do carácter de retorno de carro (CR) fóra do corpo con contido, é dicir. Nos elementos de protocolo, o carácter CR só se pode usar xunto co carácter de avance de liña (CRLF). Mellorouse o algoritmo de deseño de solicitudes fragmentadas para simplificar a separación de campos anexos e seccións con cabeceiras. Engadíronse recomendacións para xestionar contido ambiguo para bloquear os ataques de "contrabando de solicitudes HTTP", que nos permiten axustarnos ao contido das solicitudes doutros usuarios no fluxo entre o frontend e o backend.
A actualización da especificación HTTP/2.0 define explícitamente a compatibilidade con TLS 1.3. O esquema de priorización e os campos de cabeceira asociados quedaron en desuso. O mecanismo non utilizado para actualizar a conexión con HTTP/1.1 declarouse obsoleto. Reduciron os requisitos para comprobar os nomes e os valores dos campos. Propóñense para o seu uso algúns tipos de cadros e parámetros reservados previamente. Os campos de cabeceira prohibidos relacionados coa conexión defínense con máis precisión.
Fonte: opennet.ru