Grundlagen moderner Netzwerktechnologien im Überblick – Teil 87

Die TCP/IP-Protokollfamilie – das Internet Protokoll (IP) im Überblick

12.01.2011 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / Andreas Donner

Passende Protokolle bringen die Daten im Netz auf Trab
Passende Protokolle bringen die Daten im Netz auf Trab

Das Internet Protocol (IP) ermöglicht den Transport von Datenpaketen vom Sender über mehrere Netze hinweg bis zum Empfänger. Die Datenpakete bei IP heißen Datagramme. Bei IP gibt es keine Quittierungsmechanismen. IP garantiert deshalb weder eine Datagramm-Reihenfolge noch eine gesicherte Ablieferung der Datagramme beim Empfänger. IP besitzt allerdings die Möglichkeit der Fragmentierung, um große Datagramme auch über Netze transportieren zu können, deren maximal erlaubte Datagramm-Länge kleiner ist.

Sender und Empfänger in TCP/IP Netzen können über IPv4 eineindeutig mit 32-Bit- Adressen gekennzeichnet werden. Eine zentrale Stelle vergibt auf Wunsch kostenlos einen Adressbereich an eine Installation, um somit sicherzustellen, dass Endsysteme immer eindeutig identifizierbar sind. Wer nur ein privates Netz unterhält und keine Kommunikation mit anderen Netzen ermöglicht, kann die Adressierung frei entsprechend seinen eigenen Wünschen gestalten.

Da Netze und Installationen unterschiedlich groß sein können, sieht IP eine Einteilung der Adressen in drei verschiedene Klassen vor:

  • Klasse A: (Große Netze) 0-126 nnn.hhh.hhh.hhh
  • Klasse B: (Mittlere Netze) 128.1-191.254 nnn.nnn.hhh.hhh
  • Klasse C: (Kleine Netze) 192.1.1-223.254.254 nnn.nnn.nnn.hhh

„n“ bezeichnet dabei das Netzwerk und „h“ den Host innerhalb des Netzwerkes. Einige Adressen sind für besondere Funktionen wie Test-Und-Diagnosemöglichkeiten reserviert.

Ansprechen kann man einen Zielrechner nicht nur über dessen Adresse, sondern auch über einen vorher vergebenen Namen. Die Umsetzung des Namens auf die eigentliche Zieladresse wird durch das Name Server Protocol geregelt.

Zur Übergabe der Daten an die nächst höhere Schicht stehen die beiden Kommandos SEND und RECV zur Verfügung. Mit übergeben werden Parameter wie Adresse, Protokolltyp, Service-Typ etc. Die Header-Information des IP-Datagramms ist im Minimum 20 Zeichen lang.

Obwohl die Diskussion eines Standardprotokolls sonst eher langweilig ist, wollen wir bei IP einigen Dingen genauer nachgehen – einerseits weil hier sehr interessante Lösungen enthalten sind, andererseits weil das Protokoll für die Benutzung des Internet so immens wichtig ist.

Das Internet Protokoll im Detail

Die ersten Bytes werden vom IP-Header gebildet. Zunächst muss die Versionsnummer angegeben werden, damit sich die empfangende Station darauf einstellen kann. Meist wird heute (noch) die Version 4 benutzt. Man kann mit unterschiedlichen Versionsangaben z.B. verhindern, dass sich verschiedene IP-Versionen im Netz gegenseitig stören.

Danach gibt ein Feld die Länge des Headers an (Internet Header Length IHL) und den Typ des mit diesem Frame geleisteten Dienstes. Die Länge des Headers ist nicht fest, sondern wegen des Optionen Feldes variabel und muss deshalb angegeben werden.

Das „Type of Service“-Feld kann eine Reihe von Qualitäten für den Dienst des IP-Datagramms festlegen. Man kann für Durchsatz, Verzögerung und Zuverlässigkeit jeweils einen Normal- und einen verbesserten Wert annehmen sowie eine vorrangige Behandlung von Datagrammen verlangen. Die beteiligten Router sind dann entweder dazu in der Lage oder nicht.

Das zweite und dritte Byte dient der Darstellung der Gesamtlänge des Frames. Ein Frame-Datenfeld kann maximal 65.535 Bytes lang werden. Manche Netze, Protokolle oder Zwischenschalteinrichtungen können diese Länge nicht verarbeiten. IP definiert eine Mindestlänge von 576 Bytes. Es kann also durchaus die Notwendigkeit bestehen, IP-Pakete zu fragmentieren und am Ende des Weges wieder zusammenzubauen.

Jedes dabei entstehende Fragment hat natürlich wieder ein ganzes IP-Frame-Format mit eigenem Header. Kurzum: Man erzeugt auf diese Weise nur Overhead.

Wie gesagt, gibt es nur die Send- und Deliver-(Receive-)Primitive. Das Send-Primitiv benutzt die Parameter: Quell-Adresse, Ziel-Adresse, Protokoll, Services-Typ Indicator, „Nicht fragmentieren“-Indicator, Lebenszeit, Datenlänge, Optionen und Daten. Das Deliver-Primitiv kann auf die Indikatoren und die Lebenszeit verzichten.

Die Quell-Adresse gibt die Internet-Adresse des Senders an, während die Ziel-Adresse die Internet-Adresse des Empfängers beschreibt. Das Feld „Flags“ dient zur Aufnahme der Kontrollflags für „Don‘t Fragment“ und „More Fragment“, welches zur Eingliederung von Fragmenten bei der Reassemblierung benutzt wird.

Der Fragment Offset

Der Fragment Offset gibt die Lage der Fragmentdaten relativ zum Anfang des Datenblocks im ursprünglichen unzerlegten Frame als Vielfaches von 8 Bytes an. Maximal sind pro Datagramm 8.192 Fragmente möglich. Durch den Fragment Offest kann der Empfänger auch dann ein Datagramm wieder zusammenbauen, wenn die einzelnen Fragmente auf dem Weg vom Sender zum Empfänger etwas durcheinandergeraten sind.

Wegen der Identifikation ist es darüber hinaus auch gar nicht schlimm, wenn Fragmente mehrerer Datagramme durcheinander purzeln. Dies geschieht z.B. dann, wenn im Rahmen einer bestehenden Verbindung plötzlich ein dynamisches Re-Routing stattfindet, z.B. weil sich Optimalitätskriterien geändert haben oder weil schlicht eine defekte oder überlastete Leitung umgangen werden soll.

Bei großen Netzen ergab sich schnell das Problem endlos kreisender Uralt-Pakete. Sie können aus den unterschiedlichsten Gründen entstehen, z.B. dann, wenn das Adressierungsschema geändert wurde oder ein Empfänger die Pakete nicht „abgenommen“ sondern zurückgeschickt hat.

Wir stellen uns vor, dass eine Teilstrecke zusammenbricht, weil eine Leitung in der Mitte ausfällt. Das dynamische Re-Routing baut einen Ersatzweg auf. Leider muss dieser Weg schon weit vor der eigentlichen Störstelle „abzweigen“. Deshalb nimmt ein Protokoll der höheren Schichten (ab 4) an, dass eine Menge von Daten verlorengegangen ist, und veranlasst den Sender, in seiner Übertragung nochmals zurückzusetzen und früher bereits übertragene Daten, die aber durch das Re-Routing „verschollen“ sind, erneut zu übertragen. Es ist dann denkbar, dass die Router, die zwischen neuem Abzweig und Störstelle liegen, noch die alten Datenpakete gespeichert haben, weil sie sie ja durch die gestörte Leitung nicht mehr losgeworden sind. Wird dann die gestörte Leitung früher als erwartet wieder arbeitsfähig, schicken die Router die Pakete einfach weiter. So kommen dann völlig veraltete Pakete als Doubletten bei den Empfängern an.

weiter mit: Die Lebenszeit begrenzen

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2049135 / Netzwerk Basics)