HTTP/3.0 recebeu o status de “Proposed Standard”

Uma prova da completa estabilização do protocolo, o HTTP/3.0 recebeu o status de “Proposed Standard”. Confira os detalhes dessa mudança.

Recentemente a IETF (Internet Engineering Task Force), que desenvolve os protocolos e arquitetura da Internet, divulgou a notícia de que concluiu a formação da RFC para o protocolo HTTP/3.0 e publicou as especificações relacionadas sob os identificadores RFC 9114 e RFC 9204.

A especificação HTTP/3.0 recebeu o status de “Proposed Standard”, após o qual os trabalhos começarão a dar à RFC o status de Draft Standard, o que na verdade significa uma completa estabilização do protocolo e levando em consideração todos os comentários feitos.

HTTP/3.0 recebeu o status de “Proposed Standard”

HTTP/3.0 recebeu o status de "Proposed Standard"
HTTP/3.0 recebeu o status de “Proposed Standard”

O protocolo HTTP/3 define o uso do protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP/2. QUIC é um plugin para o 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 ao TCP + TLS para a Web, resolvendo o problema de configuração de conexão longa e tempo de negociação no TCP e eliminando atrasos devido à perda de pacotes durante a transferência de dados.

Atualmente, o suporte a QUIC e HTTP/3.0 já está implementado em todos os navegadores populares.

No lado do servidor, implementações de HTTP/3 estão disponíveis para nginx (em uma ramificação separada e como um módulo separado), Caddy , IIS e LiteSpeed. O HTTP/3 também é suportado pela Content Delivery Network da Cloudflare.

Principais características do QUIC:

  • Alta segurança, semelhante ao TLS (na verdade, o QUIC oferece a capacidade de usar TLS sobre UDP)
  • Controle de integridade de transmissão para evitar perda de pacotes
  • A capacidade de estabelecer uma conexão instantaneamente e garantir atrasos mínimos entre o envio de uma solicitação e o recebimento de uma resposta (RTT, tempo de ida e volta)
  • Use um número de sequência diferente ao retransmitir um pacote, permitindo evitar ambiguidade ao determinar os pacotes recebidos e eliminar os tempos limite
  • A perda de um pacote afeta a entrega apenas do fluxo associado a ele e não interrompe a entrega de dados em fluxos transmitidos em paralelo pela 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 em nível de pacote para reduzir situações que exigem retransmissão de dados de pacote perdidos.
  • Os limites do bloco criptográfico são alinhados com os limites do pacote QUIC, reduzindo o impacto da perda de pacotes na decodificação do conteúdo dos pacotes subsequentes
  • Nenhum problema com o bloqueio de fila TCP
  • Suporte de identificação 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
  • Use técnicas de previsão de largura de banda em cada direção para garantir taxas ideais de encaminhamento de pacotes, evitando condições de congestionamento onde os pacotes são perdidos.
  • Desempenho notável e ganhos de desempenho sobre TCP. Para serviços de vídeo como o YouTube, o QUIC demonstrou reduzir as operações de buffer de vídeo em 30%.

Além disso, também na mesma época, foram publicadas versões atualizadas das especificações para os 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).

Pelas alterações na especificação HTTP/1.1, nota-se a proibição do uso separado do caractere de retorno de carro (CR) fora do corpo com o conteúdo, ou seja, em elementos de protocolo, o caractere CR só pode ser utilizado em conjunto com o novo caractere de linha (CRLF).

O algoritmo de layout de solicitação fragmentada foi aprimorado para simplificar a separação de campos e seções anexados com cabeçalhos.
Adicionadas diretrizes para lidar com conteúdo ambíguo para bloquear ataques de classe “HTTP Request Smuggling” que podem invadir o conteúdo de solicitações de outros usuários no fluxo entre front-end e back-end.

Uma atualização para a especificação HTTP/2.0 define explicitamente o suporte para TLS 1.3, o esquema de priorização e os campos de cabeçalho relacionados foram preteridos e o mecanismo de atualização de conexão HTTP/1.1 preterido foi preterido.

Sobre o Edivaldo Brito

Edivaldo Brito é analista de sistemas, gestor de TI, blogueiro e também um grande fã de sistemas operacionais, banco de dados, software livre, redes, programação, dispositivos móveis e tudo mais que envolve tecnologia.