2.1.2 HTTP 1.1 zustandslos und persistent

Bei der Entstehung des Protokolls HTTP waren Server längst nicht so leistungsstark, und auch die Netzwerke liefen ganz anders als heutzutage. Daher wurde HTTP als zustandsloses Protokoll entwickelt. Nur so war es seinerzeit möglich, viele unterschiedliche Anfragen beantworten zu können.

Das zustandshaltende Protokoll FTP ist älter als HTTP. FTP-Server waren sogar schon um 1990 im Einsatz. Typischerweise konnte ein FTP-Server früher 10 gleichzeitige Verbindungen bearbeiten. Wenn diese Verbindungen belegt waren, dann musste ein Nutzer es zu einem späteren Zeitpunkt erneut probieren. Dieses Verhalten wollte man bei HTTP vermeiden, denn die HTML-Seiten sollten vielen Nutzern gleichzeitig zur Verfügung stehen. Also wurde HTTP seinerzeit modern und zustandslos entwickelt.

Zustandslos

Zustandslos bedeutet, dass eine nachfolgende Anfrage sich nicht unmittelbar auf die vorherige Anfrage beziehen kann (Wikipedia über Zustandslosigkeit).

Generell gilt somit für jede Anfrage: Verbindungsaufbau, Verbindung, Datenübertragung, Verbindungsabbau.

  • Client-Request: Aufbau einer TCP/IP-Verbindung
  • Übertragen der HTTP-Anforderung
  • Server-Response: Übertragen der HTTP-Antwort und Abbau der TCP/IP-Verbindung

Ein Bearbeiterprozess für eine Anfrage existiert auf dem Server, bis die Daten auf dem Client angekommen sind. Somit ist folgende Bedingung notwendig: Anfragen < Anzahl der Bearbeiterprozesse.

Wichtig

Mit zustandslos oder zustandshaltend wird die Verbindungsart zwischen zwei (unabhängigen) Anfragen bezeichnet.

Hinweis

Wenn HTTP nicht zustandslos wäre, hätte dies tiefgreifende Auswirkungen auf das Web, wie wir es kennen. Jede Verbindung zwischen einem Webbrowser und einem Server müsste Informationen über frühere Interaktionen speichern. Dies würde bedeuten:

  • Erhöhter Speicherbedarf auf dem Server: Für jeden Nutzer müsste eine Sitzungsinformation gespeichert werden, um den Zustand zwischen den Anfragen zu erhalten.
  • Komplexere Serverlogik: Server müssten komplexe Logiken implementieren, um unterschiedliche Nutzerzustände zu verwalten und entsprechend zu reagieren.
  • Skalierungsprobleme: Die Notwendigkeit, Zustände für Millionen von Nutzern gleichzeitig zu verwalten, würde zu viel mehr Ressourcen bei der Skalierung von Webdiensten führen (Server, Stromverbrauch).
  • Sicherheitsrisiken: Das Speichern von Zustandsinformationen erhöht das Risiko von Sicherheitsverletzungen, da Angreifer potenziell Zugriff auf sensible Nutzerdaten erlangen könnten.

Die Zustandslosigkeit von HTTP ermöglicht eine einfache und skalierbare Kommunikation zwischen Clients und Servern, indem sie die Komplexität reduziert und die Unabhängigkeit von einzelnen Anfragen gewährleistet. Dies trägt wesentlich zur Leistungsfähigkeit und Zuverlässigkeit des Internets bei.

Persistent

Wenn über HTTP eine Internetseite angefordert wird, so befinden sich in dieser angeforderten Seite normalerweise eingebettete Objekte (Bilder etc.).

Eine Internetanfrage über HTTP löst also viele zugehörige Anfragen zu einem Server aus. Damit nicht bei jeder Anfrage die TCP/IP-Verbindung neu aufgebaut werden muss, wird eine persistente Verbindung ausgeführt. Seit HTTP/1.1 von 1999 erfolgt die persistente Verbindung automatisch.

Wichtig

Unter einer persistenten Verbindung wird verstanden, dass alle Anfragen, die aufgrund eines Seitenaufrufs erfolgen, zu einem Zustand zusammengefasst werden.

Es gilt:

  • Persistente Verbindungen können über eine Anweisung im HTTP/1.1-Header geschlossen werden (Connection: close).
  • Persistente Verbindungen werden nach Überschreitung eines Zeitlimits oder nach einer maximalen Anzahl von übertragenen Elementen geschlossen. Zeitlimit und Anzahl der Elemente lassen sich über eine Anweisung im HTTP/1.1-Header steuern (Keep-Alive: time-out=5, max=100).
  • Persistente Verbindungen werden nach Verbindungsabbruch automatisch geschlossen.
  • Der Server sendet die Response-Daten in der Reihenfolge, in der die Requests ankommen.

Vorteile gegenüber nicht-persistenten Verbindungen:

  • Geringere Netzwerkbelastung und Serverbelastung, sowie weniger TCP/IP-Verbindungen und geringere CPU-Zeit auf dem Server.
  • Es sind Mehrfach-Requests erlaubt; somit muss nicht erst der Response abgewartet werden, um einen weiteren Request abzusetzen.

Die Rolle von Zustandslosigkeit und Persistenz in HTTP/2 und HTTP/3

In HTTP/2 und HTTP/3 bleiben die Konzepte von Zustandslosigkeit und Persistenz weiterhin wichtig.

HTTP/2 ermöglicht durch Multiplexing, dass viele "gleichzeitige" Anfragen über persistente Verbindungen transportiert werden. Persistenz hilft, Zeit zu sparen, da Verbindungen aufrecht erhalten bleiben. HTTP/2 nutzt dies für einen effizienteren Datenaustausch. HTTP/3 macht durch das QUIC-Protokoll die Verbindung noch schneller.

Zustandslosigkeit ist eine Grundeigenschaft von HTTP und ändert sich auch mit den neueren Versionen nicht.