Espera-se que o Firefox lance suporte HTTP/3 até o final de maio.

A Mozilla anunciou sua intenção de começar a implementar HTTP/3 e QUIC com o lançamento do Firefox 88, agendado para 19 de abril (originalmente previsto para ser lançado em 20 de abril, mas a julgar pelo cronograma, será adiado por um dia). O suporte HTTP/3 será habilitado inicialmente apenas para uma pequena porcentagem de usuários e, salvo quaisquer problemas inesperados, será implementado para todos até o final de maio. Nas compilações noturnas e nas versões beta, o HTTP/3 foi habilitado por padrão no final de março.

Lembremos que a implementação do HTTP/3 no Firefox é baseada no projeto neqo desenvolvido pela Mozilla, que fornece uma implementação cliente e servidor para o protocolo QUIC. O código do componente para suporte HTTP/3 e QUIC é escrito em Rust. Para controlar se o HTTP/3 está habilitado, about:config fornece a opção “network.http.http3.enabled”. Do software cliente, o suporte experimental para HTTP/3 também foi adicionado ao Chrome e curl, e para servidores está disponível em nginx, bem como na forma de um módulo nginx e um servidor de teste da Cloudflare. Do lado do site, o suporte HTTP/3 já é fornecido nos servidores do Google e do Facebook.

O protocolo HTTP/3 ainda está em fase de rascunho de especificação e ainda não foi totalmente padronizado pela IETF. HTTP/3 requer suporte de cliente e servidor para a mesma versão do padrão de rascunho QUIC e HTTP/3, que é especificado no cabeçalho Alt-Svc (o Firefox suporta rascunhos de especificações 27 a 32).

HTTP/3 define o uso do protocolo QUIC como um transporte para HTTP/2. O protocolo QUIC (Quick UDP Internet Connections) é desenvolvido pelo Google desde 2013 como uma alternativa à combinação TCP+TLS para a Web, resolvendo problemas com longos tempos de configuração e negociação de conexões em TCP e eliminando atrasos quando pacotes são perdidos durante a transmissão de dados. transferir. 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. Durante o desenvolvimento do padrão IETF, foram feitas alterações no protocolo, o que levou ao surgimento de duas ramificações paralelas, uma para HTTP/3 e a segunda suportada pelo Google (o Chrome suporta ambas as opções).

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.
  • Fonte: opennet.ru

Adicionar um comentário