DE10219390A1 - Verfahren zum Nutzen von Funktionen und Hardwareressourcen einer Kommunikationseinrichtung durch mehrere Betreiber - Google Patents

Abstract

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.

Description

• Die Erfindung betrifft die beschleunigte Ü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 Grafiken 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.
• 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 Fig. 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:
  <HTML><HEAD><TITLE>TEST1</TITLE></HEAD> <BODY><H1>TEST1</H1>
  Image: <IMG SRC=img1.jpg ALT="img1">
  Link: <A HREF=test2.html> test2 </a>
  Script: <srcipt src=script1.js></script>
  JAVA-Applet: <APPLET src=an_applet.java> </applet> </BODY></HTML>
• 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 Anzeigeprogralnm 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 Fig. 1 angedeutet. Bei 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 Datenbank 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 Anzahl 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. Bei 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 ("multipart 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.

Claims (9)

1. Server für mehrere, durch Adressen bestimmte Dateien, insbesondere Markup-Seiten, mit den Merkmalen:

- der Server bestimmt unter Verwendung der in einer Anforderung einer Datei enthaltenen Adresse, ob

a) die Datei selbst oder

b) anstelle der Datei ein Archiv, das mehrere Dateien umfaßt,

zurückgesendet wird.

2. Server nach Anspruch 1, wobei die Anforderung einen Archiv-Indikator umfaßt und nur bei Anwesenheit Indikators anstelle der Datei ein Archiv zurückgesendet wird.

3. Server nach Anspruch 2, wobei der Indikator mittels einer Inhalts-Auswahl implementiert wird.

4. Server nach einem der Ansprüche 1 bis 3, wobei eine Assoziativliste verwendet wird und,

- wenn hierdurch der Adresse der angeforderten Datei eine andere Datei zugeordnet ist, diese Datei gesendet wird, und

- wenn der angeforderten Datei mehrere Dateien zugeordnet sind, diese Dateien als ein Archiv gesendet werden.

5. Server nach einem der Ansprüche 1 bis 3, wobei die angeforderte Datei in vorhandenen Archiven sucht und, wenn die angeforderte Datei vorhanden ist, ein solches Archiv anstelle der Datei zurücksendet.

6. Server nach einem der Ansprüche 1 bis 3, wobei die angeforderte Datei in einem Verzeichnis lokalisiert und anstelle der Datei ein Archiv aus allen Dateien des Verzeichnisses, gebildet gemäß vorbestimmter Auswahlkriterien, zurückgesendet wird.

7. Server nach einem der vorigen Ansprüche, wobei das Archiv als mehrteilige Nachricht mit Trennzeilen gestaltet ist.

8. Pufferspeicher mit Einträgen für adressierte Dateien, insbesondere Markup-Seiten, wobei der Pufferspeicher ein Assoziativspeicher ist, der einen Index mit der Adresse der gepufferten Dateien und einen Speicher mit deren Inhalten hat, mit den Merkmalen:

- ist eine angeforderte Datei nicht im Pufferspeicher vorhanden oder ungültig, wird sie mit ihrer Adresse von einem durch die Adresse bestimmten Server angefordert,

- falls von dem Server anstelle der adressierten Datei ein Archiv gesendet wird, in das mehrere Dateien gepackt sind, wird das Archiv entpackt, und es werden die mehreren Dateien einzeln in dem Pufferspeicher abgelegt, so daß nachfolgende Anforderungen dieser Dateien aus dem Pufferspeicher befriedigt werden können.

9. Browser für Markup-Seiten, umfassend einen Pufferspeicher nach Anspruch 8.