{"id":81847,"date":"2020-05-17T01:42:34","date_gmt":"2020-05-16T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic"},"modified":"2020-05-17T01:42:34","modified_gmt":"2020-05-16T23:42:34","slug":"http-po-udp-ispolzuem-s-polzoj-protokol-quic","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP sobre UDP \u2014 aproveitando o protocolo QUIC","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) \u00e9 um protocolo sobre UDP que suporta todas as funcionalidades do TCP, TLS e HTTP\/2 e resolve a maioria de seus problemas. \u00c9 frequentemente chamado de novo ou \"experimental\", mas j\u00e1 passou h\u00e1 muito tempo da fase de experimento: o desenvolvimento est\u00e1 em andamento h\u00e1 mais de 7 anos. Durante esse tempo, o protocolo n\u00e3o se tornou um padr\u00e3o, mas ainda assim ganhou uma ampla ado\u00e7\u00e3o. Por exemplo, QUIC \u00e9 utilizado para acelerar o tr\u00e1fego e reduzir a lat\u00eancia em redes m\u00f3veis por gigantes como Google e Facebook, e o IETF anunciou seu fork como a base para o padr\u00e3o HTTP\/3 (considerando que o HTTP\/2 utiliza apenas 44,8%<\/a><\/noindex> dos sites).<\/a><\/noindex><\/p>\n

Conceito<\/h2>\n

\nQUIC foi desenvolvido como uma alternativa ao antigo TCP, que foi originalmente projetado para redes com fio com uma baixa taxa de perda. O TCP entrega pacotes em ordem, portanto, quando um pacote \u00e9 perdido, toda a fila (head-of-line blocking<\/a><\/noindex>) \u00e9 interrompida, o que impacta negativamente a qualidade e a estabilidade da conex\u00e3o. Para evitar perdas massivas, as redes celulares fazem uso de grandes buffers, o que, por sua vez, leva a redund\u00e2ncia e rea\u00e7\u00f5es false negative do protocolo (bufferbloat<\/a><\/noindex>). Al\u00e9m disso, o TCP leva muito tempo para estabelecer uma conex\u00e3o: as solicita\u00e7\u00f5es SYN\/ACK e TLS ocorrem separadamente, exigindo tr\u00eas roundtrips em vez de um, como faz o QUIC.<\/p>\n

\"HTTP
\n
\nComo o QUIC combina a substitui\u00e7\u00e3o do TCP e a implementa\u00e7\u00e3o do TLS 1.3, todas as conex\u00f5es s\u00e3o sempre criptografadas, e descriptografar esse tr\u00e1fego n\u00e3o \u00e9 mais f\u00e1cil do que se estivesse passando por HTTPS. Al\u00e9m disso, o QUIC \u00e9 implementado em n\u00edvel aplicativo, pois uma substitui\u00e7\u00e3o completa da pilha TCP levaria uma eternidade.<\/i>.<\/p>\n

Apesar do suporte a multiplexa\u00e7\u00e3o no HTTP\/2, o problema de head-of-line blocking persiste devido \u00e0 necessidade de entregar pacotes em ordem. O QUIC \u00e9 implementado sobre UDP, portanto, n\u00e3o apresenta bloqueios nesse sentido, e para garantir que os pacotes n\u00e3o sejam perdidos irreversivelmente, eles s\u00e3o numerados e podem conter partes de \"vizinhos\", garantindo redund\u00e2ncia. Al\u00e9m disso, o QUIC divide a fila monol\u00edtica em v\u00e1rios streams para diferentes tipos de solicita\u00e7\u00f5es dentro de uma \u00fanica conex\u00e3o. Assim, em caso de perda de um pacote, os problemas podem ocorrer apenas em uma fila (por exemplo, na transmiss\u00e3o de um arquivo espec\u00edfico):<\/p>\n

\"HTTP
\n<\/p>\n

Uso <\/h2>\n

\nInicialmente, o QUIC foi desenvolvido internamente no Google e foi muito adaptado para uso na empresa. Em 2013, ele foi transferido para a IETF para padroniza\u00e7\u00e3o (que ainda est\u00e1 em andamento), e agora qualquer um pode participar do desenvolvimento do protocolo, sugerindo o que lhe falta. O grupo de trabalho da IETF organiza anualmente reuni\u00f5es nas quais um novo padr\u00e3o \u00e9 aprovado e as novidades s\u00e3o discutidas. Esta implementa\u00e7\u00e3o do QUIC \u00e9 considerada a principal e \u00e9 com base nela que o padr\u00e3o HTTP\/3 \u00e9 certificado.<\/p>\n

At\u00e9 agora, n\u00e3o se fala em incluir o HTTP\/3 como protocolo principal, pois ele ainda n\u00e3o est\u00e1 conclu\u00eddo e quase n\u00e3o \u00e9 suportado:<\/p>\n

\"HTTP
\n
\nMas o QUIC pode ser implementado como transporte entre o aplicativo e o servidor, algo que a Uber fez com sucesso:<\/p>\n

\n

Coment\u00e1rio da Uber sobre a implementa\u00e7\u00e3o do QUIC<\/i><\/h3>\n

\nPara integrar com sucesso o QUIC e melhorar o desempenho do aplicativo em condi\u00e7\u00f5es de conex\u00e3o ruim, substitu\u00edmos a pilha antiga (HTTP\/2 sobre TLS\/TCP) pelo protocolo QUIC. Utilizamos a biblioteca de rede Cronet<\/a><\/noindex> do Chromium Projects<\/a><\/noindex>, que cont\u00e9m a vers\u00e3o original do protocolo desenvolvida pelo Google \u2013 gQUIC. Esta implementa\u00e7\u00e3o tamb\u00e9m est\u00e1 sempre sendo aprimorada para seguir a \u00faltima especifica\u00e7\u00e3o da IETF.<\/p>\n

Primeiro, integramos o Cronet em nossos aplicativos Android para adicionar suporte ao QUIC. A integra\u00e7\u00e3o foi feita de tal forma a minimizar os custos de migra\u00e7\u00e3o. Em vez de substituir completamente a pilha de rede antiga, que usava a biblioteca OkHttp<\/a><\/noindex>, integramos o Cronet SOB o framework OkHttp API. Ao realizar a integra\u00e7\u00e3o dessa forma, evitamos mudan\u00e7as em nossas chamadas de rede (que usam Retrofit<\/a><\/noindex>) no n\u00edvel da API.<\/p>\n

Semelhante \u00e0 abordagem em dispositivos Android, implementamos o Cronet em aplicativos da Uber para iOS, interceptando o tr\u00e1fego HTTP das redes API<\/a><\/noindex>, usando NSURLProtocol<\/a><\/noindex>. Esta abstra\u00e7\u00e3o, fornecida pela iOS Foundation, lida com dados de URL espec\u00edficos do protocolo e garante que possamos integrar o Cronet em nossos aplicativos iOS sem custos de migra\u00e7\u00e3o significativos.<\/p><\/blockquote>\n

retirado de esta tradu\u00e7\u00e3o<\/a><\/noindex> do artigo da Uber<\/i><\/p>\n

No backend, eles capturavam conex\u00f5es QUIC atrav\u00e9s do Google Cloud lb, que suporta o protocolo<\/a><\/noindex> desde meados de 2018.<\/p>\n

N\u00e3o \u00e9 surpreendente que o Google Cloud funcione perfeitamente com um protocolo desenvolvido pelo Google, mas quais s\u00e3o as alternativas?<\/p>\n

Nginx<\/h3>\n

\nN\u00e3o muito tempo atr\u00e1s, a CloudFlare tentou cruzar<\/a><\/noindex> nginx (que por padr\u00e3o n\u00e3o suporta HTTP\/3) com sua ferramenta Quiche. A implementa\u00e7\u00e3o est\u00e1 dispon\u00edvel como um \u00fanico arquivo .patch, que vem com um tutorial de instala\u00e7\u00e3o:<\/p>\n

curl -O https:\/\/nginx.org\/download\/nginx-1.16.1.tar.gz\ntar xvzf nginx-1.16.1.tar.gz\ngit clone --recursive https:\/\/github.com\/cloudflare\/quiche\ncd nginx-1.16.1\npatch -p01 < ..\/quiche\/extras\/nginx\/nginx-1.16.patch<\/code><\/pre>\n
\nAqui voc\u00ea pode adicionar seus m\u00f3dulos, se necess\u00e1rio<\/p>\n
.\/configure                          \t\n   \t--prefix=$PWD                       \t\n   \t--with-http_ssl_module              \t\n   \t--with-http_v2_module               \t\n   \t--with-http_v3_module               \t\n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nResta apenas habilitar o suporte ao HTTP\/3<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Ativar QUIC e HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Ativar HTTP\/2 (opcional).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Ativar todas as vers\u00f5es TLS (TLSv1.3 \u00e9 necess\u00e1ria para QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # O buffering de solicita\u00e7\u00e3o n\u00e3o \u00e9 atualmente suportado para HTTP\/3.\n        proxy_request_buffering off;\n\n        # Adicionar cabe\u00e7alho Alt-Svc para negociar HTTP\/3.\n        add_header alt-svc 'h3-27=\"443\"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nComum em navegadores, n\u00e3o ser\u00e1 poss\u00edvel se conectar via HTTP\/3 por enquanto, mas voc\u00ea pode usar Chrome Canary<\/a><\/noindex> e execut\u00e1-lo com a flag --enable-quic<\/code>, conectando-se ao seu servidor ou, por exemplo, ao site quic.rocks e verificar o tipo de conex\u00e3o nas Ferramentas de Desenvolvedor:
\n\"HTTP
\nEm vez de HTTP\/3, aparece http2+quic\/99<\/code>, mas na verdade \u00e9 a mesma coisa.<\/p>\n
Outras tecnologias<\/h3>\n
<\/p>\n