-
Die
Erfindung betrifft einen Server, einen Pufferspeicher und einen
Browser zur beschleunigten Übermittlung
von Hypertext-Dokumenten,
insbesondere von HTML-Seiten mit dem Protokoll HTTP.
-
Die
Verwendung des als Internet bekannten Netzwerks mit 'Browser' genannten Anzeigeprogrammen, der
Markierungssprache HTML und dem Protokoll HTTP ist dem entsprechenden
Fachmann im Detail allgemein bekannt.
-
Bei
dem Abruf von HTML-Seiten wird seitens der Autoren der Seiten in
immer größerem Umfang
von Grafiken und anderen eingebetteten Komponenten Gebrauch gemacht.
Dies bewirkt, daß zunächst die
durch eine URL adressierte HTML-Seite von dem darin angegebenen
Server abgerufen und vom Server an den Browser übertragen wird. Nach dem Erhalt
der Seite (oder eines ersten Teils) wird diese nach den Syntax-Regeln
von HTML analysiert, wobei die Elemente durch Tags markiert sind.
Dabei werden Grafiken durch das IMG-Tag eingebettet. Das IMG-Tag enthält mit dem 'SRC=' Parameter die Adresse
einer zu ladenden Grafik oder Bilddatei. Für jedes dieser Elemente wird
nun die Datei von dem Server abgerufen, also für jedes Bild ein Anforderungs-Antwort-Paar
des HTTP-Protokolls durchgeführt.
-
Die
damit lange Zeit des Aufbaus einer HTML-Seite wird durch verschiedene
Maßnahmen
kompensiert. Zum einen erlaubt es das Protokoll HTTP/1.1, eine Verbindung
geöffnet
zu halten, so daß der
Verbindungsauf- und -abbau entfallen. Weiterhin hat der Browser
regelmäßig einen
Pufferspeicher ('cache'), dem bereits früher geladene
Elemente entnommen werden können.
Letzterer wird allerdings dadurch entwertet, daß die Grafik-Designer mit Vorliebe
auf jeder Seite unterschiedliche Grafiken einsetzen. Außerdem kann
der Pufferspeicher nur Elemente identischer Adresse puffern; beim
Aktivieren eines Verweises, der auf einen anderen Rechner führt, sind
von dort alle Gra fiken neu zu laden, wenn diese Seite das erste
Mal besucht wird. Das Problem wird lediglich durch die hohen Rechengeschwindigkeiten
und schnellen heutigen Netzwerkverbindungen den professionellen
Nutzern wenig sichtbar. Es wird allerdings festgestellt, daß auch die
privaten Benutzer nicht mehr bereit sind, lange auf den Aufbau einer
Seite zu warten und ein kommerzielles Angebot gegebenenfalls nicht
mehr in Betracht ziehen, wenn die Ladezeit subjektiv zu langsam
ist.
-
Für die spezielle
Klasse eingebetteter Objekte namens JAVA-Applet sieht das HTML-Tag vor, daß nicht
nur der Name der auszuführenden
JAVA-Klasse, sondern zudem die Adresse eines JAR-Archivs angegeben
wird, in dem die Klasse enthalten sein soll. Der Browser lädt dann
das gesamte Archiv und entnimmt die Klasse wie auch davon benötigte Objekte
dem Archiv.
-
Davon
ausgehend, wird in der Patentschrift
US
6,026,437 eine Verbesserung vorgeschlagen. Wenn in der
traditionellen Lösung
zunächst
das HTML-Dokument und danach das JAR-Archiv in zwei getrennten Aufrufen
geladen werden muß,
so schlägt
die genannte Schrift vor, daß der
Hypertext-Verweis ('link') auf ein JAR-Archiv
zeigt, das genau ein, das JAR-Archiv benutzende HTML-Dokument enthält. Diese
Lösung
erfordert allerdings zuvor Änderungen
aller Browser, da die Optimierung durch eine geänderte Syntax der Verweise bewirkt
wird.
-
In „Ever Thought
of Compressed HTML Files?",
Armin Kielack, www.kielack.de/chtml.htm, Funddatum 03.05.2001 wird
vorgeschlagen, anstelle von nicht-komprimierten Dateien komprimierte
HTML-Dateien zu übertragen.
Dabei wird jede HTML-Datei einzeln in ein separates ZIP-Archiv verpackt.
-
Aus „Java Tip
21: Use archive files to speed up applet loading", John D. Mitchell, www.javaworld.com/javaworld/javatips/jw-javatip21.html,
Funddatum 31.10.2001 ist bekannt, die HTML-Tags "<APPLET>" bzw. "<OBJECT>" zur Angabe eines Archivs für von einem
JAVA-Applet benötigte
Klassen zu verwenden, die dann vorab geladen werden können. Diese
Funktionalität
ist jedoch einerseits auf JAVA beschränkt und erfolgt zudem unter
Kontrolle des Browsers, nicht des Servers. Der Server liefert weiterhin
die angeforderten Dateien.
-
In „System-Architektur
und -Software",
Prof. Dr. L. Richter, Vorlesung Universität Zürich, Sommersemester 2000 wird
ein Cache-Verfahren in Prozessoren beschrieben. Bei einem Seitenfehler
wird die fehlende Seite angefordert und vom Hauptspeicher geliefert.
-
Die
vorliegende Erfindung stellt sich die Aufgabe, eine Lösung anzugeben,
mit der alle von einer Seite benötigten
Objekte mit einem Netzwerktransfer übertragen werden können und
die dennoch kompatibel mit der bisherigen Verwendung ist. Insbesondere
soll die HTML-Seite unverändert
bleiben; lediglich werden Server und Browser so ergänzt, daß ein verbesserter
Server mit einem verbesserten Browser eine Effizienzsteigerung bewirkt,
aber die restlichen drei Kombinationen unverändert funktionsfähig bleiben.
-
Die
Lösung
verwendet die Möglichkeit,
daß der
Browser bei der Anforderung der HTML-Seite einen Indikator setzt,
der von bisherigen Servern ignoriert wird und von neuen Servern
dazu verwendet wird, anstelle der HTML-Seite ein Archiv zu senden,
das die HTML-Seite enthält.
Dieses Archiv wird, im Gegensatz zu einem JAR-Archiv, nicht als
ganzes in den Pufferspeicher eingestellt, sondern entpackt und elementweise
in den Pufferspeicher (cache) geladen. Der Inhalt des Archivs kann
beliebige, per URL adressierbare Elemente enthalten, die dann durch
den Pufferspeicher-Mechanismus automatisch benutzt werden. Es ist
also, auch im Gegensatz zu dem genannten Stand der Technik, nicht
notwendig, daß alle
in der Seite enthaltenden Elemente in dem Archiv enthalten sind.
Insbesondere wird es häufig
sinnvoll sein, ein JAR-Archiv gerade nicht zu integrieren und dieses
getrennt zu laden. Auch können
Elemente enthalten sein, die erst mittelbar referiert werden, wenn
z.B. in der Seite auf eine andere Seite verwiesen wird, die wiederum
Graphiken enthält
und diese bereits bei der ersten Seite mit übertragen werden.
-
Zusammengefaßt stellt
sich die Erfindung wie folgt dar: Bei der Anforderung einer HTML-Seite
wird von dem Browser ein Indikator gesetzt, auf Grund dessen der
Server anstelle der HTML-Seite ein Archiv zurücksendet, das von dem Browser
in den Cache entpackt wird. Das Archiv enthält beispielsweise die von der Seite
benötigten
Bilder, die dann von dem Cache abgerufen werden, so daß pro Seite
nur ein Netzwerk-Transfer notwendig ist. Die Erfindung ist kompatibel
zum bisherigen Betrieb, insbesondere durch Verwendung der 'content negotiation' nach RFC 2295 oder 'remote variant selection' nach RFC 2296.
-
Die
Erfindung wird nachfolgend an Hand eines Ausführungsbeispiels und einiger
Varianten genauer beschrieben.
-
In 1 ist
eine Anordnung skizziert, an Hand derer der Ablauf beschrieben werden
soll.
-
Durch
die Wellenlinie 10 ist ein Netzwerk angedeutet, mit dem
ein Client unterhalb der Wellenlinie 10 und ein Server
oberhalb der Wellenlinie 10 verbunden sind. Das Netzwerk
und die Verbindungen werden bevorzugt mit dem Internet-Protokoll
HTTP realisiert.
-
In
dem Client befinde sich ein HTML-Dokument
12, das einen
Verweis (link), hier '<a href="test1.html"> link </a>', enthält. Durch Aktivierung des Verweises
wird eine Anfrage an den HTTP-Prozeß
14 gerichtet. Der HTTP-Prozeß umfaßt einen
Schalter
16, mit dem entschieden wird, ob das angeforderte
Dokument "test1.html" wie bisher von dem
Massenspeicher
18 entnommen und zum Client zurückgeschickt
wird, oder die noch zu beschreibende Erweiterung angewendet wird.
Das Anzeigeprogramm ('browser') im Client, das
die Seite angefordert hat, umfaßt
eine Steuerung
22 für
einen Pufferspeicher
24.
-
Das
angeforderte Dokument "test1.html" lautet beispielsweise
wie folgt:
-
In
dem Fall, das vom Server-Prozeß
14 nur
wie bisher das angeforderte Dokument zurückgesendet wird, wird dieses
wie gehabt von der Steuerung
22 in den Pufferspeicher
24 eingetragen
und steht dann dem Anzeigeprogramm als Dokument
26 zur
Verfügung.
In dem Dokument
26 sind mehrere Verweise enthalten, und
zwar die Verweise '<img src=img1.jpg>', <a
href=test2.html>" und <script src=script1.js>". Nunmehr interpretiert das Anzeigeprogramm
das Dokument "test1.html" und trifft auf eben
diese Verweise, woraufhin die darin angegebenen Dateien "img1.jpg", "test2.html" und "script1.js" nacheinander vom
Server angefordert, in den Cache
24 abgelegt und sodann
in den HTML-Text
26 funktional eingefügt werden.
-
Die
Erfindung verändert
den Ablauf wie folgt: Durch einen Indikator in der Anforderung von "test1.html" wird dem Server-Prozeß 14 mitgeteilt,
daß anstelle
der angeforderten Datei auch ein Archiv verarbeitet werden kann.
Dieser Indikator wird weiter unten noch genauer dargestellt. Ist
dieser Indikator gesetzt, so prüft
der Server-Prozeß 14,
ob es ein entsprechendes Archiv 20, hier mit dem Namen 'test1.harc', gibt und sendet
dann, durch den Schalter 16 symbolisiert, eben dieses Archiv 20 zurück. Durch
einen entsprechenden Eintrag in den Kopfzeilen ('header') gemäß dem Protokoll HTTP, beispielsweise
dem (neuen) MIME-Typ 'archive/harc' anstelle von 'text/html', wird dem Pufferspeicherprozeß 22 angezeigt,
daß anstelle
eines einzigen Dokuments ein Archiv übermittelt wird. Daraufhin
zerlegt der Pufferspeicherprozeß 22 das
Archiv in seine Elemente und speichert diese Elemente einzeln im
Pufferspeicher 24, wie in 1 angedeutet.
Sei wie im Beispiel die Datei 'test1.html' in dem Archiv enthalten.
Da diese nunmehr im Pufferspeicher ist, kann sie wie bisher dem
Anzeigeprogramm zur Verfügung
gestellt werden. Dieses interpretiert den HTML-Text und stellt fest,
daß noch
weitere Dateien benötigt
werden. Hierzu wird, wie immer, zunächst geprüft, ob sich diese im Pufferspeicher
befinden. Da das der Fall ist, werden diese weiteren Dateien 'img1.jpg', 'test2.html' und 'script1.js' dem Pufferspeicher
entnommen; eine Kommunikation zu dem Server ist nicht mehr notwendig.
-
Für den Indikator,
mit dem der Client dem Server mitteilt, daß ein Archiv willkommen ist,
kann entweder ein neues Element in den HTTP-Kopfzeile definiert
werden. Bevorzugt wird jedoch die Inhalts-Auswahl ('content negotiation') nach RFC 2295 oder
die 'remote variant
selection' nach
RFC 2296 verwendet. Letztere wird überwiegend verwendet, um verschiedene Sprachvarianten
einer HTML-Seite anzufordern und ist daher, um diese Fähigkeit
nicht zu verlieren, nicht uneingeschränkt verwendbar. Besser ist
die Inhalts-Auswahl, die bislang dazu verwendet wird, daß der Server
nicht die Original-Datei, sondern eine komprimierte Version sendet. Hierzu
werden die dem Browser bekannten Formate in dem Header der Anfrage
aufgezählt;
der Server kann dann eines dieser Formate senden. Ein Browser mit
einem Pufferspeicher nach der Erfindung benutzt diesen Header und
fügt einen
passenden (MIME-) Typ hinzu. Ein Server, der nicht darauf eingerichtet
ist, ignoriert dieses Format und verhält sich wie bisher. Ein Server
gemäß der Erfindung
sendet auch nur dann das Archiv-Format, wenn der Browser dieses
als möglich
deklariert hat. Dies ist damit eine Möglichkeit, den oben aufgeführten Indikator
zu realisieren.
-
In
einer anderen Variante wird der Browser so eingerichtet, daß er anstelle
der Datei 'test1.html' zunächst die
Datei 'test1.harc' anfordert und, wenn
der Server diese als nicht verfügbar
darstellt, dann die ursprüngliche 'test1.html' anfordert. Der geänderte Dateityp
stellt dann den oben genannten Indikator da.
-
In
einer Weiterbildung der Erfindung wird der ein Archiv zulassende
Indikator nur dann gesetzt, wenn das Dokument noch nicht im Pufferspeicher
ist. In dem Fall, das es sich zwar noch im Pufferspeicher befindet, aber
nicht mehr gültig
ist, wird dann ein Archiv nicht mehr zugelassen, da die anderen
Elemente durchaus noch gültig
sein können.
-
Eine
andere Weiterbildung macht die Anforderung eines Archivs davon abhängig, daß keine
oder nur eine vorgegebenen geringe Anzahl oder nur ältere Dokumente
desselben Servers im Pufferspeicher sind.
-
Seitens
des Servers besteht eine Lösung
darin, daß manuell
oder automatisch geführte
Listen, auch mittels einer Daten bank realisiert, vorhanden sind,
die den Dateinamen der Seiten Archive zuordnen. Wird der Dateiname
in einer der Listen gefunden und existiert das zugeordnete Archiv,
dann wird das Archiv anstelle der Datei übertragen.
-
Auch
kann der Server jedes Mal nach vorhandenen Archiven und in diesen
nach der Seite suchen und im Trefferfalle automatisch das Archiv übermitteln.
-
In
einer anderen Variante wird geprüft,
ob das Unterverzeichnis, in dem die angeforderte Datei gespeichert
ist oder sein sollte, ein Archiv enthält. Ist dies der Fall, so wird
das Archiv statt der Datei übertragen.
Optional kann zuvor geprüft
werden, ob die Datei in dem Archiv enthalten ist. In einer Weiterbildung
wird, wenn kein Archiv vorhanden ist, dieses aus allen Dateien des
Unterverzeichnisses 'on
the fly' gebildet,
abgespeichert und übermittelt.
Hierbei wird bevorzugt eine Positiv- oder Negativliste von Dateiarten,
insbesondere über
deren Erweiterungen, beispielsweise festlegen, daß JAVA-Archive
(.jar) nicht eingeschlossen werden.
-
Bei
einer alternative Anwendung der Erfindung wird der Pufferspeicher
eines als 'proxy' bezeichnenten Vermittlers
verwendet. Ein Proxy-Server erhält
von dem Browser die Anforderung und stellt sie seinerseits an den
Server, erhält
das angeforderte Dokument zurück
und gibt dieses dem Browser weiter. Ein Proxy-Server hat einerseits
eine Schutzfunktion, indem die nach außen gehenden Anfragen über einen
einziges, dedizierte System geleitet werden. Ein Proxy-Server wie 'SQID' oder der entsprechenden
Apache-Modul wird meist mit einem Pufferspeicher kombiniert, um über die
teure Externverbindung angeforderte Seiten möglichst häufig von dem Proxy aus zu übermitteln,
ohne daß die
Externverbindung belastet wird. Deshalb kann der Proxy-Server den
Indikator setzen, ein Archiv erhalten, dieses in den Pufferspeicher
entpacken und dann über
das schnelle und preiswerte interne Netz eine große An zahl
von herkömmlichen
Browsern effizient mit Teilen externer HTML-Seiten versorgen.
-
In
der Regel und damit bevorzugt enthält das von dem Server gesendete
Archiv die angeforderte Datei, die dann aus dem Pufferspeicher heraus
weiterverarbeitet wird.
-
Auch
um robust gegen Fehler zu sein, soll die Steuerung für den Pufferspeicher
auch den Fall handhaben können,
daß das
erhaltene Archiv die angeforderte Datei nicht enthält. Da es
nicht allgemein entscheidbar ist, ob in diesem Fall der Inhalt des
Archivs aus Sicherheitsgründen
verworfen werden soll oder dennoch in den Pufferspeicher eingestellt
werden kann, wird diese Auswahl über
Benutzeroptionen eingestellt und ggf. davon abhängig sein, ob als Protokoll
einfaches HTTP oder gesichertes HTTPS verwendet wurde. Weiterhin kann
entweder die angeforderte Datei sogleich als nicht vorhanden (Fehler
404 im HTTP-Protokoll) behandelt werden. Oder es kann bevorzugt
eine zweite Anforderung erfolgen, bei welcher der Indikator, daß ein Archiv willkommen
ist, nicht gesetzt ist und somit die Seite nochmals einzeln angefordert
wird.
-
Der
Server kann einerseits, nachdem ein Archiv bestimmt ist, das der
angeforderten Datei zugeordnet ist, prüfen, ob die angeforderte Datei
im Archiv vorhanden ist und nur dann das Archiv senden, andernfalls doch
die Datei selbst senden. Diese Lösung
ist einfach, überschaubar
und robust gegen Fehler in der Zuordnung von Dateien und Archiven.
-
Besser
ist es jedoch, wenn zudem geprüft
wird, ob die Datei in dem Archiv nicht nur vorhanden, sondern auch
aktuell ist. Ist sie aktuell und vorhanden, wird das Archiv gesendet.
Ist sie nicht aktuell, wird entweder nur die Seite gesendet oder
zuvor die aktuelle Seite temporär
oder permanent in dem Archiv durch die aktuelle Version ersetzt
und dann das Archiv gesendet.
-
Ist
sie nicht vorhanden, kann dennoch das Archiv gesendet werden in
der Annahme, daß die
Steuerung der Pufferspeicher, wie oben beschrieben, daraufhin die
Seite nochmals, jedoch ohne Archiv-Indikator, anfordert. Dieser
Fall betrifft HTML-Seiten,
die zwar häufiger
geändert
werden, aber bei denen die darin verwendeten Bilder usw. sehr selten
verändert
werden. Bei dieser Ausführung
wird sozusagen vor der Seite immer noch ein Archiv gesendet, das
von der Seite benötigte
Objekte enthält.
-
Bei
einer Fortbildung dieser Variante schickt der Server auf die Anfrage
einer Datei hin zwei Dateien; nämlich
ein Archiv ohne die Datei und sodann oder zuvor die Datei.
-
Der
Indikator, der anzeigt, daß ein
Archiv anstelle der angeforderten Seite geliefert werden kann, ist für die Erfindung
zweckmäßig, aber
nicht zwingend. Sei beispielsweise ein geschlossenes Netzwerk gegeben, wie
es bei Selbstbedienungsterminals häufig der Fall ist. Dann kann
davon ausgegangen werden, daß alle Browser
in der Lage sind, anstelle einer angeforderten Datei ein Archiv
zu erhalten; eine explizite Markierung ist nicht mehr notwendig.
Gleiches gilt für
die vom Server gelieferten Daten: Es wird bevorzugt über den
MIME-Typ im Header angezeigt, daß ein Archiv gesendet wird.
Alternativ kann aber auch jede erhaltenen Datei zunächst als
Archiv interpretiert werden und erst dann, wenn es sich nicht um
ein gültiges
Archiv handelt, als einfache Datei behandelt werden.
-
Als
Archivformat kann einerseits eines der unter als 'arc', 'zip', 'tar', 'cpio', 'cab', 'lha' usw. bekannten Formate
verwendet werden, bei denen die Dateien zu einer neuen, das Archiv
darstellenden Datei verpackt werden. Häufig wird dabei noch eine Kompression
verwendet und so die Übertragung
weiter beschleunigt, sofern die verpackten Dateien nicht bereits
ohnehin komprimiert sind, wie es bei den gängigen Bildformaten 'gif', 'jpg' und 'png' der Fall ist.
-
Eine
andere Möglichkeit
beim HTTP(S)-Protokoll besteht darin, die zurückgesendeten Daten als mehrteilige
Nachricht mit Trennzeichen gemäß dem MIME-Standard
RFC- 2046 ('multi-part
message') zu codieren. Hierbei
wird eine Anzahl von einzelnen Dateien durch Trenner zu einem Gesamtstrom
verbunden. Der Datentyp im Header ist dann 'multipart/mixed'. Diese Variante hat den Vorteil, daß die dynamische
Zusammenstellung im Server besonders einfach ist. Bevorzugt wird
als erster Teil die angeforderte Datei selbst gesendet. Daran anschließend wird
entweder eine vorbereitete Datei angefügt, die bereits eine 'multipart-message' darstellt und die
dann ohne weiteres angefügt
werden kann (ggf. unter Anpassung der Grenztrenner ('boundary delimiter'). Oder es werden
gemäß eines
Datenbankeintrags bzw. einer sonstigen Liste die dort enthaltenen Dateien
einzeln angefügt.
Diese Variante ist funktional gleichwertig zu einem traditionellen
Archiv und wird daher im Rahmen der Erfindung als Archiv-Format
angesehen.
-
Die
Erfindung wurde an Hand von HTML-Seiten beschrieben. Sie ist auf
weitere Markup-Seiten wie den Nachfolger XHTML, die Erweiterung
XML, sowie andere adäquate
Formate gleichermaßem
anwendbar.
