en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Een inleiding tot HTTP / 2

Einführung

HTTP / 2 is de laatste herziening van de HyperText Transfer Protocol of HTTP [01], die door browsers wordt gebruikt om met webservers te communiceren. Afgeleid van de oudere SPDY [02] protocol, HTTP / 2 is de eerste nieuwe versie van HTTP sinds de standaardisatie van HTTP / 1.1 in RFC 2068 in 1997.

Het is ontwikkeld door de Internet Engineering Task Force (IETF) HTTP-werkgroep httpbis (waar "bis" "tweemaal" betekent), en gepubliceerd als RFC 7540 [03] mei 2015.

HTTP / 2-acceptatie

HTTP / 2 wordt sinds de officiële publicatie steeds vaker gebruikt door werkende websites. De online enquêteservice W3Techs [04] merkt op dat de ondersteuning van HTTP / 2017 van september 2018 tot september 2 is gestegen van 16% tot 30% van alle gecontroleerde websites.

Bovendien bieden grote browsers (bijv. Chrome, Firefox, Edge, enz.) Al volledige ondersteuning voor HTTP / 2 [05]. (Sommige ontwikkelden zelfs experimentele implementaties voordat HTTP / 2 als standaard werd geaccepteerd.)

Deze wijdverbreide acceptatie betekent dat HTTP / 2 het potentieel heeft om het de facto communicatieprotocol van het web te worden.

Motivatie achter HTTP / 2

HTTPS' Handvest [06] noemt verschillende componenten van HTTP / 1.1 die verbeterd zouden kunnen worden als motivatie voor HTTP / 2. Het primaire doel van de groep was echter om de latentie die door de eindgebruiker werd waargenomen, te verminderen.

Om dit te doen, httpbis overwogen om de overhead van de bandbreedte te minimaliseren via headercompressie en agressieve prefetching-technieken (bijv. server push), terwijl tegelijkertijd wordt geprobeerd bekende prestatieproblemen zoals congestie van de verbinding en het Head-of-Line (HoL) -blokkeerprobleem systematisch aan te pakken [07].

Bovendien moest HTTP / 2 achterwaarts compatibel zijn, wat betekent dat het dezelfde methode-werkwoorden, statuscodes, URI's en (de meeste) koptekstvelden moest gebruiken die te vinden zijn in HTTP / 1.1. HTTP / 2 moest ook worden ontworpen om algemene HTTP-use-cases te ondersteunen, zoals desktop- en mobiele webbrowsers, programmeerinterfaces, proxy's en firewalls.

Om deze compatibiliteit te behouden, heeft de werkgroep een protocolonderhandelingsmechanisme ontwikkeld waarmee clients en servers kunnen kiezen tussen HTTP / 1.1-, HTTP / 2- of zelfs niet-HTTP-protocollen.

Dus wat is er nieuw in HTTP / 2?

HTTP / 2 gebruikt nog steeds dezelfde URI-schema's en poortnummers die worden gebruikt in HTTP / 1.1 (dwz poort 80 voor http URI's en poort 443 voor https URI's), maar veel dingen worden anders gedaan onder de motorkap.

De meest fundamentele verandering is de introductie van frames als de basisgegevenseenheid van HTTP / 2.

HTTP / 1.1 gebruikt traditioneel pakketten om netwerkgegevens weer te geven. Een client construeert een aanvraagpakket met een methodewerkwoord (bijv GET or POST), een lijst met kopteksten toe te voegen die de verbinding beschrijven, en een lichaam dat toepassingsgegevens bevat.

Na ontvangst van een aanvraagpakket reageert een HTTP / 1.1-server met een soortgelijk antwoordpakket dat de gevraagde informatie bevat. Als gevolg hiervan heeft elke aanvraag- en responscyclus een nieuwe verbinding nodig.

Omgekeerd brengen HTTP / 2-clients een enkele netwerkverbinding tot stand met de server, die ze gebruiken voor alle daaropvolgende netwerkcommunicatie. Headers, gebruikersgegevens, foutmeldingen en dergelijke informatie zijn verpakt in verschillende binaire gegevensstructuren, frames genoemd, voordat ze via het netwerk worden verzonden.

Dit lijkt een kleine verandering, maar heeft grote gevolgen.

Koptekstcompressie

Een groot voordeel van het gebruik van frames is dat HTTP / 2-headers in een HEADER frame, dat kan worden gecomprimeerd met normale compressiemethoden. Headers moeten worden overgedragen voorafgaand aan gegevens, dus headercompressie kan de overhead voor bandbreedte die door HTTP / 2 wordt opgelegd, verminderen.

Headercompressie, samen met de volgende prestatieverbeterende HTTP / 2-functies, kan vooral handig zijn in mobiele of internet-of-things (IOT) -toepassingen, waar minimaal netwerkgebruik vereist is.

Streams en multiplexing

Een onafhankelijke reeks van semantisch relevante frames wordt a genoemd stream. Aan streams wordt een unieke identifier toegewezen door het eindpunt (dwz client of server) dat ze heeft gemaakt, zodat andere eindpunten er onderscheid tussen kunnen maken.

Eindpunten kunnen frames van verschillende streams via dezelfde HTTP / 2-verbinding door elkaar halen, waardoor een enkele netwerkverbinding meerdere gelijktijdig geopende streams kan ondersteunen. multiplexing [08].

Het opnieuw gebruiken van dezelfde verbinding vermindert problemen zoals verstopte verbindingen en het eerder genoemde HoL-probleem, en biedt betere prestaties en een soepelere gebruikerservaring dan eerdere HTTP-versies.

Stroomafhankelijkheid en prioritering

Het beheren van meerdere gelijktijdige streams betekent dat sommige streams voor andere worden verwerkt. Met HTTP / 2 kan de ontwikkelaar (of beheerder) dit gedrag verfijnen met een zogenaamde functie stream afhankelijkheid.

Een stream kan afhankelijk zijn van de volledige overdracht van een andere stream voordat deze wordt afgehandeld. Op een site waar bijvoorbeeld de hoofdinhoud van een webpagina moet worden geladen voordat er aanbevelingen voor soortgelijke inhoud worden gedaan, staat HTTP / 2 toe dat de aanbevelingsstroom wordt gemaakt als afhankelijk van de hoofdinhoudstroom.

HTTP / 2 ondersteunt ook stroomprioritering. Dat wil zeggen dat aan elke stream een ​​prioriteit kan worden toegewezen om te suggereren hoe dringend de eindpunten bronnen moeten toewijzen om de frames van de stream te verwerken.

Prioritering en stroomafhankelijkheid helpen ontwikkelaars en website-eigenaren het netwerkgebruik van hun site te optimaliseren, wat de gebruikerservaring van hun site aanzienlijk kan verbeteren.

Server Push

Ten slotte kan HTTP / 2 de prestaties van een website verbeteren door "push" -functionaliteit te bieden. Een HTTP / 2-webserver kan met gegevens reageren voor meer zoekopdrachten dan de client oorspronkelijk heeft gevraagd. Hierdoor kan de server gegevens leveren waarvan hij weet dat een webbrowser een pagina moet renderen, zonder te wachten tot de browser het eerste antwoord onderzoekt, en dus zonder de overhead van een extra verzoekcyclus.

Server push geeft ontwikkelaars volledige controle over het aantal verzoeken dat een browser nodig heeft om hun website weer te geven. Bij correct gebruik kan deze functie de netwerkoverhead minimaliseren.

Uiteraard kan misbruik van de push-functie ook meer bandbreedte verspillen dan eigenlijk nodig is. Om deze reden stelt HTTP / 2 een client in staat te vragen dat serverpush wordt uitgeschakeld wanneer hij voor het eerst een verbinding tot stand brengt.

HTTP / 2-beveiliging

Als je tot nu toe hebt gelezen, moet het duidelijk zijn dat de ontwikkelaars van HTTP / 2 echt moeite hebben gedaan om de prestaties te verbeteren. Er moet echter worden opgemerkt dat HTTP / 2 ook kan helpen de algehele beveiliging van browsergebruikers te verbeteren.

Meer specifiek is HTTP / 2 gedefinieerd voor zowel HTTP-URI's (dwz zonder codering) als HTTPS-URI's (meer dan TLS gecodeerde kanalen). Hoewel de standaard zelf geen codering vereist, zijn alle belangrijke browserimplementaties (dat wil zeggen Firefox [09], Chrome, Safari, Opera, IE, Edge) hebben besloten dat ze dat zullen doen enige ondersteuning HTTP / 2 over TLS.

In feite maken browsers onderscheid tussen HTTP / 2 met duidelijke tekst en HTTP / 2 boven gecodeerd TLS als twee verschillende protocollen. Gecodeerde HTTP / 2 wordt aangeroepen h2 en duidelijke tekst h2c. Op het moment van schrijven ondersteunt geen van de belangrijkste browsers h2c , Waardoor TLS versleuteling is verplicht voor een website om te profiteren van de andere voordelen van HTTP / 2. Wanneer HTTP / 2 het standaardprotocol voor het webnetwerk wordt, moeten eigenaren van oude websites die nog niet zijn geüpgraded naar SSL /TLS, zal sterk gemotiveerd zijn om dit eindelijk te doen.

Conclusie

Wijdverbreide adoptie van HTTP / 2 zal een nieuw en verbeterd web tot stand brengen. Het is sneller, heeft minder bandbreedte nodig en het helpt websites veilig te blijven. De algemene acceptatie ervan zal de algehele webgebruikerservaring zeker soepeler en veiliger maken.

Ontvang vandaag nog een certificaat en doe mee in de toekomst.

Referenties

  1. HTTP-protocol
  2. SPDY-protocol
  3. HTTP / 2-specificatie
  4. W3Techs HTTP / 2-adoptieonderzoek
  5. HTTP / 2-acceptatie in browsers
  6. httpbis-charter
  7. HOL-blokkering
  8. multiplexing
  9. Firefox op HTTP / 2

Gerelateerde artikelen

Abonneer u op de nieuwsbrief van SSL.com

Wat is SSL /TLS?

Video afspelen

Abonneer u op de nieuwsbrief van SSL.com

Mis geen nieuwe artikelen en updates van SSL.com