HTTP/2 vs HTTP/3: Webprotokolle im Vergleich

Wer heute eine Website betreibt oder entwickelt, kommt an der Frage nicht vorbei: Welches HTTP-Protokoll sorgt für die beste Performance? Während HTTP/2 seit 2015 der Standard ist und von nahezu allen Browsern unterstützt wird, gewinnt HTTP/3 mit seinem QUIC-Unterbau rasant an Bedeutung. In diesem Artikel vergleichen wir beide Protokolle im Detail, zeigen konkrete Konfigurationen und helfen dir bei der Entscheidung, welches Protokoll du wann einsetzen solltest.

Die Evolution der Webprotokolle

HTTP/1.1 hat das Web über anderthalb Jahrzehnte getragen – mit all seinen Limitierungen. Das größte Problem: Für jede Ressource wurde eine eigene TCP-Verbindung benötigt, was zu Head-of-Line-Blocking und hohen Latenzen führte. HTTP/2 löste viele dieser Probleme, doch erst HTTP/3 geht den radikalen Schritt, TCP komplett durch das QUIC-Protokoll zu ersetzen.

HTTP/2: Der erste große Sprung

HTTP/2 basiert weiterhin auf TCP und bringt folgende Kernfeatures mit:

• Multiplexing: Mehrere Requests über eine einzige TCP-Verbindung
• Header-Kompression (HPACK): Reduziert redundante Header-Daten
• Server Push: Der Server kann Ressourcen proaktiv senden
• Stream Prioritization: Wichtige Ressourcen werden bevorzugt geladen

HTTP/3: Die QUIC-Revolution

HTTP/3 ersetzt TCP durch QUIC (Quick UDP Internet Connections) und setzt auf UDP als Transportprotokoll. Die wichtigsten Neuerungen:

• 0-RTT Connection Establishment: Verbindungsaufbau ohne Round-Trip-Verzögerung
• Unabhängiges Stream-Multiplexing: Kein Head-of-Line-Blocking auf Transportebene
• Integrierte TLS 1.3-Verschlüsselung: Sicherheit ist fest eingebaut
• Connection Migration: Verbindungen überleben Netzwerkwechsel (z. B. WLAN → Mobilfunk)

Head-of-Line-Blocking: Der entscheidende Unterschied

Das Head-of-Line-Blocking ist der zentrale Punkt, an dem sich HTTP/2 und HTTP/3 unterscheiden. Bei HTTP/2 teilen sich alle Streams eine einzige TCP-Verbindung. Geht ein einzelnes Paket verloren, blockiert TCP alle Streams, bis das Paket erneut übertragen wurde.

QUIC löst dieses Problem elegant: Jeder Stream wird unabhängig behandelt. Ein Paketverlust in Stream A hat keinerlei Auswirkung auf Stream B. Gerade bei instabilen Netzwerken – etwa Mobilfunkverbindungen – ist dieser Unterschied dramatisch spürbar.

Verbindungsaufbau im Vergleich

Der Verbindungsaufbau zeigt den Geschwindigkeitsvorteil von HTTP/3 besonders deutlich:

Schritt	HTTP/2 (TCP + TLS 1.3)	HTTP/3 (QUIC)
TCP-Handshake	1 RTT	entfällt
TLS-Handshake	1 RTT	im QUIC-Handshake integriert
Gesamt (Erstverbindung)	2 RTT	1 RTT
Gesamt (Wiederverbindung)	2 RTT	0 RTT

Besonders der 0-RTT-Modus bei wiederkehrenden Verbindungen ist ein Gamechanger. Der Client kann sofort Daten senden, ohne auf eine Bestätigung des Servers zu warten.

Praxisbeispiel: Nginx für HTTP/2 und HTTP/3 konfigurieren

HTTP/2 aktivieren

Die Aktivierung von HTTP/2 in Nginx ist seit Jahren Standard und unkompliziert:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        root /var/www/html;
        index index.html;
    }
}

HTTP/3 zusätzlich aktivieren

Für HTTP/3 benötigst du Nginx ab Version 1.25.0 (mit QUIC-Unterstützung) oder einen alternativen Build. Die Konfiguration erweitert sich wie folgt:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;

    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.3;
    ssl_early_data on;

    # Alt-Svc Header für HTTP/3-Erkennung durch den Browser
    add_header Alt-Svc 'h3=":443"; ma=86400';

    location / {
        root /var/www/html;
        index index.html;
    }
}

Der Alt-Svc-Header ist entscheidend: Er signalisiert dem Browser, dass HTTP/3 verfügbar ist. Der Browser verbindet sich zunächst per HTTP/2 und wechselt dann bei der nächsten Anfrage auf QUIC.

Firewall-Konfiguration nicht vergessen

Da QUIC auf UDP basiert, muss Port 443/UDP in der Firewall geöffnet sein:

# UFW (Ubuntu)
sudo ufw allow 443/udp

# iptables
sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT

# firewalld (CentOS/RHEL)
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

HTTP/3-Unterstützung prüfen

Mit curl lässt sich schnell testen, ob ein Server HTTP/3 unterstützt:

# HTTP/3-Verbindung erzwingen (curl >= 7.88 mit HTTP/3-Support)
curl -I --http3 https://example.com

# Alt-Svc-Header prüfen
curl -sI https://example.com | grep -i alt-svc

Alternativ bietet sich das Tool h3spec an, um die QUIC-Konformität eines Servers zu validieren:

# h3spec installieren und ausführen
go install github.com/nicholasgasior/h3spec@latest
h3spec -host example.com -port 443

Performance-Vergleich in der Praxis

Die theoretischen Vorteile von HTTP/3 zeigen sich besonders in bestimmten Szenarien. Hier eine realistische Einordnung:

Wo HTTP/3 klar gewinnt

• Mobile Netzwerke: Hohe Paketverlustrate und Netzwerkwechsel (Connection Migration)
• Hohe Latenzen: Interkontinentale Verbindungen profitieren vom schnelleren Handshake
• Viele kleine Ressourcen: Unabhängiges Multiplexing vermeidet Blockaden
• Wiederkehrende Besucher: 0-RTT-Verbindungen sparen wertvolle Millisekunden

Wo der Unterschied marginal ist

• Stabile Kabelverbindungen: Bei geringer Latenz und ohne Paketverluste ist der Vorteil minimal
• Wenige Ressourcen pro Seite: Einfache Seiten mit wenig Assets profitieren kaum
• CDN-Nutzung: Moderne CDNs wie Cloudflare oder Fastly übernehmen HTTP/3 automatisch

CDN-Integration: HTTP/3 ohne eigenen Server

Die einfachste Methode, HTTP/3 zu nutzen, ist ein CDN mit nativer QUIC-Unterstützung. Cloudflare beispielsweise aktiviert HTTP/3 mit einem Klick. Für die programmatische Konfiguration per API:

# Cloudflare: HTTP/3 per API aktivieren
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/h3" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'

Docker-Setup mit Caddy und automatischem HTTP/3

Caddy ist ein Webserver, der HTTP/3 standardmäßig aktiviert hat. Ein minimales Docker-Setup:

# docker-compose.yml
version: "3.8"
services:
  caddy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"  # Wichtig für QUIC/HTTP/3
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./site:/srv
      - caddy_data:/data

volumes:
  caddy_data:

# Caddyfile
example.com {
    root * /srv
    file_server
    encode gzip zstd
}

Caddy übernimmt TLS-Zertifikate, HTTP/2 und HTTP/3 vollautomatisch – ohne eine Zeile zusätzliche Konfiguration.

Sicherheitsaspekte

Beide Protokolle setzen auf TLS-Verschlüsselung, unterscheiden sich aber in der Implementierung:

• HTTP/2 unterstützt TLS 1.2 und 1.3, wobei TLS 1.3 empfohlen wird
• HTTP/3 erzwingt TLS 1.3 – ältere Versionen sind nicht möglich
• QUIC verschlüsselt zusätzlich Metadaten, die bei TCP im Klartext übertragen werden (z. B. Paketnummern)

Das macht HTTP/3 aus Sicherheitsperspektive zum überlegenen Protokoll. Allerdings stellt die UDP-Basis manche Firewalls und Intrusion-Detection-Systeme vor Herausforderungen, da Deep Packet Inspection bei QUIC deutlich schwieriger ist.

Fazit

HTTP/2 bleibt ein solides, ausgereiftes Protokoll, das auf absehbare Zeit als Fallback unverzichtbar ist. HTTP/3 mit QUIC ist jedoch der klare Nachfolger und bietet messbare Vorteile – insbesondere bei mobilen Nutzern, instabilen Netzwerken und wiederkehrenden Besuchern.

Die Empfehlung für 2024 und darüber hinaus ist eindeutig: Setze beide Protokolle parallel ein. HTTP/3 als bevorzugtes Protokoll, HTTP/2 als Fallback. Mit modernen Webservern wie Caddy oder aktuellen Nginx-Versionen ist das in wenigen Minuten konfiguriert. Wer ein CDN nutzt, bekommt HTTP/3-Support oft ohne jeglichen Aufwand.

Prüfe mit den gezeigten Befehlen, ob dein Server bereits HTTP/3 spricht – und falls nicht, ist jetzt der richtige Zeitpunkt für die Umstellung.