HTTP/2 und Proxy

Proxy-Dienste unterstützen HTTP/2, indem sie als Vermittler fungieren, der entweder HTTP/2-Verbindungen terminieren und Anfragen über HTTP/1.1 an Ursprungsserver weiterleiten oder HTTP/2 Ende-zu-Ende zwischen Client und Ursprung durchleiten kann.

HTTP/2 ist eine wesentliche Überarbeitung des HTTP-Protokolls, die darauf abzielt, die Web-Performance durch die Behebung inhärenter Einschränkungen von HTTP/1.1 zu verbessern. Zu den Hauptmerkmalen gehören vollständiges Anforderungs- und Antwort-Multiplexing, Header-Kompression mittels HPACK, Server-Push und Anforderungspriorisierung. Für einen Proxy-Dienst erfordert die Verwaltung dieser Funktionen spezifische architektonische Überlegungen, um die Vorteile von HTTP/2 zu nutzen und gleichzeitig Kompatibilität und Kontrolle aufrechtzuerhalten.

HTTP/2-Protokollgrundlagen

HTTP/2 arbeitet über eine einzige TCP-Verbindung und etabliert mehrere bidirektionale Streams für die gleichzeitige Übertragung von Anforderungs- und Antwortnachrichten. Dieses Multiplexing eliminiert das Head-of-Line-Blocking, das in HTTP/1.1 vorhanden ist. Die Header-Kompression (HPACK) reduziert den Overhead, indem HTTP-Header in einem kompakten Binärformat kodiert und eine gemeinsame dynamische Tabelle verwaltet wird. Server-Push ermöglicht es dem Server, Ressourcen proaktiv an den Client zu senden, von denen er annimmt, dass sie benötigt werden, wodurch die Latenz reduziert wird.

Diese Funktionen sind zwar vorteilhaft, führen jedoch zu Komplexitäten für Proxy-Dienste, die traditionell nach einem Anforderungs-Antwort-Modell über individuelle TCP-Verbindungen arbeiten.

Proxy-Architekturen für HTTP/2

Proxy-Dienste implementieren typischerweise eine von zwei primären Architekturen für die HTTP/2-Unterstützung: Terminierung oder Ende-zu-Ende.

HTTP/2-Terminierung (Frontend HTTP/2, Backend HTTP/1.1)

In diesem Modell stellt der Proxy-Server eine HTTP/2-Verbindung mit dem Client her. Er terminiert das HTTP/2-Protokoll, dekodiert Anfragen und leitet diese dann unter Verwendung von HTTP/1.1 an den Ursprungsserver weiter. Die Antworten vom Ursprungsserver (HTTP/1.1) werden dann zurück in HTTP/2 transkodiert und an den Client gesendet.

Ablauf:

1. Der Client initiiert eine HTTP/2-Verbindung zum Proxy (typischerweise über TLS mit ALPN, das h2 aushandelt).
2. Der Proxy empfängt HTTP/2-Frames, rekonstruiert HTTP/1.1-ähnliche Anfragen (einschließlich der Dekodierung von HPACK-Headern).
3. Der Proxy leitet HTTP/1.1-Anfragen an den Ursprungsserver weiter.
4. Der Ursprungsserver antwortet mit HTTP/1.1.
5. Der Proxy empfängt HTTP/1.1-Antworten, kodiert sie in HTTP/2-Frames (einschließlich HPACK-Kompression) und sendet sie an den Client.

Vorteile:

• Backend-Kompatibilität: Ursprungsserver müssen HTTP/2 nicht unterstützen. Dies ist vorteilhaft für Altsysteme oder Dienste, die noch nicht aktualisiert wurden.
• Entlastung: Der Proxy übernimmt den Rechen-Overhead der HTTP/2-Protokoll-Aushandlung, der Header-Kompression/-Dekomprimierung und der Stream-Verwaltung, wodurch die Last auf den Ursprungsservern reduziert wird.
• Kontrolle: Es ist einfacher, traditionelle Proxy-Funktionen wie Caching, Lastverteilung, Anforderungsmodifikation und Sicherheitsfilterung durchzuführen, die oft für HTTP/1.1-Semantik konzipiert sind.

Nachteile:

• Funktionsverlust: HTTP/2-Funktionen wie Server-Push vom Ursprungsserver können nicht direkt durchgeleitet werden. Der Proxy müsste seine eigene Server-Push-Logik implementieren.
• Protokoll-Mismatch-Overhead: Die konstante Transkodierung zwischen HTTP/2 und HTTP/1.1 führt zu Verarbeitungs-Overhead am Proxy.
• Erhöhte Latenz: Der zusätzliche Verarbeitungsschritt kann im Vergleich zu einer direkten HTTP/2-Verbindung eine geringfügige Latenz einführen.

Anwendungsfall: Ideal für Szenarien, in denen clientseitige Performance-Vorteile von HTTP/2 gewünscht sind, die Backend-Infrastruktur aber noch nicht HTTP/2-fähig ist oder wenn eine umfangreiche proxyseitige Anforderungsmanipulation erforderlich ist.

HTTP/2 Ende-zu-Ende (Full Proxy)

Bei einem Ende-zu-Ende-HTTP/2-Proxy-Setup unterhält der Proxy HTTP/2-Verbindungen sowohl mit dem Client als auch mit dem Ursprungsserver. Der Proxy fungiert als transparenter Vermittler, der HTTP/2-Frames oder -Streams direkt ohne Protokollkonvertierung weiterleitet.

Ablauf:

1. Der Client initiiert eine HTTP/2-Verbindung zum Proxy.
2. Der Proxy stellt eine HTTP/2-Verbindung zum Ursprungsserver her.
3. Der Proxy leitet HTTP/2-Frames/Streams zwischen Client und Ursprung weiter.
4. Der Proxy verwaltet Stream-IDs und priorisiert potenziell Streams.

Vorteile:

• Volle Funktionserhaltung: Alle HTTP/2-Funktionen, einschließlich Server-Push vom Ursprung, Stream-Priorisierung und HPACK-Kompression, bleiben Ende-zu-Ende erhalten.
• Geringere Latenz: Eliminiert den Transkodierungs-Overhead, was potenziell zu geringerer Latenz führt, wenn der Ursprungsserver geografisch nah oder hochoptimiert für HTTP/2 ist.
• Reduzierter Proxy-Overhead: Die Rolle des Proxys besteht hauptsächlich in der Frame-Weiterleitung und Stream-Verwaltung, anstatt einer vollständigen Protokollkonvertierung.

Nachteile:

• Anforderung an den Ursprungsserver: Erfordert, dass der Ursprungsserver HTTP/2 vollständig unterstützt.
• Reduzierte Sichtbarkeit/Kontrolle: Die direkte Manipulation von HTTP-Headern oder Anforderungs-Bodies durch den Proxy wird aufgrund der HPACK-Kompression und der binären Natur von HTTP/2-Frames komplexer. Eine Tiefenpaketinspektion erfordert oft eine vollständige Frame-Dekodierung und erneute Kodierung.
• Sicherheitsimplikationen: Wenn die Ursprungsverbindung ebenfalls TLS ist, fungiert der Proxy als TLS-Terminierungspunkt und stellt eine neue TLS-Verbindung zum Ursprung her, was potenziell die Sicherheitsposition beeinträchtigen oder eine Zertifikatsverwaltung erfordern kann.

Anwendungsfall: Am besten geeignet, wenn sowohl Clients als auch Ursprungsserver HTTP/2 unterstützen und das Ziel darin besteht, die Performance-Vorteile von HTTP/2 über den gesamten Verbindungspfad zu maximieren, mit minimaler proxyseitiger Interferenz über Routing und Lastverteilung hinaus.

Wichtige Überlegungen für Proxy-Dienste

Application-Layer Protocol Negotiation (ALPN)

HTTP/2 wird typischerweise über TLS mittels ALPN ausgehandelt. Wenn ein Client eine Verbindung zu einem Proxy herstellt, sendet er eine ALPN-Erweiterung in der TLS ClientHello-Nachricht, die die Unterstützung für h2 (HTTP/2 über TLS) und http/1.1 anzeigt. Der Proxy wählt das bevorzugte Protokoll aus.

Beispiel (Konzeptioneller ALPN-Handshake):

ClientHello (ALPN: [h2, http/1.1]) -> Proxy
Proxy selects h2
ServerHello (ALPN: h2) <- Proxy

Header-Übersetzung und HPACK

Beim Übergang zwischen HTTP/2 und HTTP/1.1 (Terminierungsmodell) muss der Proxy HPACK-Header aus HTTP/2-Anfragen dekomprimieren und HTTP/1.1-Header für HTTP/2-Antworten erneut in HPACK kodieren. Dies beinhaltet die Verwaltung der zustandsbehafteten HPACK-Dynamiktabelle.

Stream-Verwaltung und Priorisierung

HTTP/2 ermöglicht mehrere gleichzeitige Streams über eine einzige Verbindung. Ein Proxy muss diese Streams verwalten, sie Backend-Verbindungen (für HTTP/1.1-Backends) zuordnen oder sie unter Berücksichtigung von Prioritätshinweisen weiterleiten. Eine falsche Stream-Verwaltung kann die Multiplexing-Vorteile von HTTP/2 aufheben.

Server-Push-Behandlung

• Terminierung: Wenn der Proxy HTTP/2 terminiert, kann er Server-Push-Anfragen vom Ursprung nicht direkt weiterleiten. Der Proxy kann seine eigene Server-Push-Logik basierend auf Inhaltsanalyse oder Konfiguration implementieren.
• Ende-zu-Ende: In einem Ende-zu-Ende-Setup werden Server-Push-Frames vom Ursprung direkt an den Client weitergeleitet.

Traffic-Inspektion und -Modifikation

Die Inspektion oder Modifikation von HTTP/2-Traffic ist anspruchsvoller als bei HTTP/1.1.
* Verschlüsselung: HTTP/2 wird fast universell mit TLS verwendet, was erfordert, dass der Proxy TLS zur Inspektion terminiert.
* Header-Kompression: Das Modifizieren von Headern erfordert Dekodierung, Modifikation und erneute Kodierung mit HPACK, was zustandsbehaftet und komplex sein kann.

Lastverteilung

Bei HTTP/2 können mehrere Anfragen von einem einzigen Client über eine Verbindung eingehen. Lastverteiler müssen entscheiden, ob alle Streams einer einzelnen Client-Verbindung an einen Backend-Server geleitet werden sollen (Session-Stickiness) oder ob einzelne Streams auf mehrere Backend-Server verteilt werden sollen. Letzteres erfordert eine ausgefeiltere, Stream-bewusste Lastverteilung.

Konfigurationsbeispiele (Nginx)

Nginx, ein gängiger Reverse-Proxy, unterstützt sowohl HTTP/2-Terminierung als auch Ende-zu-Ende-Proxying.

HTTP/2-Terminierung (Frontend HTTP/2, Backend HTTP/1.1):

server {
    listen 443 ssl http2; # HTTP/2 für Client-Verbindungen aktivieren
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass http://backend_servers; # Backend ist HTTP/1.1
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        # Nginx konvertiert HTTP/2-Client-Anfragen automatisch in HTTP/1.1 für das Backend
    }
}

upstream backend_servers {
    server 192.168.1.100:80;
    server 192.168.1.101:80;
}

HTTP/2 Ende-zu-Ende (Frontend HTTP/2, Backend HTTP/2):

server {
    listen 443 ssl http2; # HTTP/2 für Client-Verbindungen aktivieren
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass https://backend_h2_servers; # Backend ist HTTP/2
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on; # SNI an Backend weiterleiten
        proxy_http_version 2; # Nginx anweisen, HTTP/2 für die Backend-Verbindung zu verwenden
    }
}

upstream backend_h2_servers {
    server 192.168.1.100:443;
    server 192.168.1.101:443;
}

Vergleich: HTTP/2-Terminierung vs. Ende-zu-Ende

Praktische Implikationen

Die Implementierung von HTTP/2 in einem Proxy-Dienst wirkt sich direkt auf die Benutzererfahrung und die Infrastruktureffizienz aus. Benutzer profitieren von schnelleren Seitenladevorgängen und einem reaktionsschnelleren Web durch Multiplexing und Header-Kompression. Für die Proxy-Infrastruktur erfordert die Unterstützung von HTTP/2 ein sorgfältiges Ressourcenmanagement, insbesondere hinsichtlich der CPU-Auslastung für TLS-Terminierung und HPACK-Verarbeitung. Die Wahl zwischen Terminierung und Ende-zu-Ende hängt von der bestehenden Backend-Architektur, den Leistungszielen und dem Bedarf an Proxy-Kontrolle über den Traffic ab. Die Sicherheit bleibt von größter Bedeutung, wobei TLS eine Voraussetzung für die meisten HTTP/2-Bereitstellungen ist, was ein robustes Zertifikatsmanagement und eine sichere Konfiguration erfordert.