Universität Koblenz-Landau
Platzhalter
 
[Hauptdokument]
[Inhalt]
[Glossar]
[Links]
[Literatur]
 
Baustelle
Platzhalter Rund ums Web: Version 1.0 vom 12. Juli 2000, Autor: Andreas Pidde
 
Bottom

Das Web unter der Lupe

Top Bottom

Einleitung

Der folgende Text ist für diejenigen Surfer gedacht, die ein wenig hinter die Kulissen des World Wide Web (WWW, Web) schauen möchten.

Das Laden von Web-Dokumenten ist durch die Benutzung eines Web-Browsers denkbar einfach: Ein Klick auf eine Verknüpfung (Link) in einem schon geladenen Dokument, die Auswahl eines Lesezeichens (Bookmark) oder die direkte Eingabe einer Adresse, des Uniform Resource Locators (URL), und schon wird das entsprechende Dokument präsentiert - vom einfachen Text bis zur aufwendigen Multimedia-Präsentation.

Aber wie findet "mein Computer" dieses Dokument und wie wird der Inhalt verschickt? Anhand der Klärung dieser Frage entfaltet sich schon ein großer Teil des Computer-Netzwerks, auf dem das Web verteilt ist. Dieses Netzwerk wird "weltweites Internet" oder kurz "das Internet" genannt - wohlgemerkt, das Web ist nicht das Internet. Das Internet ist das Rechnernetzwerk, auf dem das Web verteilt ist. Im Folgenden soll nun geklärt werden, was von der Eingabe des URLs bis zur Darstellung des fertigen Web-Dokuments im Einzelnen geschieht und welche Infrastruktur dafür notwendig ist.

Top Bottom

Die Infrastruktur

Im Internet sind die unterschiedlichsten Rechner auf verschiedene Weise miteinander vernetzt. Neben allgemeinen Systemen wie Unix, das "eigentliche" Betriebssystem des Internets, ist auch Microsofts Windows NT/2000 gebräuchlich. Daneben gibt es Betriebsysteme, deren Hauptaufgabe es ist, nur Web-Dokumente zu liefern. Diese speziellen Betriebssysteme kommen z.B. in Web-Kameras zum Einsatz. Wichtig ist nur, dass alle Systeme im Netzwerk untereinander die "gleiche Sprache sprechen" oder einen entsprechenden Übersetzer (Gateway) zwischengeschaltet haben. Diese gemeinsame Sprache wird auch Protokoll genannt. Im Fall des Internets ist es das Transmission Control Protocol/Internet Protocol (TCP/IP). Das TCP/IP wiederum besitzt Unterprotokolle oder Dienste (Services). Das für das Web wichtige Hypertext Transfer Protocol (HTTP) ist nur ein Unterprotokoll von vielen aus der TCP/IP Protokoll-Suite. Das HTTP ist die Sprache, mit der sich Web-Client (Programm, das im Web Dienste anfordert, z.B. der Web-Browser) und Web-Server (Programm zur Bereitstellung der Dienste im Web) verständigen. Neben HTTP gibt es noch das HTTPS (die zugehörenden URLs beginnen entsprechend mit https:), das sichere HTTP - S steht hierbei für Secure. Dieses Protokoll ist gleichwertig zum HTTP, allerdings werden die Inhalte nach einem feststehenden Verfahren verschlüsselt, so dass von Dritten abgefangene Daten nicht ohne immensen Aufwand entschlüsselt werden können.

Als Organisation ist das World Wide Web Consortium (W3C) zu nennen. Das Konsortium kümmert sich um die Standardisierung des Web - z.B. durch den Hypertext Markup Language (HTML) Sprachstandard für die im Web gebräuchlichen Hypertext-Dokumente und das HTTP.

Top Bottom

Der Datenweg

Zurück zur Frage: Was passiert nun beim Laden eines Web-Dokuments? Alles beginnt mit der Eingabe eines URLs. Als Beispiel nehmen Sie einmal die Adresse: http://www.uni-koblenz-landau.de/, das Portal zu unserer Universität, an. Um das dazu gehörende Dokument zu finden, wird nach der Feststellung des Protokolls zunächst versucht, zu dem Interfacenamen www.uni-koblenz-landau.de die zugehörende Internet-Adresse zu finden. Dazu wird der URL vom Browser in ihre Bestandteile zerlegt. Dieser Vorgang wird auch Parsen genannt. Ist der Interfacename aus der URL herausgelesen, wird eine Anfrage an einen Namensserver (Domain Name System, DNS) gesendet. Die Internet-Adresse unter der dieser Namensserver erreicht werden kann, ist immer bekannt. Sie wird entweder bei der Netzwerkeinrichtung von Hand eingegeben oder bei der Einwahl oder über das Dynamic Host Configuration Protocol (DHCP) mit weiteren Netzwerkdaten automatisch zugewiesen. Der Namensserver sucht in eigenen Tabellen oder einem weiteren, übergeordneten Namensserver nach der numerischen Adresse zu dem gesuchten Namen. Die gefundene Adresse, zum Zeitpunkt der Erstellung dieser Seite war sie 141.26.200.8, bezeichnet einen Anschluss an einem Netzwerkadapter oder eine virtuelle Adresse des Zielrechners. Nur mit dieser Adresse kann der Zielrechner im Internet gefunden werden. Es ist übrigens nicht ungewöhnlich, dass ein Zielrechner mehrere Namen und Adressen hat. Die Zuordnung zwischen Name und Adresse kann zwar geändert werden, dadurch, dass die Adresse aber in mehreren DNS-Tabellen steht, kann es eine Zeit dauern, bis der Name unter der neuen Adresse bekannt ist. Der Web-Server muss natürlich nicht unbedingt www heißen.

Nach Erhalt dieser Adresse schaut der Browser zunächst in seinem lokalen Zwischenspeicher (Cache) nach, ob die gesuchte Datei dort schon vorhanden ist. Falls ja, wird als nächstes ihre Aktualität geprüft. Dazu wird eine entsprechende Anfrage an den Web-Server gesendet. Der Web-Server ist ein Prozess auf dem Zielrechner, der die Web-Dokumente bereitstellt. Die Aktualitätsprüfung kann so konfiguriert werden, dass sie nicht unbedingt jedes Mal stattfinden muss. Soll die Aktualitätsprüfung nicht stattfinden und ist die Seite im Cache vorhanden, könnte, wie im Offline-Betrieb, prinzipiell auch ohne die Feststellung der Adresse des Zielrechners die Seite direkt aus dem Cache schnell geladen werden. Die Seite ist dann aber nicht unbedingt aktuell.

Die aktuellen Inhalte, d.h. die Dateien (engl. files) oder allgemeiner Ressourcen, deren im Cache vermerktes Datum nicht älter ist als das der aktuell im Web vorhandenen, werden direkt von der lokalen Platte geladen und angezeigt. Es braucht also nicht mehr im Web danach gesucht werden. Manche Browser halten einige (möglichst häufig angeforderte) Ressourcen auch im Hauptspeicher, diese können dann noch schneller angezeigt werden. Ist eine Datei nicht im Cache, oder nicht mehr aktuell, gibt es zwei (für den Nutzer transparente) Möglichkeiten, wie es weiter geht.

  • Ist ein Proxy-Server eingetragen, wird die Suche nach der Datei an den Proxy übertragen. Dieser besitzt einen eigenen, möglichst großen Cache. Ist die aktuelle Datei in diesem Cache vorhanden, wird sie sofort zurückgeliefert, ohne dass sie über das Web geladen werden muss.
  • Ist sie nicht vorhanden, oder wird kein Proxy benutzt, muss die Datei vom Zielrechner geladen werden. Es wird dazu eine Anfrage an den Web-Server des Zielrechners gesendet.

Der Web-Server bekommt also nur die Anfrage zum Versenden der Daten, falls lokal keine aktuellen verfügbar sind. Im Beispiel ist das nur letzte Zeichen "/" des URLs. Der Zielrechner weiß, dass mit der Anfrage der Web-Server angesprochen werden soll, weil mit der Anfrage eine Nummer, die Portnummer, der ein Web-Server zugeordnet ist, mitgeliefert wird. Normalerweise ist das die Nummer 80. Diese kann sogar explizit in dem URL angegeben werden (http://www.uni-koblenz-landau.de:80/). Durch die Verwendung weiterer Ports können auf dem Zielrechner Web-Server mit unterschiedlichen Eigenschaften gleichzeitig laufen, ohne das virtuelle Adressen vergeben werden müssen.

Da in dem URL kein vollständiger Ressourcen-Bezeichner vorkommt (nur ein Verzeichnis), wird vom Server zunächst der Name der Startseite ergänzt. In diesem Fall index.html. Der URL http://www.uni-koblenz-landau.de/index.html bezeichnet also das gleiche Dokument wie http://www.uni-koblenz-landau.de/ oder http://141.26.200.8/. Der Name der Startseite muss allerdings nicht immer index.html sein. Oft kommen auch die Namen default.asp, default.htm oder index.htm vor. Der Name kann am Webserver konfiguriert werden.

Die Datei, die der Web-Server zurückschickt, kommt in den seltensten Fällen direkt vom lokalen Dateisystem des Web-Servers. Normalerweise werden die Dateien von Datei-Servern angefordert, die sich irgendwo anders im Netz befinden. Unter Umständen liefert der Webserver die Ressource nicht direkt sondern lenkt über einen URL auf einen anderen Webserver um, der dann die Ressource bereitstellt. Z.B. wird der URL http://www.uni-koblenz.de/ vom Server www.uni-koblenz.de auf den URL http://www.uni-koblenz-landau.de/ umgeleitet.

Die angeforderte Ressource wird schließlich (hoffentlich) zurückgesendet. Sie wird in Pakete aufgeteilt, die dann einzeln verschickt werden (Paketvermittlung). Die Routen im Netz, auf denen diese Datenpakete verschickt werden, laufen selten über eine direkte Verbindung. Normalerweise liegen viele Knotenpunkte zwischen Client und Server. Die Route, welche die Datenpakete nehmen, muss auch nicht immer die gleiche sein. Jeder Knotenpunkt ist ein so genannter Router, der dynamisch die als nächst schnellere vermutete Verbindung zum Empfänger des Datenpakets feststellt und das Paket dorthin weiterleitet.

Wird die Ressource nicht von dem Server gefunden, liefert er eine Fehlermeldung, die dann im Browser aufbereitet dargestellt wird, oder der Server liefert eine spezielle Seite, die auf die nicht gefundene Ressource hinweist. Andere Fehler können auftreten, wenn die Seite ganz oder teilweise auf ihrem Weg zum Client verloren geht (die Ressource kann dann erneut angefordert werden) oder der Webserver nicht gefunden wird, bzw. nicht antwortet.

Im lokalen Netzwerk (LAN), bzw. bei einer weiteren Strukturierung im Subnetz eines Rechners, ist die Zuordnung der Internet-Adresse zu der eigentlichen Hardwareadresse (MAC-Adresse Medium Access Control oder NIC-Adresse, in diesem Fall steht NIC für Network Interface Card) eines Anschlusses eines Netzwerkadapters bekannt. Das Gateway am Eingang des Subnetzes kann so die Anfrage an einen bestimmten Adapter im lokalen Netzwerk des Zielrechners leiten. Die physikalische Adresse ist zum Routen nicht geeignet und hat deshalb nur in einem Subnetz, bzw. LAN Bedeutung.

Der Browser fängt sobald wie möglich mit der Darstellung der Seite an. Wenn eine HTML-Seite entsprechend geschrieben ist (u.a. wenn alle Bilder mit ihrer Größe versehen sind), kann z.B. der Text angezeigt werden, bevor alle Bilder angefordert und geladen sind. Zusätzlich werden die Caches im eigenen Rechner und im Proxy automatisch mit den aktuelleren Daten gefüllt, damit sie bei einer erneuten Anfrage schneller vorhanden sind. Nach dem Erhalt der Antwort besteht zwischen Client und Server keine Verbindung mehr. Es können also keine weiteren Daten ausgetauscht werden, ohne dass eine erneute HTTP-Anfrage vom Client an den Server gesendet wird. Oder andersherum erfordert nur ein Bild in einem HTML-Text eine komplett neue HTTP Ressource-Anforderung. Seiten mit vielen kleinen Bildchen sind deshalb vergleichsweise langsam im Aufbau.

Top Bottom

Server-seitige Aktivitäten

Der Zugriffspfad steht übrigens nicht immer für eine Datei. Der Server kann mit der Anfrage prinzipiell machen, was er (bzw. der Web-Administrator) will. Die Daten können aktive Elemente enthalten, die erst beim Ausführen durch den Server weitere Daten liefern. Der Client (der Sender der HTTP-Anfrage, z.B. ein HTML-Browser) merkt nicht, dass die Daten dynamisch generiert wurden.

Vom Server dynamisch generierte Daten gelten nie als aktuell und müssen jedes Mal neu geladen werden. Der Zugriffspfad bezeichnet in diesem Fall nicht direkt eine Datei sondern vielmehr ein kleines Programm (oft als server-seitiges Skript, in einer interpretierten Sprache wie Perl oder einer Shell-Sprache geschrieben) auf dem Server, das, wenn es vom Server ausgeführt wird, einen bestimmten Inhalt liefert. Beispiele für solche dynamischen Daten sind die allseits beliebten Web-Counter, die als CGI-Skript (CGI steht für Common Gateway Interface) implementiert sind und die Anzahl der Zugriffe auf eine Web-Seite als GIF-Bildchen liefert. Ernsthaftere Anwendungen sind Datenbankanfragen an Suchmaschinen und Online-Shops. Den Anwendungen können zusätzliche Informationen in Parametern übergeben werden. Diese Parameter werden von dem übrigen URL durch ein vorangestelltes Fragezeichen "?" abgegrenzt. Es wird so erst möglich, beliebige Anfragen an Suchmaschinen zu stellen.

Neben dem Ausführen von relativ kleinen CGI-Skripten, gibt es noch größere server-seitigen Anwendungen, die in einer beliebigen Programmiersprache (oft in C oder Java) geschrieben sein können. Es besteht auch die Möglichkeit Programmelemente direkt in den HTML-Code einzubetten, verbreitet ist PHP (steht für PHP Hypertext Preprocessor). Diese "HTML"-Seiten werden, bevor Sie an den Client geschickt werden, zuerst durch einen Zusatzprogramm des Web-Servers interpretiert und durch dynamisch erzeugte Elemente angereichert.

Modernere Entwicklungen, so genannte Content-Management-Systeme, speichern den Inhalt von Web-Sites in Datenbanken. Die Dokumente werden bei einer HTTP-Anfrage aus der Datenbank extrahiert und dynamisch zusammengestellt. Intelligente Cache-Algorithmen speichern die fertigen Dokumente, damit nicht jede HTTP-Anfrage zu Datenbankzugriffen führt. Content-Management-Systeme unterstützen bei richtiger Anwendung die Trennung von Inhalt und Darstellungsformen der Dokumente.

Für den Client (z.B. einen HTML-Browser) ist die Ausführung dieser server-seitigen Programme transparent - er braucht sich also nicht weiter darum zu kümmern. Der Server kann die aktuellen Daten aber nur liefern, wenn die Anfrage auch wirklich zum Server gelangt. Der eigene Browser (und natürlich auch der Proxy des Providers) muss dazu so eingestellt sein, dass der Server nicht ohne Aktualitäts-Prüfung durch einen Zugriff auf den Cache umgangen wird.

Top Bottom

Aktivitäten des Clients

Außer diesen server-seitigen Skripten gibt es noch die client-seitigen Skripte. Diese sind im HTML-Text eingebettet und werden erst auf dem Client ausgeführt. Sie können dazu dienen, direkt auf Eingaben zu reagieren, ohne dass eine erneute HTTP-Anfrage gesendet werden muss. Zur Formulierung dieser Skripte kann z.B. JavaScript verwendet werden. Komplexere Interaktionen auf dem Client, wie z.B. Brettspiele, können mit Java-Applets implementiert werden. Java ist eine Programmiersprache, mit der es möglich ist, Programme zu entwickeln, die in einem HTML-Browser ablaufen können (Applets). JavaScript hat mit Java im Grunde nur das Wörtchen "Java" gemein.

Top Bottom

Zusammenfassung

Im folgenden Abschnitt finden sie die Schritte, die zum Abfragen eines Web-Dokuments erforderlich sind, noch einmal in der zeitlichen Abfolge zusammengefasst. Jeder Punkt erfordert natürlich eine bestimmte Zeitspanne zur Ausführung. Auch erfordert der Datenweg meist mehrere Umleitungen, so dass das Laden eines Web-Dokuments nicht immer schnell vonstatten geht.

  1. Eingabe eines URLs, z.B. http://www.uni-koblenz-landau.de/.
  2. Der Web-Browser (Client) zerlegt den URL in seine Bestandteile (parsen): Den Dienstnamen "http:", den Interfacenamen des Zielrechners: "www.uni-koblenz-landau.de" und den Pfad des Dokuments: "/".
  3. Der Web-Client startet eine Anfrage an den Namenserver um die Internet-Adresse des Web-Servers herauszubekommen.
  4. Die Anfrage wird durchs Internet an den Namensserver geleitet.
  5. Der Namensserver sucht in den eigenen Tabellen die zugeordnete Internet-Adresse oder startet, wenn er sie dort nicht findet, eine erneute Anfrage an einen übergeordneten Namensserver.
  6. Die Internet-Adresse wird zurückgeliefert.
  7. Der Browser wird nun die Aktualität des Dokuments feststellen. Eine entsprechende Anfrage wird an den Web-Server auf dem Zielrechner geschickt.
  8. Die Anfrage wird über das Internet zum Web-Server geleitet.
  9. Der Web-Server lenkt die Anfrage eventuell an einen weiteren Web-Server um (usw.).
  10. Der endgültige Web-Server liefert in seiner Antwort das Datum, an dem das Dokument zum letzten Mal geändert wurde.
  11. Ist das Dokument nicht mehr aktuell im Cache, wird eine Anfrage zum Laden des Dokuments an den Web-Server generiert.
  12. Der Web-Server lädt die Ressource und schickt sie über das Internet an den Client.
  13. Der Web-Client stellt das Dokument dar.
  14. Werden zum Darstellen weitere Dokumente (z.B. Bilder) benötigt, wird eine erneute, komplette Anfrage an einen Web-Server gestellt. Die Verbindung zwischen Client und Server wird nach vollständigem Erhalt der Antwort abgebrochen.

Alternativ kann zwischen Web-Client und Web-Server ein Proxy-Server des Internet Service Providers (ISP) geschaltet sein, der wie ein Web-Server Anfragen beantworten kann. Die Seiten können dann aus dem, normalerweise mehrere Gigabyte großen Cache des Proxys kommen. Das langwierige Laden über das Internet von aktuell gecachten Dokumenten kann so umgangen werden. Auch können durch das Zwischenschalten eines Proxys bestimmte Web-Server vom Zugang gesperrt werden.

Top Bottom

Vernetzungsplan

In der Grafik sehen Sie die beschriebenen Netzwerkkomponenten. Durch einen Klick auf einen Bestandteil erhalten Sie eine nähere Erklärung zu dieser Komponente.

Vernetzung Client über Einwahl verbunden Modem Einwahlknoten Ein lokales Netzwerk Client im lokalen Netzwerk Rechner mit DNS Rechner mit Proxy-Server Gateway ins Internet Das weltweite Internet Gateway ins Internet Ein Lokales Netzwerk Rechner mit Web-Server Datei-Server
Abb.: Vernetzungsplan

Es braucht in der Praxis nicht für jeden Dienst (DNS, Proxy, Web-Server, ...) ein eigener Rechner vorhanden sein. Es können auch mehrere Dienste auf einem Rechner laufen - oder ein Dienst verteilt auf mehreren Rechnern. Es ist durchaus möglich, dass vom Client bis zum Server alles auf einem Rechner stattfindet - z.B. unter dem Betriebssystem Linux mit dem Web-Server von Apache und einem HTML-Browser. Beim Erstellen von eigenen Web-Sites brauchen in diesem Fall keine Daten über das Internet geschickt werden und server-seitige Skripte können direkt am lokalen Rechner getestet werden ohne den Server eines ISP durch fehl laufende Skripte in Gefahr zu bringen.

Top Bottom

Verknüpfungsliste

Einleitung

Die Infrastruktur

Der Datenweg

Server-seitige Aktivitäten

Aktivitäten des Clients

Zusammenfassung

Zusammenfassung - Vernetzungsplan

Top Bottom

Weiterführende Links

Top
 

© 2000 Andreas Pidde, pidde@uni-koblenz.de
[Zu meiner Homepage]
Erstellt mit:
Ulli Meybohm's HTML Editor
Baustelle
 
[Hauptdokument]
[Inhalt]
[Glossar]
[Links]
[Literatur]
 
Platzhalter
Valid HTML 4.0!