HTTP-Keep-Alive-Header

Typ

Der Keep-Alive-Header ist ein General-Header, der Parameter für persistente HTTP-Verbindungen definiert (Timeout, maximale Request-Anzahl).

Syntax

Der Header enthält kommaseparierte Direktiven für Timeout (in Sekunden) und Max-Requests pro Verbindung.

http 
Keep-Alive: timeout=5, max=100
Keep-Alive: timeout=120

Direktiven

Der Keep-Alive-Header verwendet Parameter für Connection-Timeout und Request-Limits, wobei die Semantik vom Connection-Header abhängt.

timeout
Idle-Timeout in Sekunden, nach dem der Server die Verbindung schließt (Minimum: 1 Sekunde).
max
Maximale Anzahl von Requests, die über diese Verbindung gesendet werden können, bevor sie geschlossen wird.

Beispiele

Die folgenden Beispiele zeigen typische Anwendungsfälle für Connection-Pooling in API-Clients, Load-Balancer-Konfiguration und Performance-Optimierung.

API-Server mit Connection-Pooling

Ein API-Server signalisiert dem Client, dass er bis zu 1000 Requests über eine Verbindung mit 60-Sekunden-Timeout akzeptiert.

http 
HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: timeout=60, max=1000
Content-Type: application/json
Content-Length: 1234

{
  "id": "12345",
  "status": "success"
}

Client-Request mit Keep-Alive-Erwartung:

http 
GET /api/v1/products HTTP/1.1
Host: api.example.com
Connection: keep-alive
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Load-Balancer mit kurzen Timeouts

Ein Load-Balancer verwendet kurze Keep-Alive-Timeouts zur Lastverteilung über mehrere Backend-Instanzen.

http 
HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: timeout=5, max=100
X-Load-Balancer: nginx-lb-01
Content-Type: application/json

{
  "data": []
}

Microservice mit langen Connection-Timeouts

Ein Microservice optimiert Performance durch lange Connection-Timeouts für interne Service-to-Service-Kommunikation.

http 
HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: timeout=120, max=5000
X-Service-Name: inventory-service
Content-Type: application/json

{
  "inventory": []
}

Connection-Pooling-Flow

Der Keep-Alive-Header ermöglicht persistente Verbindungen und reduziert TCP-Handshake-Overhead für sequentielle Requests.

plantuml 
@startuml
!theme plain
skinparam BoxPadding 20
skinparam ParticipantPadding 20

participant "API\nClient" as client
participant "TCP\nConnection" as tcp
participant "API\nServer" as api

client -> tcp: TCP Handshake\n(SYN, SYN-ACK, ACK)
tcp -> api: Connection established

client -> api: GET /api/products/1\nConnection: keep-alive
api --> client: 200 OK\nConnection: keep-alive\nKeep-Alive: timeout=60, max=1000

note over tcp: Connection bleibt offen\n(kein TCP-Close)

client -> api: GET /api/products/2\n(same TCP connection)
api --> client: 200 OK\nConnection: keep-alive\nKeep-Alive: timeout=60, max=999

client -> api: POST /api/orders\n(same TCP connection)
api --> client: 201 Created\nConnection: keep-alive\nKeep-Alive: timeout=60, max=998

note over tcp: 60 Sekunden Idle-Time

note over tcp: Timeout erreicht\noder Client schließt

client -> tcp: TCP Close\n(FIN, ACK)
tcp -> api: Connection closed

note over client,api: Vorteile:\n- 3 Requests über 1 TCP-Connection\n- 2 TCP-Handshakes gespart\n- Reduzierte Latenz
@enduml

Vorteile für die Systemarchitektur

  • Reduzierter TCP-Handshake-Overhead durch Connection-Reuse
  • Performance-Optimierung für Burst-Requests in API-Clients
  • Load-Balancer-Kompatibilität mit konfigurierbaren Timeouts
  • Automatische Unterstützung in HTTP/1.1 (Default: keep-alive)
  • Explizites Connection-Management für Resource-Limits

Spezifikation

RFC 9110 (HTTP Semantics) definiert den Keep-Alive-Header als optionalen General-Header für persistente Connection-Parameter in HTTP/1.1.

Weitere Spezifikationen

Connection Header, Transfer-Encoding Header