HTTP přes UDP — využijme protokol QUIC

QUIC (Rychlé UDP Internetové připojení) je protokol nad UDP, který podporuje všechny funkce TCP, TLS a HTTP/2 a řeší většinu jejich problémů. Často je nazýván novým nebo "experimentálním" protokolem, ale již dlouho překročil fázi experimentu: vývoj trvá více než 7 let. Během této doby protokol se sice nestal standardem, ale přesto získal široké rozšíření. Například QUIC používají k urychlení provozu a snížení latence v mobilních sítích takoví giganti jako Google a Facebook, zatímco IETF vyhlásila jeho fork základem pro standard HTTP/3 (během toho, co HTTP/2 využívá pouze 44,8% stránek).

Koncept

QUIC byl vyvinut jako náhrada zastaralého TCP, které bylo původně navrženo pro drátové sítě s nízkým procentem ztrát. TCP doručuje pakety v určitém pořadí, takže při ztrátě jednoho paketu se celá fronta zastaví (blokování na začátku řady), což negativně ovlivňuje kvalitu a stabilitu připojení. Aby se předešlo masivním ztrátám, mobilní sítě používají velké buffery, což na druhé straně vede k nadbytečnosti a falešně negativní reakci protokolu (bufferbloat). Kromě toho TCP spotřebovává velmi mnoho času na navázání spojení: SYN/ACK a TLS požadavky jdou odděleně, což vyžaduje tři roundtripy místo jednoho, jak to dělá QUIC.

Jelikož QUIC kombinuje nahrazení TCP s implementací TLS 1.3, všechna spojení jsou vždy šifrována, dešifrovat takový provoz není snazší než kdyby probíhal přes HTTPS. Kromě toho je QUIC implementován na aplikační úrovni, protože kompletní náhrada TCP stacku by zabrala věčnost..

I přes podporu multiplexování v HTTP/2 zůstává problém blokování na začátku řady kvůli nutnosti doručovat pakety ve správném pořadí. QUIC je implementován nad UDP, takže se blokování vlastně nevyskytuje, a aby pakety nebyly ztraceny bez návratu, jsou očíslovány a mohou obsahovat části "sousedů", čímž zajišťují nadbytečnost. Kromě toho QUIC rozbíjí monolitickou frontu na několik proudů pro různé typy požadavků uvnitř jednoho připojení. Tím pádem, při ztrátě paketu, mohou problémy nastat pouze u jedné fronty (například při přenosu konkrétního souboru):

Použití

Původně byl QUIC vyvinut uvnitř společnosti Google a byl přizpůsoben především pro interní použití. V roce 2013 byl předán IETF k standardizaci (která stále probíhá) a nyní se může každý zapojit do vývoje protokolu a navrhnout, co mu právě chybí. Pracovní skupina IETF každoročně organizuje setkání, během nichž je schvalován nový standard a diskutují se novinky. Tato implementace QUIC je považována za hlavní a právě na jejím základě je certifikován standard HTTP/3.

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

QUIC však může být realizován jako přenos mezi aplikací a serverem, což úspěšně provedli v Uberu:

Komentář Uber ohledně implementace QUIC

Abychom úspěšně integrovali QUIC a zlepšili výkon aplikace za špatných podmínek připojení, nahradili jsme starou technologii (HTTP/2 nad TLS/TCP) protokolem QUIC. Využili jsme síťovou knihovnu Cronet z Chromium Projects, která obsahuje originální verzi protokolu – gQUIC. Tato implementace je také neustále vylepšována, aby odpovídala posledním specifikacím IETF.

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

Podobně jako u přístupu k zařízení Android jsme implementovali Cronet do aplikací Uber na iOS tím, že jsme zachytávali HTTP provoz ze síťových API, pomocí NSURLProtocol. Tato abstrakce poskytnutá iOS Foundation zpracovává specifická URL pro protokoly a zajišťuje, že můžeme integrovat Cronet do našich aplikací pro iOS bez významných nákladů na migraci.

čerpáno z tohoto překladu článku Uber

Na backendu zachytávali QUIC spojení přes Google Cloud lb, který podporuje protokol od poloviny roku 2018.

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

Nginx

Nedávno se CloudFlare pokoušel zkombinovat nginx (který výchozí nastavení neumožňuje HTTP/3) s nástrojem Quiche. Implementace je k dispozici jako jediný .patch soubor, k němuž je přiložen tutoriál k instalaci:

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

Nyní zbývá pouze zapnout podporu HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Aktivujte QUIC a HTTP/3.
        listen 443 quic reuseport;

        # Aktivujte HTTP/2 (volitelné).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Aktivujte všechny verze TLS (TLSv1.3 je požadováno pro QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Buffering požadavků není v současnosti podporováno pro HTTP/3.
        proxy_request_buffering off;

        # Přidejte záhlaví Alt-Svc pro jednání o HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

V běžných prohlížečích zatím nebude možné se připojit přes HTTP/3, ale můžete vzít Chrome Canary a spustit jej s příznakem --enable-quic, obrátit se na svůj server nebo například na stránku quic.rocks a zkontrolovat typ připojení v Nástrojích pro vývojáře:

Místo HTTP/3 se zobrazí http2+quic/99, ale v podstatě jde o to samé.

Další technologie

• QUIC podporují také LiteSpeed (které se velkolepě připojovaly k Facebooku přes HTTP/3) a progresivní Caddy. Apache zatím neumožňuje, ale práce na tom probíhá plným tempem.
• 21. ledna byla aktualizována návrh standardu pro WebRTC
• Doslova před pár dny Microsoft odhalil kód své implementace msquic, ve které zatím nejsou dostupné všechny funkce ze standardu IETF, ale to už je velký pokrok.

Závěr

Zájem o QUIC je nestálý, ale roste, probíhá práce na jeho standardizaci. Nové implementace protokolu se objevují téměř každý měsíc, a s každým rokem si stále více vývojářů uvědomuje, že budoucnost patří QUIC. Uvažuje se dokonce o zahrnutí protokolu do budoucích verzí TCP zásobníku, což znamená, že dříve nebo později se celý internet přesune na stabilnější a rychlejší připojení.

Už nyní můžete nakonfigurovat QUIC interakci pro svou infrastrukturu nebo dokonce přenášet na prohlížeče — všechny plánují přidat podporu protokolu, a smutná statistika na caniuse se stane veselejší.

Zdroj: habr.com