Netzwerk-Know-how (tecCHANNEL COMPACT) Kapitel 10: Netzwerkanwendungen

Veröffentlicht: 13. Jul 2005

Von PROF. DR. STEPHAN EULER

Auf die von

Ende-zu-Ende-Protokollen wie TCP und UDP bereitgestellten Dienste bauen verbreitete Anwendungen wie E-Mail oder WWW für die Benutzer auf. Einige davon, wie etwa telnet, nutzen direkt den Transportdienst, während andere zusätzliche eigene Kommunikationsprotokolle einführen. In diesem Beitrag wird am Beispiel einiger weit verbreiteter Anwendungen diskutiert, wie diese die Funktionalität der Transportschicht nutzen.

Auf dieser Seite

In diesem Beitrag

World Wide Web Das Protokoll HTTP Universal Resource Identifier HTTP-Cache E-Mail Das Protokoll SMPT Nachrichtenformat und MIME E-Mail-Adressierung Usenet Netzwerk-Management Multimedia-Kommunikation Real-Time Transport Protocol RTP-Verbindungsaufbau VolP - Sprachübertragung über IP Sprachkodierung Telefonanwendungen Literatur

Kapitel 1: Netzwerkgrundlagen Kapitel 2: Rechner-zu-Rechner-Verbindung Kapitel 3: Ethernet & Co. Kapitel 4: Vermittlung Kapitel 5: Internet-Protokoll Kapitel 6: UDP und TCP Kapitel 7: Grundlagen der ATM-Netzwerktechnologie Kapitel 8: Verbindungsorientierte Kommunikation Kapitel 9: Remote Procedure Call – RPC Kapitel 10: Netzwerkanwendungen Kapitel 11: Datensicherheit und Verschlüsselung Kapitel 12: RSA im Detail

World Wide Web

Die wohl derzeit 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 über TCP. Es stellt einen zuverlässigen, bidirektionalen Byte-Strom bereit. Die Kommunikation erfolgt aber in Form von Anfragen und Antworten. Daher benötigt man ein Protokoll, das über den TCP-Strom einen geeigneten Anfragen- und Antwortmechanismus realisiert. Dieses Protokoll nennt sich HTTP: HyperText Transport Protocol.

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 Bilder 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.

Zum Seitenanfang

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.

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:

1. dem Befehl GET
2. dem URL
3. 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.

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 Inhaltes 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 2002 08:51:23 CEST
Last-Modified: Wed, 05 Jun 2002 11:00:27 CEST
MIME-Version: 1.0
Content-Type: text/html
Content-length: 78

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

Die erste Zeile enthält in diesem Beispiel die HTTP-Version der Nachricht und 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 und Datumsangaben.

Wichtig für die weitere Bearbeitung durch den Client sind die Einträge Content Type und Content Length. Content Type beschreibt den MIME-Typ der im Datenbereich übermittelten Datei. Im Header-Feld Content Length gibt der Server die Länge der Daten in Byte an. Der Einsatz des Feldes ist dabei nicht zwingend vorgeschrieben. Das RFC gibt jedoch die Empfehlung, das Feld immer zu senden. Getrennt durch eine Leerzeile folgt dann der HTML-Code der Seite.

Zum Seitenanfang

Universal Resource Identifier

HTTP spricht Dokumente über eine Adresse in Form eines Universal Resource Locator (URL) an. Der URL ist einer 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 im Netzwerk 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 automatisch.

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=l &shortcut=4
&SortProperty=MetaEndSort
&maxRecordsPerPage=50
&st=2 &ebaytaglcode=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.

Zum Seitenanfang

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, den Cache (Englisch: geheimes Lager), abzulegen. Bei einem erneuten Aufruf der Seite kann der Browser dann 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 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.

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. Durch diesen Effekt kann der Zugriffszähler einen zu niedrigen Wert enthalten.

Der zweite Teil der Artikelserie „Netzwerkanwendungen“ beschäftigt sich mit elektronischer Post. Dabei wird das Anwendungsprotokoll Simple Mail Transfer Protocol (SMTP) und das Protokoll Multi-Purpose Internet Mail Extension (MIME) zum Format der Nachricht näher betrachtet.

Zum Seitenanfang

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 oder 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 gleichen Funktionalität - Empfangen und Senden von E-Mails - bereit. Insofern ergibt sich die Unterscheidung eher aus der jeweiligen Rolle aus Sicht des Benutzers.

Zum Seitenanfang

Das Protokoll SMPT

Das Protokoll zum Austausch von E-Mails über das 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 E-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 den gewünschten 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.

Zum Seitenanfang

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 definierten 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 darauf folgenden 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; ...
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

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

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/Piain;
Charset="ISO-8859-1"
Content-Transfer-Encoding: Quoted-Printable

Text
--__Next_1024570278_Part4__
Content-Disposition: Attachment; filename="uebl .doc"
Content-Type: application/msword;
Name="uebl.doc"
Content-Transfer-Encoding: Base64
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7 /CQAGAAAAAAABAAAALgAA AAAAEAAAMAAAAAEAAAD+ / / / /AAAAACOAAAD/////////////////////////

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.

Bild 1: Je drei Bytes werden bei der Base64-Kodierung in vier Zeichen des einfachen ASCII-Zeichensatzes umgewandelt

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 zwischen unterschiedlichen Gateways, E-Mail-Servern und Clients. Der E-Mail-Client des Empfängers findet bei Erhalt der Nachricht alle Informationen in den Kopfzeilen der E-Mail, um die ursprüngliche Datei wiederherzustellen.

Zum Seitenanfang

E-Mail-Adressierung

Aus der E-Mail-Adresse extrahiert der Mail-Daemon die Zieladresse. Mittlerweile haben viele Adressen ein klares und leicht verständliches Format in der Art Voname.Name@Firma. Der Teil nach dem @ enthält den Namen des zuständigen Mail-Servers. Die zugehörige IP-Adresse kann der Mail-Daemon über eine DNS-Anfrage ermitteln.

Häufig werden E-Mails jedoch nicht direkt, sondern über spezielle Zwischenstationen (Gateways) geleitet. Diese Gateways übernehmen auch, falls erforderlich, eine Zwischenspeicherung. Denn anders als IP-Pakete sollen E-Mails nicht ohne Weiteres verworfen werden, nur weil durch einen Leitungsengpass die Weiterleitung momentan nicht möglich ist. Eine weitere wichtige Aufgabe von Gateways kann die Überprüfung von eingehenden E-Mails auf verdächtigen Inhalt wie Viren oder Spam sein.

Der eigentliche Zielknoten, also der Rechner, auf dem der Adressat seine E-Mails anschauen wird, ist in der Regel nicht bekannt. Zudem kann er sich von Fall zu Fall ändern. Daher wird die E-Mail zunächst nur bis zum Mail-Server geschickt.

Ist der Benutzer dort angemeldet und läuft auf seinem Client ein aktiver Mail-Daemon, so kann der Server die Nachricht direkt zustellen. Ansonsten informiert bei der nächsten Anmeldung des Benutzers der dann gestartete Mail-Daemon den Server und holt damit die Post ab. Alternativ kann der Benutzer selbst aktiv die E-Mails abfragen. Unter Umständen muss der Mail-Server die Nachrichten über eine längere Zeit vorhalten, etwa wenn der Adressat in Urlaub ist.

Zum Seitenanfang

Usenet

Neben der direkten Kommunikation über E-Mail besteht auch die Möglichkeit, Informationen in Diskussionsforen auszutauschen:

• Die Teilnehmer können Beiträge (Artikel; Englisch: news) schreiben und in dem Forum veröffentlichen.
• Andere Teilnehmer können auf diese Artikel antworten. Diese Antworten werden als neue Beiträge veröffentlicht, auf die die Forumsteilnehmer wiederum reagieren können. Dadurch kann sich die Diskussion auch in mehrere Äste aufspalten. Zur besseren Übersicht stellt die Anwendung alle Antworten als gemeinsamen Baum dar. Man spricht dann von Threads - dem englischen Wort für Faden oder Zwirn. Dementsprechend markiert der Newsreader von Mozilla solche Diskussionen mit dem Symbol einer Zwirnrolle.

Diese Diskussionsforen (Newsgroups) sind auf speziellen News-Servern abgelegt. Einen Verbund vieler News-Server bildet das USENET (ursprünglich Unix User Network). Die daran beteiligten Server tauschen untereinander ständig die neuen Artikel aus (Replikation), so dass ein einheitlicher Stand gewährleistet ist.

Allerdings kann ein Server schon allein aus Speicherplatzgründen nicht alle Newsgroups bereitstellen, sondern immer nur einen Teilbereich abdecken. Außerdem ist es auch möglich, mit der gleichen Technologie private oder interne News-Server zu betreiben.

Die Vielzahl von Diskussionsgruppen ist hierarchisch unterteilt. Die einzelnen Namensbestandteile sind durch Punkte getrennt, und es gilt die Regel „Vom Allgemeinen zum Speziellen". Die ersten Kürzel spezifiziert das Hauptthema oder ein Land. Einige Beispiele sind:

• comp.speech.research - ein Forum zur Erforschung der Sprachverarbeitung mit Computern.
• de.sci.informatik.ki - eine deutsche Gruppe zum Thema „Künstliche Intelligenz".
• rec.games.majong - alles über das Spiel Majong (das Kürzel rec steht für re-creation; Erholung).

Newsgroups findet man über spezielle Suchdienste wie etwa.fmdolin (http://www. fmdolin.com). Die allermeisten Newsgroups sind unmoderiert. Allerdings wird an die Teilnehmer appelliert, bestimmte Regeln einzuhalten. Man sollte sich klar machen, dass ein eigener Beitrag von Millionen von Menschen gelesen werden könnte. Daher sind Klarheit und Sorgfalt notwendig, um eventuellen Missverständnissen vorzubeugen. Allzu schnell wird ein Beitrag falsch verstanden und führt zu einem erbitterten Austausch von News. In der RFC 1855 „Netiquette Guidelines" sind allgemeine Regeln für Newsgroups und andere Kommunikationsdienste zusammengestellt.

Um an Newsgroups teilzunehmen, benötigt man einen entsprechenden Newsreader. Dazu stehen spezielle Programme zur Verfügung. Alternativ bieten die meisten E-Mail-Programme die entsprechende Funktionalität. Man muss nur noch einen passenden News-Server auswählen. Das kann der Server eines Netzanbieters sein (etwa news.t-online.de bei T-Online). Daneben gibt es kommerzielle oder frei verfügbare Server wie den www.individual.de der Freien Universität Berlin. Der komplette Verweis auf eine Gruppe hat dann die Form

news://news.t-online.de/de.comm.internet.misc

Verbindung Informationen und die Beiträge zu übertragen. Es umfasst sowohl die Kommunikation zwischen News-Server und Newsreader als auch den Abgleich zwischen zwei News-Servern. Für die Nachrichten wird die gleiche Formatierung wie für E-Mails verwendet. Entsprechende Kopfeinträge übermitteln die erforderlichen Informationen. So wird im Eintrag Newsgroups: festgelegt, zu welcher Gruppe oder zu welchen Gruppen ein Beitrag gehört. Der Rumpf der Nachricht wird mittels MIME kodiert.

Zum Seitenanfang

Netzwerk-Management

In der Diskussion der verschiedenen Protokollebenen hat sich bereits gezeigt, dass deren Designer Wert auf ein weit gehend selbstständiges, unüberwachtes Funktionieren des Netzes gelegt haben. Die Protokolle enthalten Mechanismen, um mit auftretenden Fehlern umgehen zu können. Die Knoten passen ihr Verhalten teilweise an die aktuelle Situation an. Trotzdem benötigt man Möglichkeiten, das Verhalten eines Netzes im Detail untersuchen zu können, um Fehler oder Schwachstellen aufzuspüren.

Ein dazu häufig verwendetes Protokoll ist das Simple Network Management Protocol (SNMP). SNMP erlaubt es, zahlreiche Parameter von Knoten im Netz abzufragen. Jeder Knoten, der an diesem System teilnimmt, stellt dazu einen SNMP-Server bereit. Von anderen Systemen aus kann man dann mit einem Client die Statusinformationen abfragen. SNMP realisiert dazu ein Abfrage-Antwort-Protokoll auf der Basis von UDP Die beiden wesentlichen Operationen sind GET, um Werte zu lesen und SET, um Werte zu setzen.

Der Netzwerkknoten sammelt im laufenden Betrieb ständig Informationen und legt sie in einer internen Datenbank, der Management Information Base (MIB), ab. Über ein spezielles Identifizierungssystem kann man per SMTP jede dieser Variablen abfragen. SNMP verwendet dazu eine standardisierte Darstellung zur Übermittlung von Datentypen wie Integer-Zahlen oder Gleitkommazahlen.

Zum Seitenanfang

Multimedia-Kommunikation

Mit seiner ständig wachsenden Ausdehnung und Verfügbarkeit ist das Internet auch als Plattform für Multimedia-Anwendungen interessant. Unter Multimedia im eigentlichen Sinne versteht man die Integration verschiedener Medien in einer Anwendung oder in einem Dokument. Dabei können die Medien zeitunabhängig (Text, Grafik, Bild) oder zeitabhängig (Audio, Video) sein.

Weiterhin lassen sich die Anwendungen in zwei Klassen aufteilen:

• Anwendungen zwischen zwei oder mehr Benutzern. Diese bezeichnet man auch als Konferenzanwendungen.
• Anwendungen zwischen einem Server und einem oder mehreren Clients (Streaming-Anwendungen)

Zeitabhängige Multimedia-Anwendungen stellen hohe Anforderungen an die Übertragung. So benötigt etwa eine Video-Konferenz eine große Bandbreite bei gleichzeitig geringer Latenz. Die Synchronisation verschiedener Datenströme (etwa bei getrennten Audio- und Video-Kanälen) erfordert zusätzliche Maßnahmen zur Zusammenführung und Ablaufsteuerung. Hierbei kann es beispielsweise erforderlich sein, bei Leitungsengpässen das Video-Bild einzufrieren und nur noch den Ton zu übertragen, da dieser die wichtigere Informationsquelle für den Kommunikationspartner ist.

Zum Seitenanfang

Real-Time Transport Protocol

Ein universelles Transportprotokoll für Multimedia-Daten ist das Real-Time Transport Protocol (RTP). Es soll die notwendigen Eigenschaften für eine Echtzeitkommunikation bereitstellen, dabei aber so wenige Festlegungen wie möglich enthalten. So bleibt es etwa der Anwendung selbst überlassen, wie sie mit Paketverlusten umgeht.

RTP setzt auf UDP auf. UDP bietet die notwendige Grundfunktionalität - Zustellung von Paketen ohne großen Overhead. RTP ergänzt diesen Paketdienst um einige für die Echtzeit-Kommunikation notwendige Elemente.

Bild 2: Der Protokoll-Stack von RTP setzt auf UDP auf.

Der Header für RTP-Pakete ist mindestens 12 Byte lang. Er enthält eine 16 Bit große Sequenznummer für das Paket. Diese Nummer wird bei jedem Paket um Eins erhöht. Anhand dieser Nummern kann der Empfänger erkennen, ob er alle Pakete in der richtigen Reihenfolge erhält. Die zeitliche Beziehung stellt ein Feld mit einem Zeitstempel her. Dabei ist das exakte Format des Zeitstempels abhängig von der Anwendung.

Die Quelle des Datenstroms wird über eine 32-Bit-Zahl im Feld Synchronization Source (SSRC) mitgeteilt. Über ein 7 Bit großes Feld wird der Typ der Nutzdaten angegeben. Damit könnte beispielsweise ein Wechsel der Kodierungsmethode angezeigt werden. Schließlich kann ein RTP-Strom Beiträge von mehreren Quellen enthalten (zum Beispiel mehrere Mikrofonkanäle).

Bild 3: RTP regelt den Transport der Echtzeltdaten über einen eigenen Header.

Die Bedeutung der einzelnen Datenfelder im RTP-Header erläutert die folgende Tabelle.

RTP ist optimiert für die schnelle Übertragung. Das Protokoll enthält keinerlei Elemente zum Umgang mit verlorenen Paketen oder etwa zur Überlastkontrolle. Allerdings ist es wünschenswert, dass der Empfänger über den aktuellen Zustand der Verbindung informiert wird. Beispielsweise könnte ein Sender bei einem Bandbreitenengpass zu einer Kodierung mit niedriger Datenrate wechseln oder unwichtigere Elemente nicht mehr übertragen.

Zur Überwachung und Steuerung einer RTP-Sitzung dient das Protokoll RTP Control Protocol (RTCP). Eine RTP-Sitzung besteht aus einem RTP- und einem RTCP-Kanal. Für eine Sitzung wird für RTP eine gerade Portnummer und für RTCP die darauf folgende ungerade Portnummer vergeben.

Über RTCP tauschen die Kommunikationspartner parallel zu RTP Pakete aus. Dabei kommen in der Regel ebenfalls ÜDP-Pakete zum Einsatz. Diese Pakete beinhalten Sende- oder Empfangsberichte mit Übertragungsstatistiken. Die Statusberichte tauschen die Partner in periodischen Abständen aus.

Informationen über den Sender werden mit Quellenbeschreibungspaketen übermittelt. Als Kennung dient der so genannte kanonische Name (CNAME). Das übliche Format dafür ist „user@host". Die Quellenbeschreibungspakete enthalten die Zuordnung zwischen SSRC und CNAME. Mit dieser Information kann der Empfänger die Daten dem Absender zuordnen. Damit kann er auch mehrere Quellen (etwa Audio, Video, Grafik) von einem gemeinsamen Sender unterscheiden.

Schließlich bietet RTCP die Möglichkeit, ergänzende Informationen parallel zu dem Datenstrom über RTP zu senden. Ein Beispiel hierzu sind Untertitel für einen Video-Strom. Trotz all dieser Funktionen streben beide Kommunikationspartner an, den Verkehr über RTCP auf etwa fünf Prozent des Datenaufkommens für den RTP-Verkehr zu beschränken.

Zum Seitenanfang

RTP-Verbindungsaufbau

Vor einer Kommunikation über RTP muss eine Sitzung eingeleitet werden. Je nach Anwendung reicht diese Aufgabe von der einfachen Ankündigung einer Übertragung bis hin zum aufwendigen Aufbau einer Video-Konferenz. Dabei muss der Initiator zunächst die Gesprächspartner suchen und dann ein gemeinsames Kodierungsverfahren aushandeln.

Eine Arbeitsgruppe der Internet Engineering Task Force (IETF) hat dafür eine Reihe von Protokollen entwickelt. Um beispielsweise eine Telefonverbindung über Internet herzustellen, sind die Protokolle Session Initiation Protocol (SIP) und Session Description Protocol (SDP) gebräuchlich.

Alternativ entwickelte ITU (International Telecommunication Union) die Empfehlung H.323 für den Gesprächsaufbau. Die Eigenschaften des Gesprächs werden dabei über das Call-Control-Protokoll H.245 bestimmt. Geräte, die über H.323 Verbindungen aufbauen, werden auch als H.323-Terminals bezeichnet.

Während der ITU-Standard H.323 vor allem im Umfeld professioneller TK-Anlagen zum Einsatz kommt, gewinnt das von der IETF festgelegte SIP in öffentlichen Netzen und bei Privathaushalten zunehmend an Bedeutung.

Zum Seitenanfang

VolP - Sprachübertragung über IP

Eine Anwendung von großer kommerzieller Bedeutung ist die Sprachübertragung für Telefongespräche. Daher begannen verschiedene Firmen frühzeitig, Lösungen zur Sprachübertragung über IP (Voice over IP, VolP) zu entwickeln. Die paketorientierte Technik verspricht einen deutlichen Kostenvorteil gegenüber dem lei-tungsorientierten herkömmlichen Telefonsystem.

Zum einen entfällt die Installation eines eigenen Netzwerkes nur für den Telefonverkehr. Zum anderen ist die Übertragung innerhalb des Internets zumindest bei Fernverbindungen wesentlich preisgünstiger möglich. Allerdings erwartet der Kunde einen vergleichbaren Stand bezüglich

• einfacher Bedienung
• guter Sprachqualität
• hoher Zuverlässigkeit

Im Folgenden werden die Grundprinzipien als Beispiel für eine Echtzeitkommunikation über das Internet beschrieben. Eine ausführliche Darstellung findet man beispielsweise in [2] und [3].

Zum Seitenanfang

Sprachkodierung

Das analoge Telefonnetz überträgt die Sprachsignale in dem Frequenzbereich von 300 bis 3300 Hz (Telefonbandbreite). Ausgehend von diesem Frequenzband wurde bei der Digitalisierung eine Abtastrate von 8000 Hz gewählt. Gemäß dem Ny-quist-Kriterium (Maximalfrequenz = halbe Abtastrate) sind so Frequenzen bis 4000 Hz enthalten. Die Pulscodemodulation (PCM) kodiert dabei jeden Abtastwert als Zahlen. Der Wertebereich dieser Zahlen bestimmt den Signal-Rauschabstand der Übertragung und damit deren Qualität.

Für Gespräche im Telefonnetz nutzt man physiologische Schwächen des menschlichen Gehörs aus. Daher ist nicht über den gesamten Amplitudenbereich eine gleichmäßige Quantisierung notwendig. Für große Amplituden kann man eine gröbere Rasterung verwenden, ohne dass dadurch eine hörbare Verschlechterung der Sprachqualität auftritt.

Auf diese Weise ist es möglich, mit nur 8 Bit Auflösung eine gute Qualität zu erreichen. Die Kombination aus 8 kHz Abtastrate und 8 Bit Auflösung ergibt eine nötige Bandbreite von 64 Kbit/s - den Standard in ISDN.

Bild 4: Die nicht lineare Quantisierungskurve verringert das so genannte Quantisier rauschen, da sie den relativen Fehler bei kleinen Abtastwerten reduziert

Die Datenrate lässt sich weiter verringern, wenn man spezielle Eigenschaften der Sprachsignale ausnutzt. Ein Ansatz dazu beruht auf der Annahme, dass die Amplituden aufeinander folgender Abtastwerte in der Regel nicht beliebig weit auseinander liegen. Überträgt man anstelle der Abtastwerte nur die Differenzen benachbarter Werte, so kann man den dann auftretenden kleineren Wertebereich mit weniger Bit quantisieren.

Bei adaptiven Verfahren wird der Wertebereich zusätzlich an die aktuelle Lautstärke angepasst. Dadurch erreicht man eine möglichst gute Übereinstimmung zwischen Wertebereich und auftretenden Amplituden. Ein Standard nach diesem Prinzip ist der „Adaptive Differenzielle PCM" (ADPCM) mit 32 Kbit/s gemäß ITU G.726. Gegenüber dem PCM-Standard wird bei nahezu gleicher Sprachqualität nur die halbe Datenrate benötigt. Ein Beispiel für den Einsatz dieses Standards ist DECT (Digital European Cordless Telephony) für schnurlose Telefone.

Sprachsignale enthalten noch sehr viel mehr Strukturen. Eine Reihe von Verfahren, die diese Strukturen weit gehend ausnutzen, beruhen auf dem Basisprinzip von Code Excited Linear Predictive Coding (CELP). Diese Verfahren benutzen spezielle adaptive Filter - so genannte lineare Prädiktoren - zur Vorhersage der nächsten Abtastwerte. Das Anregungssignal wird durch systematisches Probieren von Codes aus einem Vorrat ermittelt [4]. Vertreter dieser Coder-Familie setzen die GSM-Netze für Handytelefonate ein.

Der so genannte CELP Füll Rate Coder arbeitet mit 12,2 Kbit/s. Die neue Nachfolgetechnik Half Rate benötigt bei annähernd gleicher Sprachqualität nur noch 5,6 Kbit/s. Für VoIP weit verbreitet sind die Standards G.729A (CompuServe ACELP) mit 8 Kbit/s und G.723.1 Multi Rate Coder mit 5,3 und 6,3 Kbit/s. Ein neuerer Standard speziell für das Internet ist der Internet Low Bit Rate Codec (iLBC). Dieser Coder arbeitet bei 13,3 oder 15,2 Kbit/s. Er wurde speziell für Situationen, in denen Pakete verloren gehen, ausgelegt. In solchen Fällen wird mittels einer so genannten Packet-Loss-Concealment-Einheit für eine Überbrückung der fehlenden Blöcke ohne Störgeräusche gesorgt.

Dialoge enthalten einen Anteil von bis zu 50 Prozent Pausen. Eine weitere Datenreduktion ist daher möglich, wenn der Coder die Sprachpausen nicht mit übertragen muss. Erkennt er, dass ein Teilnehmer im Moment nicht spricht, überträgt er keine Blöcke, die nur Hintergrundgeräusche enthalten. Um den Eindruck einer „toten Leitung" zu vermeiden, kann die Gegenseite ein künstliches Rauschen einspielen. Damit ist eine deutliche Reduktion der Datenkommunikation möglich. Allerdings können Fehlentscheidung in der Pause-Detektion oder ein zu spätes Ansprechen auf eine beginnende Sprachaktivität zu einem sehr unnatürlichen Spracheindruck führen.

Bei sämtlichen Codecs muss man zur Berechnung der Bandbreite zu den Sprachdaten noch die Paket-Header hinzuaddieren. Die unten stehende Tabelle zeigt die entsprechenden Werte bei einem Coder mit 6 Kbit/s und einer Dauer von 30 ms für einen Sprachblock.

Bei der Übertragung über Ethernet kommen weitere 29 Byte (inklusive 3 Byte LLC-Header) pro Paket hinzu. Insgesamt ergeben sich somit 92 Byte pro Paket in dem 23 Bytes Sprachinformationen enthalten sind. Mit 33,3 Paketen pro Sekunde resultiert daraus eine Bandbreite im Netzwerk von 24,5 Kbit/s pro Richtung und 49 Kbit/s für die Telefonverbindung.

Die Zusammenstellung zeigt, dass die verschiedenen Header in Summe gegenüber der Nutzlast dominieren. Daher wurden Protokoll-Erweiterungen entwickelt, um die Länge der Header zu reduzieren. Ein Ansatzpunkt ist, einen Teil der Header-Informationen nur zu Beginn der Verbindung zu übertragen. Während der eigentlichen Datenübertragung ändern sich diese Informationen entweder gar nicht mehr oder nur geringfügig. Indem das Protokoll nur noch die Veränderungen überträgt, kann es die Länge der Header deutlich reduzieren.

Ein Problem besteht allerdings darin, dass einzelne Pakete verloren gehen können. Ohne weitere Maßnahmen würde dann unter Umständen ein Teil der Veränderungen fehlen, so dass der Empfänger fehlerhafte Werte rekonstruiert. Speziell für dieses Einsatzgebiet ist das Protokoll RObust Header Compression (ROHC), RFC 3095, definiert. Nach [5] lässt sich mit ROHC eine Reduktion der Header von RTP, UDP und IP mit zusammen 20 Byte auf durchschnittlich 6 Byte erzielen, ohne die Sprachqualität zu beeinträchtigen.

Ein zweites wichtiges Kriterium für die Verbindungsqualität ist die Verzögerungszeit. Ab etwa 100 ms machen sich Verzögerungen im Gespräch störend bemerkbar. Laut ITU-T-Empfehlung gelten Verzögerungen bis 200 ms noch als gut und bis 400 ms gerade noch als akzeptabel. Die Sprachkodierung führt durch die Blockbildung bei den niedrigen Datenraten zu etwa 10 bis 30 ms Verzögerung. Hinzu kommt die Latenz der Verbindung. Innerhalb eines Firmennetzes ist die resultierende Gesamtverzögerung in der Regel unterhalb der kritischen Grenzen. Bei einer Übertragung im Internet können sich allerdings durch die zahlreichen Zwischenstationen und Paketverluste deutliche Qualitätseinbußen ergeben.

Zum Seitenanfang

Telefonanwendungen

Mit den beschriebenen Mitteln kann ein Rechner die Funktion eines Telefons übernehmen. Dazu genügen ein PC, eine handelsüblichen Sound-Karte, ein Mikrofon und ein Lautsprecher sowie eine entsprechende Software. Eine einfache Anwendung ist das Telefonieren von Rechner zu Rechner.

Die entsprechenden Programme ähneln Chat-Programmen. Über einen Server kann man Verbindung zu den angemeldeten Personen aufnehmen. In der Regel können sich weitere Personen an dem Gespräch beteiligen, so dass eine Konferenz entsteht. Viele Programme unterstützen dabei die parallele Kommunikation über mehrere Medien. So sind in das Programm NetMeeting von Microsoft neben der Sprachkommunikation auch noch Video und Whiteboard - ein gemeinsam genutztes Zeichentablett - integriert.

Neben der Kommunikation zwischen Rechnern ist auch die Verbindung zum öffentlichen Telefonnetz möglich. So bieten diverse Anbieter Gateways zwischen Internet und Telefonnetz an. Eine kostengünstige Verbindung besteht dann aus einer Internet-Verbindung bis zu einem Gateway in der Nähe des Ziels und einer Telefonverbindung vom Gateway bis zum Endteilnehmer. Das Gateway übernimmt die Umsetzung der Daten sowie der Signalisierungsinformationen. Bei H.323 ist ein so genannter Gatekeeper bei der Suche nach dem günstigsten Gateway behilflich.

Das Konzept lässt sich leicht zum Telefonieren zwischen zwei konventionellen Telefonen erweitern. Ein Teilnehmer ruft bei seinem lokalen Gateway an. Von dort wird eine RTP-Sitzung zu dem passenden Gateway in der Nähe des Ziels aufgebaut. Dieses leitet das Gespräch dann wieder an das konventionelle Telefon des Gesprächspartners weiter.

Zum Seitenanfang

Literatur

© www.tecCHANNEL.de

[1] Microsoft. RPC Programmer’s Guide and Reference

[2] Rolf-Dieter Köhler. Voice over IP. Mitp-Verlag, Bonn, 2002

[3] B. Goode. Voice over Ibternet Protocol (VoIP). Proc. IEEE, Vol. 90:1495-1517, 2002

[4] P. Noll. Speech and audio coding for multimedia communications. In Proceedings International Costs 254 Workshop on Intelligent Communication Technologies an Applications, pages 253-263, Neuchatel, 2000

[5] Stephan Rein, Frank Fitzek, and Martin Reisslein. Voice quality evaluationfor wireless transmission with ROHC. In Proceedings of the 7th IASTED International Conference in Internet an Multimedia Systems and Applications (ISMA), pages 461- 466, Honululu, August 2003

Zum Seitenanfang

| Home | Technische Artikel | Community