QUIC (Quick UDP Internet Connections) is een protocol bovenop UDP, dat alle mogelijkheden van TCP, TLS en HTTP/2 ondersteunt en de meeste van hun problemen oplost. Het wordt vaak een nieuw of 'experimenteel' protocol genoemd, maar is al geruime tijd geen experimentele fase meer: de ontwikkeling is al meer dan 7 jaar aan de gang. In die tijd is het protocol nog geen standaard geworden, maar heeft het wel brede verspreiding gevonden. Zo gebruiken giganten als Google en Facebook QUIC om de datastroom te versnellen en vertraging in mobiele netwerken te verminderen, en heeft de IETF zijn fork van het protocol aangekondigd als basis voor de standaard HTTP/3 (terwijl HTTP/2 slechts van de sites gebruikt).
Concept
QUIC is ontwikkeld als vervanging voor het verouderde TCP, dat oorspronkelijk was geoptimaliseerd voor bedrade netwerken met een laag verliespercentage. TCP levert pakketten op volgorde, wat betekent dat bij het verlies van één pakket de hele wachtrij stagneert (), wat een negatieve invloed heeft op de kwaliteit en stabiliteit van de verbinding. Om massaal verlies te voorkomen, gebruiken mobiele netwerken grote buffers, wat op zijn beurt leidt tot overbodigheid en een false negative-reactie van het protocol (). Bovendien kost het TCP veel tijd om verbinding te maken: SYN/ACK- en TLS-verzoeken gaan apart, wat drie roundtrips vereist in plaats van één, zoals QUIC doet.
Aangezien QUIC zowel een vervanging van TCP als een implementatie van TLS 1.3 is, zijn alle verbindingen altijd versleuteld, en het decrypten van zo'n verkeer is niet eenvoudiger dan wanneer het via HTTPS zou verlopen. Daarnaast is QUIC op applicatieniveau geïmplementeerd, terwijl het een volledige vervanging van de TCP-stack enorm veel tijd zou kosten. Ewigigheid.
Ondanks de ondersteuning van multiplexing in HTTP/2, blijft het probleem van head-of-line blocking bestaan door de noodzaak om pakketten in volgorde te leveren. QUIC is bovenop UDP geïmplementeerd, waardoor er in principe geen blokkades zijn; om ervoor te zorgen dat pakketten niet onherroepelijk verloren gaan, worden ze genummerd en kunnen ze onderdelen van "buren" bevatten, wat zorgt voor redundantie. Bovendien verdeelt QUIC de monolithische wachtrij in verschillende stromen voor verschillende typen verzoeken binnen één verbinding. Bij het verlies van een pakket kunnen problemen dus alleen bij één wachtrij optreden (bijvoorbeeld voor de overdracht van een specifiek bestand):
Gebruik van
QUIC werd oorspronkelijk binnen Google ontwikkeld en was in veel opzichten gericht op gebruik binnen het bedrijf. In 2013 is het overgedragen aan de IETF voor standaardisatie (die nog steeds doorgaat), en nu kan iedereen deelnemen aan de ontwikkeling van het protocol door het aan te vullen met wat hij mist. De IETF-werkgroep organiseert jaarlijks bijeenkomsten waarin de nieuwe standaard wordt goedgekeurd en de innovaties worden besproken. Deze implementatie van QUIC wordt als de belangrijkste beschouwd en op basis daarvan wordt de standaard HTTP/3 gecertificeerd.
Momenteel is er nog geen sprake van HTTP/3 als het belangrijkste protocol, omdat het nog niet voltooid is en bijna niet wordt ondersteund:
Maar QUIC kan worden geïmplementeerd als transport tussen de applicatie en de server, wat met succes is gedaan bij Uber:
Uber's opmerking over de implementatie van QUIC
Om QUIC succesvol te integreren en de prestaties van de applicatie onder slechte verbindingen te verbeteren, hebben we de oude stack (HTTP/2 boven TLS/TCP) vervangen door het QUIC-protocol. We hebben de netwerklibrary uit , die de originele, Google-versie van het protocol – gQUIC – bevat. Deze implementatie wordt ook voortdurend verbeterd om de laatste specificatie van de IETF te volgen.
Eerst hebben we Cronet geïntegreerd in onze Android-applicaties om ondersteuning voor QUIC toe te voegen. De integratie is zo uitgevoerd dat de migratiekosten tot een minimum worden beperkt. In plaats van de oude netwerklayer volledig te vervangen, die gebruik maakte van de library , hebben we Cronet geïntegreerd ONDER de OkHttp API-framework. Door de integratie op deze manier uit te voeren, hebben we wijzigingen in onze netwerkoproepen (die gebruik maken van ) op API-niveau vermeden.
Net als bij de aanpak voor Android-apparaten hebben we Cronet geïmplementeerd in de Uber-apps voor iOS, waarbij we HTTP-verkeer onderscheppen vanuit de netwerken , met gebruik van . Deze abstractie, geboden door de iOS Foundation, verwerkt protocol-specifieke URL-gegevens en zorgt ervoor dat we Cronet in onze iOS-applicaties kunnen integreren zonder aanzienlijke migratiekosten.
genomen uit van het Uber-artikel
Aan de achterkant vingen ze QUIC-verbindingen op via Google Cloud lb, die sinds midden 2018.
Het is dan ook geen verrassing dat Google Cloud uitstekend werkt met een protocol dat door Google is ontwikkeld, maar welke alternatieven zijn er?
Nginx
Niet zo lang geleden heeft CloudFlare nginx (dat standaard geen HTTP/3 ondersteunt) met zijn Quiche-tool. De implementatie is beschikbaar als één enkele .patch-bestand, met een installatiehandleiding erbij:
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.patchHier kunnen indien nodig uw eigen modules worden toegevoegd
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeHet enige wat overblijft, is de ondersteuning voor HTTP/3 in te schakelen
events {
worker_connections 1024;
}
http {
server {
# Schakel QUIC en HTTP/3 in.
listen 443 quic reuseport;
# HTTP/2 inschakelen (optioneel).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Schakel alle TLS-versies in (TLSv1.3 is verplicht voor QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Verzoekbuffering wordt momenteel niet ondersteund voor HTTP/3.
proxy_request_buffering off;
# Voeg Alt-Svc header toe om HTTP/3 te onderhandelen.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
} In reguliere browsers is verbinding maken via HTTP/3 nog niet mogelijk, maar u kunt nemen en het starten met de vlag --enable-quic, verbinding maken met uw server of bijvoorbeeld met de website quic.rocks en het type verbinding bekijken in de Developer Tools:
In plaats van HTTP/3 staat er http2+quic/99, maar dat is in feite hetzelfde.
Andere technologieën
- QUIC wordt ook ondersteund door (die met veel fanfare verbinding maakten met Facebook via HTTP/3) en de progressieve . Apache ondersteunt het nog niet, maar het werk gaat .
- Op 21 januari is de
- Kort geleden heeft Microsoft de , waarin nog niet alle functies van de IETF-standaard beschikbaar zijn, maar dit is al een grote doorbraak.
Conclusie
De interesse in QUIC is inconsistent, maar groeit, en er wordt gewerkt aan de standaardisatie ervan. Nieuwe implementaties van het protocol verschijnen bijna elke maand, en elk jaar overtuigen steeds meer ontwikkelaars zich ervan dat de toekomst voor QUIC is. Er wordt zelfs overwogen om het protocol op te nemen in toekomstige versies van de TCP-stack, wat betekent dat op een gegeven moment het hele internet over zal stappen op meer stabiele en snelle verbindingen.
U kunt nu al QUIC-interacties instellen voor uw infrastructuur of zelfs browsers de verbinding laten maken — zij hebben allemaal plannen om de protocollen te ondersteunen, en de treurige statistieken van caniuse zullen vrolijker worden.
Bron: habr.com
