QUIC

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa

QUIC é um protocolo de rede de camada de transporte[1] para propósitos gerais[2] inicialmente concebido por Jim Roskind no Google,[3] implementado e implantado em 2012,[4] anunciado publicamente em 2013, à medida que a experimentação se alarga[5][6][7] e descrito à IETF.[8] Embora continue a ser um projeto Internet, o QUIC é utilizado por mais de metade de todas as ligações do navegador Web Chrome aos servidores da Google.[9] O navegador Microsoft Edge suporta o QUIC, o Firefox suporta-o nas suas construções noturnas.

Embora seu nome tenha sido inicialmente proposto como o acrônimo de "Quick UDP Internet Connections",[3][8] o uso da palavra QUIC pela IETF não é um acrônimo; é simplesmente o nome do protocolo.[2]

Entre outras aplicações, o QUIC melhora o desempenho das aplicações web orientadas para a conexão que estão atualmente utilizando TCP.[1][9] Para isso, estabelece uma série de conexões multiplexadas entre dois pontos terminais sobre o User Datagram Protocol (UDP). Isto funciona em conjunto com as conexões multiplexadas do HTTP/2, permitindo que múltiplos fluxos de dados cheguem a todos os pontos terminais de forma independente e, portanto, independente de perdas de pacotes envolvendo outros fluxos. Em contraste, o HTTP/2 hospedado no Protocolo de Controle de Transmissão (TCP) pode sofrer atrasos de bloqueio de cabeça de linha de todos os fluxos multiplexados se algum dos pacotes TCP for atrasado ou perdido.

Os objetivos secundários do QUIC incluem a redução da latência da ligação e do transporte, e a estimativa da largura de banda em cada direção para evitar congestionamentos. Também move algoritmos de controle de congestionamento para o espaço de usuário em ambos os pontos terminais, em vez do espaço de núcleo, o que, segundo se afirma, permitirá que estes algoritmos melhorem mais rapidamente. Além disso, o protocolo pode ser alargado com a correção de erros em avanço (FEC) para melhorar ainda mais o desempenho quando são esperados erros, o que é visto como o próximo passo na evolução do protocolo.

Em Junho de 2015, foi apresentado à IETF, para normalização, um projeto de especificação do QUIC na Internet.[10][11] Em 2016, foi criado um grupo de trabalho QUIC.[12] Em Outubro de 2018, os Grupos de Trabalho HTTP e QUIC da IETF decidiram conjuntamente chamar ao mapeamento HTTP sobre o QUIC "HTTP/3", antes de o tornarem um padrão mundial.[13]

Motivação[editar | editar código-fonte]

O Protocolo de Controle de Transmissão, ou TCP, tem como objetivo fornecer uma interface para o envio de fluxos de dados entre dois pontos finais. Os dados são entregues ao sistema TCP, o que garante que os dados cheguem à outra ponta exatamente da mesma forma, ou a conexão indicará que existe uma condição de erro.[14][15][16][17][18]

Para fazer isso, o TCP divide os dados em pacotes de rede e adiciona pequenas quantidades de dados a cada pacote. Esses dados adicionais incluem um número de sequência usado para detectar pacotes perdidos ou transmitidos fora de ordem e uma soma de verificação que permite a detecção de erros nos dados dos pacotes. Quando um desses problemas ocorre, o TCP usa o pedido de repetição automático (ARQ) para solicitar ao remetente que reenvie o pacote perdido ou danificado.[14][15][16][17][18]

Na maioria das implementações, o TCP verá qualquer erro em uma conexão como uma operação de bloqueio, interrompendo outras transferências até que o erro seja resolvido ou a conexão seja considerada com falha. Se uma única conexão estiver sendo usada para enviar vários fluxos de dados, como é o caso do protocolo HTTP/2, todos esses fluxos serão bloqueados, embora apenas um deles possa ter um problema. Por exemplo, se ocorrer um único erro ao baixar uma imagem GIF usada para um favicon, o resto da página aguardará enquanto esse problema for resolvido.[14][15][16][17][18]

Como o sistema TCP foi projetado para se parecer com um "canal de dados", ou fluxo, ele contém deliberadamente pouco entendimento dos dados que transmite. Se esses dados tiverem requisitos adicionais, como criptografia usando TLS, eles deverão ser configurados por sistemas executando sobre o TCP, usando o TCP para se comunicar com software semelhante na outra ponta da conexão. Cada um desses tipos de tarefas de configuração requer seu próprio processo de handshake. Isso geralmente requer várias viagens de ida e volta até que a conexão seja estabelecida. Devido à latência inerente das comunicações de longa distância, isso pode adicionar uma sobrecarga significativa à transmissão geral.[14][15][16][17][18]

Características[editar | editar código-fonte]

O QUIC tem como objetivo ser quase equivalente a uma conexão TCP, mas com latência muito reduzida. Isso é feito principalmente por meio de duas alterações que dependem da compreensão do comportamento do tráfego HTTP.[14][15][16][17][18]

A primeira alteração é reduzir significativamente a sobrecarga durante a configuração da conexão. Como a maioria das conexões HTTP exigirá TLS, o QUIC torna a troca de chaves de configuração e de protocolos suportados parte do processo inicial de handshake. Quando um cliente abre uma conexão, o pacote de resposta inclui os dados necessários para que pacotes futuros usem criptografia. Isso elimina a necessidade de configurar a conexão TCP e de negociar o protocolo de segurança usando pacotes adicionais. Outros protocolos podem ser atendidos da mesma maneira, combinando várias etapas em uma única solicitação-resposta. Esses dados podem ser usados tanto para as seguintes solicitações na configuração inicial, quanto para solicitações futuras que, de outra forma, seriam negociadas como conexões separadas.[14][15][16][17][18]

O QUIC usa o UDP como base, o que não inclui a recuperação de perdas. Em vez disso, cada fluxo QUIC é controlado separadamente e os dados perdidos são retransmitidos no nível do QUIC, não no UDP. Isso significa que, se ocorrer um erro em um fluxo, como no exemplo de favicon acima, a pilha de protocolos poderá continuar atendendo outros fluxos independentemente. Isso pode ser muito útil para melhorar o desempenho em links suscetíveis a erros, pois na maioria dos casos dados adicionais consideráveis podem ser recebidos antes que o TCP note que um pacote está ausente ou quebrado, e todos esses dados são bloqueados ou mesmo reinicializados enquanto o erro é corrigido. No QUIC, esses dados podem ser processados livremente enquanto o único fluxo multiplexado é reparado.[19]

O QUIC inclui várias outras alterações mais comuns que também melhoram a latência e a taxa de transferência gerais. Por exemplo, os pacotes são criptografados individualmente, para que não resultem em dados criptografados aguardando por pacotes parciais. Isso geralmente não é possível no TCP, onde os registros de criptografia estão em um bytestream e a pilha de protocolos não tem conhecimento dos limites da camada superior nesse fluxo. Eles podem ser negociados pelas camadas executadas no topo, mas o QUIC visa fazer tudo isso em um único processo de handshake.[8]

Outro objetivo do sistema QUIC era melhorar o desempenho durante eventos de comutação de rede, como o que acontece quando um usuário de um dispositivo móvel passa de um ponto de acesso WiFi local para uma rede móvel. Quando isso ocorre no TCP, um processo demorado é iniciado, onde todas as conexões existentes atingem o tempo limite, uma por uma, e são restabelecidas sob demanda. Para resolver esse problema, o QUIC inclui um identificador de conexão que identifica exclusivamente a conexão com o servidor, independentemente da origem. Isso permite que a conexão seja restabelecida simplesmente enviando um pacote, que sempre contém esse ID, pois o ID da conexão original ainda será válido, mesmo que o endereço IP do usuário seja alterado.[20]

O QUIC pode ser implementado no espaço do aplicativo, em vez de estar no núcleo do sistema operacional. Isso geralmente cria sobrecarga adicional devido as trocas de contexto à medida que os dados são movidos entre aplicativos. No entanto, no caso do QUIC, a pilha de protocolos deve ser usada por um único aplicativo, com cada aplicativo usando o QUIC tendo suas próprias conexões hospedadas no UDP. Por fim, a diferença pode ser muito pequena, porque grande parte da pilha HTTP/2 já está nos aplicativos (ou em suas bibliotecas, mais comumente). A colocação das partes restantes nessas bibliotecas, essencialmente a correção de erros, tem pouco efeito no tamanho da pilha HTTP/2 ou na complexidade geral.[8]

Essa organização permite que alterações futuras sejam feitas mais facilmente, pois não requer alterações no núcleo para atualizações. Um dos objetivos de longo prazo do QUIC é adicionar novos sistemas para correção antecipada de erros (FEC) e para controle aprimorado de congestionamento.[20]

Uma preocupação sobre a migração do TCP para o UDP é que o TCP é amplamente adotado e muitas das "caixas intermediárias" na infraestrutura da Internet são otimizadas para TCP e limitam a taxa de transmissão ou até bloqueiam o UDP. O Google realizou uma série de experiências exploratórias para caracterizar isso e descobriu que apenas um pequeno número de conexões foi bloqueado dessa maneira.[3] Isso levou ao uso de um rápido sistema de fallback para TCP; a pilha de rede do Chromium abre uma conexão QUIC e uma conexão TCP tradicional ao mesmo tempo, o que permite o fallback com latência zero.[21]

Google QUIC (gQUIC)[editar | editar código-fonte]

O protocolo que foi criado pelo Google e levado para a IETF sob o nome QUIC (já em 2012 em torno da versão 20 do QUIC) é bem diferente do QUIC que continuou a evoluir e a ser refinado dentro da IETF. O QUIC original do Google foi projetado para ser um protocolo de uso geral, embora tenha sido inicialmente implantado como um protocolo para suportar HTTP(S) no Chromium, enquanto a evolução atual do protocolo IETF QUIC é o protocolo de transporte de uso geral. Os desenvolvedores de Chromium continuaram acompanhando a evolução dos esforços de padronização da IETF QUIC para adotar e cumprir totalmente com os padrões mais recentes da Internet para QUIC no Chromium.

Adoção[editar | editar código-fonte]

Suporte em clientes e navegadores[editar | editar código-fonte]

O código do QUIC foi desenvolvido experimentalmente no Google Chrome a partir de 2012[4] e foi anunciado como parte do Chromium versão 29 (lançada em 20 de agosto de 2013) do Chrome.[13] No momento, está ativado por padrão no Chromium. No navegador Chrome, o suporte experimental ao QUIC pode ser ativado em chrome://flags. Há também uma extensão do navegador para indicar quais páginas são servidas pelo QUIC.

Da mesma forma, ele foi introduzido no Opera 16, pode ser ativado em opera://flags/#enable-quic e opera://flags/#enable-quic-https, e sessões ativas podem ser vistas em opera://net-internals/#quic.

O suporte no Firefox Nightly chegou em novembro de 2019.[22][23]

A biblioteca cronet para QUIC e outros protocolos está disponível para aplicativos do Android como um módulo carregável via Google Play Services.[24]

Curl 7.66, lançado em 11 de setembro de 2019, suporta HTTP/3 (e, portanto, QUIC).[25][26]

Suporte em servidores[editar | editar código-fonte]

Desde 2017, existem três implementações ativamente mantidas. Os servidores do Google oferecem suporte ao QUIC e o Google publicou um protótipo de servidor. Uma implementação em Go chamada quic-go também está disponível, e fornece suporte experimental ao QUIC no servidor Caddy.[27] Em 11 de julho de 2017, a LiteSpeed Technologies começou oficialmente a oferecer suporte ao QUIC em seus produtos balanceador de carga (WebADC) e LiteSpeed Web Server.[28] Desde outubro de 2019, 88,6% dos sites em QUIC usavam o LiteSpeed e 10,8% usavam o Nginx.[29] Embora, inicialmente, apenas os servidores do Google tenham suporte para conexões HTTP-sobre-QUIC, o Facebook também lançou a tecnologia em 2018,[13] e a Cloudflare oferece suporte a QUIC em versão beta desde 2018.[30] Em abril de 2020, 4,2% de todos os sites usam QUIC.[31]

Além disso, existem vários projetos antigos da comunidade: libquic foi criado extraindo a implementação do QUIC no Chromium e modificando-a para minimizar os requisitos de dependências, e a goquic fornece ligações em Go da libquic. Por fim, quic-reverse-proxy é uma imagem para o Docker que atua como um servidor proxy reverso, traduzindo solicitações QUIC em HTTP sem criptografia que pode ser entendido pelo servidor de origem.

Código-fonte[editar | editar código-fonte]

As seguintes implementações de QUIC ou gQUIC estão disponíveis no formato código-fonte:
Implementação Linguagem Descrição
Chromium C++ Este é o código-fonte do navegador Web Chrome e a implementação de referência do gQUIC. Ele contém um cliente e servidor gQUIC e QUIC independentes que podem ser usados para teste. Código fonte navegável. Esta versão também é a base do stellite usado pelo LINE e do cronet desenvolvido pela Google.
QUIC Library (mvfst) C++ O mvfst é uma implementação de cliente e de servidor do protocolo IETF QUIC em C ++ desenvolvido pelo Facebook.
LiteSpeed QUIC Library (lsquic) C Esta é a implementação do QUIC e do HTTP/3 usada pelo LiteSpeed Web Server e pelo OpenLiteSpeed.
Quiche Rust Independente do soquete e expõe uma API em C para uso em aplicativos C/C++.
quicly C Esta biblioteca é a implementação do QUIC para o servidor web H2O.
quic-go Go Esta biblioteca fornece suporte ao QUIC no servidor web Caddy. A funcionalidade de cliente também está disponível.
Quinn Rust
Neqo Rust Esta implementação da Mozilla está planejada para ser integrada ao Necko, uma biblioteca de rede usada no navegador web Firefox.
aioquic Python Essa biblioteca possui uma API sem E/S apropriada para incorporação em clientes e em servidores.
picoquic C Uma implementação mínima do QUIC alinhada com as especificações do IETF.
pquic C Uma implementação do QUIC extensível que inclui uma máquina virtual eBPF capaz de carregar dinamicamente extensões como plugins.
MsQuic C Uma implementação do QUIC multiplataforma da Microsoft projetada para ser uma biblioteca QUIC de uso geral.

Ver também[editar | editar código-fonte]

Referências

  1. a b Nathan Willis. «Connecting on the QUIC». Linux Weekly News. Consultado em 27 de abril de 2020 
  2. a b «QUIC: A UDP-Based Multiplexed and Secure Transport». IETF 
  3. a b c «QUIC: Design Document and Specification Rationale». Jim Roskind, Chromium Contributor 
  4. a b «First Chromium Code Landing: CL 11125002: Add QuicFramer and friends.». Consultado em 27 de abril de 2020 
  5. «Experimenting with QUIC». Chromium Official Blog. Consultado em 27 de abril de 2020 
  6. «QUIC, Google wants to make the web faster». François Beaufort, Chromium Evangelist 
  7. «QUIC: next generation multiplexed transport over UDP». YouTube. Consultado em 27 de abril de 2020 
  8. a b c d «QUIC: IETF-88 TSV Area Presentation» (PDF). Jim Roskind, Google. Consultado em 27 de abril de 2020 
  9. a b Lardinois, Frederic. «Google Wants To Speed Up The Web With Its QUIC Protocol». TechCrunch. Consultado em 27 de abril de 2020 
  10. «Google Will Propose QUIC As IETF Standard». InfoQ. Consultado em 27 de abril de 2020 
  11. «I-D Action: draft-tsvwg-quic-protocol-00.txt». i-d-announce (Lista de grupo de correio). 17 de junho de 2015 
  12. «QUIC - IETF Working Group». datatracker.ietf.org. Consultado em 27 de abril de 2020 
  13. a b c Cimpanu, Catalin (12 de novembro de 2018). «HTTP-over-QUIC to be renamed HTTP/3». ZDNet 
  14. a b c d e f Bright, Peter (12 de novembro de 2018). «The next version of HTTP won't be using TCP». Arstechnica 
  15. a b c d e f Paulo Higa (27 de setembro de 2019). «HTTP/3 está chegando para tornar sua internet mais rápida e segura». Tecnoblog. Consultado em 18 de maio de 2020 
  16. a b c d e f Claudio Yuge (27 de setembro de 2019). «HTTP/3 promete web mais rápida e já tem suporte do Chrome, Firefox e Cloudflare». Canaltech. Consultado em 18 de maio de 2020 
  17. a b c d e f Pedro Pinto (13 de novembro de 2018). «HTTP/3 já está a caminho da Internet e deixará o protocolo TCP de fora». Pplware. Consultado em 18 de maio de 2020 
  18. a b c d e f Tonino Jankov (29 de abril de 2019). «O Que É HTTP/3 – A Verdade Sobre o Novo Protocolo Baseado em UDP». Blog Kinsta. Consultado em 18 de maio de 2020 
  19. Behr, Michael; Swett, Ian. «Introducing QUIC support for HTTPS load balancing». Google Cloud Platform Blog. Consultado em 18 de maio de 2020 
  20. a b «QUIC at 10,000 feet». Chromium 
  21. «Applicability of the QUIC Transport Protocol». IETF Network Working Group. 22 de outubro de 2018 
  22. Stenberg, Daniel. «Daniel Stenberg announces HTTP/3 support in Firefox Nightly». Twitter. Consultado em 1 de maio de 2020 
  23. Cimpanu, Catalin (26 de setembro de 2019). «Cloudflare, Google Chrome, and Firefox add HTTP/3 support». ZDNet. Consultado em 1 de maio de 2020 
  24. «Perform network operations using Cronet». Android Developers. Consultado em 1 de maio de 2020 
  25. «curl - Changes». curl.haxx.se. Consultado em 1 de maio de 2020 
  26. «curl 7.66.0 – the parallel HTTP/3 future is here | daniel.haxx.se». Consultado em 1 de maio de 2020 
  27. «QUIC support in Caddy». Consultado em 1 de maio de 2020 
  28. «LiteSpeed Technologies QUIC Blog Post». Consultado em 1 de maio de 2020 
  29. «Distribution of web servers among websites that use QUIC» 
  30. «Get a head start with QUIC». 25 de setembro de 2018. Consultado em 1 de maio de 2020 
  31. «Usage statistics of QUIC for websites» 

Ligações externas[editar | editar código-fonte]