Skriptum

Netzwerktechnologie 4: TCP/IP
Begleitmaterial zur Vorlesung NET 4 des FH-Studienganges
Bioinformatik
in Hagenberg
Sommersemester 2004
FH-Prof. Dipl.-Ing. Dr. Gerhard Jahn
email: [email protected]
1. April 2004
Inhaltsverzeichnis
1 Entstehung und Überblick
3
2 Schichtenmodell, Einordnung der Protokolle
4
3 Internet Layer
3.1 Aufgaben und Charakteristika . . . . . . .
3.2 IP-Header . . . . . . . . . . . . . . . . . .
3.3 Fragmentierung . . . . . . . . . . . . . . .
3.4 IP-Adressen . . . . . . . . . . . . . . . . .
3.5 Subnetting . . . . . . . . . . . . . . . . . .
3.6 ICMP – Internet Control Message Protocol
3.7 ARP und RARP . . . . . . . . . . . . . .
3.8 Classless Interdomain Routing (CIDR) . .
3.9 Network Adress Translation (NAT) . . . .
3.10 IPv6 – IP Version 6 . . . . . . . . . . . . .
4 Transport Layer
4.1 User Datagram Protocol (UDP) . . .
4.2 Einschub: Gesicherte Übertragung . .
4.3 Transmission Control Protocol (TCP)
4.3.1 Einführung . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
8
8
9
10
10
11
12
14
.
.
.
.
16
16
17
18
18
INHALTSVERZEICHNIS
4.3.2
4.3.3
Header von TCP . . . . . . . . . . . . . . . . . . . . . . . . . 19
Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . . 22
5 Domain Name Services (DNS)
5.1 Aufgabenstellung . . . . . . . . .
5.2 Lokale Datenbank . . . . . . . . .
5.3 Verteilte Datenbank . . . . . . .
5.3.1 Namensraum . . . . . . .
5.3.2 Name Server . . . . . . . .
5.3.3 Root Name Server . . . .
5.3.4 Resolver . . . . . . . . . .
5.3.5 Auflösung im Name Server
Literatur
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
26
26
26
27
27
27
29
1 ENTSTEHUNG UND ÜBERBLICK
3
Am Anfang schuf die Arpa das Arpanet.
Und das Arpanet war wüst und leer.
Und es war finster in der Tiefe.
Und der Geist der Arpa schwebte auf dem Netzwerk,
und die Arpa sprach: Es werde ein Protokoll.“
”
Und es ward ein Protokoll.
Und die Arpa sah, dass es gut war.
Und die Arpa sagte: Es seien mehr Protokolle.“
”
Und es geschah so.
Und die Arpa sagte: Es seien mehr Netzwerke.“
”
Und so geschah es.
[Hafner und Lyon 1996]
1
Entstehung und Überblick
Die Entstehung und Verbreitung der TCP/IP-Protokollfamilie ist eng mit UNIX
verbunden: Praktisch jedes UNIX-System enthielt auch immer eine Implementierung von TCP/IP. Mittlerweile ist der TCP/IP-Protokollstack auch bei praktisch
allen anderen Betriebssytemen zum Standard geworden. Auch das Internet basiert
auf TCP/IP. Die ursprüngliche Entwicklung initiierte das Department of Defence
(DoD), genauer die US Defense Advanced Research Projects Agency (DARPA) in
den frühen 70er Jahren. Dieses Netz der DARPA hieß ARPANET. Es verband Universitäten mit Einrichtungen des DoD und Industriepartnern. Ursprünglich umfasste
es nur eine kleine Anzahl von Netzwerken und Rechnern. Primär wurden damit auf
Applikationsebene die (rudimentären) Dienste Telnet, FTP und EMail realisiert.
Seit damals wächst dieses Netz ständig an. 1983 spaltete sich der militärische Teil in
ein eigenes Netzwerk (MILNET) ab, 1990 ging das ARPANET in das heute populäre
Internet über.
Der große Erfolg von TCP/IP liegt zum Teil an seinen grundlegenden DesignGedanken: Das DoD war an Protokollen interessiert, die ohne zentrale Wartung zu
betreiben sind. Zusätzlich soll ein solches Netzwerk fehlertolerant sein, d.h. auch
bei Ausfall einzelner Verbindungen soll das gesamte Netzwerk seine Funktionen zumindest noch eingeschränkt erfüllen können. Diese Anforderungen sind typisch für
Anwendungen im militärischen Bereich. Aber auch für ein an sich chaotisches Netzwerk wie das Internet – das praktisch ohne zentrale Wartung auskommt, bei dem
ständig neue Teilnetze und Rechner dazukommen und auch laufend Rechner stillschweigend entfernt werden – ist TCP/IP bestens geeignet.
Ein Großteil der Dokumente über TCP/IP und auch das Internet über Architektur, Protokolle und auch Geschichte liegt als Serie von Berichten den sogenannten
2 SCHICHTENMODELL, EINORDNUNG DER PROTOKOLLE
4
Request for Comments (RFCs) vor. Dabei handelt es sich um eine eher lose koordinierte Sammlung, die ziemlich bunt gemischt ist. Unter anderem finden sich in den
RFCs alle Festlegungen von TCP/IP wie Protokolle, vergebene Nummern, usw. Die
RFCs sind numerisch indizierte Texte, welche auf vielen Servern im Internet abgelegt sind. Ein RFC hat zu Beginn Vorschlagscharakter und wird nach einer gewissen
Diskussionsphase durch die Internetgemeinde zu einem verbindlichen Dokument.
Änderungen oder Klarstellungen zu einem RFC werden als neuer RFC – mit einer
neuen Nummer – herausgebracht. Dadurch steigt die Anzahl der RFCs ständig an,
derzeit sind es knapp 3500 (Stand März 2003). Jeder Server mit RFCs einhält aus
diesem Grund auch eine Liste der aktuellen RFCs mit Verweisen auf ältere RFCs
zum gleichen Thema (vgl. z.B. http://www.rfc-editor.org [RFC-Editor 2001]).
Dieses Dokument basiert im Wesentlichen auf den RFCs, [Tanenbaum 1998],
[Comer 1995], [Halsall 1996], [Hart und Rosenberg 1995], [Douba 1995], sowie diversen WWW- Seiten.
2
Schichtenmodell, Einordnung der Protokolle
Wie jede andere Protokollfamilie, besteht TCP/IP aus hierarchisch angeordneten
Schichten, die jeweils bestimmte Teilaufgaben übernehmen. Damit wird die Komplexität der gesamten Aufgabe geordnet in kleinere Problembereiche zerlegt. Verglichen
zum OSI-Modell für offene Kommunikation ist das Modell von TCP/IP wesentlich
einfacher: Es besitzt statt sieben Schichten lediglich vier. Zu jeder dieser Schichten
gehört in der Regel mehr als ein Protokoll:
• Der Application Layer ist die oberste Ebene, er entspricht im OSI-Modell
den Schichten 5 bis 7. Hier sind die Applikationsprotokolle wie Telnet, SMTP
(Simple Mail Transfer Protocol für EMail), FTP (File Transfer Protocol) usw.
enthalten.
• Der Transport Layer oder Host to Host Layer ist die Basis der Applikationsprogramme. Er geht von einer existierenden Verbindung zwischen den Endteilnehmern (Hosts) im Netzwerk aus. Der Host to Host Layer kümmert sich
um die Zustellung zu den richtigen Prozessen innerhalb des Zielrechners. Vertreter sind hier die Protokolle UDP (User Datagram Protocol, ungesichert und
verbindungslos) und TCP (Transmission Control Protocol, gesichert und verbindungsorientiert). Der Transport Layer entspricht der gleichnamigen Schicht
4 des OSI-Modells.
• Die Basis für den Transport Layer ist der Internet Layer. Das wichtigste
Protokoll ist hier IP (Internet Protocol ). Seine primäre Aufgabe ist die Über-
3 INTERNET LAYER
5
tragung von Nachrichten zwischen Endgeräten über ein Netzwerk von Routern. IP ist für die Router transparent: Router verwendet die Informationen
im IP-Header. IP ist datagramm-orientiert, d.h. die Zustellung erfolgt ohne
Verbindungsaufbau und wird von IP nicht garantiert. Wichtige Aufgaben sind
die korrekte Adressierung, das Weiterleiten zu den richtigen Vermittlungsknoten (Routing) und ggf. die Fragmentierung und Defragmentierung der zu
übertragenden Nachrichten. Weitere Protokolle sind ARP (Address Resolution Protocol) und ICMP (Internet Control Message Protocol). Im OSI-Modell
entspricht der Internet Layer der Schicht 3.
• Den Abschluß nach unten bildet der Network Access Layer, er entspricht
nach OSI den Schichten 1 und 2. Wie z.B. Netware von Novell, setzt auch
TCP/IP auf bekannten und bewährten Schicht-2-Protokollen wie Ethernet,
Token Ring u. ä. auf.
Die Bezeichnung TCP/IP steht für die gesamte Protokollfamilie, Namensgeber
waren hier zwei der wichtigsten Protokolle.
3
3.1
Internet Layer
Aufgaben und Charakteristika
Die Schicht 3 aus dem ISO/OSI-Modell ist für die Kommunikation zwischen Geräten
zuständig, die nicht direkt miteinander verbunden sind. Der Internet Layer ist das
Gegenstück dazu. Hier sind zwei Protokolle angesiedelt. Sie haben die folgenden
Aufgaben:
Internet Protocol (IP)
• Routing der IP-Datagramme
• Adressierung der Rechner
• ggf. Fragmentierung
• keine End-to-End-Sicherung zwischen Sender und Empfänger
• aber: meist Punkt-zu-Punkt-Sicherung durch Schicht 2
• Prüfsumme nur über Header, nicht über Daten
• endliche Lebensdauer der Datagramme vermeidet Zyklen
• Best Effort Zustellung
Internet Control Message Protocol (ICMP)
• Source Quench zur Flusskontrolle (veraltet)
3 INTERNET LAYER
6
• Host unreachable: Problem beim Routing
• Echo request / echo reply: Kommando Ping
• ... (diverse Management-Aufgaben)
3.2
IP-Header
IP ist verbindungslos, d.h. vor dem Senden der eigentlichen Daten muss die Verbindung nicht aufgebaut werden. Damit ist es mit dem IPX-Prototokoll von NetWare
vergleichbar.
Der Header ist in Blöcke zu je 32 Bit unterteilt und besteht aus einem festen
Teil mit 5 x 32 Bit und ev. weiteren Optionen. Falls notwendig wird der Platz hinter
den Optionen mit Füllbytes auf ein Vielfaches von 32 Bit aufgefüllt. Die Felder des
Headers:
Version (4 Bit) enthält die Version des IP-Layers der abgebenden Stelle. Dieses
Feld bestimmt damit die Struktur der nachfolgenden Datenfelder. Damit kann
gleichzeitig mit unterschiedlichen Versionen gearbeitet werden. Derzeit ist die
Version 4 in Verwendung (Codierung 0100 binär).
Header Length (4 Bit) gibt die tatsächliche Länge des Header in 32-bit Worten
an. Der Header kann ja wegen der Optionen auch mehr als 5 Worte zu je 32
Bit enthalten.
Type of service enthält Informationen über die gewünschten Übertragungswege.
Diese Daten werden von Routern bei alternativen Wegen berücksichtigt. Konkret besteht Type of service aus den Einzelfeldern:
Precedence (3 Bit) nimmt die Priorität (0 − 7) des Paketes auf.
Low delay (1 Bit) signalisiert ein Paket, bei dem auf geringste Verzögerungszeiten zu achten ist (z.B. bei telnet).
High throughput (1 Bit) zeigt an, daß hier auf hohen Durchsatz zu achten
ist (z.B. ftp).
High reliability (1 Bit) zeigt an, daß hier eine Verbindung mit hoher Zuverlässigkeit zu wählen ist.
Unused (2 Bit); die letzten beiden Bit des Feldes Type of service sind ungenutzt.
Total length (16 Bit) enthält die Gesamtlänge des Datagrammes inkl. Header und
Nutzdaten. Die maximale Länge ist 216 Bytes.
Identification (16 Bit) identifiziert das Datagramm eindeutig. Damit kann ein
längeres Datagramm auf mehrere – der darunterliegenden Schicht 2 genehme
3 INTERNET LAYER
7
– Fragmente zerlegt werden. Alle Fragmente haben dann den gleichen Wert in
Identification.
Bit flags (3 Bit) ist ein Feld mit 3 Bit, von denen nur die ersten beiden genutzt
werden:
Don’t fragment, D bit wird wieder von Routern benutzt: Ein gesetztes Dbit zeigt an, dass ein Router eine Alternative wählen muss, deren Schicht
2 das vorliegende Datagramm als Ganzes übertragen kann.
More fragments, M bit Ist für das Zusammenstellen der Fragmente in ZielHost wichtig: Ein gesetztes M-bit zeigt an, dass zu diesem Datagramm
noch weitere Fragmente folgen.
Fragment offset (13 Bit) zeigt die Lage des vorliegenden Fragmentes im gesamten
Datagramm an. Der Wert von fragment offset entspricht dem Offset in Bytes
vom Anfang geteilt durch 8. (Hinweis: Ein Fragment enthält immer einen Datenteil, dessen Länge durch 8 teilbar ist. Die einzige Ausnahme ist das letzte
Fragment eines Datagrammes.)
Time-to-live (8 Bit) definiert die maximale Zeit, die ein Datagramm für die Zustellung zum Zielrechner (Destination Host) benötigen darf. Der Wert – angegeben
in Sekunden – wird vom Quellrechner (Source Host) gesetzt. Da die tatsächliche Zeit schwer zu bestimmen ist, dekrementiert jeder Router den Wert von
time to live um einen bestimmten Wert – in der Regel um 1. Damit gibt dieses
Feld eigentlich die Anzahl der möglichen hops zum Zielrechner an. Erreicht
time to live vor seiner Ankunft im Zielrechner den Wert 0, so entfernt der
aktuelle Router das Datagramm vom Netzwerk. Damit werden zirkulierende
Pakete, die durch schlecht eingestellte Router entstehen können, eliminiert.
Protocol (8 Bit) zeigt das höhere Protokoll – den Benutzer der IP-Schicht – an.
Damit ist die Zustellung im Zielrechner zur richtigen höheren Schicht möglich.
Konkret steht 1 für ICMP, 6 für TCP und 17 für UDP. Details dazu enthält
der RFC 1700 (Assigned Numbers).
Header checksum (16 Bit) ist die Prüfsumme über den Header, jedoch nicht über
die Daten. Eigentlich fällt diese Aufgabe in den Bereich der Schicht 2. Da
jedoch fehlerhafte Daten im Header unter Umständen beim Routing zu völlig
falschen Wegen führen können, wird diese Information in IP noch zusätzlich
gesichert.
Source IP address, Destination IP address (jeweils 32 Bit) identifizieren
Quell- und Zielrechner.
Options nimmt ggf. weitere Optionen über z.B. die folgenden Themen auf:
3 INTERNET LAYER
8
Security: Die Daten sind vertraulich zu behandeln.
Source routing: Der Quellrechner bestimmt selber die zu wählende Route
zum Zielrechner.
3.3
Fragmentierung
Ein IP-Datagramm kann maximal 64 kByte lang werden. Ethernet lässt z.B. aber
in den meisten Varianten nur Frames mit max. 1500 Byte Payload zu. In solchen
Fällen zerlegt (fragmentiert) IP ein Datagramm in mehrere Frames. Dies kann auch
bei einem Router geschehen, der Pakete aus einer Verbindung mit hoher maximaler
Paketgröße empfängt und in eine Verbindung mit geringerer maximaler Paketgröße
weiterleitet. Prinzipiell fügen umgekehrt Router die einzelnen Fragmente nicht mehr
zusammen. Dies macht lediglich der Zielrechner: Erst wenn alle Fragmente eines Datagrammes bei ihm eintreffen, gibt er das Datagramm an seinen Benutzer weiter. Bei
einem Router würde dieses Defragmentieren viel Speicherbedarf und hohe Verzögerungszeiten verursachen. Die bei IP gewählte Variante bei der Fragmente erst am
Ziel zusammengefügt werden, nennt man internet fragmentation. Sie hat gegenüber
der intranet fragmentation den Nachteil, dass beim Übergang von Verbindungen mit
kurzer maximaler Frame-Länge zu Verbindungen mit höherer Frame-Länge trotzdem
weiter kurze Frames übertragen werden. Allerdings ist besonders bei ungesicherten
Protokollen – wie IP – das Sammeln der Fragmente in Routern eine aufwändige
Aufgabe bzw. wegen eventuell vorhandener alternativer Wege gar nicht möglich.
3.4
IP-Adressen
Jeder Host oder Router im gesamten Netzwerk (z.B. dem Internet) bekommt eine
numerische IP-Adresse, die ihn eindeutig identifiziert. Maschinen, die an mehrere
Netze angeschlossen sind, haben auch in jedem Netz eine eigene IP-Adresse. Diese
Adressen sind 32 Bit breit. Damit ist die Adressierung in IP und den darüber liegenden Schichten unabhängig von den Adressen der verwendeten Schicht 2. Meist
werden die einzelnen Bytes einer Adresse dezimal mit einem Punkt als Trennzeichen
notiert (dotted decimal ). Die Adresse besteht aus einem Teil für das Netzwerk und
einem Teil, der den Rechner innerhalb des Netzwerkes identifiziert. Alle Rechner
im gleichen Netzwerk – die direkt (d.h. ohne Router) miteinander kommunizieren
können – führen in ihren Adressen den gleichen Wert im Netzwerkteil. Auf dieser
Konvention basiert das Routing. Um Netzwerke unterschiedlicher Größe realisieren zu können, ist die Grenze zwischen Netzwerk-Nummer und Host-Nummer in
den Adressen innerhalb gewisser Grenzen variabel. Primär existieren die folgenden
Klassen von Adressen:
3 INTERNET LAYER
9
Klasse A: Die Adresse beginnt mit einer binären 0, gefolgt von 7 Bit für die Kennung des Netzwerkes. Die restlichen 3 Bytes identifizieren den Rechner innerhalb des Netzwerkes. Gültige Netzwerk-Nummern gehen von 0 bis 126, der
Wert 127 ist unabhängig von der aktuellen Klasse für das lokale Netzwerk
reserviert.
Klasse B: Die ersten beiden Bit enthalten die Kombination 10, die nächsten 14 Bit
bestimmen das Netzwerk. Damit verbleiben 16 Bit für die Rechner-Nummer.
Klasse C: Die Adresse beginnt mit 110, für das Netzwerk sind die nächsten 21 Bit
vorgesehen. Der Rechner wird innerhalb des Netzwerkes mit dem verbleibenden Byte identifiziert.
Klasse D: Dieser Bereich ist für Multicasts vorgesehen. Multicast-Adressen beginnen mit dem Bitmuster 1110, die restlichen 28 bit sind die eigentliche
Multicast-Adresse.
Klasse E: Adressen, die mit dem Bitmuster 11110 sind für künftige Nutzungen
reserviert.
Bei den Klassen A, B und C sind im hinteren Teil der Adresse – also bei den
Hostnummern – zwei Werte reserviert:
• Eine Adresse, mit einer Host-ID 0 bezieht sich allgemein auf das Netzwerk und
nicht auf einen bestimmten Host.
• Umgekehrt steht eine Adresse, bei der alle Bit der Host-ID gesetzt sind, für
alle Rechner dieses Netzwerkes.
Diese Konventionen schränken die Anzahl der möglichen Rechner in einem Netzwerk noch ein, so kann z.B. ein Netzwerk der Klasse C bis zu 254 Hosts enthalten.
3.5
Subnetting
In manchen Fällen ist eine Unterteilung eines aufgrund der Klasse großen oder mittleren Netzwerkes in mehrere kleine Netzwerke sinnvoll. Ein Beispiel ist die Unterteilung einer größeren Organisation in Divisionen oder Abteilungen. Dann wird die
Grenze zwischen Netzwerk-ID und Host-ID um ein oder mehrere Bit nach rechts
verschoben. Nach außen ändert sich nichts: Die einzelnen Netzwerke treten für externe Hosts und Router als ein gemeinsames Netzwerk auf. Lediglich der Router zum
Umfeld und die lokalen Hosts müssen mit einer geänderten Grenze, d.h. geänderten
Subnet-Mask arbeiten.
3 INTERNET LAYER
10
Nachrichtentyp
Beschreibung
Destination Unreachable
Ein Paket kann nicht zugestellt werden, da entweder
das Zielnetz oder der nächste Router nicht gefunden
wurde.
Das Feld Time to Live erreichte 0, das Paket läuft
vermutlich im Kreis.
Ungültiger IP-Header
Nachricht zur Flusskontrolle (veraltet), damit soll der
Empfänger der ICMP-Nachricht zu einer Drosselung
veranlasst werden.
Der Sender dieser ICMP-Nachricht ist der Meinung,
dass ein Paket fälschlicher Weise an ihn gerichtetet
wurde. Er weist damit den Sender des Paketes auf
einen möglichen Fehler hin.
Anklopfen bei einem Host oder Router (ping)
Antwort auf Echo Request
wie Echo Request, zusätzlich mit Zeitstempel
Antwort auf Timestamp Request
Timer Exeeded
Parameter Problem
Source Quench
Redirect
Echo Request
Echo Reply
Timestamp Request
Timestamp Reply
Tabelle 1: Wichtige ICMP-Meldungen
3.6
ICMP – Internet Control Message Protocol
Neben IP existieren im Internetlayer einige andere Protokolle, die für Managementaufgaben zuständig sind. Eines davon ist ICMP, es wird von den Routern verwendet,
um aussergewöhnliche Ereignisse zu melden. Auch Hosts können mit ICMP-Paketen
die Erreichbarkeit anderer Hosts testen. ICMP-Nachrichten werden in IP-Frames
eingepackt. Die Tabelle 1 zeigt einige wichtige Typen von ICMP-Nachrichten.
3.7
ARP und RARP
IP muss zur Datenübertragung die darunterliegende Schicht 2 (Network Access
Layer in TCP/IP-Terminologie) verwenden. Die Schicht 2 führt aber eigene Adressen
(die sog. MAC-Adressen od. Kartennummern) ein, die nicht mit den IP-Adressen
kompatibel sind und auch keine Rückschlüsse auf das Netzwerk, in dem sich ein
bestimmter Rechner befindet, zulassen.
Allerdings kann der Internet-Layer durch einen Vergleich der IP-Adresse des
Kommunikationspartners mit der eigenen IP-Adresse feststellen, ob er die Nachricht
direkt zustellen kann oder ob er dazu einen Router benötigt. Bei der Direktzustellung
muss der IP-Layer die MAC-Adresse des Ziel-Host erfahren, bei der Zustellung über
3 INTERNET LAYER
11
einen Router ist die MAC-Adresse des Routers gefragt.
Die Zuordnung zwischen MAC-Adresse und IP-Adresse eines Host wird nicht
im Netzwerk zentral abgelegt, sondern mit dem Address Resolution Protocol
(ARP) ermittelt. Vorraussetzung dazu ist, dass jeder Host die eigene IP-Adresse
und auch die eigene MAC-Adresse kennt. Die MAC-Adressen sind nur für die Rechner im gleichen Netz interessant, sie werden nach außen nicht bekannt gegeben.
Um die MAC-Adresse zu einer bekannten IP-Adresse eines Fremdrechners (im
gleichen Netzwerk!) zu erfahren, setzt ein Rechner einen Schicht-2-Broadcast ab.
Hier ein Szenario am Beispiel Ethernet:
• ARP-Request von Rechner aaa.aaa.aaa.aaa / Kartennummer xx-xx-xx-xx-xxxx an Kartennummer ff-ff-ff-ff-ff-ff mit dem Inhalt: Ich will wissen, welche
Kartennummer der Rechner bbb.bbb.bbb.bbb hat!
• Alle Rechner im Netzwerk hören diese Broadcast-Nachricht, der Rechner
bbb.bbb.bbb.bbb reagiert jedoch als einziger darauf:
• ARP-response von Rechner bbb.bbb.bbb.bbb an aaa.aaa.aaa.aaa mit dem Inhalt: Meine Kartennummer ist yy-yy-yy-yy-yy-yy.
Gleichzeitig hat so auch der Zielrechner die Kartennummer des ersten Rechners
erfahren. Der Internet-Layer speichert die so erfahrenen Daten in einem Cache.
Damit werden weitere Zugriffe innerhalb des Netzwerkes beschleunigt. In Unix zeigt
das Kommando arp -a den aktuellen Inhalt des Cache an.
Auch für den umgekehrten Weg, also die Umsetzung der Kartennummer zur
IP-Adresse existiert ein Prokoll, das Reverse Address Resolution Protocol. Es
wird vor allem von Discless Workstations verwendet, die von einem Startprogramm
auf der Netzwerkkarte hochfahren.
3.8
Classless Interdomain Routing (CIDR)
Mit dem rasanten Wachsen des Internet in den letzten Jahren ist die Anzahl der
Rechner und damit auch der Bedarf an IP-Adressen gestiegen. Dazu kommt noch,
dass durch die starre Einteilung in die Klassen A, B und C viele Adressen vergeudet
werden. Die Vergabe mehrerer Netze der Klasse C an eine einzige Organisation bläht
die Routing-Tabellen auf und belastet dadurch die Router zusätzlich.
Eine kurzfristige Erleichterung schafft hier das Classless Interdomain Routing
(vgl. RFC 1519). Es weicht die starren Grenzen zwischen den Klassen auf und erlaubt
so die Vergabe von Netzen individueller Größe. Dazu ist es notwendig, dass zu jeder
Netz-ID auch die Subnetmask angegeben wird. In der Praxis findet man häufig
stattdessen die Anzahl der (führenden) binären 1er in der Subnetmask. So benutzen
3 INTERNET LAYER
Adressbereich
194.0.0.0 - 195.255.255.255
198.0.0.0 - 199.255.255.255
200.0.0.0 - 201.255.255.255
202.0.0.0 - 203.255.255.255
12
Kontinent
Europa
Nordamerika
Mittel- und Südamerika
Asien und Pazifischer Raum
Tabelle 2: Regionale Trennung für Netze der Klasse C
die FH-Studiengänge in O.Ö. derzeit das Netz 193.170.124.0/22, was für die Netze
193.170.124.0 bis 193.170.127.0 steht.
Um die Routing-Tabellen nicht zu stark wachsen zu lassen, existiert ein Plan für
die weitere Vergabe der noch freien Netze der Klasse C nach regionalen Kriterien,
den Zonen (vgl. Tabelle 2). Damit benötigt ein Router lediglich genaue Kenntnis
über die Netze in seiner Zone. Von Netzen anderer Zonen reicht die Kenntnis des
Standard-Routers für diese Zone.
3.9
Network Adress Translation (NAT)
Hinweis: Dieser Abschnitt gehört inhaltlich zum Internet Layer, setzt
jedoch Fachwissen über den Transport Layer von TCP/IP – vor allem
die Ports und deren Rolle bei der Kommunikation – vorraus.
Wenn jedem Host weltweit eine eindeutige Adresse zugewiesen wird, gehen die
IP-Adressen bald aus. Neben CIDR hilft vor allem die hier beschriebene Adressumsetzung das Problem der ausgehenden IP-Adressen um einige Jahre zu verschieben.
Zu jeder Klasse (A, B und C) wurden von der IANA einige IP-Adressen für die
lokale bzw. private Nutzung reserviert (vgl. den RFC 1918). Es sind dies die Netze:
• 10.0.0.0 - 10.255.255.255 (10/8 prefix)
• 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Mit privater Nutzung ist gemeint, dass solche Adressen zwar lokal und ohne Absprache mit anderen Organisiationen verwendet werden können aber nicht am Internet
aufscheinen dürfen. Für Netze ohne Internetanbindung sind natürlich keine weiteren
Maßnahmen notwendig. Wenn ein solches Netz aber auch an das Internet angebunden ist, muss an der Schnittstelle d.h. dem Router zum Internet eine Umsetzung
der Adressen erfolgen. Neben einigen anderen Vorteilen (vgl. unten) können sich
so mehrere Hosts eines lokalen Netzes wesentlich weniger öffentliche IP-Adressen
3 INTERNET LAYER
13
teilen. Für die lokale Kommunikation ist hingegen keine Umsetzung der Adressen
notwendig.
Prinzipiell existieren mehrere Arten der technischen Realisierung:
1. Single Pool: Die NAT-Realisierung besitzt einen Pool von öffentlichen IPAdressen, aus dem jeweils eine Adresse bei Bedarf einem lokalen Host temporär
zugeordnet wird.
2. Multiple Pool: Diese Variante entstand historisch aus der Vorhergehenden.
Werden bei Single Pool nachträglich weitere öffentliche IP-Adressen vom Provider angefordert, so liegen diese praktisch immer in einem anderen Adressbereich. Jedem Adressbereich wird ein Pool zugeordnet.
3. Port Adress Translation (PAT): Dies ist die gebräuchlichste Form. Hier
verwenden mehrere lokale Hosts sehr viel weniger öffentliche IP-Adressen gemeinsam und gleichzeitig. Meist wird nur eine einzige IP-Adresse – nämlich
die des Routers – benötigt. Zur Unterscheidung der gebündelten Verbindungen
wird zusätzlich die verwendete Port-Nummer des lokalen Hosts herangezogen.
Die NAT-Komponente verwaltet die Requests in einer Tabelle und ersetzt die
Quell-Adresse und den Quell-Port des Requesters durch die eigene (externe)
Adresse und einen eigenen freien Port. Der angesprochene externe Host sieht
so den Router als Requester und antwortet auch diesem. Die Response wird
von der NAT-Komponente anhand des Tabelleneintrages wieder manipuliert
(Adressdaten des lokalen Host als Ziel-Adresse und Ziel-Port eintragen) und
kann dem lokalen Host zugestellt werden. Erst wenn viele lokale Hosts mit
PAT konzentriert werden, ist das Verwenden mehrerer öffentlicher IP-Adressen
sinnvoll. Hier werden – aus Sicht des Client – die Quelladressen geändert,
deshalb heißt dieses Verfahren auch Source NAT.
Probleme bereiten manche Applikationsprotokolle, bei denen mehrere Ports
gemeinsam mit einer weiteren Initiierung durch den Server vorkommen wie
z.B. FTP im active mode.
Allen drei Lösungen ist gemein, dass an den Hosts keine Änderungen notwendig
sind. NAT bedarf lediglich einer Manipulation der Pakete am Router.
Die Tabelleneintragungen erfolgen dynamisch. Lokal vorhandene Server sind
zunächst nicht von außen erreichbar. Für sie werden zusätzlich statisch weitere
öffentliche IP-Adressen in der NAT-Komponente definiert. Die Server selber behalten die private IP-Adresse. Aus Sicht des Client werden hier Zieladressen geändert,
deshalb heißt dieses Verfahren auch Destination-NAT. Manchmal werden auch einzelne Ports des öffentlich zugänglichen Gateway auch bestimmte interne Server weiter geleitet. Clients erreichen diese eigentlich internen Server dann über die öffentliche Adresse des Gateway. Man spricht dann von Port Forwarding.
3 INTERNET LAYER
14
Neben der entsprechenden Einsparung an öffentlichen IP-Adressen ist ein weiterer entscheidender Vorteil, dass Hosts ohne eine aktuelle Verbindung nach außen
von außerhalb des Netzes nicht erreichbar sind. Damit sind sie natürlich vor externen Angriffen geschützt. Dies ersetzt zwar keine Firewall, zeigt aber Ansätze in
Richtung Sicherheit. Auch ein gewisser Schutz vor dem Missbrauch von lokaler Seite ist vorhanden: Ohne entsprechende Konfiguration der NAT-Komponente können
lokal keine öffentlich erreichbaren Server installiert werden. Öffentliche IP-Adressen
werden nicht verschenkt, NAT führt hier zu Einsparungen.
Ein Nachteil von NAT ist natürlich der Aufwand für die Konfiguration. Die
eigentliche Umsetzung belastet den Router zusätzlich und führt zu einer – meist
kaum merkbaren – zusätzlichen Verzögerung.
3.10
IPv6 – IP Version 6
Das Problem der ausgehenden IP-Adressen kann mit CIDR und NAT um einige
Jahre hinausgeschoben werden, allerdings muss langfristig eine andere Lösung gefunden werden. Zusätzlich werden an das Internet ganz neue Anforderungen gestellt:
Einerseits betrifft es die Sicherheit und Vertraulichkeit der übertragenen Daten –
IP bietet in der derzeit verwendeten Version 4 hier praktisch nichts – andererseits
werden oft nicht nur Daten im klassischen Sinn übertragen. Ein Beispiel ist Videoon-Demand. Die wesentlichen Ziele bei der Entwicklung einer neuen Version für IP
waren:
• Eignung für Milliarden von Hosts
• möglichst kurze Routing-Tabellen
• bessere Sicherheit (Authentifikation und Datenschutz)
• echte Unterstützung von Dienstarten, speziell für Echtzeitanforderungen
• gleitender Übergang d.h. Koexistenz mit alter Version über Jahre
Die Arbeit an der neuen Version begann 1990, der RFC 2460 beschreibt IPv6.
Hier die wichtigsten Merkmale:
• Adressen sind 16 Byte lang. Damit ist die Anzahl der verwaltbaren Hosts
praktisch unbegrenzt.
• Der Header wurde vereinfacht. Er enthält zunächst nur 7 Felder. Das erleichtert
die Arbeit für Router. Bisher zwingend vorhandene Felder sind jetzt optional
und können in Erweiterungs-Headern angegeben werden.
• Die Sicherheit wurde erhöht: IPv6 erlaubt die Authentifizierung und Verschlüsselung.
3 INTERNET LAYER
15
• Die schon in der Version 4 ansatzweise vorhandenen Dienstarten wurden ausgeweitet.
Jedes Datagramm beginnt mit dem Hauptheader. Er enthält die folgenden Felder:
Version (4 Bit) Hier steht der Wert 6. Damit kann in der Übergangsphase gleichzeitig auch noch mit der alten Version gearbeitet werden.
Traffic Class (8 Bit) Hier soll dem Paket eine bestimmte Klasse oder Priorität
zugewiesen werden. Details sind noch in Ausarbeitung. Neben einer Prioritätsangabe wird auch zwischen Paketen mit Flusssteuerung und solchen ohne Flusssteuerung unterschieden. Die Übertragung mit Flusssteuerung kann
und soll sich bei Überlastung verlangsamen. Bei Echtzeitübertragung (ohne
Flusssteuerung) soll eine konstante Übertragungsrate eingehalten werden. Im
Überlastfall dürfen dann auch Pakete verloren gehen. In diese Kategorie fallen
z.B. die Echtzeitübertragung von Audio und Video.
Flow Label (20 Bit) Mit diesem Feld soll den Routern eine spezielle Behandlung
dieses Paketes abverlangt werden, die sich nicht im Feld Traffic Class spezifizieren läßt. Die genaue Bedeutung dieses Feldes ist noch immer nicht festgelegt.
Payload Length (16 Bit) Dieses Feld gibt die Länge der diesem Header folgenden
Nutzdaten an, es erfüllt damit die gleiche bzw. eine ähnliche Aufgabe wie das
Feld Total Length in der Version 4.
Next Header (8 Bit) Hier steht die Kennung des nächsten Headers. Damit können
weitere Header mit optionalen Feldern folgen. Im letzten Erweiterungs-Header
enthält dieses Feld die Kennung des Transportprotokolls dieses Paketes. Derzeit sind die folgenden Erweiterungs-Header definiert:
• Optionen für Teilstrecken (Unterstützung für sehr große Datagramme
> 64 kB)
• Source Routing
• Fragmentierung
• Authentifikation
• Verschlüsselung
Hop Limit (8 Bit) Hop Limit entspricht dem Feld Time to Live.
Source Address, Destination Address (jeweils 16 Byte) Hier werden Quellund Zieladresse angegeben. Der riesige Adressraum ist in Bereiche unterteilt.
Die Tabelle 3 auf der nächsten Seite zeigt Teile des gesamten Adressraums.
4 TRANSPORT LAYER
Präfix (binär)
Verwendung
0000
010
100
1111
1111
1111
reserviert (einschließlich IPv4)
Adressen für Service Provider
Adressen für geographische Bereiche
Verbindungsspezifische lokale Adressen
Standortspezifische lokale Adressen
Multicast
0000
1110 10
1110 11
1111
16
Bruch (Anteil
am Adressraum)
1/256
1/8
1/8
1/1024
1/1024
1/256
Tabelle 3: Auszug IPv6 Adressraum
4
Transport Layer
Der Transport oder Host-to-Host Layer verbindet Applikationen, d.h. er geht von
einer existierenden Verbindung zwischen den beteiligten Stationen aus. Er enstpricht
im OSI-Modell der Schicht 4 (Transport).
Dazu stützt sich dieser Layer auf dem Protokoll IP aus dem Internet Layer ab.
Bei IP werden die Stationen durch die IP-Adresse identifiziert. Der Host-to-Host
Layer verfeinert Adressen mit ports. Sie kennzeichnen die Applikationen innerhalb
der Rechner. Die Applikationen können aus zwei Protokollen mit unterschiedlichen
Charakteristika auswählen:
Das User Datagram Protocol (UDP) übernimmt im Wesentlichen die Eigenschaften von IP. Es arbeitet verbindungslos nach einer best-try-Philosopie. Damit wird die Übertragung nicht garantiert. Das Transmission Control Protocol
(TCP) erweitert die Funktionalität von IP. Es garantiert Zustellung und richtige
Reihenfolge der Nachrichten. Auch eine Flusskontrolle ist vorhanden. Damit wird
verhindert, dass ein schneller Sender einen langsamen Empfänger unnötig überlastet.
Zur Unterscheidung dieser beiden Protokolle wird das Feld Protocol im IP-Header
verwendet (vgl. Abschnitt 3.2 ab Seite 6).
4.1
User Datagram Protocol (UDP)
UDP übernimmt die Fähigkeiten von IP und zeichnet sich deshalb durch einen
minimalen Overhead und einen guten Durchsatz aus. Es arbeitet verbindungslos,
zwischen den einzelnen Datagrammen besteht keine Beziehung. Die Abbildung 1 auf
der nächsten Seite zeigt den Header von UDP. Er folgt unmittelbar nach dem IPHeader. An ihn sind die Applikationsdaten angefügt. Die Felder im Einzelnen:
Source Port (16 Bit) kennzeichnet die sendende Applikation. Falls keine Antwort
auf eine Nachricht erwartet wird, kann seine Angabe auch entfallen. Dann hat
4 TRANSPORT LAYER
1
2
3
4
17
5
6
7
8
9
10 11 12 13 14 15 16
Source port
Destination port
Length
Checksum
Abbildung 1: UDP-Header
Source Port den Wert 0.
Destination Port (16 Bit) kennzeichnet die angesprochene Applikation. Er muss
in jedem Fall angegeben werden.
Length (16 Bit) enthält die Anzahl der Oktetts (Bytes) im ganzen UDPDatagramm, d.h. inkl. Header.
Checksum (16 Bit) ist die Prüfsumme über Daten und Header. Sie ist notwendig,
da ja IP zwar eine eigene Prüfsumme mitführt, diese jedoch nur den IP-Header
abdeckt. Die Angabe der Prüfsumme kann auch entfallen, dann hat Checksum
den Wert 0.
Die sendende Applikation muss die Adressdaten der empfangenden Station (IPNummer und Port-Nummer) selbst kennen. Ihre Ermittlung ist nicht Aufgabe des
Host-to-Host-Layers, dies fällt sowohl bei UDP als auch bei TCP in den Aufgabenbereich der Applikationen. Bei einer typischen Client-/Server-Applikation meldet
der Server zunächst seine Dienste an einem bestimmten lokalen Port an. Der Port
wird dabei von der Applikation vorgegeben. Nur so kann der Client dann später
die Server-Applikation ansprechen. Für Standard-Applikationen wie Telnet, FTP,
. . . sind vordefinierte Ports festgelegt, die auch Well Known Ports heißen (vgl. unter
Unix die Datei /etc/services). Ein Client bekommt bei der Kontaktaufnahme mit
dem Server einen eigenen lokalen Port dynamisch zugewiesen.
4.2
Einschub: Gesicherte Übertragung
Im Gegensatz zu UDP garantiert TCP die Übertragung d.h. fehlerhafte Pakete werden als solche erkannt und – auch bei völligem Verlust der Pakete – wiederholt. TCP
verwendet dazu ein ausgeklügeltes Verfahren, wobei sich die Güte dieses Verfahrens
nicht in seiner Korrektheit und Robustheit – diese werden ohnehin vorausgesetzt
– sondern in seiner Effizienz im Sinne von Performanz ausdrückt. Zum besseren
4 TRANSPORT LAYER
18
Verständnis von TCP werden zunächst die Basisverfahren untersucht. Es wird hier
auf die entsprechende Literatur verwiesen [Halsall 1996, S. 170-200]. An dieser Stelle
erfolgt lediglich eine kurze Übersicht mit Stichworten. Sie soll das Durcharbeiten der
entsprechenden Seiten erleichtern.
• Einführung
– Einordnung in 7-Schichtenmodell
– Varianten (gesichert vs. best try)
• Idle-RQ [Halsall 1996, S. 170 – 174]
– implicit retransmission
– explicit retransmission
• Continous RQ [Halsall 1996, S. 188 – 200]
– Selective Repeat
– Go-Back-N
– Flusskontrolle
• Realisierung (Schichtenarchitektur)
– Primitives, Services, Event Control Blocks
– Schichten und Warteschlangen zur Kommunikation zwischen den Schichten
– Realisierung als single task (Hauptschleife mit Pseudo Tasks)
– Remote und local Services
4.3
4.3.1
Transmission Control Protocol (TCP)
Einführung
Der Einsatz von UDP ist immer dann sinnvoll, wenn eine Quittierung und die ev.
notwendige Fehlerbehandlung nicht notwendig ist. Dies trifft vor allem bei einmaligen und kurzen Nachrichten zu. In den meisten Fällen wird jedoch gerade auf solche
Eigenschaften besonders Wert gelegt. Auch das Einhalten der richtigen Reihenfolge
ist meist wichtig. All diese Anforderungen erfüllt TCP.
Es betrachtet die zu übertragenden Nachrichten als einen konsekutiven Strom
von Daten (Oktetts) der mit dem Verbindungsaufbau beginnt und erst beim Verbindungsabbau endet. Genauer kann TCP zwei solcher Datenströme auf einer Verbindung gleichzeitig übertragen: TCP arbeitet bidirektional. Die Flusskontrolle verhindert das Überlasten des Empfängers. Die TCP-Komponente einer empfangenden
4 TRANSPORT LAYER
19
Station kann das Senden von Nachrichten durch die abgebende Station verzögern,
falls die Empfangspuffer zu stark belastet werden.
TCP überträgt den Datenstrom in Einheiten (Segmenten). Dabei bestimmt ein
TCP-Sender in der Regel selbständig wie groß die einzelnen Segmente sind. Der
TCP-Empfänger legt die eingehenden Segmente in einem Empfangspuffer ab und
gibt den Inhalt im allgemeinen erst an die Applikation weiter, wenn der Puffer voll
ist. Ein Segment kann daher mehrere Nachrichten enthalten (bei kurzen Nachrichten). Andererseits kann – im Fall von langen Applikationsdaten, wie ganzen Dateien
– ein Segment auch nur einen Teil der Applikationsnachricht enthalten. Der Benutzer von TCP hat jedoch noch die Möglichkeit einer Einflussnahme: Parameter an
der Schnittstelle zu TCP gestatten den sofortigen Transport einer Nachricht (vgl.
das push flag im TCP Header), und mit dem urgent flag (vgl. dazu den Header
von TCP) kann die Nachricht auch unter Umgehen der Flusskontrolle übertragen
werden.
Der RFC 793 definiert TCP. Seit seiner Veröffentlichung wurden einige Fehler
und Inkonsistenzen gefunden und im RFC 1122 behandelt. Der RFC 1323 definiert
Erweiterungen von TCP.
4.3.2
Header von TCP
Die Abbildung 2 auf der nächsten Seite zeigt den Aufbau des Headers von TCP:
Source, Destination Port (jeweils 16 Bit) haben die gleiche Funktion wie bei
UDP, hier ist jedoch auch die Angabe des Source Port zwingend.
Sequence Number (32 Bit) dient der Identifikation des Paketes. TCP betrachtet
alle Daten, die im Lauf einer Verbindung übertragen werden als einen Strom,
der durch einzelne Übertragungen in Teile zerschnitten ist. Die Sequence Number gibt die Position des ersten Oktetts der vorliegenden Nachricht innerhalb
des Datenstromes an. Beim Verbindungsaufbau wählt jede Station ihre Sequence Number nach eigenem Ermessen, bei einem Überlauf beginnt Sequence
Number wieder mit dem Wert 0.
Acknowledgement Number (32 Bit) dient zum Bestätigen von zuvor eingelangten Paketen. Die hier sendende Station bestätigt den Erhalt aller zuvor empfangenen Oktetts bis zum Oktett mit der Nr. Acknowledgement Number −1.
Das nächste erwartete Oktett hat damit den Offset Acknowledgement Number.
Damit kann eine Station mit dem zum Bestätigen notwendigen Paket selber
wieder Daten senden.
Header Length (4 Bit) gibt die Länge des Headers in 32-Bit Worten an. Wegen
der ev. vorhandenen Optionen (vgl. Feld Options) kann die Länge variieren.
4 TRANSPORT LAYER
1
2
3
4
20
5
6
7
8
9
10 11 12 13 14 15 16
Source port
Destination port
Sequence Number
Acknowledgement number
Header Length
Reserved
Code bits
Window
Checksum
Urgent Pointer
Options (if any)
Padding
Abbildung 2: TCP-Header
4 TRANSPORT LAYER
Bit
Pos.
11
12
13
14
15
16
21
Code - Funktion
URG - urgent pointer field valid : Die Nachricht enthält wichtige Daten.
Die durch das Feld urgent pointer angegebenen Oktetts werden
unter Umgehung der Flusskontrolle übertragen.
ACK - acknowledgement field valid : Diese Nachricht bestätigt den Empfang von Daten aus der Gegenrichtung.
PSH - push: Die Oktetts dieser Nachricht sind sofort an die Applikation
weiterzugeben.
RST - reset: Die Verbindung wird hart – d.h. ohne weitere Formalitäten
beendet.
SYN - sequence number : Diese Nachricht enthält eine Initial Sequence
Number.
FIN - end of byte stream from sender : Die Verbindung wird (zumindest) einseitig beendet. Der Kommunikationspartner kann jedoch noch Nachrichten übertragen.
Tabelle 4: Code bits im TCP-Header
Im RFC 793 heißt dieses Feld Data Offset.
Reserved (6 Bit) ist für künftige Erweiterungen vorgesehen und wird derzeit nicht
verwendet.
Code bits (6 Bit) enthält einige Flags. Die Tabelle 4 zeigt die einzelnen Positionen
und deren Bedeutung.
Window (16 Bit) dient der Flusskontrolle. Dieses Feld enthält die Anzahl der Oktetts, die der Sender derzeit, d. h. ab dem Wert von Acknowledgement Number
aufnehmen kann.
Checksum (16 Bit) enthält wie bei UDP die Prüfsumme über das komplette Paket.
Urgent pointer (16 Bit) gibt die Lage der dringenden Daten im Segment an, falls
das URG flag gesetzt ist.
Options nimmt weitere Optionen auf, wie z. B. das Verabreden auf eine maximale
Paketgröße zwischen Sender und Empfänger (der Vorschlagswert für die max.
Paketgröße ist 536 Oktett).
Padding füllt den Header auf ganze 32-Bit Worte auf.
4 TRANSPORT LAYER
22
Server
Client
SYN, Seq=X
z
SYN, ACK, Seq=Y, Ack=X+1
9
ACK, Seq=X+1, Ack=Y+1
z
Abbildung 3: Sequentieller Verbindungsaufbau in TCP
Station A
SYN, Seq=X
9
ACK, Seq=X+1, Ack=Y+1
9
Station B
SYN, Seq=Y
z
ACK, Seq=Y+1, Ack=X+1
z
Abbildung 4: Gleichzeitiger Verbindungsaufbau in TCP
4.3.3
Verbindungsmanagement
Bei Client-/Server-Anwendungen bereitet sich der Server zunächst passiv auf einen
bevorstehenden Verbindungsaufbau durch einen Client vor. Damit ist die Reihenfolge der für den Aufbau notwendigen Übertragungen vorgegeben. Die Abbildung 3
zeigt den Ablauf bei dieser Art des Verbindungsaufbaus. Der Client übermittelt
zunächst seine eigene Sequence Number. Diese wird dann vom Server bestätigt.
Mit der Bestätigung übermittelt auch der Server seine eigene Sequence Number an
den Client. Auch diese wird vom Client bestätigt. Dieses Verfahren heißt three-way
handshake.
TCP erlaubt jedoch auch den ev. zufällig gleichzeitig erfolgenden Verbindungsaufbau zwischen gleichrangigen Applikationen. Die Abbildung 4 zeigt die dabei auftretenden Aktionen der beiden Stationen.
Die Abbildungen 5 auf der nächsten Seite und 6 auf Seite 24 zeigen die dazugehörigen Spezifikationen für den Auf- und Abbau von Verbindungen in Form
endlicher Automaten. Die Tabelle 5 auf der nächsten Seite beschreibt die in diesen
4 TRANSPORT LAYER
ACK or TIMEOUT
/ TERMINATE
23
- Closed
PASSIVE OPEN
6
?
Wait
ACK
Listen
6
CLOSE /
RST /
SYN / SYN+ACK,
FIN
TERMINATE
OPEN RECEIVED
?
SYN
Recvd
Closing
6
FIN / ACK,
CLOSING
Data
¾
Transfer
ACK
Abbildung 5: Zustandsautomat TCP-Server
Primitive
Typ
PASSIVE OPEN
ACTIVE OPEN
Request
Request
OPEN RECEIVED
Indication
CLOSE
CLOSING
TERMINATE
ABORT
Request
Indication
Confirm
Request
Client/ Parameter
Server
S
Source port, timeout, timeout-action
C
Source port, destination port, destination address, timeout, timeout-action
S
Local connection name, destination
port, destination address
C/S
Local connection name
C/S
Local connection name
C/S
Local connection name, reason code
C/S
Local connection name
Tabelle 5: TCP-User: Service-Primitiven und ihre Parameter
Spezifikationen vorkommenden Service-Primitiven an der Schnittstelle zum TCPUser.
4 TRANSPORT LAYER
24
TIMEOUT
- Closed
6
FIN /
ACTIVE OPEN /
SYN
TERMINATE, ACK
- Timed
wait
²
6
Wait
FIN 2
ABORT /
ACK
RST
SYN
Sent
6
ACK
Closing
6
Wait
FIN 1
I
FIN / ACK,
CLOSING
Data
¾
Transfer
CLOSE / FIN
Abbildung 6: Zustandsautomat TCP-Client
SYN+ACK /
OPEN SUCCESS, ACK
5 DOMAIN NAME SERVICES (DNS)
5
25
Domain Name Services (DNS)
Dieser Abschnitt basiert zum Großteil auf [Douba 1995, Kap. 6].
5.1
Aufgabenstellung
In TCP/IP ist jedem Host zumindest eine IP-Adresse zugeordnet. Diese Adresse
identifiziert den Host im ganzen Netzwerk eindeutig, sie ist auch die Basis für das
Routing. Solche IP-Adressen sind kompakt zu speichern, sie sind jedoch für den
Menschen schwer zu merken und wenig aussagekräftig.
Mit den Domain Name Services werden den IP-Adressen sprechende Namen zugeordnet. Menschen können mit diesen Bezeichnungen besser umgehen. Zusätzlich
haben sie noch einen weiteren Vorteil: Die IP-Adresse ist starr mit dem Teilnetz
verbunden. Wird ein bekannter Server in ein anderes Teilnetz verlegt, so ändert sich
damit auch seine IP-Adresse. Trotzdem kann er auch im neuen LAN – zumindest
nach einer Aktualisierung der DNS-Datenbank – unter dem alten Namen angesprochen werden.
5.2
Lokale Datenbank
Ursprünglich wurde die Zuordnung zwischen IP-Adresse und Rechnername in jedem
Rechner lokal getroffen. Solche Daten sind auch heute noch in der Datei /etc/hosts
enthalten. Darin sind neben den eigenen Daten auch die Daten der bekannten Rechner abgelegt. Hier ein – mitlerweile nicht mehr aktueller – Auszug aus der entsprechenden Datei eines unserer Server:
# Internet Address
Hostname
127.0.0.1
loopback localhost
193.170.124.101 EDV201.fhs-hagenberg.ac.at
193.170.124.102 EDV202.fhs-hagenberg.ac.at
193.170.124.103 EDV203.fhs-hagenberg.ac.at
193.170.124.104 EDV204.fhs-hagenberg.ac.at
193.170.124.105 EDV205.fhs-hagenberg.ac.at
# Comments
# loopback
EDV201
EDV202
EDV203
EDV204
EDV205
Neben der IP-Nummer steht zumindest der offizielle Name. Weitere alternative
Namen (Aliases) sind optional. Auch im Internet wurde in seiner Anfangsphase
die Namenszuordnung ausschließlich mit lokalen Konfigurationsdateien realisiert.
Offizielle Rechnernamen vergab das NIC (Network Information Center). Es hielt eine
offizielle Version der Datei /etc/hosts die laufend an alle teilnehmenden Rechner
verteilt wurde. Diese Methode ist für kleine Netzwerke durchaus praktikabel. Bei
5 DOMAIN NAME SERVICES (DNS)
26
größeren Netzwerken steigt der Aufwand für die Aktualisierung der lokalen Kopien
dieser Datei jedoch dramatisch an. Auch heute wird die lokale Konfigurationsdatei
als Backup verwendet, in ihr sind meist wichtige, im lokalen Umfeld angesiedelte
Hosts eingetragen. Damit sind diese Hosts auch bei einem Ausfall der Verbindung
zum Internet zu erreichen.
Die durch eine wachsende Anzahl von Rechnern entstehenden Nachteile dieser
Methode sind klar:
• Kollisionen von Namen
• hoher Verwaltungsaufwand in der Zentrale
• Konsistenz durch viele Änderungen nur schwer zu gewährleisten
• vermehrter Datenverkehr am Netz durch große Datenbank und viele Hosts
5.3
Verteilte Datenbank
Aufgrund dieser Nachteile ging das NIC bald zu einer hierarchisch organisierten
Datenbank über, den eigentlichen Domain Name Services. Sie sind in den RFCs
1034 und 1035 festgelegt.
5.3.1
Namensraum
In DNS sind Rechnernamen hierarchisch aufgebaut. Statt einem einzigen Namen, besteht ein Name aus einem Teil der den Rechner innerhalb seines logischen Umfeldes
(Bereich/Domain) identifiziert und einem Domain-Anteil, der hierarchisch aufgebaut
ist. Im Internet vergibt das NIC lediglich die Haupt-Domain (toplevel domains), es
tritt die Verantwortung für Sub-Domains an lokale Verantwortliche ab. Diese können
weitere Domain- und Rechnernamen innerhalb der eigenen Domain vergeben. Dadurch enstehen die heute verwendeten hierarchisch organisierten Domain-Namen.
Sie werden von unten nach oben gelesen. Das Problem der Namenskonflikte ist damit weitestgehend entschärft.
5.3.2
Name Server
Jeder Betreiber einer Domain ist für die unter ihm befindlichen Sub-Domains verantwortlich. Nach außen vertritt er den ganzen unter seiner Obhut befindlichen
Teilbaum. Bei größern Domains delegiert er die Zuständigkeit für die Sub-Domains
an die darin befindlichen Institutionen.
Aus dieser Hierarchie resultiert eine verteilte Datenbank für die Zuordnung zwischen Namen und IP-Adressen: Jeder Verantwortliche einer Domain verwaltet seinen
Teil mit einem eigenen lokalen Name Server. Dieser kennt die Rechner, die direkt
5 DOMAIN NAME SERVICES (DNS)
27
in der eigenen Domain angesiedelt sind. Existieren Sub-Domains, so bieten sich zwei
Alternativen an:
1. Die Sub-Domains betreiben eigene Name Server. Der übergeordnete Name
Server kennt von seinen Sub-Domains lediglich die Namen und IP-Adressen
der jeweiligen Name Server.
2. Die Adressdaten der einzelnen Rechner der Sub-Domains sind ebenfalls in der
Datenbank des übergeordneten Name Servers enthalten. Diese Variante ist vor
allem für kleine Sub-Domains sinnvoll.
5.3.3
Root Name Server
Im ganzen Internet existieren einige Name Server, denen die vom NIC festgelegte
oberste Hierarchieebene bekannt ist. Diese Root Name Server sind für einen besseren
Durchsatz lokal verstreut. Ihr Datenbestand ist ident. Damit ist ein Zugriff auf diese
Datenbestände auch bei einem Teilausfall des Internet möglich. Jeder Name Server
kennt einige dieser Root Name Server.
5.3.4
Resolver
Gewöhnliche Rechner (Workstations) nehmen die Dienste lokaler Name Server in
Anspruch. Die in Workstations dafür vorhandene Komponente heißt Resolver, sie
wird z.B. von der Funktion gethostbyname() verwendet. Der Resolver wird in Unix
durch die Datei /etc/resolv.conf konfiguriert. Hier der Inhalt dieser Datei einer
Workstation:
domain
nameserver
fh-hagenberg.at
193.170.124.100
Sie enthält den Namen der eigenen Domain und die IP-Adresse des für diese Domain
zuständigen Name Servers. Die Nennung mehrerer Name Server ist möglich, dies
steigert die Fehlertoleranz. Abhängig von der Konfiguration des Resolvers verwendet
er zum Ermitteln von IP-Adressen aus Namen entweder die lokale Hosts-Datei, den
lokalen Name Server oder beides (Regelfall). Der Resolver setzt ein dns_query an
den lokalen Name Server ab. In dieser Query ist der Rechnername angegeben. Er
erwartet vom Name Server ein dns_reply mit der korrespondierenden IP-Adresse.
5.3.5
Auflösung im Name Server
Ein Name Server hält den Datenbestand über die lokal in seiner Domain existierenden Rechner. Er muss seinen Clients jedoch über alle Rechner des gesamten
5 DOMAIN NAME SERVICES (DNS)
28
Netzwerkes Auskunft geben können. Dazu nimmt er Verbindung zu anderen Name Servern auf. In der Hochlaufphase sind ihm zunächst nur die folgenden Daten
bekannt:
• Adressdaten der in seiner Domain vorhandenen Rechner
• IP-Adressen der in der DNS-Hierarchie untergelagerten Name Server, bzw.
direkt die Adressdaten der Rechner aus den Subdomains
• IP-Adressen der Root Name Server
Durch einen Vergleich des Domain-Teils aus dem gesuchten Namen stellt der
Name Server fest, ob er die Anfrage aus einem dns_request direkt beantworten
kann. Ist dies nicht der Fall, so befragt er selber einen Root Server. Der sendet
entweder direkt die Antwort oder teilt dem lokalen Name Server die IP-Adresse eines
untergelagerten Name Servers mit, der für die gewünschte Subdomain zuständig ist.
Dieses Spiel wiederholt sich, bis ein Name Server gefunden wird, der den gesuchten
Eintrag in seiner Datenbank hat. Das Motto bei diesem Verfahren ist:
Ich weiß es selber nicht, aber ich kenne jemanden, der es wissen sollte!
Die schließlich erhaltene Antwort gibt der lokale Name Server an seinen Client
(den Resolver eines lokalen Rechners) weiter. Bei diesem Vorgang lernt der lokale
Name Server einerseits die Adressdaten des gewünschten Rechners kennen, andererseits werden ihm aber auch die Adressdaten einiger Name Server bekannt. Diese
Daten hält ein Name Server einige Zeit im lokalen Speicher. Damit werden andere
Name Server (ganz besonders die Root Name Server) entlastet.
Einen Sonderfall im Namensbaum des Internet stellt die Domain in_addr.arpa
dar. Sie enthält die inverse Zuordnung, also die Abbildung von IP-Adressen zu Rechnernamen. Mit dieser Domain kann ein beliebiger Applikations-Server den DomainNamen eines Rechners aus der IP-Adresse erfahren. Dies wird z.B. zum Prüfen von
IP-Adressen auf Authentizität verwendet. Jeder Name Server muss auch auf solche
inversen Anfragen antworten können.
LITERATUR
29
Literatur
Comer, D. E., [1995]: Internetworking with TCP/IP, Vol. I: Principles, Protocols,
and Architecture, Prentice-Hall, dritte Auflage.
Douba, S., [1995]: Networking Unix, Sams Publishing, Indianapolis.
Hafner, K. und Lyon, M., [1996]: ARPA KADABRA, Die Geschichte des INTERNET, dpunkt.Verlag.
Halsall, F., [1996]: Data Communications, Computer Networks and Open Systems,
Addison–Wesley, vierte Auflage.
Hart, J. M. und Rosenberg, B., [1995]: Client/Server Computing for Technical Professionals, Addison–Wesley, Reading, Massachusetts.
RFC-Editor, [2001]: last visited on FEB/27/2001.
http://www.rfc-editor.org/
Tanenbaum, A. S., [1998]: Computernetzwerke, Prentice-Hall, dritte Auflage.