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”
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.
Muito bom amigo, vc tem contribuído muito com os usuários do linux.