Galileo Computing < openbook >
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.


Kompendium der Informationstechnik
 von Sascha Kersken
EDV-Grundlagen, Programmierung, Mediengestaltung
Buch: Kompendium der Informationstechnik
gp Kapitel 13 Netzwerkhardware und -protokolle
  gp 13.1 Netzwerkkarten, -kabel und Netzzugangsverfahren
    gp 13.1.1 Die verschiedenen Ethernet-Standards
    gp 13.1.2 Token Ring
    gp 13.1.3 Drahtlose Netze
    gp 13.1.4 Sonstige Zugangsarten
  gp 13.2 Datenfernübertragung
    gp 13.2.1 Netzwerkzugang per Modem (analoge Telefonleitung)
    gp 13.2.2 ISDN
    gp 13.2.3 DSL-Dienste
  gp 13.3 Die TCP/IP-Protokollfamilie
    gp 13.3.1 IP-Adressen, Datagramme und Routing
    gp 13.3.2 Transportprotokolle
    gp 13.3.3 Das Domain Name System (DNS)
    gp 13.3.4 Verschiedene Internet-Anwendungsprotokolle
  gp 13.4 Andere Protokollstapel
    gp 13.4.1 Die AppleTalk-Protokollfamilie
    gp 13.4.2 Novell IPX/SPX
    gp 13.4.3 NetBEUI/SMB
  gp 13.5 Zusammenfassung

gp

Prüfungsfragen zu diesem Kapitel (extern)


Galileo Computing

13.3 Die TCP/IP-Protokollfamilie  downtop

Nach einigen halbherzigen Versuchen, das OSI-Referenzmodell durch konkrete Protokolle tatsächlich zu implementieren, bemerkte man letzten Endes, dass die bereits Jahre zuvor entwickelten Internetprotokolle hervorragend als flexible, skalierbare und universelle Netzwerkprotokollfamilie einsetzbar sind. Die rasante Ausbreitung des Internets und die freie Verfügbarkeit sorgten dafür, dass diese Protokolle heute häufiger als jeder andere Protokollstapel eingesetzt werden.


Abbildung 13.1   Der TCP/IP-Protokollstapel

Abbildung
Hier klicken, um das Bild zu Vergrößern


Der Internet-Protokollstapel

Zunächst zeigt Abbildung 13.1 eine konkrete Version des TCP/IP-Protokollstapels, der bereits im vorigen Kapitel vorgestellt wurde: Auf jeder Ebene sind die konkreten Protokolle zu erkennen, die dort arbeiten können. Die meisten dieser Protokolle werden in den folgenden Abschnitten genau erläutert; die Netzzugangsprotokolle der untersten Schicht wurden bereits weiter oben vorgestellt. Ganz unten habe ich zusätzlich einige Beispiele für die Hardware angegeben, auch wenn sie kein Teil des eigentlichen TCP/IP-Stapels ist.

Zwischen der Hardware und dem Netzzugang auf der einen und den anwendungsorientierten Protokollen auf der anderen Seite befinden sich die Protokolle der Vermittlungs- und der Transportschicht. Insgesamt werden alle Protokolle, die auf den verschiedenen Ebenen eines Schichtenmodells zusammenarbeiten, als Protokollstapel oder auch Protokollfamilie bezeichnet. Allerdings konzentriert sich der Schwerpunkt von TCP/IP auf die beiden mittleren Ebenen des Internet-Protokollstapels. Sie können zum einen auf fast jeden beliebigen Netzzugang aufsetzen, zum anderen wurde beinahe jede ernst zu nehmende Netzwerkanwendung inzwischen für diesen Protokollstapel umgesetzt – abgesehen von den klassischen Internetanwendungen, die ohnehin dafür geschrieben wurden.

Die Protokolle der mittleren Schichten sind dafür verantwortlich, dass Daten zuverlässig über verschiedene Teilnetze oder Netzwerksegmente hinweg übertragen werden können oder auch über Netze, die verschiedene Hardware oder Netzzugangsverfahren verwenden:

gp  Die Protokolle der Vermittlungsschicht regeln die Adressierung der Rechner und die Übertragung der Daten an den korrekten Rechner im Netzwerk. Darüber hinaus kümmern sie sich darum, dass Daten bei Bedarf in andere Teilnetze weitergeleitet werden, übernehmen also das so genannte Routing.
gp  Auf der Transportschicht werden die Daten in Pakete unterteilt sowie mit der Information versehen, welche Anwendung auf dem einen Host diese Daten an welche Anwendung auf dem anderen sendet.

Die Bezeichnung TCP/IP kombiniert die Namen der beiden wichtigsten Bestandteile des Protokollstapels: das Internet Protocol (IP) auf der Vermittlungsschicht und das Transmission Control Protocol, das am häufigsten verwendete Protokoll der Transportebene. In den nächsten beiden Abschnitten werden diese Protokolle näher vorgestellt, anschließend wird die technische Seite einiger wichtiger Internet-Anwendungsprotokolle beleuchtet.


Galileo Computing

13.3.1 IP-Adressen, Datagramme und Routing  downtop

Auf der Internet- oder Vermittlungs-Schicht des Internet-Protokollstapels arbeitet das Internet Protocol (IP). Als Internet wird in diesem Zusammenhang jedes Netzwerk bezeichnet, das diese Protokollfamilie verwendet. Dies verdeutlicht den Umstand, dass die Internetprotokolle dem Datenaustausch über mehrere physikalische Netzwerke hinweg dienen können. Spezielle Rechner, die mindestens zwei Netzwerkschnittstellen besitzen, leiten die Daten zwischen diesen Netzen weiter. Sie werden als IP-Router oder -Gateways bezeichnet. Im engeren Sinne ist ein Router ein Rechner, der Daten zwischen zwei Netzen des gleichen physikalischen Typs weiterleitet; ein Gateway verbindet dagegen zwei physikalisch verschiedene Netze. In der Regel werden die beiden Begriffe jedoch heute synonym verwendet.

Aufbau der IP-Adressen

Eine IP-Adresse des klassischen Typs – der Version IPv4 gemäß RFC 791 – ist eine 32 Bits lange Zahl. Sie wird üblicherweise in vier durch Punkte getrennten Dezimalzahlen zwischen 0 und 255 geschrieben. Allerdings ist die Logik, die einer solchen Adresse zugrunde liegt, besser verständlich, wenn sie binär notiert wird:

Eine typische IP-Adresse wäre etwa 11000010000100010101000111000001, in 8-Bit-Gruppen getrennt ergibt sich daraus 11000010 00010001 01010001 11000001 und lautet in der gängigen Schreibweise dann 194.17.81.193.

Netzzugang in TCP/IP-Netzwerken

Die unterste Ebene des Internet-Schichtenmodells ist der Netzzugang, nicht die Netzwerkhardware. Dies garantiert, dass sich die Internetprotokolle auf fast jeder beliebigen Hardware implementieren lassen, und in der Tat ist dies geschehen: In allen Formen von LANs wie Ethernet oder Token Ring, in WANs über Wähl- und Standleitungen wie auch über die meisten Formen von drahtlosen Netzen – überall laufen diese Protokolle. Dies ist ein weiterer guter Grund dafür, dass sich die Protokolle des Internets als Standard für die Netzwerkkommunikation durchsetzen konnten.

Im Grunde wird innerhalb der Spezifikation der TCP/IP-Protokolle nicht einmal der Netzzugang im OSI-Sinn beschrieben, sondern lediglich die Zusammenarbeit des IP-Protokolls, das sich innerhalb des Internet-Protokollstapels um Adressierung und Routing kümmert, mit verschiedenen Netzzugangsverfahren.

An dieser Stelle sollen nur zwei der wichtigsten Internet-Netzzugangsverfahren genannt werden: das für den Zugriff auf Ethernet verwendete Address Resolution Protocol (ARP) und das Point-to-Point Protocol (PPP), das für serielle Verbindungen über Modem, ISDN oder DSL eingesetzt wird. PPP wurde bereits weiter oben ausführlich beschrieben; hier das Wichtigste über ARP:

ARP

Das Address Resolution Protocol, beschrieben in RFC 826, übernimmt kurz gesagt die Umsetzung der vom Netzwerkadministrator vergebenen IP-Adressen in die vorgegebenen Hardware-Adressen der Netzwerkschnittstellen.

Da die IP-Adresse den einzelnen Hosts willkürlich zugeteilt wird, kann diese auf der Netzzugangsschicht nicht bekannt sein: Auf einer bestimmten Schicht eines Protokollstapels werden die Steuerdaten der höher gelegenen Ebenen nicht ausgewertet, sondern als gewöhnliche Nutzdaten betrachtet. Deshalb kann beispielsweise eine Netzwerkkarte oder ein Hub nicht anhand der IP-Adresse entscheiden, für welche Station ein Datenpaket bestimmt ist; sie nehmen diese Adresse nicht einmal wahr.

Nachdem die IP-Software auf einem Host oder Router anhand der Empfänger-IP-Adresse festgestellt hat, dass die Daten überhaupt für das eigene Netz bestimmt sind, wird der ARP-Prozess gestartet, um diese IP-Adresse in die MAC-Adresse des Empfänger-Hosts umzusetzen. Zu diesem Zweck sendet ein Rechner, der das ARP-Protokoll ausführt (beinahe jeder Rechner, der TCP/IP über Ethernet betreibt), ein so genanntes Broadcast-Datenpaket in das Netzwerk. Es handelt sich um ein Datenpaket mit einer speziellen Empfängeradresse, das an alle Rechner im Netzwerk übertragen wird. Der Rechner, der seine eigene IP-Adresse im Inhalt dieses Pakets erkennt, antwortet als Einziger auf diese Anfrage und versendet seine eigene MAC-Adresse. Auf diese Weise wird ermittelt, für welchen Rechner das Datenpaket bestimmt ist.

In Ausnahmefällen kann ein Rechner auch die MAC-Adressen anderer Stationen zwischenspeichern und in Vertretung antworten.

IP-Adress-Klassen

IP-Adressen bestehen aus zwei Komponenten: dem Netzwerk-Teil und dem Host-Teil. Der Netzwerk-Teil gibt an, in welchem Netz sich der entsprechende Rechner befindet, während der Host-Teil den einzelnen Rechner innerhalb dieses Netzes identifiziert.

Es gibt verschiedene Sorten von IP-Adressen, die sich bezüglich der Länge des Netzwerk- beziehungsweise Host-Teils voneinander unterscheiden. Traditionell werden die verfügbaren Adressen in feste Klassen unterteilt; inzwischen hat sich jedoch herausgestellt, dass diese Lösung allein zu inflexibel ist. Deshalb wurden Verfahren entwickelt, um die Trennung zwischen Netzwerk- und Host-Teil dynamisch vorzunehmen. Trotzdem werden als Erstes die ursprünglichen festen Klassen vorgestellt, denn noch immer erfolgt die öffentliche Vergabe von IP-Adressen an Netzbetreiber nach der Klassen-Logik.

Zu welcher Klasse eine IP-Adresse gehört, zeigt sich an den Bits, die am weitesten links stehen:

gp  Klasse A: Das erste Bit ist 0, folglich liegt die erste 8-Bit-Gruppe zwischen 0 und 127.
gp  Klasse B: Die ersten beiden Bits lauten 10; die erste Gruppe liegt im Bereich 128 bis 191.
gp  Klasse C: Die ersten drei Bits sind 110, sodass die erste Gruppe zwischen 192 bis 223 liegt.
gp  Klasse D: Die ersten vier Bits sind 1110; die Adressen beginnen mit 224 bis 239.

Die restlichen Adressen, die mit 240 bis 255 anfangen, sind nicht vergeben und für zukünftige Anwendungszwecke reserviert.

Je nach Klasse ist der Teil, der das Netzwerk kennzeichnet, unterschiedlich lang, entsprechend existieren unterschiedlich viele Netze der verschiedenen Klassen. Die Bits, die ganz rechts in der Adresse stehen und nicht zum Netzwerk-Teil gehören, sind die Host-Bits. Je nach Länge des Netzwerk-Teils bleiben unterschiedlich viele Bits für den Host-Teil übrig, sodass die Höchstzahl der Rechner in einem Netz variiert.


Tabelle 13.3   Die IP-Adress-Klassen

Klasse Adressbereich Netzwerk-Bits Host-Bits Anzahl Netze Adressen pro Netz
A 0.0.0.0 bis 127.255.255.255 8 (7) 24 128 16, 7 Mio.
B 128.0.0.0 bis 191.255.255.255 16 (14) 16 16.384 65.536
C 192.0.0.0 bis 223.255.255.255 24 (21) 8 2.097.152 256
D 224.0.0.0 bis 239.255.255.255 Spezieller Bereich der Multicast-Adressen

Tabelle 13.3 zeigt die wichtigsten Informationen zu den einzelnen Klassen im Überblick. In der Spalte Netzwerk-Bits stehen jeweils zwei Werte. Der erste stellt die Anzahl von Bits dar, die insgesamt den Netzwerk-Teil bilden. Da die Grenzen zwischen Netzwerk- und Host-Teil an den Byte-Grenzen verlaufen, handelt es sich je nach Klasse um 1 bis 3 Byte. Da jedoch die Bits am Anfang der Adresse – wie oben gezeigt – die Klasse angeben, besteht die praktisch nutzbare Netzwerkangabe nur aus 7, 14 beziehungsweise 21 Bit. Der Rest der Adresse bildet den Host-Teil, der je nach Klasse unterschiedlich groß ausfällt.

Netz- und Broadcast-Adresse

Innerhalb eines einzelnen Netzes – egal welcher Klasse – stehen die erste und die letzte mögliche Adresse nicht als Host-Adressen zur Verfügung: Die niedrigste Adresse identifiziert das gesamte Netz als solches nach außen hin, aber keinen speziellen Host; die höchste Adresse ist die so genannte Broadcast-Adresse: Werden Datenpakete innerhalb des Netzes an diese Adresse gesendet, so werden sie von jedem Host empfangen.

Zum Beispiel bilden die Adressen, die mit 18.x.x.x beginnen, das Klasse-A-Netzwerk 18.0.0.0 mit der Broadcast-Adresse 18.255.255.255 und Host-Adressen von 18.0.0.1 bis 18.255.255.254. Dieses Netz kann theoretisch bis zu 16.777.214 Hosts beherbergen (224  – 2).

Die Adressen, die mit 162.21.x.x anfangen, befinden sich in dem Klasse-B-Netzwerk 162.21.0.0, dessen Broadcast-Adresse 162.21.255.255 lautet. Es kann bis zu 65.534 Hosts (216   –  2) mit den Adressen 162.21.0.1 bis 162.21.255.254 enthalten.

Letztes Beispiel: Adressen, die mit 201.30.9.x beginnen, liegen in dem Klasse-C-Netz 201.30.9.0 mit der Broadcast-Adresse 201.30.9.255; die 254 möglichen Host-Adressen (2 – 2) sind 201.30.9.1 bis 201.30.9.254.

Multicasting

Die so genannten Multicast-Adressen der Pseudo-Klasse D nehmen eine Sonderstellung ein: Eine Multicast-Gruppe ist eine auf beliebige Netze verteilte Gruppe von Hosts, die sich dieselbe Multicast-IP-Adresse teilen. Dies ermöglicht einen erheblich ökonomischeren Versand von Daten, da sie nicht mehr je einmal pro empfangendem Host versendet werden, sondern nur noch kopiert werden müssen, wo Empfängerrechner in unterschiedlichen Teilnetzen liegen. Aus diesem Grund ist Multicasting eine zukunftsträchtige Technologie für datenintensive Anwendungen wie etwa Videokonferenzen. Im Gegensatz dazu werden die individuellen Host-Adressen als Unicast-Adressen bezeichnet.

Die Verteilung der IP-Adressen

Alle Adressen des IPv4-Adressraums werden von der Internet Assigned Numbers Association (IANA) verwaltet. Falls Sie jedoch für bestimmte Anwendungen in Ihrem Unternehmen eine oder mehrere feste IP-Adressen benötigen, dann sollten Sie sich in der Regel an einen Internetprovider und nicht an die IANA selbst wenden.

Verfügbarkeit nach Klassen

Die 128 Netze der Klasse A sind bereits alle vergeben; in der Regel an große internationale Unternehmen aus dem Elektronik- und Computerbereich sowie an US-amerikanische Staats-, Militär- und Bildungsinstitutionen. Beispielsweise gehört das Netz 17.0.0.0 der Firma Apple, 18.0.0.0 dem Massachusetts Institute of Technology (MIT) und 19.0.0.0 der Ford Motor Company.

Die 16.384 Klasse-B-Netze sind ebenfalls weitgehend vergeben, insbesondere an US-amerikanische Unternehmen und Internetprovider.

Die mehr als zwei Millionen Netze der Klasse C schließlich sind inzwischen ebenfalls überwiegend belegt. Die meisten von ihnen gehören Unternehmen und Internetprovidern, die nicht in den USA residieren, etwa in Europa oder Asien. Da solche Institutionen oft mehr als 254 Hosts in ihrem Netz betreiben, wird ihnen häufig ein größerer Block von aufeinander folgenden Klasse-C-Netzen zugewiesen.

Die aktuelle Verteilung der IPv4-Adressen können Sie direkt auf der Website der IANA unter http://www.iana.org/assignments/ipv4-address-space einsehen.

Spezielle Adressen

Als das Konzept der IP-Adressen entstand, konnte niemand auch nur ansatzweise erahnen, welche Dimensionen das Internet einmal annehmen würde. Deshalb glaubten die ursprünglichen Entwickler, dass sie es sich leisten könnten, den Adressraum relativ großzügig aufzuteilen: Bedenken Sie etwa, dass die Hälfte des Adressraums für die überaus ineffektiven Klasse-A-Adressen vergeudet wird. Um die drohende Verknappung der IP-Adressen zu verhindern oder zumindest zu verzögern, bis eine Alternative gefunden würde, wurden einige Adressbereiche zur Verwendung in privaten Netzwerken freigegeben, die nicht mit dem Internet verbunden sind. Es handelt sich um die folgenden Blöcke:

gp  Das Klasse-A-Netz 10.0.0.0
gp  Die 16 Klasse-B-Netze 172.16.0.0 bis 172.31.0.0
gp  Die 256 Klasse-C-Netze 192.168.0.0 bis 192.168.255.0

Ein weiterer Block, der erst später freigegeben wurde, ist das Klasse-B-Netz 169.254.0.0, das einem besonderen Verwendungszweck vorbehalten ist: Moderne TCP/IP-Implementierungen in fast allen Betriebssystemen verwenden dieses Netz für »link local« – eine Möglichkeit, sich automatisch selbst IP-Adressen zuzuweisen, falls wider Erwarten keine Verbindung zu einem DHCP-Server hergestellt werden kann, der eigentlich für die automatische Zuweisung von Adressen zuständig wäre.


Vorsicht! In der Literatur zu TCP/IP wird immer wieder behauptet, die privaten Adressbereiche würden durch Router nicht weitergeleitet – als wären öffentliche Internet-Router automatisch so konfiguriert beziehungsweise nicht in der Lage, Daten mit solchen Adressen weiterzuleiten. Aber egal, wie oft Sie diese Formulierung irgendwo lesen und wie seriös die jeweilige Quelle ansonsten sein mag – es stimmt nicht. Router sind durchaus fähig, Datenpakete von solchen Adressen und auch an solche Adressen weiterzuleiten. Natürlich lässt sich dieser Umstand nicht sinnvoll nutzen, weil die Adressen nicht eindeutig sind, sondern definitionsgemäß weltweit beliebig oft zugewiesen sein können. Das Problem besteht vielmehr in einem Sicherheitsrisiko: Datenpakete, die solche Adressen aufweisen, könnten rein zufällig zu Ihrem Netzwerk passen – ein potenzieller Angreifer könnte sich einen besonders häufig genutzten Adressbereich wie das Klasse-C-Netz 192.168.0.0 aussuchen, um Pakete so aussehen zu lassen, als stammten sie aus dem lokalen Netz. Sie sollten daher eine Paketfilter-Firewall so konfigurieren, dass sie diese Pakete an den Grenzen Ihres lokalen Netzes automatisch verwirft.

Zu guter Letzt existieren noch einige Netze mit anderen speziellen Bedeutungen:

gp  Die Adresse 0.0.0.0 kann innerhalb eines Netzes verwendet werden, um sich auf das aktuelle Netz selbst zu beziehen.
gp  Das Klasse-A-Netz 127.0.0.0 beherbergt den so genannten Loopback-Bereich: Über das Loopback-Interface, eine virtuelle Netzwerkschnittstelle mit der Adresse 127.0.0.1, kann ein Host mit sich selbst Netzwerkkommunikation betreiben. Dies ist zum Beispiel nützlich, um während der Programmierung von Client-Server-Anwendungen sowohl das Client- als auch das Server-Programm auf dem lokalen Host laufen zu lassen.
gp  Schließlich wird die Adresse 255.255.255.255 als universelle Broadcast-Adresse verwendet: Ein Datenpaket, das an diese Adresse gesendet wird, wird wie beim normalen Broadcast von allen Hosts im Netzwerk empfangen. Nützlich ist diese Einrichtung für Schnittstellen, die ihre IP-Adresse dynamisch beziehen, da sie bei Inbetriebnahme in der Regel noch nicht einmal wissen, in welchem Netz sie sich eigentlich befinden. Auf diese Weise erhalten sie überhaupt erst die Möglichkeit, die Zuteilung einer Adresse anzufordern.

Die Vergabe der privaten Adressbereiche ist in RFC 1918 geregelt; die Festlegung der anderen speziellen Adressbereiche befindet sich in RFC 3330.

Supernetting, Subnetting und CIDR

In der neueren Entwicklungsgeschichte des Internets hat sich herausgestellt, dass die traditionellen Adressklassen nicht für alle Anwendungsbereiche flexibel genug sind. Deshalb wurde ein neues Schema entwickelt, das die Trennlinie zwischen Netz- und Host-Teil der Adressen an einer beliebigen Bitgrenze ermöglicht. Das in RFC 1519 beschriebene Verfahren heißt Classless Inter-Domain Routing (CIDR).

Die folgenden beiden Anwendungsbeispiele verdeutlichen typische Probleme mit der alten Klassenlogik, die mit Hilfe von CIDR gelöst werden können:

gp  Ein Unternehmen besitzt das Klasse-B-Netzwerk 139.17.0.0. Es wäre jedoch wünschenswert, wenn die vier verschiedenen Filialen des Unternehmens jeweils unabhängige Netze betreiben könnten. Dazu soll das vorhandene Netz in vier Teile unterteilt werden – ein Fall für das so genannte Subnetting.
gp  Ein vor kurzem neu gegründeter europäischer Internetprovider hat die 1.024 Klasse-C-Netze 203.16.0.0 bis 203.19.255.0 erhalten. Das Unternehmen möchte diese Netze als ein großes Netz verwalten, da dies die dynamische Zuteilung an Kunden bei der Einwahl erheblich vereinfacht. Eine solche Zusammenfassung von Netzen wird Supernetting genannt.

CIDR-Funktionsweise

Das Prinzip von CIDR basiert darauf, dass die traditionellen Byte-Grenzen zwischen Netz- und Host-Teil völlig aufgehoben werden. Deshalb ist die Größe des Netzes bei einem CIDR nicht mehr am Beginn der Adresse zu erkennen. Stattdessen wird die Anzahl der Bits, die den Netzwerk-Teil der Adresse bilden, durch einen Slash getrennt hinter der Netzwerkadresse notiert. Zum Beispiel wird das Klasse-A-Netz 14.0.0.0 zu 14.0.0.0/8.

Eine alternative Darstellungsform für die Grenze zwischen Netz- und Host-Teil bei CIDR-Adressen – insbesondere in der IP-Konfiguration der meisten Betriebssysteme – stellt die Teilnetzmaske (englisch Subnet Mask) dar. In dieser Maske werden für die Bits des Netzwerk-Teils am Anfang der Adresse Einsen notiert, für die Bits des Host-Teils am Ende der Adresse dagegen Nullen. Genau wie die IP-Adresse selbst wird auch die Teilnetzmaske in vier dezimalen 8-Bit-Blöcken geschrieben.

Tabelle 13.4 zeigt Beispiele für die Schreibweise der ursprünglichen klassenbasierten Adressen nach CIDR-Logik sowie ihre Teilnetzmasken.


Tabelle 13.4   Die traditionellen IP-Adress-Klassen in CIDR-Darstellung

Klasse Beispielnetz CIDR-Adresse Teilnetzmaske
A 17.0.0.0 17.0.0.0/8 255.0.0.0
B 167.18.0.0 167.18.0.0/16 255.255.0.0
C 195.21.92.0 195.21.92.0/24 255.255.255.0

Das Subnetting aus dem ersten Beispiel, die Unterteilung des Netzes 139.17.0.0/16 in vier gleich große Teilnetze, kann folgendermaßen durchgeführt werden:

gp  Da die 65.536 rechnerischen Adressen in vier Teile unterteilt werden sollen, sind zwei weitere Bits für den Netzwerk-Teil der Adresse erforderlich (4 = 2).
gp  Da das ursprüngliche Klasse-B-Netz einen 16 Bit (zwei Byte) langen Netzwerk-Teil besitzt, erfolgt die Unterteilung der vier Adressbereiche nach Bit 18, also nach dem zweiten Bit des dritten Bytes; die vier neuen Netze sind demnach 139.17.0.0/18, 139.17.64.0/18, 139.17.128.0/18 sowie 139.17.192.0/18.

Tabelle 13.5 zeigt die Eigenschaften der vier neuen Netze.


Tabelle 13.5   Subnetting – Unterteilung des Netzes 139.17.0.0/16 in vier gleich große Teilnetze

Netzwerk 1. Host-Adresse Letzte Host-Adresse Broadcast-Adresse Teilnetzmaske
139.17.0.0/18 139.17.0.1 139.17.63.254 139.17.63.255 255.255.192.0
139.17.64.0/18 139.17.64.1 139.17.127.254 139.17.127.255 255.255.192.0
139.17.128.0/18 139.17.128.1 139.17.191.254 139.17.191.255 255.255.192.0
139.17.192.0/18 139.17.192.1 139.17.255.254 139.17.255.255 255.255.192.0

Im zweiten Beispiel geht es um Supernetting, das heißt um die Zusammenfassung einzelner Netze zu einem größeren Gesamtnetz. Die Netze 203.16.0.0/24 bis 203.19.255.0/24 sollen zu einem einzigen Netz verbunden werden. Diese Aufgabe lässt sich auf folgende Weise lösen:

gp  Es werden 1.024 Klasse-C-Netze miteinander verbunden. 256 Netze der Klasse C würden einfach ein Gesamtnetz von der Größe eines Klasse-B-Netzwerks ergeben; beispielsweise ergäbe die Vereinigung der Netze 203.16.0.0/24 bis 203.16.255.0/24 das neue Netz 203.16.0.0/16. Um das gewünschte Netz der vierfachen Größe zu erhalten, muss die Grenze zwischen Netz- und Host-Teil um zwei Bit nach links verschoben werden.
gp  Die Adresse wird zwei Bit links von der Klasse-B-Grenze, also vor dem vorletzten Bit des zweiten Bytes, unterteilt. Daraus ergibt sich die Netzwerk-Adresse 203.16.0.0/14 mit der Teilnetzmaske 255.252.0.0.

IP-Adressraum-Umrechnung

Im Allgemeinen bietet es sich an, die Teilnetzmaske des ursprünglichen Netzes, das aufgeteilt oder mit mehreren verbunden werden soll, zunächst in die Binärdarstellung umzurechnen. In dieser Schreibweise fällt es am leichtesten, die Grenze zwischen Netz- und Host-Teil um die gewünschte Anzahl von Bits nach links oder nach rechts zu verschieben. Anschließend können Sie die Maske wieder in die vier üblichen 8-Bit-Gruppen unterteilen und in Dezimalzahlen umrechnen.

Diese Vorgehensweise soll im Folgenden an zwei neuen Beispielen demonstriert werden.

Das Klasse-B-Netzwerk 146.20.0.0/16 soll in acht Teilnetze unterteilt werden:

gp  Die ursprüngliche Netzmaske ist 255.255.0.0.
gp  In binärer Darstellung entspricht dies 11111111 11111111 00000000 00000000.
gp  Eine Aufteilung in acht Netze erfolgt durch eine Verschiebung der Grenze zwischen den beiden Adressteilen um drei Stellen (8 = 2) nach rechts.
gp  Die neue Netzmaske in binärer Schreibweise ist 11111111 11111111 11100000 00000000.
gp  Nach der erneuten Umrechnung in die dezimale Vierergruppen-Darstellung ergibt sich 255.255.224.0.
gp  Entsprechend ergeben sich die folgenden acht Netze:
146.20.0.0/19 146.20.32.0/19 146.20.64.0/19 146.20.96.0/19 146.20.128.0/19 146.20.160.0/19 146.20.192.0/19 146.20.224.0/19

Die vier Klasse-C-Netzwerke 190.16.0.0/24 bis 190.16.3.0/24 sollen zu einem gemeinsamen Netz verbunden werden:

gp  Die Teilnetzmaske der vier Netze lautet jeweils 255.255.255.0.
gp  Binär geschrieben ergibt sich daraus 11111111 11111111 11111111 00000000.
gp  Die Zusammenfassung von vier solchen Netzen erfordert eine Verschiebung der Adressgrenze um zwei Bit (4 = 2) nach links.
gp  In Binärdarstellung lautet die neue Maske 11111111 11111111 11111100 00000000.
gp  Wird diese Maske wieder in Dezimalschreibweise umgerechnet, dann resultiert daraus 255.255.252.0.
gp  Das neue Netz besitzt die CIDR-Adresse 190.16.0.0/22.

Die folgenden Tabellen zeigen in übersichtlicher Form, wie die Aufteilung der alten IP-Adressklassen in verschiedene Anzahlen von Teilnetzen funktioniert. In Tabelle 13.6 wird die Klasse A behandelt. Die – rein rechnerisch mögliche – Zusammenfassung mehrerer Klasse-A-Netze durch Supernetting wird in der Praxis nicht durchgeführt, weil erstens wohl niemand mehr als 16,7 Millionen Hosts in einem Teilnetz betreiben möchte, und zweitens alle Klasse-A-Netze an einzelne Betreiber vergeben wurden.


Tabelle 13.6   Bildung von CIDR-Teilnetzen aus einem Klasse-A-Netz

Netzwerk-Bits Host-Bits Anzahl Teilnetze Anzahl Hosts Teilnetzmaske
8 24 1 16.777.214 255.0.0.0
9 23 2 8.388.606 255.128.0.0
10 22 4 4.194.302 255.192.0.0
11 21 8 2.097.150 255.224.0.0
12 20 16 1.048.574 255.240.0.0
13 19 32 524.286 255.248.0.0
14 18 64 262.142 255.252.0.0
15 17 128 131.070 255.254.0.0
16 16 256 65.534 255.255.0.0
17 15 512 32.766 255.255.128.0
18 14 1.024 16.382 255.255.192.0
19 13 2.048 8.190 255.255.224.0
20 12 4.096 4.094 255.255.240.0
21 11 8.192 2.046 255.255.248.0
22 10 16.384 1.022 255.255.252.0
23 9 32.768 510 255.255.254.0
24 8 65.536 254 255.255.255.0
25 7 131.072 126 255.255.255.128
26 6 262.144 62 255.255.255.192
27 5 524.288 30 255.255.255.224
28 4 1.048.576 14 255.255.255.240
29 3 2.097.152 6 255.255.255.248
30 2 4.194.302 2 255.255.255.252

In Tabelle 13.7 wird die Aufteilung eines Klasse-B-Netzes in beliebig kleine Teilnetze gezeigt.


Tabelle 13.7   Bildung von CIDR-Teilnetzen aus einem Klasse-B-Netz

Netzwerk-Bits Host-Bits Anzahl Teilnetze Anzahl Hosts Teilnetzmaske
16 16 1 65.534 255.255.0.0
17 15 2 32.766 255.255.128.0
18 14 4 16.382 255.255.192.0
19 13 8 8.190 255.255.224.0
20 12 16 4.094 255.255.240.0
21 11 32 2.046 255.255.248.0
22 10 64 1.022 255.255.252.0
23 9 128 510 255.255.254.0
24 8 256 254 255.255.255.0
25 7 512 126 255.255.255.128
26 6 1.024 62 255.255.255.192
27 5 2.048 30 255.255.255.224
28 4 4.096 14 255.255.255.240
29 3 8.192 6 255.255.255.248
30 2 16.384 2 255.255.255.252

Die Tabelle 13.8 schließlich zeigt, wie die Unterteilung eines Klasse-C-Netzes erfolgt. In kleineren Unternehmen könnte es durchaus praktisch sein, ein solches – ohnehin kleines – Netzwerk weiter zu unterteilen.


Tabelle 13.8   Bildung von CIDR-Teilnetzen aus einem Klasse-C-Netz

Netzwerk-Bits Host-Bits Anzahl Teilnetze Anzahl Hosts Teilnetzmaske
24 8 1 254 255.255.255.0
25 7 2 126 255.255.255.128
26 6 4 62 255.255.255.192
27 5 8 30 255.255.255.224
28 4 16 14 255.255.255.240
29 3 32 6 255.255.255.248
30 2 64 2 255.255.255.252

In der Praxis ermöglicht CIDR bereits einen erheblich flexibleren Netzwerkaufbau als die Verwendung der alten Klassen. Doch auch diese Verfahrensweise kann immer noch ungünstige Ergebnisse zur Folge haben, wenn Teilnetze mit erheblich unterschiedlichen Größen benötigt werden: Das größte benötigte Teilnetz bestimmt die Größe aller anderen; selbst das kleinste belegt eine Menge von Adressen, die es womöglich niemals benötigen wird.

Aus diesem Grund wurde das VLSM-Konzept (Variable Length Subnet Mask) eingeführt. Es handelt sich um ein spezielles Subnetting-Verfahren, bei dem ein gegebenes Netz nicht mehr in gleich große, sondern in verschieden große Teilnetze unterteilt wird. Jedem dieser Teilnetze wird eine individuelle Teilnetzmaske zugewiesen.

VLSM-Funktionsweise

Das grundlegende Prinzip von VLSM besteht darin, vom kleinsten benötigten Teilnetz auszugehen und die entsprechenden größeren Netze aus Blöcken solcher kleinsten Teilnetze zu bilden, denen dann höhere Teilnetzmasken zugewiesen werden. Angenommen etwa, bei der Aufteilung eines Klasse-B-Netzes mit seinen 65.534 Host-Adressen besitzt das kleinste gewünschte Teilnetz 12 Hosts, das größte etwa 500. Für die 12 Hosts ist mindestens ein Netz mit der Teilnetzmaske 255.255.255.248 erforderlich, das 14 Host-Adressen bietet. Aus diesen kleinen Teilnetzen können dann entsprechend größere aufgebaut werden, wobei die Grenzen zwischen den Netzen der Logik der jeweiligen Netzmaske entsprechen müssen.

An dieser Stelle soll ein einfaches Beispiel genügen: Ein Unternehmen betreibt das öffentliche Klasse-C-Netz 196.17.41.0/24. Dieses Netz soll auf die drei Abteilungen der Firma aufgeteilt werden; die beiden Router und die drei Server sollen ein viertes separates Teilnetz bilden. Tabelle 13.9 zeigt die klassische Aufteilung des Netzes in vier gleich große Teile nach CIDR-Logik.


Tabelle 13.9   Aufteilung des Netzes 196.17.41.0/24 in vier Teile nach dem CIDR-Schema

Bereich Anzahl Hosts Teilnetz Maximale Hosts Freie Adressen
Server/Router 5 196.17.41.0/26 62 57
Verwaltung 20 196.17.41.64/26 62 42
Programmierung 61 196.17.41.128/26 62 1
Design 30 196.17.41.192/26 62 32

Es ist leicht zu erkennen, dass zwei der Teilnetze, Server/Router und Verwaltung, vollkommen überdimensioniert sind, während zumindest das Teilnetz der Programmierabteilung beinahe seine Belastungsgrenze erreicht hat. Stellen Sie sich vor, es werden noch zwei weitere Hosts in diese Abteilung aufgenommen: Schon wäre das Teilnetz zu klein, und es müsste über eine andere Verteilung nachgedacht werden. In diesem Beispiel könnte sie nur noch darin bestehen, zwei der anderen Bereiche zusammenzulegen, um den Programmiererbereich zu vergrößern.

Eine komplexere, aber für den konkreten Anwendungsfall sinnvollere Aufteilung des Netzes mit Hilfe der VLSM-Technik wird in Tabelle 13.10 gezeigt.


Tabelle 13.10   Flexible Aufteilung des Netzes 196.17.41.0/24 in vier Teile nach dem VLSM-Schema

Bereich Anzahl Hosts Teilnetz Maximale Hosts Freie Adressen
Server/Router 5 196.17.41.0/27 30 25
Verwaltung 20 196.17.41.32/27 30 10
Design 30 196.17.41.64/26 62 32
Programmierung 61 196.17.41.128/25 126 65

Für die IP-Konfiguration eines einzelnen Hosts macht es keinen Unterschied, ob das Teilnetz, in dem er sich befindet, nach der alten Klassenlogik, nach dem CIDR-Verfahren oder nach der VLSM-Methode konfiguriert wurde: In jedem Fall wird im Konfigurationsdialog des jeweiligen Betriebssystems die korrekte Teilnetzmaske eingestellt. Spezielle Unterstützung für VLSM benötigen lediglich die Router, die in dem betroffenen Netz eingesetzt werden. Die meisten neueren Routing-Protokolle bieten diese Unterstützung.

Die Übertragung von IP-Datagrammen

Auf der Vermittlungsschicht des TCP/IP-Protokollstapels, auf der das IP-Protokoll arbeitet, werden die Datenpakete als Datagramme bezeichnet. Um die Datenübertragung mit Hilfe des IP-Protokolls genau zu erläutern, soll an dieser Stelle zunächst der IP-Header vorgestellt werden. Er enthält die Steuerdaten, die das IP-Protokoll zu einem Datenpaket hinzufügt, das ihm vom übergeordneten Transportprotokoll übergeben wird.

Der IPv4-Protokoll-Header wird – wie das gesamte Protokoll – in RFC 791 definiert. Seine Länge beträgt mindestens 20 Byte, dazu können bis zu 40 Byte Optionen kommen. Tabelle 13.11 zeigt den genauen Aufbau.


Tabelle 13.11   Aufbau des IPv4-Datagramm-Headers

Byte 0 1 2 3
0 Version IHL Type of Service Paket-Gesamtlänge
4 Identifikation Flags Fragment-Offset
8 Time to Live Protokoll Header-Prüfsumme
12 Quell-Adresse
16 Ziel-Adresse
20 Optionen Padding
... evtl. weitere Optionen

Die einzelnen Daten des IP-Headers sind folgende:

gp  Version (4 Bit): die Versionsnummer des IP-Protokolls, die das Paket verwendet. Bei IPv4, wie der Name schon sagt, die Version 4.
gp  IHL (4 Bit): Internet Header Length; die Länge des Internet-Headers in 32-Bit-Worten (Zeilen in der Tabelle oben). Der kleinste mögliche Wert beträgt 5.
gp  Type of Service (8 Bit): ein Code, der die Art des Datenpakets bestimmt. Bestimmte Sorten von Paketen, etwa für den Austausch von Routing- oder Status-Informationen, werden von bestimmten Netzen bevorzugt weitergeleitet. In ihrem 1999er Aprilscherz bot die Computerzeitschrift c’t ein angebliches Tool zum Download an, das diese Quality-of-Service-Informationen manipulieren könne, um die Geschwindigkeit von Internet-Verbindungen zu erhöhen.
gp  Paket-Gesamtlänge (16 Bit): die Gesamtlänge des Datagramms in Bytes, Header und Nutzdaten.
gp  Identifikation (16 Bit): ein durch den Absender frei definierbarer Identifikationswert, der beispielsweise das Zusammensetzen fragmentierter Datagramme ermöglicht.
gp  Flags (3 Bit): Kontrollflags, die die Paketfragmentierung regeln. Das erste Bit ist reserviert und muss immer 0 sein, das zweite (DF) bestimmt, ob das Paket fragmentiert werden darf (Wert 1) oder nicht (0), das dritte (MF) regelt, ob dieses Paket das letzte Fragment (0) ist oder ob weitere Fragmente folgen (1).
gp  Fragment-Offset (13 Bit): Dieser Wert (angegeben in 64-Bit-Blöcken) legt fest, an welcher Stelle in einem Gesamtpaket dieses Paket steht, falls es sich um ein Fragment handelt. Das erste Fragment oder ein nicht fragmentiertes Paket erhält den Wert 0.
gp  Time to Live (8 Bit): Der TTL-Mechanismus sorgt dafür, dass Datagramme nicht endlos im Internet weitergeleitet werden, falls die Empfängerstation nicht gefunden wird. Jeder Router, der ein Datagramm weiterleitet, zieht von diesem Wert 1 ab; wird der Wert 0 erreicht, dann leitet der betreffende Router das Paket nicht weiter, sondern verwirft es.
gp  Protokoll (8 Bit): Die hier gespeicherte Nummer bestimmt, für welches Transportprotokoll der Inhalt des Datagramms bestimmt ist. Die beiden wichtigsten Transportprotokolle, TCP und UDP, werden im nächsten Abschnitt beschrieben.
gp  Header-Prüfsumme (16 Bit): Die Prüfsumme stellt eine einfache Plausibilitätskontrolle für den Datagramm-Header zur Verfügung. Ein Paket, dessen Header-Prüfsumme nicht korrekt ist, wird nicht akzeptiert und muss erneut versendet werden.
gp  Quelladresse und Zieladresse (je 32 Bit): die IP-Adressen von Absender und Empfänger. IP-Adressen wurden oben ausführlich behandelt.
gp  Optionen (variable Länge): Die meisten IP-Datagramme werden ohne zusätzliche Optionen versandt, da Absender- und Empfänger-Host sowie alle auf dem Weg befindlichen Router die jeweils verwendeten Optionen unterstützen müssen. Zu den verfügbaren Optionen gehören unter anderem Sicherheitsfeatures und spezielle Streaming-Funktionen.

Paket-Fragmentierung

Das Problem der Paket-Fragmentierung entsteht dadurch, dass verschiedene physikalische Netzarten unterschiedliche Maximallängen für Datenpakete erlauben. Dieser Wert, der als Maximum Transmission Unit (MTU) bezeichnet wird, kann bei einigen Netzwerkschnittstellen per Software konfiguriert werden, bei anderen ist er vom Hersteller vorgegeben. Werden nun Datagramme aus einem Netz mit einer bestimmten MTU in ein anderes Netz mit einer kleineren MTU weitergeleitet, dann müssen die Daten in kleinere Pakete »umgepackt« werden. Wie oben beschrieben, werden sie dazu mit Fragmentierungsinformationen versehen, damit sie später wieder richtig zusammengesetzt werden können.

Solange Quell- und Zieladresse im gleichen Netzwerk liegen, ist die Übertragung der Datagramme sehr einfach: Je nach Netzwerkart wird auf die passende Art und Weise (bei Ethernet zum Beispiel über ARP) die Schnittstelle ermittelt, für die die Daten bestimmt sind. Anschließend wird das Datagramm an den korrekten Empfänger übermittelt. Dieser liest den IP-Header des Pakets, setzt eventuelle Fragmente wieder richtig zusammen und übermittelt das Paket an das Transportprotokoll, dessen Nummer im Header angegeben ist. Wie der Transportdienst mit den Daten umgeht, erfahren Sie im nächsten Abschnitt.

IP-Routing

Komplizierter, aber auch interessanter wird es, wenn die Daten nicht für einen Host im lokalen Netz bestimmt sind, sondern für ein anderes Netzwerk. In diesem Fall muss das Paket an einen Router übergeben werden, der es weiterleitet. Die meisten Daten, die im Internet übertragen werden, passieren eine Vielzahl solcher Router, bis sie letztendlich ihr Ziel erreichen. Um das Konzept des IP-Routings verstehen zu können, müssen Sie verschiedene Aspekte betrachten. Insbesondere ist die Frage von Bedeutung, auf welche Art und Weise überhaupt das korrekte Empfängernetzwerk gefunden wird.

Default Gateway und »normale« Router

Bei einem einzelnen Host können üblicherweise zwei verschiedene Arten von Routern angegeben werden: zum einen die Router, die Daten in ein bestimmtes Fremdnetzwerk weiterleiten, und zum anderen der Standard-Router (meist als »Default Gateway« bezeichnet), der alle Daten entgegennimmt, die weder für das lokale Netz noch für ein Netz mit einem speziellen Router bestimmt sind.

Bei einem privaten PC, der über eine Wählleitung mit dem Internet verbunden ist, besteht in der Regel nur eine Verbindung zu einem einzelnen Router. Welcher das ist, wird jedoch bei der Einwahl in das Netzwerk des Providers bestimmt, da auch die IP-Adresse bei jeder Einwahl dynamisch zugeteilt wird. Je nachdem, welche Adresse dem Host zugeteilt wird, ist möglicherweise ein anderer Router zuständig. Deshalb wird der Router bei der IP-Konfiguration des DFÜ-Netzwerkzugangs nicht fest angegeben, sondern durch das Einwahlprotokoll (üblicherweise PPP) mitgeteilt.

Anders sieht es dagegen oft bei Workstations in Unternehmen aus, die an ein lokales Netzwerk angeschlossen sind: Sämtliche Netzwerkkommunikation, sowohl mit dem lokalen Netz als auch mit dem Internet, findet über ein und dieselbe LAN-Schnittstelle statt, meistens über Ethernet. Innerhalb des LAN besitzt der Router für die Verknüpfung zum Internet eine bekannte IP-Adresse, die bei der IP-Konfiguration des Hosts angegeben wird. Mitunter besteht die Netzwerkinfrastruktur eines größeren Unternehmens auch aus mehreren Einzelnetzen, die über interne Router miteinander vernetzt werden. In einem solchen Fall wird häufig der Router, der zu dem anderen lokalen Netz führt, als Router für dieses konkrete Netz angegeben, während der Internet-Router (dessen Zielnetz »alle anderen Netze« sind) als Standard-Router eingerichtet wird. Für diesen letzteren – Routing-technisch relativ interessanten – Fall sehen Sie hier ein Beispiel:

Routing-Beispiel

In einem Unternehmen bestehen die beiden lokalen Netze 196.87.98.0/24 und 196.87.99.0/24. Das erste Netz wird von der Grafikabteilung verwendet, das zweite von den Softwareentwicklern. In Abbildung 13.2 wird der Aufbau dieses Netzes dargestellt.

Das Netzwerk der Grafikabteilung enthält die folgenden drei Rechner:

gp  zeus (196.87.98.3)
gp  aphrodite (196.87.98.4)
gp  hermes (196.87.98.5)

Zum Netzwerk der Entwicklungsabteilung gehören die drei folgenden Hosts:

gp  newton (196.87.99.7)
gp  curie (196.87.99.8)
gp  einstein (196.87.99.9)

Abbildung 13.2   Verbindung zwischen zwei verschiedenen lokalen Netzen und dem Internet über zwei Router

Abbildung
Hier klicken, um das Bild zu Vergrößern


Zwischen den beiden lokalen Netzen befindet sich ein Router, dessen Schnittstelle im Netz der Grafikabteilung die IP-Adresse 196.87.98.1 besitzt. Seiner anderen Schnittstelle für die Entwicklungsabteilung wurde die Adresse 196.87.99.2 zugewiesen. Ein zweiter Router verbindet die Entwicklungsabteilung mit dem Internet. Seine lokale Schnittstelle wurde mit der IP-Adresse 196.87.99.1 konfiguriert; die Adresse für die Internet-Schnittstelle wird vom Internetprovider dynamisch zugewiesen.

Interessant ist nun die Routing-Konfiguration der einzelnen Hosts. Die drei Rechner im Entwickler-Netzwerk kennen zwei verschiedene Router: Der Standard-Router ist 196.87.99.1, als spezieller Router für Datenpakete an das Netz 196.87.98.0 wird 196.87.99.2 angegeben. Dagegen kennen die drei Hosts im Grafik-Netzwerk nur einen einzigen Router, nämlich 196.87.98.1, der als Standard-Router eingerichtet wird. Ob Datenpakete jenseits dieses Routers für das Netz 196.87.99.0 oder für das Internet bestimmt sind, muss der Router selbst entscheiden; die Rechner schicken ihm einfach alle Datagramme, die nicht für das lokale Netz bestimmt sind.

Angenommen »aphrodite« möchte auf Daten zugreifen, die »newton« bereitstellt. Die Daten sind offensichtlich nicht für das Netz 196.87.98.0 bestimmt, deshalb werden sie dem Router übergeben. Dieser erkennt, dass sie für das Netz 196.87.99.0 bestimmt sind, an das er unmittelbar angeschlossen ist. Er kann die Daten direkt an den Ziel-Host ausliefern.

Will dagegen »zeus« auf Daten aus dem Internet zugreifen, beispielsweise auf die Website http://www.heise.de, dann muss der Standard-Router des Grafik-Netzes erkennen, dass die Daten nicht für das andere Netz bestimmt sind, an das er selbst angeschlossen ist, und sie an den nächsten Router weiterreichen.

Ein wenig anders verhält es sich, wenn ein Rechner aus dem Entwickler-Netz wie »curie« auf »zeus« zugreifen möchte. Es ist bereits in der Routing-Konfiguration von »curie« bekannt, dass ein bestimmter Router, nämlich 196.87.99.2, zu verwenden ist. Ebenso weiß beispielsweise »einstein«, dass Zugriffe auf das Internet über den Router 196.87.99.1 erfolgen müssen.

Routing-Tabellen

Damit ein Host weiß, wohin er Datenpakete eigentlich schicken muss, um ein bestimmtes Netz zu erreichen, müssen die einzelnen Router in seiner Netzwerkkonfiguration angegeben werden – dies funktioniert je nach Betriebssystem unterschiedlich; die konkrete Vorgehensweise wird im nächsten Kapitel beschrieben. Das Ergebnis dieser Konfiguration ist eine Routing-Tabelle, die ebenfalls je nach System unterschiedlich aussieht. Angenommen, alle Rechner im oben gezeigten Beispielnetzwerk liefen unter UNIX (die Grafik-Rechner unter Mac  OS X, die Entwickler-Computer unter Linux). Dann sähe die Routing-Tabelle von »curie«, die durch den UNIX-Befehl netstat -rn angezeigt werden kann, so aus:

$ netstat -rn
Routing Tables
Destination    Gateway       Flags  Refcnt  Use    Interface
127.0.0.1      127.0.0.1     UH     1       132    lo0
196.87.99.0    196.87.99.8   U      26      49041  le0
196.87.98.0    196.87.99.2   UG     0       0      le0
default        196.87.99.1   UG     0       0      le0

Die erste Zeile (Zieladresse 127.0.0.1) beschreibt das Erreichen der Loopback-Adresse: Das Interface (Netzwerkschnittstelle) ist »lo0« (local loopback). Das Flag »H« zeigt an, dass es sich um eine Route zum Erreichen eines einzelnen Hosts handelt. Das Flag »U« dagegen steht für »Up« und bedeutet, dass die Route zurzeit intakt ist.

In der nächsten Zeile wird das lokale Netzwerk angegeben, in dem sich »curie« selbst befindet. Deshalb wird als Gateway einfach die IP-Adresse von »curie« angegeben. Das Interface »le0« ist die erste (und in diesem Fall einzige) Ethernet-Schnittstelle des Rechners.

Die dritte Zeile beschreibt die Route in das Grafik-Netzwerk über den Router, dessen Adresse im Entwickler-Netz 196.87.99.2 lautet. Das Flag »G« steht für Gateway, also für die Tatsache, dass für diese Route die Dienste eines Routers in Anspruch genommen werden.

In der letzten Zeile wird schließlich 196.87.99.1 als Default-Gateway angegeben, das heißt als Router für alle Ziele, die nicht explizit in der Routing-Tabelle auftauchen.

Die Routing-Tabelle von »hermes« sieht einfacher aus:

Routing Tables
Destination    Gateway       Flags  Refcnt  Use    Interface
127.0.0.1      127.0.0.1     UH     1       132    lo0
196.87.98.0    196.87.98.5   U      26      49041  le0
default        196.87.98.1   UG     0       0      le0

Da das Grafik-Netz nur einen Router kennt, gibt es nur den Loopback-Eintrag, die Information für das lokale Netz und schließlich den Default-Eintrag für alle anderen Netze.

Lebensdauer von
IP-Datagrammen

Auf diese Weise werden Daten durch das gesamte Internet geroutet. Jedes Mal, wenn ein Router passiert wird, erfolgt ein so genannter »Hop« der Daten. Wegen des TTL-Felds von 8 Bit Größe, das im IP-Header enthalten ist und weiter oben beschrieben wurde, erreicht ein Datagramm sein Ziel stets mit höchstens 255 Hops – oder eben gar nicht.

Damit IP-Datenpakete ihr Ziel überhaupt erreichen können, muss im Prinzip jeder einzelne Router im gesamten Internet darüber Bescheid wissen, wie er jedes beliebige Netz erreichen kann. Zu diesem Zweck unterhält auch jeder Router Routing-Tabellen, die den oben für die einzelnen Hosts gezeigten ähnlich sehen. Da das Internet ein Zusammenschluss aus vielen einzelnen Netzwerken ist, müssen diese Tabellen jedoch ständig aktualisiert werden, denn es ergeben sich häufig Konfigurationsänderungen, weil neue Netze hinzukommen oder vorhandene geändert oder aufgegeben werden. Es wäre absolut unzumutbar, diese Konfigurationsänderungen ständig manuell auf dem aktuellen Stand zu halten, was deshalb auch seit vielen Jahren nicht mehr üblich ist (außer innerhalb sehr kleiner Netze wie in dem Beispiel oben, in denen sich die Routing-Einstellungen selten ändern müssen).

Routing-Protokolle

Die Router im Internet müssen deshalb ständig Informationen darüber austauschen, an welche anderen Netzwerke sie jeweils Daten vermitteln. Es wurden eine Reihe verschiedener Routing-Protokolle entwickelt, mit deren Hilfe dies bewerkstelligt wird. Jedes dieser Routing-Protokolle besitzt andere Eigenschaften, außerdem wird nicht jedes dieser Protokolle von jedem Hersteller unterstützt.

Zunächst muss zwischen zwei verschiedenen Arten von Routing unterschieden werden: dem Routing innerhalb zusammenhängender Netze eines einzelnen Betreibers (Interior Routing), der innerhalb dieses Bereiches frei über die Konfiguration entscheiden kann, und dem Routing zwischen voneinander unabhängigen derartigen Bereichen (Exterior Routing). Alle zusammenhängenden Netze eines Betreibers werden als autonome Systeme (autonomous systems, abgekürzt AS) bezeichnet. Einige Routing-Protokolle, etwa das veraltete RIP oder das aktuellere OSPF, dienen dem Routing innerhalb von autonomen Systemen, während andere, vor allem BGP, für das Routing zwischen den Grenzen autonomer Systeme zuständig sind. Diese drei genannten Routing-Protokolle werden weiter unten kurz vorgestellt.

Wenn ein Router ein Routing-Protokoll ausführt, dann teilt er den benachbarten Routern mit, an welche Netze er Daten weiterleitet. Die meisten Routing-Protokolle machen außerdem Angaben über die »Kosten«, die für das Erreichen eines bestimmten Netzes kalkuliert werden müssen. Der Begriff »Kosten« hat nichts mit dem Preis zu tun, sondern bestimmt vor allem, über wie viele Hops ein bestimmtes Netzwerk durch den jeweiligen Router erreicht werden kann. Allerdings gibt es auch die Möglichkeit, die Kostenangaben willkürlich zu manipulieren – je nachdem, wie »gern« ein Router Daten an ein bestimmtes Netzwerk übermittelt. Wenn ein Router bestimmen muss, an welchen benachbarten Router er die Daten für ein bestimmtes Netz übergeben soll, sucht er sich denjenigen aus, der für dieses Netz geringere Kosten angibt. Diese Kostendaten werden auch als die Metrik des Routings bezeichnet.

Auf diese Weise wird versucht, die Datenströme zwischen den verschiedenen Backbone-Netzwerken möglichst gleichmäßig zu verteilen, außerdem bestehen verschiedene Arten von Verträgen oder Vereinbarungen zwischen den Netzbetreibern, was die Weiterleitung von Daten bestimmter anderer Netzwerke betrifft. Beispielsweise bestand in Deutschland in den 90er-Jahren ein mehrjähriger Streit zwischen dem Deutschen Forschungsnetz (DFN), dem Betreiber der deutschen Universitätsnetze, und den kommerziellen Internetprovidern. Es ging um die Frage, wer wem mehr Datenverkehr aus dem jeweils anderen Netz zumutete. Erst durch die Einführung neuer zentraler Datenaustauschpunkte wie dem DE-CIX konnte der Konflikt beigelegt werden.

gp  Routing Information Protocol (RIP)
Das Routing Information Protocol wird auf UNIX-Routern durch den Routing Daemon (»routed«) ausgeführt. Beim Start von »routed« wird eine Anfrage ausgesendet. Alle anderen Router, die innerhalb desselben autonomen Systems ebenfalls »routed« ausführen, beantworten diese Anfrage durch Update-Pakete. Darin sind die Zieladressen aus den Routing-Tabellen der anderen Router und deren jeweilige Metrik enthalten.
    Enthält ein Update-Paket die Routen zu Netzen, die noch gar nicht bekannt sind, dann fügt der Router sie zu seiner Routing-Tabelle hinzu. Außerdem werden Routen ersetzt, falls ein Update-Paket die Information enthält, dass ein bestimmtes Netzwerk über einen anderen Router mit geringeren Kosten zu erreichen ist.
       
    Ein Router, auf dem »routed« läuft, sendet ebenfalls Update-Pakete, und zwar in der Regel alle 30 Sekunden. Erhält ein Router von einem anderen mehrere Male keine Update-Pakete mehr (häufig beträgt die Wartezeit 180 Sekunden), dann löscht er alle Einträge aus seiner Routing-Tabelle, die diesen Router verwenden. Außerdem werden diejenigen Einträge gelöscht, deren Kosten mehr als 15 Hops betragen. Letzteres beschränkt RIP auf kleinere autonome Systeme.
       
    RIP interpretiert IP-Adressen streng nach der alten Klassen-Logik und beherrscht weder CIDR noch VLSM. Dies ist der Hauptgrund, warum es immer seltener verwendet wird.
       
    Außerdem besteht das Problem, dass durch den plötzlichen Ausfall von Routern Konfigurationsfehler entstehen können: Alle Netze, die ursprünglich nur durch den ausgefallenen Router erreicht werden konnten, können nun gar nicht mehr erreicht werden. Dies spricht sich jedoch nur allmählich herum, da ein Router zwar zunächst alle Routen entfernt, die durch den ausgefallenen Router führten, von den anderen jedoch wieder die Route zu dem Netz lernt, das nun nicht mehr erreichbar ist. Bei einem Update-Intervall von 30 Sekunden kann es recht lange dauern, bis die Router die Entfernung zu dem nicht mehr verfügbaren Netz auf die nicht mehr relevanten 16 Hops »hochgeschaukelt« haben.
       
    Um dieses Szenario zu verhindern, wird eine Technik namens Split Horizon verwendet: Ein Router bietet Routing-Informationen nicht über die Verbindung an, über die er sie gelernt hat. Eine Erweiterung dieses Verfahrens ist Poison Reverse; hier wird den Routern, von denen eine bestimmte Verbindung gelernt wurde, aktiv die »Unendlich-Metrik« 16 angegeben.
       
    Einige Probleme von RIP werden in der neueren Version RIP-2, die in RFC 1723 beschrieben wird, beseitigt; vor allem arbeitet diese Version mit CIDR-Adressierung.
       
gp  Open Shortest Path First (OSPF)
Das in RFC 2178 beschriebene Open Shortest Path First-Protokoll ist ein so genanntes Link-State-Protokoll: Der einzelne Router speichert einen gerichteten Graphen des Netzwerks aus seiner jeweiligen Sicht. Ein gerichteter Graph ist eine Art Baumdiagramm mit dem lokalen Router als Wurzel; sein Aufbau geschieht nach dem Shortest-Path-First-Algorithmus von Dijkstra: Die Kosten des lokalen Routers selbst werden mit 0 angegeben; von diesem zweigen die Routen zu den Nachbarn baumförmig ab, dann wiederum zu deren Nachbarn und so weiter. In einem zweiten Schritt wird der Link-State-Graph optimiert. Falls mehrere Routen zu einem Ziel bestehen, beispielsweise eine direkte und eine indirekte, wird jeweils die weniger kostengünstige Route entfernt.
    Um die Link-State-Datenbank klein zu halten, werden größere autonome Systeme in kleinere Einheiten unterteilt, die Areas. Nur vereinzelte Router, die so genannten Bereichsgrenzrouter, werden von den Routern innerhalb einer Area als Verbindung in andere Areas betrachtet.
       
    Ein OSPF-Router gewinnt seine Erkenntnisse über die benachbarten Router, indem er so genannte Hello-Pakete aussendet. Diese enthalten seine eigene Adresse und die Information, von welchen benachbarten Routern er bereits Routing-Daten erhalten hat. Ein Router, der ein Hello-Paket erhält, trägt den Absender dieses Pakets als Nachbarn in seinen eigenen Link-State-Graphen ein. Die Hello-Pakete werden in regelmäßigen Abständen ausgesandt, um den Nachbarn mitzuteilen, dass der Router noch bereit ist. Erhält ein Router keine weiteren Pakete von einem bestimmten Nachbarn, geht er davon aus, dass dieser nicht mehr zur Verfügung steht, entfernt ihn aus seiner Link-State-Datenbank und informiert das Netzwerk darüber.
       
    OSPF-Router geben Daten über ihre Nachbarn an das gesamte Netzwerk weiter, indem sie Link State Advertisements (LSA) über alle ihre Netzwerkschnittstellen versenden. Der Empfänger eines LSA-Pakets leitet es weiter, indem er es ebenfalls über alle seine Schnittstellen versendet – mit Ausnahme derjenigen, über die er es empfangen hat. Dieses Verfahren der schnellen Verbreitung von Informationen über ein Netzwerk wird als Flooding bezeichnet.
       
gp  Border Gateway Protocol (BGP)
Anders als bei den beiden oben behandelten Routing-Protokollen handelt es sich beim Border Gateway Protocol um ein externes Routing-Protokoll, das Verbindungen zwischen verschiedenen autonomen Systemen regelt. Vom Standpunkt des externen Routings aus erscheinen die autonomen Systeme selbst als in sich geschlossene Gebilde, die nicht näher differenziert werden. BGP wird nur von den Bereichsgrenzroutern der autonomen Systeme ausgeführt, also in der Regel lediglich bei Internetprovidern oder großen Backbone-Netzbetreibern. Die meisten Firmennetze sind dagegen Teil eines autonomen Systems, das von einem Provider betrieben wird, führen also lediglich interne Routing-Protokolle wie OSPF aus.
    Die benachbarten BGP-Router, Peers genannt, kommunizieren über eine zuverlässige TCP-Verbindung, die über den dafür vorgesehenen TCP-Port 179 abgewickelt wird. Es wird stets eine vollständige Route mit allen ihren Knotenpunkten angegeben. Dies unterscheidet BGP von den meisten internen Routing-Protokollen, die nur die Verbindungen zu ihren unmittelbaren Nachbarn angeben. Aus diesem Grund wird BGP als Pfadvektor-Protokoll bezeichnet.
       
    Wird das erste Mal eine Verbindung zu einem Peer hergestellt, dann werden über so genannte UPDATE-Pakete die vollständigen Routing-Tabellen ausgetauscht, danach werden nur noch Änderungen mitgeteilt. Außerdem werden in regelmäßigen Abständen KEEPALIVE-Pakete versandt, falls keine Änderungen vorliegen, um den Peers mitzuteilen, dass der Router noch einsatzbereit ist.
       

Weitere IP-Dienste

In fast allen modernen TCP/IP-Netzwerken – insbesondere in lokalen Firmennetzen, die mit dem Internet verbunden sind – spielen zwei weitere Protokolle eine wichtige Rolle: Das DHCP dient dazu, den Rechnern im Netzwerk automatisch IP-Adressen zuzuweisen, während das NAT-Protokoll meist vom Standard-Router ausgeführt wird und die im Internet unbrauchbaren privaten IP-Adressen mit öffentlichen überschreibt und umgekehrt. Diese beiden Protokolle sollen hier näher vorgestellt werden.

DHCP

Das in den RFCs 2131 und 2132 definierte Dynamic Host Configuration Protocol (DHCP) dient dazu, einem Host automatisch TCP/IP-Konfigurationsdaten zuzuweisen. Es ist eine Erweiterung des älteren Bootstrap Protocol (BOOTP). Ein Host, der seine Netzwerkparameter über DHCP beziehen möchte, sendet bei Inbetriebnahme eine Broadcast-Anfrage namens BOOTREQUEST an die allgemeine Broadcast-Adresse 255.255.255.255. Der Rechner muss also noch nicht einmal wissen, in welchem Netzwerk er sich befindet – das ist beispielsweise ideal für ein Notebook, das manchmal an ein Heim- und manchmal an ein Büro-Netzwerk angeschlossen wird. Läuft in dem Netz ein DHCP-Server, dann antwortet er mit einem Satz von Konfigurationsparametern, mit denen der Host seine TCP/IP-Konfiguration durchführt.

Das wichtigste Merkmal von DHCP besteht in der dynamischen Vergabe von IP-Adressen, die Netzwerkadministratoren das Leben erheblich erleichtert, insbesondere in solchen Netzwerken, in denen häufig Änderungen auftreten. Diese automatische Vergabe erfolgt in Form einer »Lease« (Pacht) mit beschränkter Gültigkeit. Ein Host, der ordnungsgemäß vom Netz abgemeldet wird (ein normaler Vorgang beim Herunterfahren moderner Betriebssysteme), gibt seine IP-Adresse selbst an den DHCP-Server zurück. Das Lease-Verfahren sorgt dagegen dafür, dass IP-Adressen auch dann wieder für den Server verfügbar werden, wenn ein Host unerwartet vom Netz getrennt oder unsachgemäß abgeschaltet wird. Bleibt ein Rechner über den Lease-Zeitraum hinaus im Netz aktiv, dann erfolgt in der Regel eine Verlängerung der Lease.

Auf dem DHCP-Server muss ein Teil der Adressen des Netzwerks, in dem er sich befindet, als DHCP-Pool konfiguriert werden, aus dem die Adressen automatisch an die anfragenden DHCP-Clients vergeben werden. Es muss darauf geachtet werden, genügend Adressen aus diesem Pool auszuschließen, weil eine Reihe von Internetdiensten eine feste IP-Adresse benötigt oder zumindest besser damit funktioniert.

NAT

Network Address Translation (NAT) ist eine relativ neue Entwicklung und löst dementsprechend ein modernes Problem: Immer mehr Netzwerke benötigen permanenten oder auch nur temporären Zugang zum Internet, obwohl sie mit den weiter oben vorgestellten privaten IP-Adressen konfiguriert wurden. Es wäre bei der heutigen Anzahl von Internet-Hosts und angeschlossenen Netzen auch gar nicht mehr möglich, allen angeschlossenen Netzwerken öffentliche IP-Adressen zuzuweisen. Da die privaten IP-Adressen jedoch nicht eindeutig sind, müssen sie beim Übergang ins Internet mit einer öffentlichen Adresse überschrieben werden und umgekehrt.

Eine aktuelle Form von NAT, die im Kernel moderner UNIX-Systeme konfiguriert werden kann, wird auch als IP-Masquerading bezeichnet und geht noch einen Schritt weiter als NAT allgemein: Es ist nur eine externe IP-Adresse erforderlich; alle lokalen Adressen werden auf diese eine Adresse abgebildet. Unterschieden werden die Rechner in diesem Fall anhand der Client-Portnummer der Datenpakete, die zur Transportebene gehört und in Abschnitt 17.3.2 näher beschrieben wird. Aus diesem Grund wird das echte Masquerading manchmal auch als PAT (Port Address Translation) bezeichnet. Diese spezielle Form von NAT verbirgt die Details des internen Netzwerks vor dem Internet, die einzelnen Rechner sind von außen nicht erreichbar. Dies ist ein angenehmer Nebeneffekt dieses Verfahrens, der zusätzlich der Sicherheit im Netzwerk dient.

Tabelle 13.12 zeigt ein Beispiel für klassisches NAT in einem privaten Netzwerk mit der Adresse 192.168.1.0/24. Jede interne IP-Adresse wird auf eine individuelle externe Adresse abgebildet.


Tabelle 13.12   Beispiel für klassisches NAT

Hostname Interne IP-Adresse Externe IP-Adresse
gandalf 192.168.1.4 204.81.92.6
frodo 192.168.1.5 204.81.92.3
bilbo 192.168.1.6 204.81.92.5

In Tabelle 13.13 wird dagegen für dasselbe Netzwerk ein Beispiel für IP-Masquerading (PAT) gezeigt. Das Konzept der Portnummern wird weiter unten genauer beschrieben.


Tabelle 13.13   Beispiel für IP-Masquerading

Hostname Interne IP-Adresse Externe IP-Adresse Externe Portnummer
gandalf 192.168.1.4 204.81.92.4 22.191
frodo 192.168.1.5 22.192
bilbo 192.168.1.6 22.193

Der Rechner, der NAT ausführt, ist üblicherweise der Router, der das lokale Netz mit dem Netzwerk eines Providers und demzufolge mit dem Internet verbindet. NAT wird von allen gängigen UNIX-Versionen sowie von Windows NT und seinen Nachfolgern unterstützt. Außerdem können die meisten ISDN- oder DSL-Kompakt-Router NAT ausführen. Eine nähere Beschreibung vieler Aspekte von NAT befindet sich in RFC 3022.

IPv6

Bereits vor zehn Jahren wurde damit gerechnet, dass sehr bald keine weiteren IPv4-Adressen mehr verfügbar sein würden. Dass dies bisher noch immer nicht der Fall ist, liegt an der Einführung von CIDR, VLSM und NAT. Da das Internet aber weiterhin wächst, ist es nur noch eine Frage der Zeit, bis die Anzahl der Adressen endgültig erschöpft ist.

IPv6-Motivation

Deshalb wurde schon vor einigen Jahren mit der Arbeit an einem Nachfolger für das IPv4-Protokoll gearbeitet, das vor allem einen größeren Adressraum durch längere IP-Adressen besitzen sollte. Letzten Endes entschieden die Entwickler sich für Adressen von 128 Bit Länge. Dies ergibt theoretisch mehr als 3,4 * 1038  verschiedene Adressen! Damit erscheint der Adressraum mehr als überdimensioniert; offensichtlich kann man damit jedem einzelnen Sandkorn auf unserem Planeten mehrere eigene IP-Adressen zuweisen. Letzten Endes geht es allerdings eher darum, beinahe beliebig viele Netze von sehr unterschiedlicher Größe einrichten zu können, und abgesehen davon werden immer mehr tragbare, spezialisierte Geräte entwickelt, die mit Netzwerken verbunden werden – etwa dynamisch über öffentliche WLAN-Access-Points.

Die aktuelle Version des neuen IP-Protokolls wird in RFC 2460 beschrieben. Da die Version 5 für Experimente mit Multicasting verwendet wurde, lautet die Versionsnummer des Protokolls IPv6; während seiner Entwicklung wurde es auch manchmal als IPng (für »next generation«) bezeichnet, zum Beispiel in RFC 1752, das den ersten Arbeitsentwurf beschreibt. Die IPv6-Adresse wird nicht in 8-Bit-Dezimalgruppen geschrieben wie bei IPv4; mit 16 Gruppen wäre sie ein wenig unhandlich. Stattdessen schreibt man 8 vierstellige Hexadezimalgruppen, die durch Doppelpunkte getrennt werden. Eine IPv6-Adresse sieht zum Beispiel folgendermaßen aus: 4A29:30B4:0031: 0000:0000:0092:1A3B:3394. Eine zulässige Verkürzung besteht darin, führende Nullen in einem Block wegzulassen sowie Blöcke, die nur aus Nullen bestehen, durch zwei aufeinander folgende Doppelpunkte zu ersetzen. Kurz gefasst lautet die Beispieladresse also 4A29:30B4:31::92:1A3B:3394. Um die Adresse eindeutig zu halten, darf diese Verkürzung innerhalb einer Adresse nur einmal durchgeführt werden.

Aufbau von IPv6-Adressen

Genau wie IPv4-Adressen werden auch die neuen IPv6-Adressen in zwei Teile unterteilt: Links steht ein Präfix, dahinter ein Individualteil, der dem Host-Teil der IPv4-Adresse entspricht. Das Präfix gibt allerdings nicht das einzelne Netz an, zu dem die Adresse gehört, sondern informiert über den Adresstyp. Da die Präfixe wie bei IPv4 unterschiedliche Längen aufweisen können, wird das Präfix zusammen mit seiner Bit-Anzahl angegeben. Tabelle 13.14 gibt einen Überblick über die verschiedenen Adressblöcke und ihre Verwendung.


Tabelle 13.14   IPv6-Adressbereiche und -Präfixe

Präfix Verwendung
0::0/8 reserviert für spezielle Anwendungen
100::0/8 noch nicht zugeordnet
200::0/7 Abbildung von NSAP-Adressen
400::0/7 Abbildung von IPX-Adressen
600::0/7 noch nicht zugeordnet
800::0/5 noch nicht zugeordnet
1000::0/4 noch nicht zugeordnet
2000::0/3 global eindeutige Adressen
6000::0/3 noch nicht zugeordnet
8000::0/3 noch nicht zugeordnet
A000::0/3 noch nicht zugeordnet
C000::0/3 noch nicht zugeordnet
E000::0/4 noch nicht zugeordnet
F000::0/5 noch nicht zugeordnet
F800::0/6 noch nicht zugeordnet
FE00::0/7 noch nicht zugeordnet
FE00::0/9 noch nicht zugeordnet
FE80::0/10 auf eine Verbindung begrenzte Adressen
FEC0::0/10 auf eine Einrichtung begrenzte Adressen
FF00::0/8 Multicast-Adressen

Die typischste Form von IPv6-Adressen, deren Stil am ehesten den öffentlich gerouteten IPv4-Adressen entspricht, ist die globale Unicast-Adresse. Ihre Struktur ist in RFC 2374 festgelegt und sieht folgendermaßen aus:

gp  Externes Routing-Präfix (48 Bit)
gp  Site-Topologie (üblicherweise 16 Bit)
gp  Schnittstellen-Identifikationsnummer (normalerweise 64 Bit). Sie wird in der Regel automatisch generiert, oft aus der bisherigen IPv4-Adresse.

Der IPv6-Datagramm-Header wurde gegenüber dem IPv4-Header erheblich vereinfacht. Durch die Auslagerung eventueller Optionen in so genannte Erweiterungs-Header wird die Länge des Basis-Headers auf genau 320 Bit (40 Byte) festgelegt; einige Felder des IPv4-Headers wurden entfernt, weil sie keine Bedeutung mehr haben. Tabelle 13.15 zeigt den genauen Aufbau des IPv6-Headers.


Tabelle 13.15   Aufbau des IPv6-Datagramm-Headers

Byte 0 1 2 3
0 Version Klasse Flow Label
4 Payload Length Next Header Hop Limit
8 Quell-Adresse
12
16
20          
24 Ziel-Adresse
28
32
36          

Hier die Bedeutung der einzelnen Felder des Headers:

gp  Version (4 Bit): die Versionsnummer des IP-Protokolls; hier natürlich 6.
gp  Klasse (8 Bit): Dieses Feld gibt die Priorität an, mit der das Datagramm übertragen werden soll. Es ist noch nicht abschließend geklärt, wie die entsprechenden Werte aussehen sollen.
gp  Flow Label (20 Bit): ein Erweiterungsfeld, in das ein von 0 verschiedener Wert eingetragen wird, wenn IPv6-Router das Datagramm auf besondere Weise behandeln sollen. Es dient vor allem der Implementierung der Quality-of-Service-Funktionalität, mit deren Hilfe Paketsorten voneinander unterschieden werden, um beispielsweise Echtzeitanwendungen wie Streaming Multimedia oder Videokonferenzen zu unterstützen.
gp  Payload Length (16 Bit): die Länge der Nutzdaten, die auf den Header folgen.
gp  Next Header (8 Bit): Der Wert in diesem Feld gibt den Typ des ersten Erweiterungs-Headers an, falls einer vorhanden ist. Es gibt bisher sechs Arten von Erweiterungs-Headern; eine Übersicht finden Sie in Tabelle 13.16.
gp  Hop Limit (8 Bit): ein neuer Name für die Time-to-Live-Funktionalität: Jeder Router zieht von dem ursprünglichen Wert 1 ab; bei Erreichen des Wertes 0 wird das Paket verworfen.
gp  Quell- und Zieladresse (je 128 Bit): die Adresse des Absenders und des Empfängers; genau wie bei IPv4, nur entsprechend der Protokollspezifikation 128 statt 32 Bit lang.

Tabelle 13.16   Die verschiedenen Typen von IPv6-Erweiterungs-Headern

Header Next-Header-Code Beschreibung
Hop-by-Hop Options Header 0 Optionen, die bei jedem Routing-Schritt ausgeführt werden müssen
Routing Header 43 Festlegung der Router, über die das Paket geleitet werden soll
Fragment Header 44 Der Absender muss bei IPv6 die MTU herausfinden und Fragmente selbst bilden; die Fragment-Informationen befinden sich hier
Authentication Header 51 Authentifizierung des Absenders gegenüber dem Empfänger
Encapsulating Security Payload Header 50 Dient der Verschlüsselung des Datagramms (IPv6)
Destination Options Header 60 Optionen, die nur für den Ziel-Host bestimmt sind
Upper-Layer Header 59 Header einer höheren Schicht; aus IPv6-Sicht also Nutzdaten

IPv6-Migration

Das größte Problem, das der sofortigen Einführung von IPv6 noch im Wege steht, ist ein organisatorisches: Zum einen kann man nicht einfach über Nacht flächendeckend umsteigen, da in diesem Fall die IP-Treiber aller Hosts und Router weltweit gewechselt werden müssten, was vollkommen illusorisch ist – zumal viele ältere Hardwarekomponenten, Betriebssysteme und Programme IPv6 gar nicht unterstützen und ihre Hersteller auch nicht vorhaben, diese Unterstützung nachträglich zu implementieren. Zum anderen ist es aber auch nicht möglich, gleichzeitig einen Teil des Internets mit IPv4 und einen anderen mit IPv6 zu betreiben und auf diese Weise allmählich auf die neue Version umzusteigen, da die beiden Adressierungsschemata zueinander inkompatibel sind.

Die Lösung, die letzten Endes gefunden wurde, besteht in der Tunnelung von IPv6-Paketen durch das klassische IPv4-Netzwerk. Tunnelung bedeutet letzten Endes nichts anderes, als dass jedes IPv6-Datagramm in ein IPv4-Datagramm verpackt wird; das heißt, das IPv6-Paket bildet aus der Sicht des IPv4-Pakets die Nutzdaten, die mit einem v4-Header versehen werden. Am jeweiligen Zielpunkt, an dem wiederum IPv6 verfügbar ist, wird das Version-4-Datagramm »ausgepackt« und den Header-Daten entsprechend weiterverarbeitet.

IPv6-Tunnel-Dienste werden mittlerweile auch von mehreren kommerziellen und verschiedenen freien Anbietern, den Tunnel-Brokern, zur Verfügung gestellt. Einer der größten derartigen Dienste ist das 6Bone-Projekt. Nähere Informationen erhalten Sie auf der Website des Projekts unter http://www.6bone.net.


Galileo Computing

13.3.2 Transportprotokolle  downtop

Eine Anwendung, die Daten über ein TCP/IP-Netzwerk wie das Internet übertragen möchte, beauftragt zu diesem Zweck ein Transportprotokoll, also ein Protokoll der Host-zu-Host-Transportschicht des Internet-Schichtenmodells. Nachdem im vorigen Abschnitt das IP-Routing erläutert wurde, sollten Sie auch verstehen, warum der Vorgang als Host-zu-Host-Transport bezeichnet wird: Router betrachten von den Datenpaketen, die sie weiterleiten sollen, immer nur den IP-Header und werten dessen Informationen aus. Aus der Sicht des IP-Protokolls existieren die Daten der Transportschicht nicht. Umgekehrt ist also das Routing ein Implementierungsdetail, das für die Protokolle der Transportschicht nicht sichtbar ist. Aus ihrer Sicht kann der Ziel-Host immer unmittelbar erreicht werden.

TCP kontra UDP

Um den Bedürfnissen verschiedener Anwendungen gerecht zu werden, wurden zwei verschiedene wichtige Transportprotokolle definiert. Das häufiger verwendete TCP-Protokoll, das einen Teil des Namens der Protokollfamilie ausmacht, stellt den zuverlässigen Transport von Datenpaketen in einer definierten Reihenfolge zur Verfügung. Dagegen bietet das UDP-Protokoll die Möglichkeit, Daten auf Kosten der Zuverlässigkeit möglichst schnell zu transportieren.

Ein wenig zwischen Vermittlungs- und Transportschicht liegt das ICMP-Protokoll (Internet Control Message Protocol), das für den Versand spezieller Datagramme verwendet wird, mit deren Hilfe überprüft werden kann, ob ein entfernter Host im Netzwerk aktiv ist. Das entsprechende Dienstprogramm heißt ping und wird im nächsten Kapitel vorgestellt.

Die beiden Protokolle werden in den folgenden Unterabschnitten genauer beschrieben.

Das Transmission Control Protocol (TCP)

Wie Sie im vorigen Abschnitt erfahren haben, werden IP-Datagramme jeweils individuell durch das Netzwerk geleitet. Deshalb kann auf der Basis von Datagrammen kein zuverlässiger Transport kontinuierlicher Datenströme stattfinden, weil es vollkommen normal ist, dass Datagramme nicht in der Reihenfolge ankommen, in der sie abgeschickt wurden. Außerdem ist es auch gut möglich, dass sie gar nicht ankommen, weil auf der Ebene des IP-Protokolls keine entsprechende Kontrolle durchgeführt wird.

TCP-Funktionsweise

Um nun über den potenziell unsicheren Weg der IP-Datagramme Daten zuverlässig durch das Netzwerk zu transportieren, wird auf dieser höher gelegenen Ebene eine Flusskontrolle implementiert: Im Wesentlichen werden die Datenpakete durch das TCP-Protokoll durchnummeriert, um die korrekte Reihenfolge aufrecht zu erhalten. Im Übrigen erwartet der ursprüngliche Absender für jedes einzelne Datenpaket eine Bestätigung; bleibt sie zu lange aus, dann versendet der Absender das entsprechende Paket einfach erneut.

Als Erstes sollten Sie sich den TCP-Paket-Header ansehen, der in Tabelle 13.17 gezeigt wird.


Tabelle 13.17   Aufbau des TCP-Datenpaket-Headers

Byte 0 1 2 3
0 Quell-Port Ziel-Port
4 Sequenznummer
8 Bestätigungsnummer
12 Offset Reserviert Flags Fenster
16 Prüfsumme Urgent-Zeiger
20 Optionen Padding

Ein TCP-Datenpaket besteht aus den folgenden Bestandteilen:

gp  Quell-Port (16 Bit): Ports stellen eine Methode zur Identifikation der konkreten Anwendungen zur Verfügung, die auf den beteiligten Hosts miteinander kommunizieren. Der Quell-Port ist die Portnummer des Absenders.
gp  Ziel-Port (16 Bit): Dies ist entsprechend die Portnummer des Empfängers.
gp  Sequenznummer (32 Bit): Normalerweise gibt diese Nummer an, dem wie vielten Byte der zu übertragenden Sequenz das erste Nutzdaten-Byte des Pakets entspricht. Ausnahme: Ist das SYN-Flag gesetzt, so wird die Anfangs-Sequenznummer (Initial Sequence Number, ISN) angegeben.
gp  Bestätigungsnummer (32 Bit): Das Startbyte der Sequenz, deren Übertragung als Nächstes erwartet wird; ist nur bei gesetztem ACK-Bit von Bedeutung.
gp  Offset (4 Bit): Anzahl der 32-Bit-Wörter, aus denen der Header besteht; gibt entsprechend den Beginn der Nutzdaten im Paket an.
gp  Reserviert (6 Bit): reserviert für zukünftige Anwendungen; muss 0 sein.
gp  Flags (6 Bit): verschiedene Statusbits; im Einzelnen:
URG: Urgent Data wird versandt; der Inhalt des Urgent-Zeigers muss beachtet werden. ACK: Acknowledgment – das Bestätigungsfeld muss berücksichtigt werden. PSH: Push-Funktion – ist dieses Bit gesetzt, dann wird die Pufferung des Pakets verhindert; es wird unmittelbar gesendet. RST: Reset – Verbindung zurücksetzen SYN: Sequenznummern synchronisieren FIN: Ende der Sequenz; keine weiteren Daten vom Absender
gp  Fenster (16 Bit): die Anzahl von Datenbytes, die der Absender des Pakets zu empfangen bereit ist; basiert unter anderem auf der IP-MTU der verwendeten Schnittstelle.
gp  Prüfsumme (16 Bit): Anhand dieser einfacheren Plausibilitätskontrolle kann die Korrektheit der übertragenen Daten überprüft werden.
gp  Urgent-Zeiger (16 Bit): ein Zeiger auf das Byte der aktuellen Sequenz, das Urgent Data enthält. Wird nur ausgewertet, wenn das URG-Flag gesetzt ist.
gp  Optionen (variable Länge): verschiedene hersteller- und implementierungsabhängige Zusatzinformationen; stets ein Vielfaches von 8 Bit lang.

Der TCP-Verbindungsaufbau

Zwischen den beiden Hosts, die über TCP kommunizieren, wird eine virtuelle Punkt-zu-Punkt-Verbindung hergestellt; aus diesem Grund wird TCP auch als verbindungsorientiertes Protokoll bezeichnet. Dies ermöglicht den Transport eines kontinuierlichen Datenstroms über die potenziell unzuverlässigen IP-Datagramme, in die die TCP-Pakete verpackt werden. Um die Datenübertragung einzuleiten, findet zunächst ein so genannter Drei-Wege-Handshake statt: Drei spezielle Datenpakete ohne Nutzdateninhalt werden ausgetauscht. Der Host, der die Verbindung initiiert, sendet ein Paket mit gesetztem SYN-Bit an den Empfänger. Dieser schickt ein Paket zurück, bei dem SYN und ACK gesetzt sind, und erwartet wiederum eine Antwort, bei der nur das ACK-Flag gesetzt ist. Erst nachdem dies geschehen ist, beginnt die eigentliche Übertragung von Nutzdaten. Dieses Vorgehen garantiert, dass beide Hosts bereit sind, miteinander zu kommunizieren.

Anschließend sendet der Absender ein Paket nach dem anderen an den Empfänger-Host, wobei die Sequenznummer stets um die im vorigen Paket versandte Nutzdatenmenge erhöht wird. Der Empfänger beantwortet jedes empfangene Paket, dessen Prüfsumme mit dem Inhalt übereinstimmt, mit einem Bestätigungspaket, dessen ACK-Flag also gesetzt ist. Der Wert des Bestätigungsfelds ist der Byte-Offset der nächsten Datensequenz, die der Empfänger erwartet, ist also die Summe aus Sequenznummer und Nutzdatenlänge des soeben empfangenen Pakets.

Erhält der Absender die Bestätigung nicht innerhalb einer definierten Zeit (Timeout), so sendet er das entsprechende Paket unaufgefordert erneut. Dieses Verfahren wird positive Bestätigung (positive acknowledgement) genannt, da lediglich der Erfolg gemeldet wird; von einem Misserfolg wird automatisch ausgegangen, wenn keine Meldung erfolgt. Dieses Verfahren ist zuverlässiger als das Arbeiten mit Misserfolgsmeldungen: Kommt die Erfolgsmeldung nicht an, so wird das Paket einfach erneut versandt, ansonsten gibt es aber keine schädlichen Folgen (außer dem geringen Mehraufwand für ein überflüssig versandtes Paket, falls einmal lediglich die Bestätigung verloren gegangen ist). Käme dagegen eine Misserfolgsmeldung nicht an, so würde das betreffende Paket nicht erneut versandt und würde den Empfänger niemals erreichen.

TCP-Ports

Ein weiterer wichtiger Bestandteil von TCP-Paketen sind die beiden 16 Bits langen Portnummern. Jedes Paket kann anhand des Portnummern-Paares als zu einer bestimmten Sequenz und Anwendung gehörig identifiziert werden. Das ist auch absolut notwendig: Stellen Sie sich vor, Sie haben zwei Browserfenster geöffnet; in beiden werden gleichzeitig verschiedene Seiten von www.galileo-computing.de geladen. Anhand der IP-Adressen können die beiden Datenübertragungen nicht voneinander unterschieden werden, da die beiden Hosts, die hier miteinander kommunizieren, identisch sind. Es könnte also sehr leicht passieren, dass die Daten fehlerhaft zugeordnet werden und Sie zwei seltsame Mischungen der beiden Dokumente erhalten – ein Effekt wie in dem Horror-Klassiker »Die Fliege«!

Dieses Szenario kann deshalb nicht eintreten, weil die beiden Datenübertragungen nicht über dasselbe Paar von Portnummern erfolgen. In der Regel ist die Portnummer des Servers festgelegt, während der Client irgendeinen Port wählt, der gerade frei ist. Die untersten 1.024 Portnummern sind als so genannte »Well-Known Ports« für Standard-Serverdienste fest vergeben; für Clients wird eine zufällige Nummer (ein so genannter »Ephemeral Port«) zwischen 1.024 und 65.535 verwendet. Beispielsweise benutzen Webserver, also HTTP-Server, üblicherweise den TCP-Port 80, FTP-Server den Port 21 und TELNET-Server den Port 23. Eine kleine Liste, die auch UDP betrifft, finden Sie weiter unten in Tabelle 13.18.

In dem Beispiel mit den beiden Browserfenstern ist der Server-Port jeweils 80; die Client-Ports sind dagegen unterschiedlich, beispielsweise 16832 und 16723. Dies ist eine Verdeutlichung der Formulierung, dass nur die Port-Paare und nicht beide einzelnen Ports unterschiedlich sein müssen, um Sequenzen voneinander abzugrenzen.

Gewöhnlich »lauscht« ein TCP-Serverdienst an seinem speziellen Port auf ankommende Verbindungsversuche. Unternimmt ein Client den Versuch, eine TCP-Verbindung mit dieser speziellen Portnummer als Empfänger-Port und einer zufälligen Nummer als Absender herzustellen, dann akzeptiert der Server dies nach den Regeln des Drei-Wege-Handshakes; eine Verbindung für den gegenseitigen Datenaustausch ist hergestellt.

TCP Urgent Data

Interessant ist zu guter Letzt das Thema Urgent Data: Manchmal muss ein Host einen anderen über einen besonderen Zustand informieren, beispielsweise eine Konfigurationsänderung oder einen vom Benutzer initiierten Abbruch mitteilen. Zu diesem Zweck wird das URG-Flag gesetzt; der Empfänger ermittelt daraufhin aus dem Urgent-Zeiger-Feld des Paket-Headers die Bytenummer innerhalb der Sequenz, in der sich diese dringlichen Daten befinden. Es handelt sich stets nur um ein einziges Byte, das auch als »Out of Bound-Byte« bezeichnet wird, weil es nicht zum gewöhnlichen Datenstrom gehört. Es ist also unmöglich, auf diesem Weg eine längere dringende Mitteilung zu versenden, aber immerhin besteht die Möglichkeit, verschiedene vereinbarte Signale zu versenden.

Das User Datagram Protocol (UDP)

Manche Anwendungen möchten auf den Komfort und die Sicherheit von TCP getrost verzichten, wenn sie die Daten dafür schneller ans Ziel befördern können. Die Möglichkeit eines solchen möglichst schnellen Versandes bietet das UDP-Protokoll. Ob eine Anwendung für ihre Datenübertragung nun TCP, UDP oder beide verwenden möchte, entscheidet sie selbst.

Ein UDP-Anwendungsbeispiel

Stellen Sie sich als Beispiel ein Netzwerkspiel vor, eine virtuelle 3-D-Umgebung, in der Sie gegen Ihre Mitspieler »kämpfen« können. Ein solches Spiel ist ideal für die Erklärung des Nutzens beider Übertragungsarten geeignet: Bestimmte grundlegende Konfigurationsdaten (Lebt der Gegner überhaupt noch? Hat er auf mich geschossen?) sind entscheidend für den eigentlichen Spielverlauf und sollten deshalb zuverlässig über TCP übertragen werden. Dagegen sind bestimmte Details (Pose und Gesichtsausdruck der gegnerischen Spielfigur; die Position von Gegnern außerhalb unseres »Gesichtsfelds« usw.) nicht so wichtig. Wenn überhaupt, sollten sie möglichst schnell übertragen werden. Fallen sie vorübergehend aus, schadet das auch nichts – ideale Kandidaten für die Übertragung mit Hilfe des schnelleren, aber weniger zuverlässigen UDP-Protokolls.

Der Hauptgrund, warum sich Daten über UDP schneller übertragen lassen als mittels TCP, ist der erheblich kleinere und weniger komplexe Paket-Header. Der Aufbau dieses Headers, der gerade einmal (unveränderlich) 64 Bit groß ist, wird in Tabelle 13.18 dargestellt.


Tabelle 13.18   Aufbau des UDP-Headers

Byte 0 1 2 3
0 Quell-Port Ziel-Port
4 Länge Prüfsumme

Die einzelnen Header-Felder haben dieselbe Bedeutung wie die gleichnamigen Felder beim TCP-Protokoll. Mit der Länge ist hier die Länge des gesamten Pakets inklusive diesem Header gemeint. Der Quell-Port wird häufig einfach auf 0 gesetzt: Da UDP dem schnellen Versand einer einzelnen Nachricht dient, auf die in der Regel keine Antwort erwartet wird, ist es nicht nötig, diese Information festzulegen. Der Ziel-Port ist dagegen meist der festgelegte Port des UDP-Servers, an den das Paket verschickt wird. UDP wird für viele einfache Internetdienste verwendet: die Uhrzeitsynchronisation über ein Netzwerk, den Echo-Dienst zur Kontrolle der Funktionstüchtigkeit von Verbindungen oder entfernten Hosts und so weiter.

Im Gegensatz zu dem verbindungsorientierten TCP wird UDP als nachrichtenorientiertes Protokoll bezeichnet, da es dem schnellen, verbindungslosen Versand einzelner Pakete in Form kurzer Meldungen dient. Dies erklärt auch den Namen des Protokolls: Einer Anwendung, die von diesem Transportdienst Gebrauch macht, wird der unmittelbare und leichtgewichtige Zugriff auf IP-Datagramme ermöglicht.

Die Portnummern für gängige Serverdienste (bei UDP spricht man häufig auch von Servicenummern) liegen wie bei TCP zwischen 0 und 1.023. Sie werden genau wie öffentliche IP-Adressen von der IANA vergeben. In der Regel wird dieselbe Portnummer für beide Transportprotokolle verwendet, obwohl die meisten Anwendungen nur auf jeweils einem der beiden laufen. Tabelle 13.19 zeigt einige häufig verwendete Beispiele mit ihrem offiziellen Namen und dem am häufigsten verwendeten Transportprotokoll. Die vollständige Liste aller öffentlichen Serverdienste finden Sie unter http://www.iana.org/assignments/port-numbers. Falls Sie ein UNIX-System verwenden, steht eine ähnliche, möglicherweise weniger vollständige Liste in der Konfigurationsdatei /etc/services.


Tabelle 13.19   Einige TCP/UDP-Portnummern für gängige Dienste

Nummer Transportprotokoll Name Beschreibung
7 TCP, UDP echo Genaue Rückgabe der übermittelten Daten zur Kontrolle
13 TCP, UDP daytime Uhrzeitsynchronisation (RFC 867)
21 TCP ftp Dateiübertragung
22 TCP ssh Secure Shell – Telnet-Alternative mit Verschlüsselung
23 TCP telnet Terminal-Emulation
25 TCP smtp E-Mail-Versand
53 TCP, UDP domain Nameserver-Abfragen
80 TCP http Webserver
110 TCP pop3 E-Mail-Postfach-Server (klassisch)
142 TCP imap E-Mail-Postfach-Server (modern)


Galileo Computing

13.3.3 Das Domain Name System (DNS)  downtop

Die Verwendung von IP-Adressen zum Erreichen entfernter Rechner ist ideal, solange in die Datenübertragung nur Computer involviert sind. Für die Verwendung durch Menschen sind sie weniger gut geeignet (es gibt zum Beispiel nur wenige Menschen, die sich Telefonnummern auf Anhieb besser merken können als die zugehörigen Namen). Aus diesem Grund ist es seit Beginn des Internets und seiner Vorläufer üblich, einen Mechanismus einzurichten, der den beteiligten Menschen die Verwendung benutzerfreundlicher Namen statt der unhandlichen IP-Adressen ermöglicht.

Die Datei
/etc/hosts

Als das ARPANet entwickelt wurde, behalf man sich mit einer einfachen Textdatei, die pro Zeile einen Hostname und eine IP-Adresse nebeneinander auflistet (siehe unten). Noch heute verwenden UNIX-Rechner eine ähnliche Datei namens /etc/hosts. Auch unter Windows NT, 2000 und XP ist das Verfahren bekannt; hier befindet sich die Datei in <Windows-Verzeichnis>\system32\drivers\etc und heißt – untypisch für Windows – ebenfalls nur hosts, ohne Dateiendung. Allerdings wird dieses Verfahren heute immer seltener für die Namenszuordnung in lokalen Netzen eingesetzt, weil in immer mehr Firmennetzen DHCP verwendet wird. Leider kommt das dazu passende DynDNS, das die Hostnames auf dynamisch vergebene IP-Adressen abbilden kann, noch nicht ebenso häufig zur Anwendung.

Findet der Rechner einen Namenseintrag in seiner /etc/hosts-Datei, dann wird er die entsprechende Adresse nicht mehr bei einem Nameserver nachfragen. Auf diese Weise können Sie natürlich Ihre Kollegen ein wenig ärgern: Machen Sie beispielsweise die IP-Adresse ausfindig, die zu www.yahoo.de gehört (in diesem Moment 217.12.3.11), und tragen Sie in die /etc/hosts eines Kollegen etwa folgende Zeile ein:

217.12.3.11  www.google.de

Jedes Mal, wenn der Kollege nun die Suchmaschine Google anwenden möchte, wird er stattdessen bei Yahoo landen, kann sich das aber zunächst beim besten Willen nicht erklären.

Früher wurde eine solche Textdatei namens hosts.txt zentral verwaltet und unter den teilnehmenden Hosts im ARPANet regelmäßig ausgetauscht, um die Namensdaten aktuell zu halten. Als das Netz jedoch immer größer wurde, funktionierte dieses System nicht mehr, weil man mit den häufigen Änderungen nicht mehr nachkam und weil die gesamte Datei außerdem sehr umfangreich war sowie ihr Versand eine erhebliche Menge an Netzwerkverkehr erzeugte.

DNS-Einführung

Schließlich wurde statt der einfachen Textdatei eine hierarchische, vernetzte Datenbank eingeführt, die bis heute ein verteiltes Netz von Nameservern bildet. Diese Server geben auf Anfrage Auskunft über die zu einem Hostname gehörende IP-Adresse oder umgekehrt. Außerdem leiten sie die Anfrage automatisch weiter, wenn sie selbst keine Antwort wissen. Das System wird als Domain Name System (DNS) bezeichnet und ist Thema einer ganzen Reihe von RFCs. Die wesentlichen Grundlagen werden in RFC 1034 und 1035 beschrieben.

Damit Hostnames im gesamten Internet eindeutig sind, werden sie hierarchisch als so genannte Domainnamen vergeben. Zu diesem Zweck wird ein Name aus immer spezialisierteren Bestandteilen zusammengesetzt; das System lässt sich mit einem Pfad in einem Dateisystem vergleichen. Allerdings besteht ein wesentlicher Unterschied: Beim Dateisystempfad steht der allgemeinste Name vorn und der speziellste hinten, während es beim Domainnamen genau umgekehrt ist.

Beispielsweise bedeutet der UNIX-Pfad /home/sascha/it-kompendium/netzwerk/protokolle.txt, dass sich die Datei protokolle.txt im Verzeichnis netzwerk befindet, einem Unterverzeichnis von it-kompendium, welches wiederum dem Verzeichnis sascha untergeordnet ist. sascha ist seinerseits ein Unterverzeichnis von home, das zu guter Letzt direkt unter der Wurzel des Dateisystems (/) liegt.

Aufbau von Domain-Namen

Dagegen ist der Domainname www.buecher.lingoworld.de genau umgekehrt aufgebaut: Der Host/Dienst www liegt in der Domain buecher, einer Subdomain von lingoworld in der Top-Level-Domain de. Die Wurzel des DNS-Systems selbst ist nicht sichtbar, weil ihr Name der leere String ist.

Auf der jeweiligen Ebene des DNS-Systems muss ein bestimmter Name einmalig sein. Beispielsweise kann es buecher.lingoworld.de nur einmal geben. Unterhalb dieser Domain können untergeordnete Domains (Subdomains) oder die Namen einzelner Hosts oder Serverdienste bestehen, beispielsweise www.buecher.lingoworld.de, ftp.buecher.lingoworld.de oder neuheiten.buecher.lingoworld.de. Im Übrigen dürfen dieselben Namen natürlich auf über- oder untergeordneten oder auch auf »Geschwister-Ebenen« existieren: Es kann die Website www.lingoworld.de ebenso geben wie etwa www.download.lingoworld.de. Selbstverständlich ist auch www.buecher.de kein Problem – es handelt sich um eine andere Domain unterhalb der Top-Level-Domain de.

DNS-Zonen

Aus der Sicht der DNS-Administration wird jede Ebene eines solchen Namens auch als Zone bezeichnet, weil eine solche Ebene jeweils unabhängig von den übergeordneten Ebenen verwaltet wird. Beispielsweise kann der Administrator der Domain lingoworld.de Subdomains wie buecher.lingoworld.de oder download.lingoworld.de einrichten. Er kann die Verantwortung für eine Subdomain auch an jemand anderen delegieren, für den dann beispielsweise buecher.lingoworld.de wieder eine unabhängige Zone darstellt. Andererseits kann der Zonenverantwortliche für lingoworld.de nicht auf andere Zonen in der Domain de zugreifen; beispielsweise geht ihn die Konfiguration der Zone google.de nichts an.

Die Infrastruktur der Domainnamen wird von den über das gesamte Internet verbreiteten Nameservern verwaltet. Diese führen alle ein Programm aus, das Anfragen nach Name-Adresse-Zuordnungen beantwortet, unbekannte Zuordnungen bei anderen Nameservern erfragt und dann meistens dauerhaft speichert. Die am häufigsten verwendete derartige Software heißt BIND (Berkeley Internet Name Domain) und läuft unter allen UNIX-Varianten.

Die DNS-Hierarchie

Auf der obersten Ebene des DNS existiert die spezielle Zone, deren Name der leere String ist. Diese Zone wird durch die Root-Nameserver der ICANN verwaltet und enthält Verweise auf alle Top-Level-Domains. Davon gibt es organisatorisch gesehen zwei verschiedene Sorten (auch wenn es keinen technischen Unterschied gibt): Die »Generic TLDs« (allgemeine Top-Level-Domains) wie .com oder .org unterteilen die jeweiligen Domains, die unter ihnen liegen, nach der Funktion ihrer Betreiber. Die »Country TLDs« oder »ccTLDs« (Länder-TLDs) sind dagegen für eine geografische Einteilung vorgesehen. In der Praxis kommt es ohnehin zu einer Vermischung: Zum einen sind viele Generic TLDs mittlerweile für beliebige Betreiber verwendbar, zum anderen gibt es einige Länder-TLDs, die wegen ihrer spezifischen Abkürzung für bestimmte Branchen interessant sind – am bekanntesten ist in diesem Zusammenhang wohl der Südsee-Inselstaat Tuvalu mit seiner bei Fernsehsendern beliebten TLD .tv.

Tabelle 13.20 listet einige häufig verwendete Top-Level-Domains auf. Die mit Abstand meisten Betreiber-Domains enthält die Generic-TLD .com, gefolgt von der länderspezifischen Domain .de (Deutschland).


Tabelle 13.20   Übersicht über einige wichtige Top-Level-Domains

Top-Level-Domain Bedeutung
Generic Top-Level-Domains
.com commercial (Firmen)
.org organization (Organisationen und Vereine)
.net network (Netzwerkbetreiber; Internet-Infrastruktur)
.edu educational (US-Schulen und -Universitäten)
.gov government (US-Regierung, -Behördern, öffentl. Dienst)
.mil military (US-Militär)
.info information (allgemeine Informationsdienste)
.aero aeronautics (Luftfahrtindustrie, Fluggesellschaften)
Länder-Top-Level-Domains
.at Österreich
.ch Schweiz
.cn Volksrepublik China
.de Deutschland
.es Spanien
.fr Frankreich
.it Italien
.jp Japan
.ru Russland
.tr Türkei
.uk Großbritannien
.us USA
.va Vatikanstadt (!)

Der jeweilige Haupt-Nameserver einer Top-Level-Domain enthält Verweise auf sämtliche unterhalb dieser Domain befindlichen Second-Level-Domains. Je nach konkreter TLD handelt es sich dabei entweder unmittelbar um die einzelnen Domains, die von Betreibern angemeldet werden können, oder eine Domain ist in sich noch einmal in Organisationsstrukturen unterteilt. Bei allen Generic-TLDs und den meisten Länder-TLDs ist Ersteres der Fall. Nur einige Länder-TLDs werden noch einmal organisatorisch unterteilt: Zum Beispiel verwendet Großbritannien Unterteilungen wie .co.uk für Firmen, .ac.uk für Universitäten oder .org.uk für Vereine und Organisationen; auch die Türkei verwendet die entsprechenden Unterteilungen .com.tr, .edu.tr und .org.tr.

Master- und Slave-Nameserver

Aus Sicherheitsgründen sollten die Zonendaten für die Domain eines einzelnen Betreibers auf mindestens zwei voneinander unabhängigen (das heißt in verschiedenen autonomen Systemen befindlichen) Nameservern vorliegen. Die Daten müssen dafür nur auf einem der beiden Server erstellt werden, der als primärer Master-Nameserver bezeichnet wird; der andere – Slave-Nameserver genannt – repliziert sie automatisch. Größere Unternehmen und Institutionen verwalten in der Regel ihre eigenen Zonen. Der externe Slave-Nameserver mit denselben Zonendaten befindet sich in diesem Fall meist beim zuständigen Backbone-Provider, über den diese Betreiber mit dem Internet verbunden sind. Privatanwender oder kleinere Firmen besitzen dagegen zwar häufig eine eigene Domain (www.meinname.de ist werbewirksamer als so etwas wie home.t-online.de/users/~meinname), unter dieser Domain laufen allerdings oft lediglich eine beim Provider gehostete Website und einige E-Mail-Adressen. In diesem Fall werden die Zonendaten meist beim Hosting-Provider und einem anderen Provider verwaltet; die beiden Provider stellen sich den Slave-Name-Service dann gegenseitig zur Verfügung.

Bei den meisten Einzelrechnern oder kleineren Firmennetzwerken besteht die ganze DNS-Konfiguration oft lediglich in der Eingabe der IP-Adresse eines Nameservers des eigenen Providers; dieser wird stets befragt, wenn Namensdaten erforderlich sind. Gebe ich zum Beispiel in meinem Webbrowser www.google.de ein, so überprüft dieser zunächst, ob er die IP-Adresse vielleicht bereits kennt. Andernfalls fragt er den Standard-Nameserver des Providers. Dieser weiß die Antwort entweder selbst und liefert sie unmittelbar zurück oder wendet sich an den übergeordneten Nameserver – in diesem Fall den für die Top-Level-Domain .de zuständigen Server. Dieser kennt die für die Domain google.de zuständigen Nameserver und leitet die Anfrage an den ersten von ihnen weiter. Der wiederum ermittelt die IP-Adresse des Dienstes www.google.de und gibt sie zurück. Nun weiß der Browser, welche IP-Adresse er verwenden muss; außerdem speichert der Nameserver des Providers die gefundene Adresse ebenfalls in seinem Cache ab, um die nächste entsprechende Anfrage schneller beantworten zu können.

Andere Namensdienste

Insgesamt stellt das DNS ein leistungsfähiges, flexibles und effizientes System zur Verwaltung benutzerfreundlicher Hostnames zur Verfügung. Es wird im gesamten Internet eingesetzt und zumindest Client-seitig von jedem beliebigen Betriebssystem unterstützt. Allerdings handelt es sich nicht um die einzige Art und Weise der Namensverwaltung. Gerade in herstellerabhängigen lokalen Netzen werden Dienste wie der Windows-Namensdienst WINS oder das Network Information System (NIS) von Sun eingesetzt.


Galileo Computing

13.3.4 Verschiedene Internet-Anwendungsprotokolle  toptop

Genau wie beinahe jede Hardware die TCP/IP-Protokolle unterstützt, laufen auf der Anwendungsschicht des Internet-Protokollstapels auch fast alle Arten von Netzwerkanwendungen. Dazu gehören unter anderem auch Anwendungsprotokolle, die ursprünglich für bestimmte herstellerabhängige Netzwerke konzipiert wurden, beispielsweise die Standard-Fileserver-Protokolle der diversen Betriebssysteme: Das unter Windows verwendete SMB-(Server Message Blocks-)Protokoll wurde zunächst auf Microsofts eigenes NetBEUI-Netzwerk aufgesetzt (siehe Abschnitt 17.4.3); das von Apple konzipierte AppleShare lief ursprünglich nur unter AppleTalk. Mittlerweile können diese speziellen Anwendungsprotokolle alternativ auch auf TCP/IP aufgesetzt werden, was in der Praxis immer häufiger der Fall ist. Solche nativen Spezialprotokolle sind allerdings nicht Thema dieses Abschnitts.

Die eigentliche Beschreibung des Netzwerks aus Anwendersicht erfolgt im nächsten Kapitel. An dieser Stelle geht es lediglich darum, die grundlegende Funktionsweise einiger typischer Internetdienste auf der Ebene ihrer Protokolle zu beschreiben. Falls Sie also Details über die Verwendung von Internet-Client-Server-Diensten oder deren Konfiguration unter einem bestimmten Betriebssystem suchen, sollten Sie Kapitel 14, Netzwerkanwendung, lesen. Hier erfahren Sie dagegen eher, was hinter den Kulissen wirklich passiert, wenn Sie eine E-Mail versenden oder eine Webseite anfordern.

Funktion der Anwendungsprotokolle

Das (für Administratoren und Programmierer) Angenehme an den meisten Internet-Anwendungsprotokollen ist, dass die Protokollbefehle in Form von Klartextwörtern in Englisch verschickt werden. Wenn Sie mit einem Packet-Sniffer die Inhalte der über das Netzwerk übertragenen Datenpakete kontrollieren, können Sie deshalb unmittelbar verstehen, was die verschiedenen Hosts miteinander »reden«. Auf diese Weise ist es verhältnismäßig einfach, Konfigurations- oder Programmierfehler auf der Ebene der Anwendungsprotokolle zu entdecken und zu beseitigen.

In der Regel bestehen die Anforderungen eines Internet-Anwendungs-Clients aus einzeiligen Befehlen, die vom Server mit einer Statusmeldung und manchmal auch mit der Lieferung konkreter Daten beantwortet werden. Sie können das Verhalten eines Clients simulieren, indem Sie mit einem Terminal-Programm wie telnet eine Verbindung zu dem passenden Host und Port aufbauen und die entsprechenden Befehle von Hand eintippen.

Telnet

Eine der ältesten Anwendungen des Internets ist die Terminal-Emulation: Ein Programm ermöglicht Ihnen über ein Terminal, das an Ihren Computer angeschlossen ist, die Arbeit an einem anderen Computer, zu dem eine Netzwerkverbindung besteht. Telnet ist eines der wichtigsten Werkzeuge für Systemadministratoren, die auf diese Weise entfernte Rechner verwalten, ohne sich physikalisch dorthin zu begeben (insbesondere an Wochenenden oder nach Feierabend schätzen Admins diese Möglichkeit, weil sie eventuelle Pannenhilfe von zu Hause aus erledigen können). Die Telnet-Spezifikation ist in RFC 854 festgelegt.

Bessere Alternative: SSH

Fast alles, was an dieser Stelle über Telnet gesagt wird, gilt sinngemäß auch für SSH, die Secure Shell – im Grunde genommen handelt es sich dabei um eine sichere Variante von Telnet, die mit Verschlüsselung arbeitet. Der gravierendste Schönheitsfehler des klassischen Telnet besteht nämlich darin, dass es Daten im Klartext überträgt – und das gilt unter anderem auch für Passwörter und ähnlich sensible Daten. SSH ist nicht in einem RFC spezifiziert, denn obwohl es sich aus frei verfügbaren Komponenten zusammensetzt, ist die ursprüngliche Implementierung kommerziell. Nähere Informationen erhalten Sie stattdessen auf der Site http://www.ssh.com.

Telnet-Server

Der Telnet-Server lauscht auf dem TCP-Port 23 auf eingehende Verbindungen (SSH verwendet Port 22). Wenn ein TCP-Verbindungsversuch erfolgt, wird der Benutzer am entfernten Host zunächst nach Benutzername und Passwort gefragt, bevor er tatsächlich arbeiten kann. Im Grunde genommen wird dem jeweiligen Benutzer seine Standard-UNIX-Shell zur Verfügung gestellt, an der er auch lokal auf dem entsprechenden Rechner arbeiten würde.

Telnet und SSH sind daher beliebig flexibel, was den Inhalt der in beide Richtungen übermittelten Daten angeht. Wenn Sie erst einmal mit dem Telnet-Server verbunden sind, können Sie jedes beliebige Programm auf dem entfernten Host ausführen, für das Sie die Benutzerrechte besitzen. Dazu gehören auch solche Programme, die nicht zeilenorientiert, sondern mit einer Vollbildmaske arbeiten – zum Beispiel die klassischen UNIX-Texteditoren vi und Emacs. Deshalb genügt die zeilenorientierte Kommunikation zwischen Client und Server bei Telnet nicht: In einem Vollbildprogramm kann jeder einzelne Tastendruck eine Bedeutung haben, die unmittelbar umgesetzt werden muss. Wenn Sie Beispiele dafür sehen möchten, was Sie in einer Telnet-Sitzung eingeben können, lesen Sie einfach den Abschnitt über Linux in Kapitel 4, Betriebssysteme. Dort wird die Funktionsweise einer lokalen UNIX-Shell genau erläutert. Alles, was dort steht, gilt auch für Telnet-Sitzungen.

Die Grenzen von Telnet

Die einzige Art von Programmen, die nicht über Telnet ausgeführt werden können, sind solche, die auf einer grafischen Benutzeroberfläche laufen. Allerdings bietet die UNIX-Welt auch für dieses Problem die passende Lösung: Sie benötigen auf Ihrem lokalen Rechner zusätzlich zu dem Telnet-Client einen X-Window-Server, der die grundlegenden Zeichenfunktionen für die GUI zur Verfügung stellt. Sobald dieser X-Server läuft, können Sie ein X-basiertes Anwendungsprogramm auf dem entfernten Server starten und Ihren eigenen Rechner als Ziel der grafischen Darstellung angeben (in der Regel mit dem Parameter -display). Angenommen, Ihr eigener Rechner besitzt im lokalen Netz die IP-Adresse 192.168.0.9. Dann können Sie in das Telnet-Programm, in dem eine Sitzung auf einem anderen Rechner läuft, Folgendes eingeben, um in Ihrem X-Server ein xterm (ein X-basiertes Terminal) zu starten:

#  xterm -display 192.168.0.9:0.0

Der Zusatz 0.0 hinter der IP-Adresse bedeutet sinngemäß »erster X-Server, erstes Fenster«. Wichtig ist, dass Sie den Begriff »X-Server« nicht falsch verstehen: Hier läuft der Server, der die grafische Oberfläche als Dienstleistung zur Verfügung stellt, auf Ihrem eigenen Rechner, während der Client das auf dem entfernten Rechner laufende Programm ist, dessen Ausgabe in Ihrem lokalen X-Window-System erfolgt. Näheres über die Konfiguration von X-Servern unter UNIX erfahren Sie in Kapitel 4, Betriebssysteme. Allerdings gibt es auch X-Server für andere Systeme, beispielsweise für Windows oder klassisches Mac  OS. Sie sind natürlich nicht für die grafische Darstellung lokaler Programme gedacht (das können die eingebauten GUIs von Mac  OS oder Windows selbst gut genug), sondern für grafisch orientierte Programme, die auf entfernten UNIX-Rechnern laufen.

Im Übrigen sollten Sie das Telnet-Protokoll, das die Terminal-Emulation bereitstellt, nicht mit dem UNIX- und Windows-Dienstprogramm telnet verwechseln. Letzteres kann nämlich – wie oben erwähnt – mit fast jedem Internetserver kommunizieren, wenn Sie die passenden Parameter (IP-Adresse beziehungsweise Hostname und Portnummer beziehungsweise Standard-Dienstname) eingeben.

FTP

Das File Transfer Protocol (FTP) ist beinahe das genaue Gegenteil von Telnet: ein aus ganz wenigen Befehlen bestehendes, klartextbasiertes, zeilenorientiertes Protokoll. Es gehört zu den frühesten Internetanwendungen überhaupt. Ihre erste Definition steht in RFC 172 von 1971, die aktuelle Spezifikation befindet sich in RFC 959. Den reinen Datei-Download über FTP beherrscht heutzutage fast jeder Webbrowser; die meisten stellen auch die Verzeichnisansicht des entfernten Rechners übersichtlich und angenehm dar.

FTP-Clients

In der Praxis wird jedoch überwiegend ein grafisch orientierter FTP-Client verwendet, der dem lokalen Dateinavigator Ihres Betriebssystems idealerweise möglichst ähnlich sieht. Die häufigste Anwendung für ein solches Programm dürfte die Pflege einer eigenen Website sein. Dabei bearbeiten Sie die Daten in der Regel auf Ihrem eigenen Rechner und laden sie anschließend mit Hilfe eines solchen FTP-Programms auf den Server Ihres Hosting-Providers hoch, um sie zu veröffentlichen. Bekannte FTP-Clients sind beispielsweise WS_FTP von IPSwitch Software für Windows oder Fetch für Mac  OS. Auch in gängige Website-Editoren wie Macromedia Dreamweaver oder Adobe GoLive sind FTP-Module eingebaut.

Falls Sie jedoch genau sehen möchten, wie FTP-Client (auf Ihrem eigenen Rechner) und -Server (auf dem entfernten Rechner) miteinander kommunizieren, können Sie das UNIX- und Windows-Konsolenprogramm ftp verwenden. Die Befehle, die Sie auf der Client-Seite eingeben, sind jeweils einzeilig und bestehen aus einem Schlüsselwort mit eventuellen Parametern, gefolgt von einem Zeilenumbruch. Die Antwort des Servers ist zunächst eine Statusmeldung, die aus einer dreistelligen dezimalen Codenummer und einem Meldungstext besteht; häufig folgen auf die Statusmeldung zusätzliche Datenzeilen. Um dem Client das Ende einer solchen Datensequenz zu signalisieren, beginnt die letzte Zeile der Serverantwort wieder mit derselben Codenummer wie die erste.

Eine FTP-Sitzung

Die folgenden Zeilen zeigen den Mitschnitt einer FTP-Sitzung mit dem Host www.lingoworld.de (der Name www besagt natürlich, dass es sich eigentlich um einen Webserver handelt; es ist durchaus üblich, dass Hosting-Provider den Webserver unmittelbar per FTP zugänglich machen, um die eigene Website hochzuladen):

#  ftp www.lingoworld.de
Verbunden zu www.lingoworld.de.
220 FTP Server ready.
Benutzer (www.lingoworld.de:(none)): XXXXX
331 Password required for XXXXX.
Kennwort:
230 User XXXXX logged in.
Ftp> pwd
257 "/" is current directory.
Ftp> cd extra
250 CWD command successful.
Ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
test.txt
info.txt
226-Transfer complete.
226 Quotas off
21 Bytes empfangen in 0,01 Sekunden (2,10 KB/s)
Ftp> get test.txt
200 PORT command successful.
150 Opening ASCII mode data connection for test.txt (2589 bytes).
226 Transfer complete.
2718 Bytes empfangen in 0,04 Sekunden (67,95 KB/s)
Ftp> quit
221 Goodbye.

FTP-Befehle

In dieser Sitzung wird zunächst die Anmeldung durchgeführt (Benutzername wird angezeigt, allerdings habe ich ihn hier geändert; die Passworteingabe hat kein grafisches Feedback), anschließend werden die folgenden Befehle eingesetzt:

gp  pwd: »Print working directory« – aktuelles Arbeitsverzeichnis ausgeben
gp  cd: »Change directory« – Verzeichnis auf dem entfernten Server wechseln
gp  ls: »list« – Verzeichnisinhalt anzeigen
gp  get: Die angegebene Datei in das aktuelle lokale Verzeichnis herunterladen
gp  quit: Die Sitzung und das FTP-Programm beenden

Weitere wichtige Befehle sind folgende:

gp  put: Die angegebene Datei in das aktuelle entfernte Verzeichnis hochladen
gp  binary: Umschalten in den Binärmodus
gp  ascii: Umschalten in den ASCII-Modus
gp  help: Eine Liste aller verfügbaren Befehle anzeigen

ASCII- und Binärmodus

Es ist wichtig, dass Sie den Unterschied zwischen dem ASCII- und dem Binärmodus verstehen. Das ganze Problem hat damit zu tun, dass die verschiedenen Betriebssystementwickler sich nicht auf einen gemeinsamen Standard für Zeilenumbrüche in Textdateien einigen konnten. Wie in Kapitel 11, Datei- und Datenformate, genau erläutert wird, verwendet UNIX das ASCII-Zeichen mit dem Code 10 (LF), Mac  OS das ASCII-Zeichen 13 (CR) und Windows und die meisten Netzwerk-Anwendungsprotokolle benutzen beide Zeichen hintereinander.

Im ASCII-Modus werden die Zeilenumbrüche innerhalb einer Datei bei der Übertragung jeweils umgewandelt, sodass beispielsweise die auf Ihrem Windows-Rechner gespeicherten Textdateien mit CR/LF auf dem entfernten UNIX-Server mit dem für dessen Verhältnisse korrekten Nur-LF ankommen und umgekehrt. Sie sollten jedoch begreifen, dass dieses bei Textdateien recht segensreiche Feature bei Binärdateien wie Bildern oder Programmen den sicheren Tod zur Folge hat. Wird jedes Vorkommen des Byte-Wertes 10 durch die beiden Bytes 13 und 10 ersetzt oder umgekehrt, so werden die Bytes in einer solchen Datei verändert und planlos verschoben! Natürlich ist eine auf diese Weise behandelte Bild-, Sound- oder Programmdatei unbrauchbar.

Die meisten grafisch orientierten FTP-Programme entscheiden je nach Dateityp sinnvoll selbst, ob sie ASCII- oder Binär-Übertragung verwenden sollen. Bei dem Konsolen-FTP-Programm müssen Sie für jede einzelne Datei selbst in den richtigen Modus umschalten. Das ist ein – aber nicht der einzige – Grund dafür, dass die Arbeit mit der Konsolenversion von FTP absolut unzumutbar ist.

E-Mail

Die E-Mail, die sich unter dem Dach eines Mail-Clients wie Eudora, Outlook Express oder Netscape Mail so einheitlich präsentiert, bedarf in Wirklichkeit der Zusammenarbeit mit mindestens zwei verschiedenen Servern. Der eine ist für den Versand von E-Mails zuständig und führt zu diesem Zweck das Protokoll SMTP (Simple Mail Transport Protocol) aus. Ein anderer enthält das E-Mail-Postfach, in dem an Sie adressierte Nachrichten ankommen; dieser Dienst wird entweder von dem weit verbreiteten POP3-Protokoll (Post Office Protocol Version 3) oder dem komfortableren, aber bisher eher selten verwendeten IMAP (Internet Message Access Protocol) versehen.

Mail-Versand

Wenn Sie eine Mail versenden möchten, dann wird diese an einen SMTP-Server übermittelt, der sich um die Weiterleitung der Nachricht an den Empfänger kümmert. SMTP, definiert in RFC 821, ist ähnlich wie FTP ein einfaches, textbasiertes Protokoll aus wenigen Befehlen; der zuständige Server wartet am TCP-Port 25 auf Verbindungen.

Viele SMTP-Server von Internetprovidern nehmen bis heute keine Kontrolle der Identität des Absenders vor. Das Problem dabei ist, dass solche Server dadurch leicht für das Versenden von Spam verwendet werden können oder dass sogar jemand eine falsche Identität vortäuschen kann. Dabei sieht die SMTP-Spezifikation durchaus mehrere mögliche Authentifizierungsverfahren vor:

gp  Manche SMTP-Server überprüfen die IP-Adresse des Hosts, von dem die Verbindung initiiert wurde – ein ideales Verfahren für normale Internetprovider, die nur ihren eigenen Kunden Zugriff auf ihre SMTP-Server gewähren möchten.
gp  Eine andere Möglichkeit besteht darin, die Anmeldung am Mail-Empfangs-Server desselben Providers als Voraussetzung für den E-Mail-Versand zu verlangen. Dies Verfahren wird »SMTP after POP« genannt und beispielsweise von dem bekannten Hosting-Provider Strato eingesetzt. Der Nachteil ist, dass manche E-Mail-Clients wie etwa Outlook Express für Mac  OS nicht damit umgehen können, sodass man jedes Mal vor dem E-Mail-Versand auf »Mail empfangen« klicken muss!
gp  Das sicherste Verfahren wird leider viel zu selten eingesetzt: die persönliche Anmeldung beim SMTP-Server mit Benutzername und Passwort. Erst nach und nach gehen Provider dazu über, diese Methode einzuführen.

Eine SMTP-Sitzung

Sie können die Kommunikation mit einem SMTP-Server über das Programm telnet abwickeln. Eine solche Sitzung sieht beispielsweise folgendermaßen aus (die konkreten Namens- und Adressdaten habe ich anonymisiert):

#  telnet smtp.myprovider.de smtp
220 smtp.myprovider.de ESMTP Tue, 24 Dec 2002 01:45:16 +010 HELO
250 smtp.myprovider.de Hello  [203.51.81.17]
MAIL From: absender@myprovider.de
250 <absender@myprovider.de> is syntactically correct
RCPT To: empfaenger@elsewhere.com
250 <empfaenger@elsewhere.com> verified
DATA
354 Enter message, ending with "." on a line by itself
FROM: Sascha <absender@myprovider.de>
To: Jack <empfaenger@elsewhere.com>
Subject: Gruesse
 
Hallo Jack,
hier ist wieder einmal Post für dich.
Viel Spaß damit!
Gruss, Sascha
.
250 OK id=18QdIY-00048Y-0 QUIT
221 smtp.myprovider.de closing connection.

SMTP-Befehle

In dieser kurzen Konversation werden die folgenden SMTP-Befehle verwendet:

gp  HELO: Mit diesem Befehl meldet sich der Client beim Server an; eventuell findet in diesem Zusammenhang die oben beschriebene Überprüfung der Client-IP-Adresse statt.
gp  MAIL: Dieser Befehl leitet die Erzeugung einer neuen Nachricht ein; der Empfänger muss im Format From: E-Mail-Adresse oder From: Name <E-Mail-Adresse> angegeben werden.
gp  RCPT: Angabe eines Empfängers im Format To: E-Mail-Adresse oder To: Name <E-Mail-Adresse>.
gp  DATA: Alle folgenden Zeilen des Clients werden als Teil der eigentlichen E-Mail-Nachricht aufgefasst, bis eine Zeile folgt, die nur einen Punkt (.) enthält.
gp  QUIT: Die Sitzung wird hiermit beendet; alle bis zu diesem Zeitpunkt erzeugten Mail-Nachrichten werden versandt.

RFC-822-Nachrichten

Die E-Mail-Nachricht selbst (zwischen DATA und der Abschlusszeile mit dem Punkt) ist eine klassische Textnachricht, deren Aufbau in RFC 822 beschrieben wird. Prinzipiell besteht sie aus mehreren Header-Zeilen im Format Feldname: Wert, gefolgt von einer Leerzeile und dem eigentlichen Text. Der minimale Header enthält den Absender (From:), den Empfänger (To:) und einen Betreff (Subject:). Absender und Empfänger dürfen wie bei den SMTP-Befehlen MAIL und RCPT diverse Formate besitzen. Weitere häufige Header-Felder sind die Kopien-Empfänger (Cc: für »Carbon Copy«) sowie die unsichtbaren Kopien-Empfänger (Bcc: für »Blind Carbon Copy«). Die normalen Kopien-Empfänger werden in der Nachricht selbst angezeigt, die unsichtbaren nicht.

Ein alternatives Format für E-Mails, das heutzutage bereits häufiger verwendet wird als RFC 822, ist das MIME-Format. Die verschiedenen Aspekte von MIME werden in RFC 2045 bis 2049 dargelegt. Die Abkürzung MIME steht für Multipurpose Internet Mail Extensions. Es handelt sich um ein Format, das für den Versand beliebiger Text- und Binärdaten geeignet ist, sogar von verschiedenen Datentypen innerhalb derselben Nachricht.

MIME-Nachrichten

Der MIME-Header ist eine Erweiterung des RFC-822-Headers. Die wichtigsten neuen Felder sind Content-type:, das den Datentyp angibt, und Content-Transfer-Encoding:, mit dessen Hilfe das Datenformat festgelegt wird. Ersteres beschreibt also den Inhalt der Nachricht, Letzteres die Form, in der es versandt wird. Der Inhaltstyp (Content-Type), meist MIME-Type genannt, besteht aus zwei Bestandteilen, die durch einen Slash (/) voneinander getrennt werden: dem Haupttyp und dem genaueren Untertyp. Haupttypen sind beispielsweise text (ASCII-Text), image (Bilddaten), audio (Sounddaten), video (Digitalvideo) oder application (proprietäres Datenformat eines bestimmten Anwendungsprogramms). Tabelle 13.21 listet einige gängige MIME-Types auf.


Tabelle 13.21   Einige gängige MIME-Datentypen

Typ Beschreibung
text/plain reiner Text ohne Formatierungsbefehle
text/html HTML-Code
text/xml XML-Code
image/gif Bild vom Dateityp GIF
image/jpeg Bild vom Dateityp JPEG
image/png Bild vom Dateityp PNG
audio/wav Sounddatei vom Typ Microsoft Wave
audio/aiff Sounddatei vom Typ Apple AIFF
audio/mp3 Komprimierte Sounddatei vom Typ MP3
video/avi Digitalvideo vom Typ Microsoft Video for Windows
video/mov Digitalvideo vom Typ Apple QuickTime
video/mpeg Digitalvideo vom Typ MPEG
application/x-shockwave-flash Komprimierter Macromedia-Flash-Film (Dateiendung .swf)
application/x-director Komprimierter Macromedia-Director-Film (Dateiendung .dcr)
multipart/mixed »Umschlag« für mehrere MIME-Unterabschnitte
multipart/alternative »Umschlag« für denselben Inhalt in mehreren Alternativformaten

MIME-Multipart-Nachrichten

Die beiden letzten Typen in der Tabelle machen MIME besonders interessant: Ein MIME-Dokument vom Typ multipart/mixed kann beliebig viele Teile enthalten, die jeweils einen vollständigen MIME-Header besitzen und wiederum beliebige MIME-Types aufweisen können. Mit Hilfe dieser Technik werden in modernen E-Mail-Programmen Attachments (Datei-Anhänge) der Mail hinzugefügt. Dagegen wird ein Abschnitt vom Typ multipart/alternative eingesetzt, um denselben Inhalt in verschiedenen alternativen Darstellungsformen zu umschließen, beispielsweise ein Bild im GIF- und im PNG-Format oder (wahrscheinlich die häufigste Anwendung) den Text einer E-Mail-Nachricht einmal im Text- und einmal im HTML-Format. Abbildung 13.3 zeigt, wie eine MIME-Nachricht mit zwei Datei-Anhängen zum Beispiel aufgebaut sein könnte.


Abbildung 13.3   Beispiel für eine E-Mail im MIME-Multipart-Format

Abbildung
Hier klicken, um das Bild zu Vergrößern


Der Content-Transfer-Encoding:-Header gibt dem Empfänger-Client einen Hinweis, auf welche Weise die ankommenden Daten zu interpretieren sind. Häufig verwendete Werte sind etwa folgende:

gp  7bit: keine Codierung; nur geeignet für 7-Bit-ASCII (englischen Text). Automatischer Zeilenumbruch nach spätestens 1.000 Zeichen.
gp  8bit: keine Codierung; geeignet für 8-Bit-Text (internationalen Text). Ebenfalls automatischer Zeilenumbruch nach spätestens 1.000 Zeichen.
gp  binary: keine Codierung, kein automatischer Zeilenumbruch.
gp  quoted-printable: spezielle Codierung von Sonderzeichen, die über 7-Bit-ASCII hinausgehen. Beispiel: »größer« wird zu »gr=FC=DFer« (die Codierung besteht aus einem Gleichheitszeichen, gefolgt vom hexadezimalen Zeichencode).
gp  base64: bevorzugte Codierung für Binärdateien. Ein spezieller Algorithmus packt die Daten 7-Bit-kompatibel um.

Die Codierungsformen quoted-printable und base64 besitzen den Vorteil, dass die Mail-Nachricht formal RFC-822-kompatibel bleibt und entsprechend auch über alte Mail-Server versandt und empfangen werden kann.

Eine POP3-Sitzung

Der E-Mail-Empfang über einen POP3-Server erfolgt auf textbasierte Art und Weise, ähnlich wie bei SMTP. Der Server kommuniziert über den TCP-Port 110. Die Beschreibung von POP3 steht in RFC 1939. Zur Verdeutlichung hier wiederum eine Telnet-basierte Konversation mit einem (unkenntlich gemachten) POP3-Server:

# telnet pop.myprovider.de pop3
+OK POP3 server ready
USER absender
+OK
PASS XXXXX
+OK
LIST
1  898
.
RETR 1
+OK 953 octets
Return-path: <empfanger@elsewhere.com>
Envelope-to: absender@myprovider.de
Delivery-date: Tue, 24 Dec 2002 03:08:24 +010
Received: from [207.18.31.76] (helo=smtp.elsewhere.com)
        by mxng13.myprovider.de with esmtp (Exim 3.35 #1)
        id 18QeUU-00027O-0
        for absender@myprovider.de; Tue, 24 Dec 2002 03:08:18 +010
Received: from box (xdsl-202-21-109-17.elsewhere.com [202.21.109.17])
        by smtp.elsewhere.com (Postfix) with SMTP id CA500866C1
        for <absender@myprovider.de>; Tue, 24 Dec 2002 03:08:14 
        +0100 (MET)
Message-ID: <001901c2aaf2$31ce81e0$0200a8c0@box>
From: "Jack" <empfaenger@elsewhere.com>
To: "Sascha" <absender@provider.de>
Subject: Gruesse
Date: Tue, 24 Dec 2002 03:14:30 +010 MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
 
Hi!
Wie geht's?
Alles klar?
Ciao.
.
DELE 1
+OK
QUIT
+OK

POP3-Befehle

In dieser Sitzung kommen die folgenden POP3-Befehle zum Einsatz:

gp  USER: Angabe des Benutzernamen für die Anmeldung
gp  PASS: Angabe des Passworts für die Anmeldung
gp  LIST: nummerierte Liste der verfügbaren E-Mails mit der jeweiligen Länge in Byte
gp  RETR: E-Mail mit der angegebenen Nummer empfangen
gp  DELE: E-Mail mit der angegebenen Nummer vom Server löschen
gp  QUIT: Sitzung beenden

IMAP

Die meisten E-Mail-Programme führen RETR und DELE standardmäßig unmittelbar nacheinander durch, die Nachrichten verbleiben also in der Regel nicht auf dem Server. Bei IMAP-Servern ist es dagegen meist anders: Der besondere Vorteil des IMAP-Protokolls besteht darin, dass auf dem Mail-Server selbst verschiedene Ordner eingerichtet werden können, um Mails dort zu verwalten. Auf diese Weise erleichtert IMAP die E-Mail-Verwaltung für mobile Benutzer. Die aktuelle Version von IMAP ist das in RFC 2060 dargestellte IMAP4. Ein IMAP-Server funktioniert ähnlich wie ein POP3-Server, verwendet allerdings den TCP-Port 142.

Eine weitere beliebte Form der E-Mail-Nutzung sind webbasierte Free-Mail-Dienste wie GMX oder HotMail. Dabei handelt es sich um gewöhnliche POP/SMTP-Kombinationen, die über eine Website mit persönlicher Anmeldung zugänglich gemacht werden. Das Programm, das mit den Mail-Servern kommuniziert, läuft auf dem Webserver und wird dem Kunden per Browser zugänglich gemacht.

Newsgroups

Newsgroups als virtuelle »schwarze Bretter« wurden 1979 eingeführt, um Gruppendiskussionen zwischen der Duke University und der University of North Carolina zu ermöglichen. Das System entwickelte sich im Laufe der Jahre zum weltweiten Usenet mit mehreren zehntausend Newsgroups.

Usenet-Geschichte

Das Usenet besteht aus einem losen Verbund von weltweit verteilten News-Servern, die das in RFC 977 festgelegte Protokoll NNTP (Network News Transport Protocol) ausführen. Wer einen Artikel in einer Newsgroup veröffentlichen möchte, sendet diesen an den TCP-Port 119 des nächstgelegenen News-Servers (in der Regel den des eigenen Providers); innerhalb von 24 Stunden dürfte die Nachricht jeden News-Server weltweit erreicht haben.

Um Nachrichten in einer bestimmten Newsgroup zu lesen, müssen Sie diese abonnieren: Sie verbinden sich über Ihren News-Reader mit einem News-Server, der diese Group anbietet, und aktivieren das Abonnement für die Group. Bei jedem Start Ihres News-Readers werden nun zunächst die Header-Daten aller aktuellen Nachrichten in der Group heruntergeladen und angezeigt. Sobald Sie eine solche Kopfzeile anklicken, wird der eigentliche Inhalt der Nachricht geladen.

Eine Newsgroup-Nachricht ist ein RFC-822-kompatibles Dokument. Allerdings definiert das NNTP-Protokoll einige spezielle Header-Felder, die erforderlich sind, um die Nachrichten den verschiedenen Groups zuzuordnen und ihre Position in einem Thread, einem Diskussionsstrang, festzulegen. Die meisten News-Server beherrschen im Übrigen die MIME-Erweiterungen, allerdings sind MIME-basierte HTML- oder gar Multimedia-Nachrichten in den meisten traditionellen Usenet-Newsgroups verpönt; es ist üblich, nur reinen Text zu verwenden.

NNTP-Header

Zu einer Newsgroup-Nachricht gehören die folgenden wichtigen Header-Felder (abgesehen von denjenigen, die bereits beim Thema SMTP beschrieben wurden):

gp  Article: eine ID des Beitrags, bestehend aus einer Nummer und dem Namen der Newsgroup, in die der Beitrag gepostet wird. Diese Nummern können auf verschiedenen News-Servern unterschiedlich sein, da sie in der Reihenfolge vergeben werden, in der Nachrichten eintreffen.
gp  Message-ID: eine unveränderliche und weltweit einmalige ID für diesen einen Beitrag über alle Newsgroups hinweg.
gp  Referrers: die Message-ID des ursprünglichen Newsgroup-Beitrags, auf den geantwortet wurde. Aufgrund dieses Felds wird die Nachricht in einen Thread einsortiert.

Newsgroup-Hierarchie

Das Usenet besteht aus einer Reihe von Newsgroups mit hierarchisch gegliederten Namen. Ganz links steht dabei die allgemeine Oberkategorie, die nach rechts immer weiter spezialisiert wird (ähnlich wie in einem Dateisystem und andersherum als bei Domainnamen). Die Hauptkategorien sind beispielsweise comp für computerbezogene Themen, rec (recreation) für Freizeit, Sport und Spiel, soc für gesellschaftspolitische Themen oder sci (Science) für die Welt der Naturwissenschaft und Technik. Innerhalb dieser Kategorien bestehen einzelne Groups wie comp.lang.perl.modules (Computer – Programmiersprachen – Perl – Module), rec.autos.vw (Freizeit – Autos – Volkswagen), soc.religion.islam (Gesellschaft – Religion – Islam) oder sci.crypt.random-numbers (Wissenschaft – Kryptografie – Zufallsgeneratoren). Im Übrigen gibt es Hauptkategorien, die auf ein bestimmtes Länderkürzel lauten, für Newsgroups, in denen eine bestimmte Sprache gesprochen wird (etwa die de.*-Hierarchie für deutschsprachige Groups).

Da das traditionelle Usenet recht schwerfällig und konservativ ist, bedarf es beinahe endloser Diskussionen, bevor unter einer der klassischen Hauptkategorien eine neue Newsgroup eingerichtet wird. Aus diesem Grund wurde die spezielle alt.*-Hierarchie eingeführt, unter der jeder neue Groups anlegen kann. Diese Hierarchie gehört nicht zum eigentlichen Usenet und enthält die bizarrsten, aber auch einige der interessantesten Newsgroups.

Die Beliebtheit der Newsgroups unter den Internetnutzern scheint allerdings bereits vor einigen Jahren ihren Zenit überschritten zu haben. Die größte Konkurrenz bilden heutzutage webbasierte Foren, in denen über speziellere Themen diskutiert wird und die nicht ganz so strenge Verhaltensregeln besitzen wie die Newsgroups oder insbesondere das Usenet. Dennoch besteht die Möglichkeit, ohne spezielles News-Programm auf beliebige Newsgroups zuzugreifen: Die beliebte Suchmaschine Google kaufte vor einigen Jahren den webbasierten News-Dienst Deja.com und dessen Usenet-Archiv auf; unter http://groups.google.com können Sie in fast allen jemals geschriebenen Newsgroup-Beiträgen recherchieren und sich darüber hinaus anmelden, um aktiv an Newsgroup-Diskussionen teilzunehmen.

Das World Wide Web

Das Web ist heute die dominierende Internetanwendung überhaupt, und zwar in einem solchen Maße, dass viele Leute das WWW mit dem gesamten Internet gleichsetzen. Wer auf das Web zugreifen möchte, verwendet dazu eine spezielle Client-Software, den so genannten Webbrowser. Nach der Eingabe einer Dokumentadresse stellt der Browser eine TCP-Verbindung zu dem gewünschten Webserver her und fordert über das HTTP-Protokoll das gewünschte Dokument an. Das Dokument ist üblicherweise in der Seitenbeschreibungssprache HTML verfasst, die der Browser interpretiert und in eine auf bestimmte Art und Weise formatierte Webseite umwandelt.

Webseiten

Eine solche Seite kann außerdem Verweise auf eingebettete Dateien wie Bilder oder Multimedia enthalten, die der Browser auf dieselbe Art und Weise anfordert wie das HTML-Dokument selbst und an der passenden Stelle auf der Seite platziert. Ein weiteres wichtiges Element von Webseiten sind die Hyperlinks, anklickbare Verknüpfungen mit anderen Dokumenten. Wenn Sie einen Link aktivieren, wird die entsprechende Datei angefordert und in den Browser geladen.

Damit das Web funktionieren kann, wirken einige wesentliche Konzepte zusammen:

gp  Das Anwendungsprotokoll HTTP, über das Dokumente beim Server angefordert und von diesem ausgeliefert werden. Die aktuelle Version des Protokolls, HTTP 1.1, wird in RFC 2616 beschrieben.
gp  Ein spezielles Format für Dokumentadressen, das als Uniform Resource Locator (URL) bezeichnet wird und dessen Definition sich in RFC 1738 befindet.
gp  Die Seitenbeschreibungssprache HTML, in der Hypertext-Dokumente für das WWW geschrieben werden. Neuere HTML-Versionen werden nicht mehr in RFCs definiert; eine genaue Beschreibung von HTML finden Sie in Kapitel 16.

Eine HTTP-Sitzung

HTTP ist ein ähnlich einfaches, klartextbasiertes Protokoll wie etwa FTP. Ein Webserver wartet üblicherweise auf dem TCP-Port 80 auf Verbindungen. Der folgende Mitschnitt einer Dokumentanforderung über telnet zeigt einige wesentliche Bestandteile:

#  telnet www.galileocomputing.de http
GET / HTTP/1.1
HTTP/1.1 200 OK
Date: Tue, 24 Dec 2002 22:49:20 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.9 OpenSSL/0.9.6e
Cache-Control: max-age=17280 Expires: Thu, 26 Dec 2002 22:49:20 GMT
Last-Modified: Tue, 21 Aug 2001 10:45:10 GMT
ETag: "7-50d-3b823bb6"
Accept-Ranges: bytes
Content-Length: 1293
Connection: close
Content-Type: text/html
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" 
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="de">
[...] 

Der wichtigste HTTP-Client-Befehl, mit dessen Hilfe hier das Dokument angefordert wird, lautet GET. Die Parameter sind der Dokument-Pfad (hier das Wurzeldokument /) und die HTTP-Protokoll-Version. Die Antwort des Servers besteht ebenfalls aus der HTTP-Version, darauf folgt eine Statuscodenummer wie bei FTP und ein entsprechender Meldungstext. In diesem Fall bedeutet »200 OK«, dass das Dokument gefunden wurde und nun übertragen wird (im obigen Beispiel wurde es aus Platzgründen nach der zweiten Zeile abgebrochen).

HTTP-Header

Die eigentliche Datenübertragung besteht aus einer Reihe von Header-Feldern im Format Feldname: Wert, darauf folgt eine Leerzeile und dann der eigentliche Dokumentinhalt.

Das einzige wirklich erforderliche Header-Feld ist Content-type – wie bei E-Mails handelt es sich um die MIME-Formatangabe des Dokumentinhalts. Der Webserver ermittelt den Wert, den er hier eintragen muss, anhand der jeweiligen Dateiendung. Der Browser interpretiert den Wert dieses Felds und nicht etwa die Dateiendung des übermittelten Dokuments. Daher toleriert der Browser auch dynamisch erzeugte Dokumente mit Dateiendungen wie .php, .pl oder .jsp als HTML. Ein Browser benötigt diese Information dringend, damit er weiß, auf welche Weise er die ankommenden Daten interpretieren soll.

Weitere HTTP-Client-Befehle sind beispielsweise POST, durch den Benutzereingaben aus HTML-Formularen unabhängig an den Server übertragen werden, oder HEAD, mit dessen Hilfe nur die Header-Daten ohne das eigentliche Dokument angefordert werden (zum Beispiel, damit der Browser überprüfen kann, ob er bereits die aktuelle Version eines zum wiederholten Mal geladenen Dokuments in seinem Cache gespeichert hat).

HTTP-Statuscodes

Einige wichtige Statuscodes, die der Server zurückgeben kann, werden in Tabelle 13.22 gezeigt.


Tabelle 13.22   Einige wichtige HTTP-Statuscodes

Code Meldungstext Beschreibung
200 OK Dokument gefunden; wird geliefert.
204 No Content Anfrage akzeptiert, kein Dateninhalt.
301 Moved Permanently Die Dateien befinden sich unter einer neuen URL, die mitgeliefert wird.
304 Not Modified Seit dem letzten Aufruf wurde der Dokumentinhalt nicht geändert. Der Browser kann seine lokale Kopie verwenden.
401 Unauthorized Es ist eine persönliche Anmeldung mit Benutzername und Kennwort erforderlich.
403 Forbidden Zugriff verweigert; eine persönliche Anmeldung nützt auch nichts.
404 Not Found Dokument existiert nicht; meist Folge eines fehlerhaften oder veralteten Links.
500 Internal Server Error Ein serverseitiges Skript enthält einen schwerwiegenden Fehler.

Um die Anfrage, die oben per telnet manuell erstellt wurde, von einem Browser durchführen zu lassen, müssen Sie die URL http://www.galileocomputing.de in sein Adressfeld eintippen. Der Browser stellt eine Verbindung mit dem Standard-HTTP-Port des Hosts www.galileocomputing.de her und fordert, da kein konkreter Pfad angegeben wurde, das Wurzeldokument / an. Damit der Webserver auch dann ein Dokument ausliefern kann, wenn der Browser lediglich einen Verzeichnis-, aber keinen Dateinamen übermittelt hat, verwenden Webserver das Konzept des Standard- oder Index-Dokuments: Ein Dokument im angeforderten Verzeichnis, das einen speziellen Dateinamen besitzt, wird automatisch ausgeliefert. Der häufigste Name für ein solches Dokument ist index.htm beziehungsweise index.html.

URLs

Allgemein setzt sich eine URL aus dem Zugriffsverfahren beziehungsweise Anwendungsprotokoll, dem Hostname oder der IP-Adresse und dem Pfad des gewünschten Dokuments zusammen. Die Verwendung ist nicht auf HTTP beschränkt; es gibt beispielsweise auch FTP-URLs wie ftp://ftp.uni-koeln.de. Daneben existieren auch speziellere URL-Schemata wie diejenigen für E-Mail-Verweise in der Form mailto:E-Mail-Empfänger oder für Newsgroups, zum Beispiel news:comp.lang.java.beans. Solche besonderen URLs werden häufig als Link in HTML-Dokumenten verwendet. Die meisten Browser können entweder selbst damit umgehen oder es ist ein Zusatzprogramm konfiguriert, das automatisch geöffnet wird, wenn man einen solchen Link anklickt.

  

Einstieg in PHP 5

Einstieg in Java

C von A bis Z

Einstieg in C++

Einstieg in Linux

Einstieg in XML

Apache 2




Copyright © Galileo Press GmbH 2004
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de