
Recentemente, os desenvolvedores por trás do navegador Google Chrome anunciaram a notícia da adição de suporte ao protocolo HTTP/3 às compilações experimentais do Chrome Canary, que implementa um complemento para ativar o HTTP sobre QUIC.
O próprio protocolo QUIC foi adicionado ao navegador há cinco anos e, desde então, é usado para otimizar o trabalho com os serviços do Google. Ao mesmo tempo, a versão do Google QUIC usada no Chrome diferia em alguns detalhes da versão das especificações da IETF, mas agora as implementações estão sincronizadas.
É importante observar que o Google desenvolve o QUIC (Quick UDP Internet Connections) desde 2013 como uma alternativa ao TCP+TLS para o pacote da Web, que resolve problemas com longos tempos de configuração e negociação das conexões TCP e elimina atrasos na perda de pacotes durante a transferência de dados.
O QUIC é um complemento ao protocolo UDP que oferece suporte à multiplexação de várias conexões e fornece métodos de criptografia equivalentes ao TLS/SSL.
O protocolo em questão já está integrado à infraestrutura de servidores do Google, faz parte do Chrome, está planejado para inclusão no Firefox e é usado ativamente para atender às solicitações dos clientes nos servidores do Google.
Entre as principais características do QUIC que se destacam estão:
- Alta segurança, semelhante ao TLS (de fato, o QUIC oferece a capacidade de usar TLS sobre UDP).
- Controle de integridade de fluxo que evita a perda de pacotes
- A capacidade de estabelecer uma conexão instantânea (0-RTT, em aproximadamente 75% dos casos, os dados podem ser transmitidos imediatamente após o envio do pacote de configuração da conexão) e garantir atrasos mínimos entre o envio de uma solicitação e Recebendo uma resposta (RTT, Tempo de Ida e Volta)
- Não usa o mesmo número de sequência ao retransmitir um pacote, o que evita ambiguidade na determinação de pacotes recebidos e elimina os tempos de espera
- 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.
- O 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.
- Os limites criptográficos dos blocos estão alinhados com os limites dos pacotes QUIC, o que reduz o efeito da perda de pacotes na decodificação do conteúdo dos seguintes pacotes
- Sem problemas com o bloqueio da fila TCP
- Suporte para o identificador de conexão, que reduz o tempo para estabelecer uma reconexão para clientes móveis
- Capacidade de conectar mecanismos avançados para controlar a sobrecarga de conexão
Note-se também que a técnica de previsão da largura de banda em cada direção é usada para garantir a intensidade ideal de envio de pacotes, impedindo que ela atinja um estado de congestionamento no qual a perda de pacotes é observada;
Além de notáveis ganhos de desempenho e desempenho sobre o TCP. Para serviços de vídeo como o YouTube, o QUIC mostrou uma redução de 30% nas operações de buffer ao assistir vídeos.
O protocolo HTTP / 3 padroniza o uso do QUIC como um transporte para HTTP / 2. Para habilitar o HTTP / 3 e a versão QUIC dos 23 rascunhos das especificações da IETF, o Chrome deve ser executado com as opções “–enable-quic –quic-version = h3-23” e depois quando o site de teste quic.rocks:4433 for aberto no modo de inspeção de rede nas ferramentas do desenvolvedor, a atividade HTTP / 3 será exibida como “http / 2 + quic / 99”.
Comparado a um pacote perdido devido a conexões HTTP paralelas, apenas uma das muitas conexões será interrompida, o que significa que o QUIC pode oferecer suporte a entrega fora de ordem, para que um pacote perdido tenha menos impacto.
Se você quiser saber mais sobre isso, verifique o seguinte link.