HTTP via UDP - goed gebruik maken van het QUIC-protocol

QUIC (Quick UDP Internet Connections) is een protocol bovenop UDP dat alle functies van TCP, TLS en HTTP/2 ondersteunt en de meeste van hun problemen oplost. Het wordt vaak een nieuw of ‘experimenteel’ protocol genoemd, maar het heeft de experimentele fase al lang overleefd: de ontwikkeling is al meer dan zeven jaar aan de gang. Gedurende deze tijd slaagde het protocol er niet in een standaard te worden, maar raakte het toch wijdverspreid. QUIC wordt bijvoorbeeld gebruikt door giganten als Google en Facebook om het verkeer te versnellen en vertragingen in mobiele netwerken te verminderen, en de IETF heeft zijn fork van het protocol uitgeroepen tot basis voor de HTTP/7-standaard (ook al gebruikt HTTP/3 slechts 44.8% sites).

Concept

QUIC is ontwikkeld als vervanging voor het oudere TCP, dat oorspronkelijk was ontworpen voor bekabelde netwerken met laag verlies. TCP levert pakketten op volgorde af, dus als één pakket verloren gaat, wordt de hele wachtrij gestopt (head-of-line blokkering), wat de kwaliteit en stabiliteit van de verbinding negatief beïnvloedt. Om enorme verliezen te voorkomen, nemen mobiele netwerken hun toevlucht tot het gebruik van grote buffers, wat op zijn beurt leidt tot redundantie en vals-negatieve reacties van het protocol (bufferbloat). Bovendien besteedt TCP veel tijd aan het tot stand brengen van een verbinding: SYN/ACK- en TLS-verzoeken worden afzonderlijk verwerkt, waardoor er drie roundtrips nodig zijn in plaats van één, zoals QUIC dat doet.

Omdat QUIC een TCP-vervanging en een implementatie van TLS 1.3 combineert, zijn alle verbindingen altijd gecodeerd en is het ontsleutelen van dergelijk verkeer niet eenvoudiger dan wanneer het via HTTPS zou gaan. Bovendien wordt QUIC op applicatieniveau geïmplementeerd, wat een volledige vervanging van de TCP-stack zou vergen eeuwigheid.

Ondanks ondersteuning voor multiplexing in HTTP/2 bleef het probleem van head-of-line-blokkering bestaan ​​vanwege de noodzaak om pakketten in de juiste volgorde af te leveren. QUIC wordt bovenop UDP geïmplementeerd, dus er is in principe geen blokkering. Om te voorkomen dat pakketten voor altijd verloren gaan, zijn ze genummerd en kunnen ze delen van “buren” bevatten, wat voor redundantie zorgt. Bovendien splitst QUIC de monolithische wachtrij in meerdere threads voor verschillende soorten verzoeken binnen één verbinding. Als een pakket verloren gaat, kunnen er dus slechts voor één wachtrij problemen optreden (bijvoorbeeld voor het overbrengen van een specifiek bestand):

Gebruiken

QUIC is in eerste instantie binnen Google ontwikkeld en grotendeels op maat gemaakt voor gebruik binnen het bedrijf. In 2013 werd het overgedragen aan de IETF voor standaardisatie (wat nog steeds aan de gang is), en nu kan iedereen deelnemen aan de ontwikkeling van het protocol door voor te stellen wat ze missen. De IETF-werkgroep organiseert jaarlijks bijeenkomsten waarin een nieuwe standaard wordt goedgekeurd en innovaties worden besproken. Deze implementatie van QUIC wordt als de belangrijkste beschouwd en op basis daarvan is de HTTP/3-standaard gecertificeerd.

Tot nu toe is er geen sprake van het opnemen van HTTP/3 als hoofdprotocol, omdat het nog niet klaar is en vrijwel niet wordt ondersteund:

Maar QUIC kan worden geïmplementeerd als transport tussen de applicatie en de server, wat bij Uber met succes is gedaan:

Uber's commentaar op de introductie van QUIC

Om QUIC succesvol te integreren en de applicatieprestaties in omgevingen met slechte connectiviteit te verbeteren, hebben we de oude stack (HTTP/2 via TLS/TCP) vervangen door het QUIC-protocol. We gebruikten de netwerkbibliotheek Cronet van Chroomprojecten, dat de originele Google-versie van het protocol bevat: gQUIC. Deze implementatie wordt ook voortdurend verbeterd om de nieuwste IETF-specificatie te volgen.

We hebben Cronet eerst in onze Android-apps geïntegreerd om ondersteuning voor QUIC toe te voegen. De integratie is zo uitgevoerd dat de migratiekosten zoveel mogelijk beperkt werden. In plaats van de oude netwerkstack die de bibliotheek gebruikte volledig te vervangen okHttp, hebben we Cronet ONDER het OkHttp API-framework geïntegreerd. Door de integratie op deze manier uit te voeren, vermeden we wijzigingen in onze netwerkoproepen (die worden gebruikt door retrofit) op API-niveau.

Vergelijkbaar met de aanpak voor Android-apparaten hebben we Cronet geïmplementeerd in Uber-apps op iOS, waarbij we HTTP-verkeer van het netwerk onderscheppen APIgebruik makend van NSURLProtocol. Deze abstractie, geleverd door de iOS Foundation, verwerkt protocolspecifieke URL-gegevens en zorgt ervoor dat we Cronet in onze iOS-applicaties kunnen integreren zonder noemenswaardige migratiekosten.

genomen van deze vertaling Uber-artikelen

Op de backend vingen ze QUIC-verbindingen op via Google Cloud lb, die ondersteunt protocollen sinds medio 2018.

Het is geen verrassing dat Google Cloud uitstekend werkt met het door Google ontwikkelde protocol, maar wat zijn de alternatieven?

Nginx

Nog niet zo lang geleden CloudFlare Ik probeerde over te steken nginx (die standaard geen HTTP/3 ondersteunt) met zijn Quiche-tool. De implementatie is beschikbaar als één enkel .patch-bestand, dat wordt geleverd met een installatiehandleiding:

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

Hier kunt u indien nodig uw modules aansluiten

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

Het enige dat overblijft is het inschakelen van HTTP/3-ondersteuning

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';
    }
}

Het is nog niet mogelijk om in reguliere browsers verbinding te maken via HTTP/3, maar je kunt er wel gebruik van maken Chrome Canary en voer het uit met de vlag --enable-quic, ga naar je server of bijvoorbeeld de site quic.rocks en kijk naar het verbindingstype in Developer Tools:

In plaats van HTTP/3 wordt het geschreven http2+quic/99, maar in essentie is het hetzelfde.

Andere technologieën

• QUIC ondersteunt ook LiteSpeed (die via HTTP/3 met veel tamtam verbonden was met Facebook) en progressief Caddy. Apache kan het nog niet, maar er wordt aan gewerkt volle gang.
• 21 januari bijgewerkt conceptstandaard voor WebRTC
• Onlangs opende Microsoft msquic-implementatiecode, waarin nog niet alle functies uit de IETF-standaard beschikbaar zijn, maar dit is al een grote doorbraak.

Conclusie

De belangstelling voor QUIC is onstabiel, maar groeit, en er wordt gewerkt aan de standaardisering ervan. Bijna elke maand verschijnen er nieuwe implementaties van het protocol, en elk jaar zijn steeds meer ontwikkelaars ervan overtuigd dat QUIC de toekomst is. Het is zelfs mogelijk om het protocol op te nemen in toekomstige versies van de TCP-stack, wat betekent dat vroeg of laat het hele internet zal overgaan op stabielere en snellere verbindingen.

U kunt nu al QUIC-interactie voor uw infrastructuur configureren of deze zelfs aan browsers geven - ze zijn allemaal van plan ondersteuning voor het protocol toe te voegen, en de trieste statistieken met caniuse zullen vrolijker worden.

Bron: www.habr.com