Webzugriff

Was passiert dabei im Detail?

HTTP-Antwort empfangen

Nachdem der Client den Request abgesendet hat (Push-Flag, um dies dem anderen System anzudeuten), ist der Server an der Reihe. Zuerst wird der HTTP-Request bestätigt:

IP 192.168.1.6.80 > 10.0.0.1.47401: . ack 176 win 1716 <nop,nop,timestamp 388120 1064978>

D.h. der Kernel reicht nun die Daten (den HTTP-Request) an den Webserver weiter. Dieser analysiert ihn und antwortet darauf (ich habe die TCP-Optionen weggelassen, die verwirren nur und enthalten keine hier wichtigen Informationen mehr):

IP 192.168.1.6.80 > 10.0.0.1.47401: . 1:1449(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 1449 win 69
IP 192.168.1.6.80 > 10.0.0.1.47401: . 1449:2897(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 2897 win 91
IP 192.168.1.6.80 > 10.0.0.1.47401: . 2897:4345(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 4345 win 114
IP 192.168.1.6.80 > 10.0.0.1.47401: FP 4345:4604(259) ack 176 win 1716
IP 10.0.0.1.47402 > 192.168.1.6.80: S 1285270109:1285270109(0) win 5840
IP 192.168.1.6.80 > 10.0.0.1.47402: S 1135847585:1135847585(0) ack 1285270110 win 5792
IP 10.0.0.1.47402 > 192.168.1.6.80: . ack 1 win 46
IP 10.0.0.1.47403 > 192.168.1.6.80: S 1290686861:1290686861(0) win 5840
IP 192.168.1.6.80 > 10.0.0.1.47403: S 1138145597:1138145597(0) ack 1290686862 win 5792
IP 10.0.0.1.47403 > 192.168.1.6.80: . ack 1 win 46
IP 10.0.0.1.47401 > 192.168.1.6.80: F 176:176(0) ack 4605 win 137
IP 10.0.0.1.47402 > 192.168.1.6.80: P 1:188(187) ack 1 win 46
...

Hier kann man noch etwas beobachten: Erst werden die Daten gesendet und auch bestätigt. Dann schließt der Webserver die Verbindung mit einem FP, aber der Client macht gleich darauf noch zwei Verbindungen auf, einmal mit dem Source-Port 47402 und einmal mit 47403.

Warum macht er das? Ganz einfach: Nachdem die index.html-Datei übertragen worden war, hat der Client diese analysiert und gesehen, dass da noch mehr Elemente nachgeladen werden müssen. Dafür öffnet er dann mehrere Verbindungen, um die Daten parallel zu laden. Das könnten auch andere Server sein, dann wäre es vermutlich deutlich schneller.

Mit tcpdump kann man aber auch gezielt eine Verbindung heraussuchen, z.B. durch Angabe des Source-Ports:

tcpdump -n -r lug.pcap port 47401

Das liefert, etwas gestutzt:

IP 10.0.0.1.47401 > 192.168.1.6.80: S 1287558560:1287558560(0) win 5840
IP 192.168.1.6.80 > 10.0.0.1.47401: S 1133845053:1133845053(0) ack 1287558561 win 5792
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 1 win 46
IP 10.0.0.1.47401 > 192.168.1.6.80: P 1:176(175) ack 1 win 46
IP 192.168.1.6.80 > 10.0.0.1.47401: . ack 176 win 1716
IP 192.168.1.6.80 > 10.0.0.1.47401: . 1:1449(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 1449 win 69
IP 192.168.1.6.80 > 10.0.0.1.47401: . 1449:2897(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 2897 win 91
IP 192.168.1.6.80 > 10.0.0.1.47401: . 2897:4345(1448) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: . ack 4345 win 114
IP 192.168.1.6.80 > 10.0.0.1.47401: FP 4345:4604(259) ack 176 win 1716
IP 10.0.0.1.47401 > 192.168.1.6.80: F 176:176(0) ack 4605 win 137
IP 192.168.1.6.80 > 10.0.0.1.47401: . ack 177 win 1716

Jetzt sieht man auch, wie die Verbindung abgebaut wird. Es können zwischen drei und vier Pakete sein:

FIN + ACK, hier noch mit Push-Flag
ACK des FINs -> half-closed Verbindung
FIN + ACK von der Gegenstelle
ACK, letztes FIN bestätigen, Verbindung ist zu.

Im obigen Fall erfolgt 2. und 3. in einem Paket. Es ist aber auch möglich, eine Verbindung halboffen zu halten, dann kann nur noch eine Seite senden. Schaut man sich die Antwort wieder genauer an, dann sieht man:

HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Encoding: gzip
Last-Modified: Thu, 30 Dec 2010 15:09:38 GMT
ETag: "1886677020"
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 4321
Connection: close
Date: Thu, 01 Jan 1970 01:09:41 GMT
Server: lighttpd/1.4.28

Danach folgt eine Leerzeile und Binärdaten. Der Server hat den Inhalt der Webseite mit gzip (Content-Encoding: gzip) gesendet. Wer sich an den Request erinnert, da stand u.a.:

Accept-Encoding: gzip

Daher wurde hier alles gepackt verschickt. Dabei ginge es auch anders, das deutet der Server mit

Vary: Accept-Encoding

an. Er könnte die Daten auch anders ausliefern, vermutlich nicht-gepackt.

Aus diesem Grund hatte ich auch noch lug2.pcap erstellt, da sieht man dann die Daten vom Server in der Antwort ungepackt.

Wer sich über das Datum wundert: Der 1.1.1970 ist der Start der Unix-Zeit, er enstpricht 0 Sekunden. Von dieser Zeit an wird die Zeit in Sekunden gezählt. Der Webserver hier war aber mein DockStar. Scheinbar kann der sich die Uhrzeit nicht merken und fängt dadurch beim Einschalten bei 0, also beim 1.1.1970 an.

Weiteres Vorgehen im Browser

Der Browser analysiert die erhaltenen Daten. Dabei gibt der Content-Type Auskunft darüber, um was für Daten es sich handelt. Bei reinen HTML-Dateien steht da z.B.:

Content-Type: text/html

Der Browser kann diese Daten direkt darstellen. Dazu analysiert er aber erst die Datei, ob da noch weitere Elemente vorliegen, so wie verwendete CSS-Dateien, eingebettete Links, Bilder, etc. Wenn alle Elemente vorliegen, fängt der Browser an zu rendern, d.h. er versucht die Elemente in der angegebenen Weise zu arrangieren, so dass sie darstellbar werden. Da hat dann z.B. die aktuelle Browsergröße einen Einfluss. Hier wird auch oft die meiste Zeit beim Surfen gewartet: Oft hilft deswegen auch keine schnellere Leitung.

Was passiert, wenn es sich um nicht-HTML-Dateien handelt? Dann schaut der Browser anhand des Content-Types nach, ob er ein Plugin zur Darstellung hat. (about:plugins in der URL-Zeile des Firefox gibt hier Auskunft oder auch Edit -> Preferences -> Applications.)

Ist das nicht der Fall, so wird in /etc/mailcap oder ~/.mailcap nachgesehen, ob hier steht, welches Programm die Daten anzeigen kann. Firefox fragt dann aber in aller Regel nach, ob er das Programm auch verwenden soll, eine Alternative dazu, oder ob die Daten nur gespeichert werden sollen.

In mailcap steht z.B.:

application/pdf; /usr/bin/gv '%s' ...

D.h. bei PDF-Dateien würde er hier das Programm gv starten, um die Daten anzeigen zu lassen. Oft gibt es aber mehrere Varianten, z.B. auch xpdf oder evince. Normalerweise wird die erste genommen, manche Programme schlagen das auch vor, bieten aber die Option, ein anderes auszuwählen.