Mod-el: Substantiv: 1 – strukturelles Design, 2 – eine Miniaturdarstellung, 3 – ein Beispiel für eine Emulation oder Imitation

Ein Modell ist eine Methode, um die Funktionen und Eigenschaften eines Systems zu organisieren und damit sein strukturelles Design zu definieren. Ein Design kann uns helfen, zu verstehen, wie ein Kommunikationssystem Aufgaben bewältigt, um eine Protokollsuite zu bilden. Vielleicht zum besseren Verständnis von Modellen: Kommunikationssysteme werden oft mit der Post verglichen (Abbildung 1.1). Angenommen, Sie schreiben einen Brief und bringen ihn zum Postamt. Irgendwann werden die Briefe sortiert und dann über irgendein Transportsystem an ein anderes Postamt geliefert. Dort werden sie wieder sortiert und einem Zusteller übergeben, der sie an ihr Ziel bringt. Der Brief wird mehrmals auf seinem Weg angefasst und quasi verarbeitet. Jeder Teil des Systems versucht, das Gleiche zu erreichen – die Post auszuliefern. Allerdings muss jeder Bereich einer bestimmten Menge an Regeln gehorchen. Beim Transport befolgt der Lkw die Verkehrsregeln, während der Brief an den nächsten Verarbeitungspunkt gebracht wird. Dazwischen sorgen Inspektoren und Sortierer dafür, dass die Postsendungen gezählt werden und sicher ankommen, ohne dass sie sich um Verkehrsschilder oder Ampeln sorgen müssen.

Ein Kommunikationssystem funktioniert nicht viel anders, da die Nachrichten, die auf einem Computer erzeugt werden, verarbeitet und ausgeliefert werden müssen, wobei jedes Teil der Ausrüstung eine Funktion ausführt und bestimmten Übertragungsregeln folgt. Abbildung 1.2 zeigt ein typisches Szenario, in dem zwei Computer über ein Netzwerkgerät und ihre Netzwerkkarten miteinander verbunden sind. Zwei Leute kommunizieren mithilfe eines Programms miteinander, sei es ein Instant Messenger oder ein E-Mail-Programm. An irgendeiner Stelle müssen wir genau entscheiden, wie wir diese Kommunikation behandeln wollen. Wenn Sie den Brief wegschicken, können Sie die Adresse schließlich auch nicht in irgendeiner beliebigen Sprache auf den Umschlag schreiben oder die Postleitzahl weglassen, und der Fahrer des Postautos kann auch nicht einfach auf der falschen Straßenseite fahren.

Wie also wird die Aufgabe der einzelnen Geräte oder Verbindungen festgelegt? Ein Programm auf Benutzerebene sollte nicht dafür verantwortlich sein, die Kodierungssequenz oder die Signaltypen zu wählen, die zwischen Client und Server benutzt werden. Der Brief beschließt ja auch nicht, per Flugzeug oder Schiff zu reisen. Und die Netzwerkkarte (Network Interface Card oder NIC) hat ebenfalls nichts damit zu tun, wie der Nachrichten-Header aufgebaut ist, genau wie sich das Postsortiersystem nicht darum kümmert, ob Sie einen Brief mit Kugelschreiber, Bleistift oder vielleicht mit einer Schreibfeder schreiben.

Modelle werden normalerweise in einer hierarchischen oder schichtförmigen Struktur organisiert. Jede Schicht muss bestimmte Funktionen ausführen. Um diese Funktionen durchzuführen, werden Protokolle geschaffen, sodass mit jeder Schicht auch Protokolle verknüpft sind. Man bezeichnet die Protokolle zusammen als Protokollsuite. Die unteren Schichten sind oft mit der Hardware verbunden, die oberen mit der Software. So arbeitet zum Beispiel Ethernet auf den Schichten 1 und 2, während das File Transfer Protocol (FTP) ganz oben auf dem Modell tätig ist. Das gilt sowohl für das TCP/IP- als auch für das OSI-Modell. Man kann den Netzwerkverkehr auch in Bezug auf diese Schichten betrachten, von denen man viele tatsächlich mithilfe eines Werkzeugs zum Aufzeichnen von Paketen, wie etwa Wireshark, sehen kann. In Abbildung 1.3 werden die wichtigsten Schichten des TCP/IP-Modells in einer Nachricht gezeigt, die an einen Webserver geht.

Bevor wir weitergehen, folgt erst mal eine Bestandsaufnahme. Ein Modell beschreibt die gesamte Struktur. Am Anfang dieses Kapitels habe ich gesagt, dass viele dieser Modelle auf dem Rückzug sind. Jedes Modell enthielt bestimmt mindestens eine gute Idee, dennoch benutzen heutzutage alle ein ganz bestimmtes Modell, nämlich TCP/IP. So haben zum Beispiel sowohl Apple als auch IBM ursprünglich ihre eigenen Protokollsuiten entwickelt, sind aber wegen dessen Beliebtheit schließlich doch bei TCP/IP gelandet. In diesem Abschnitt erläutere ich die Nutzung von Modellen aus historischer Sicht und stelle eine modernere Betrachtungsweise vor.

Selbst ein einfaches Kommunikationssystem ist eine komplizierte Umgebung, in der täglich Tausende oder Millionen von Transaktionen stattfinden. Miteinander verbundene Systeme sind noch deutlich komplexer. Eine einzige elektrische Störung oder ein Fehler in der Softwarekonfiguration kann die erfolgreiche Durchführung dieser Transaktionen verhindern. Modelle bieten einen Ausgangspunkt zum Feststellen, was getan werden muss, um die Kommunikation zu erlauben oder um zu ermitteln, wie Systeme, die unterschiedliche Protokolle benutzen, miteinander verbunden werden können. Sie helfen darüber hinaus bei der Lösung von Problemen. Wie würde zum Beispiel ein Novell Netware-Client, auf dem IPX/SPX läuft, mit einer IBM AS400 über ein TCP/IP-basiertes Netzwerk kommunizieren? Abbildung 1.4 stellt ein Szenario dar, in dem mehrere unterschiedliche Plattformen miteinander interagieren müssen. Windows-Knoten bauen auf der TCP/IP-Protokollsuite auf, können aber nötigenfalls auch Novell Netware-Clientsoftware zur Netzwerkauthentifizierung ausführen. Novell entwickelte Protokolle zur Vernetzung und zum Transport: IPX und SPX. Am anderen Ende des Netzwerks kommuniziert das IBM-Mainframe über die Protokolle, die im SNA-Modell verwendet werden. Stellen Sie sich die Programmierung und den zusätzlichen Aufwand vor, die nötig sind, um die Transaktionen zwischen diesen getrennten Architekturen aufrechtzuerhalten.

Ein anderes Beispiel ist ein Netzwerk aus Apple-Computern, auf denen Appletalk läuft, das mit einem Netzwerk aus Windows-Maschinen verbunden ist, die TCP/IP benutzen.

Wie bereits erwähnt, ist TCP/IP heutzutage die vorherrschende Architektur. Mit TCP/IP wurden die Komplexitäten der Kommunikation zwischen verschiedenen Plattformen deutlich reduziert. Protokollsysteme wie Appletalk, Netware und SNA werden als überholt betrachtet. Dennoch ist es immer noch wichtig, zu verstehen, wie Protokollschichten auf einem bestimmten Kommunikationsgerät funktionieren oder wie Prozesse auf einem Netzwerk miteinander interagieren könnten. Wenn man versucht, normale Probleme zu lösen oder potenzielle Sicherheitsrisiken auszuräumen, bieten die Modelle und deren Schichten logische Einstiegspunkte. Das bewahrt Sie davor, die Routingprotokolle nach Fehlern abzusuchen, wenn die LED-Leuchte für die bestehende Verbindung ausgeht.

Das OSI-Modell ist ein sogenanntes Referenzmodell. Das bedeutet, dass dieses spezielle Modell eine Methode bietet, mit der Standards und Protokolle miteinander verglichen werden können, um Konnektivität und Konsistenz zu unterstützen. Entwickler können ein Referenzmodell verwenden, um zu verstehen, wie Übertragungen aufgebaut sind, und um Methoden zu erzeugen, mit denen man zwischen Systemen übersetzen kann.

Das grundlegende OSI-Modell ist in ISO/IEC (International Standards Organization/International Electrotechnical Commission) 7498 standardisiert, das die meisten der hier verwendeten Definitionen enthält. Diese beiden Organisationen haben ein gemeinsames technisches Komitee geschaffen (Joint Technical Committee, JTC), das sich mit den Problemen und Fragen befasst, die im Zusammenhang mit der Informationstechnik auftauchen. Dieses Modell wurde in Zusammenarbeit mit der ITU-T entwickelt und als ITU-T Recommendation X.200 veröffentlicht. Die ITU-T ist die International Telecommunications Union – Telecom-Sektor. Das soll es jetzt aber erst einmal gewesen sein mit den Akronymen, kommen wir nun...