8. Connections (Verbindungen)

8.1 Persistent Connections (Persistente Verbindungen)

8.1.1 Purpose (Zweck)

Vor persistenten Verbindungen musste für jede URL eine separate TCP-Verbindung hergestellt werden, was die Last auf HTTP-Servern erhöhte und zu Internet-Überlastung führte. Die Verwendung von Inline-Bildern und anderen zugehörigen Daten erfordert typischerweise, dass ein Client innerhalb kurzer Zeit mehrere Anfragen an denselben Server stellt. Ergebnisse aus Analysen dieser Leistungsprobleme und Prototyp-Implementierungen sind verfügbar [26] [30]. Implementierungserfahrung und Messungen tatsächlicher HTTP/1.1 (RFC 2068) Implementierungen zeigen gute Ergebnisse [39]. Alternativen wie T/TCP [27] wurden ebenfalls untersucht.

Persistente HTTP-Verbindungen haben viele Vorteile:

• Durch das Öffnen und Schließen weniger TCP-Verbindungen wird CPU-Zeit in Routern und Hosts (Clients, Servern, Proxies, Gateways, Tunneln oder Caches) gespart, und Speicher für TCP-Protokollkontrollblöcke wird in Hosts gespart.

• HTTP-Anfragen und -Antworten können über die Verbindung im Pipeline-Verfahren (pipelining) verarbeitet werden. Pipelining ermöglicht es einem Client, mehrere Anfragen zu stellen, ohne auf jede Antwort zu warten, was eine effizientere Nutzung einer einzelnen TCP-Verbindung ermöglicht und die verstrichene Zeit erheblich reduziert.

• Die Netzwerküberlastung wird durch Reduzierung der durch TCP-Öffnungen verursachten Paketzahl und durch Zulassen, dass TCP genügend Zeit hat, den Überlastungszustand des Netzwerks zu bestimmen, reduziert.

• Die Latenz nachfolgender Anfragen wird reduziert, da keine Zeit für den TCP-Verbindungs-Handshake aufgewendet werden muss.

• HTTP kann eleganter weiterentwickelt werden, da Fehler gemeldet werden können, ohne die Strafe des Schließens der TCP-Verbindung zu zahlen. Clients, die zukünftige Versionen von HTTP verwenden, könnten optimistisch neue Funktionen ausprobieren, aber wenn sie mit einem älteren Server kommunizieren, nach Meldung eines Fehlers mit alter Semantik wiederholen.

HTTP-Implementierungen sollten (SHOULD) persistente Verbindungen implementieren.

8.1.2 Overall Operation (Gesamtbetrieb)

Ein signifikanter Unterschied zwischen HTTP/1.1 und früheren Versionen von HTTP besteht darin, dass persistente Verbindungen das Standardverhalten jeder HTTP-Verbindung sind. Das heißt, sofern nicht anders angegeben, sollte (SHOULD) der Client annehmen, dass der Server eine persistente Verbindung aufrechterhalten wird, auch nach einer Fehlerantwort vom Server.

Persistente Verbindungen bieten einen Mechanismus für HTTP/1.0- und HTTP/1.1-Anwendungen, um das Schließen von Verbindungen zu signalisieren. Dieses Signal wird über das Connection-Header-Feld (Abschnitt 14.10) bereitgestellt. Sobald eine "close"-Verbindungsoption gesendet oder empfangen wurde, darf (MUST NOT) diese Verbindung nicht als "persistent" betrachtet werden.

HTTP/1.1-Anwendungen dürfen (MUST NOT) persistente Verbindungen mit HTTP/1.0-Clients etablieren.

8.1.3 Proxy Servers (Proxy-Server)

Besonders wichtig ist, dass Proxies die Eigenschaften des Connection-Header-Felds korrekt implementieren, wie in Abschnitt 14.10 beschrieben.

Proxy-Server müssen (MUST) persistente Verbindungen zu Clients und Upstream-Servern separat signalisieren. Jede persistente Verbindung gilt nur für einen einzelnen Transportlink.

8.1.4 Practical Considerations (Praktische Überlegungen)

Server haben typischerweise einen Timeout-Wert, über den hinaus sie eine inaktive Verbindung nicht mehr aufrechterhalten. Proxy-Server können diesen Timeout-Wert höher setzen, da Clients möglicherweise bereits Verbindungen über bestehende Verbindungen hergestellt haben. Die Verwendung persistenter Verbindungen erfordert nicht, dass Server Verbindungen unbegrenzt aufrechterhalten. Tatsächlich können (MAY) Server eine Verbindung jederzeit schließen, sollten (SHOULD) dies aber elegant tun.

Clients, Server und Proxies müssen (MUST) in der Lage sein, sich von asynchronen Schließereignissen zu erholen. Client-Software sollte (SHOULD) die Transportverbindung ohne Benutzerinteraktion wieder öffnen und die abgebrochene Anforderungssequenz erneut übertragen, solange die Anforderungssequenz idempotent ist (siehe Abschnitt 9.1.2). Nicht-idempotente Methoden oder Sequenzen dürfen (MUST NOT) automatisch wiederholt werden, obwohl der Benutzeragent dem Benutzer ein Mittel bieten kann (MAY), um Anfragen manuell zu wiederholen.

Server sollten (SHOULD) immer auf mindestens eine Anfrage antworten, bevor sie eine Verbindung schließen. Server sollten (SHOULD NOT) eine Verbindung mitten in der Übertragung einer Antwort schließen, es sei denn, ein Netzwerk- oder Client-Fehler wird vermutet.

Clients, die eine persistente Verbindung senden möchten, können (MAY) ihre Anfragen "pipelinen" (d.h. mehrere Anfragen senden, ohne auf die Ankunft jeder Antwort zu warten). Server müssen (MUST) ihre Antworten in der Reihenfolge senden, in der die entsprechenden Anfragen empfangen wurden.

8.2 Message Transmission Requirements (Anforderungen an die Nachrichtenübertragung)

8.2.1 Persistent Connections and Flow Control (Persistente Verbindungen und Flusskontrolle)

HTTP/1.1-Server sollten (SHOULD) persistente Verbindungen für sich selbst aufrechterhalten, wenn möglich. Wenn sie jedoch persistente Verbindungen aufrechterhalten, sollten (SHOULD) sie für eine gegebene TCP-Verbindung diese Verbindung für mindestens eine Anfrage-Antwort-Sequenz verwenden.

8.2.2 Monitoring Connections for Error Status Messages (Überwachung von Verbindungen auf Fehlerstatusmeldungen)

Ein HTTP/1.1 (oder höher) Client, der eine Anfrage sendet (insbesondere eine für Authentifizierung kritische Anfrage oder eine mit einer unsicheren Methode), muss (MUST) die Anfrage erneut senden, wenn die Transportverbindung geschlossen oder zurückgesetzt wird, bevor der Client die Anfragenachricht vollständig gesendet hat.

8.2.3 Use of the 100 (Continue) Status (Verwendung des 100 (Continue) Status)

Der Zweck des 100 (Continue) Status (siehe Abschnitt 10.1.1) besteht darin, einem Client, der einen Anfragenachrichtenkörper sendet, zu ermöglichen, festzustellen, ob der Origin-Server bereit ist, die Anfrage (basierend auf den Anfrage-Headern) zu akzeptieren, bevor der Client den Anfragekörper sendet. In einigen Fällen kann es unangemessen oder ineffizient sein, dass ein Client einen Körper sendet, wenn der Server die Nachricht ablehnen wird, ohne den Körper zu lesen.

Anforderungen für einen HTTP/1.1 (oder höher) Client, der einen Anfragenachrichtenkörper enthält:

• Wenn der Client auf eine 100 (Continue) Antwort für eine angemessene Zeitspanne wartet, muss (MUST) der Client ein Expect-Anfrage-Header-Feld (Abschnitt 14.20) mit dem Erwartungswert "100-continue" senden.

• Der Client darf (MUST NOT) ein Expect-Anfrage-Header-Feld mit dem Erwartungswert "100-continue" an einen HTTP/1.0 (oder früheren) Server senden.

• Ein Client, der eine 100 (Continue) Erwartung sendet, aber keinen 100 (Continue) Status empfängt, sollte (SHOULD) eine unbestimmte Zeit warten; der Client kann (MAY) dann ablaufen und die Anfrage senden (mit ihrem Nachrichtenkörper) oder die Verbindung schließen.

Anforderungen für einen HTTP/1.1 (oder höher) Origin-Server, der eine Anfrage von einem HTTP/1.1 (oder höher) Client empfängt:

• Nach Empfang einer Anfrage mit einem Expect-Anfrage-Header-Feld, das den Erwartungswert "100-continue" enthält, muss (MUST) der Origin-Server mit einem 100 (Continue) Status antworten, wenn er beabsichtigt, den Anfragenachrichtenkörper zu lesen und zu verarbeiten, oder mit einem endgültigen Statuscode antworten. Der Origin-Server darf (MUST NOT) auf den Anfragekörper warten, bevor er die 100 (Continue) Antwort sendet. Wenn er mit einem endgültigen Statuscode antwortet, kann (MAY) er die Transportverbindung schließen oder kann (MAY) weiterhin den Rest der Anfrage lesen und verwerfen. Er darf (MUST NOT) die Methode der Anfrage ausführen (wenn er beabsichtigt, die Anfrage abzulehnen).

• Der Origin-Server sollte (SHOULD) mit 100 (Continue) antworten, unmittelbar nachdem er Anfrage-Header von einem HTTP/1.1 (oder höher) Client empfangen hat, es sei denn, die Anfrage enthält ein Expect-Anfrage-Header-Feld mit einem Erwartungswert, der nicht "100-continue" umfasst.

8.2.4 Client Behavior if Server Prematurely Closes Connection (Client-Verhalten wenn Server Verbindung vorzeitig schließt)

Wenn ein HTTP/1.1-Client eine HTTP-Anfrage sendet, bevor er eine Antwort empfängt, und eine Antwort empfängt, die anzeigt, dass der Server keine weiteren Anfragen auf dieser Verbindung empfangen möchte, sollte (SHOULD) der Client die Anfrage erneut senden, vorausgesetzt, er kann feststellen, dass alle Anfragen in der Sequenz idempotent sind (siehe Abschnitt 9.1.2).

Nicht-idempotente Methoden oder Sequenzen dürfen (MUST NOT) automatisch erneut übertragen werden, aber der Benutzeragent kann (MAY) dem Benutzer ein Mittel bieten, diese Sequenz manuell zu wiederholen. Bevor Anfragen automatisch erneut übertragen werden, sollte (SHOULD) der Client, wenn die vorherige Anforderungssequenz nicht vollständig abgeschlossen werden konnte, alle Unterschiede zwischen seinem aktuellen Zustand und dem erwarteten Zustand bestätigen.

---