Predigt: KeepAlive und Transport-Encodings

[Christian Kruse]

Hallo Sven,

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.

Korrekt.

Der TCP/IP-Stack kann die einzelnen Ziele eindeutig
anhand der Client-IP/Port auseinanderhalten.

Korrekt.

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 Grenzen liegen nicht nur beim Apachen. Auch das
Betriebssystem selber legt Grenzen fest. Diese liegen idR
jedoch weit ueber 255 parallele Verbindungen pro Port. Bei
FreeBSD kann man den Wert ueber 'sysctl kern.ipc.somaxconn'
abgefragt werden. Er liegt normalerweise bei 2048 -- bei
Linux kann ich nicht genau sagen, wo sich der Wert versteckt,
aber er duerfte sich in aehnlichen Regionen bewegen.

Der von dir dargelegte Vorteil von KeepAlive beruht
einzig darauf, dass das Herstellen einer TCP-Verbindung
ein 3-Wege-Handshake erfordert.

Richtig.

Zuerst sendet der Client eine Verbindungsanfrage an den
Server, die der Server positiv beantwortet. Dann erst
kann der Client den eigentlichen HTTP-Request senden.

Das ist ein Zwei-Wege-Handshake :) Richtig waere:

Der lokale Rechner sendet ein SYN. Der Host sendet ein
SYN|ACK. Der lokale Rechner muss darauf mit einem ACK
antworten. Erst nach dieser erfolgreich abgelaufenen
Prozedur ist die TCP/IP-Verbindung aufgebaut.

Dasselbe gilt ueberigens fuer den Verbindungsabbau: hier muss
ein FIN von Seite a (a moege einer der beiden
Verbindungspartner sein; b ist demnach der andere) geschickt
werden. Der muss mit einem ACK|FIN von b beantwortet werden.
Das wiederum muss mit einem ACK von a beantwortet werden.
Danach erst ist die Verbindung aufgebaut.

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).

Falsch: erst das 4. Paket kann vom ueberliegenden Protokoll
genutzt werden.

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).

Die dreifache Ping-Zeit :) Aber das ist so auch nicht ganz
wahr. Es wird die Zeit gemessen, bis ich ein Paket losschicke
und eine Antwort zurueck kommt. Es wird also auf zwei
Datenpakete gewartet. So komme ich auf die 1 1/2-fache
Ping-Zeit.

Wer einen Ping von 0,5 Sekunden hat, wartet allein
deshalb pro Ressource eine Sekunde lang, ohne dass was
passiert.

0,75 Sekunden :)

Gruesse,
 CK