Grundlagen Computernetze


Prof. Jürgen Plate

TCP/IP

Die Protokolle der TCP/IP-Familie wurden in den 70-er Jahren für den Datenaustausch in heterogenen Rechnernetzen (d. h. Rechner verschiedener Hersteller mit unterschiedlichen Betriebssystemen) entwickelt. TCP steht für 'Transmission Control Protocol' (Schicht 4) und IP für 'Internet Protocol' (Schicht 3). Die Protokollspezifikationen sind in sogenannten RFC-Dokumenten (RFC - Request for Comment) festgeschrieben und veröffentlicht. Aufgrund ihrer Durchsetzung stellen sie Quasi-Standards dar.

Die Schichten 5 - 7 des OSI-Standards werden hier in einer Anwendungsschicht zusammengefaßt, da die Anwendungsprogramme alle direkt mit der Transportschicht kommunizieren.

In Schicht 4 befindet sich außer TCP, welches gesicherten Datentransport (verbindungsorientiert, mit Flußkontrolle (d. h. Empfangsbestätigung, etc.) durch Windowing ermöglicht, auch UDP (User Datagram Protocol), in welchem verbindungsloser und ungesicherter Transport festgelegt ist. Beide Protokolle erlauben durch die Einführung von sogenannten Ports den Zugriff mehrerer Anwendungsprogramme gleichzeitig auf ein- und dieselbe Maschine.

In Schicht 3 ist das verbindungslose Internet-Protokoll (IP) angesiedelt. Datenpakete werden auf den Weg geschickt, ohne daß auf eine Empfangsbestätigung gewartet werden muß. IP-Pakete dürfen unter bestimmten Bedingungen (TTL=0, siehe unten) sogar vernichtet werden. In Schicht 3 werden damit auch die IP-Adressen festgelegt. Hier findet auch das Routing, das heißt die Wegsteuerung eines Paketes von einem Netz ins andere statt. Ebenfalls in diese Ebene integriert sind die ARP-Protokolle (ARP - Address Resolution Protocol), die zur Auflösung (= Umwandlung) einer logischen IP-Adresse in eine physikalische (z. B. Ethernet-) Adresse dienen und dazu sogenannte Broadcasts (Datenpakete, durch die alle angeschloßenen Stationen angesprochen werden) verwenden. ICMP, ein Protokoll, welches den Austausch von Kontroll- und Fehlerpaketen im Netz ermöglicht, ist ebenfalls in dieser Schicht realisiert.

Die Schichten 1 und 2 sind gegenüber Schicht 3 protokolltransparent. Sie können durch standardisierte Protokolle (z. B. Ethernet (CSMA/CD), FDDI, SLIP (Serial Line IP), PPP (Point-to-Point Protocol)) oder andere Übertragungsverfahren realisiert werden.

Zur TCP/IP-Familie gehören mehrere Dienstprogramme der höheren OSI-Schichten (5 - 7), z. B.:

Die TCP/IP-Protokolle

Der große Vorteil der TCP/IP-Protokollfamilie ist die einfache Realisierung von Netzwerkverbunden. Einzelne Lokale Netze werden über Router oder Gateways verbunden. Einzelne Hosts können daher über mehrere Teilnetze hinweg miteinander kommunizieren.
IP als Protokoll der Ebene 3 ist die unterste Ebene, die darunter liegenden Netzebenen können sehr unterschiedlich sein:

Es ist offensichtlich, daß die Gateways neben dem Routing weitere nichttriviale Funktionen haben, wenn sie zwischen den unterschiedlichsten Teilnetzen vermitteln (z. B. unterschiedliche Protokolle auf Ebene 2, unterschiedliche Datenpaketgröße, usw.).

Aus diesem Grund existieren in einem Internet drei unabhängige Namens- bzw. Adressierungsebenen:

Die Ethernet-Adresse wurde bereits behandelt, auf die anderen beiden Ebenen wird in den folgenden Abschnitten eingegangen. Die Umsetzung der höchsten Ebene (Domain-Namen) in IP-Adressen erfolgt durch das oben erwähnte DNS, worauf die Dienstprogramm der Schichten 5-7 zurückgreifen.

ARP

Die Umsetzung einer IP-Adresse in eine Hardware-Adresse erfolgt durch Tabellen und auf Hardware-Ebene (z. B. Ethernet) automatisch über ARP (Adress Resolution Protocol). Dazu ein Beispiel:

Die Station A will Daten an eine Station B mit der Internetadresse I(B) senden, deren physikalische Adresse P(B) sie noch nicht kennt. Sie sendet einem ARP-Request an alle Stationen im Netz, der die eigene pysikalische Adresse und die IP-Adresse von B enthält. Alle Stationen erhalten und überprüfen den ARP-Request und die angesprochene Station B antwortet, indem sie einen ARP-Reply mit ihrer eigenen physikalischen Adresse an die Station A sendet. Letztere speichert die Zuordnung in einer Tabelle (Address Resolution Cache).

Auch für die Umkehrfunktion gibt es eine standardisierte Vorgehensweise, den RARP (Reverse ARP). Hier sendet die Station A unter Angabe ihrer physikalischen Adresse P(A) einen RARP-Request. Wenn im Netz nur eine Station als RARP-Server eingerichtet ist (eine Station, die alle Zuordnungen von P(x) <--> I(x) "kennt"), antwortet diese mit einem RARP-Reply an die anfragende Station, der I(A) enthält. Diese Funktion ist z. B. für sogenannte "Diskless Workstations" wichtig, die ihre gesamte Software von einem Server laden.

IP - Internet Protocol

Das Internet-Protokoll ist ein verbindungsloser Dienst (im Gegensatz zu X.25) mit einem 'Unreliable Datagram Service', d. h. es wird auf der IP-Ebene weder die Richtigkeit der der Daten noch die Einhaltung von Sequenz, Vollständigkeit und Eindeutigkeit der Datagramme überprüft. Ein zuverlässiger verbindungsorientierter Dienst wird in der darüberliegenden TCP-Ebene realisiert.

Ein IP-Datagramm besteht aus einem Header und einem nachfolgenden Datenblock, der seinerseits dann z. B. in einem Ethernet-Frame "verpackt" wird. Die maximale Datenlänge wird auf die maximale Rahmenlänge des physikalischen Netzes abgestimmt. Da nicht ausgeschlossen werden kann, daß ein Datagramm auf seinem Weg ein Teilnetz passieren muß, dessen Rahmenlänge niedriger ist, müssen zum Weitertransport mehrere (Teil-)Datagramme erzeugt werden. Dazu wird der Header im Wesentlichen repliziert und die Daten in kleiner Blöcke unterteilt. Jedes Teil-Datagramm hat also wieder einen Header. Diesen Vorgang nennt man Fragmentierung. Es handelt sich um eine rein netztechnische Maßnahme, von der Quell- und Zielknoten nicht wissen müssen. Es gibt natürlich auch eine umgekehrte Funktion, "Reassembly", die kleine Datagramme wieder zu einem größeren packt. Geht auf dem Übertragungsweg nur ein Fragment verloren, muß das gesamte Datagramm wiederholt werden. Es gilt die Empfehlung, daß Datagramme bis zu einer Länge von 576 Bytes unfragmetiert übertragen werden sollten.

Format des IP-Headers

Version

Kennzeichnet die IP-Protokollversion

IHL (Internet Header Length)

Die Angabe der Länge des IP-Headers erfolgt in 32-Bit-Worten (normalerweise 5). Da die Optionen nicht unbedingt auf Wortlänge enden, wird der Header gegebenenfalls aufgefüllt.

Type of Service

Alle Bits haben nur "empfehlenden" Charakter. 'Precedence' bietet die Möglichkeit, Steuerinformationen vorrangig zu befördern.

Total Length

Gesamtlänge des Datagramms in Bytes (max. 64 KByte).

Identification

Dieses und die beiden folgenden Felder steuern die Reassembly. Eindeutige Kennung eines Datagramms. Anhand dieses Feldes und der 'Source Address' ist die Zusammengehörigkeit von Fragmenten zu detektieren.

Flags

Die beiden niederwertigen Bits haben folgende Bedeutung:

·        Don't fragment: Für Hosts, die keine Fragmentierung unterstützen

·        More fragments: Zum Erkennen, ob alle Fragmente eines Datagramms empfangen wurden

Fragment Offset

Die Daten-Bytes eines Datagramms werden numeriert und auf die Fragmente verteilt. Das erst Fragment hat Offset 0, für alle weiteren erhöht sich der Wert um die Länge des Datenfeldes eines Fragments. Anhand dieses Wertes kann der Empfänger feststellen, ob Fragmente fehlen.

Time-to-live (TTL)

Jedes Datagramm hat eine vorgegebene maximale Lebensdauer, die hier angegeben wird. Auch bei Routing-Fehlern (z. B. Schleifen) wird das Datagramm irgendwann aus dem Netz entfernt. Da Zeitmessung im Netz problematisch ist, und keine Startzeit im Header vermerkt ist, decrementiert jeder Gateway dieses Feld --> de-facto ein 'Hop Count'.

Protocol

Da sich unterschiedliche Protokolle auf IP stützen, muß das übergeordnete Protokoll (ULP, Upper Layer Protocol) angegeben werden. Wichtige ULPs sind

·        1: ICMP Internet Control Message P.

·        3: GGP Gateway-to-Gateway P.

·        6: TCP Transmission Control P.

·        8: EGP Exterior Gateway P.

·        17: UDP User Datagram P.

Header Checksum

16-Bit-Längsparität über den IP-Header (nicht die Daten)

Source Address

Internet-Adresse der Quellstation

Destinantion Address

Internet-Adresse der Zielstation

Options

Optionales Feld für weitere Informationen (deshalb gibt es auch die Header-Länge). Viele Codes sind für zukünftige Erweiterungen vorgesehen. Die Optionen dienen vor allem der Netzsteuerung, der Fehlersuche und für Messungen. Die wichtigsten sind:

·        Record Route: Weg des Datagramms mitprotokollieren

·        Loose Source Routing: Die sendende Station schreibt einige Zwischenstationen vor (aber nicht alle)

·        Strict Source Routing: Die sendende Station schreibt alle Zwischenstationen vor.

·        Timestamp Option: Statt seiner IP-Adresse (wie bei Record Route) trägt jeder Gateway den Bearbeitungszeitpunkt ein (Universal Time).

Padding

Füllbits

ICMP - Internet Control Message Protocol

ICMP erlaubt den Austauch von Fehlermeldungen und Kontrollnachrichten auf IP-Ebene. ICMP benutzt das IP wie ein ULP, ist aber integraler Bestandteil der IP-Implementierung. Es macht IP nicht zu einem 'Reliable Service', ist aber die einzige Möglichkeit Hosts und Gateways über den Zustand des Netzes zu informieren (z. B. wenn ein Host temporär nicht erreichbar ist --> Timeout).

Die ICMP-Nachricht ist im Datenteil des IP-Datagramms untergebracht, sie enthält ggf. den IP-Header und die ersten 64 Bytes des die Nachricht auslösenden Datagramms (z. B. bei Timeout).

Die fünf Felder der ICMP-Message haben folgende Bedeutung:

Type

Identifiziert die ICMP-Nachricht

·        0 Echo reply

·        3 Destination unreachable

·        4 Source quench

·        5 Redirect (Change a Route)

·        8 Echo request

·        11 Time exceeded for a datagram

·        12 Parameter Problem on a datagram

·        13 Timestamp request

·        14 Timestamp reply

·        15 Information request

·        16 Information reply

·        17 Address mask request

·        18 Address mask reply

Code

Detailinformation zum Nachrichten-Typ

Checksum

Prüfsumme der ICMP-Nachricht (Datenteil des IP-Datagramms)

Identifier und Sequence-Nummer

dienen der Zuordnung eintreffender Antworten zu den jeweiligen Anfragen, da eine Station mehrere Anfragen aussenden kann oder auf eine Anfrage mehrere Antworten eintreffen können.

Wenden wir uns nun den einzelnen Nachrichtentypen zu:

Echo request/reply

Überprüfen der Erreichbarkeit eines Zielknotens. Es können Testdaten mitgeschickt werden, die dann unverändert zurückgeschickt werden (--> Ping-Kommando unter UNIX).

Destination unreachable

Im Codefeld wird die Ursache näher beschrieben: 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed 5 Source route failed

Source quench

Wenn mehr Datagramme kommen als eine Station verarbeiten kann, sendet sie diese Nachricht an die sendende Station.

Redirect

wird vom ersten Gateway an Hosts im gleichen Teilnetz gesendet, wenn es eine bessere Route-Verbindung über einen anderen Gateway gibt. In der Nachricht wird die IP-Adresse des anderen Gateways angegeben.

Time exceeded

Für diese Nachricht an den Quellknoten gibt es zwei Ursachen:

·        Time-to-live exceeded (Code 0): Wenn ein Gateway ein Datagramm eliminiert, dessen TTL-Zähler abgelaufen ist.

·        Fragment reassembly time exceeded (Code 1): Wenn ein Timer abläuft, bevor alle Fragmente des Datagramms eingetroffen sind.

Parameter problem on a Datagramm

Probleme bei der Interpretation des IP-Headers. Es wird ein Verweis auf die Fehlerstelle und der fragliche IP-Header zurückgeschickt.

Timestamp request/reply

Erlaubt Zeitmessungen und -synchronisation im Netz. Drei Zeiten werden gesendet (in ms seit Mitternacht, Universal Time):

·        Originate T.: Sendezeitpunkt des Requests (vom Absender)

·        Receive T.: Ankunftszeit (beim Empfänger)

·        Transmit T.: Sendezeitpunkt des Reply (vom Empfänger)

Information request/reply

Mit dieser Nachricht kann ein Host die Netid seines Netzes erfragen, indem er seine Netid auf Null setzt.

Address mask request/reply

Bei Subnetting (siehe unten) kann ein Host die Subnet-Mask erfragen.

UDP - User Datagram Protocol

UDP ist ein einfaches Schicht-4-Protokoll, das einen nicht zuverlässigen, verbindungslosen Transportdienst ohne Flußkontrolle zur Verfügung stellt. UDP ermöglicht zwischen zwei Stationen mehrere unabhängige Kommunikationsbeziehungen (Multiplex-Verbindung): Die Identifikation der beiden Prozesse einer Kommuninkationsbeziehung geschieht (wie auch bei TCP, siehe unten) durch Port-Nummern (kurz "Ports"), die allgemein bekannten Anwendungen fest zugeordnet sind. Es lassen sich aber auch Ports dynamisch vergeben oder bei einer Anwendung durch verschiedene Ports deren Verhalten steuern. Die Transporteinheiten werden 'UDP-Datagramme' oder 'User Datagramme' genannt. Sie haben folgenden Aufbau:

Source Port

Identifiziert den sendenden Prozeß (falls nicht benötigt, wird der Wert auf Null gesetzt).

Destination Port

Identifiziert den Prozeß des Zielknotens.

Length

Länge des UDP-Datagramms in Bytes (mindestens 8 = Headerlänge)

UDP-Checksum

Optionale Angabe (falls nicht verwendet auf Null gesetzt) einer Prüfsumme. Zu deren Ermittlung wird dem UDP-Datagramm ein Pseudoheader von 12 Byte vorangestellt (aber nicht mit übertragen), der u. a. IP-Source-Address, IP-Destination-Address und Protokoll-Nummer (UDP = 17) enthält.

TCP- Transmission Control Protocol

Dieses Protokoll implementiert einen verbindungsorientierten, sicheren Transportdienst als Schicht-4-Protokoll. Die Sicherheit wird durch poritive Rückmeldungen (acknowledgements) und Wiederholung fehlerhafter Blöcke erreicht. Fast alle Standardanwendungen vieler Betriebssysteme nutzen TCP und das darunterliegende IP als Transportprotokoll, weshalb man die gesamte Protokollfamilie allgemein unter 'TCP/IP' zusammenfaßt. TCP läßt sich in lokalen und weltweiten Netzen einsetzen, da IP und die darunterliegenden Schichten mit den unterschiedlichsten Netzwerk- und Übertragungssystemen arbeiten können (Ethernet, Funk, serielle Leitungen, ...). Zur Realisierung der Flußkontrolle wird ein Fenstermechanismus (sliding windows) ähnlich HDLC verwendet (variable Fenstergröße). TCP-Verbindungen sind vollduplex. Wie bei allen verbindungsorientierten Diensten muß zunächst eine Virtuelle Verbindung aufgebaut und bei Beendigung der Kommunikation wieder abgebaut werden. "Verbindungsaufbau" bedeutet hier eine Vereinbarung beider Stationen über die Modalitäten der Übertragung (z. B. Fenstergröße, Akzeptieren eines bestimmten Dienstes, usw.). Ausgangs- und Endpunkte einer virtuellen Verbindung werden wie bei UDP durch Ports identifiziert. Allgemein verfügbare Dienste (Beispiele in 4.6) werden über 'well known' Ports (--> feste zugeordnete Portnummer) erreichbar. Andere Portnummern werden beim Verbindungsaufbau vereinbart.

Die Fenstergröße gibt an, wieviele Bytes gesendet werden dürfen, bis die Übertragung quittiert werden muß. Erfolgt keine Quittung, werden die Daten nochmals gesendet. Die empfangene Quittung enthält die Nummer des Bytes, das als nächstes vom Empfänger erwartet wird - womit auch alle vorhergehenden Bytes quittiert sind. Die Fenstergröße richtet sich zunächst nach der maximalen Größe eines IP-Datagramms, sie kann aber dynamisch mit der Quittung des Empfängers geändert werden. Werden die Ressourcen knapp, wird die Fenstergröße verringert. Beim Extremfall Null wird die Übertragung unterbrochen, bis der Empfänger erneut quittiert. Neben einem verläßlichen Datentransport ist so auch die Flußkontrolle gewährleistet.

Die TCP-Übertragungseinheit zwischen Sender und Empfänger wird als 'Segment' bezeichnet. Jedem TCP-Block ist ein Header vorangestellt, der aber wesentlich umfangreicher als die bisherigen ist:

Source Port

Identifiziert den sendenden Prozeß.

Destination Port

Identifiziert den Prozeß des Zielknotens.

Sequence Number

TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).

Acknowledgement Number

Hiermit werden Daten von der Empfängerstation bestätigt, wobei gleichzeitig Daten in Gegenrichtung gesendet werden. Die Bestätigung wird also den Daten "aufgesattelt" (Piggyback). Die Nummer bezieht sich auf eine Sequence-Nummer der empfangenen Daten; alle Daten bis zu dieser Nummer (ausschließlich) sind damit bestätigt --> Nummer des nächsten erwarteten Bytes. Die Gültigkeit der Nummer wird durch das ACK-Feld (--> Code) bestätigt.

Data Offset

Da der Segment-Header ähnlich dem IP-Header Optionen enthalten kann, wird hier die Länge des Headers in 32-Bit-Worten angegeben.

Res.

Reserviert für spätere Nutzung

Code

Angabe der Funktion des Segments:

·        URG Urgent-Pointer (siehe unten)

·        ACK Quittungs-Segment (Acknowledgement-Nummer gültig)

·        PSH Auf Senderseite sofortiges Senden der Daten (bevor Sendepuffer gefüllt ist) und auf Empfangsseite sofortige Weitergabe an die Applikation (bevor Empfangspuffer gefüllt ist) z. B. für interaktive Programme.

·        RST Reset, Verbindung abbauen

·        SYN Das 'Sequence Number'-Feld enthält die initiale Byte-Nummer (ISN) --> Numerierung beginnt mit ISN + 1. In der Bestätigung übergibt die Zielstation ihre ISN (Verbindungsaufbau).

·        FIN Verbindung abbauen (Sender hat alle Daten gesendet), sobald der Empfänger alles korrekt empfangen hat und selbst keine Daten mehr loswerden will.

Window

Spezifiziert die Fenstergröße, die der Empfänger bereit ist anzunehmen - kann dynamisch geändert werden.

Checksum

16-Bit Längsparität über Header und Daten.

Urgent Pointer

Markierung eines Teils des Datenteils als dringend. Dieser wird unabhängig von der Reihenfolge im Datenstrom sofort an das Anwenderprogramm weitergegeben (URG-Code muß gesetzt sein). Der Wert des Urgent-Pointers markiert das letzte abzuliefernde Byte; es hat die Nummer <Sequence Number> + <Urgent Pointer>.

Options

Dieses Feld dient dem Informationsaustausch zwischen beiden Stationen auf der TCP-Ebene, z. B. die Segmentgröße (die Ihrerseits von der Größe des IP-Datagramms abhängen sollte, um den Durchsatz im Netz optimal zu gestalten).

TCP-Zustandsübergangsdiagramm

Den gesamte Lebenszyklus einer TCP-Verbindung beschreibt die folgende Grafik in einer relativ groben Darstellung.

Erklärung der Zustände:

Die Hauptmerkmale von TCP

Normalerweise stützen sich Programme auf Anwendungseben auf mehrere der Protokolle (ICMP, UDP, TCP).

Zum Inhaltsverzeichnis        Zur XINUX Homepage

Copyright © Prof. Jürgen Plate, Fachhochschule München