Kapitel 1: Das TCP/IP- und OSI-Netzwerkmodell

Es existiert heute kaum ein Computer, der die TCP/IP genannte Netzwerkprotokollsammlung nicht unterstützt. Das liegt daran, dass heute so gut wie jeder Computer mit dem Internet verbunden ist und deshalb gar nicht darum herum kommt. Jedes Betriebssystem, ob Windows, Linux oder Unix, unterstützt TCP/IP. Selbst die sogenannten digitalen Assistenten (PDAs) und neueren Mobiltelefone unterstützen TCP/IP. Netzwerk-Switches unterstützen TCP/IP und Router natürlich ebenfalls, denn sonst könnten sie ihre Aufgabe, Daten über lokale Netzwerke und das Internet an den richtigen Adressaten weiterzuleiten, gar nicht erledigen.

So einfach war es nicht immer. Es ist noch nicht besonders lange her, da gab es keine Netzwerkprotokolle – auch kein TCP/IP. Computerhersteller erfanden die ersten Netzwerkprotokolle, die aber zunächst nur die Systeme genau dieses Herstellers unterstützten. Die Details der Implementierung wurden als Geheimnis gehütet. Irgendwann erkannten die Hersteller aber die Notwendigkeit, ihre Computer auch mit Computern und Geräten anderer Hersteller kommunizieren zu lassen, und veröffentlichten ihre Netzwerkprotokolle. IBM veröffentlichte beispielsweise 1974 ihr Netzwerkmodell Systems Network Architecture (SNA). Daraufhin entwickelten andere Hersteller Produkte, mit deren Hilfe ihre Computer über SNA mit den Computern von IBM kommunizieren konnten. Das funktionierte tadellos, hatte aber unter anderem den Nachteil, dass die großen Hersteller sagen konnten, wo es im Netzwerkmarkt langgeht. Dieses Problem ist noch immer nicht so ganz gelöst ...

Eine bessere Lösung war es jedenfalls, ein offenes standardisiertes Netzwerkmodell zu schaffen, das alle Hersteller unterstützen. In den später 1970er Jahren nahm sich die International Organization for Standardization (ISO) dieser Aufgabe an und begann, an etwas zu arbeiten, das wir heute als Open-Systems-Interconnection- oder OSI-Netzwerkmodell kennen. Das Ziel des OSI-Modells war von Anfang an, Netzwerkprotokolle zu standardisieren, um die Kommunikation zwischen allen Computern auf der Welt zu ermöglichen.

Dem US-Verteidigungsministerium verdanken wir nicht nur Patriot-Raketen sondern auch ein zweites standardisiertes offenes Netzwerkmodell. Verschiedene amerikanische Universitäten entwickelten (freiwillig) im Auftrag des Ministeriums Netzwerkprotokolle. Diese Arbeit resultierte in ein konkurrierendes Netzwerkmodell mit dem Namen TCP/IP.

Ende der 1980er Jahre gab es viele konkurrierende proprietäre Netzwerkmodelle, darunter beispielsweise auch Novells IPX/SPX, und zwei konkurrierende standardisierte Netzwerkmodelle (OSI und TCP/IP). Was passierte, wissen wir: Am Ende setzte sich TCP/IP durch, nicht nur unter den zwei standardisierten Modellen, sondern es verdrängte auch viele der proprietären Protokolle.

Dieses Kapitel liefert die Grundlagen zu TCP/IP. Es beschreibt, was das TCP/IP-Netzwerkmodell ist und wie es funktioniert. Da in Verbindung mit TCP/IP immer wieder Begriffe auftauchen, die sich auf OSI beziehen, ist es notwendig, auch kurz auf das OSI-Modell einzugehen.

1.1  Die TCP/IP-Architektur

TCP/IP definiert eine große Anzahl von Protokollen, die Computern erlauben, miteinander zu kommunizieren. Allerdings sind es nur einige wenige Protokolle, die tatsächlich als „Hauptprotokolle” betrachtet werden. Von diesen wenigen Schlüsselprotokollen gelten zwei Protokolle als die wichtigsten: Das Internet Protocol (IP) übernimmt die Adressierung, das Datagram-Routing und weitere Funktionen in einem Internetzwerk. Das Transmission Control Protocol (TCP) ist das primäre Protokoll der Transportschicht; es ist verantwortlich für den Verbindungsaufbau und das Verbindungsmanagement und sorgt für einen zuverlässigen Datentransport zwischen Softwareprozessen auf Geräten. Die Details aller Protokolle der TCP/IP-Suite sind in Dokumenten beschrieben, die Request for Comments (RFCs) genannt werden. Wer die in den TCP/IP-RFCs beschriebenen Protokolle in einen Computer implementiert, kann relativ sicher sein, dass dieser Computer mit anderen Computern kommunizieren kann, die ebenfalls TCP/IP implementiert haben.

Wie andere Netzwerkarchitekturen verteilt TCP/IP die verschiedenen Protokolle auf unterschiedliche Schichten oder Layers eines Architektur- oder Schichtenmodells. Ein solches Modell hilft, die einzelnen Komponenten und deren Funktionen zu beschreiben. Als klassisches Schichtenmodell wird zwar das 1979 definierte OSI-Modell angesehen. Protokollschichtenkonzepte existierten allerdings schon lange, bevor sie durch das OSI-Modell formalisiert wurden. Ein Beispiel dafür ist eben die TCP/IP-Protokollarchitektur. Da TCP/IP historisch eng mit dem Department of Defence (US-Verteidigungsministerium) verknüpft ist, wird das TCP/IP-Schichtenmodell auch als DoD-Modell bezeichnet.

Tabelle 1.1 zeigt die Hauptkategorien des TCP/IP-Architekturmodells.

TCP/IP-Layer (Schicht)

Beispielprotokolle

Application (Anwendungsschicht)

HTTP, POP3, SMTP, FTP, Telnet

Transport (Transportschicht)

TCP, UDP

Internet (Internetschicht)

IP (IPv4 und IPv6)

Network Access (Netzzugangsschicht)

Ethernet, Token-Ring, FDDI

Tabelle 1.1: Das TCP/IP-Architekturmodell

Hinweis

Für die Bezeichnungen der einzelnen Schichten sowohl im TCP/IP- als auch im OSI-Schichtenmodell gibt es deutsche Begriffe. In Tabelle 1.1 sehen Sie die deutschen Begriffe in Klammern hinter den englischen Originalbegriffen. Es empfiehlt sich, beide Begriffe zu lernen, weil der größte Teil der Dokumentation zu TCP/IP und anderen Netzwerkthemen in englischer Sprache vorliegt und IT-Profis selbst in Deutschland häufig die englischen Originalbegriffe bevorzugen (und die deutschen Begriffe manchmal noch nicht einmal kennen – ich selbst muss sie auch immer wieder nachschlagen).

Tabelle 1.1 zeigt die vier Schichten des TCP/IP-Modells und nennt für jede Schicht beispielhaft ein paar populäre Protokolle, die eben auf der jeweiligen Schicht angesiedelt sind. Die folgenden Abschnitte beschreiben jede der vier Schichten und ihr Zusammenspiel genauer.

1.1.1  Die TCP/IP-Anwendungsschicht

Gleich das Wichtigste vorweg: Die TCP/IP-Anwendungsschicht definiert nicht die Anwendung selbst, sondern Dienste, die von Anwendungen benötigt werden. Das kann im Fall von HTTP beispielsweise die Fähigkeit sein, eine Datei zu übertragen. Die TCP/IP-Anwendungsschicht bietet also der auf einem Computer laufenden Anwendungssoftware Dienste. Sie bildet die Schnittstelle zwischen der Software auf dem Computer und dem Netzwerk.

Die heute populärste TCP/IP-Anwendung ist ohne Zweifel der Web-Browser. Einen Web-Browser zu benutzen ist so einfach wie Kaugummi kauen: Sie starten den Web-Browser auf Ihrem Computer und tippen den Namen der gewünschten Website ein, die daraufhin – falls nichts schiefgeht – erscheint. Hinter den Kulissen läuft dabei natürlich einiges ab.

Nehmen wir einmal an, Peter öffnet seinen Browser, der bequemerweise so konfiguriert ist, dass er automatisch die Homepage des Web-Servers Webby lädt.

Um die Webseite von Webby zu bekommen, sendet Peter einen HTTP-Header zu Webby. Dieser Header enthält den Befehl „get”, um eine Datei abzurufen. Normalerweise enthält diese Anfrage auch noch den Namen der Datei. Wird kein Name angegeben, nimmt der Web-Server an, dass die Default-Webseite gewünscht ist. Damit liegt er in der Regel richtig.

Hinweis

In deutschsprachiger Literatur über Netzwerkprotokolle liest man statt Header gelegentlich Kopf, beispielsweise statt Nachrichten-Header Nachrichtenkopf. Obwohl dies ein Buch in deutscher Sprache ist, möchte ich doch lieber beim englischen Originalbegriff Header bleiben.

Abb. 1.1: Eine HTTP-Get-Anfrage und die HTTP-Antwort

Die Antwort des Web-Servers enthält ebenfalls einen HTTP-Header, der aber gerade mal ein „OK” zurück liefert. In der Realität enthält der Header natürlich einen HTTP-Return-Code, der sagt, ob die Anfrage bedient werden kann. Kann der Web-Server die gewünschte Datei nicht finden, sendet er einen HTTP-404-Fehler, „not found”. Findet er die Datei, dann sendet er den Return-Code 200: „Alles klar, ich bearbeite die Anfrage.”

Dieses einfache Beispiel zeigt eines der wichtigsten Konzepte von Netzwerkmodellen: Wenn eine...