Netzwerkanwendungen, Teil 1: HTTP und E-Mail

World Wide Web WWW

Die derzeit wohl am meisten genutzte Anwendung über Rechnernetze ist das World Wide Web WWW. An diesem Beispiel lassen sich gut einige grundlegende Konzepte darstellen.

Auf Seite des Benutzers steht ein Anwendungsprogramm (User Interface), das Informationen in textueller und grafischer Form darstellt und Eingaben des Benutzers annimmt. Dieses Anwendungsprogramm ist der Webclient oder Webbrowser wie etwa Opera, Firefox oder der Internet Explorer. Auf der anderen Seite steht ein Webserver, der in der Regel über ein Netzwerk zu erreichen ist. Der Webserver reagiert auf Anfragen des Clients und schickt die angeforderten Informationen sowie Bestätigungsmeldungen.

Die Kommunikation zwischen Server und Client erfolgt mittels TCP. Es stellt einen zuverlässigen, bidirektionalen Byte-Strom bereit. Die Kommunikation erfolgt aber in Form von Anfragen und Antworten. Daher wird ein Protokoll benötigt, das über den TCP-Byte-Strom einen geeigneten Anfragen- und Antwortmechanismus realisiert. Dieses Protokoll nennt sich HTTP: HyperText Transport Protocol.

Grenzenlose Interoperabilität

HTTP ist ein einheitliches Anwendungsprotokoll, mit dem Clients von unterschiedlichen Herstellern mit beliebigen Webservern kommunizieren können. Die Clients und Server können dabei auf unterschiedlichen Hard- und Software-Plattformen laufen. Auch die Darstellung der Information durch den Client kann sich nach den jeweiligen Gegebenheiten stark unterscheiden und text- oder grafikbasierend sein. Aber das gemeinsame Anwendungsprotokoll ermöglicht über all diese Grenzen hinweg die Interoperabilität zwischen Server und Client.

HTTP legt in seinem Anwendungsprotokoll fest, welche Anfragen möglich sind und wie die Antworten darauf aussehen. Der Inhalt der ausgetauschten Informationen ist hierbei irrelevant. HTTP ist lediglich für den Transport zuständig. Die Informationsdarstellung ist in dem Begleitprotokoll HTML (HyperText Markup Language) geregelt. In HTML ist der Aufbau der Seite mit Formatierungsinformationen wie etwa Textart, Textgrößen, Farben sowie die Einbindung von Elementen wie Bildern oder Video-Clips beschrieben. Weiterhin kann ein Dokument Verweise (Links) auf andere Dokumente enthalten. Erweiterungen wie Java Applets, Javascript oder Flash können in die Dokumente integriert werden.

Diese Unterteilung in Client-Anwendung, Server-Anwendung, Anwendungsprotokoll und eventuelles Begleitprotokoll findet man bei vielen Anwendungen wieder. In manchen Fällen ist die Trennung weniger deutlich sichtbar, wenn wie bei FTP die Anwendung den gleichen Namen wie das Anwendungsprotokoll trägt.

Das Protokoll HTTP

Das Protokoll HTTP besteht aus Anfrage- und Antwortnachrichten. HTTP tauscht diese Nachrichten in lesbarer Form als ASCII-Texte aus. Es ist daher ohne Weiteres möglich, über eine telnet-Verbindung selbst HTTP-Anfragenachrichten an einen Server zu schicken.

Als Beispiel soll der Ablauf für die elementare Operation zum Lesen einer HTML-Datei dienen. Der Standort der Datei ist als Universal Resource Locator URL spezifiziert. Ein solcher URL ist http://www.fh-friedberg.de/index.html. Der Ablauf ist dann wie folgt:

1. Der Client extrahiert aus dem URL den Knotennamen www.fh-friedberg.de des Servers.

2. Über DNS ermittelt der Client die IP-Adresse.

3. Er baut eine TCP-Verbindung zu Port 80 des Servers auf.

4. Der Client schickt die Abfrage für die Datei index.html.

5. Der Server antwortet und überträgt die Datei.

6. Die TCP-Verbindung wird abgebaut. (Ab der Version 1.1 besteht die Möglichkeit, die TCP-Verbindung aufrechtzuerhalten, um weitere Elemente über die gleiche Verbindung laden zu können.)

7. Der Browser analysiert den HTML-Code der Seite und zeigt den Text an. Gegebenenfalls holt er weitere benötigte Elemente wie etwa Bilder.

Anfragenachricht von HTTP

Die Anfragenachricht für die Datei index.html hat die Form:

GET http://www.fh-friedberg.de/index.html HTTP/1.1

Sie besteht aus drei Teilen:

• dem Befehl GET

• dem URL

• einer Kennung der verwendeten Version des Protokolls.

Im Allgemeinen können auf die erste Zeile der Abfrage noch mehrere weitere Zeilen mit Optionen folgen. Das Ende der Nachricht wird durch eine Leerzeile markiert. Folgende Tabelle enthält wichtige Anfrageoptionen in HTTP. Die Optionen ermöglichen im Wesentlichen das Lesen, Schreiben und Löschen von Dokumenten auf dem Server.

Serverantworten

In der ersten Zeile der Antwortnachricht sendet der Server seine Versionsnummer für HTTP und einen Ergebniscode mit einem erläuternden Text. Daran anschließend können optionale Informationszeilen folgen. Das Format dabei ist Informationsart : Informationstext.

Typische Informationen sind eine Beschreibung des Inhalts oder das Datum der letzten Änderung. Bei der Abfrage GET folgt dann der Inhalt des angeforderten Dokuments. Als Beispiel erhält man mit der oben angegebenen Abfrage die Antwort:

HTTP/1.0 200 OK
Server: WEBULA/1.2.3
Date: Wed, 19 Jun 2004 08:51:23 CEST
Last-Modified: Wed, 05 Jun 2005 11:00:27 CEST
MIME-Version: 1.0
Content-Type: text/html

<DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
...
</HTML>

Die erste Zeile enthält in diesem Beispiel den Code 200 mit der Erläuterung OK als Bestätigung für eine erfolgreiche Transaktion. Eine Übersicht über die Statuscodes in HTTP gibt folgende Tabelle. Die nächsten Zeilen enthalten Informationen über den Server, Datumsangaben sowie die Spezifikation des Inhalts. Getrennt durch eine Leerzeile folgt dann der HTML-Code der Seite.

Universal Resource Identifier

HTTP spricht Dokumente über eine Adresse in Form eines Universal Resource Locator (URL) an. Der URL ist eine der beiden Unterkategorien des Universal Resource Identifier (URI). Deren zweite Unterkategorie sind die Universal Resource Names (URN), zu denen etwa E-Mail- oder News-Adressen gehören. Der URI ist ein allgemeines Schema, um Ressourcen zu adressieren. Die Spezifikation ist in der RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax" beschrieben.

Die allgemeine Form des URI ist Schema : schemaspezifischer Teil. Der Schemateil beschreibt dabei den Dienst, im obigen Beispiel also http. Daneben sind noch ftp, news, file, telnet oder mailto gängig. Browser erlauben in der Regel auch die Eingabe von anderen Diensten als HTTP und starten dann die entsprechende Anwendung.

Der zweite Teil hat bei HTTP die allgemeine Form //user:password@host:port/pfad. In den meisten Fällen wird aber nur der Pfad benötigt. Weiterhin gelten Vereinbarungen wie etwa die Verwendung von index.html als Default-Wert für den Dateinamen.

Neben dem eigentlichen Namen kann man weitere Optionen an den URI anhängen. Dies ist eine einfache Möglichkeit für den Client, Informationen an den Server zu schicken. Der Server entnimmt dann die Optionen dem erweiterten URI und erzeugt eine Seite mit der angeforderten Information. Als Beispiel ist der folgende URI die Anfrage an eBay nach Artikeln mit dem Schlüsselwort Friedberg (Zeilenwechsel und Leerzeichen sind nur zur besseren Übersicht eingefügt):

http://search.ebay.de/search/search.dll?MfcISAPICommand=GetResult
&ht=1 &shortcut=4 &SortProperty=MetaEndSort &maxRecordsPerPage=50
&st=2 &ebaytag1code=77 &query=friedberg

Der Teil bis zu dem Fragezeichen spezifiziert die Anwendung. Der Rest wird dann beim Aufruf als Argument an diese Anwendung übergeben. Im Beispiel besteht das Argument aus einer Liste mit Eigenschaften und den dazugehörigen Werten. Die Anwendung wird vom Browser aktiviert. Sie liest die Argumente, führt auf dem Server eine entsprechende Aktion aus und gibt das Resultat als HTML-Text an den Browser zurück.

HTTP-Cache

Wenn für jedes Lesen einer Webseite der komplette Inhalt neu über das Netz geladen wird, entsteht sehr viel Datenverkehr. In vielen Fällen ist das neue Lesen aller Elemente aber gar nicht erforderlich, da sich deren Inhalt nicht geändert hat. Daher ist es sinnvoll, die gelesenen Seiten und deren Elemente, etwa darin enthaltene Bilder, in einem temporären Speicher, dem Cache (Englisch: geheimes Lager) abzulegen. Bei einem erneuten Aufruf der Seite kann der Browser die Kopie aus dem Zwischenspeicher verwenden. Dadurch entlastet der Cache nicht nur das Netz, sondern beschleunigt auch den Seitenaufbau.

Die Zwischenspeicherung kann an mehreren Stellen erfolgen. Zunächst kann der Browser Daten lokal auf der Festplatte ablegen. Weiterhin kann in einem lokalen Netz ein Knoten auch einen gemeinsamen Cache anbieten. Dadurch nutzen mehrere Clients die lokale Kopie gemeinsam, was den Datenverkehr weiter verringert.

Knoten mit dieser Funktionalität nennt man Proxy (Englisch: Stellvertreter). Neben dem Caching übernehmen Proxies weitere Aufgaben wie die Regelung von Zugriffsrechten oder die Umsetzung von Protokollen. So kann ein Proxy für einen Client, der nur HTTP unterstützt, eine Umsetzung auf FTP vornehmen, damit dieser einen FTP-Server abfragen kann.

Schließlich kann auch ein Internet Service Provider (ISP) in seinem Netz einen oder mehrere Knoten mit Cache installieren. Dadurch entlastet er seine Leitungen und reduziert gleichzeitig die Kosten für den Datenverkehr in fremde Netze.

Prüfung der Cache-Gültigkeit

Das Design von HTTP unterstützt Caching durch mehrere Elemente. Bevor eine Seite aus dem Cache verwendet wird, muss sichergestellt sein, dass die Seite noch aktuell ist. Dazu weist der Server beim Verschicken jeder Seite in dem Optionsfeld Expires ein Gültigkeitsdatum zu. Bis zu diesem Datum kann der Cache davon ausgehen, dass die Seite auf jeden Fall aktuell ist.

Bei Zugriffen nach dem Gültigkeitsdatum prüft der Proxy über die Abfrageoption HEAD oder eine spezielle Variante von GET, ob sich die Seite geändert hat. In diesem Fall fordert er sie erneut an. Damit der Cache nicht über eine voreingestellte Größe wächst, entfernt der Proxy zudem Seiten aus dem Cache, auf die längere Zeit kein Browser mehr zugegriffen hat.

Ein Seiteneffekt des Caching-Mechanismus betrifft die häufig benutzten Zähler für Zugriffe auf Seiten. Wenn noch eine aktuelle Version in dem Cache eines Proxys liegt, wird der Zugriff eines zweiten Benutzers lokal bedient, ohne dass der Webserver dies bemerkt. Daher kann der Zugriffszähler einen zu niedrigen Wert enthalten.

E-Mail

Elektronische Post - E-Mail - ist eine einfache Anwendung. Die Aufgabe ist es, ein Dokument - etwa einen einfachen Text, ein Bild, ein Video oder eine Kombination mehrerer Elemente - von einem Sender zu einem Empfänger zu schicken. Auch hier findet sich wieder die Unterteilung in Client-Anwendung, Server-Anwendung, Anwendungsprotokoll und Begleitprotokoll. Im Folgenden sollen das Anwendungsprotokoll Simple Mail Transfer Protocol (SMTP) und das Protokoll Multi-Purpose Internet Mail Extension (MIME) zum Format der Nachricht näher betrachtet werden.

Auf Seiten des Clients ist die Situation etwas komplizierter als bei einem Webbrowser. Anders als bei WWW ist E-Mail eine asynchrone Anwendung. Neue Mails können zu beliebigen Zeiten eintreffen. Man benötigt daher einen Mechanismus, um die Anwendung für das Benutzer-Interface (Benutzeragent, E-Mail-Reader) von der Zustellung zu entkoppeln. Dabei gibt es zwei unterschiedliche Strategien.

Falls eine permanente Verbindung zum Mail-Server (etwa einem Rechner in einem lokalen Netz) besteht, kann ein im Hintergrund laufender Prozess als Postamt arbeiten. Dieser Mail-Daemon nimmt Mails an und legt sie im Postfach des Benutzers ab. Gleichzeitig informiert er den Benutzer über die Ankunft einer neuen E-Mail. Der Benutzer kann dann mit seinem Mail-Reader die Nachricht lesen. Erhält der Mail-Daemon umgekehrt ausgehende Nachrichten, schickt er sie sofort an den Mail-Server.

Wenn allerdings nur temporär eine Verbindung zum Mail-Server vorhanden ist, benötigt man ein Protokoll, um gezielt Nachrichten abzuholen und abzugeben. Ein typischer Anwendungsfall dafür ist die manuelle Einwahl vieler Privathaushalte über ein Modem. Hier kommt meist das Mail-Fetching-Protokoll Post Office Protocol Version 3 (POP3) zum Einsatz.

Bei der E-Mail-Anwendung ist die Trennung zwischen Client und Server weniger deutlich als beim WWW. Letztlich stellen beide Seiten die gleiche Funktionalität - Empfangen und Senden von E-Mails - bereit. Insofern ergibt sich die Unterscheidung eher aus der jeweiligen Rolle aus Sicht des Benutzers.

Das Protokoll SMTP

Das Protokoll zum Austausch von E-Mails im Internet ist das Simple Mail Transfer Protocol SMTP. Wie HTTP ist es ein textbasiertes Protokoll auf der Basis von TCP mit Anfragen und Antworten. Ein kleines Beispiel für das Versenden einer Mail sieht wie folgt aus (Eingaben sind zur besseren Lesbarkeit mit >> gekennzeichnet):

>> telnet monet 25
Trying 212.201.24.18...
Connected to monet.
Escape character is '^]'.
220 monet.fh-friedberg.de ESMTP
>> HELO monet.fh-friedberg.de
250 monet.fh-friedberg.de
>> MAIL FROM <stephan.euler@mnd.fh-friedberg.de>
250 ok
>> RCPT TO <stephan.euler@t-online.de>
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
>> RCPT TO <stephan.euler@mnd.fh-friedberg.de>
250 ok
>> DATA
354 go ahead
>> Hallo
>> Hier ist eine kleine Testmail.
>> .
250 ok 1024507580 qp 27898
>> QUIT
221 monet.fh-friedberg.de

Der Server bestätigt zunächst den erfolgreichen Verbindungsaufbau. Anschließend schickt der Client Anfragen mit Optionen. Der Server bestätigt die Anfragen mit einem dreistelligen Code und einem erläuternden Text. In dem Beispiel ist die erste Adresse nicht erlaubt, und die Eingabe führt zu einem Fehler. Nach der Option DATA folgt der Nachrichtentext, der durch eine Zeile mit nur einem Punkt beendet wird.

Nachrichtenformat und MIME

Zu Beginn der Entwicklung konnte man über elektronische Post lediglich einfache Textnachrichten verschicken. Eine Nachricht besteht aus zwei Teilen: einem Kopf (Header) und einem Rumpf (Body). Jede Kopfzeile enthält einen Typ und einen dazugehörenden Wert, getrennt durch einen Doppelpunkt. Kopfzeilen werden mit der Kombination der Zeichen für Zeilenende CR und LF (kurz "CRLF") abgeschlossen. Eine Leerzeile trennt den Kopf vom Rumpf. Beispiele für Kopfzeilen sind:

Return-Path: <Manfred.Merkel@mnd.fh-friedberg.de>
Message-Id: <3C57CD5A.3020609@mnd.fh-friedberg.de>
Date: Wed, 30 Jan 2002 11:39:22 +0100
From: merkel <Manfred.Merkel@mnd.fh-friedberg.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; ...
To: Stephan.Euler@mnd.fh-friedberg.de
Subject: [Fwd: Termin morgen]

Die Kopfzeilen enthalten unter anderem Informationen über Sender und Empfänger, Thema und Versanddatum. Gateways auf dem Weg der Nachricht zum Empfänger fügen weitere Informationen, etwa über die Weiterleitung, hinzu:

Received: from mx0.gmx.net by merkur.hrz.uni-giessen.de for
Stephan.Euler@mnd.fh-friedberg.de; Mon, 4 Mar 2002 11:34:21 +0100

In der Regel steht die eigentliche Nachricht im Rumpf. Lediglich in Spezialfällen kann die gesamte Information bereits im Betreff enthalten sein (etwa bei subscribe, um sich für eine Mailing-Liste anzumelden).

Mehr Objekte durch MIME

Moderne E-Mail-Systeme erlauben den Versand von nahezu beliebigen Objekten. Der Text kann formatiert sein (zum Beispiel als HTML-Code) und Bilder, Musikstücke oder Ähnliches können als Anhang (Attachment) mitgeschickt werden. Als Standard zur Darstellung der unterschiedlichen Objekte dient die Multi-Purpose Internet Mail Extension (MIME). MIME umfasst dabei:

• Weitere Typen für die Kopfzeile wie etwa die MIME-Version.

• Definition von Inhaltstypen und -untertypen; zwei Beispiele sind: image/gif, text/richtext.

• Einen Typ Multipart, um mehrere Objekte zu einer gemeinsamen E-Mail zu verbinden.

Das folgende Beispiel zeigt eine E-Mail mit einem kurzen Text und einer MS-Word-Datei als Anhang.

MIME-Version: 1.0
Content-Type: Multipart/Mixed;
Boundary="__Next_1024570278_Part4__"

--__Next_1024570278_Part4__
Content-Type: Text/Plain;
Charset="ISO-8859-1"
Content-Transfer-Encoding: Quoted-Printable

Text
--__Next_1024570278_Part4__
Content-Disposition: Attachment; filename="ueb1.doc"
Content-Type: application/msword;
Name="ueb1.doc"
Content-Transfer-Encoding: Base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAABAAAALgAAAAAA
AAAAEAAAMAAAAAEAAAD+////AAAAAC0AAAD/////////////////////////////
////////////////////////////////////////////////////////////////

Kodierung der Daten

Mime überträgt Dateien nicht binär, um eventuelle Probleme mit der unterschiedlichen Darstellung von Binärdaten auf den diversen Gateways zu vermeiden. In dem Beispiel wird eine Base64-Kodierung benutzt. Diese fasst je drei Bytes zu einer 24-Bit-Einheit zusammen. Daraus erzeugt sie vier ASCII-Zeichen mit je sechs Bit.

Die Darstellung beschränkt sich damit auf nur 64 Zeichen: 26 Buchstaben (jeweils klein und groß), zehn Ziffern und die beiden Sonderzeichen + und /. Dies bläht zwar das zu übertragende Datenvolumen um ein Drittel auf, verhindert aber zuverlässig Kompatibilitätsprobleme. Der Client des Empfängers findet bei Erhalt der Nachricht alle Informationen in den Kopfzeilen der E-Mail, um die ursprüngliche Datei wiederherzustellen. (ala)