Chat in HTML mit einer Scriptsprache ohne Reload

[Michael Schröpl]

Hallo Stefan,

Und wer schreibt vor, dass immer nur komplette HTML-Seiten uebertragen werden muessen,
und nicht mal nur einzelne HTML-Strings?

Niemand. Aber es ist hochgradig unwirtschaftlich, einzelne HTML-Skripts mit HTTP zu übertragen.

HTTP erfordert sowohl für den Request als auch für die Response einen HTTP-Header.
Beim Request ist dieser bei handelsüblichen Browser-Konfigurationen 400-700 Bytes lang (wenn man sich bei der Browser-Konfiguration sehr gut auskennt, kann man ca. 50% davon einsparen: Cookies aus, Referer aus, User-Agent weg, wenn man sich traut, Language weg, wenn man nicht mit Negotiation rechnet, Accept- und Accept-Encoding-Listen kürzen etc. - beim M$IE steht das Zeug in der Registry, man kommt an ziemlich viel davon ran ... ich müßte eigentlich mal einen Feature-Artikel darüber schreiben ...), bei der Response etwa 200-300 Bytes (das liegt auf der Seite des Servers und dort an der Art der Antwort, d. h. es hängt teilweise auch von der Art der Frage ab).
Durch Cookies kann dieser Wert übrigens extrem in die Höhe gehen: Ein Cookie kann bis zu 4 kB Inhalt haben, und wenn das bei jedem Request hin und her geschickt werden muß ...
Hinzu kommt noch etwas Verpackung auf TCP/IP-Ebene ... wenn Du pro Request konservativ einen Overhead von 1 kB schätzt, liegst Du auf der sicheren Seite.
(OT: In mgzta ist dieser Wert konfigurierbar, weil Apache 1.3 ihn leider gar nicht erfassen kann - in Apache 2.0 soll das wohl gehen.)

Wenn Du eine HTML-Seite im Umfang von 10 kB über das Netz sendest, dann hast Du also immerhin fast 10% Verpackungs-Overhead. Bei großen Dateien wird das Verhältnis immer günstiger; bei kleinen Dateien (etwa den Markierungs-GIFs hier im Forum) wird es immer schlechter. Auch ein GIF-Bild von nur 50 Byte kostet 1000 Bytes Verpackung - satte 2000% Overhead also! Ich kenne kaum ein Ladezeit-Analyse-Werkzeug, das diese Werte in seiner Berechnung berücksichtigt ... aber viele kleine Bilder können eine Katastrophe sein, wenn der Browser sie alle einzeln anfordern muß.

Und schlimmer noch: Selbst ein "conditional GET" eines Browsers, also die Frage "ich habe hier einen Cache-Inhalt vom Datum X.Y - hast Du schon etwas Neueres, oder darf ich den weiter verwenden?" kostet immer noch dieselben 1000 Bytes - Du sparst gerade mal die 50 Bytes des Bildchens ein, nicht aber die übrigen 95% des Übertragungsvolumens.
Das ist der Grund, weshalb ich es für so wichtig halte, solche Bilder vom Browser "aggressiv" cachen zu lassen, also durch den Server eine Aufbewahrungsfrist zu senden, während welcher der Browser den Server _nicht_fragt_ (vorausgesetzt, der Browser ist richtig konfiguriert ... das sind leider natürlich auch nicht alle). Dies kostet zwar zusätzliche ca. 50-100 Bytes im Response-Header - aber wenn ich damit 20% aller Anfragen verhindern kann (in dieser Größenordnung lag der Effekt auf dem Self-Server, wo Christian das aktiviert hat), ist das eine gute Investition. (Vor allem wird das Surfen subjektiv schneller, weil sich die zeitliche Verteilung der HTTP-Requests ändert - _das_ ist ein "Preloading-Effekt".)

Und nein - HTTP-Header werden üblicherweise auch nicht komprimiert übertragen. Es gibt zwar wohl auf Modem-Ebene ein Protokoll, welches das kann, aber erstens unterstützt das nicht jeder ISP und zweitens sind die Informationen eines HTTP-Headers von begrenzter Redundanz, insbesondere sehr viel schlechter komprimierbar als HTML oder CSS: Innerhalb _eines_ HTTP-Headers wiederholt sich nichts.
(Ich habe hier ein "Labor" von HTTP-Request-Headern von ca. 20 Browsern und habe die gerade mal alle gezippt: Die Komprimierungsraten liegen zwischen 19% und 34%, während bei HTML 60-90% durchaus normal sind - wir haben schon Fälle von 97% gemessen, bei großen Tabellen ohne CSS ...)

Die gesendeten HTTP-Header sind _einander_ sehr ähnlich: Etwa 50-75% ihres Inhalts ist immer gleich. Aber HTTP hat ja kein Gedächtnis, deshalb kann man auch keine Deltas übertragen.
Hier ist eine stehende Verbindung (welche diesen immer gleichen Teil natürlich auf dem Server cachen würde) grundsätzlich überlegen, wenn viele kleine Anforderungen übertragen werden sollen.

Wenn Du pro Chat-Posting einen Mittelwert von ca. 100 Bytes annimmst, dann hast Du einen mittleren Verpackungs-Overhead von 1000%. Das kann's nicht sein.

aber warum jemand tobt, wenn ueber ein zustandsloses Protokoll doch noch eine Art
Quasi-Verbindung (z.B. ueber intervallische Aufrufe) realisiert wird, kann ich daran
keine Vergewaltigung erkennen.

Jetzt immer noch nicht? ;-)

Viele Grüße
      Michael