O Comitê IETF (Internet Engineering Task Force), responsável pelo desenvolvimento de protocolos e arquitetura da internet, concluiu a elaboração da RFC para o protocolo HTTP/3.0 e publicou as especificações relacionadas com os identificadores RFC 9114 (protocolo) e RFC 9204 (tecnologia de compressão de cabeçalhos QPACK para HTTP/3). A especificação HTTP/3.0 recebeu o status de 'Proposta de padrão', após o que começará o trabalho para conferir à RFC o status de padrão rascunho (Draft Standard), o que significa, na prática, a estabilização total do protocolo e a consideração de todos os comentários feitos. Simultaneamente, foram publicadas versões atualizadas das especificações para os protocolos HTTP/1.1 (RFC 9112) e HTTP/2.0 (RFC 9113), assim como documentos que definem a semântica das requisições HTTP (RFC 9110) e os 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. O QUIC é uma camada sobre o protocolo UDP, que suporta multiplexação de várias conexões e fornece métodos de criptografia equivalentes a TLS/SSL. O protocolo foi criado em 2013 pela Google como uma alternativa à combinação TCP+TLS para a Web, abordando problemas de alto tempo de instalação e negociação de conexões em TCP e eliminando atrasos causados pela perda de pacotes durante a transmissão de dados.
Atualmente, o suporte ao QUIC e HTTP/3.0 já foi implementado em todos os navegadores web populares (no Chrome, Firefox e Edge o suporte ao HTTP/3 vem ativado por padrão, enquanto no Safari é necessário ativar a configuração 'Advanced > Experimental Features > HTTP/3'). No lado do servidor, implementações do HTTP/3 estão disponíveis para nginx (em um branch separado e na forma de um módulo separado), Caddy, IIS e LiteSpeed. O suporte ao HTTP/3 também é garantido pela rede de entrega de conteúdo Cloudflare.
Principais características do QUIC:
- Alta segurança, equivalente ao TLS (na prática, o QUIC possibilita o uso do TLS sobre UDP);
- Controle da integridade do fluxo, prevenindo a perda de pacotes;
- Capacidade de estabelecer uma conexão instantaneamente (0-RTT, aproximadamente em 75% dos casos os dados podem ser transmitidos imediatamente após o envio do pacote de instalação da conexão) e garantir latências mínimas entre o envio da solicitação e o recebimento da resposta (RTT, Round Trip Time);
- Uso de um número de sequência diferente para retransmissão de pacotes, o que permite evitar ambiguidades na determinação dos pacotes recebidos e eliminar timeouts;
- A perda de um pacote afeta apenas a entrega do fluxo relacionado e não interrompe a entrega de dados em fluxos paralelos transmitidos através da conexão atual;
- Mecanismos de correção de erros que minimizam atrasos devido à retransmissão de pacotes perdidos. Uso de códigos especiais de correção de erros em nível de pacote para reduzir situações que exigem a retransmissão de dados de pacotes perdidos.
- Os limites dos blocos criptográficos estão alinhados com os limites dos pacotes QUIC, o que diminui o impacto da perda de pacotes na decodificação do conteúdo dos pacotes subsequentes.
- Ausência de problemas de bloqueio de fila TCP.
- Suporte a identificadores de conexão, permitindo reduzir o tempo de estabelecimento de novas conexões para clientes móveis.
- Capacidade de conectar mecanismos avançados de controle de congestionamento.
- Uso de técnicas de previsão de largura de banda em cada direção para garantir a intensidade ideal de envio de pacotes, evitando um estado de sobrecarga em que ocorre a perda de pacotes.
- Um aumento significativo no desempenho e na largura de banda em comparação com o TCP. Para serviços de vídeo, como o YouTube, a aplicação do QUIC mostrou uma redução de 30% nas operações de buffering durante a reprodução de vídeos.
Entre as mudanças na especificação do HTTP/1.1, destaca-se a proibição do uso isolado do caractere de retorno de carro (CR) fora do corpo com conteúdo, ou seja, nos elementos do protocolo o CR pode ser utilizado apenas junto com o caractere de nova linha (CRLF). O algoritmo de montagem de requisições em chunks foi aprimorado para simplificar a separação de campos anexados e a seção de cabeçalhos. Foram adicionadas recomendações para o tratamento de conteúdo ambíguo para bloquear ataques do tipo "HTTP Request Smuggling", que permitem a inserção no conteúdo de requisições de outros usuários na linha entre o front-end e o back-end.
Na atualização da especificação do HTTP/2.0, foi claramente definida a compatibilidade com o TLS 1.3. O esquema de definição de prioridades e os campos relacionados nos cabeçalhos foram classificados como obsoletos. Foi declarado obsoleto o mecanismo de atualização de conexão do HTTP/1.1 que não se difundiu. As exigências para a verificação dos nomes dos campos e valores foram reduzidas. Alguns tipos de quadros e parâmetros anteriormente reservados foram sugeridos para uso. Os campos de cabeçalho, referentes à conexão, foram definidos de forma mais precisa como proibidos.
Fonte: opennet.ru
