In november 2018 kwam de Internet Engineering Task Force (IETF) bijeen in Bangkok en werd een nieuw internet-concept goedgekeurd. Het QUIC-transportprotocol, een HTTP/2-opvolger, werd hernoemd naar HTTP/3. HTTP/3 is gebaseerd op UDP en wordt al gebruikt door vooraanstaande internetbedrijven zoals Google en Facebook. Als je Chrome gebruikt en verbinding maakt met een Google-service, gebruik je waarschijnlijk al QUIC.

De nieuwe versie van het HTTP-protocol profiteert van het bare-metal, low-level UDP-protocol en definieert veel van de nieuwe functies die in eerdere versies HTTP op de TCP-laag aanwezig waren. Dit biedt een manier om beperkingen op te lossen binnen de bestaande internetinfrastructuur.

De eerste resultaten zijn veelbelovend en wanneer het internet ontwerp van IETF afloopt, kunnen we in juni 2019 verwachten dat HTTP/3 wordt gepromoot als een nieuwe HTTP-standaard van de derde generatie.

Net als met HTTP/2 wordt HTTP/3 gebouwd op successen om het web sneller te make. 🚀 Click to Tweet

HTTP/3 Komt er aan

Sommigen zeggen dat de honger van de webindustrie naar meer snelheid en lagere latency alleen wordt geëvenaard door de honger van Google Chrome naar meer RAM.

In 2016 publiceerden we een artikel over HTTP/2, een norm die volgens W3Techs momenteel een wereldwijde acceptatiegraad van 34% heeft. En volgens Can i Use, wordt het ondersteund door alle moderne webbrowsers. Toch staan we nu hier, en zijn we een artikel aan het schrijven over de volgende versie van het protocol, HTTP/3.

HTTP/2 gebruik

HTTP/2 gebruik

HTTP/3 is, op het moment van schrijven, een IETF Internet-Concept of ID, wat betekent dat het momenteel wordt overwogen voor een nieuwe internet-standaard door de Internet Engineering Task Force – een internationale instantie voor internet-normen, die belast is met het definiëren van en het bevorderen van overeengekomen internetprotocol-standaarden, zoals TCP, IPv6, VoIP, Internet of Things, enz.

Het is een open instantie die de web-industrie verenigt en discussies faciliteert over de richting van het internet.

Momenteel is de ID-fase van HTTP/3 de laatste fase voordat voorstellen worden gepromoveerd tot het niveau van RFCs, ook wel Request-for-Comments, die we, voor alle mogelijke doeleinden, kunnen beschouwen als officiële internetprotocol-definities. Vervolgens worden ze geïmplementeerd door alle grote internetspelers.

Dit betekent dat HTTP/3 een officiële standaard moet worden zodra het concept later dit jaar afloopt (juni 2019).

Een beetje achtergrondinformatie — Het Begon met HTTP/2

Bij Kinsta zijn we geobsedeerd om elke laatste milliseconde uit onze stack te persen, of het nu gebruik maakt van de nieuwste versie PHP, gegevens levert via het premium tier-netwerk van het Google Cloud Platform, of caching van assets op onze HTTP/2 CDN.

HTTP/2 bracht enkele serieuze verbeteringen met niet-blokkerende downloads, pipelining en server-push, wat ons heeft geholpen een aantal beperkingen van het onderliggende TCP-protocol te overwinnen. Hierdoor konden we het aantal cycli voor verzoeken, antwoorden en handshakes minimaliseren.

HTTP/2 maakte het mogelijk om meer dan één bron in één TCP-verbinding te duwen – multiplexing. We kregen ook meer flexibiliteit bij het aanvragen van statische downloads en onze pagina’s worden nu niet langer beperkt door een lineaire voortgang van downloads.

 HTTP/2 push

HTTP/2 push

In de praktijk betekent dit dat nu één grote javascript-resource niet noodzakelijk gelijk staat aan een knelpunt voor alle andere statische bronnen die op hun beurt moeten wachten.

Geen pipelining versus pipelining

Geen pipelining versus pipelining (Bron afbeelding: Wikipedia, Author Mwhitlock)

Voeg daar de HTTP/2 header HPACK-compressie en standaard binair formaat van gegevensoverdracht aan toe en we hebben in veel gevallen een aanzienlijk efficiënter protocol.

HTTP/2 HPACK compressie

HTTP/2 HPACK compressie

Voor grote browser-implementaties was het een vereiste voor websites om versleuteling te implementeren – SSL – om de voordelen van HTTP/2 te kunnen benutten – en soms had dit als resultaat een rekenoverhead die snelheidsverbeteringen onmerkbaar maakte. Er waren zelfs enkele gevallen waarin gebruikers een vertraging rapporteerden na de overgang naar HTTP/2.

Laten we zeggen dat de eerste dagen van goedkeuring van deze versie niet voor bangeriken was.

In de NGINX-implementatie ontbrak ook de server-push-functie, deze vertrouwde op een module. En NGINX-modules zijn niet de gebruikelijke Apache drop-in-modules die je gewoon kunt kopiëren – NGINX moet hiervoor opnieuw worden gecompileerd.

Hoewel sommige van deze problemen nu zijn opgelost, als we naar de volledige protocol-stack kijken, zien we dat de primaire beperking op een lager niveau ligt dan HTTP/2 aandurfde.

Om dit uit te leggen, zullen we de internetprotocol-stack van vandaag de dag ontleden vanuit de onderste laag naar de bovenste. Als je meer wilt weten over de achtergrond van HTTP/2, kan je onze ultieme HTTP/2-handleiding raadplegen.

Internet Protocol (IP)

Het internetprotocol (IP) definieert het onderste deel van de volledige internet-topologie. Het is het deel van de internet-stack dat, en dit kunnen we gerust zeggen, echt niet onderhandelbaar is zonder alles te moeten veranderen, inclusief het vervangen van de volledige hardware-infrastructuur, van routers tot servers en zelfs de machines van eindgebruikers.

Dus, hoewel de herziening van het protocol mogelijk is, is zo’n uitgebreide onderneming op dit moment niet aan de orde, vooral omdat we geen haalbaar, baanbrekend en toch achterwaarts compatibel alternatief hebben.

Daaronder bevindt zich een verbindingslaag – het deel van het protocol dat als het ware de ‘kale basis’ is.

Een kanttekening: overtuigend bewijs voor een complete revisie blijkt uit de snelheid waarmee de makers van IPFS (interplanetair bestandssysteem) erin slaagden een ICO-financiering te krijgen die hen binnen een maand 250 miljoen USD opleverde.

We kunnen de start van het IP-protocol terug herleiden naar 1974, er werd een paper gepubliceerd door het Institute of Electrical and Electronics Engineers geschreven door Vint Cerf en Bob Cahn. Het weergaf gedetailleerd pakketten weer die via een netwerk verzonden konden worden, deze werden doorgegeven via IP-adressen en numeriek gedefinieerde adressen van knooppunten in een netwerk/netwerken. Het protocol definieerde ook het formaat van deze pakketten of datagrammen – de headers en payload.

Na de RFC 760 definitie in 1980, stelde de IETF de definitie die tot op de dag van vandaag wordt gebruikt vast in de Request For Comments 791. Dit was de vierde versie van het protocol, maar we kunnen wel stellen dat dit de eerste productieversie is.

Internet Protocol (RFC791)

Internet Protocol (Bron afbeelding: RFC791)

Het maakt gebruik van 32-bits adressen, waardoor het aantal adressen beperkt wordt tot ongeveer 4 miljard. Deze beperking is de verklaring voor het mysterie waarom niet-zakelijke internetgebruikers “dynamische IP-adressen” krijgen van hun ISPs. Een statische IP wordt beschouwd als een “toegevoegde waarde” en heeft vaak extra kosten.

Ze zijn op rantsoen.

Het duurde niet lang voordat men zich realiseerde dat 32-bits adressen niet genoeg waren en er een tekort aankwam. Hierdoor werden er veel RFC’s gepubliceerd die hiermee om probeerden te gaan. Hoewel deze oplossingen tegenwoordig veel worden gebruikt en deel uitmaken van ons dagelijks leven, is het veilig om te zeggen dat dit neerkomt op hacks.

Internetprotocol versie 6 ook bekend als IPv6 kwam als een manier om deze beperkingen aan te pakken, onder meer door geleidelijk te worden overgenomen ten opzichte van de vorige versie. Er werd in 1998 een Draft Standard-document door de IETF gemaakt en werd in 2017 verhoogd naar een internet-standaard.

Hoewel de IPv4-adresruimte werd beperkt door de 32-bits adreslengte, kreeg de IPv6-standaard 128 bits of 3,4 * 10 ^ 38 mogelijke adressen. Dit zou genoeg moeten zijn om ons geruime tijd van dienst te zijn.

Volgens Google en IPv6-connectiviteit onder de gebruikers, is de acceptatie van IPv6 iets meer dan 25% sinds maart 2019.

IPv6 Acceptatie

IPv6 Acceptatie

IP is een rudimentaire laag van de internet-stack, die de meest elementaire dingen definieert, zonder garanties van aflevering, gegevensintegriteit of de volgorde van verzonden pakketten. Op zichzelf staand is het onbetrouwbaar. Het header-formaat van IPv4 voorziet in een header-controlesom, die de knooppunten gebruiken om de integriteit van de header te verifiëren. Dit maakt het anders dan de IPv6-versie, die afhankelijk is van de onderliggende link-laag, waardoor deze sneller kan zijn.

Internet Datagram Header (RFC:791)

Internet Datagram Header (Bron Afbeelding: RFC791)

Begrijpen van de rollen TCP en UDP

Nu is het tijd om te onderzoeken hoe HTTP/3 past binnen de TCP en UDP

TCP

Hoewel IP tegenwoordig de onderliggende laag is van al onze online communicatie, is TCP (Transmission Control Protocol) een onderdeel van het internetprotocol-pakket op een hoger niveau, dat betrouwbaarheid biedt die nodig is voor internet, e-mail, bestandsoverdracht (FTP) – voor toepassing lagen/protocollen van het internet.

Dit omvat het opzetten van verbindingen in meerdere stappen, met handshakes, een gegarandeerde volgorde van pakketten en her-versturing van verloren pakketten. Het geeft feedback (Acks) van aflevering aan de afzender en nog meer. Er is ook checksum-berekening om fouten op te sporen.

Al deze dingen duiden op veel stappen die TCP een betrouwbaar protocol maken, waardoor het een fundament is van de internetdiensten die wij tegenwoordig gebruiken.

De specificatie die teruggaat naar 1974 (RFC 675) en 1981 (RFC 793) is tot op de dag van vandaag niet aanzienlijk veranderd.

De betrouwbaarheid die TCP biedt, is echter niet kosteloos. De overheadkosten van alle roundtrips die vereist zijn voor handshakes, afleverings-feedback en controlesommen die als zwak en overbodig kunnen worden beschouwd. Dit heeft van TCP een knelpunt gemaakt in de moderne protocol-stack. HTTP/2 heeft een aantal snelheidsverbeteringen die bovenop TCP konden worden bereikt.

Het TCP substantieel veranderen is geen simpele onderneming, omdat het protocol onderdeel is van de TCP/IP-stack die teruggaat tot aan de jaren ’70. Het is diep verweven in besturingssystemen, apparaat-firmware, enz.

UDP

UDP (User Datagram Protocol) is ook een van de onderdelen van de Internet Protocol Suite, waarvan de specificaties teruggaan tot 1980 (RFC 768).

Het is, zoals de naam al doet vermoeden, een datagram-gebaseerd verbinding-loos protocol. Wat betekent dat er geen handshakes zijn en er geen garanties zijn voor de volgorde of aflevering. Dit betekent dat alle mogelijke stappen voor het garanderen van levering, gegevensintegriteit en andere dingen worden overgelaten aan de applicatielaag. Dit betekent dat een applicatie die bovenop UDP bouwt, strategieën kan kiezen die specifiek zijn voor het concrete geval, of het kan elementen van de verbindingslaag gebruiken, zoals checksums, om overhead te vermijden.

Omdat UDP, net als TCP, wijdverspreid is, maakt het het mogelijk om verbeteringen te bereiken zonder dat er een uitgebreide wijziging van de firmware nodig is op alle apparaten die op internet zijn aangesloten, of er belangrijke wijzigingen in de besturingssystemen nodig zijn.

De implementatie van nieuwe protocollen wordt belemmerd door veel firewalls, NAT’s, routers en andere middle-boxes die alleen TCP of UDP toestaan tussen gebruikers en de servers die zij moeten bereiken. – HTTP/3 uitgelegd

Deze thread op Hacker News kan ons helpen de redenering achter het bouwen van de nieuwe HTTP-versie boven op de bestaande netwerkstack te begrijpen, in plaats van het opnieuw uit te vinden (hoewel er meer is dan dat).

De specificatie van het UDP-pakketformaat is tamelijk minimaal, de header bestaat uit de bronpoort, de bestemmingspoort, lengte, in bytes, pakket-header- en gegevens en checksum. De checksum kan worden gebruikt om de gegevensintegriteit te controleren, zowel voor de header- als het gegevensgedeelte van het pakket.

De checksum is optioneel wanneer de onderliggende protocol-laag IPv4 is en verplicht wanneer dit IPv6. Tot nu toe is UDP gebruikt voor zaken als computersystemen kloksynchronisatie (NTP),VoIP-toepassingen, videostreaming, DNS-systemen en het DHCP-protocol.

QUIC en HTTP/3

QUIC (Quick UDP Internet Connections) werd voor het eerst ingezet door Google in 2012. Het herdefinieert de grenzen van netwerklagen, vertrouwt op een lager niveau UDP-protocol, herdefinieert handshakes, betrouwbaarheidskenmerken en beveiligingsfuncties in de ‘user-space’, waardoor het de noodzaak voor het upgraden van kernels van internet-brede systemen omzeilt.

HTTP/2 stack versus HTTP/3 stack

HTTP/2 stack versus HTTP/3 stack

Net als met HTTP/2, zal een vooruitgang die werd aangevoerd door Googles SPDY of Speedy, HTTP/3 opnieuw voortbouwen op deze prestaties.

Hoewel HTTP/2 ons multiplexing heeft gegeven en head-of-line-blokkering heeft beperkt, wordt het beperkt door TCP. Je kunt een enkele TCP-verbinding gebruiken voor meerdere streams gemultiplexed om gegevens over te dragen, maar wanneer een van die streams een pakketverlies lijdt, wordt de hele verbinding (en al zijn streams) als het ware gegijzeld totdat TCP zijn ding doet (het verloren pakket opnieuw verzenden).

Dit betekent dat alle pakketten, zelfs als deze al zijn verzonden en wachten, in de buffer van het bestemmingsknooppunt worden geblokkeerd totdat het verloren pakket opnieuw wordt verzonden. Daniel Stenberg noemt dit in zijn boek over HTTP/3 een “op TCP gebaseerde head of line block”. Hij beweert dat gebruikers met 2% packet loss beter af zijn met HTTP/1, met zes connecties om dit risico af te dekken.

QUIC heeft deze beperking niet. Omdat QUIC voortbouwt op het verbindingloze UDP-protocol, heeft het concept van verbinding niet de beperkingen van TCP en hoeven storingen in één stream de rest niet te beïnvloeden.

Zoals Lucas Pardue van Cloudflare het stelde:

Lucas Pardue over HTTP/3

Lucas Pardue over HTTP/3

Met de focus op UDP-streams, bereikt QUIC multiplexing zonder op één TCP-verbinding mee te liften. QUIC bouwt zijn verbinding op een hoger niveau dan TCP. Nieuwe streams binnen QUIC-verbindingen hoeven niet te wachten tot de anderen klaar zijn. QUIC-verbindingen profiteren ook van het afschaffen van handshake via TCP, wat de latency vermindert.

Mensen bij Cisco hebben een interessante video gemaakt over de 3-weg-handshake van TCP.

Hoewel QUIC de TCP-betrouwbaarheidskenmerken wegneemt, maakt dit het goed via de UDP-laag, waardoor pakketten opnieuw worden verzonden, volgordes worden gemaakt enzovoort. Google Cloud Platform introduceerde QUIC-ondersteuning voor hun load balancers in 2018 en zag een verbetering van de gemiddelde laadtijd van pagina’s met 8% wereldwijd en tot 13% in regio’s waar de latency hoger is.

Tussen Google Chrome, YouTube, Gmail, Google’s zoek- en andere diensten kon Google QUIC op een groot stuk internet implementeren, zonder op IETF te moeten wachten. De ingenieurs van Google beweren dat in 2017 7% van het internetverkeer al via QUIC werd uitgevoerd.

Google’s versie van QUIC was gericht op alleen HTTP-transport, met behulp van de HTTP/2-syntaxis. Mensen van IETF (die verantwoordelijk zijn voor het standaardiseren van QUIC), besloten dat de IETF-versie van QUIC meer dan alleen HTTP zou moeten kunnen transporteren. Voorlopig staat werk met niet-HTTP-protocollen via QUIC echter in de wachtstand.

IETF’s werkgroep besloot nog een keer dat de gestandaardiseerde versie TLS 1.3 versleuteling gaat gebruiken in plaats van de aangepaste oplossing van Google. TLS 1.3 draagt, vergeleken met de oudere versies, ook bij aan de protocol-snelheid, omdat de handshakes minder roudtrips vereisen. Kinsta ondersteunt TLS 1.3 op al onze servers en onze Kinsta CDN.

Op dit moment blijft Google zijn eigen versie van QUIC gebruiken in zijn product, terwijl hij zijn ontwikkelingsinspanningen richt op de IETF-normen. De meeste andere internetspelers bouwen bovenop de IETF-versie (de twee verschillen in een aantal andere aspecten naast versleuteling).

Als we Chrome Dev Tools openen en een aantal producten van Google, zoals Gmail, in de kolom Protocol van het tabblad Netwerk laden, zien we dat veel bronnen worden geladen via de Google-versie van het QUIC-protocol. Dit is ook het geval voor Google-producten zoals Analytics, Google Tag Manager, enz.

Google QUIC service

Google QUIC service

Cloudflare heeft onlangs een zeer uitgebreide update gepubliceerd over het proces van de standaardisatie.

Hoewel UDP QUIC en HTTP/3 weliswaar enkele voordelen biedt, brengt het ook enkele uitdagingen met zich mee. TCP is al jaren het mainstream-protocol, terwijl UDP dat niet is, dus besturingssystemen en de softwarestack daarvoor zijn over het algemeen niet zo geoptimaliseerd. Als gevolg is er een veel hogere CPU-belasting/ -vereisten voor QUIC, volgens sommige schattingen, tweemaal zoveel als voor HTTP/2.

Optimalisaties gaan diep in op de kernel van besturingssystemen en verschillende routers en firmware van apparaten. Deze Red Hat tuning handleiding kan meer informatie bieden over het onderwerp voor diegenen die meer technisch onderlegd zijn.

We zouden kunnen zeggen dat QUIC probeert de TCP-functies opnieuw te ontwerpen bovenop een minimaler en flexibeler protocol.

QUIC-verbindingen, die we eerder noemden, combineren TLS en transport-handshakes. Nadat ze zijn vastgesteld, worden ze geïdentificeerd door unieke CID’s (verbindings-id’s). Deze ID’s blijven behouden bij IP-wijzigingen en kunnen helpen bij het veiligstellen van ononderbroken downloads tijdens, bijvoorbeeld, een overstap van 4G naar WiFi. Dit is relevant, vooral omdat steeds meer internetverkeer wordt uitgevoerd op mobiele apparaten. Er kunnen vragen ontstaan of dit element door Google is ontworpen om betere gebruikersregistratie over verschillende verbindingen en internetproviders mogelijk te maken.

TLS is verplicht, en bedoeld om het voor apparaten moeilijk te maken in het midden te knoeien met, of het verkeer af te luisteren. Daarom is het niet zeldzaam dat firewall providers en -leveranciers zoals Cisco het UDP-protocol als een probleem zien en manieren bieden om dit uit te schakelen. Het is voor tussenpersonen moeilijker om QUIC-verkeer te inspecteren, te controleren of te filteren.

QUIC-streams worden verzonden via QUIC-verbindingen, uni-directioneel of bi-directioneel. Streams hebben ID’s, die de initiator identificeren, controleren of de stream uni-directioneel of bi-directioneel is, en ook als in-stream flow-control fungeren.

Hoewel QUIC een transportlaag-protocol is, is HTTP de laag daarboven, een toepassingslaag-protocol of toepassingsprotocol.

Omdat achterwaartse compatibiliteit van het grootste belang is, zal de IETF de implementatie van HTTP/3 de oude versie (HTT1 of HTTP/2) in de respons opnemen. Het bevat een header die de client informeert dat HTTP/3 beschikbaar is, samen met poort-/host-informatie, zoals beschreven in RFC 7838.

Dit verschilt van HTTP/2, waarbinnen transport kan worden onderhandeld binnen de TLS-handshake. Maar omdat IETF bijna QUIC-gebaseerde HTTP/3 als de volgende standaard heeft overgenomen, kunnen we verwachten dat web-clients steeds vaker op HTTP/3-ondersteuning anticiperen. Het is mogelijk voor clients om gegevens van eerdere HTTP/3-verbindingen te cachen en direct verbinding te maken (zero-round-trip, of 0-RTT) bij latere bezoeken aan dezelfde host.

Samenvatting

Er zijn mensen die denken dat, dankzij het feit dat de HTTP/2-standaard nog niet volledig is geaccepteerd, het misschien nog te vroeg is om voor HTTP/3 (versie drie) te gaan. Dit is een geldig punt, maar zoals we al zeiden, dit protocol heeft al uitgebreide tests en implementaties gezien. Google begon al in 2015 met testen, evenals Facebook in 2017.

Sindsdien hebben andere spelers zich aangesloten bij de normalisatie-inspanningen, zoals Akamai en Mozilla. Tijdens de laatste IETF-hackathon in november 2018 toonde de aanwezigen interesse in QUIC door bedrijven zoals Facebook, Apple, Google, Mozilla, NetApp en LiteSpeed ​​Tech. Er waren enkele veelbelovende testen en het lijkt erop dat LiteSpeed ​​de eerste grote server-leverancier is met een werkende HTTP/3-server. Cloudflare draait momenteel ook QUIC in bèta.

Kort daarna werd QUIC hernoemd naar HTTP/3 in IETF’s Internet Draft. Het zal eind juni 2019 aflopen en we kunnen de RFC of de definitieve standaard ergens rond juli verwachten.

Dit jaar zal spannend zijn, omdat we kunnen verwachten dat grote softwareleveranciers de overstap maken naar de nieuwe standaard.

Wanneer is HTTP/3 beschikbaar bij Kinsta?

Nadat de RFC definitief is (zomer 2019) en Nginx officieel QUIC ondersteunt, kunnen we garanderen dat het Kinsta-team dit beschikbaar gaat maken! Wanneer het klaar is voor productie, zullen we het uitrollen.

15
Delen