Wenn es um die Versionen von HTTP geht, denken viele wahrscheinlich an folgendes:

„Ist das Web nicht sowieso alles HTTP? Was ist eigentlich der Unterschied zwischen 1.1 und 2?“
„Kann man nicht einfach die neue Version HTTP/2 verwenden?“

Zusammengefasst:

  • HTTP/1.1 vs HTTP/2 ist eher ein Unterschied im Sendemuster, um den gleichen HTTP-Inhalt (Methoden/Häufigkeit/Zustandscodes usw.) effizienter zu übertragen.

  • In der Praxis besteht die Struktur nicht darin, „einen von beiden zu wählen“, sondern dass der Server beide unterstützt und der Client die mögliche Variante auswählt.

Im Folgenden werde ich die wichtigsten Punkte aus der Perspektive eines Entwicklers zusammenfassen.

1. Kurzüberblick über HTTP/1.1

Commandbox 광고

1) Textbasiertes Protokoll

HTTP/1.1 ist die Art von Anfragen/Antworten, die wir normalerweise sehen.

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>

  • Es ist textbasiert, was es leicht lesbar und einfach debugbar macht,

  • und Tools wie curl, telnet, nc können verwendet werden, um die Struktur zu überprüfen.

2) Persistente Verbindung + Pipelining

Ein großes Problem bei HTTP/1.0 war, dass für jede Anfrage eine neue TCP-Verbindung geöffnet werden musste,
aber in HTTP/1.1 ist die Standardverbindung persistent connection (keep-alive),
was es ermöglicht, mehrere Anfragen nacheinander über eine Verbindung zu senden.

Zusätzlich gibt es eine Funktion namens HTTP-Pipelining:

  • Anfragen zu senden, ohne auf die Antwort zu warten

  • und die Antworten in der richtigen Reihenfolge zu erhalten.

In der Praxis wurde es jedoch kaum von Browsern genutzt,
und es blieb ein „Struktur, die in der richtigen Reihenfolge bearbeitet werden muss“, wodurch Leistungsprobleme bestehen blieben.

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

Ein typischer Flaschenhals von HTTP/1.1 ist das HOL (Head-of-Line) Blocking.

  • Da Anfragen in einer einzigen Verbindung nacheinander verarbeitet werden müssen,

  • müssen alle nachfolgenden Anfragen warten, wenn die erste langsam ist.

  • Um dieses Problem zu mildern, öffnen Browser mehrere TCP-Verbindungen pro Domain (z. B. maximal 6).

Zusammengefasst:

HTTP/1.1 „schafft mehrere Leitungen, um Engpässe zu minimieren“.
(Mehrere TCP-Verbindungen)

2. Was ist anders bei HTTP/2?

Das Ziel von HTTP/2 ist klar.

  • Die Latenz zu reduzieren

  • Netzwerkressourcen effizienter zu nutzen

Die Schlüsselpunkte sind:

  1. Binär-Frame (Binary Framing)

  2. Stream-basiertes Multiplexing

  3. Header-Kompression (HPACK)

  4. (Ursprünglich) Server Push – praktisch tot in Browsern

2-1. Text → Binär-Frame

HTTP/1.1 ist zeilenbasiert, aber HTTP/2 zerlegt alles in Frames, die binäre Stücke sind.

  • Header ist im HEADERS-Frame

  • Der Body ist im DATA-Frame

  • Diese Frames gehören zu einer bestimmten Stream-ID.

Entwickler arbeiten selten direkt mit Frames,
aber dies ermöglicht Funktionen wie Multiplexing, Header-Kompression und Priorisierung.

2-2. Multiplexing

Das ist der spürbarste Unterschied.

  • HTTP/1.1: Anfragen und Antworten werden nacheinander verarbeitet

  • HTTP/2: Mehrere Streams werden gleichzeitig über eine TCP-Verbindung gesendet

Das bedeutet:

„Es ist nicht nötig, mehrere TCP-Verbindungen zu öffnen,
man kann Anfragen und Antworten innerhalb einer einzigen Verbindung gleichzeitig senden.“

So kann:

  • Eine HTML-Seite, die Dutzende bis Hunderte von Ressourcen benötigt, auch gleichzeitig geladen werden,

  • während nur eine Verbindung aufrechterhalten wird,

  • besonders in mobilen Umgebungen und bei hohen RTTs großen Nutzen bringt.

Allerdings bleibt HOL Blocking auf TCP-Ebene bestehen, sodass dieser Punkt in HTTP/3 (QUIC) weiter verbessert wird.

2-3. Header-Kompression (HPACK)

HTTP-Anfrage/Antwort-Header sind oft sehr redundant.

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

  • Diese können pro Anfrage mehrere Hundert KB beanspruchen.

HTTP/2 verwendet eine Komprimierungstechnik namens HPACK, um
Redundanzen zwischen diesen Headern zu reduzieren.

  • Häufig verwendete Header werden in einer Tabelle registriert und mit kurzen Indizes gesendet.

  • Nur die Teile, die sich von vorherigen Anfragen unterscheiden, werden effizient kodiert.

Das bringt großen Nutzen, insbesondere für SPA mit vielen Anfragen / ressourcenintensive Seiten.

2-4. Server Push ist praktisch tot

Zu Beginn von HTTP/2 wurde die Funktion Server Push, bei der der Server CSS/JS vor dem Anfordern durch den Client sendet, als großer Vorteil angesehen. In der Praxis:

  • die Implementierung ist schwierig

  • es gibt Probleme mit Caching und doppelten Ressourcen

  • die tatsächliche Leistungsverbesserung ist minimal oder in einigen Fällen sogar schlechter

Deshalb wurde es in Chrome/Chromium seit 2022 standardmäßig deaktiviert (Chrome für Entwickler)
und Firefox plant ebenfalls, die Unterstützung in den 2020er Jahren zu entfernen, wodurch dieses Feature in der Browserlandschaft praktisch beendet ist.

Wenn heute über HTTP/2 gesprochen wird, betrachten wir Server Push bestenfalls als eine „historische Funktion“.

3. HTTPS, ALPN und die Wahl zwischen „h2 und http/1.1“

Commandbox 광고

In der Praxis wird die Frage, ob man „HTTP/1.1 oder HTTP/2 verwenden soll“
während des TLS Handshake-Prozesses zwischen Client und Server automatisch ausgehandelt.

Dies erfolgt durch eine TLS-Erweiterung namens ALPN (Application-Layer Protocol Negotiation).

  • Client: „Ich kann sowohl h2 als auch http/1.1“

  • Server: „Lass uns h2 verwenden“ (oder „Ich kann nur http/1.1“)

Beispielkonfiguration für Apache:

Protocols h2 http/1.1

Wenn so eingestellt:

  • Aktuelle Browser, die HTTP/2 unterstützen, verwenden automatisch HTTP/2 (h2)

  • Ältere Clients kommunizieren automatisch über HTTP/1.1

Die meisten gängigen Browser unterstützen bereits HTTP/2 gut,
und viele Webseiten haben HTTP/2 aktiviert.

4. „Wann sollte man es getrennt verwenden?“ – Zusammenfassung aus Entwicklersicht

Schauen wir uns den Kern dieser Frage in verschiedenen Anwendungsfällen an.

4-1. Allgemeine Webdienste (für Browser)

Eine fast perfekte Strategie:

„HTTPS + HTTP/2 standardmäßig aktivieren,
und HTTP/1.1 als Fallback belassen.“

  • Die meisten Webserver (Nginx, Apache, Envoy usw.) und CDNs
    verhandeln automatisch, wenn man nur die HTTP/2 Unterstützung einschaltet.

  • Es gibt in der Regel kaum Situationen auf Anwendungsebene, in denen man „diese Anfrage ist 1.1, jene ist 2“ direkt trennen muss.

Das heißt, wenn man einen neuen Dienst erstellt, sollte man HTTPS mit aktivem HTTP/2 als Standardoption betrachten.

4-2. Interne API / Mikrodiensten-Kommunikation

Hier gibt es etwas mehr Auswahl.

  • Wenn es bereits gut mit REST + HTTP/1.1 funktioniert,
    gibt es keinen zwingenden Grund, es auf HTTP/2 umzustellen.

  • Allerdings,

    • wenn zwischen den gleichen Diensten sehr viele kurze Anfragen ausgetauscht werden

    • oder wenn man ein HTTP/2-basiertes Protokoll wie gRPC verwendet,
      dann ist es nur sinnvoll, HTTP/2 zu verwenden.

Das heißt:

  • „Bestehende legacys REST-APIs“ → 1.1 beibehalten + HTTP/2-Termination bei Bedarf im Proxy/Loadbalancer verwenden

  • „Neu gRPC implementieren, hochfrequentierte Mikrodienstaufrufe“ → aktiv HTTP/2 nutzen

4-3. Debugging, Logging, Legacy-Umgebungen

HTTP/1.1 ist auch in einigen Situationen nach wie vor nützlich.

  • Textbasiert, wodurch es in tcpdump, Wireshark leicht lesbar ist

  • Ältere Proxys/Firewalls/Clients unterstützen möglicherweise kein HTTP/2

  • Bei einfachen internen Tools oder Testservern ist HTTP/2 möglicherweise nicht notwendig.

In vielen Umgebungen ist es tatsächlich so:

  • Extern (Browser) ↔ Front End Proxy (CDN/Load Balancer) : HTTP/2

  • Proxy ↔ Backend-Dienste : HTTP/1.1

In vielen Fällen gibt es eine gemischte Struktur.

5. Realität zu der Frage „Kann ich nicht nur HTTP/2 verwenden?“

Theoretisch könnte man sagen:

„Wenn man einen neuen öffentlichen Webdienst erstellt, kann man HTTP/2 als Standard ansetzen.“

Aber in der Praxis:

  1. Es ist schwierig, HTTP/1.1 vollständig zu eliminieren

    • Ältere Clients oder besondere Umgebungen unterstützen oft nur 1.1

    • In Debugging/Tools/internen Systemen ist 1.1 oft bequemer.

  2. Für Server ist es üblich, „beide zu unterstützen“

    • Servereinstellungen wie h2 http/1.1 aktivieren,

  3. und den Clients überlassen, den besten unterstützten Protokoll auszuwählen.

  4. Wir leben in einer Zeit, in der auch HTTP/3 (QUIC) in Betracht gezogen wird

    • Aktuelle Browser/Dienste unterstützen bereits HTTP/3

    • Aber dies geschieht normalerweise, indem man „HTTP/1.1 + HTTP/2 + HTTP/3“ gleichzeitig aktiviert und
      es den Clients überlässt, auszuhandeln.

Somit ist die realistische Schlussfolgerung:

„Statt nur auf HTTP/2 zu bestehen,
ist es am besten, HTTP/2 standardmäßig zu aktivieren und HTTP/1.1 als natürlichen Fallback zu nutzen.“

Das ist meine Empfehlung.

Vergleich der Übertragungsmethoden nach HTTP-Version

6. Zusammenfassung

Wenn wir es zusammenfassen:

  • HTTP/1.1

    • Textbasiert

    • Persistente Verbindung + (theoretisches) Pipelining

    • Wegen des HOL Blocking Problems öffnen Browser mehrere TCP-Verbindungen.

  • HTTP/2

    • Binär-Frame

    • Multiplexing, wo mehrere Streams gleichzeitig über eine TCP-Verbindung bearbeitet werden

    • HPACK Header-Kompression

    • Server-Push ist in der Praxis praktisch tot.

  • Verwendungsstrategie

    • Äußeres Web (für Browser): HTTPS + HTTP/2 aktivieren und HTTP/1.1 als Fallback beibehalten.

    • Interne API: Bestehende REST kann auf 1.1 bleiben, bei hochfrequentierten/Streaming/gRPC-Fällen HTTP/2 aktiv nutzen.

    • Debugging/Legacy: HTTP/1.1 bleibt bequem und nützlich.

Eine wichtige Erkenntnis für Entwickler:

„Versuche nicht im Anwendungs-Code darüber nachzudenken, welche Version du wählen solltest,
lass den Server HTTP/2 aktivieren und überlasse die Protokollverhandlung (ALPN) ihm.“