HTTP/1.1, HTTP/2 und HTTP/3: die Unterschiede, die ein Betriebsteam bemerkt

Worum es geht

HTTP/1.1 (RFC 9112) rahmt Nachrichten als Text: eine Anfragezeile, Header-Zeilen, einen optionalen Body, begrenzt durch Content-Length oder Chunked Transfer Coding. Verbindungen sind standardmässig persistent, doch Antworten müssen in der Reihenfolge der Anfragen zurückkommen, sodass Clients warten oder mehrere Verbindungen öffnen. HTTP/2 (RFC 9113) behält dieselbe Semantik bei, verwendet aber binäre Frames, viele gleichzeitige Streams auf einer Verbindung, HPACK-Header-Kompression und Flusskontrolle pro Stream. Es wird über ALPN als h2 bei TLS ausgehandelt; unverschlüsseltes h2c existiert nur mit vorherigem Wissen, da die RFC den Upgrade-Pfad als veraltet einstuft. HTTP/3 (RFC 9114) trägt dieselbe Semantik über QUIC, einen UDP-basierten Transport mit eingebautem TLS 1.3; jeder Anfrage-Stream wird unabhängig zugestellt, sodass ein verlorenes Paket nur seinen eigenen Stream verzögert, und Header verwenden QPACK, was das Head-of-Line-Blocking begrenzt, das Kompression sonst verursachen könnte. Clients erfahren von einem HTTP/3-Endpunkt über einen Alt-Svc-Header (RFC 9114) oder einen HTTPS-DNS-Eintrag (RFC 9460) und sollten auf TCP-basiertes HTTP zurückfallen, wenn die QUIC-Verbindung scheitert, etwa weil UDP blockiert ist.

Warum es wichtig ist

Die Version ändert, was das Betriebsteam konfigurieren muss und beobachten kann. HTTP/2 konzentriert den Verkehr eines Browsers auf eine Verbindung, sodass ein einziger Verbindungsabbruch oder eine einzige langsame TCP-Neuübertragung alle Streams gleichzeitig stocken lässt; Verbindungslimits pro Client bedeuten etwas anderes als bei HTTP/1.1. HTTP/3 bedeutet, dass der angekündigte UDP-Port (RFC 9114 erlaubt jeden Port; Alt-Svc benennt ihn stets explizit) in Firewalls, Security Groups und Load Balancern offen sein muss, und Paketmitschnitte zeigen verschlüsseltes UDP statt lesbarer TLS-Datensätze.

So wird es angewendet

• HTTP/2 und HTTP/3 am Rand terminieren (Reverse Proxy oder Load Balancer) und mit Anwendungsservern HTTP/1.1 sprechen, sofern diese nicht von Multiplexing profitieren; das hält die Verbindungsbehandlung der Anwendung einfach.
• HTTP/3 erst ankündigen, nachdem die UDP-Erreichbarkeit von aussen getestet wurde; ein falsches Alt-Svc kostet Clients einen gescheiterten Versuch, bevor sie zurückfallen.
• Limits pro Stream (SETTINGS_MAX_CONCURRENT_STREAMS) und Grössenlimits für Anfrage-Bodys im Proxy halten; Multiplexing macht es für einen Client günstig, viele Anfragen zu öffnen.
• Das ausgehandelte Protokoll pro Anfrage protokollieren, damit sich versionsspezifische Probleme im Access-Log trennen lassen.

Stolpersteine

Header-Namen sind bei HTTP/2 und HTTP/3 kleingeschrieben, und einige Header (Connection, Transfer-Encoding) sind verboten; Middleware, die Header umschreibt, muss beide Formen handhaben. RFC 9113 hält fest, dass der unverschlüsselte Upgrade-Pfad nie breit eingesetzt wurde; Browser sprechen HTTP/2 nur über TLS mit ALPN, sodass h2c eine Server-zu-Server-Option ist. QUIC-Connection-IDs erlauben es einem Client, die Adresse mitten in der Verbindung zu wechseln, was zustandsloses Load Balancing nach 4-Tupel nicht handhabt.