Keep-Alive

Keep-Alive, im Kontext persistenter Verbindungen über einen Proxy, ist ein HTTP-Mechanismus, der es ermöglicht, eine einzige TCP-Verbindung offen zu halten und für mehrere HTTP-Anfragen und -Antworten zwischen einem Client und einem Proxy sowie zwischen einem Proxy und einem Ursprungsserver wiederzuverwenden, wodurch der Overhead für den Aufbau neuer Verbindungen für jede Transaktion reduziert wird.

Keep-Alive verstehen

HTTP Keep-Alive, auch bekannt als persistente Verbindungen, ist eine grundlegende Optimierung für die Webleistung. Ohne Keep-Alive würde jede HTTP-Anfrage den Aufbau einer neuen TCP-Verbindung (TCP-Handshake), gefolgt von der Datenübertragung und anschließend der Verbindungsbeendigung erfordern. Dieser Prozess verursacht einen erheblichen Overhead, insbesondere bei sicheren Verbindungen, die auch einen TLS-Handshake erfordern.

Vorteile persistenter Verbindungen

• Reduzierte Latenz: Eliminiert die Latenz, die mit dem TCP- und TLS-Handshake für nachfolgende Anfragen über dieselbe Verbindung verbunden ist. Dies ist besonders bei Clients mit hohen Round-Trip-Zeiten (RTT) spürbar.
• Reduzierte CPU- und Speichernutzung: Weniger häufiger Verbindungsaufbau und -abbau reduziert die Rechenlast auf Clients, Proxys und Ursprungsservern. Dies umfasst CPU-Zyklen für Socket-Operationen, Speicher für den Verbindungsstatus und die Nutzung von Dateideskriptoren.
• Reduzierte Netzwerküberlastung: Weniger geöffnete und geschlossene TCP-Verbindungen bedeuten weniger Signalisierungsverkehr (SYN-, SYN-ACK-, FIN-, FIN-ACK-Pakete) im Netzwerk.
• Verbesserter Durchsatz: Ermöglicht eine effizientere Nutzung der TCP-Staukontrollmechanismen, da Verbindungen im Laufe der Zeit höhere Durchsatzraten erreichen können.

Keep-Alive in HTTP/1.x

Die Implementierung und das Standardverhalten von Keep-Alive unterscheiden sich zwischen HTTP/1.0 und HTTP/1.1.

HTTP/1.0 Keep-Alive

In HTTP/1.0 waren persistente Verbindungen nicht der Standard. Clients mussten Keep-Alive explizit anfordern, indem sie den Header Connection: keep-alive in ihre Anfragen aufnahmen. Server antworteten mit demselben Header, um ihre Unterstützung für persistente Verbindungen anzuzeigen. Wenn eine der Parteien diesen Header nicht enthielt, wurde die Verbindung nach der aktuellen Antwort geschlossen.

HTTP/1.1 Keep-Alive

HTTP/1.1 machte persistente Verbindungen zum Standardverhalten. Sofern nicht explizit anders angegeben, gehen Clients und Server davon aus, dass eine Verbindung nach einer Transaktion offen bleiben sollte. Um eine Verbindung zu schließen, muss eine der Parteien den Header Connection: close senden. Diese Änderung verbesserte die Webleistung standardmäßig erheblich.

Der Connection-Header als Hop-by-Hop-Header

Der Connection-Header ist ein Hop-by-Hop-Header. Das bedeutet, er ist nur für die direkte Verbindung zwischen zwei kommunizierenden Parteien (z.B. Client zu Proxy oder Proxy zu Ursprungsserver) bestimmt und darf von Proxys oder Intermediären nicht weitergeleitet werden. Proxys müssen Hop-by-Hop-Header entfernen oder modifizieren, bevor sie Anfragen oder Antworten weiterleiten. Andernfalls kann dies zu Protokollverletzungen und unerwartetem Verhalten führen, da der nachgeschaltete Server oder Client die Anweisungen zur Verbindungsverwaltung möglicherweise falsch interpretiert.

Andere gängige Hop-by-Hop-Header sind Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers und Upgrade.

Keep-Alive über einen Proxy

Proxys spielen eine entscheidende Rolle bei der Verwaltung persistenter Verbindungen. Sie unterhalten typischerweise zwei Sätze persistenter Verbindungen:

1. Client-zu-Proxy-Verbindungen: Der Proxy unterhält persistente Verbindungen mit seinen Clients.
2. Proxy-zu-Ursprungsserver-Verbindungen: Der Proxy unterhält persistente Verbindungen mit den Ursprungsservern, an die er Anfragen weiterleitet.

Rolle des Proxys bei der Header-Verwaltung

Wenn ein Proxy einen Connection: keep-alive-Header von einem Client empfängt, versteht er, dass der Client die Verbindung zum Proxy offen halten möchte. Der Proxy darf diesen Connection-Header jedoch nicht an den Ursprungsserver weiterleiten. Stattdessen entscheidet der Proxy unabhängig, ob er eine persistente Verbindung zum Ursprungsserver herstellt, basierend auf seiner eigenen Konfiguration und den Fähigkeiten des Ursprungsservers.

Ein gängiges Muster für Proxys, insbesondere im Umgang mit HTTP/1.1, ist es, den Connection-Header aus eingehenden Client-Anfragen zu entfernen und dann die Upstream-Verbindung zum Ursprungsserver separat zu verwalten. Wenn der Proxy HTTP/1.1 persistente Verbindungen Upstream verwenden möchte, lässt er einfach den Connection: close-Header weg.

# Beispiel Nginx-Konfiguration für das Proxying von HTTP/1.1 mit Keep-Alive
location / {
    proxy_pass http://backend_server;
    proxy_http_version 1.1; # Weist Nginx an, HTTP/1.1 für Upstream zu verwenden
    proxy_set_header Connection ""; # Entfernt den Connection-Header aus Client-Anfragen,
                                    # um sicherzustellen, dass Nginx Upstream Keep-Alive unabhängig verwaltet.
                                    # Dies ist entscheidend für die korrekte Handhabung von Hop-by-Hop-Headern.
}

In diesem Nginx-Beispiel stellt proxy_http_version 1.1; sicher, dass Nginx HTTP/1.1 verwendet, wenn es sich mit backend_server verbindet. Standardmäßig sind HTTP/1.1-Verbindungen persistent. proxy_set_header Connection ""; entfernt explizit den Connection-Header, der möglicherweise vom Client kam, verhindert dessen Weiterleitung an den Ursprungsserver und ermöglicht Nginx, seine eigenen persistenten Upstream-Verbindungen korrekt zu verwalten.

Verbindungspooling

Proxys implementieren oft Verbindungspooling für ihre Upstream-Verbindungen zu Ursprungsservern. Das bedeutet, sie unterhalten einen Pool von inaktiven, offenen TCP-Verbindungen zu verschiedenen Ursprungsservern. Wenn eine neue Anfrage für einen bestimmten Ursprung eingeht, prüft der Proxy zuerst, ob eine inaktive Verbindung zu diesem Ursprung im Pool verfügbar ist. Wenn ja, wird diese Verbindung wiederverwendet. Wenn nicht, wird eine neue Verbindung hergestellt. Dies erhöht die Effizienz weiter, indem die Anzahl der neuen Verbindungen reduziert wird, die der Proxy herstellen muss.

Keep-Alive-Timeouts und Ressourcenmanagement

Obwohl vorteilhaft, erfordern persistente Verbindungen eine sorgfältige Verwaltung, um eine Ressourcenerschöpfung auf dem Proxy und den Ursprungsservern zu verhindern.

Timeout-Mechanismen

Jede Partei (Client, Proxy, Ursprungsserver) kann ein keep-alive-Timeout festlegen. Wenn innerhalb dieser Timeout-Periode keine Daten über eine persistente Verbindung ausgetauscht werden, wird die Verbindung geschlossen.

• Client-seitiges Timeout: Der Client könnte seine Verbindung zum Proxy schließen, wenn er innerhalb einer bestimmten Zeit keine weitere Anfrage sendet.
• Proxy-seitiges Timeout: Der Proxy kann seine eigenen keep-alive-Timeouts sowohl für clientseitige als auch für ursprungsserver-seitige Verbindungen konfigurieren. Wenn eine inaktive Client-zu-Proxy-Verbindung oder Proxy-zu-Ursprungsserver-Verbindung ihr Timeout überschreitet, schließt der Proxy sie.
• Ursprungsserver-Timeout: Der Ursprungsserver schließt seine Verbindung zum Proxy, wenn sie zu lange inaktiv bleibt.

Nicht übereinstimmende Timeouts können zu Problemen führen. Wenn beispielsweise ein Ursprungsserver ein kürzeres keep-alive-Timeout hat als der Proxy, könnte der Ursprung eine Verbindung schließen, die der Proxy noch für offen hält. Wenn der Proxy versucht, diese "veraltete" Verbindung wiederzuverwenden, wird er auf einen Fehler stoßen (z.B. einen Verbindungsreset) und muss die Anfrage über eine neue Verbindung wiederholen. Dies erhöht die Latenz und die Fehlerraten. Daher ist es im Allgemeinen ratsam, die keep-alive-Timeouts von Proxy zu Ursprungsserver so zu konfigurieren, dass sie etwas kürzer oder gleich den Timeouts des Ursprungsservers sind.

Maximale Verbindungen

Proxys müssen auch die Gesamtzahl der persistenten Verbindungen begrenzen, die sie aufrechterhalten, sowohl zu Clients als auch zu Ursprungsservern. Jede offene Verbindung verbraucht Systemressourcen (Speicher, Dateideskriptoren). Unbegrenzte persistente Verbindungen können zu Folgendem führen:

• Erschöpfung der Dateideskriptoren: Dem Proxy gehen die verfügbaren Dateideskriptoren aus.
• Speichererschöpfung: Zu viele offene Verbindungen verbrauchen übermäßigen Speicher.
• Erhöhte CPU-Last: Die Verwaltung einer großen Anzahl von inaktiven Verbindungen verursacht immer noch einen gewissen Overhead.

Proxy-Konfigurationen ermöglichen es Administratoren typischerweise, keep-alive_timeout und keep-alive_requests (die maximale Anzahl von Anfragen, die über eine einzelne persistente Verbindung zugelassen sind, bevor diese geschlossen und neu erstellt wird) festzulegen.

# Nginx-Beispiel: Keep-Alive-Einstellungen für clientseitige Verbindungen
http {
    keepalive_timeout 60s; # Client-zu-Nginx Keep-Alive-Timeout
    keepalive_requests 1000; # Maximale Anfragen pro Client-zu-Nginx Keep-Alive-Verbindung
    # ...
}

# Nginx-Beispiel: Keep-Alive-Einstellungen für Proxy-zu-Ursprungsserver-Verbindungen
location / {
    proxy_pass http://backend_server;
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    # Optional: Spezifische Upstream-Keep-Alive-Einstellungen bei Bedarf konfigurieren
    # Das Standard-Upstream-Keep-Alive-Verhalten von Nginx ist es, Verbindungen wiederzuverwenden,
    # solange sie nicht explizit vom Upstream geschlossen oder von Nginx getimt werden.
    # Für eine explizitere Kontrolle über den Upstream-Verbindungspool:
    # proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    # proxy_connect_timeout 5s;
    # proxy_read_timeout 10s;
    # proxy_send_timeout 10s;
}

Keep-Alive in HTTP/2 und darüber hinaus

HTTP/2 führte Multiplexing ein, das es ermöglicht, mehrere HTTP-Anfragen und -Antworten gleichzeitig über eine einzige TCP-Verbindung zu senden. Dies bietet von Natur aus die Vorteile von Keep-Alive, ohne dass explizite Connection: keep-alive-Header auf der Anwendungsebene erforderlich sind. Eine HTTP/2-Ver