Protokolle

Wozu Protokolle? Eine nicht ganz ernst zu nehmende Ausarbeitung.

Kommunikationsprobleme sind allgegenwärtig. Sei es der juristische Kauderwelsch der aktuellen Fassung der Steuererklärung, der selbst gestandenen Juristen den Schweiß auf die Stirn treibt. Seien es die Nuancen des englischen Humors, die es dem Außenstehenden schier unmöglich machen, Ernst von Ironie zu unterscheiden. Oder die Sprachbarriere allgemein, die die Verständigung zwischen den Nationalitäten ungemein erschwert...

Mensch weiß sich oft zu helfen. Er engagiert einen Steuerberater, schmunzelt verständnisvoll bei einer Backgammon-Runde in feiner englischer Gesellschaft oder gestikuliert, wenn der magere Wortschatz eine Beschreibung seines Herzenswunsches nicht zulässt.

Bei der Kommunikation zwischen Computern ist das ungleich problematischer. Hier gibt es (noch) keine intelligenten Programme, die fehlende oder zweifelhafte Informationen in Eigenregie recherchieren. Hier gibt es keine einheitliche Sprache und es gibt für jede Anforderung dutzende Client-Programme, die diese formulieren und ebenso dutzende Server, die sie erfüllen. Und jeder Client sollte mit jedem Server zusammen arbeiten und jeder Server muss jedem Client antworten können.

Die Lösung für derartige Probleme ist die Schaffung allgemein gültiger Regeln, so genannter Protokolle.

OSI Referenzmodell - Spielzeug der Theoretiker

Der Nebentitel Spielzeug der Theoretiker soll verdeutlichen, dass dieses Modell praktisch kaum konsequente Anwendung findet. Dazu sind manche Definitionen zu »schwammig«, um verbindliche Strukturen zu schaffen. Und dennoch verhalf es, das Verständnis für die Prinzipien des Datenaustauschs zu schärfen.

Beginnen wir mit einem Beispiel und betrachten die Kommunikation zwischen einem NIS-Server und einem Client. Um die Bedeutung der Schichten des 7-Schichten-OSI-Modells zu veranschaulichen, nehmen wir an, dass der Server auf einem 64-Bit-Rechner und der Client auf einem 32-Bit-Rechner läuft, d.h. die Daten liegen auf den beteiligten Rechnern in unterschiedlichen Formaten vor.

Abbildung 1: Schichten des OSI-Modells

Ablauf der Kommunikation: Der NIS-Client sendet eine Anfrage. Da er das vom Server verstandene Datenformat nicht kennen kann, bringt er diese in ein allgemeines Format (im Zusammenhang mit RPC kommt meist External Data Representation XDR zum Einsatz). Der Remote Procedure Call organisiert den »entfernten Prozeduraufruf«, indem er die Daten zusammen mit Informationen zum erwünschten Dienst verpackt. Auf Transportebene werden u.a. die Daten in Blöcke bestimmter Größe zerlegt, die Vermittlung übernimmt die Adressierung des Zielrechners auf IP-Ebene. Die Sicherungsschicht ist schon recht Hardware spezifisch und kümmert sich um die fehlerfreie Übertragung auf dem eigentlichen Medium. Schließlich erfolgt die Übertragung über ein physisches Medium, dessen Charakteristika durch das Protokoll der Übertragungsschicht spezifiziert ist. Auf Serverseite wird das Paket der Schicht 2 übergeben. Stellt diese die Fehlerfreiheit fest, erreicht es die Vermittlungsschicht. Auf Transportebene werden die vom Sender erzeugten Pakete zu der kompletten Nachricht zusammen gefügt. Der RPC-Server-Prozess wertet die Anforderungen aus. Sind sie erfüllbar, werden die Daten ins benötigte Format übertragen und der NIS-Server konsultiert. Dieser generiert eine Antwort und das Spiel wiederholt sich mit verteilten Rollen...

Widmen wir uns den einzelnen Schichten und ihren Aufgaben.

Übertragungsschicht

Diese Schicht korrespondiert mit der zugrunde liegenden Hardware. Protokolle dieser Schicht legen die Eigenschaften der Schnittstellen fest wie Anschlusseigenschaften, zulässige Übertragungsraten, Signalpegel und elektrische Kodierung der einzelnen Bits (z.B. Modulationsverfahren bei Modems)...

Verbreitete Vertreter dieser Protokolle sind RS-232 (serielle Schnittstelle) und X.21.

Sicherungsschicht

Protokolle dieser Schicht gewährleisten die Unversehrtheit der übertragenen Daten. Dazu verpacken sie die Daten in für das Medium zulässige Einheiten, steuern den Fluss der Übertragung und fügen Prüfsummen an die eigentlichen Datenpakete an, anhand derer der Empfänger den Zustand der Daten überprüfen kann. Im Fehlerfall kümmern sich die Protokolle dieser Schicht automatisch um eine Wiederholung der Übertragung.

Hier offenbart sich eine Schwäche des OSI-Modells, das die Grenzen der Schichten nicht allzu konsequent gezogen hat. So unterteilen die Realisierungen lokaler Netzwerke diese Schicht nochmals in Media Access Control (MAC) und Logical Link Control (LLC). So organisiert z.B. Ethernet den Zugang zum Übertragungsmedium mittels einer MAC-Schicht (oft CSMA/CD - Carrier Sense Multiple Access with Collision Detect), während LLC eine Schnittstelle zu übergordneten Diensten darstellt.

Weitere wichtige Protokolle der Sicherungsschicht sind High-Level Data Link Control HDLC, das darauf basierende Point-to-Point-Protocol PPP, und das Serial Line Protocol SLIP.

Vermittlungsschicht

Auch als Netzwerkschicht bezeichnet, ist diese Schicht für den Aufbau eines virtuellen Kommunikationskanals verantwortlich. Dazu zählen das Auffinden eines Weges zum Zielrechner, die Vermittlung der Nachrichten und Pakete (eine »lange« Nachricht wird ggf. in einzelne Pakete unterteilt).

Verfolgt man den Weg eines Paketes vom eigenen Rechner hin zu einem Rechner »am anderen Ende der Welt«, so stellt man fest, dass die Route durch zahlreiche Teilnetze führt, denen mitunter vollkommen unterschiedliche Technologien (Lichtwellenleiter, Funk, Ethernet, Modem...) zugrunde liegen. Für jeden Übergang in ein neues Teilnetz wird ein Protokollwechsel in den »unteren« Schichten notwendig. An welchen Rechner eines solchen Teilnetzes das Paket als nächstes zu »routen« ist, bleibt Angelegenheit der Vermittlungsschicht.

Den bekanntesten Vertretern dieser Schicht, IP, ICMP und ARP, wenden wir uns nachfolgend zu. Weitere Protokolle sind X.25, Exterior Gateway Protcol EGP, Border Gateway Proctocol BGP, Open Shortest Path First OSPF und Routing Information Protocol RIP.

Transportschicht

Diese Schicht stellt den »anwendungsorientierten« Schichten einen logischen Übertragungskanal zur Verfügung, so dass diese ihre Daten sequentiell an die Schnittstelle senden. Protokolle der Transportschicht steuern die Blocklängen, die Geschwindigkeit, mit der Pakete an die unteren Schichten weiter gegeben werden und realisieren (oft) eine Fehlersicherung.

Damit sich Sender und Empfänger auch verstehen, muss auf beiden Seiten dasselbe Transportprotokoll zum Einsatz gelangen, d.h. beide Kommunikationspartner müssen »dieselbe Sprache sprechen«.

Bekannte Protokolle sind TCP und UDP.

Sitzungsschicht

Protokolle der Sitzungsschicht realisieren die logische Adressierung, d.h. sie sind u.a. zuständig, einen Zielrechner zu finden, der die geforderte Anforderung erfüllen kann. Weitere Funktionen sind Nutzeridentifikationen, die erneute Verbindungsaufnahme nach einem Abbruch, Wechsel der Kommunikationsrichtung usw...

Zu den Protokollen zählen der Remote Procedure Call und LU6.2.

Darstellungsschicht

Ein Protokoll der Darstellungssicht organisiert die Umwandlung von Daten und Texten in ein bestimmtes Format. Auch die Terminalemulationen ordnen sich in diese Schicht ein.

XDR und ASN.1 zählen zu dieser Gruppe.

Anwendungsschicht

Letztlich bilden die Protokolle der Anwendungsschicht die Schnittstelle zu den Anwendungsprogrammen.

Mit FTP und HTTP seien nur zwei Vertreter erwähnt.

Der TCP/IP-Protokollstack - Die Praxis

Abbildung 2: TCP/IP vs. OSI-Modell

Die TCP/IP-Architektur hatte sich bereits durchgesetzt, als die International Standardisation Organisation (ISO) ihr Modell eines Internet-Protokollstacks Open System Interconnection (OSI) veröffentlichte. Letztlich basierte das OSI-Modell auf den Erfahrungen von TCP/IP, aber es konnte sich bis heute in der Praxis nicht durchsetzen.

Der Grund für den Erfolg des TCP/IP-Ansatzes ist nicht allein in der BSD-Implementierung zu suchen. Es hat sich auch gezeigt, dass die gewählte Struktur den Zusammenhängen zwischen den Komponenten der Hardwareebene wie auch der Anwendungsebene besser gerecht wird. So liefern Hersteller der Übertragungstechnik die Software der Ebenen 1 und 2 mit dieser aus, während der Anwendungsentwickler seine Applikation mit Eigenschaften der »oberen« OSI-Schichten ausstattet.

Nicht zuletzt verfügt jedes Betriebssystem, das den Zugang zum Internet ermöglicht, über eine Implementierung des TCP/IP-Protokollstacks.

Im weiteren Verlauf geben wir zu den beschriebenen Protokollen deren Einordnung in das OSI-Referenz-Modell an.

Sicherungsschicht: Das Point to Point Protocol

Abbildung 3: Point to Point Protocol

Das Point-to-Point-Protokoll ist eine Erweiterung von HDLC und ermöglicht permanente Punkt-zu-Punkt-Verbindungen. Häufigster Einsatzbereich sind Wählverbindungen (Modem).

Das enthaltene Protokollfeld ermöglicht die Unterstützung beliebiger Vermittlungsprotokolle; die Prüfsumme erlaubt die Verifizierung des Dateninhalts.

Als optionale Eigenschaften können Implementierungen Folgendes enthalten:

• Einwahl nach Bedarf, Verbindungsabbau nach Zeit- oder Gebührenüberschreitung
• Parallele Verwendung mehrerer Leitungen
• Einfache Filtermechanismen
• Komprimierung der Daten und/oder des Headers

Das PPP handelt mit der Gegenseite eine Maximale Empfangspaketgröße aus, das ist der Grund für den verzögerten Verbindungsaufbau über analoge Telefonleitungen.

Sicherungsschicht: Das Serial LIne Protocol

Abbildung 4: Serial Line Protocol

Das Serial Line Protokoll ist das zweite Protokoll der Sicherungsschicht, das bei Modemverbindungen zum Einsatz gelangt. Wie der Name bereits besagt, dient es der Verbindung zweier Rechner über eine serielle Leitung. Als Protokoll der Schicht 3 kommt allerdings einzig IP in Frage; auch beinhaltet das Protokoll keinerlei Sicherungsmaßnahmen.

Mögliche Einsatzgebiete sind sichere Leitungen, bspw. ein Nullmodemkabel.

Auf SLIP baut das CSLIP (Compressed SLIP) auf, das den Header von TCP-Paketen nach einem Verfahren von Van Jacobsen komprimiert.

Vermittlungsschicht: Das Address Resolution Protocol

Abbildung 5: Address Resolution Protocol

Während im Internet Pakete anhand ihrer IP-Adresse vermittelt werden, erfolgt in lokalen Netzen die Adressierung mittels Hardwareadressen. So besitzt jede Ethernetnetzwerkkarte eine (weltweit) eindeutige 48 Bit lange Adresse.

Um nun ein IP-Paket vermitteln zu können, muss ein Rechner die Hardwareadresse des Rechners kennen, an den das Paket als nächstes zu senden ist (Bis ein Paket seinen Bestimmungsort erreicht, durchläuft es mitunter zahlreiche Rechner. In jedem dieser Zwischenknoten muss entschieden werden, wohin das Datenpaket im nächsten Schritt zu senden ist. Auf dieses als Routing bezeichnete Verfahren werden wir später eingehen).

Für die Adressermittlung bieten sich mehrere Vorgehensweisen an:

• Umsetzung von IP- in Hardwareadressen mittels statischer Tabellen
• Verwendung eines Algorithmus zur Berechnung der Hardwareadresse aus der IP-Adresse
• Verwendung dynamischer Tabellen, die regelmäßig aktualisiert werden

In der großen, weiten Welt des Internets ist nichts statisch. Rechner kommen hinzu oder gehen vom Netz, Rechner erhalten eine neue IP-Adresse oder eine andere Netzwerkkarte... die Zuordnung mittels statischer Methoden zu versuchen, würde jeden Administrator zum Ausdauerathleten ausbilden.

Ein Algorithmus, der 48 Bit auf derer 32 abbildet, kann niemals ein eindeutiges Ergebnis liefern, zumal eine Gruppierung von Rechnern eines bestimmten Bereiches zu einem Subnetz unmöglich realisierbar wäre.

Bleibt der dynamische Aufbau von Tabellen. Ein Rechner, der ein IP-Paket senden möchte, schaut nun erst einmal in seiner ARP-Tabelle nach, ob ein zugehöriger Eintrag existiert. Wenn ja, verwendet er die gespeicherte Hardwareadresse bereits. Wenn nein, kommt das Address Resolution Protocol zum Zuge. Der Rechner sendet nun einen Broadcast (eine Nachricht, die gleichzeitig an mehrere Rechner eines zumeist lokalen Netzwerkes geht) aus, mit der Bitte, dass der Rechner, zu dem die IP-Adresse gehört, seine Hardwareadresse übermitteln möge. Genau jener Rechner sendet darauf hin eine Antwort. Erst jetzt kann der Rechner das IP-Paket zu seinem nächsten Bestimmungsort schicken. Die soeben ermittelte Hardwareadresse bekommt ihren Platz in der ARP-Tabelle (»Caching«), um im sehr wahrscheinlichen Falle einer folgenden Übermittlung sofort den Adressat parat zu haben.

Diese ARP-Tabelle ist allerdings in ihrer Kapazität beschränkt, somit werden ältere Einträge zyklisch entfernt (meist nach 10 Minuten des Nichtgebrauchs). Das Verfahren hat den Vorteil, dass die Tabelle auch auf Veränderungen im Netz reagiert, weil bspw. die IP-Adresse einem anderen Rechner zugewiesen wurde...

Vermittlungsschicht: Das Internet Protocol

Die heute gebräuchlichen Adressen des Internet-Protokolls sind 32 Bit lang, die häufigste Notation erfolgt byteweise als Dezimalzahl, bspw. »127.211.7.9«. Der Mathematiker errechnet rasch, dass mit 32 Bit 2³² = 4.294.967.292 Rechner adressierbar wären. Der Praktiker interveniert, dass sich nicht alle Adressen nutzen lassen, da etliche Adressen und Adressbereiche für bestimmte Funktionen reserviert sind. Auch existieren genügend Lücken im Adressraum, da IP's im Block an lokale Netzwerke vergeben werden, diese aber nur selten ihr Kontingent voll ausschöpfen.

Fazit ist, dass schon heute die Zahl der verfügbaren Adressen den Bedarf bei weitem nicht mehr decken kann und eine Aufweitung der Adressen erforderlich ist. Aus diesem Grund steht der designierte Nachfolger des korrekt als IPv4 bezeichneten Protokolls seit Jahren (erste Spezifikation 1995) in den Startlöchern. Anliegen dieses IPv6 ist nun die Definition eines Protokolls der Vermittlungsschicht, das mit 128 Bit Adressen arbeitet. Die damit erzielte Größe erscheint übertrieben (jedem Quadratmillimeter auf dem Globus ließen sich hiermit ca. 667 Billiarden IP's zuweisen), jedoch ist man auf weite Sicht auf der sicheren Seite.

Mit dem Adressformat nach IPv4 befasst sich der Abschnitt Netzwerkstrukturen, IP-Adressen.

Eigenschaften des IPv4

Bei der immensen Bedeutung, welche gerade dieses Protokoll für die Paketvermittlung im Internet erlangt hat, lohnt sich ein tieferer Einblick in dessen Fähigkeiten.

Zunächst gilt zu vermerken, dass es sich um ein verbindungsloses Protokoll handelt, d.h. es arbeitet, ohne dass eine Verbindung zum Partner zuvor aufgebaut wurde (analog zum Unterschied zwischen einem Telegramm und einem Telefonat). Die maximale Paketgröße beträgt 65535 Bytes. Ein Paket durchläuft auf seinem Weg zum Empfänger meist verschiedenste Subnetze, die ihrerseits nur eine kleinere Paketgröße unterstützen. Das IP beinhaltet deswegen einen Mechanismus zur Fragmentierung von Paketen, d.h. dass ein für ein zu durchlaufendes Subnetz zu großes Datenpaket zerlegt wird und nun mehrere IP-Pakete ihren Weg zum Empfänger suchen. Der Zusammenbau der Paketteile erfolgt erst beim endgültigen Empfänger, da die Teilpakete durchaus auf unterschiedlichen Routen ihr Ziel finden.

Eine Prüfsumme stellt die Unversehrtheit des IP-Kopfes sicher, nicht jedoch die der enthaltenen Daten. Deren Überwachung obliegt dem Protokoll der nächsthöheren Schicht; ein Code im IP-Kopf (Protokoll-Feld) verweist auf den Typ des Protokolls (bspw. steht eine 6 bei TCP und eine 17 bei UDP).

Die letzte erwähnte Eigenschaft, die die Lebensdauer eines IP-Pakets begrenzt, garantiert, dass ein nicht vermittelbares Paket nicht endlos im Netz kursiert, sondern nach Ablauf seiner Lebenszeit verworfen wird. Früher wurde hier tatsächlich mit einer Zeiteinheit gearbeitet, jedoch wich diese bald der maximalen Anzahl Stationen (»Hops«), die ein Paket maximal durchlaufen darf. Jeder Rechner, der das Paket weiterleitet, verringert diesen Wert um 1. Erreicht er in einem Rechner den Wert 0 und handelt es sich nicht um den Zielrechner, so sendet dieser Rechner ein ICMP-Protokoll an den Absender und verwirft das eigentliche Paket.

Wichtige Felder des IPv4

Abbildung 6: Internet Protocol Version 4 (IPv4)

Die Bedeutung mancher Felder ergibt sich schon aus deren Namen, diejenige, deren Bedeutung nicht sofort ersichtlich ist, sollen nun erläutert werden:

IPv6 - Das neue Format

Abbildung 7: Internet Protocol Version 6 (IPv6)

Eine Prüfsumme wie bei IPv4 ist nicht mehr vorgesehen, da die Neuberechnung auf jeder Zwischenstation recht teuer ist (geändertes »Lebenszeit«-Feld) und unter- bzw. übergeordnete Protokolle i.d.R. ohnehin eine Fehlerbehandlung beinhalten. Auch entfällt eine Fragmentierung. Ist ein Datenpaket zu groß für eine Übertragungsstrecke, wird es verworfen und der Absender per ICMP darüber in Kenntnis gesetzt. Der Absender sollte daraufhin das Paket in kleineren Einheiten erneut versenden.

Vermittlungsschicht: Das ICMP-Protokoll

Abbildung 8: Internet Control Message Protocol

Wenn Fehler bei der Vermittlung eines Pakets auftreten, wird i.d.R. eine ICMP-Nachricht an den Absender geschickt. Aber auch zu Diagnosezwecken dient dieses Protokoll, dessen Typ-Feld seine eigentliche Aufgabe offenbart:

Der Kode unterteilt den Pakettyp ggf. in weitere Unterfunktionen. Die Prüfsumme wird über das gesamte Paket gebildet. Das Feld Optionale Daten kann vom jeweiligen Kode abhängige Informationen enthalten.

Schließlich wird im Falle einer aus einem verworfenen IP-Paket resultierenden ICMP-Nachricht der Anfang des IP-Paketes als Daten übermittelt bzw. Testdaten, wenn es sich um ein Diagnosepaket handelte.

Transportschicht: Das Transmission Control Protocol

Abbildung 9: Transfer Control Protocol

Aus Sicht einer Anwendung eröffnet das Transmission Control Protocol einen bidirektionalen, virtuellen Datenkanal zwischen den beiden Kommunikationsendpunkten. Die Daten werden scheinbar in einem Fluss übertragen. Intern gehen diese natürlich blockweise übers Netz, wobei die Blockgröße dynamisch anhand von Parametern wie der Netzauslastung, der Fenstergröße oder der Empfangs- bzw. Sendepuffer angepasst wird. Im Unterschied zum nachfolgend erwähnten User Datagram Protocol kümmert sich TCP selbst um die sichere Übertragung. Es verwendet hierzu Sequenznummern, Prüfsummen, Quittungen und Wiederholung des Transfers bei einer Zeitüberschreitung. Andere wesentliche Eigenschaften sind das Sliding-Window-Verfahren und die Kennzeichnung von Vorrangdaten.

Die Felder des Protokollkopfes bedeuten:

Das Zusammenspiel von Sequenz- und Quittungsnummer wird in den meisten Fällen die Unversehrtheit der übertragenen Daten garantieren. Jedoch verlangt eine ausstehende Quittung das Warten auf diese. Ist nun der Partner ausgefallen, würde ein Sender bis in alle Ewigkeit auf die Bestätigung des Empfangs seines Pakets lauern. Um einen solchen "Hänger" zu verhindern, werden beim Versand eines Pakets gleich mehrere Zeitgeber gestartet.

Der wichtigste Ticker stoppt die seit dem Senden vergangene Zeit. Läuft er ab, ohne dass eine Quittung eintraf, muss das Paket erneut auf die Reise geschickt werden. Diese Zeitspanne wird allerdings dynamisch berechnet (aus dem Mittelwert der bisherigen Paketlaufzeiten), sodass sie sich an veränderte Situationen (hohe Netzlast, alternative Route) allmählich anpasst.

Ein weiterer Wecker wird verwendet, um die Bereitschaft des Empfängers zu überprüfen. Dieser Zeitgeber garantiert, dass ein Datentransfer nicht blockiert, weil dessen Fenstergröße auf 0 steht, das Paket zum Öffnen des Empfangsfensters aber verloren ging.

Der letzte hier vorgestellte Timer hält einen Port noch eine gewisse Zeit geschlossen, nachdem die Verbindung schon abgebaut wurde. Die Zeitspanne entspricht in etwa der maximalen Lebensdauer (TimeToLive) eines Datenpakets und ist nützlich, um die nächste auf dem selben Port eröffnete Verbindung nicht durch alte irrgeleitete Pakete durcheinander zu bringen.

Transportschicht: Das User Datagram Protocol

Abbildung 10:User Datagram Protocol

Neben TCP spielt das User Datagram Protocol eine bedeutende Rolle als Transportprotokoll. Es arbeitet verbindungslos und garantiert keinen Erfolg der Übertragung. Es beinhaltet einzig eine Prüfsumme über die Daten, um beim Empfänger deren Unversehrtheit kontrollieren zu können. Dienste, die UDP verwenden, implementieren häufig eigene Routinen zur Fehlersicherung.

Der schlanke Protokollkopf und der Verzicht auf jegliche Sicherungsmechanismen oder eine Flusssteuerung prädistinieren das Protokoll für zeitkitische Übertragungen auf sicheren Medien (wo ein Datenverlust ziemlich unwahrscheinlich ist). Auch verwenden die meisten RPC-basierten Dienste UDP, da eine solche Abfrage eher einen Telegrammcharakter trägt. (einmalige, kurze Nachrichten).