Predigt: KeepAlive und Transport-Encodings

[Sven Rautenberg]

Moin!

Der Selfserver hat wohl eine KeepAliveTimeout von 15 Sekunden, d.h. das
unterschiedliche Verhalten wäre damit nicht erklärbar.
Was aber bedeutet "Die Zeitspanne um auf die nächste Abfrage desselben
Clients mit derselben Verbindung zu warten." konkret?

(ich bewege mich mal auf dünnem Eis ... Netzwerk-Experten, bitte korrigiert mich, falls erforderlich)

Ok. Naja, Netzwerk-Experte mag nicht stimmen, aber zum Korrigieren eigne ich mich. :)

Der Aufbau einer HTTP-Verbindung setzt den Aufbau einer TCP/IP-Verbindung voraus, erfordert also ein explizites Handshaking mit dem Server, um eine entsprechende Übertragung vorzubereiten (der Server will ja nicht den Port 80 zunageln, wo er ständig neue Requests annehmen möchte).
Client und Server einigen sich also auf einen zu verwendenden Port, und über diesen wird dann der eigentliche HTTP-Request gesendet und die Response zurück übertragen. Anschließend kann die Verbindung geschlossen und dieser Port wieder freigegeben werden.

Platsch, reingefallen.

Die HTTP-Verbindung wird tatsächlich komplett über den Server-Port 80 sowie den vom Browser belegten Client-Port abgewickelt. Eine Veränderung der Portbelegung findet nicht statt. Der TCP/IP-Stack kann die einzelnen Ziele eindeutig anhand der Client-IP/Port auseinanderhalten. So können also über den einen TCP-Port 80 ziemlich viele (soviele, wie Serverressourcen da sind) Verbindungen abgewickelt werden. Typischerweise erlaubt der Apache 150 Child-Prozesse, also 150 parallele Verbindungen. Die Zahl kann bis auf 255 hochkonfiguriert werden, darüber hinaus ist im Quelltext eine Änderung der maximalen Child-Zahl notwendig - aber auch das sollte funktionieren. Ich weiß aber nicht, was aktuelle Betriebssysteme so als Maximum vertragen.

Der von dir dargelegte Vorteil von KeepAlive beruht einzig darauf, dass das Herstellen einer TCP-Verbindung ein 3-Wege-Handshake erfordert. Zuerst sendet der Client eine Verbindungsanfrage an den Server, die der Server positiv beantwortet. Dann erst kann der Client den eigentlichen HTTP-Request senden.

Dieses Handshake kann auch mit fortgeschrittenen Netzwerk-Techniken zeitlich nicht verkürzt werden: Es muß zwingend die Laufzeit der Pakete abgewartet werden. Also geht ein Datenpaket hin, eines kommt zurück, und eines geht wieder hin (das erste, was effektiv dem darüberliegenden Protokoll etwas bringt).

Wenn man sich die Zeit, die dabei draufgeht, mal ausmalt: Mit Modem hat man unter Umständen Ping-Zeiten von mehreren hundert Millisekunden. Mit anderen Worten: Der Aufbau einer TCP-Verbindung bis hin zur ersten Serverreaktion (indem er eine HTML-Seite o.ä. sendet) dauert mindestens die doppelte Ping-Zeit (Handshake hin und her, Request hin und her). Wer einen Ping von 0,5 Sekunden hat, wartet allein deshalb pro Ressource eine Sekunde lang, ohne dass was passiert. Und 0,5 Sekunden (oder 500 ms) sind zum Beispiel bei Satellitenstrecken heutzutage auch bei hohen Bandbreiten vorhanden.

- Sven Rautenberg