HTTP/2: Multiplexing, Header-Kompression und Server Push
Kurz: HTTP/2 überträgt viele Anfragen gleichzeitig über eine einzige Verbindung, komprimiert Header und macht Webseiten damit schneller als HTTP/1.1.
Genauer: HTTP/1.1 behandelt pro Verbindung eine Anfrage nach der anderen; Browser öffnen deshalb mehrere Verbindungen und kämpfen mit Head-of-Line-Blocking (eine langsame Antwort hält alle dahinter auf). HTTP/2 (2015) löst viele dieser Probleme, ohne die Bedeutung von Methoden, Statuscodes und Headern zu ändern.
Im Detail
Wesentliche Neuerungen
- Binäres Protokoll statt Text: kompakter und schneller zu verarbeiten.
- Multiplexing: Viele Streams laufen parallel über eine TCP-Verbindung; Frames verschiedener Anfragen werden vermischt.
- Header-Kompression (HPACK): Wiederkehrende Header (Cookies, User-Agent) werden nur einmal vollständig gesendet.
- Priorisierung von Streams.
- Server Push: Server schickt Ressourcen ungefragt voraus (in der Praxis kaum genutzt und von Browsern entfernt).
Folgen für die Webentwicklung
Früher half es, viele kleine Dateien zu bündeln (Sprites, Concatenation) und über mehrere Domains zu verteilen (Domain Sharding). Mit HTTP/2 ist das oft unnötig oder schädlich; viele kleine Dateien sind kein großes Problem mehr, dennoch bleibt Bündeln zur Verringerung von Overhead und für Caching sinnvoll. Browser nutzen HTTP/2 nur über HTTPS.
Grenzen und Nachfolger
HTTP/2 läuft über TCP: Geht ein Paket verloren, wartet die ganze Verbindung (Head-of-Line-Blocking auf TCP-Ebene). HTTP/3 setzt auf QUIC (über UDP), pro Stream unabhängig, mit schnellerem Verbindungsaufbau und Verbindungswechsel (WLAN zu Mobilfunk). Server sagen per Alt-Svc, dass HTTP/3 verfügbar ist.
Prüfen
Im Browser unter F12 → Netzwerk die Spalte Protokoll ansehen (h2, h3). Im Terminal: curl -I --http2 https://beispiel.de. Webserver wie Nginx, Caddy und Apache aktivieren HTTP/2 mit einer Zeile Konfiguration, CDNs bieten es automatisch.
Siehe auch: QUIC und HTTP/3, HTTP Keep-Alive, HTTP-Header, TLS