HTTP över UDP — vi använder QUIC-protokollet effektivt

QUIC (Quick UDP Internet Connections) är ett protokoll ovanpå UDP som stödjer alla funktioner hos TCP, TLS och HTTP/2 och löser de flesta av deras problem. Det kallas ofta det nya eller "experimentella" protokollet, men det har länge överlevt experimentfasen: utvecklingen har pågått i över 7 år. Under denna tid har protokollet inte blivit en standard, men har ändå fått bred spridning. Till exempel använder företag som Google och Facebook QUIC för att öka hastigheten på trafik och minska fördröjningar i mobila nätverk, och IETF har deklarerat sin fork-version av protokollet som grunden för standarden HTTP/3 (även om HTTP/2 bara används av 44,8% av webbplatser).

Konceptet

QUIC utvecklades som en ersättning för det föråldrade TCP, som ursprungligen var anpassat för trådbundna nät med låg förlust. TCP levererar paket i ordning, så när ett paket går förlorat stannar hela kön (head-of-line blocking), vilket negativt påverkar kvaliteten och stabiliteten i anslutningen. För att undvika massförluster använder mobila nät stora buffertar, vilket i sin tur leder till överflödighet och falska negativa reaktioner från protokollet (bufferbloat). Dessutom tar TCP väldigt lång tid på sig att etablera en anslutning: SYN/ACK och TLS-förfrågningar skickas separat, vilket kräver tre roundtrip istället för en, som QUIC gör.

Eftersom QUIC kombinerar ersättningen för TCP och implementeringen av TLS 1.3, är alla anslutningar alltid krypterade, och att dekryptera sådan trafik är inte enklare än om den skulle gå över HTTPS. Dessutom har QUIC implementerats på applikationsnivå, eftersom en fullständig ersättning av TCP-stacken skulle ta evigheter.

Trots att HTTP/2 stödjer multiplexering kvarstår problemet med head-of-line blocking där på grund av behovet av att leverera paket i ordning. QUIC implementeras ovanpå UDP, vilket i princip eliminerar blockeringsproblemet, och för att säkerställa att paket inte går förlorade för alltid numreras de och kan innehålla delar av "grannar" för att säkerställa överflödighet. Dessutom delar QUIC upp den monolitiska kön i flera strömmar för olika typer av förfrågningar inom en anslutning. Således kan problem vid paketförlust endast uppstå i en kö (till exempel vid överföring av en specifik fil):

Användning

QUIC utvecklades ursprungligen inom Google och var till stor del anpassad för interna behov. År 2013 överfördes det till IETF för standardisering (som fortfarande pågår), och nu kan alla delta i utvecklingen av protokollet genom att föreslå det som saknas för dem. IETF:s arbetsgrupp anordnar årliga möten där nya standarder godkänns och nya idéer diskuteras. Denna implementation av QUIC anses vara den grundläggande och det är på denna som standarden HTTP/3 certifieras.

För tillfället talas det inte om att inkludera HTTP/3 som huvudprotokoll, eftersom det fortfarande är ofullständigt och nästan inte stöds:

Men QUIC kan implementeras som transport mellan applikationen och servern, vilket har gjorts framgångsrikt av Uber:

Ubers kommentar om implementeringen av QUIC

För att framgångsrikt integrera QUIC och förbättra applikationens prestanda under dåliga anslutningar, bytte vi ut den gamla stacken (HTTP/2 över TLS/TCP) mot protokollet QUIC. Vi använde det nätverksbiblioteket Cronet från Chromium Projects, som innehåller den ursprungliga Google-versionen av protokollet – gQUIC. Denna implementation förbättras också ständigt för att följa den senaste IETF-specifikationen.

Först integrerade vi Cronet i våra Android-appar för att lägga till stöd för QUIC. Integrationen genomfördes på ett sätt som minimerade migrationskostnaderna. Istället för att helt ersätta den gamla nätverksstacken, som använde biblioteket OkHttp, integrerade vi Cronet UNDER OkHttp API-ramverket. Genom att utföra integrationen på detta sätt undvek vi förändringar i våra nätverksanrop (som använder Retrofit) på API-nivå.

På liknande sätt som för Android-enheter implementerade vi Cronet i Uber-apparna på iOS, genom att avlyssna HTTP-trafiken från nätverks API, med hjälp av NSURLProtocol. Denna abstraktion, som tillhandahålls av iOS Foundation, hanterar protokollspecifika URL-data och säkerställer att vi kan integrera Cronet i våra iOS-appar utan betydande migrationskostnader.

tagit från denna översättning artikel från Uber

På backend fångade de QUIC-anslutningar via Google Cloud lb, som stöder protokollet sedan mitten av 2018.

Det är inte förvånande att Google Cloud fungerar utmärkt med protokollet som Google utvecklade, men vilka alternativ finns?

Nginx

Nyligen försökte CloudFlare komma i kontakt med nginx (som som standard inte stödjer HTTP/3) med sitt verktyg Quiche. Implementeringen finns tillgänglig som en enda .patch-fil, som har en installationshandledning bifogad:

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

Här kan man ansluta sina egna moduler vid behov

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

Det återstår bara att aktivera stöd för HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Aktivera QUIC och HTTP/3.
        listen 443 quic reuseport;

        # Aktivera HTTP/2 (valfritt).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Aktivera alla TLS-versioner (TLSv1.3 krävs för QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Begärningsbuffring stöds för närvarande inte för HTTP/3.
        proxy_request_buffering off;

        # Lägg till Alt-Svc-header för att förhandla HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

I vanliga webbläsare går det fortfarande inte att ansluta via HTTP/3, men man kan ta Chrome Canary och köra det med flaggan --enable-quic, besöka sin server eller till exempel sidan quic.rocks och se vilken typ av anslutning som används i Developer Tools:

Istället för HTTP/3 står det http2+quic/99, men det är i stort sett samma sak.

Andra teknologier

• QUIC stöder också LiteSpeed (som i stor stil kopplades till Facebook via HTTP/3) och progressiv Caddy. Apache kan än så länge inte, men arbetet pågår i full gång.
• Den 21 januari uppdaterades utkastet till standard för WebRTC
• Bokstavligen för några dagar sedan släppte Microsoft koden för sin implementation av msquic, där alla funktioner i IETF-standarden ännu inte är tillgängliga, men det är redan ett stort framsteg.

Slutsats

Intresset för QUIC är ostadigt men växer, arbetet med dess standardisering pågår. Nya implementationer av protokollet dyker upp nästan varje månad, och allt fler utvecklare övertygar sig om att framtiden ligger i QUIC. Det är till och med möjligt att inkludera protokollet i framtida versioner av TCP-stacken, vilket innebär att hela internet förr eller senare kommer att övergå till mer stabila och snabba anslutningar.

Redan nu kan du konfigurera QUIC-interaktioner för din infrastruktur eller till och med erbjuda dem till webbläsare - de planerar alla att lägga till stöd för protokollet, och den sorgliga statistiken från caniuse kommer att bli roligare.

Källa: habr.com