O Grupo de Trabalho de Engenharia da Internet (IETF), o comitê que desenvolve os protocolos e a arquitetura da Internet, concluiu as RFCs para o protocolo QUIC e publicou as especificações relacionadas como RFC 8999 (propriedades de protocolo independentes de versão), RFC 9000 (transporte sobre UDP), RFC 9001 (criptografia baseada em TLS do canal de comunicação QUIC) e RFC 9002 (controle de congestionamento e detecção de perda de pacotes durante a transmissão de dados).
As RFCs receberam o status de "Padrão Proposto", após o qual o trabalho começará para elevá-las ao status de Padrão Provisório, o que significa, efetivamente, a estabilização completa do protocolo e a incorporação de todos os comentários. O protocolo HTTP/3, que define o uso do protocolo QUIC como transporte para HTTP/2, está atualmente na fase de especificação preliminar, mas também será em breve padronizado pela IETF.
Espera-se que a padronização do QUIC impulsione uma adoção mais ampla desse protocolo, bem como o desenvolvimento de extensões baseadas nele, como o WebTransport (uma tecnologia para envio e recebimento de dados entre um navegador e um servidor). servidor) e MASQUE (uma tecnologia de proxy de conexão que amplia as capacidades do SOCKS e do HTTP CONNECT e usa HTTPS sobre QUIC como transporte).
Para relembrar, o protocolo QUIC (Quick UDP Internet Connections) foi desenvolvido pelo Google em 2013 como uma alternativa ao TCP+TLS para a web. Ele resolve o problema da lentidão no estabelecimento e negociação de conexões do TCP e elimina os atrasos causados pela perda de pacotes durante a transferência de dados. O QUIC é um superconjunto do protocolo UDP que suporta multiplexação de múltiplas conexões e fornece métodos de criptografia equivalentes ao TLS/SSL. Durante o desenvolvimento do padrão IETF, foram feitas alterações no protocolo, resultando em duas versões paralelas: uma para HTTP/3 e outra suportada pelo Google (o Chrome suporta ambas as variantes, enquanto o Firefox suporta a variante IETF).
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
