HTTP/2 ist die zweite große Version des Hypertext Transfer Protocol und die Grundlage der meisten heutigen Webseiten. Statt wie HTTP/1.1 für jede Anfrage eine eigene Verbindung aufzubauen, bündelt HTTP/2 viele parallele Anfragen in einer TCP-Verbindung. Standardisiert wurde es 2015 in RFC 7540; seit Juni 2022 ist die überarbeitete Fassung RFC 9113 maßgeblich.
Binäres Framing statt Textzeilen
HTTP/1.1 schickte Anfragen und Antworten als Text mit Zeilenenden – schwer zu parsen und anfällig für Fehler. HTTP/2 teilt den Datenstrom in kleine binäre Frames mit festem Format (9-Byte-Kopf plus Nutzdaten). Die wichtigsten Frame-Typen sind HEADERS (überträgt die HTTP-Header), DATA (Nutzdaten) und RST_STREAM (bricht einen einzelnen Stream ab). Durch die binäre Kodierung lässt sich der Datenstrom robust in einzelne Streams zerlegen.
Multiplexing ohne Head-of-Line-Blocking auf Anwendungsebene
Jeder Request-Response-Zyklus läuft in HTTP/2 als eigener Stream mit einer 31-Bit-Stream-ID. Viele Streams teilen sich eine einzige TCP-Verbindung; die Frames der Streams werden verschränkt (multiplexed) übertragen. Damit entfällt das Head-of-Line-Blocking von HTTP/1.1, bei dem langsame Antworten alle nachfolgenden Anfragen auf derselben Verbindung blockierten. Achtung: Weil HTTP/2 weiterhin über TCP läuft, bleibt ein Rest-Risiko auf Transportebene – verliert TCP ein Segment, warten vorübergehend alle Streams. Dieses Restproblem löste erst HTTP/3 mit QUIC.
HPACK-Header-Kompression
HTTP-Header wie Cookie, User-Agent oder Accept wiederholen sich bei jeder Anfrage. HTTP/2 komprimiert sie mit HPACK (RFC 7541): Eine statische Tabelle mit 61 vordefinierten Feldern und eine dynamische, verbindungsgebundene Tabelle erlauben es, häufige Header als kurze Indexverweise zu kodieren; zusätzlich kommen Huffman-Kodierung und Integer-Kompaktdarstellung zum Einsatz. So sinkt der Overhead spürbar – auf kleinen Verbindungen oft um 80 Prozent und mehr.
Priorisierung und Server Push
Clients können Streams mit Gewichten priorisieren, sodass der Server wichtige Ressourcen (zum Beispiel CSS oder Bilder über dem Falz) zuerst sendet. Das 2015 eingeführte Server Push sollte es Servern erlauben, Ressourcen vorausschauend mitzuschicken, bevor der Browser sie anfordert. In der Praxis erwies sich Push als komplex und oft kontraproduktiv (doppelte Übertragungen, Cache-Probleme): Chrome entfernte die Unterstützung 2022, Firefox und die meisten Server folgten. HTTP/3 (RFC 9114) hat Push nie vorgesehen; empfohlen ist stattdessen das Link-Preload-Header-Feld.
Aushandlung per ALPN
HTTP/2 wird fast immer über TLS genutzt. Beim TLS-Handshake handeln Client und Server über die ALPN-Erweiterung (Application-Layer Protocol Negotiation) aus, welches Protokoll sie sprechen: h2 bedeutet HTTP/2 über TLS, h2c (nur selten genutzt) HTTP/2 ohne TLS. Unterstützt wird HTTP/2 von allen gängigen Browsern, Webservern (Apache, nginx) und CDNs; praktisch alle Webseiten, die HTTPS ausliefern, nutzen es.
Verwandte Grundlagen: QPACK, WebTransport, HTTP/3, WebSocket.