TCP/IP Technik
|
|
| Home | Publikationen | Heise (c't/iX) | | Blog | Sitemap | Suchen | Webmaster | |
Genau diese Anforderung erfüllen die TCP/IP-Protokolle, die im Internet verwendet werden. Was kann TCP/IP?
In Wirklichkeit besteht jedoch die einzige Verbindung zwischen zwei Rechnern auf der Ebene 1, der physikalischen Schicht. Wenn Daten zu senden sind, werden sie von einer Schicht zur jeweils darunterliegenden Schicht weitergereicht. Damit die einzelnen Schichten voneinander unabhängig sind müssen die Schnittstellen zwischen den Schichten natürlich bekannt und definiert sein. Diese Art von Modulbildung erleichtert die Wartung und Entwicklung von neuen Netzwerkprotokollen und die Fehlersuche.
TCP/IP ist kein Netzwerkprotokoll, das von der Hardware direkt verstanden wird. Normalerweise werden TCP/IP-Daten immer über ein vorhandenes Trägernetz, etwa Ethernet oder X.25, übertragen,denn die Aufgabe von TCP/IP ist es ja gerade, solche vorhandenen Netzwerke zu vereinheitlichen. Im OSI-Modell deckt die Netzwerkschicht also die Hardwareschichten 1 und 2 sowie in einigen Fällen auch noch Teile der Schicht 3 ab. Auf der Netzwerkschicht aufbauend liegt die Internet-Schicht, die die erste Abstraktionsschicht von einem konkreten Netzwerk darstellt. Damit ist das Internet-Protokoll, kurz IP, der Kern von TCP/IP, denn es stellt den grundlegenden Dienst des Netzes zur Verfügung: den Versand von Datenpaketen, sogenannten Datagrammen, über verschiedene Netze hinweg. Die Netzwerkschicht hat keine Information darüber, von welcher Art die Daten sind, die sie befördert: Für eine Ethernetkarte sind die ankommenden Daten eben einfach nur Daten, die vom Netz kommen. Der Kartentreiber interpretiert einen Teil dieser Daten als IP-Header und den Rest als Datenteil eines IP-Paketes. Auf diese Weise ist der IP-Header innerhalb eines Ethernet-Paketes gewissermaßen eingekapselt. Aber auch das IP-Paket selbst enthält selbst wieder ein Datenpaket für eine höhere Protokollebene, dessen Header auf der IP-Ebene als Bestandteil der Daten erscheint.
Jedes IP-Paket enthält zwei Adressen in Form von 32 Bit Worten: Die Absender- und die Empfängeradresse. Eine Internet-Adresse wird meist in Form von vier, durch Punkte getrennten Bytes notiert, man spricht in diesem Fall von der "dotted quad"-Schreibweise. Um die Zustellung von IP-Paketen zu vereinfachen, unterteilt man die Adresse in zwei Teile: Den Netzwerkteil und den Rechnerteil. Ein Router muß, um ein Datenpaket zustellen zu können, nur den Netzwerkteil einer Adresse erkennen. Erst im Zielnetzwerk wird der Rechnerteil einer Adresse ausgewertet. Um den verschiedenen Anforderungen gerecht zu werden, was die Größe von Netzwerken angeht, unterscheidet man verschiedene Aufteilungen der 32 Adreßbits:
Weil das Internet-Protokoll wie bereits erwähnt normalerweise immer auf einem Trägernetzwerk aufsetzt, muß es noch eine andere Eigenschaft der unterliegenden Netzwerkschicht verbergen: Normalerweise existiert bei allen Netzwerken eine maximale Größe, die ein Datenpaket haben kann. Im IP-Jargon nennt man diese Grenze die "maximum transmisson unit", MTU. Natürlich ist diese Obergrenze je nach verwendeter Trägertechnik unterschiedlich. Die Internet-Schicht teilt IP-Pakete, die größer als die MTU des verwendeten Netzwerks in kleinere Stücke, sogenannte Fragmente auf. Auf dem Zielrechner werden diese Fragmente dann wieder zu vollständigen IP-Paketen zusammengesetzt, bevor sie an die darüberliegenden Protokolle weiter gegeben werden.
Welches darüberliegende Protokoll der Transportschicht das Datenpaket bekommt, steht im "Protokoll"-Feld eines jeden IP-Paketes. Jedes Protokoll der Transportschicht bekommt eine eindeutige Identifikationsnummer zugewiesen, anhand derer der IP-Treiber entscheiden kann, wie weiter mit dem Paket zu verfahren ist. Eines der wichtigsten Protokolle der Transportschicht ist TCP.
Im Gegensatz zu IP ist TCP verbindungsorientiert. Das muß so sein, denn TCP-Verbindungen sollen ja für den Benutzer wie Dateien zu handhaben sein. Das bedeutet, eine TCP-Verbindung wird wie eine Datei geöffnet und geschlossen und man kann seine Position innerhalb des Datenstromes bestimmen, genau wie man bei einer Datei die Position des Dateizeigers angeben kann.
Auch TCP sendet die Daten in größeren Einheiten, um den Verwaltungsaufwand durch Header und Kontrollinformation klein zu halten. Im Gegensatz zu den IP-"Paketen" bezeichnet man in die Einheiten der Transportschicht als "Segmente". Jedes gesendete TCP-Segment hat eine eindeutige Folgenummer, die die Position seines ersten Bytes im Bytestrom der Verbindung angibt. Anhand dieser Nummer kann die Reihenfolge der Segmente korrigiert werden und doppelt angekommene Segmente können aussortiert werden. Da die Länge des Segmentes aus dem IP-Header bekannt ist, können auch Lücken im Datenstrom entdeckt werden und der Empfänger kann verlorengegangene Segmente neu anfordern.
Beim Öffnen einer TCP-Verbindung werden zwischen beiden Kommunikationspartnern Kontrollinformationen ausgetauscht, die sicherstellen, daß der Endpunkt der Verbindung existiert und Daten annehmen kann. Dazu schickt der Sender ein Segment mit der Aufforderung, die Folgenummern zu synchronisieren. Der Empfänger weiß jetzt, daß der Sender eine Verbindung öffnen möchte und an welcher Position im Datenstrom der Sender anfangen wird zu zählen. Der Empfänger bestätigt den Empfang der Nachricht und legt seinerseits eine Folgenummer für Übertragungen in Gegenrichtung fest. Der Sender bestätigt nun seinerseits den Empfang der Folgenummer von B und beginnt dann mit der Übertragung von Daten. Diese Art des Austausches von Kontrollinformation, bei der jede Seite die Aktionen der Gegenseite bestätigen muß, ehe sie wirksam werden können, heisst "Dreiweg-Handshake". Auch beim Abbau einer Verbindung wird auf diese Weise sichergestellt, daß beide Seiten alle Daten korrekt und vollständig empfangen haben.
Auf einem Rechner können mehrere Prozesse zu einem Zeitpunkt TCP-Verbindungen geöffnet haben. Die Portnummer in jedem TCP-Segment gibt an, welche virtuelle Verbindung zu welchem Prozeß gehört. So ist es möglich, Leitungen für eine Vielzahl von Prozessen zu multiplexen. Vom Standpunkt eines Modembenutzers aus kann man TCP/IP also in gewisser Weise als eine Art glorifiziertes ZMODEM- oder BIMODEM-Protokoll betrachten: Es ist nicht nur eine Übertragung von Daten in beide Richtungen gleichzeitig möglich, sondern es können pro Richtung noch mehrere Verbindungen zugleich unterhalten werden.
Damit die verschiedenen Schichten des Protokollturms miteinander Daten austauschen können, müssen jeweils zwei aneinanderstoßende Schichten sich jeweils über ein gemeinsames Interface einig sein. Normalerweise sind diese Interfaces nicht interessant, weil sie für den Anwender unsichtbar sind. Das Interface der Internet-Schicht ist zum Beispiel nur für denjenigen interessant, der TCP oder ein vergleichbares Protokoll selbst implementieren möchte. Das Interface zwischen der Transportschicht und der Anwendungsschicht ist jedoch von besonderem Interesse, denn es stellt das Interface dar, mit dem ein Programmierer umgehen muß, der eine Anwendung schreiben möchte, die von den Möglichkeiten von TCP/IP Gebrauch macht.
Leider gibt es zwei verschiedene, inkompatible APIs für TCP/IP. Die ältere der beiden ist als "Berkeley Sockets" bekannt geworden und in BSD UNIX zusammen mit der ersten Version von TCP/IP implementiert worden. Die andere API ist das "Transport Level Interface", kurz TLI, von AT&T. Es stellt den Versuch dar, eine generelle, TCP/IP unabhängige API für Netzwerkprogrammierung zu schaffen. Die Namen und Parameter der TLI-Aufrufe orientieren sich dabei an der Begriffswelt der OSI.
Die Grenze zwischen der Anwendungsschicht und der Transportschicht ist in den meisten Implementierungen zugleich die Grenze zwischen dem Betriebssystem und den Anwendungsprogrammen. Im OSI-Modell ist diese Grenze in etwa die Grenze zwischen den Schichten 4 und 5. Daher ordnet man IP meist ungefähr in die Ebene 3 und TCP ungefähr in Ebene 4 des OSI-Modells ein. Da TCP/IP jedoch älter und einfacher als das OSI-Modell sind, kann diese Einordnung nicht genau passen.
Eines dieser Protokolle ist zum Beispiel das "simple mail transport protocol", SMTP. Es dient der synchronen Auslieferung von Electronic Mail im Internet und wird von einer ganzen Palette von Mailtransportprogrammen direkt verstanden. Ist eine Mail zu versenden, so baut der sendende Mailer eine TCP/IP-Verbindung direkt zum Zielrechner auf. Der physikalische Weg zu diesem Rechner muß nicht direkt vorhanden sein, aber das braucht den Absender nicht zu kümmern. Die Internet-Schicht des Netzes wird einen Weg zum Zielrechner konstruieren, wenn es einen gibt. Für den Mailer sieht es so aus, als hätte er eine direkte, virtuelle Verbindung zum Zielrechner. Kommt eine Verbindung zustande, so meldet sich auf dem Zielrechner ein Hintergrundprozeß, der auf eingehende Nachrichten wartet. Zwischen den beiden Mailern läuft dann ein SMTP-Dialog ab. Da der Dialog aber in reinem ASCII und sogar relativ lesbar ist, kann man ihn bei Kenntnis des SMTP-Protokolls auch als Mensch simulieren. Im Kasten SMTP ist so eine Simulation eines SMTP-Dialoges zu sehen.
So wie SMTP der Zustellung persönlicher Nachrichten an einzelne Personen dienst, ermöglicht das NNTP-Protokoll die Verbreitung öffentlicher Nachrichten, der USENET News, im Internet. Das FTP-Protokoll dient zur Übertragung von Dateien durch das Netz, das TELNET- und das rlogin-Protokoll ermöglichen es, Sessions auf entfernten Rechnern zu fahren und wieder andere Protokolle ermöglichen die Einrichtung von Namensverzeichnissen oder die Fernabfrage der eigenen Mail.
TCP/IP ist durch das schichtweise Design ein modularer Protokollstandard. Die einzelnen Komponenten sind in den sogenannten "Requests for Comments" (RFCs) genormt und offengelegt. Am Zustandekommen einer einzelnen SMTP über TCP über IP über Ethernet-Verbindung sind dann auch eine ganze Reihe dieser Normen beteiligt. Das Format der übertragenen Nachricht ist in RFC 822, "Standard for the format of ARPA Internet text messages" festgelegt. Die Nachrichten werden nach dem in RFC 821 definierten SMTP-Verfahren übertragen. SMTP bedient sich wiederum des in RFC 793 spezifizierten TCP, das auf dem in RFC 791 und RFC 792 definierten Internet Protocol aufsetzt. Wie Internet-Pakete auf einem Ethernet als Träger verschickt werden, ist wiederum in RFC 894 festgelegt, während RFC 826 die Zuordnung von Ethernet-Adressen zu IP-Adressen regelt.
Die Universalität von TCP/IP verbirgt die Eigenheiten der
unterliegenden Trägernetze vollständig. Für einen
TCP/IP-Benutzer, ja sogar für den Programmierer ist es
egal, auf welche Weise der Zielrechner erreicht wird, er hat
eine einheitliche Sicht auf ein riesiges, weltweites, aus
tausenden von Teilnetzen zusammengesetztes Netzwerk.
| Top | Geändert:15-Feb-2004 15:10:50 Url: http://kris.koehntopp.de/artikel/tcpip-technik/index.html |