HTTP přes UDP – dobré využití protokolu QUIC

QUIC (Quick UDP Internet Connections) je protokol nad UDP, který podporuje všechny funkce TCP, TLS a HTTP/2 a řeší většinu jejich problémů. Často se mu říká nový nebo „experimentální“ protokol, ale již dávno přežil experimentální fázi: vývoj probíhá již více než 7 let. Během této doby se protokol nestihl stát standardem, ale přesto se rozšířil. QUIC například používají takoví giganti jako Google a Facebook ke zrychlení provozu a snížení zpoždění v mobilních sítích a IETF prohlásila jeho fork protokolu za základ pro standard HTTP/3 (i když HTTP/2 používá pouze 44.8 % stránky).

Koncepce

QUIC byl vyvinut jako náhrada za starší TCP, který byl původně navržen pro nízkoztrátové kabelové sítě. TCP doručuje pakety v pořadí, takže pokud dojde ke ztrátě jednoho paketu, celá fronta se zastaví (blokování hlavy), což negativně ovlivňuje kvalitu a stabilitu spojení. Aby se zabránilo masivním ztrátám, mobilní sítě se uchylují k používání velkých vyrovnávacích pamětí, což zase vede k redundanci a falešně negativní odezvě protokolu (bufferbloat). Kromě toho TCP tráví spoustu času navazováním spojení: požadavky SYN/ACK a TLS jsou zpracovávány odděleně a vyžadují tři zpáteční cesty namísto jednoho, jak to dělá QUIC.

Protože QUIC kombinuje náhradu TCP a implementaci TLS 1.3, všechna připojení jsou vždy šifrována a dešifrování takového provozu není o nic snazší, než kdyby šel přes HTTPS. Navíc je QUIC implementován na aplikační úrovni, protože kompletní výměna TCP stacku by vyžadovala navždy.

Navzdory podpoře multiplexování v HTTP/2 zde zůstal problém s blokováním head-of-line kvůli nutnosti doručovat pakety v pořádku. QUIC je implementován nad UDP, takže v zásadě nemá žádné blokování, a aby se pakety neztratily navždy, jsou očíslovány a mohou obsahovat části „sousedů“, což zajišťuje redundanci. Kromě toho QUIC rozděluje monolitickou frontu do více vláken pro různé typy požadavků v rámci jednoho připojení. Pokud se tedy ztratí paket, mohou nastat problémy pouze pro jednu frontu (například pro přenos konkrétního souboru):

Použití

Zpočátku byl QUIC vyvinut v rámci společnosti Google a byl z velké části přizpůsoben pro použití v rámci společnosti. V roce 2013 byl převeden na IETF ke standardizaci (která stále probíhá) a nyní se každý může podílet na vývoji protokolu tím, že navrhne, co mu chybí. Pracovní skupina IETF pořádá každoroční setkání, na kterých se schvaluje nový standard a diskutuje se o inovacích. Tato implementace QUIC je považována za hlavní a na jejím základě je certifikován standard HTTP/3.

Zatím se nemluví o zařazení HTTP/3 jako hlavního protokolu, protože ještě není dokončen a téměř není podporován:

Ale QUIC lze implementovat jako přenos mezi aplikací a serverem, což bylo úspěšně provedeno v Uberu:

Komentář Uberu k zavedení QUIC

Abychom úspěšně začlenili QUIC a zlepšili výkon aplikací v prostředích se špatnou konektivitou, nahradili jsme starý zásobník (HTTP/2 přes TLS/TCP) protokolem QUIC. Použili jsme síťovou knihovnu Cronet z Projekty Chromium, který obsahuje původní, Google verzi protokolu - gQUIC. Tato implementace je také neustále vylepšována, aby odpovídala nejnovější specifikaci IETF.

Nejprve jsme do našich aplikací pro Android integrovali Cronet, abychom přidali podporu pro QUIC. Integrace byla provedena tak, aby se co nejvíce snížily náklady na migraci. Místo úplného nahrazení starého síťového zásobníku, který používal knihovnu OkHttp, integrovali jsme Cronet POD rámcem API OkHttp. Tím, že jsme provedli integraci tímto způsobem, jsme se vyhnuli změnám našich síťových hovorů (které používají Retrofit) na úrovni API.

Podobně jako u zařízení se systémem Android jsme implementovali Cronet do aplikací Uber na iOS a zachytili jsme HTTP provoz ze sítě APIPoužití NSURLProtocol. Tato abstrakce, kterou poskytuje iOS Foundation, zpracovává data URL specifická pro protokol a zajišťuje, že můžeme integrovat Cronet do našich aplikací pro iOS bez značných nákladů na migraci.

vzáno z tento překlad články o Uberu

Na backendu zachytili připojení QUIC přes Google Cloud lb, což podporuje protokol od poloviny roku 2018.

Není žádným překvapením, že Google Cloud skvěle funguje s protokolem vyvinutým společností Google, ale jaké jsou alternativy?

Nginx

Není to tak dávno CloudFlare Zkusil jsem přejít nginx (který standardně nepodporuje HTTP/3) se svým nástrojem Quiche. Implementace je k dispozici jako jeden soubor .patch, který je dodáván s instalačním tutoriálem:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

Zde můžete v případě potřeby připojit své moduly

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

Zbývá pouze povolit podporu HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

V běžných prohlížečích se zatím nelze připojit přes HTTP/3, ale můžete použít Chrome Canary a spustit to s vlajkou --enable-quic, přejděte na svůj server nebo například web quic.rocks a podívejte se na typ připojení v Nástrojích pro vývojáře:

Místo HTTP/3 se píše http2+quic/99, ale je to v podstatě to samé.

Jiné technologie

• QUIC také podporuje LiteSpeed (který se s velkou pompou připojil k Facebooku přes HTTP/3) a progresivní Krabička. Apache to zatím neumí, ale pracuje se naplno.
• 21. ledna aktualizováno návrh standardu pro WebRTC
• Právě druhý den Microsoft otevřel implementační kód msquic, ve kterém ještě nejsou dostupné všechny funkce ze standardu IETF, ale to už je velký průlom.

Závěr

Zájem o QUIC je nestabilní, ale roste a na jeho standardizaci se pracuje. Nové implementace protokolu se objevují téměř každý měsíc a každým rokem je stále více vývojářů přesvědčeno, že QUIC je budoucnost. Protokol je dokonce možné zahrnout do budoucích verzí TCP stacku, což znamená, že dříve nebo později celý internet přejde na stabilnější a rychlejší připojení.

Již nyní můžete nakonfigurovat interakci QUIC pro vaši infrastrukturu nebo ji dokonce poskytnout prohlížečům - všechny plánují přidat podporu pro protokol a smutné statistiky s caniuse budou veselejší.

Zdroj: www.habr.com