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.

Deixe um comentário

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Ads Blocker Image Powered by Code Help Pro

Bloqueador de anúncios detectado!!!

Nosso site precisa de publicidade para existir. Por favor, insira-o na lista de permissões/lista branca para liberar a exibição de anúncios e apoiar nosso site. Nosso conteúdo é GRATUITO, e tudo o que pedimos é isso!