Al meer dan 20 jaar bekijken we webpagina's met behulp van het HTTP-protocol. De meeste gebruikers denken niet eens na over wat het is en hoe het werkt. Anderen weten dat er ergens onder HTTP TLS zit, en daaronder TCP, waaronder IP, enzovoort. En weer anderen – ketters – geloven dat TCP tot het verleden behoort; zij willen iets dat sneller, betrouwbaarder en veiliger is. Maar in hun pogingen om een nieuw ideaal protocol te bedenken, zijn ze teruggekeerd naar de technologie van de jaren 80 en proberen ze hun dappere nieuwe wereld daarop te bouwen.
Немного истории: HTTP/1.1
In 1997 kreeg het tekstinformatie-uitwisselingsprotocol HTTP versie 1.1 zijn eigen RFC. Destijds werd het protocol al enkele jaren door browsers gebruikt en de nieuwe standaard duurde nog eens vijftien jaar. Het protocol werkte alleen volgens het request-response-principe en was vooral bedoeld voor de overdracht van tekstinformatie.
HTTP is ontworpen om bovenop het TCP-protocol te draaien en ervoor te zorgen dat pakketten betrouwbaar op hun bestemming worden afgeleverd. TCP werkt door het tot stand brengen en onderhouden van een betrouwbare verbinding tussen eindpunten en het opdelen van verkeer in segmenten. Segmenten hebben hun eigen serienummer en controlesom. Als plotseling een van de segmenten niet arriveert of arriveert met een onjuiste controlesom, stopt de verzending totdat het verloren segment is hersteld.
In HTTP/1.0 werd de TCP-verbinding na elk verzoek gesloten. Dit was uiterst verspillend, omdat... Het tot stand brengen van een TCP-verbinding (3-Way-Handshake) is een langzaam proces. HTTP/1.1 introduceerde het keep-alive-mechanisme, waarmee u één verbinding voor meerdere verzoeken kunt hergebruiken. Omdat het echter gemakkelijk een knelpunt kan worden, maken verschillende implementaties van HTTP/1.1 het mogelijk dat meerdere TCP-verbindingen met dezelfde host worden geopend. Chrome en recente versies van Firefox staan bijvoorbeeld maximaal zes verbindingen toe.
Encryptie moest ook aan andere protocollen worden overgelaten, en hiervoor werd het TLS-protocol via TCP gebruikt, dat de gegevens betrouwbaar beschermde, maar de tijd die nodig was om een verbinding tot stand te brengen verder verlengde. Als gevolg hiervan begon het handdrukproces er als volgt uit te zien:
Wolkenflare illustratie
HTTP/1.1 kende dus een aantal problemen:
- Trage verbindingsopbouw.
- Gegevens worden in tekstvorm verzonden, wat betekent dat de overdracht van afbeeldingen, video's en andere niet-tekstuele informatie niet effectief is.
- Voor één verzoek wordt één TCP-verbinding gebruikt, wat betekent dat andere verzoeken een andere verbinding moeten vinden of moeten wachten totdat het huidige verzoek deze vrijgeeft.
- Alleen het pull-model wordt ondersteund. Er staat niets in de standaard over server-push.
- Koppen worden in tekst verzonden.
Als server-push op zijn minst wordt geïmplementeerd met behulp van het WebSocket-protocol, dan moesten de resterende problemen radicaler worden aangepakt.
Een beetje moderniteit: HTTP/2
In 2012 begon Google te werken aan het SPDY-protocol (uitgesproken als ‘speedy’). Het protocol is ontworpen om de belangrijkste problemen van HTTP/1.1 op te lossen en tegelijkertijd de achterwaartse compatibiliteit te behouden. In 2015 introduceerde de IETF-werkgroep de HTTP/2-specificatie op basis van het SPDY-protocol. Hier zijn de verschillen in HTTP/2:
- Binaire serialisatie.
- Multiplexing van meerdere HTTP-verzoeken in één enkele TCP-verbinding.
- Server-push-out-of-the-box (zonder WebSocket).
Het protocol was een grote stap voorwaarts. Hij sterk и не требует создания нескольких TCP-соединений: все запросы к одному хосту мультиплексируются в одно. То есть в одном соединении есть несколько так называемых стримов, каждый из которых имеет свой ID. Бонусом идет коробочный server-push.
Multiplexing leidt echter tot een ander belangrijk probleem. Stel je voor dat we asynchroon 5 verzoeken naar één server uitvoeren. Bij gebruik van HTTP/2 worden al deze verzoeken binnen dezelfde TCP-verbinding uitgevoerd, wat betekent dat als een van de segmenten van een verzoek verloren gaat of onjuist wordt ontvangen, de verzending van alle verzoeken en antwoorden stopt totdat het verloren segment is teruggevonden. hersteld. Het is duidelijk dat hoe slechter de verbindingskwaliteit is, hoe langzamer HTTP/2 werkt. In omstandigheden waarin verloren pakketten 2% van alle pakketten uitmaken, presteert HTTP/1.1 in de browser beter dan HTTP/2, omdat er zes verbindingen worden geopend in plaats van één.
Эта проблема называется «head-of-line blocking» и, к сожалению, решить её при использовании TCP не представляется возможным.
Illustratie door Daniel Steinberg
Als gevolg hiervan hebben de ontwikkelaars van de HTTP/2-standaard uitstekend werk geleverd en bijna alles gedaan wat mogelijk was op de applicatielaag van het OSI-model. Het is tijd om naar de transportlaag te gaan en een nieuw transportprotocol uit te vinden.
We hebben een nieuw protocol nodig: UDP versus TCP
Al snel werd duidelijk dat het implementeren van een compleet nieuw transportlaagprotocol in de huidige realiteit een onmogelijke opgave is. Feit is dat hardware of middle-boxes (routers, firewalls, NAT-servers...) op de hoogte zijn van de transportlaag, en hen iets nieuws leren is een uiterst moeilijke taak. Bovendien is ondersteuning voor transportprotocollen ingebouwd in de kernel van besturingssystemen, en kernels zijn ook niet erg bereid om te veranderen.
En hier zou je je handen kunnen opsteken en zeggen: “We zullen natuurlijk een nieuwe HTTP/3 uitvinden met voorkeur en courtisanes, maar het zal 10-15 jaar duren voordat deze geïmplementeerd is (na ongeveer deze tijd zal de meeste hardware vervangen)”, maar er is er nog één die dat niet doet. De voor de hand liggende optie is om het UDP-protocol te gebruiken. Ja, ja, hetzelfde protocol dat we eind jaren negentig en begin jaren XNUMX gebruikten om bestanden via LAN te versturen. Bijna alle hedendaagse hardware kan ermee overweg.
Wat zijn de voordelen van UDP ten opzichte van TCP? Allereerst hebben we geen transportlaagsessie waarvan de hardware op de hoogte is. Hierdoor kunnen wij zelf de sessie op de eindpunten bepalen en daar conflicten oplossen. Dat wil zeggen dat we niet beperkt zijn tot één of meerdere sessies (zoals in TCP), maar er zoveel kunnen creëren als we nodig hebben. Ten tweede is de gegevensoverdracht via UDP sneller dan via TCP. In theorie kunnen we dus het huidige snelheidsplafond van HTTP/2 doorbreken.
Однако UDP не гарантирует надёжность передачи данных. Фактически мы просто посылаем пакеты, надеясь, что на другом конце их получат. Не получили? Ну не повезло… Этого было достаточно для передачи видео для взрослых, но для более серьёзных вещей нужна надёжность, а значит придётся накрутить что-то ещё поверх UDP.
Как и в случае с HTTP/2, работа по созданию нового протокола началась в Google в 2012-м году, то есть примерно в одно время с началом работы над SPDY. В 2013-м Джим Роскинд представил широкой общественности , en al in 2015 werd de Internet Draft geïntroduceerd voor standaardisatie in de IETF. Al in die tijd verschilde het door Roskind bij Google ontwikkelde protocol sterk van de standaard, dus de Google-versie begon gQUIC te heten.
Wat is QUIC
Ten eerste is dit, zoals reeds vermeld, een wrapper over UDP. Bovenop UDP komt een QUIC-verbinding, waarin naar analogie met HTTP/2 meerdere streams kunnen bestaan. Deze stromen bestaan alleen op de eindpunten en worden onafhankelijk bediend. Als er pakketverlies optreedt in één stream, heeft dit geen invloed op andere streams.
Illustratie door Daniel Steinberg
Ten tweede wordt encryptie niet meer op een apart niveau geïmplementeerd, maar opgenomen in het protocol. Hierdoor kunt u een verbinding tot stand brengen en openbare sleutels uitwisselen in één enkele handshake, en kunt u ook het slimme 0-RTT handshake-mechanisme gebruiken en handshake-vertragingen helemaal vermijden. Bovendien is het nu mogelijk om individuele datapakketten te versleutelen. Hierdoor kunt u niet wachten op de voltooiing van het ontvangen van gegevens uit de stream, maar kunt u de ontvangen pakketten onafhankelijk decoderen. Deze werkingsmodus was over het algemeen onmogelijk in TCP, omdat TLS en TCP werkten onafhankelijk van elkaar, en TLS kon niet weten in welke stukken TCP-gegevens zouden worden gehakt. En daarom kon hij zijn segmenten niet zo voorbereiden dat ze één op één in TCP-segmenten pasten en onafhankelijk konden worden gedecodeerd. Door al deze verbeteringen kan QUIC de latentie verminderen in vergelijking met TCP.
Ten derde kunt u met het concept van lichtstreaming de verbinding loskoppelen van het IP-adres van de client. Dit is bijvoorbeeld belangrijk wanneer een client van het ene Wi-Fi-toegangspunt naar het andere overschakelt en daarbij het IP-adres wijzigt. In dit geval vindt er bij het gebruik van TCP een langdurig proces plaats waarbij bestaande TCP-verbindingen een time-out krijgen en nieuwe verbindingen worden gemaakt vanaf een nieuw IP-adres. In het geval van QUIC blijft de client eenvoudigweg pakketten naar de server sturen vanaf een nieuw IP-adres met de oude stream-ID. Omdat De stream-ID is nu uniek en wordt niet hergebruikt; de server begrijpt dat de client het IP-adres heeft gewijzigd, verzendt verloren pakketten opnieuw en zet de communicatie voort op het nieuwe adres.
Ten vierde wordt QUIC geïmplementeerd op applicatieniveau, niet op besturingssysteemniveau. Hierdoor kunt u enerzijds snel wijzigingen in het protocol aanbrengen, omdat Om een update te krijgen, hoeft u alleen maar de bibliotheek bij te werken, in plaats van te wachten op een nieuwe versie van het besturingssysteem. Aan de andere kant leidt dit tot een sterke toename van het processorverbruik.
Ну и напоследок, заголовки. Компрессия заголовков как раз относится к моментам, которые отличаются в QUIC и gQUIC. Не вижу смысла посвящать этому много времени, скажу только, что в версии, поданной на стандартизацию, компрессию заголовков сделали максимально похожей на компрессию заголовков в HTTP/2. Подробнее можно прочитать .
Hoeveel sneller is het?
Это сложный вопрос. Дело в том, что пока у нас нет стандарта, особо нечего измерять. Пожалуй, единственные статистические данные, которыми мы располагаем – статистика Гугла, который использует gQUIC с 2013 года и в 2016 dat ongeveer 90% van het verkeer dat vanuit de Chrome-browser naar hun servers gaat nu QUIC gebruikt. In dezelfde presentatie melden ze dat pagina's ongeveer 5% sneller laden via gQUIC en dat er 30% minder haperingen zijn bij videostreaming vergeleken met TCP.
In 2017 publiceerde een groep onderzoekers onder leiding van Arash Molavi Kakhki om de prestaties van gQUIC te bestuderen in vergelijking met TCP.
Het onderzoek bracht verschillende zwakke punten van gQUIC aan het licht, zoals instabiliteit bij het mixen van netwerkpakketten, hebzucht (oneerlijkheid) om bandbreedte te kanaliseren en langzamere overdracht van kleine (tot 10 kb) objecten. Dit laatste kan echter gecompenseerd worden door gebruik te maken van 0-RTT. In alle andere onderzochte gevallen vertoonde gQUIC een snelheidsverhoging vergeleken met TCP. Het is moeilijk om hier over specifieke cijfers te praten. Beter lezen of .
Hier moet gezegd worden dat deze gegevens specifiek over gQUIC gaan en niet relevant zijn voor de standaard die wordt ontwikkeld. Wat er gaat gebeuren met QUIC: het is nog steeds een geheim, maar er is hoop dat de zwakke punten die in gQUIC zijn geïdentificeerd in aanmerking zullen worden genomen en gecorrigeerd.
Een stukje toekomst: hoe zit het met HTTP/3?
Maar hier is alles glashelder: de API zal op geen enkele manier veranderen. Alles blijft precies hetzelfde als in HTTP/2. Als de API hetzelfde blijft, zal de overgang naar HTTP/3 opgelost moeten worden door een nieuwe versie van de bibliotheek op de backend te gebruiken die QUIC-transport ondersteunt. Het is waar dat je de terugval op oude versies van HTTP nog geruime tijd zult moeten behouden, omdat Het internet is momenteel niet klaar voor een volledige transitie naar UDP.
Wie steunt al
Hier существующих реализаций QUIC. Несмотря на отсутствие стандарта, список неплохой.
Momenteel ondersteunt geen enkele browser QUIC in een productierelease. Onlangs was er informatie dat ondersteuning voor HTTP/3 in Chrome was opgenomen, maar tot nu toe alleen in Canary.
Van de backends ondersteunt HTTP/3 alleen и , maar nog steeds experimenteel. NGINX eind voorjaar 2019 , что начали работу над поддержкой HTTP/3, но пока не закончили.
Wat zijn de problemen?
Jij en ik leven in de echte wereld, waar geen enkele grote technologie de massa kan bereiken zonder op weerstand te stuiten, en QUIC is daarop geen uitzondering.
Het belangrijkste is dat je op de een of andere manier aan de browser moet uitleggen dat “https://” niet langer een feit is en naar TCP-poort 443 leidt. Mogelijk is er helemaal geen TCP. Hiervoor wordt de Alt-Svc-header gebruikt. Hiermee kunt u de browser vertellen dat deze website ook beschikbaar is op dat en dat protocol op dat en dat adres. In theorie zou dit als een tierelier moeten werken, maar in de praktijk zullen we tegenkomen dat UDP bijvoorbeeld verboden kan worden op een firewall om DDoS-aanvallen te voorkomen.
Maar zelfs als UDP niet verboden is, kan het zijn dat de client zich achter een NAT-router bevindt die is geconfigureerd om een TCP-sessie op IP-adres te houden. we gebruiken UDP, dat geen hardwaresessie heeft, NAT houdt de verbinding niet vast, en een QUIC-sessie .
Al deze problemen zijn te wijten aan het feit dat UDP nog niet eerder werd gebruikt om internetinhoud te verzenden, en hardwarefabrikanten konden niet voorzien dat dit ooit zou gebeuren. Op dezelfde manier begrijpen beheerders nog niet echt hoe ze hun netwerken correct moeten configureren zodat QUIC werkt. Deze situatie zal geleidelijk veranderen, en in ieder geval zullen dergelijke veranderingen minder tijd vergen dan de implementatie van een nieuw transportlaagprotocol.
Bovendien verhoogt QUIC, zoals reeds beschreven, het CPU-gebruik aanzienlijk. Daniël Stenberg processorgroei tot drie keer.
Wanneer komt HTTP/3?
Standaard mei 2020, maar gezien het feit dat de documenten die gepland zijn voor juli 2019 op dit moment nog niet af zijn, kunnen we zeggen dat de datum hoogstwaarschijnlijk zal worden uitgesteld.
Welnu, Google gebruikt zijn gQUIC-implementatie sinds 2013. Als je kijkt naar het HTTP-verzoek dat naar de Google-zoekmachine wordt verzonden, zie je dit:
Bevindingen
QUIC ziet er nu uit als een nogal ruwe, maar veelbelovende technologie. Gezien het feit dat de afgelopen twintig jaar alle optimalisaties van transportlaagprotocollen voornamelijk TCP betroffen, ziet QUIC, dat in de meeste gevallen de beste prestaties levert, er al buitengewoon goed uit.
Er zijn echter nog steeds onopgeloste problemen die de komende jaren moeten worden aangepakt. Het proces kan worden uitgesteld vanwege het feit dat er hardware bij betrokken is, die niemand graag updatet, maar toch lijken alle problemen redelijk oplosbaar, en vroeg of laat zullen we allemaal HTTP/3 hebben.
De toekomst ligt net om de hoek!
Bron: www.habr.com