Persistente HTTP-Verbindung - HTTP persistent connection

Eine persistente HTTP- Verbindung , auch HTTP-Keep-Alive oder HTTP-Verbindungswiederverwendung genannt , ist die Idee, eine einzelne TCP- Verbindung zum Senden und Empfangen mehrerer HTTP-Anfragen /Antworten zu verwenden, anstatt für jedes einzelne Anfrage/Antwort-Paar eine neue Verbindung zu öffnen. Das neuere HTTP/2- Protokoll verwendet die gleiche Idee und geht weiter, um das Multiplexen mehrerer gleichzeitiger Anforderungen/Antworten über eine einzige Verbindung zu ermöglichen.

Betrieb

HTTP 1.0

Unter HTTP 1.0 sollten Verbindungen nach dem Senden der Antwort immer vom Server geschlossen werden.

Seit Ende 1996 begannen Entwickler populärer Produkte (Browser, Webserver usw.), die HTTP/1.0 verwenden, eine inoffizielle Erweiterung (zum Protokoll) namens "keep-alive" hinzuzufügen, um die Wiederverwendung einer Verbindung für mehrere zu ermöglichen Anfragen/Antworten.

Wenn der Client Keep-Alive unterstützt, fügt er der Anfrage einen zusätzlichen Header hinzu:

Connection: keep-alive

Wenn der Server diese Anfrage empfängt und eine Antwort generiert, wenn er Keep-Alive unterstützt, fügt er der Antwort auch den gleichen Header oben hinzu. Danach wird die Verbindung nicht abgebaut, sondern offen gehalten. Wenn der Client eine weitere Anfrage sendet, verwendet er dieselbe Verbindung.

Dies wird so lange fortgesetzt, bis entweder der Client oder der Server entscheidet, dass die Konversation beendet ist, und in diesem Fall den "Connection:"Header der letzten gesendeten Nachricht weglassen oder besser das Schlüsselwort "close" hinzufügen:

Connection: close

Danach wird die Verbindung nach festgelegten Regeln geschlossen.

Seit 1997 haben die verschiedenen Versionen der HTTP/1.1-Spezifikationen die Verwendung dieser inoffiziellen Erweiterung anerkannt und einige Vorbehalte hinsichtlich der Interoperabilität zwischen HTTP/1.0 (Keep-Alive) und HTTP/1.1-Clients / Servern enthalten.

HTTP 1.1

In HTTP 1.1 gelten alle Verbindungen als persistent, sofern nicht anders angegeben. Die persistenten HTTP- Verbindungen verwenden keine separaten Keepalive-Nachrichten, sondern erlauben nur mehreren Anfragen, eine einzige Verbindung zu verwenden. Allerdings beträgt das standardmäßige Verbindungs-Timeout von Apache httpd 1.3 und 2.0 nur 15 Sekunden und nur 5 Sekunden für Apache httpd 2.2 und höher. Der Vorteil einer kurzen Zeitüberschreitung ist die Möglichkeit, mehrere Komponenten einer Webseite schnell bereitzustellen, ohne Ressourcen zu verbrauchen, um mehrere Serverprozesse oder Threads zu lange auszuführen.

Keepalive mit Chunked Transfer Encoding

Keepalive erschwert es dem Client, zu bestimmen, wo eine Antwort endet und die nächste Antwort beginnt, insbesondere während des HTTP-Pipeline-Vorgangs. Dies ist ein ernstes Problem, wenn Content-Lengthes aufgrund von Streaming nicht verwendet werden kann. Um dieses Problem zu lösen, hat HTTP 1.1 eine Chunked Transfer Coding eingeführt , die ein last-chunkBit definiert . Das last-chunkBit wird am Ende jeder Antwort gesetzt, damit der Client weiß, wo die nächste Antwort beginnt.

Vorteile

Gemäß RFC 7230, Abschnitt 6.4 , "sollte ein Client die Anzahl gleichzeitig geöffneter Verbindungen, die er zu einem bestimmten Server aufrechterhält, begrenzen". In der vorherigen Version der HTTP/1.1-Spezifikation wurden spezifische Maximalwerte angegeben, aber in den Worten von RFC 7230 "wurde dies für viele Anwendungen als unpraktisch befunden ... stattdessen ... beim Öffnen mehrerer Verbindungen konservativ". Diese Richtlinien sollen die HTTP-Antwortzeiten verbessern und Staus vermeiden. Wenn HTTP-Pipelining korrekt implementiert ist, können keine Leistungsvorteile durch zusätzliche Verbindungen erzielt werden, während zusätzliche Verbindungen zu Problemen mit Überlastung führen können.

Nachteile

Wenn der Client die Verbindung nicht schließt, nachdem alle benötigten Daten empfangen wurden, stehen die Ressourcen, die zum Offenhalten der Verbindung auf dem Server erforderlich sind, für andere Clients nicht zur Verfügung. Wie stark dies die Verfügbarkeit des Servers beeinflusst und wie lange die Ressourcen nicht verfügbar sind, hängt von der Architektur und Konfiguration des Servers ab.

Es kann auch eine Race Condition auftreten, bei der der Client eine Anfrage an den Server sendet, während der Server die TCP-Verbindung schließt. Ein Server sollte unmittelbar vor dem Schließen der Verbindung einen Statuscode 408 Request Timeout an den Client senden. Wenn ein Client den Statuscode 408 empfängt, nachdem er die Anfrage gesendet hat, kann er eine neue Verbindung zum Server öffnen und die Anfrage erneut senden. Nicht alle Clients senden die Anfrage erneut, und viele, die dies tun, tun dies nur, wenn die Anfrage eine idempotente HTTP-Methode hat .

Verwendung in Webbrowsern

Schema der multiplen vs. persistenten Verbindung.

Alle modernen Webbrowser einschließlich Google Chrome , Firefox , Internet Explorer (seit 4.01), Opera (seit 4.0) und Safari verwenden dauerhafte Verbindungen.

Standardmäßig verwenden Internet Explorer- Versionen 6 und 7 zwei persistente Verbindungen, während Version 8 sechs verwendet. Dauerhafte Verbindungen Timeout nach 60 Sekunden Inaktivität, die über die Windows-Registrierung geändert werden kann.

In Firefox kann die Anzahl der gleichzeitigen Verbindungen angepasst werden (pro Server, pro Proxy, insgesamt). Persistente Verbindungen Timeout nach 115 Sekunden (1,92 Minuten) Inaktivität, die über die Konfiguration geändert werden kann.

Siehe auch

  • HTTP-Pipelining , wodurch mehrere Anfragen gesendet werden können, ohne auf eine Antwort zu warten
  • HTTP/2 , das das Pipelining von Anfragen und Antworten außerhalb der Reihenfolge sowie das vorausschauende Pushen von Inhalten ermöglicht, bevor sie angefordert wurden

Verweise

Externe Links