Wanneer het gaat om de versies van HTTP, komt vaak deze gedachte op.

“Is het web niet gewoon allemaal HTTP? Wat is het grote verschil tussen 1.1 en 2?”
“Kun je niet gewoon de nieuwe versie, HTTP/2, gebruiken?”

Om het samen te vatten:

  • HTTP/1.1 vs HTTP/2 is niet letterlijk “volledig verschillende protocollen”, maar eerder een verschil in hoe ze dezelfde HTTP-informatie (methoden/headers/statuscodes, etc.) efficiënter sturen.

  • In de praktijk is het niet zozeer een keuze tussen “de ene of de andere”, maar is de gebruikelijke structuur dat de server beide ondersteunt en de client kiest wat mogelijk is.

Hieronder volgt een samenvatting van de kernpunten vanuit een ontwikkelaarssperspectief.

1. Eenvoudige samenvatting van HTTP/1.1

Commandbox 광고

1) Tekst-gebaseerd protocol

HTTP/1.1 is de gebruikelijke aanvraag-/responsvorm die we vaak zien.

GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

  • Het is tekst-gebaseerd, wat het eenvoudig maakt om te debuggen,

  • en je kunt de structuur begrijpen met hulpmiddelen zoals curl, telnet, nc.

2) Persistent Connection + Pipelining

Een groot probleem van HTTP/1.0 was het telkens opnieuw openen van een TCP-verbinding voor elke aanvraag, maar
met HTTP/1.1 is de persistent connection (keep-alive) standaard geworden,
waardoor meerdere aanvragen sequentieel over één verbinding kunnen worden verzonden.

Daarnaast was er ook de functie HTTP pipelining:

  • Aanvragen kunnen worden verzonden zonder op een respons te wachten

  • en de responsen kunnen in volgorde worden ontvangen.

Maar deze werden in de praktijk zelden door browsers gebruikt,
en er bleef een “structuur waarbij sequentieel moet worden verwerkt”, waardoor er prestatieproblemen overbleven.

3) HOL (Head-of-Line) Blocking probleem

Een van de belangrijkste knelpunten van HTTP/1.1 is HOL (Head-of-Line) Blocking.

  • Doordat aanvragen sequentieel moeten worden verwerkt binnen één verbinding,

  • als de eerste aanvraag traag is, moeten de daarop volgende aanvragen ook wachten.

  • Daarom heeft de browser meerdere TCP-verbindingen per domein (bijv. maximaal 6) geopend om dit probleem te verlichten.

Samenvattend:

HTTP/1.1 is “een manier om meerdere leidingen te creëren om knelpunten te verminderen”.
(Meerdere TCP-verbindingen)

2. Wat is er anders aan HTTP/2?

Het doel van HTTP/2 is duidelijk.

  • Vertraging (latency) te verminderen

  • Netwerkresources efficiënter te benutten

De kernwoorden zijn:

  1. Binaire framing (Binary Framing)

  2. Stream-gebaseerde multiplexing

  3. Headercompressie (HPACK)

  4. (Oorspronkelijk) Server Push – feitelijk dood in de browser

2-1. Tekst → Binaire framing

HTTP/1.1 is regel-gebaseerd tekstparsing, maar bij HTTP/2 worden alle gegevens verzonden als frames, wat betekent dat ze in binaire stukjes worden gesplitst.

  • Headers zijn HEADERS frames

  • De body is een DATA frame

  • Deze frames behoren tot een specifieke stream ID.

Ontwikkelaars zullen zelden direct met frames werken,
maar dit maakt functies zoals multiplexing, headercompressie, prioritering mogelijk.

2-2. Multiplexing

Dit is het meest merkbare verschil.

  • HTTP/1.1: Aanvragen en reacties worden sequentieel verwerkt over één TCP-verbinding

  • HTTP/2: Meerdere streams worden gelijktijdig over één TCP-verbinding verzonden

Dat wil zeggen,

“Het versturen van verzoeken en antwoorden in één verbinding zonder dat er meerdere TCP-verbindingen hoeven te worden geopend”

Hierdoor:

  • Wanneer een enkele HTML-pagina tientallen tot honderden resources moet ophalen,

  • kan alles gelijktijdig binnen één enkele verbinding worden verzonden

  • en dit is vooral voordelig bij mobiele omgevingen en hoge RTT-omgevingen.

Maar er blijft nog steeds HOL Blocking op TCP-niveau bestaan, waardoor dit onderdeel is verbeterd in HTTP/3 (QUIC).

2-3. Headercompressie (HPACK)

HTTP-aanvraag/response headers bevatten vaak veel duplicaties.

  • Cookie, User-Agent, Accept-* enz.

  • Bij elke aanvraag kunnen ze honderden tot enkele kilobytes bedragen.

HTTP/2 gebruikt HPACK, een methode voor headercompressie,
om duplicatie tussen deze headers te verminderen.

  • Veelgebruikte headers worden geregistreerd in een tabel en verzonden met korte indexen

  • Alleen de delen die verschillen van eerdere aanvragen worden efficiënt gecodeerd

Hierdoor zijn vooral hoge frequentie SPA / pagina’s met veel resources aanzienlijk voordelig.

2-4. Server Push is feitelijk overleden

In de vroege dagen van HTTP/2 werd Server Push, de functie waarmee de server CSS/JS vóór de aanvraag naar de client kan “duwen”, als een groot voordeel gezien. Maar in de praktijk:

  • de implementatie is complex

  • problemen met cache/duplicatie van resources

  • de daadwerkelijke prestatieverbeteringen zijn minimaal of leiden soms zelfs tot verslechtering

Daarom is in Chromium-gebaseerde browsers deze functie standaard uitgeschakeld sinds 2022 (Chrome for Developers)
en Firefox zal dit ook in 2024 verwijderen, waardoor deze functie in de browser-ecosystemen feitelijk voorbij is.

Dus als we het tegenwoordig over HTTP/2 hebben, beschouwen we server push gewoon als een “historische functie”.

3. HTTPS, ALPN, en “h2 vs http/1.1 keuze”

Commandbox 광고

In de praktijk zal de keuze tussen “HTTP/1.1 of HTTP/2” automatisch worden onderhandeld tijdens het TLS-handshake proces tussen client en server.

Dit wordt behandeld door de TLS-uitbreiding genaamd ALPN (Application-Layer Protocol Negotiation).

  • Client: “Ik ondersteun zowel h2 als http/1.1”

  • Server: “Laten we h2 gebruiken” (of “ik ondersteun alleen http/1.1”)

Instelling voorbeeld voor Apache:

Protocols h2 http/1.1

Als je dit instelt:

  • Moderne browsers die HTTP/2 ondersteunen, zullen automatisch HTTP/2 (h2) gebruiken

  • Oude clients zullen automatisch communiceren met HTTP/1.1

De meeste grote browsers ondersteunen al goed HTTP/2,
en veel websites hebben HTTP/2 al geactiveerd.

4. “Wanneer moeten we ze zelfs apart gebruiken?” – Samenvatting vanuit ontwikkelaarsperspectief

Laten we deze sleutelvraag bekijken per casus.

4-1. Algemene webdiensten (voor browsers)

Dichtbij het juiste antwoord:

“Zet HTTPS + HTTP/2 standaard aan,
en laat HTTP/1.1 als fallback.”

  • De meeste webservers (Nginx, Apache, Envoy, etc.) en CDN’s onderhandelen automatisch door alleen de optie voor HTTP/2 in te schakelen.

  • Op applicatieniveau is het vrijwel nooit nodig om “deze aanvraag met 1.1 te verzenden, die met 2” te splitsen.

Dus, als je een nieuwe service maakt, beschouw dan ‘HTTPS met HTTP/2 aan’ als de standaardinstelling.

4-2. Interne API / Microservices communicatie

Hier zijn er iets meer keuzes.

  • Als je al goed draait met REST + HTTP/1.1,

  • is er meestal geen noodzaak om opnieuw naar HTTP/2 te herschrijven.

  • Maar,

    • als je zeer korte aanvragen heel vaak verstuurt tussen dezelfde diensten,

    • of een HTTP/2-gebaseerd protocol zoals gRPC gebruikt,
      moet je HTTP/2 gebruiken.

Dat betekent:

  • “Bestaande legacy REST API” → behoud 1.1 + gebruik eventueel HTTP/2-terminatie in proxy/loadbalancer

  • “Nieuwe gRPC implementatie, hoge frequentie microservices-aanroepen” → gebruik actief HTTP/2

4-3. Debugging, logging, legacy omgevingen

HTTP/1.1 is nog steeds nuttig in bepaalde situaties.

  • Tekstgebaseerd, dus makkelijk te bekijken in tcpdump, Wireshark

  • Oude proxies/firewalls/clients ondersteunen misschien geen HTTP/2

  • In eenvoudige interne tools of testservers is het vaak voldoende om HTTP/2 niet te gebruiken.

In feite zien veel omgevingen er als volgt uit:

  • Externe (browser) ↔ frontproxy (CDN/Load Balancer) : HTTP/2

  • Proxy ↔ backend service : HTTP/1.1

Structuren zijn vaak gemengd.

5. Realistische antwoorden op de vraag: “Kan ik alleen HTTP/2 gebruiken?”

Theoretisch kun je zeggen:

“Als je een nieuwe publieke webdienst maakt, kun je HTTP/2 als standaard beschouwen.”

Dat klopt.

Maar in de praktijk:

  1. Het is moeilijk om HTTP/1.1 volledig af te schaffen

    • Oude clients of speciale omgevingen ondersteunen misschien nog alleen 1.1.

    • Debugging/tools/interne systemen zijn in veel gevallen gemakkelijker met 1.1.

  2. Vanuit het serverperspectief is “ondersteuning voor beide” gebruikelijk

    • Webserverinstellingen zoals h2 http/1.1 inschakelen

    • Laat de client automatisch het beste protocol kiezen.

  3. Het is het tijdperk waarin ook HTTP/3 (QUIC) in overweging wordt genomen

    • Moderne browsers en diensten ondersteunen al HTTP/3.

    • Maar dit wordt ook meestal gedaan door tegelijkertijd “HTTP/1.1 + HTTP/2 + HTTP/3” open te houden,

Dus de realistische conclusie is:

“In plaats van vast te houden aan uitsluitend HTTP/2,
is het het beste om HTTP/2 standaard in te schakelen en HTTP/1.1 als een natuurlijk fallback te beschouwen.”

Dat is het.

Vergelijking van verzendmethoden per HTTP-versie

6. Samenvatting

Om het allemaal samen te vatten:

  • HTTP/1.1

    • Tekst-gebaseerd

    • Persistent connection + (theoretische) pipelining

    • Vanwege het HOL Blocking probleem maken browsers meerdere TCP-verbindingen open om te gebruiken

  • HTTP/2

    • Binaire framing

    • Multiplexing voor meerdere streams over één TCP-verbinding

    • HPACK headercompressie

    • Server push is feitelijk dood in de praktijk

  • Gebruikstrategie

    • Externe webdiensten (voor browsers): Zet HTTPS + HTTP/2 aan en laat HTTP/1.1 als fallback

    • Interne API: Bestaande REST is prima met 1.1, maar bij hoge frequentie/streaming/gRPC, gebruik dan actief HTTP/2

    • Debugging/legacy: HTTP/1.1 blijft nuttig en bruikbaar

Een zin die ontwikkelaars zouden moeten onthouden:

“Maak je geen zorgen over het kiezen van versies in de app-code,
schakel HTTP/2 op de server in en laat de rest aan protocolonderhandeling (ALPN).”