HTTP cez UDP — efektívne používame protokol QUIC

QUIC (Rýchle UDP Internetové Spojenia) je protokol nad UDP, ktorý podporuje všetky funkcie TCP, TLS a HTTP/2 a rieši väčšinu ich problémov. Často sa nazýva novým alebo 'experimentálnym' protokolom, ale už dávno prekonal fázu experimentu: jeho vývoj trvá viac ako 7 rokov. Počas tohto času sa protokol nestal štandardom, ale predsa len získal široké rozšírenie. Napríklad QUIC používajú na zrýchlenie dopravy a zníženie latencie v mobilných sieťach giganti ako Google a Facebook, a IETF vyhlásila jeho fork ako základ pre štandard HTTP/3 (pričom HTTP/2 využíva iba 44,8% webových stránok).

Koncept

QUIC bol vyvinutý ako náhrada zastaraného TCP, ktoré bolo pôvodne navrhnuté pre drôtové siete s nízkym percentom strát. TCP dodáva pakety v poradí, takže pri strate jedného paketu sa zastaví celá rada (problém blokovania na hlave), čo negatívne ovplyvňuje kvalitu a stabilitu pripojenia. Aby sa predišlo masovým stratám, mobilné siete využívajú veľké buffre, čo v konečnom dôsledku vedie k redundantnosti a falošne negatívnej reakcii protokolu (bufferbloat). Okrem toho TCP trávi veľmi veľa času na nadviazanie spojenia: SYN/ACK a TLS požiadavky idú oddelene, čo si vyžaduje tri roundtrip-y namiesto jedného, ako to robí QUIC.

Keďže QUIC kombinuje náhradu TCP a implementáciu TLS 1.3, všetky pripojenia sú vždy šifrované, dekódovanie takého prenosu nie je jednoduchšie, než keby prebiehal cez HTTPS. Okrem toho je QUIC implementovaný na aplikačnej úrovni, pretože úplná náhrada TCP zásobníka by trvala večnosť.

Napriek podpore multiplexovania v HTTP/2 pretrváva problém blokovania na hlave kvôli potrebe dodávať pakety v poradí. QUIC je implementovaný nad UDP, takže v podstate neexistuje blokovanie, a aby pakety nevznikali beznádejne, sú číslované a môžu obsahovať časti „susedov“, čím zabezpečujú redundantnosť. Okrem toho QUIC rozdeľuje monolitickú radu na niekoľko prúdov pre rôzne typy požiadaviek v rámci jedného pripojenia. Tým pádom, pri strate paketu môžu problémy vzniknúť len v jednej rade (napríklad pri prenosu konkrétneho súboru):

Použitie

Pôvodne bol QUIC vyvinutý v rámci Google a bol v mnohom prispôsobený na interné používanie. V roku 2013 bol odovzdaný IETF na štandardizáciu (ktorá trvá dodnes) a teraz sa každý môže zúčastniť na rozvoji protokolu navrhnutím toho, čo mu chýba. Pracovná skupina IETF každoročne organizuje stretnutia, počas ktorých sa schvaľuje nový štandard a diskutujú sa inovácie. Táto implementácia QUIC sa považuje za hlavnú a práve na jej základe sa certifikuje štandard HTTP/3.

Zatiaľ sa o zahrnutí HTTP/3 ako hlavného protokolu nehovorí, pretože ešte nie je dokončený a takmer nie je podporovaný:

Ale QUIC je možné implementovať ako prepravu medzi aplikáciou a serverom, čo úspešne urobili v Uber:

Komentár Uber o implementácii QUIC

Aby sme úspešne integrovali QUIC a zlepšili výkon aplikácie za podmienok zlého pripojenia, nahradili sme starý stack (HTTP/2 nad TLS/TCP) protokolom QUIC. Zapojili sme sieťovú knižnicu Cronet z Chromium Projects, ktorá obsahuje pôvodnú, Googlovskú verziu protokolu – gQUIC. Táto implementácia sa neustále vylepšuje, aby sledovala najnovšiu špecifikáciu IETF.

Najprv sme integrovali Cronet do našich aplikácií pre Android, aby sme pridali podporu pre QUIC. Integrácia bola realizovaná tak, aby sa minimalizovali náklady na migráciu. Namiesto toho, aby sme úplne nahradili starý sieťový zásobník, ktorý používal knižnicu OkHttp, sme integrovali Cronet POD rámcom OkHttp API. Takouto integráciou sme sa vyhli zmenám v našich sieťových volaniach (ktoré používajú Retrofit) na úrovni API.

Podobne ako pri prístupe k zariadeniam Android, sme implementovali Cronet do aplikácií Uber na iOS, zachytávajúc HTTP prevádzku zo sieťových API, s použitím NSURLProtocol. Táto abstrakcia, poskytnutá iOS Foundation, spracováva protokoly špecifické URL dáta a zabezpečuje, že môžeme integrovať Cronet do našich aplikácií pre iOS bez podstatných nákladov na migráciu.

prebrané z tohto prekladu Článku Uber

Na backendu zachytávali QUIC pripojenia cez Google Cloud lb, ktorý podporuje protokol od polovice roku 2018.

Nie je prekvapením, že Google Cloud skvele funguje s protokolom, ktorý vyvinul Google, ale aké sú alternatívy?

Nginx

Nedávno sa CloudFlare pokusila skombinovať nginx (ktorý predvolene nepodporuje HTTP/3) so svojim nástrojom Quiche. Implementácia je dostupná vo forme jedného .patch súboru, ku ktorému je priložený tutoriál na inštaláciu:

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

Tu je možné pripojiť svoje moduly, ak je to potrebné.

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

Ostaáva už len povoliť podporu HTTP/3.

events {
    worker_connections  1024;
}

http {
    server {
        # Povoľte QUIC a HTTP/3.
        listen 443 quic reuseport;

        # Povoľte HTTP/2 (voliteľné).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Povoľte všetky verzie TLS (TLSv1.3 je potrebné pre QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Požiadavky o vyrovnávanie nie sú v súčasnosti podporované pre HTTP/3.
        proxy_request_buffering off;

        # Pridajte hlavičku Alt-Svc na vyjednávanie HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

V bežných prehliadačoch sa zatiaľ nedá pripojiť cez HTTP/3, ale môžete vziať Chrome Canary a spustiť ho s flagom --enable-quic, obrátiť sa na svoj server alebo napríklad na stránku quic.rocks a skontrolovať typ pripojenia v Developer Tools:

Namiesto HTTP/3 je napísané http2+quic/99, ale to je v podstate to isté.

Iné technológie

• QUIC podporuje aj LiteSpeed (ktoré sa s veľkou pompou pripájali na Facebook cez HTTP/3) a progresívny Caddy. Apache zatiaľ nevie, ale práca pokračuje naplno.
• 21. januára bol aktualizovaný nákres štandardu pre WebRTC
• Len nedávno Microsoft otvoril kód svojej implementácie msquic, kde zatiaľ nie sú dostupné všetky funkcie zo štandardu IETF, ale to už je veľký pokrok.

Záver

Záujem o QUIC je nestabilný, ale rastie, pracuje sa na jeho štandardizácii. Nové implementácie protokolu sa objavujú takmer každý mesiac a s každým rokom si čoraz viac vývojárov uvedomuje, že budúcnosť patrí QUIC. Dokonca sa uvažuje o zahrnutí protokolu do budúcich verzií TCP stacku, čo znamená, že skôr či neskôr celý internet prejde na stabilnejšie a rýchlejšie pripojenia.

Už teraz môžete nastaviť QUIC interakciu pre svoju infraštruktúru alebo dokonca ju poskytnúť prehliadačom — všetky plánujú pridať podporu pre protokol a smutná štatistika z caniuse sa stane veselšou.

Zdroj: habr.com