|
|
GRUNDLAGEN DER INFORMATIK WS 0203 - Vorlesung
|
Bisher wurde die Kommunikation in Netzen allgemein beschrieben. Dabei wurde herausgearbeitet, dass diese Kommunikation in Schichten ('Layern') organisiert ist. Jede Schicht hat eine spezielle Aufgabe. Die oberste Schicht wird durch die jeweilige Anwendung repräsentiert, die dann Dienste der darunter liegenden Schicht in Anspruch nimmt. Jede Schicht erweitert die zu übermittelnde Informationen jeweils um spezifische Informationen, die an den Anfang (Kopf, 'header') der Nachricht gesetzt werden. Je mehr Schichten bei einer solchen Kommunikation durchlaufen werden, umso mehr Header werden hinzugefügt. Als ein bekanntes standardisiertes Schichtenmodell wurde das OSI-Modell vorgestellt.Weiterhin wurde eine erste Einführung in das Modell des sogenannten Internet Protokolls gegeben, dessen wichtigsten Schichten die TCP- und die IP-Schichten sind. Am Beispiel des Internetprotokolls sollen diese Überlegungen heute weiter vertieft werden.
Die nachfolgenden Schaubilder zeigen die Datenformate des UDP-, des TCP- und des IP-Protokolls (nach [STEVENS 1994])
Das erste Bild zeigt einen UDP-Header und das zweite Bild einen TCP-Pseudo-Header, der genauso aufgebaut ist, wie ein UDP-Pseudo-Header, nur dass statt der Protokollzahl 6 (Fall TCP) die Protokollzahl 17 (Fall UDP) steht. Der für UDP zuständige Request ist RFC 768.
UDP-Header mit Portnummern (nach [STEVENS 1994])
Ein TCP-Pseudo-Header analog zum UDP-Pseudo-Header (nach [TANENBAUM 2001:561])
Die Port-Nummern (siehe auch weiter unten) identifizieren den Port des Senders und den Port des Empfängers.Das UDP-Längenfeld gibt die Länge des UDP-Headers und der UDP-Daten in Bytes an. Die minimale Länge ist 8 Bytes, nämlich dann, wenn keine Daten gesendet werden, was möglich ist. Die Berechnung der Checksumme ist zwar optional, wird aber dringend empfohlen. Es werden vom UDP-Header und von den UDP-Daten alle 16-Bitwörter addiert und das Ergebnis im Format eines 1er-Komplements in das Feld geschrieben. Sollte die Menge der Daten ungerade sein, dann wird ein Pad-Byte mit Wert 0 (auch im Format eines 1er-Komplements) angehängt. Zusätzlich wird ein UDP-Pseudo-Header vor den UDP-Header vorgeschaltet, der einzelne Felder des IP-Headers (siehe unten) mitbenutzt. Dieser enthält die IP-Adresse (siehe unten) des Senders und Empfängers, ein zero-Byte, das bei 0 anzeigt, dass keine Checksumme ermittelt wurde, ein Protokoll-Byte sowie nochmals die UDP-Checksumme.
Im Fall von UDP ist festzuhalten, dass von UDP selbst nicht kontrolliert wird, ob ein Pakt ankommt oder nicht. Es wird einfach abgeschickt. Neben dieser 'Schwachstelle' bietet UDP gegenüber TCP eine Reihe von Vorteilen (z.B. Broadcast- oder Multicast-Adressierung). Will man die Vorteile von UDP nutzen ohne die Nachteile in Kauf zu nehmen, so kann man in einem Dienst oberhalb von UDP eine zusätzliche Kontrolle einführen.
Im Gegensatz zu UDP ist das TCP-Protokoll verbindungsorientiert, d.h. bevor irgendwelche Daten gesendet werden, wird erst eine eindeutige Verbindung zwischen genau einem Sender und einem Empfänger etabliert. Dies schliesst eine Broadcast- oder eine Multicastverbindung (wie im Fall von UDP) aus.
Um eine zuverlässige Verbindung unterhalten zu können, bedient sich das TCP-Protokoll unterschiedlicher Techniken. Es benutzt z.B. einen Timer (Zeitgeber), um die die Antwortzeit zu kontrollieren. Erscheint diese zu lange, wird das Paket von neuem gesendet. Ferner wird eine Checksumme benutzt, deren Berechnung im Gegensatz zu UDP verpflichtend ist. Ferner bekommt jedes TCP-Segment eine Sequenz-Nummer, so dass der Empfänger die Ordnung der Datenpakete wieder herstellen kann. Den genauen Aufbau eines TCP-Headers zeigt das nächste Bild. Der ursprüngliche Request für TCP war RFC 793.
TCP-Header mit Portnummern (nach [STEVENS 1994])
Analog dem UDP-Header enthält der TCP-Header auch die Portnummern von Sender und Empfänger. Dann kommt eine unsigned 32-Bit-Sequenz-Nummer, die bei Erreichung des Maximums wieder bei 0 beginnt. Die Bestätigungsnummer ('Ackknowledgement number') ist die Nummer des nächsten Segments, das der Sender erwartet, da er das Segment Bestätigungsnummer-1 erfolgreich erhalten hat. Diese Zahl gilt aber nur, wenn das Flag ACK gesetzt ist (siehe unten). Das 4-bit lange Längenfeld gibt an, wieviele 32-Bitworte der TCP-Header umfasst. Ohne das variable Optionen-Feld ist die Länge 20 Bytes. Dann folgen 6 Flags:
URG := sagt, dass der urgent pointer (siehe weiter im Header) gültig sein soll.
ACK := sagt, dass die Bestätigungsnummer gültig ist
PSH := (push), der Empfänger soll die Daten so schnell wie möglich weiterreichen
RST := ('reset') die Verbindung soll neu wiederhergestellt werden .
SYN := zu Beginn einer Verbindung: synchronisiere die Sequenznummern um eine Verbindung aufzubauen
FIN := der Sender hat seine Sendung beendet.
Die Fenstergrösse ('windowsize') ist eine 16-Bit Zahl. Sie legt fest, wieviele Bytes ein Empfänger bereit ist, anzunehmen. Die Checksumme ist verpflichtend und wird ähnlich berechnet wie beim UDP-Header (siehe oben). Auch hier wird ein Pseudo-Header erzeugt. Wenn das URG-Flag gesetzt ist, dann repräsentiert der Urgent-Pointer einen Offset, der zur Sequenzzahl hinzugrechnet werden muss, um das letzte Byte der wichtigen Daten zu ermitteln. Die Optionen sind variabel. Die häufigste Option ist MSS (Maximum Segment Size); damit verständigen sich Sender und Empfänger zu Beginn (SYN-Flag), wie gross das grösste Segment sein soll, das der Empfänger empfangen will. Neuere Optionen umfassen neuere Verfahren zu Ermittlung der MTU (Maximum Transmission Unit), sie erlauben eine Skalierung der Fenstergrösse (wscale 0 ... 14), indem der 16-Bit-Wert der Fenstergrösse nach links geshiftet werden kann. Schliesslich wird die Zeitmessung genauer, da man jetzt jedem Segment eine Zeitmarke mitgegebn kann. Dann kommen die eigentlichen TCP-Daten. Diese können leer sein.
Für das IP-Protokoll gilt generell, dass seine Verbindungen unzuverlässig ('unreliable') und verbindungslos ('connectionless') sind. Jedes Datenpaket wird unabhängig vom anderen geroutet, was z.B. dazu führen kann, dass die Reihenfolge der Pakete sich beim Empfänger verändert hat. Die einschlägigen RFCs für IP sind RFC 791 mit neueren Modifikationen in RFC 1340 und 1349. Die Struktur eines IP-Headers zeigt das folgende Bild:
IP-Header mit IP-Adressen im IPv4-Adressformat (nach [STEVENS 1994])
Wichtig zu wissen ist, dass das Bit mit der Benennung '0' das höchste Bit ('most significant bit') ist und die Bytes 'von links nach rechts' versendet werden. Dies entspricht der sogenannten 'big endian' Byte Ordnung. Insofern die Bytes in dieser Ordnung über das Netz geschickt werden, ist dies dann auch die Netzwerk Byte-Ordnung. Computer, die intern eine 'little endian' Byte Ordnung haben, müssen die Anordnung der Bytes entprechend umändern.
Die ersten 4 Bit repräsentieren die Version des IP-Protokolls. Bislang war dies Version 4 (= IPv4); nach und nach wird diese jetzt ersetzt durch Version 6 (= IPv6). Die 4 Bit Header Länge ('header length') zählt die Anzahl der 32-Bit-Worte im Header. Das Feld TOS := Type of Service besteht aus folgendem Bitmuster: 3-Bit Präzedenz, 4-Bit TOS, 1 Bit = 0. Die TOS-Bits repräsentieren 'minimize delay', 'maximize throughput', 'maximize reliability', 'minimize monetary cost'. Nur jeweils eines dieser TOS-Bits soll gesetzt sein. Das 16-Bit Feld 'total length' gibt die Grösse des gesamten IP-Datagrams in Bytes an. Zieht man davon die Header Länge ab, erhält man den Beginn der Daten.
Das 'identification' field wird jedesmal um 1 erhöht, wenn ein neues Datagram versendet wird. Es kann daher benutzt werden, um ein Datagram zu identifizieren.
Das Feld Flags ist zu sehen im Kontext der Fragmentierung. Bevor ein IP-Sender sein Datagram sendet, versucht das IP-Protokoll zu bestimmen, über welches Interface das Datagram gesendet werden soll und was die MTU ('Maximum Transmission Unit') ist. Wenn die maximale Zahl an Bytes kleiner ist als das Datagram Bytes umfasst, muss das Datagram fragmentiert werden. Dieser Vorgang kann 'unterwegs' wiederholt werden. Die 'Zusammensetzung' aller Fragmente geschieht erst ganz am Ende durch den Empfänger. Damit das Zusammenbauen möglich ist, werden alle Fragmente so mit Informationen ausgestattet, dass sich die verschiedenen Fragmente wieder in der richtigen Reihenfolge zusammenbauen lassen. So wird der Wert des identification fields in jedes Fragment übernommen; dadurch weiss man, welche Fragmente zusammen gehören. Im Flag-Field wird ein Bit gesetzt, das für alle Fragmente ausser dem letzen, sagt, dass es noch weitere Fragmente gibt (MF := More Fragments). Ferner gibt es ein 13-Bit Fragment-Offset, der in 8-Byte Einheiten angibt, wieweit das aktuelle Fragment vom Anfang des Datagrams entfernt ist. Ausserdem wird das 'total length field' für jedes Fragment angepasst. Wenn hingegen das DF := Don't Fragment Bit gesetzt ist, dann wird nicht fragmentiert. Sollte es dann zu Problemen mit einer MTU kommen, wird das Datagram vom jeweiligen Router verworfen und ein ICMP-Fehlermeldung zurückgesandt; der Sender hat dann die Möglichkeit, die Datengrösse zu verkleinern und es von Neuem zu versuchen. Jedes Fragment hat seinen eigenen IP-Header und kann daher unabhänig von allen anderen versendet werden.
Ein weiteres wichtiges Feld ist TTL := Time to Live. Hier wird eine obere Schranke für die Anzahl der Router gesetzt, die ein Paket passieren soll. Damit soll verhindert werden, dass ein Paket in eine Endlosschleife gerät. Jeder Router vermindert den Wert von TTL um 1. Ist der Wert 0 erreicht, wird das Datagram verworfen und eine ICMP-Fehlermeldung zurückgesandt.
Das Protokoll-Feld sagt, welches Protokoll die Daten für das IP-Paket gegeben hat. Die Checksum berechnet nur eine Checksumme für den Header, nicht für die Daten. Dann folgen die 32-Bit IP-Adressen von Sender und Empfänger. Im option field, das kaum genutzt sein woll, sind folgende Inormationen vorgesehen:
Sicherheit und Handling
Aufzeichnung aller Router IP-Adressen
Zeitmarke von jedem Router mit IP-Adresse
Offenes Routing vn IP-Adressen, die geroutet werden sollen
Striktes Routing von IP-Adressen
Damit das options field immer auf einer 32-Bit Grenze endet, werden notfalls Pad-Bytes mit dem Wert 0 angefügt.
Was sind 'Ports'? IANA (:= Internet Assigned Numbers Authority) umschreibt Ports wie folgt: "Ports are used in the TCP [RFC 793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the 'well-known port'."
D.h. 'Ports' sind logische Grössen, um im Bereich einer IP-Adresse mehr als eine Verbindung gleichzeitig aufbauen zu können. Da ein ungeordneter Gebrauch von Portnummern für unterschiedliche Dienste in der Kommunikation zwischen Netzwerken zu Chaos führen kann, wird versucht, die Zuordnung von Portnummern zu Diensten international zu regeln. Diese Regelungen werden durch IANA wie folgt beschrieben:
"The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports. The Well Known Ports are those from 0 through 1023. The Registered Ports are those from 1024 through 49151. The Dynamic and/or Private Ports are those from 49152 through 65535.
### UNASSIGNED PORT NUMBERS SHOULD NOT BE USED. THE IANA WILL ASSIGN
THE NUMBER FOR THE PORT AFTER YOUR APPLICATION HAS BEEN APPROVED ###
WELL KNOWN PORT NUMBERS
The Well Known Ports are assigned by the IANA and on most systems can
only be used by system (or root) processes or by programs executed by
privileged users.
To the extent possible, these same port assignments are used with the
UDP [RFC768].
The range for assigned ports managed by the IANA is 0-1023."
Die aktuellste Liste kann man jederzeit unter der URL von IANA einsehen.
Jeder offizielle Host und Router im Internet hat in Version 4 (Version 6 siehe unten) eine eindeutige 32-Bit IP-Adresse (Teilnehmer in mehreren Netzen können in jedem Netz eine andere Adrese haben). Diese Adresse ist hierarchisch strukturiert, indem jedes Byte einen eigenen Bereich repräsentiert. Einen ersten Überblick über die verschiedenen Adressräume gibt das nachfolgende Bild:
Adressen im IPv4-Adressformat (nach [TANENBAUM 2000])
Die weltweite Zuteilung von IP-Netzwerk-Adressen erfolgt über die Organisation interNIC, die wiederum u.a. mit IANA (s.o.) zusammenarbeitet. Die Adressen werden als gepunktete Dezimalzahlen ('Dotted Decimal Notation') geschrieben.
Als Regel gilt, dass alle Hosts im gleichen Netz die gleiche Netzwerkadresse haben müssen. Bei einem 3-stufigen Konzept mit <Klasse, Netz, Host> kann dies schnell zu Problemen führen. Eine Strategie von grösseren Firmen bestand darin, die Host-Nummer in zwei Teile aufzuteilen: Subnetz-Nummer und Host-Nummer (siehe RFC 950). Ein Beispiel zeigt das folgende Bild:
Aufspaltung von Host-Adressen in Subnetz- und Host-Adresse (im IPv4-Adressformat) (nach [TANENBAUM 2000])
Daneben gibt es einige spezielle Adressen, die im folgenden Bild angeführt sind:
Spezielle IP-Adressen (im IPv4-Adressformat) (nach [TANENBAUM 2000])
Die IP-Adresse 0.0.0.0 wird vn Hosts beim Starten benutzt, danach nicht mehr. IP-Adressen mit 0 zu Beginn beziehen sich auf das eigene Netz, allerdings muss die Anzahl der 0en mit dem Netz übereinstimmen. Lauter 1en erlauben einen Broadcast entweder im gesamten LAN oder an alle Hosts eines anderen Netzes. Adressen mit 127.x.x.x erlauben es, dass ein Host sich selbst Pakete schickt.
Die immer bedroglicher werdende Verknappung von IP-Adressen hat dazu geführt, dass in einer neueren Version des IP-Protokolls (IPv6) ein wesentlich grösserer Adressraum (128 Bits) zur Verfügung gestellt wird. Einen ersten groben eindruck von diesem neuen Adressformat vermittelt das folgende Bild. Für weitere Details sei verwiesen auf die URLs IPv6-Einführung sowie OpenGroup Aenderungen IPv6 für UNIX/Linux.
Adressen im IPv6-Adressformat (nach [TANENBAUM 2000])
Neben den soeben erwähnten Protokollen UDP, TCP und IP gibt es noch zahlreiche andere wichtige Protokolle, von denen hier nur noch drei kurz erwähnt werden: ICMP, ARP, RARP und BOOTP.
Das ICMP (:= Internet Control Message Protocol) (siehe RFC 792) wurde schon im Zusammenhang mit IP erwähnt. Es dient dazu, dass sich Hosts und Router untereinander Probleme und Fehler berichten können. Beispiele für solche Fehler wurden schon erwähnt: 'Time exceeded', d.h. das feld Time-to-Live erreichte den Wert 0.Ein anderer Fehler im Zusammenhang des IP-Protokolls war das Ereignis, dass ein MTU-Wert überschritten wurde.
Das ARP (:= Address Resolution Protocol) dient dazu, IP-Adressen die zugehörigen Ethernet-Adressen der Netzwerkkarten zuzuordnen (siehe FC 826).
Das RARP (:= Reverse Address Resolution Protocol) leistet den umgekehrten Dienst; es sucht zur Ethernet-Adresse einer Netzwerkkarte die IP-Adresse des Hosts siehe RFC 903).
Im Ergebnis ähnlich wie RARP, aber im Vorgehen anders, arbeitet das Protokoll BOOTP (:= Boot Protocol) (siehe RFC 951).
Was zeichnet das UDP-Protokoll aus?
Was sind die wesentlichen Eigenschaften des TCP-Protokolls?
Durch welche konkreten Massnahmen kann das TCP-Protokoll die Unversehrtheit und Zuverlässigkeit der Datenpakete gegenüber UDP besser wahren?
Was sind die wesentlichen Eigenschaften des IP-Protokolls?
Welche Rolle spielt die Byte-Ordnung 'big endian' im Netz?
Durch welche Massnahmen kann das IP-Protokoll eine passende Fragmentierung der Datenpakete erreichen und dafür sorgen, dass diese beim Empfänger wieder in der richtigen Reihenfolge zusammengebaut werden können?
Wozu dienen Portnummern?
Wie sind IP-Adressen der Version IPv4 aufgebaut?
Wie werden bei IP-Adressen der Version IPv4 die verschiedenen Netzwerkklassen realisiert?
Wie können bei IP-Adressen der Version IPv4 die drei Stufen Netzkklasse, Netz und Host erweitert werden?
Welche speziellen IP-Adressen der Version IPv4 kennen Sie?
Welche Aufgaben erfüllen die Protokolle ICMP, ARP, RARP und BOOTP?