IE5-6 und HTTP1.1 unterstützbar?

[Cyx23]

Hallo,

um gzip zu testen, hatte ich IE5 und IE6 mit aktiviertem HTTP1.1 getestet.

Bei manchen Seiten merken die IE offenbar erst verspätet, dass fertig geladen wurde.

Nun mag das bei mir an Installation oder u.U. Proxy liegen, eigentlich egal, da aber solche Probleme wahrscheinlich öfters mit den IE auftreten dürften, wäre es doch vorteilhalft solche Probleme wenn möglich für alle Besucher serverseitig zu vermeiden, vielleicht "Cache-Control" mit no-cache im HTML wenn es überhaupt am Cache liegt?

Grüsse

Cyx23

[Cyx23]

Hallo nochmal,

um gzip zu testen, hatte ich IE5 und IE6 mit aktiviertem HTTP1.1 getestet.

Bei manchen Seiten merken die IE offenbar erst verspätet, dass fertig geladen wurde.

Nun mag das bei mir an Installation oder u.U. Proxy liegen, eigentlich egal, da aber solche Probleme wahrscheinlich öfters mit den IE auftreten dürften, wäre es doch vorteilhalft solche Probleme wenn möglich für alle Besucher serverseitig zu vermeiden, vielleicht "Cache-Control" mit no-cache im HTML wenn es überhaupt am Cache liegt?

das Problem hat wohl konkret mit dem Zugang per msn (isdn, call by call) zu tun.

Also hat msn vmtl. einen Proxy o.ä. und verhunzt das HTTP1.1?

Trotzdem scheinen Einträge wie

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<meta http-equiv="cache-control" content="no-cache">

nicht zu helfen..

Auch wenn das Problem an der Kombination von IE 6 settings sowie msn(!) liegt,
könnten solche Probleme irgendwie HTML- oder Serverseitig abgefangen werden?

Grüsse

Cyx23

[Cyx23]

Und nochmal ein anderer Aspekt,

Auch wenn das Problem an der Kombination von IE 6 settings sowie msn(!) liegt,
könnten solche Probleme irgendwie HTML- oder Serverseitig abgefangen werden?

beim Selfforum-Server gelingt, was auf anderen Servern offfenbar
nicht klappt.

Wie ist der Selfforum-Server konfiguriert, dass die Forumhauptdatei über
msn (call by call isdn, proxy?) und http1.1 bei IE 6 doch richtig ankommt?

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

Wie ist der Selfforum-Server konfiguriert, dass die Forumhauptdatei über
msn (call by call isdn, proxy?) und http1.1 bei IE 6 doch richtig ankommt?

Hast Du mal mit einem Paketsniffer (z.B. Ethereal) untersucht, wie dei Daten denn bei dir ankommen? (Du könntest ja mal eine SELFHTML-Seite bei Dir zwischenspeichern, um zwei identische Dateien zu vergleichen)

Viele Grüße,
Christian

[Cyx23]

Hallo Christian,

Hast Du mal mit einem Paketsniffer (z.B. Ethereal) untersucht,

danke für den Tipp, ich muss mir das (Ethereal) erstmal in Ruhe anschauen, da sind wohl doch umfangreichere Treiber dabei und ich kann nicht abschätzen wie riskant eine Installation unter z.B. Win9x ist.

Falls die KeepAliveTimeout vom Selfserver deutlich kürzer ist als die http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf062.htm erwähnten 15 Sekunden wäre ein Grund schon so erkennbar, und bei dem betr. Projekt könnte ich die .conf sowieso nicht verändern.

Grüsse

Cyx23

[Christian Kruse]

Hallo Cyx23,

Falls die KeepAliveTimeout vom Selfserver deutlich kürzer
ist als die
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf062.htm
erwähnten 15 Sekunden wäre ein Grund schon so erkennbar,
und bei dem betr. Projekt könnte ich die .conf sowieso
nicht verändern.

Der Fehler muss woanders liegen. Hier ist 'KeepAliveTimeout'
auf 15s gestellt.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Hier ist 'KeepAliveTimeout' auf 15s gestellt.

wie sind denn so die Erfahrungen mit KeepAlive? Bringt das wirklich etwas? (Zumal, wenn Du noch einen Squid dazwischen hattest.)

Wir hatten mit KeepAlive so viele Probleme mit diversen Proxies, daß wir ziemlich schnell die Finger davon gelassen haben.

Viele Grüße
      Michael

[Cyx23]

Hallo,
-3. ein Versuch, Forumsabsturz?-

Der Fehler muss woanders liegen. Hier ist 'KeepAliveTimeout'
auf 15s gestellt.

danke für die Info.

Interessant zu dem Problem eine ähnliche Geschichte (redirect, 302)http://support.microsoft.com:80/support/kb/articles/q193/4/89.asp&NoWebContent=1&NoWebContent=1, besonders gegen Textende der Beschreibung:

"When Internet Explorer receives the first TCP frame with an HTTP/1.1 302 redirect, Internet Explorer processes the redirect
 command and attempts to use the open socket connection to the server that sent the redirect. This occurs because Internet
 Explorer has not processed the second TCP frame containing the FIN or the "socket close connection" command, so Internet
 Explorer assumes that the current state of the socket connection is still open. This is an intermittent problem because Internet
 Explorer may recognize that the socket connection was closed by the server and open a new socket connection to the server if
 Internet Explorer receives the TCP frames close enough together, or if no HTML body is sent at all. "

und:

"Add this function to your web server:

Function XRedirect(sURL)
      Response.Buffer = True
      Response.Clear
      Response.Status = "301 Moved"
      Response.AddHeader "Location", sURL
      Response.End
      End Function"

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

und ich kann nicht abschätzen wie riskant eine Installation unter z.B. Win9x ist.

Ich kann jetzt zwar natürlich für nichts garantieren, hatte aber nie Probleme damit unter Windows 98.

Viele Grüße,
Christian

[Michael Schröpl]

Hi Cyx23,

Wie ist der Selfforum-Server konfiguriert, dass die Forumhauptdatei über
msn (call by call isdn, proxy?) und http1.1 bei IE 6 doch richtig ankommt?

den HTTP-Traffic kannst Du Dir selbst ansehen (http://www.schroepl.net/cgi-bin/http_trace.pl); wenn dort kein signifikanter Unterschied sichtbar wird, würde ich ihn auf einer niedrigeren Protokollebene vermuten.

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

den HTTP-Traffic kannst Du Dir selbst ansehen (http://www.schroepl.net/cgi-bin/http_trace.pl); wenn dort kein signifikanter Unterschied sichtbar wird, würde ich ihn auf einer niedrigeren Protokollebene vermuten.

da ist tatsächlich ein Unterschied (komfortabler Link!) zu erkennen:

ok (arcor basis):

[ 17] HEAD  HTTP/1.1
[ 13] Accept: */*
[ 32] Accept-Encoding: gzip, deflate
[ 21] Accept-Language: de
[ 19] Connection: close
[ 29] Host: ....

problem (msn):

[ 17] HEAD  HTTP/1.1
[ 13] Accept: */*
[ 32] Accept-Encoding: gzip, deflate
[ 21] Accept-Language: de
[ 29] Host: ....
[ 30] Proxy-Connection: Keep-Alive

-führt zu rund 15 Sekunden Verzögerung/Warten bei IE6/http1.1.

Allerdings schauen die Einträge bei selfforum.teamone genauso aus,
aber ohne 15 Sek. Wartezeit. Eine Erklärung warum der Self-Server
sich anders verhält ist hier nicht ersichtlich; vielleicht beendet
der Selfserver Verbindungen recht zügig von selbst?

Diese Antwort:

[ 70] Your browser sent a request that this server could not understand.
[ 55] client sent invalid HTTP/0.9 request: HEAD HTTP/1.1

kommt offenbar gleich von den verschiedenen Servern beim IE 6.

Grüsse

Cyx23

[Cyx23]

Hallo,

ok (arcor basis):
[ 19] Connection: close
[ 29] Host: ....

problem (msn):
[ 29] Host: ....
[ 30] Proxy-Connection: Keep-Alive

-führt zu rund 15 Sekunden Verzögerung/Warten bei IE6/http1.1.

da wäre interessant, ob eine KeepAliveTimeout von 15 Sekunden üblich ist,
dann würde die Verzögerung dieser KeepAliveTimeout entsprechen.

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?

Dass solange die Verbindung offengehalten wird und im einen Fall aber
nicht genutzt werden kann?

Grüsse

Cyx23

[Michael Schröpl]

Hi Cyx23,

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)

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.

HTML-Seiten haben aber eine gewisse Charakteristik. In vielen Fällen enthalten HTML-Seiten Referenzen auf weitere HTTP-Ressourcen: Bilder, JavaScript- und CSS-Dateien, Applets, whatever. KeepAlive ist nun eine Erweiterung zu HTTP, welche es dem Server erlaubt, die Verbindung nach der Übertragung der Antwort nicht sofort zu schließen, sondern dies von einer komplexeren Logik abhängig zu machen. Und solange die Verbindung besteht, _darf_ der Client eben weitere Requests senden, ohne dafür den entsprechenden Handshake durchführen zu müssen. Die konkreten 15 Sekunden sind dabei ein "sophisticated guess", den man am besten der Charakteristik der eigenen Webseiten anpassen sollte, wenn man entsprechende Werte ermitteln könnte ... wobei allerdings nicht nur die Zahl und Größe der referenzierten Ressourcen eine Rolle spielen, sondern beispielsweise auch noch das Caching-Verhalten bezüglich dieser Ressourcen (welches wiederum von weiteren eigenen Aktionen abhängt).
KeepAlive lebt also von dem Charakter heutiger real existierender HTML-Seiten, der in der Frühphase der HTTP-Spezifikation vielleicht anders gedacht war (weniger modular und weniger multimedial?).

Konkret beim Apache kann man zwei Obergrenzen einstellen: 1. eine Zeitdauer und 2. eine Anzahl von Requests. Wird eines von beiden erreicht, dann klappt der Server die Verbindung eben doch zu. Der Client kann selbst jederzeit aufgeben (und tut dies auch immer dann, wenn er KeepAlive einfach nicht unterstützen kann); er verliert dabei schlimmstenfalls Performance. Der Server verhindert durch das Schließen der Verbindungen, daß ein Angreifer den KeepAlive-Mechanismus für eine DoS-Attacke nutzen kann.

Die Grenzen der Benutzbarkeit von KeepAlive sind allerdings vielfältig. Insbesondere müssen _sämtliche_ HTTP-Zwischenstufen auf der gesamten Verbindung diesen Mechanismus unterstützen, sonst nützt er gar nichts. Schon wenn Du über einen einzigen Proxy-Server drüber mußt, der das nicht kann (und die Verbindung, deren Stabilität der Server "garantiert hat", eben doch unterbricht), kann dir das passieren, was Du gerade erlebst: Der Browser versucht, eine Verbindung zu verwenden, die schon nicht mehr existiert, weil der Server ihn dazu ermutigt hat - und keiner von beiden erkannt hat, daß zwischen ihnen ein "man in the middle" mitspielt, der sich nicht an die zwischen _ihnen_ ausgehandelten Regeln hält (weil er dazu nicht "genug HTTP" versteht).

Im konkreten Falle ist KeepAlive überhaupt eine nicht ganz ungefährliche Idee. Sie unterwandert nämlich in gewisser Weise das Konzept von HTTP, und wenn man nicht weiß, was man tut, kann man sich existierende Mechanismen damit lahmlegen.
"Normalerweise" enthält ein HTTP-Header für eine anschließend auszuliefernde Ressource insbesondere eine "Content-length:"-Angabe. Bei der Auslieferung des Inhalts statischer Dateien ist es auch einfach, diesen Header zuerst zu berechnen und anschließend den Datei-Inhalt auf die Leitung zu kippen. Was aber ist, wenn der Inhalt dynamisch berechnet wird - sagen wir mal, von einer Suchmaschine oder einem Datenbankzugriff? Die entsprechenden Applikationen wissen nicht, daß das HTTP-Frontend gerne die Gesamtgröße der Ausgabe wissen möchte - sie liefern einfach Daten. Nun müßte also das HTTP-Frontend sämtliche Daten absaugen, das HTML-Dokument generieren und puffern, nun dessen Größe berechnen und schließlich zuerst den HTTP-Header und danach das Dokument ausliefern. Was die Antwortgeschwindigkeit nicht gerade positiv beeinflussen würde.
Weil dies so ist, kann HTTP noch etwas anderes: Es kann "chunks" als Transport-Codierung verwenden (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1). Ein dynamisches serverseitiges Skript kann also einfach seine Ergebnisse ausgeben, ohne sich um die Content-length zu kümmern; am Ende darf ein Trailer fehlende HTTP-Header nachliefern. Der Client, welcher diese Transport-Codierung versteht, muß alles puffern und wieder so zusammenbauen, als wäre es in einem Rutsch und in der richtigen Reihenfolge eingetroffen. Solange der Trailer auch zuverlässig kommt, ist das noch kein Problem.
Nun ist der Trailer aber leider optional! Der Server kann einfach aufhören zu senden, und der Client muß damit fertig werden! (Sonst unterstützt er HTTP/1.1 nicht vollständig.) Solange der Server am Ende seiner Übertragung brav die Verbindung kappt, wie das in HTTP vorgesehen ist, liegt immer noch kein Problem vor.
Aber jetzt übertrage mal mit chunked transport encoding über eine HTTP-Verbindung mit KeepAlive ... woher weiß der Client jetzt, daß er wieder senden darf, wenn die empfangene HTTP-Response weder eine Längenangabe noch eine "Klammer zu" enthält? Das würde genau Deine 15 Sekunden Wartezeit erklären. Und der Apache setzt "chunked" encoding tatsächlich ein - sowohl bei CGI- als auch bei SSI-URLs ... (vermutlich auch bei PHP, denke ich mal.) Mein HTTP-Trace-Skript kann das nicht visualisieren, weil es ein Perl-Modul (LWP) einbindet, welches dies offenbar kapselt; Christian Kruses Version desselben Skript (das direkt socket-Verarbeitung macht) kann beispielsweise "chunked" responses derzeit gar nicht verarbeiten.

So ist das eben mit den Standards: Wenn alle sich daran halten würden, würde vieles prima funktionieren ... das ist der Grund, weshalb man KeepAlive sowohl im Apache als auch in Mozilla ein- und ausschalten kann: Man muß wissen, was man tut, und ob das eigene Szenario den Einsatz sinnvollerweise ermöglicht oder nicht.
Und würden sich die Proxies auf dem Weg daran halten, "Via:"-Header zu senden, in denen drin stünde, was sie können und was nicht, dann könnte der Client im vorliegenden Falle sogar gewarnt werden, dem Keep-Alive-Versprechen des HTTP-Servers besser nicht zu glauben, weil der Proxy sich nicht daran gebunden fühlt. Aber natürlich ist dieser Header auch wieder nur optional ... und wenn die Beteiligten nicht miteinander reden, wie sollen sie einander dann verstehen und sinnvoll zusammenarbeiten können?

Ein ganz ähnliches Problem ist beispielsweise das Cachen von HTTP-Negotiation-Ergebnissen in Proxy-Servern: Auch hier kann der "Mittelmann" heftig versagen, wenn er nicht weiß, was er tut - nicht zuletzt dann, wenn der Server nicht daran gedacht hat, ihn mit entsprechenden Zusatzinformationen zu versorgen, die _nur_ dem Proxy etwas nützen und für den Browser entbehrlich gewesen wären ... das ist der Grund für die Existenz der aktuellsten mod_gzip-Version.

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

danke für die Ausführungen!

Da ich die .conf hier nicht verändern kann, habe ich versucht per "KeepAliveTimeout 3" in der htaccess etwas zu ändern, soll nach einem noch im googlecache zu findenem Text  http://www.spcomputing.com/web_tutorials/htaccess_tutorial/keep_alive_timeout.php. sogar gehen, führte allerdings zu einem 500er Fehler...

Eigentlich könnte man ja meinen, wer bei einem IE das "HTTP1.1" auch für proxies einstellt und dann z.B. per msn surft ist selbst Schuld am Problem, aber unterm Strich bleibt halt eine teilweise schlechtere Erreichbarkeit, die m.E. auch beim Zugang über tonline öfters auftreten könnte.

Grüsse

Cyx23

[Michael Schröpl]

Hi Cyx23,

habe ich versucht per "KeepAliveTimeout 3" in der htaccess etwas zu ändern,

http://httpd.apache.org/docs/mod/core.html#keepalivetimeout
sagt: "Context: server config".

Nein, der Apache ändert ein Kommunikationsverhalten nicht pro URL - wie soll das bei einer explizit ÜRL-übergreifenden Angabe auch funktionieren?

Viele Grüße
      Michael

[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

[Michael Schröpl]

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

ah - danke schön. Was glücklicherweise für den Rest meiner Argumentation nicht arg relevant war. ;-)

Das heißt, die (etwa in Opera konfigurierbaren) parallelen Verbindungen des Browsers können tatsächlich zeitgleich (und nicht nur zeitlich verschränkt) mit dem HTTP-Server kommunizieren?

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.

Yep - und je kleiner die nachgesaugten Ressourcen (GIF-Icons, beispielsweise), desto (relativ) teurer der Handshake für die Gesamt-Übertragung.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Das heißt, die (etwa in Opera konfigurierbaren)
parallelen Verbindungen des Browsers können tatsächlich
zeitgleich (und nicht nur zeitlich verschränkt) mit dem
HTTP-Server kommunizieren?

Korrekt. Sogar in jedem Sinne, da alle Netzwerkverbindungen
ueber denselben Interrupt kommen und dem Prozessor es egal ist,
woher die Daten kommen.

Gruesse,
 CK

[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

[Sven Rautenberg]

Moin!

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.

Ja, ok, hab' ich ein Detail etwas unterschlagen.

Allerdings gilt für die Zeit: Der Client kann nach dem Senden des ACK sofort weitere Daten über die dann hergestellte Verbindung senden. Die Pakete können also direkt aufeinander folgen, ohne dass deswegen Zeit verloren geht.

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.

Ja, stimmt dann auch. Obwohl es eigentlich unsinnig ist, extra deswegen _zwei_ einzelne Pakete zu schicken - das könnte man doch auch in ein Paket packen. Ich bin mir nicht sicher, ob das nicht sogar gemacht wird - und gerade zu faul, tcpdump anzuwerfen. ;)

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.

Nö, das mit der doppelten Ping-Zeit ist schon nicht falsch. :)

Es wird nennenswert Zeit verbraucht, um auf ein Datenpaket vom Client eine Antwort vom Server zu erhalten. Diese Zeit vergeht einmal für den ersten Handshake-Teil, und dann (da der Client das ACK und den Request sofort hintereinander schickt) noch einmal für die Antwort auf den Request.

Die Zeit kann länger sein, wenn der Webserver noch viel Zeit für die Auslieferung der Ressource benötigt.

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

0,75 Sekunden :)

Ok, nach 0,75 Sekunden legt der Webserver los, aber erst nach einer Sekunde merkt man davon was am Client. Und nur diese Zeit ist interessant für den Benutzer.

- Sven Rautenberg

[Michael Schröpl]

Hi Cyx23,

Trotzdem scheinen Einträge wie
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<meta http-equiv="cache-control" content="no-cache">
nicht zu helfen..

kein Wunder - das ist ja auch HTML und kein HTTP. Was soll z. B. ein HTTP-Proxy damit anfangen?

Viele Grüße
      Michael