Keep-Alive
Als Keep-Alive, keep-alive oder keep alive werden ganz allgemein Kommunikationsverbindungen in einem Netzwerk bezeichnet, die nicht beendet, sondern aufrecht gehalten werden, bis der Client oder Server die Verbindung unterbricht. Das wesentliche Merkmal von Keepalive-Verbindungen ist das Versenden einer inhaltslosen Nachricht zwischen einem Server und einem Client. Mithilfe dieser Nachricht kann einer der Netzwerkteilnehmer (Client oder Server) kontrollieren, ob die Verbindung noch besteht und verhindern, dass sie abgebrochen wird. Falls die Verbindung noch vorhanden ist, kann diese für einen weiteren Datenaustausch genutzt werden.
Keepalive-Verbindungen werden ebenfalls als HTTP keep-alive, persistente HTTP-Verbindungen sowie HTTP connection reuse bezeichnet. Das HTTP 1.1 Protokoll unterstützt keep-alive standardmäßig und führt auch HTTP Pipelining ein, um Anfragen in Stapeln zu verarbeiten. HTTP 2 erweitert das Verfahren von persistenten Verbindungen noch um zusätzliche Möglichkeiten (zum Beispiel das Multiplexverfahren).
Allgemeine Informationen zum Thema
Die herkömmliche Netzwerkkommunikation arbeitet nach einem Anfrage-Antwort-Schema (engl.: request and response): Ein Client fragt bei einem Server bestimmte Daten ab; der Server antwortet, indem er das Vorhandensein dieser Daten bestätigt - oder ablehnt und einen Fehlercode ausgibt. Wenn die Daten vorliegen, fordert der Client diese an, indem er eine neue Verbindung aufbaut. Anschließend interpretiert der Client die Daten und stellt sie dar; falls sie nicht vollständig sind, fordert er weitere Daten an, um die Anzeige zu komplettieren. Auch dafür wird eine neue Verbindung verwendet und mitunter entstehen Daten, die nicht benötigt werden (engl.: Overhead). Bei dem HTTP Protokoll 1.0 wird für jede Anfrage stets eine neue TCP-Verbindung hergestellt. Das bedeutet, dass jede Anfrage eines Clients vom Server einzeln behandelt und, falls möglich, einzeln beantwortet wird.
Für Websites ist es typisch, dass sie aus verschiedenen Datenressourcen bestehen. Beispielsweise HTML-Dateien, CSS-Auszeichnungen und Skripte, die die Nutzerinteraktionen beeinflussen. Auch Bilder oder Multimedia-Dateien zählen dazu. Im Grunde wird bei HTTP 1.0 für jede Datei eine gesonderte Verbindung benötigt, die auch wieder beendet werden muss. Gerade bei größeren Websites ist dieses Vorgehen ineffizient, da die Netzwerkauslastung sehr hoch ist (engl.: network congestion).[1] Um zu verhindern, dass viele einzelne Verbindungen aufgebaut und wieder beendet werden müssen, wurde das Netzwerkmanagement durch persistente Verbindungen und HTTP Pipelining erweitert. Bei dem Protokoll HTTP 1.1 ist es nun möglich, multiple Anfragen und Antworten pro Verbindung zu realisieren, wobei für jede Verbindung eine spezielle Keep-alive-Nachricht zwischen Client und Server hin und her gesendet wird und Anfragen in einer Pipeline gespeichert werden können.
Funktionsweise
Die meisten Server können so aufgesetzt und konfiguriert werden, dass sie keep-alive unterstützen.[2] Auf der Clientseite sind die am häufigsten verwendeten Browser schon jetzt in der Lage, persistente Verbindungen aufzubauen. Dies ist allerdings eine Frage der Konfiguration auf Serverseite: Je nach verwendeter Technologie und Programmiersprache unterscheiden sich die notwendigen Änderungen ein wenig in der Syntax und der Semantik. Bei einem Apache-Server kann keep-alive in der Konfigurationsdatei „httpd.conf“ erlaubt werden. Dabei sind drei Eigenschaften besonders wichtig:[3]
- KeepAlive: Bei dieser Eigenschaft können die Werte on und off eingetragen werden. Bei HTTP 1.1 ist on der Standardwert.[4]
- MaxKeepAliveRequests: Diese Eigenschaft definiert die maximal möglichen Anfragen pro Verbindung. Ein Wert zwischen 50 und 100 ist meist ausreichend. Allerdings ist dieser Wert von der Größe des Webprojektes beziehungsweise von der Anzahl der Dateien auf einer Website abhängig.
- KeepAliveTimeout: Wenn der Server keine Requests empfängt, befindet er sich im Leerlauf und hält die Verbindung so lange aufrecht, bis sie abgebrochen wird. Die Eigenschaft Timeout begrenzt die Zeit, die der Server auf eine neue Anfrage warten muss. Etwa 10 Sekunden werden als ideal angesehen – jedoch kann das Timeout bei Websites mit sehr viel Traffic durchaus höher angesetzt werden.
Wenn in der Serverkonfiguration die entsprechenden Eigenschaften und Werte eingetragen wurden, sendet der Apache-Server Antworten auf Anfragen, die in etwa folgendermaßen aussehen:[5]
~$ curl -I https://www.domain.com/file.html HTTP/1.1 200 OK Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Date: Thu, 15 Jan 2015 16:45:29 GMT Content-Length: 1845 Keep-Alive: timeout=10, max=20 Server: Apache/2.4.9 (Unix) PHP/5.6.2
Das Prinzip ist bei allen Servern ähnlich: Zwischen Client und Server werden sehr kleine Nachrichten, die sogenannten keep-alive-messages, ausgetauscht. Sie ermöglichen es dem Client, innerhalb einer Verbindung mehrere Dateien zu erhalten. Die keep-alive-Message wird mittels des HTTP-Headers übertragen. Sie sagt dem Client oder dem Server, dass die Verbindung aufrecht erhalten werden soll. Jede Anfrage wird anschließend über eine Verbindung getätigt. Erst wenn einer der Netzwerkteilnehmer die Verbindung abbricht, sind keine multiplen Anfragen und Antworten mehr möglich.
Keep alive per .htaccess
Wenn für Website-Betreiber kein Zugang zu der Serverkonfiguration besteht, können die Änderungen auch in der .htaccess-Datei vorgenommen werden. Die .htaccess überschreibt die Konfiguration des Apache-Servers, indem folgender Quellcode dort notiert wird:[6]
<IfModule mod_headers.c> Header set Connection keep-alive </IfModule>
Nun wird jeder Anfrage der keep-alive-Header angefügt. Empfehlenswert ist ein Test, um zu überprüfen, ob die Änderung vom Server wie gewünscht umgesetzt wird. Genauere Definitionen von Timeouts und maximalen Anfragen können jedoch nur in der Konfigurationsdatei des jeweiligen Servers vorgenommen werden.
Bedeutung für die Programmierung
Persistente Verbindungen sind im HTTP 1.1 Protokoll als Standard vorgesehen. Das HTTP 2 Protokoll erweitert diesen Standard noch um ein Multiplexverfahren, das die Datenübertragung weiter optimiert. Ob und inwiefern diese Möglichkeiten genutzt werden, ist von der technischen Infrastruktur und dem Client abhängig. Das heißt, dass die Protokolle verschiedene Optimierung ermöglichen, die Umsetzung aber mitunter auf Serverseite stattfinden muss.
Für bestimmte Webprojekte sind keep-alive Header besonders empfehlenswert. Dies gilt für Websites mit vielen Dateien und umfangreichen multimedialen Inhalten sowie für Onlineshops, die auf HTTPS-Verbindungen angewiesen sind. Denn HTTPS ist allgemein ressourcenintensiv in der Übertragung von Dateien, weil die Verbindung mittels des Secure Socket Layer verschlüsselt wird. Durch das Anfügen eines keep-alive Headers kann die Ladegeschwindigkeit von Websites maßgeblich verkürzt werden, weil die Latenzzeiten zwischen unterschiedlichen Verbindungen gänzlich vermieden werden. Es besteht ja nur eine Verbindung, die multiple Anfragen und Antworten erlaubt und der Server kann diese nacheinander abarbeiten.
Zudem: Da beim Aufsetzen von neuen Verbindungen auf der TCP/IP-Schicht (das ist das, was unter der Anwendungsschicht des HTTP-Protokolls liegt) Ressourcen, wie die CPU (engl.: central proccesing unit) und der Speicher, benötigt werden, kann durch den keep-alive Header auch die CPU entlastet werden: Der Rechner muss deutlich weniger TCP-Verbindungen aufbauen.[7]
Einzelnachweise
- ↑ Congestion techopedia.com. Abgerufen am 06.06.2016
- ↑ How to enable keep alive varvy.com. Abgerufen am 06.06.2016
- ↑ Apache Performance Tuning: KeepAlive to remove latency maanasroyy.wordpress.com. Abgerufen am 06.06.2016
- ↑ HTTP Keep Alive web.archive.org. Abgerufen am 06.06.2016
- ↑ What is Keep-Alive? maxcdn.com. Abgerufen am 06.06.2016
- ↑ Connection keep-alive per .htaccess aktivieren pressengers.de. Abgerufen am 06.06.2016
- ↑ Apache optimization: KeepAlive On or Off? abdussamad.com. Abgerufen am 06.06.2016
Weblinks
- Keep-alive header clarification
- Spezifikation: Hypertext Transfer Protocol (HTTP) Keep-Alive Header
- Key Differences between HTTP/1.0 and HTTP/1.1