Nederlands
Menu

HTTP/1.1 versus HTTP/2 versus HTTP/3: transport, multiplexing, head-of-line blocking, headercompressie en versleuteling

De drie versies delen dezelfde HTTP-semantiek (RFC 9110), zoals methoden, statuscodes en headervelden; wat verschilt, is het formaat en het transport waarmee ze worden vervoerd. HTTP/1.1 (RFC 9112) verstuurt tekstberichten via TCP en geeft per verbinding de antwoorden één voor één terug. HTTP/2 (RFC 9113) deelt berichten op in binaire frames en multiplext meerdere streams over één TCP-verbinding. HTTP/3 (RFC 9114) gebruikt QUIC (RFC 9000), dat over UDP draait en het multiplexen van streams en de versleuteling met TLS 1.3 in het transport afhandelt. Zo wordt head-of-line blocking in TCP vermeden, waarbij het verlies van één pakket alle streams ophoudt.

KenmerkHTTP/1.1HTTP/2HTTP/3
SpecificatieRFC 9112 (semantiek in RFC 9110, gedeeld door alle drie de versies)RFC 9113RFC 9114 (QUIC is RFC 9000)
TransportTCPTCPQUIC (draait over UDP)
BerichtformaatTekst: een requestregel en headervelden, elk op een eigen regelBinaire framesBinaire frames (op QUIC-streams)
MultiplexingGeen: één verbinding behandelt één request en antwoord tegelijk, dus parallel ophalen vraagt meerdere verbindingenMeerdere streams worden parallel over één TCP-verbinding verstuurdMeerdere QUIC-streams worden parallel verstuurd; de streams worden door het transport beheerd
Head-of-line blockingTreedt op in de HTTP-laag: op dezelfde verbinding kan het volgende antwoord pas worden verstuurd als het vorige klaar is (ook met pipelining komen antwoorden in de volgorde van de requests terug)Opgelost in de HTTP-laag, maar omdat TCP bytes strikt op volgorde aflevert, laat het verlies van één pakket alle streams op de hertransmissie wachtenQUIC beheert de volgorde per stream, dus een verlies treft alleen de streams waarvan data verloren is gegaan
HeadercompressieGeen (de body kan worden gecomprimeerd, maar headers gaan als platte tekst)HPACK (RFC 7541)QPACK (RFC 9204), een aanpassing van HPACK die ook werkt als streams in een andere volgorde aankomen
VersleutelingOptioneel: https gebruikt TLS, http wordt onversleuteld verstuurdDe specificatie definieert zowel een variant over TLS (h2) als een onversleutelde (h2c); over TLS is minstens TLS 1.2 vereist. Grote browsers ondersteunen HTTP/2 alleen over TLSVerplicht: TLS 1.3 is in QUIC ingebouwd en er is geen onversleutelde modus
Round trips voor de verbindingsopbouwEén voor TCP, plus nog één met TLS 1.3, dus de request wordt na in totaal twee round trips verstuurdZoals bij HTTP/1.1 (twee round trips voor TCP en TLS)QUIC combineert de transport- en cryptografische handshake in één round trip; 0-RTT, dat al data meestuurt in de allereerste verzending, is ook beschikbaar voor servers waarmee eerder verbinding is gemaakt
Als het netwerk verandertEen TCP-verbinding wordt geïdentificeerd door de bron- en bestemmingsadressen en -poorten, dus als het IP-adres verandert, is een nieuwe verbinding nodigZoals bij HTTP/1.1QUIC identificeert verbindingen met connection-ID's, dus dezelfde verbinding kan doorgaan bij het overschakelen van draadloos LAN naar een mobiel netwerk (connection migration)

De getalswaarden zijn typische ordegroottes en variëren per procesgeneratie en product.

Wanneer welke variant?

HTTP/1.1
De basisversie die elke client en server kan gebruiken. Ze wordt ook gebruikt voor communicatie binnen serversystemen en voor eenvoudige webinterfaces, zoals instellingenpagina's van apparaten.
HTTP/2
Wanneer een webpagina die veel kleine bestanden laadt, efficiënt over één verbinding moet worden geleverd. Omdat het werkt op netwerken die UDP blokkeren, is het de terugvaloptie, ook voor sites die HTTP/3 ondersteunen.
HTTP/3
Wanneer je wilt voorkomen dat streams elkaar ophouden op verbindingen met verlies en hoge latentie, zoals mobiele netwerken, of een snellere verbindingsopbouw wilt. Sommige netwerken blokkeren UDP, dus sites ondersteunen meestal ook HTTP/2 of HTTP/1.1.

Veelgestelde vragen

Heeft HTTP/2 head-of-line blocking niet al opgelost?

In de HTTP-laag wel, maar in de TCP-laag blijft het bestaan. HTTP/2 multiplext meerdere streams over één TCP-verbinding, maar TCP weet niet bij welke stream de data hoort en levert bytes strikt op volgorde af. Als er één pakket verloren gaat, wordt dus ook data van niet-betrokken streams tegengehouden voor de ontvangende applicatie, tot de hertransmissie aankomt. Bij HTTP/3 beheert QUIC de volgorde per stream, dus alleen de streams met de verloren data moeten wachten.

Hoe weet een client dat een server HTTP/3 ondersteunt?

HTTP/3 gebruikt UDP, dus het moet los van een TCP-verbinding worden gestart. Meestal maakt de client eerst verbinding met HTTP/1.1 of HTTP/2 over TCP, en kondigt de server in de responsheader Alt-Svc aan dat HTTP/3 (h3) beschikbaar is. De client gebruikt dan QUIC voor latere verbindingen. Daarnaast wordt tijdens de TLS-handshake met ALPN bepaald of HTTP/1.1 of HTTP/2 over TLS wordt gebruikt.

Zijn er aandachtspunten bij 0-RTT in HTTP/3?

Ja. Data die met 0-RTT wordt verstuurd, kan door een aanvaller worden opgenomen en opnieuw worden verzonden (een replay-aanval). Bij 0-RTT is daarom voorzichtigheid nodig, bijvoorbeeld door alleen requests zoals GET te versturen die geen kwaad kunnen als ze meer dan eens worden ontvangen.

Moeten webapplicaties voor HTTP/2 of HTTP/3 worden herschreven?

In de meeste gevallen niet. De betekenis van methoden, statuscodes en headervelden is gedeeld door alle drie de versies (RFC 9110); alleen de manier van vervoer verschilt. Omdat de versie per verbinding wordt gekozen, is een gangbare opzet dat een reverse proxy of CDN HTTP/2 of HTTP/3 van browsers accepteert en met de applicatieservers erachter HTTP/1.1 spreekt.

Test uw begrip

Welke combinatie van elementen in de eerste regel van een HTTP/1.1-verzoek (de verzoekregel, request line) is juist?

  1. ADe methode, het doel van het verzoek (zoals een pad) en de HTTP-versie
  2. BDe HTTP-versie, de statuscode en een korte omschrijving van de reden (reason phrase)
  3. CHet IP-adres van de afzender, het poortnummer van de bestemming en de methode
Antwoord en toelichting tonen

Antwoord: A. De methode, het doel van het verzoek (zoals een pad) en de HTTP-versie

Een HTTP-verzoek bestaat achtereenvolgens uit de verzoekregel, de headers (één „Naam: waarde” per regel), een lege regel en de body. „GET /docs/index.html HTTP/1.1” is bijvoorbeeld een regel die met de methode GET om /docs/index.html vraagt. In HTTP/1.1 moet ook de Host-header worden meegestuurd, zodat de server kan zien voor welke site een verzoek bedoeld is, ook als er meerdere sites op hetzelfde IP-adres draaien. De eerste regel van een antwoord is de statusregel, met de versie, de statuscode en de reason phrase, zoals in „HTTP/1.1 200 OK”.

Welke beschrijving van HTTP/2 en HTTP/3 is juist?

  1. AHTTP/2 kan meerdere verzoeken parallel over één TCP-verbinding afhandelen, maar door pakketverlies kunnen ook andere streams moeten wachten; HTTP/3 vermindert dit met QUIC over UDP
  2. BHTTP/2 gebruikt berichten in hetzelfde tekstformaat als HTTP/1.1 en opent voor elk verzoek parallel een nieuwe TCP-verbinding, zodat meerdere resources tegelijk kunnen worden ontvangen
  3. CHTTP/3 werkt net als HTTP/2 over TCP en verandert alleen de methode voor headercompressie; het effect van pakketverlies is hetzelfde als bij HTTP/2, en UDP wordt niet gebruikt
Antwoord en toelichting tonen

Antwoord: A. HTTP/2 kan meerdere verzoeken parallel over één TCP-verbinding afhandelen, maar door pakketverlies kunnen ook andere streams moeten wachten; HTTP/3 vermindert dit met QUIC over UDP

Ook HTTP/1.1 kan met persistente verbindingen (keep-alive) één TCP-verbinding hergebruiken, maar over één verbinding worden antwoorden een voor een in volgorde ontvangen, zodat browsers meerdere verbindingen parallel openden. HTTP/2 verdeelt berichten in binaire frames en multiplext meerdere streams over één TCP-verbinding, zodat ze parallel worden verzonden. Omdat TCP zijn bytestroom echter in volgorde aflevert, moeten bij het verlies van één pakket ook de gegevens van niet-verwante streams wachten tot de hertransmissie aankomt (head-of-line blocking). HTTP/3 gebruikt QUIC, dat over UDP werkt en de volgorde per stream beheert, zodat het effect van een verlies binnen die stream blijft.

Van een webserver met een RTT van 40 ms worden één HTML-bestand en de vier afbeeldingen waarnaar het verwijst na elkaar opgehaald. Neem aan dat het opzetten van een TCP-verbinding één rondgang kost en elk verzoek met antwoord één rondgang, en verwaarloos de overdrachtstijd van de gegevens, de verwerkingstijd van de server, TLS en het afbreken van verbindingen. Wat is het verschil in totale tijd tussen het openen van een nieuwe TCP-verbinding voor elk object en het hergebruiken van één TCP-verbinding (een persistente verbinding)?

  1. A160 ms
  2. B200 ms
  3. C400 ms
Antwoord en toelichting tonen

Antwoord: A. 160 ms

Er zijn in totaal vijf objecten. Met elke keer een nieuwe verbinding kost elk object twee rondgangen, één voor het opzetten van de verbinding en één voor verzoek en antwoord, wat 5 × 2 × 40 = 400 ms geeft. Met een persistente verbinding wordt de verbinding alleen aan het begin één keer opgezet, gevolgd door alleen de vijf verzoeken en antwoorden, wat (1 + 5) × 40 = 240 ms geeft. Het verschil is 400 − 240 = 160 ms: de vier bespaarde keren dat een verbinding wordt opgezet. In HTTP/1.1 zijn persistente verbindingen het standaardgedrag.

  1. Een client maakt een nieuwe HTTPS-verbinding (TLS 1.3 over TCP) met een webserver met een rondetijd (RTT) van 100 ms. Welke waarde ligt het dichtst bij de tijd tot het antwoord op het eerste verzoek begint binnen te komen? De DNS-naamresolutie is al gedaan; verwaarloos de verwerkingstijd van de server en de overdrachtstijd van de gegevens.
  2. Wat wordt door HTTPS (HTTP beveiligd met TLS) beschermd?

Oefenvragen over Basis van webtechnologie

Belangrijke termen uitgelegd

HTTP (Hypertext Transfer Protocol)
Het protocol op de applicatielaag voor het uitwisselen van HTML, afbeeldingen en gegevens tussen onder meer webbrowsers en webservers. Een client verstuurt een verzoek dat bestaat uit een methode, een URL, headers en een body, en de server geeft een antwoord terug dat bestaat uit een statuscode, headers en een body. Als protocol is HTTP toestandsloos, dus een toestand zoals een login wordt bewaard met cookies en vergelijkbare middelen. HTTP/1.1 gebruikt een tekstformaat en persistente verbindingen, HTTP/2 multiplext meerdere streams over één TCP-verbinding, en HTTP/3 werkt met QUIC over UDP. HTTP die met TLS is beveiligd, heet HTTPS.
TLS (Transport Layer Security)
Protocol dat communicatie versleutelt, manipulatie detecteert en servers met certificaten authenticeert. HTTPS is HTTP beveiligd met TLS.
Three-way handshake (drieweghandshake)
De procedure waarmee een TCP-verbinding wordt opgebouwd. Drie uitwisselingen, de SYN van de client, de SYN+ACK van de server en de ACK van de client, bevestigen het initiële volgnummer van elke kant.
HTTP-methode
Het woord in een HTTP-verzoek dat aangeeft welke bewerking op een resource moet worden uitgevoerd. Voorbeelden zijn GET (ophalen), HEAD (alleen de headers ophalen), POST (verwerken of aanmaken), PUT (vervangen), PATCH (gedeeltelijk bijwerken), DELETE (verwijderen) en OPTIONS (vragen welke functies beschikbaar zijn). Een methode die de toestand van de server niet verandert, heet „veilig”, en een methode die bij willekeurig vaak verzenden dezelfde toestand oplevert als bij één keer verzenden, heet „idempotent”. GET is veilig en idempotent, PUT en DELETE zijn idempotent maar niet veilig, en POST is in het algemeen geen van beide.
HTTP-statuscode
Een getal van drie cijfers in de eerste regel van een HTTP-antwoord dat het resultaat van het verzoek aangeeft. Het honderdtal geeft de klasse: 1xx is informatief, 2xx is succes (200 OK, 201 Created, 204 No Content), 3xx is omleiding (301 Moved Permanently, 302 Found, 304 Not Modified), 4xx is een fout aan de kant van de client (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) en 5xx is een fout aan de kant van de server (500 Internal Server Error, 503 Service Unavailable). 401 wordt gebruikt als authenticatiegegevens ontbreken of ongeldig zijn, en 403 als de client wel is geauthenticeerd maar de bevoegdheid mist.
Reverse proxy
Een server die vóór webservers staat, de verzoeken van gebruikers namens die servers ontvangt en ze doorstuurt naar een of meer servers erachter. Hij neemt taken op zich zoals de HTTPS-versleuteling op één plek afhandelen (TLS-terminatie), veelgebruikte antwoorden opslaan en teruggeven, de belasting over meerdere servers verdelen en de configuratie van de servers erachter verbergen. Hij verschilt in plaats en in wat hij beschermt van een forward proxy, die aan de kant van de gebruikers staat en namens hen verbinding maakt met externe sites.

Verwante vergelijkingen