A IETF (Internet Engineering Task Force), responsável pelo desenvolvimento de protocolos e arquitetura da Internet, concluiu a formação de uma RFC para o protocolo HTTP/3.0 e publicou especificações relacionadas sob os identificadores RFC 9114 (protocolo) e RFC 9204 ( Tecnologia de compactação de cabeçalho QPACK para HTTP/3). A especificação HTTP/3.0 recebeu o status de “Padrão Proposto”, após o qual começará o trabalho para dar ao RFC o status de rascunho de padrão (Draft Standard), o que na verdade significa uma estabilização completa do protocolo e levando em consideração todos os comentários feitos. Paralelamente, foram publicadas versões atualizadas das especificações dos protocolos HTTP/1.1 (RFC 9112) e HTTP/2.0 (RFC 9113), bem como documentos que definem a semântica das solicitações HTTP (RFC 9110) e cabeçalhos de controle de cache HTTP. (RFC 9111).
O protocolo HTTP/3 define o uso do protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP/2. QUIC é uma extensão do protocolo UDP que suporta multiplexação de múltiplas conexões e fornece métodos de criptografia equivalentes a TLS/SSL. O protocolo foi criado em 2013 pelo Google como uma alternativa à combinação TCP+TLS para a Web, resolvendo problemas de longos tempos de configuração de conexão e negociação em TCP e eliminando atrasos quando pacotes são perdidos durante a transferência de dados.
Atualmente, o suporte a QUIC e HTTP/3.0 já está implementado em todos os navegadores populares (no Chrome, Firefox e Edge, o suporte a HTTP/3 está ativado por padrão e no Safari requer a configuração “Avançado > Recursos experimentais > HTTP/3” para ser habilitado). No lado do servidor, implementações HTTP/3 estão disponíveis para nginx (em uma ramificação separada e na forma de um módulo separado), Caddy, IIS e LiteSpeed. O suporte HTTP/3 também é fornecido pela rede de entrega de conteúdo Cloudflare.
Principais recursos do QUIC:
- Alta segurança, semelhante ao TLS (na verdade, o QUIC fornece a capacidade de usar TLS sobre UDP);
- Controle de integridade de fluxo para evitar perda de pacotes;
- A capacidade de estabelecer uma conexão instantaneamente (0-RTT, em aproximadamente 75% dos casos os dados podem ser transmitidos imediatamente após o envio do pacote de configuração de conexão) e fornecer atrasos mínimos entre o envio de uma solicitação e o recebimento de uma resposta (RTT, Round Trip Time);
- Utilizar um número de sequência diferente na retransmissão de um pacote, o que evita ambiguidade na identificação dos pacotes recebidos e elimina timeouts;
- A perda de pacotes afeta apenas a entrega do stream associado a ele e não interrompe a entrega de dados em streams transmitidos em paralelo na conexão atual;
- Ferramentas de correção de erros que minimizam atrasos devido à retransmissão de pacotes perdidos. Uso de códigos especiais de correção de erros no nível do pacote para reduzir situações que requerem retransmissão de dados perdidos do pacote.
- Os limites dos blocos criptográficos estão alinhados com os limites dos pacotes QUIC, o que reduz o impacto das perdas de pacotes na decodificação do conteúdo dos pacotes subsequentes;
- Sem problemas com o bloqueio da fila TCP;
- Suporte de ID de conexão para reduzir o tempo de reconexão para clientes móveis;
- Possibilidade de conectar mecanismos avançados para controle de sobrecarga de conexão;
- Utilizar técnicas de previsão de largura de banda em cada direção para garantir a intensidade ótima de envio de pacotes, evitando rolar para um estado de congestionamento, no qual há perda de pacotes;
- Aumento significativo no desempenho e na taxa de transferência em comparação com o TCP. Para serviços de vídeo como o YouTube, foi demonstrado que o QUIC reduz em 30% as operações de rebuffering ao assistir vídeos.
Dentre as alterações na especificação HTTP/1.1, pode-se destacar a proibição do uso isolado do caractere retorno de carro (CR) fora do corpo do conteúdo, ou seja, Em elementos de protocolo, o caractere CR só pode ser usado em conjunto com o caractere de alimentação de linha (CRLF). O algoritmo de layout de solicitação em partes foi aprimorado para simplificar a separação de campos anexados e seções com cabeçalhos. Adicionadas recomendações para lidar com conteúdo ambíguo para bloquear ataques de “contrabando de solicitações HTTP”, que nos permitem entrar no conteúdo das solicitações de outros usuários no fluxo entre o front-end e o back-end.
A atualização da especificação HTTP/2.0 define explicitamente o suporte para TLS 1.3. O esquema de priorização e os campos de cabeçalho associados foram descontinuados. O mecanismo não utilizado para atualizar a conexão com HTTP/1.1 foi declarado obsoleto. Os requisitos para verificação de nomes e valores de campos foram reduzidos. Alguns tipos de quadros e parâmetros previamente reservados são propostos para uso. Os campos de cabeçalho proibidos relacionados à conexão são definidos com mais precisão.
Fonte: opennet.ru