TCP/IP
Aus HackerWiki
Contents |
TCP/IP
2006 by bitmuncher(at)bitmuncher(dot)de
TCP/IP ist ein Set von Protokollen, die entwickelt wurden, um es zusammenarbeitenden Computern zu erlauben, ihre Ressourcen über ein Netzwerk zu teilen. Es wurde von einer Gruppe Forscher entwickelt, die hauptsächlich aus dem Umfeld des ARPAnet kamen (Advanced Research Projects Agency). Das ARPAnet ist sicherlich das meistbekannte TCP/IP-Netzwerk. Seit Juni 1987 gibt es verschiedenste Software-Firmen, die Produkte mit TCP/IP-Unterstützung anbieten und tausende von Netzwerken aller Art benutzen TCP/IP.
Das Internet ist eine Ansammlung von Netzwerken, zu denen das ARPAnet, das NSFnet, verschiedene regionale Netzwerke, lokale Netzwerke von Universitäten und Forschungslaboren, eine Anzahl militärischer Netzwerke, sowie eine wachsende Anzahl von privaten Netzwerken gehören. Der Terminus "Internet" umfasst alle diese Netzwerke zusammen. Eine Teilmenge davon wird von Department of Defense verwaltet und ist als DDN (Defense Data Network) bekannt. Es umfasst verschiedene forschungsorientierte Netzwerke, sowie einige Netzwerke vom Militär. Alle diese Netzwerke sind miteinander verbunden. Jedes Netzwerk kann mit den anderen Netzwerken kommunizieren, wobei bestimmte Einschränkungen, wie z.B. Zugriffsrechte, zum Zuge kommen.
Was auch immer aufgerufen wird, TCP/IP ist eine Familie von Protokollen. Einige stellen "Low-Level-Funktionen" zur Verfügung, die von vielen Applikationen benötigt werden. Diese umfassen IP, TCP und UDP (ich werde später noch intensiver darauf eingehen). Andere sind Protokolle um bestimmte Aufgaben auszuführen, z.B. das Übertragen von Dateien zwischen Computern oder das Versenden von Emails.
Die wichtigsten "traditionellen" TCP/IP-Dienste
Datei-Transfer
Das Datei-Übertragungsprotokoll (FTP - File Transfer Protocol) erlaubt es dem Benutzer irgendeines Computers Dateien von einem anderen Computer zu erhalten und Dateien an einen anderen Computer zu senden. Will man auf einen sogenannten FTP-Server zugreifen, muss man einen Benutzernamen und ein Passwort angeben. Einige FTP-Server stellen auch anonyme Logins zur Verfügung. Dabei werden Vorkehrungen getroffen um die Handhabung von Datei-Übertragungen zwischen Rechnern mit unterschiedlichen Zeichensätzen, Zeilenenden etc. zu ermöglichen. Das ist nicht ganz das Gleiche wie das neuere Netzwerk-Dateisystem (Network File System - NFS) oder das NetBIOS-Protokoll (auf NFS gehe ich später noch genauer ein). FTP wird nur dann ausgeführt wenn man auf eine Datei auf einem anderen Rechner zugreifen will. Es wird dabei nur benutzt, um eine Datei in das eigene System zu kopieren. Man arbeitet dann mit der lokalen Kopie. (siehe RFC 959 für die Spezifikationen von FTP)
Remote-Login
Das Netzwerk-Terminal-Protokoll (TELNET) erlaubt es einem Benutzer, sich auf einem anderen Computer im Netzwerk einzuloggen. Man startet eine Remote-Session indem man einen Computer angibt, mit dem man sich verbinden möchte. Vom Verbindungsaufbau bis zum Schliessen der Session geht jeglicher Input, den der User eingibt an den Remote-Computer. Das Telnet-Protokoll sorgt dafür, dass der eigene Rechner "unsichtbar" wird, solange man auf dem Remote-Computer arbeitet (nur der Remote-Computer kann den eigenen Rechner sehen). Das sieht zwar in der Realität für einen Hacker etwas anders aus, aber vorerst wollen wir uns mit dieser Vorstellung begnügen. Jedes Zeichen, das man eingibt, wird direkt an den anderen Rechner weitergeleitet. Das Remote-System verlangt einen Usernamen und ein Passwort bei der Anmeldung. Wenn man die Telnet-Session schliesst, arbeitet man wieder auf seinem lokalen Computer. Telnet-Server stellen normalerweise einen Terminal-Emulator für unterschiedliche Typen von Terminals zur Verfügung (für einen Linux-Rechner wäre das normalerweise VT100). (siehe dazu RFC 854 und RFC 855 für die Spezifikationen für Telnet)
Computer-Post
Die sogenannten Emails erlauben es einem User, Nachrichten an einen anderen User zu verschicken. Normalerweise besitzen die meisten Benutzer ein oder zwei Email-Accounts auf einem Email-Server. Auf diesen Servern werden für die einzelnen Accounts Mail-Dateien erstellt. Das Versenden einer Email an eine bestimmte Adresse sorgt dafür, dass man eine Nachricht an eine bestimmte Mail-Datei auf einem Server anfügt. Die meisten Betriebssysteme ermöglichen es einem Benutzer, seine Emails von einem Email-Server abzuholen und lokal zu lesen. Damit muss der Rechner während des Lesens einer Email nicht ständig mit dem Internet verbunden sein. (siehe RFC 821 und RFC 822 für Spezifikationen zu Computer-Mail)
Diese Dienste sollten in jeder Implementierung von TCP/IP vorhanden sein. Diese traditionellen Applikationen spielen noch heute eine grosse Rolle in TCP/IP-basierten Netzwerk. Heute geht der Trend dahin, dass ein Benutzer auf einem einzigen Rechner arbeitet und auf andere Rechner in einem Netzwerk zugreift um bestimmte Dienste zur Verfügung zu haben. Das hat zum Server/Client-Modell von heutigen Netzwerkdiensten geführt. Ein Server ist dabei ein Rechner, der bestimmte Dienste für andere Rechner in einem Netzwerk zur Verfügung stellt. Ein Client ist ein Rechner, der auf verschiedene Server im Netzwerk zugreift um verschiedene Dienste nutzen zu können. Besonders für Unix- und Linux-Benutzer besteht dabei die Möglichkeit, dass Server und Client auf einem Rechner laufen. Es handelt sich dann dabei nur um unterschiedliche Arten von Software.
Hier sind nun die Server, die in modernen Computer-Systemen vorhanden sind, wobei ich hier nicht verschweigen will, dass ich mit "modern" hauptsächlich Unix- und Linux-Systeme meine. Unter dem weit verbreiteten Windows von Microsoft stehen die meisten Server erst nach der Installation von zusätzlicher (meist kommerzieller) Software zur Verfügung, wobei nur die Server-Serie (Windows2000 Server, Windows-Server 2003 u.ä.) eine Ausnahme darstellt.
Netzwerk-Dateisystem (NFS)
Das NFS erlaubt es einem Computer auf Dateien eines anderen Computers zuzugreifen. Dabei kann ein NFS-Verzeichnis so benutzt werden, als sei es ein Verzeichnis auf dem lokalen Rechner. Damit kann man auch komplette Festplatten eines anderen Rechners benutzen. NFS erleichtert ein Backup in Netzwerken, da ein Backup-Server alle Partitionen oder Ordner via NFS einbinden kann und nicht jeder Rechner muss einzeln gesichert werden. Ein weiteres Anwendungsgebiet sind sogenannte Diskless Clienten. Diese binden eine Partition mit dem Betriebssystem via NFS ein und benutzen somit das Betriebssystem des Servers. Damit muss nur noch ein Server installiert werden und alle daran angeschlossenen Clienten können das darauf zur Verfügung gestellte Betriebssystem benutzen.
Remote-Drucken
Mit diesem Dienst ist es möglich, zentrale Drucker-Server oder Drucker von anderen Rechnern zu benutzen. Dabei kommt meist das Remote Lineprinter Protocol von Berkeley Unix zum Einsatz. Leider gibt es keine mir bekannte Protokoll-Dokumentation dafür. Der Quelltext ist aber von Berkeley erhältlich, so dass man sich ein Bild von der Implementierung des Protokolls machen kann. Derzeit ist eine neue Form der Druckertreiber unter Linux auf dem Vormarsch, die als CUPS (Common Unix Printing System) bekannt sind. Auch damit ist es möglich, anderen Rechnern in einem Netzwerk den Zugriff auf einen Drucker zu ermöglichen.
Remote-Ausführung von Programmen
Dieser Dienst wird meist benutzt, um auf "kleinen" Clienten eine grosse Menge an Software zur Verfügung zu haben. Er ermöglicht es einem Rechner ein Programm, das sich auf einem anderen Rechner befindet, auszuführen. Es gibt unterschiedliche Arten von Remote-Ausführung. Einerseits kann ein ganzes Programm auf einem anderen Rechner ausgeführt werden, wobei der Output des Programms auf den anfragenden Rechner "umgeleitet" wird. Andererseits ist es auch möglich nur Subroutinen eines Programms auf dem anderen Rechner auszuführen. Das nennt man dann Remote Procedure Call (RPC). Linux-Benutzer kennen mindestens 2 Programme, die solche Aufgaben übernehmen, RSH und RExec.
Name-Server
In grossen Netzwerken, gibt es eine grosse Anzahl von Namen, die verwaltet werden müssen. Diese beinhalten User und ihre Passwörter, Rechnernamen und ihre IP-Adressen, sowie Accounts. Es ist sehr anstrengend diese Namen auf allen Rechnern auf dem neuesten Stand zu halten. Daher werden diese Namen auf einer kleinen Anzahl von Computern aufbewahrt. Andere System greifen dann über das Netzwerk auf diese Daten zu. (RFC 822 und RFC 823 beschreiben das Name-Server-Protokoll, das benutzt wird, um Rechnernamen und die zugehörigen IP-Adressen zusammenzuhalten. Es wird von heutigen TCP/IP-Implementierungen unbedingt benötigt.) SUNs Yellow Pages wurden entwickelt um Usernamen, Datei-Zugriffe und andere für Unix typische Datenbanken zusammenzuhalten. Die Protokoll-Definitionen sind bei SUN erhältlich.
Terminal-Server
Viele Installationen verbinden einen Rechner nicht mehr mit Terminals, sondern mit Terminal-Servern. Ein Terminal-Server ist ein Rechner, der nur weiss, wie man Telnet (oder ein anderes Programm für den Remote-Login) ausführt. Wenn man mit einem solchen Rechner verbunden ist, muss man nur den Namen eines Computers eingeben und man wird mit diesem verbunden. Meist ist es notwendig mehrere aktive Verbindungen zu anderen Rechnern offen zu haben. Einem Terminal-Server ist es möglich, schnell zwischen Verbindungen zu wechseln und bekanntzugeben, wenn neuer Output bei einer anderen Verbindung wartet. Jeder echte Terminal-Server stellt allerdings auch Name-Server-Dienste und eine Anzahl anderer Protokolle zur Verfügung.
Netzwerkorientierte Fenster-Systeme
Neuerdings arbeiten fast alle Betriebssysteme mit grafischen Oberflächen. Netzwerkorientierte Fenster-Systeme erlauben es einem Rechner die Oberfläche eines anderen Rechners zu benutzen. Vollskalierte Netzwerk-Fenster-Systeme sorgen dafür, dass man sowohl remote als auch lokal Programme ausführen kann und dabei auf einer einzigen Oberfläche arbeitet. Das wohl meistbenutzte Fenster-System dieser Art ist X. Eine Protokoll-Beschreibung ist von MIT's Project Athena erhältlich. Beachte, dass einige der oben beschriebenen Protokolle von Berkeley, SUN oder anderen Organisationen entwickelt wurden. Daher sind sie kein offizieller Teil der Internet-Protokoll-Suite. Sie wurden aber unter Benutzung von TCP/IP implementiert. Ausserdem habe ich oben nur die wichtigsten Protokolle beschrieben und es gibt noch eine ganze Menge anderer (wie z.B. Dienste, die zum Abgleichen von Rechneruhren oder zum Ermitteln von auf anderen Rechnern eingeloggten Usern benutzt werden). Wer Informationen zu einem bestimmten Protokoll aus der Internet-Protokoll-Suite sucht, sollte sich das dazugehörige RFC besorgen.
Ein genereller Blick auf TCP/IP
TCP/IP ist ein überlagertes Set von Protokollen. Um dies zu verstehen, sollten wir einen Blick auf ein Beispiel werfen. Eine typische Situation ist das Versenden einer Email. Zuerst ist da ein Protokoll für Emails. Dieses definiert einige Befehle, die ein Rechner an einen anderen sendet, z.B. Befehle um anzugeben, wer der Absender der Email ist, wohin sie gesendet werden soll und natürlich die Nachricht selbst. Dieses Protokoll geht davon aus, dass es einen Weg gibt zuverlässig zwischen den 2 Rechnern zu kommunizieren. Mail und andere Applikationsprotokolle definieren einfach eine Anzahl an Befehlen und Nachrichten, die gesendet werden. Sie wurden entworfen, um zusammen mit TCP und IP benutzt zu werden.
TCP ist dafür verantwortlich, sicherzustellen, dass diese Befehle am anderen Ende ankommen. Es behält im Auge, was bereits gesendet wurde und sendet alles nochmal, was nicht durchgekommen ist. Wenn irgendeine Nachricht zu lang für ein Datagramm ist, teilt TCP sie auf mehrere Datagramme auf und stellt sicher, dass sie alle korrekt ankommen. Da diese Funktionalität für viele Applikationen benötigt wird, wurde sie in ein separates Protokoll gepackt, anstatt Teil der Spezifikationen für das Mail-Protokoll zu werden. Man kann sich TCP als eine Art Bibliothek vorstellen, die von Applikationen benutzt werden kann, wenn sie eine zuverlässige Verbindung zu anderen Rechnern benötigen.
Auf ähnliche Weise ruft TCP die Services von IP auf. Obwohl die Services, die TCP zur Verfügung stellt von vielen Applikationen benötigt werden, gibt es einige Arten von Applikationen, die diese nicht benötigen. Aber es gibt auch einige Services, die jede Applikation braucht. Daher wurden diese Services im IP-Protokoll zusammengefasst. Wie bei TCP auch, kann man sich IP als eine Art Bibliothek vorstellen, die aus Routinen besteht, die von TCP aufgerufen werden. Aber diese Routinen stehen auch Applikationen zur Verfügung, die keinen Gebrauch von TCP machen. Dieses Strategie, mehrere Level eines Protokolls zu bauen, nennt man "Layering" (deutsch: Überlagern/Aufschichten). TCP, IP und Mail sind solche "Schichten", die Gebrauch von Schichten machen, die unter ihnen liegen. Generell benutzen TCP/IP-Applikationen 4 Schichten: ein Applikationsprotokoll (wie z.B. Mail), TCP für Services, die von vielen Applikationen benötigt werden, IP, das die grundlegenden Dienste zum Versenden und Empfangen von Datagrammen zur Verfügung stellt und die Hardware-Ebene, wie z.B. Ethernet oder eine Point-to-Point-Line.
TCP/IP basiert auf dem "Catenet-Modell". Dieses Modell geht davon aus, dass es eine grosse Anzahl an unabhängigen Netzwerken gibt, die mit Gateways untereinander verbunden sind. Dem User sollte es möglich sein, auf andere Computer oder andere Resourcen irgendeines anderen Netzwerks zuzugreifen. Datagramme passieren oft ein Dutzend verschiedene Netzwerke, bevor sie bei ihrem Ziel ankommen.
Die Route, die benötigt wird, um dies zustande zu bringen, wird normalerweise vor dem User verborgen. Alles was der User wissen muss, um eine Verbindung zu einem anderen System aufzubauen, ist die Internet-Adresse des Systems. Das ist eine Adresse, die wie 128.6.4.123 aussieht. Es ist (bei IPv4) eine 32-bit Nummer. Sie wird normalerweise als 4 Dezimalzahlen geschrieben, wobei jede Zahl 8 Bit der Adresse repräsentiert (Der Terminus "Octet" wird oft in Internet-Dokumenten benutzt um solche 8-Bit-Blöcke (Chunks) zu beschreiben. Der Terminus "Byte" wird nicht benutzt, da TCP/IP auch Computer unterstützt, die eine Byte-Grösse ungleich von 8 Bit benutzen.) Generell gibt dir die Struktur einer solchen Adresse einige Informationen darüber, wie du zu diesem System kommst. Z.B., 128.6. ist eine Netzwerk-Adresse, die von einer zentralen Behörde der Rutgers University zugeordnet wurde. Rutgers benutzt das nächste Oktett, um festzulegen, zu welchem Campus-Ethernet der Rechner gehört. 128.6.4 tritt auf, wenn der Rechner zum Computer Science Department gehört. Die letzte Nummer erlaubt es, bis zu 254 Rechnern in einem Ethernet (es sind 254, da 0 und 255 nicht erlaubt sind, sie werden für die Kennung des Netzwerk und als Broadcast-Adresse benutzt, mehr dazu später). Beachte also, dass 128.6.4.194 und 128.6.5.194 zwei verschiedene Systeme sind. Die Struktur einer Internet-Adresse werde ich aber später noch genauer Erläutern. Natürlich referenzieren wir ein anderes System meist über einen Namen, und nicht mit der Internet-Adresse. Wenn wir einen Namen angeben, schaut die Netzwerk-Software in einer Datenbank nach, und bekommt dadurch die zugehörige Internet-Adresse heraus.
Die meiste Netzwerk-Software arbeitet strikt mit diesen Adressen (RFC882 beschreibt die Name-Server-Technologie, die benutzt wird, um dieses Auflösen von Adressen durchzuführen.). TCP/IP wurde auf einer "verbindungslosen" Technologie aufgebaut. Informationen werden als eine Sequenz von "Datagrammen" übertragen. Ein Datagramm ist eine Ansammlungen von Daten, die als einzelne Nachricht übertragen werden. Jedes dieser Datagramme wird separat durch das Netzwerk gesendet. Es gibt Bedingungen um eine Verbindung zu öffnen (z.B. für eine Datenübertragung über eine bestimmte Zeit). In einigen Ebenen, werde Informationen von diesen Verbindungen in Datagramme aufgespaltet und diese Datagramme werden vom Netzwerk vollständig separat behandelt.
Nehmen wir einmal an, du möchtest eine 15000-Oktett-Datei übertragen. Die meisten Netzwerke können keine 15000-Oktett-Datei handlen. Das Protokoll wird diese Informationen z.B. in 30 mal 500-Oktett-Datagramme aufspalten. Jedes dieser Datagramme wird nun an den Empfänger gesendet. Erst dort werden sie dann wieder zu einer 15000-Oktett-Datei zusammengesetzt. Während diese Datagramme allerdings unterwegs sind, weiss das Netzwerk nicht, dass es eine Verbindung zwischen ihnen gibt. Es ist sogar möglich, dass Datagramm 15 vor Datagramm 14 ankommt. Es ist auch möglich, dass es irgendwo bei der Übertragung im Netzwerk zu einem Fehler kommt und daher nicht alle Datagramme übertragen werden. In diesem Fall muss dann das Datagramm nochmal gesendet werden.
Manchmal scheint es, dass die Begriffe "Datagramm" und "Paket" beliebig ausgetauscht werden können. Technisch gesehen ist aber "Datagramm" das richtige Wort, wenn man TCP/IP beschreibt. Ein Datagramm ist eine Einheit von Daten, mit denen das Protokoll umgeht. Ein Paket ist ein physischen Ding, das in einem Ethernet oder einer Leitung auftaucht. Normalerweise enthält ein Paket ein Datagramm, was sie gleich aussehen lässt. Es kann aber auch noch grössere Unterschiede geben, wenn man TCP/IP auf X.25 benutzt. Das X.25-Interface teilt ein Datagramm auf 128-Byte-Pakete auf. Das ist für IP unsichtbar. Die Pakete werden am anderen Ende wieder in ein einziges Datagramm zusammengesetzt, bevor sie ans TCP weitergereicht werden. In einem solchen Fall kann ein IP-Datagramm auf mehrere Pakete aufgeteilt sein. In den meisten Fällen gibt es aber Erweiterungen, die es ermöglichen, ein Datagramm mit einem Paket zu übertragen.
Das TCP-Level
Zwei separate Protokolle sind beim Handling von TCP/IP-Datagrammen beteiligt. TCP (Transfer Control Protocol) ist dafür verantwortlich, Nachrichten in Datagramme aufzuteilen, sie auf der anderen Seite wieder zusammenzusetzen, alle verloren gegangenen Daten nochmal zu senden und sie wieder in die richtige Reihenfolge zu setzen. IP (Internet Protocol) ist dafür verantwortlich, dass die einzelnen Datagramme an das richtige Ziel übertragen werden. Es könnte so scheinen, dass TCP die ganze Arbeit macht und in kleinen Netzwerken ist das sogar wahr.Im Internet ist es aber eine komplexe Aufgabe, ein Datagramm von der Quelle zum Ziel zu befördern. Eine Verbindung kann es notwendig machen, dass ein Datagramm durch verschiedene Netzwerke geleitet werden muss, bevor es am Ziel ankommt. Das Aufzeichnen dieser Route und das Handling zwischen Inkompatibilitäten kann dabei sehr komplex werden. Das Interface zwischen TCP und IP ist ziemlich einfach. TCP reicht einfach ein Datagramm an IP weiter. IP weiss nicht, in welcher Beziehung dieses Datagramm zu einem anderen Datagramm steht, es leitet sie einfach nur ans Ziel weiter.
Sicherlich wird dir aufgefallen sein, dass bisher etwas fehlte. Wir haben immer nur über einzelne Verbindungen gesprochen und nie über multiple Verbindungen zu einem Rechner. Natürlich reicht es nicht einfach aus, ein Datagramm an das richtige Ziel zu senden. TCP muss wissen, zu welcher Verbindung dieses Datagramm gehört. Diese Aufgabe nennt man "Demultiplexing". Dabei geschehen im TCP/IP mehrere Stufen von Demutliplexing. Die Informationen die fürs Demultiplexing benötigt werden, sind in einer Reihe von Headern enthalten. Ein Header ist einfach nur ein weiteres Oktett, das am Anfang des Datagramms von einem Protokoll befestigt wird. Es ist, als würde man einen Brief in einen Umschlag packen und eine Adresse draufschreiben. In einem Netzwerk passiert dies aber mehrmals. Stelle dir vor, du packst einen Brief in einen kleinen Umschlag, deine Sekretärin packt ihn in einen etwas grösseren Umschlag, die Korrespondenzabteilung packt ihn wieder in einen noch grösseren Umschlag usw. Jeder, der mit diesem Brief zu tun hat, packt ihn in einen zusätzlichen Umschlag.
Hier ist eine Übersicht der Header, die an eine Nachricht angehängt werden, wenn sie durch eine typische TCP/IP-Verbindung gehen. Wir beginnen mit einem typischen einfachen Datenstream, sagen wir eine Datei, die du versucht an einen anderen Computer zu senden:
TCP teilt sie in handlebare Blöcke auf. (Dazu muss TCP wissen, wie gross Datagramme sein können, die dein Netzwerk handlen kann. Aktuell wird dies so gelösst, dass beide an der Verbindung beteiligten Netzwerk mitteilen, wie gross Datagramme sein dürfen und die kleinste Grösse wird dann benutzt.)
TCP fügt an den Anfang eines jeden Datagramms einen Header an. Dieser Header enthält mindestens 20 Oktetts, aber die wichtigsten sind eine Quell- und Ziel-Portnummer sowie eine Sequenz-Nummer. Die Port-Nummern werden benutzt, um unterschiedliche Verbindungen auseinanderzuhalten. Nehmen wir an, dass 3 verschiedene Leute Dateien übertragen. Dein TCP kann 1000, 1001 und 1002 für diese Übertragungen allozieren. Wenn du ein Datagramm absendest, bekommt es die Quellport-Nummer, da du die Quelle bist. Natürlich hat das TCP auf der anderen Seite eine eigene Port-Nummer für diese Verbindung festgelegt. Dein TCP muss also auch wissen, welche Portnummer auf der anderen Seite benutzt wird. (Diese findet es beim Aufbauen der Verbindung heraus. Wie das funktioniert wird später erlätert.) Diese wird in das Ziel-Port-Feld eingetragen. Wenn das andere Ende ein Datagramm an dich zurücksendet, werden die Portnummern natürlich umgekehrt, da du dann das Ziel bist und nicht mehr die Quelle.
Jedes Datagramm hat eine Sequenznummer. Diese wird benutzt, damit der Empfänger feststellen kann, ob die Datagramme in der richtigen Reihenfolge angekommen sind und ob auch keine Datagramme fehlen. (Siehe auch die TCP-Spezifikationen für weitere Details.) TCP nummeriert nicht die Datagramme selbst, sondern die Oktetts. Wenn es also 500 Oktetts in jedem Datagramm gibt, bekommt das erste Datagramm die Nummer 0, das zweite die 500, das dritte die 1000 u.s.w.
Zum Schluss möchte ich noch die Checksumme erwähnen. Dies ist eine Nummer, die berechnet wird, indem alle Oktetts in einem Datagramm zusammenaddiert werden. Das Ergebnis wird in den Header geschrieben. Das TCP auf der anderen Seite berechnet diese Checksumme erneut. Wenn die beiden Checksummen nicht identisch sind, ist irgendetwas bei der Übertragung schief gelaufen und das Datagramm wird verworfen.
Das Fenster (Window) wird benutzt um zu kontrollieren, wie viele Daten mit einem Mal übertragen werden können. Es ist nämlich nicht besonders praktisch, zu warten, bis ein Datagramm bestätigt wird, bevor man das nächste sendet. Das würde viel zu lange dauern. Andererseit kann man kann man auch nicht einfach fortlaufend senden, da ein schneller Computer sonst bei einem langsameren Computer zu einem Overrun führen kann. Daher legt jedes Ende fest, wieviele Dates es als nächstes verarbeiten kann, indem es die Anzahl der Oktetts in sein Fenster-Feld schreibt. Wenn ein Computer Daten empfängt, wird die Fenster-Grösse entsprechend verkleinert. Werden die Daten verarbeitet, wird die Fenstergrösse wieder erhöht um anzuzeigen, dass nun mehr Daten verarbeitet werden können.
Das "Dringend"-Feld kann benutzt werden, um der anderen Seite mitzuteilen, dass es mit der Abwicklung eines bestimmten Oktetts fortfahren soll. Das ist meist für asynchrone Events notwendig, z.B. wenn mein ein Kontrollzeichen eingibt, das den Output unterbricht. Die anderen Felder würden hier zu weit führen. Mehr dazu kann man den TCP-Spezifikationen entnehmen.
Das IP-Level
TCP sendet jedes Datagramm an IP. Natürlich muss es IP mitteilen, wohin das Datagramm gehen soll. Das ist alles, wozu IP gemacht wurde. Es nimmt nicht wahr, was sich in dem Datagramm oder gar im TCP-Header befindet. Der Job von IP ist lediglich das Finden einer Route für das Datagramm um es an sein Ziel zu befördern. Um es Gateways oder anderen erweiterten Systemen zu erlauben, das Datagramm zu forwarden, setzt es seinen eigenen Header.
Die grundlegenden Daten in diesem Header sind die Internet-Adressen der Quelle und des Ziels (32-bit Adressen), die Protokollnummer und eine zusätzliche Checksumme. Die Quell-Internet-Adresse ist die des sendenden Rechners. (Das ist notwendig, damit das Ziel weiss, woher ein Datagramm kommt.) Die Ziel-Internet-Adresse ist die des empfangenden Hosts. (Das wiederum ist notwendig, damit jeder Gateway, der mit dem Datagramm zu tun bekommt, weiss, wohin es gesendet werden soll. Die Protokollnummer teilt dem empfangenden IP mit, dass das Datagramm an TCP weitergereicht werden soll. Der Grossteil des IP-Traffic wird durch TCP benutzt, aber es gibt andere Protokolle, die IP nutzen können. Daher muss man IP mitteilen, an welches Protokoll ein Datagramm weitergereicht werden soll. Die Checksumme ermöglicht es IP am anderen Ende, sicherzustellen, dass der Header während des Transports nicht beschädigt wurde. Beachte, dass TCP und IP separate Checksummen benutzen. IP muss die Konsistenz des Headers überprüfen, um sicherzustellen, dass eine Nachricht nicht an das falsche Ziel gesendet wird. Die Gründe dafür sollen hier nicht weiter ausgeführt werden. Allgemein sollte man aber wissen, dass es sicherer und effizienter ist, wenn TCP für die Daten und den Header separate Checksummen benutzt.
Auch hier gibt es im Header verschiedene Felder, die wir hier nicht weiter diskutieren wollen. Die meisten von ihnen gehen über das hier zu vermittelnde Wissen weit hinaus. Die Flags und der Fragment-Offset werden benutzt, um die Übersicht über die Einzelteile zu behalten, wenn ein Datagramm zerteilt werden muss. Das kann passieren, wenn ein Datagramm an ein Netzwerk weitergeleitet wird, für das es zu gross ist. (Das werden wir weiter unten noch weiter behandeln.) Die Lebenszeit ist eine Nummer, die jedesmal verringert wird, wenn das Datagramm durch ein System geleitet wird. Wenn sie auf Null fällt, wird das Datagramm verworfen. Das passiert z.B., wenn irgendwo ein Loop in einem System auftritt. Natürlich sollte das unmöglich sein, aber ein gute durchdachtes Netzwerk ist so aufgebaut, dass selbst unmögliche Situationen bedacht werden.
An dieser Stelle ist es möglich, dass keine weiteren Header benötigt werden. Wenn dein Computer eine direkte Telefon-Verbindung zum empfangenden Computer oder zum Gateway hat, kann er Daten natürlich auch direkt an die Leitung senden.
Das Ethernet-Level
Die meisten der heutigen Netzwerke benutzen Ethernet. Daher wollen wir uns jetzt den Ethernet-Headers zuwenden. Unglücklicherweise benutzt Ethernet seine eigenen Adressen. Die Leute, die Ethernet entwickelt haben, wollten sicherstellen, dass niemals 2 Rechner die gleiche Ethernet-Adresse benutzen. Weiterhin sollte sich der User nicht über die Vergabe der Adressen den Kopf zerbrechen müssen. Daher kommt jede Netzwerkkarte (Ethernet-Controller) mit einer eigenen Adresse, die vom Hersteller festgelegt wird. Um sicherzustellen, dass eine Adresse niemals zweimal vergeben wird, allozierten die Ethernet-Designer 48-bit für die Ethernet-Adressen. Firmen, die Ethernet-Controller herstellen, müssen die vergebenen Nummer bei einer zentralen Behörde registrieren, um sicherzustellen, dass sie nicht von einem anderen Hersteller benutzt werden. Diese Adressen nennt man auch Mac-Adressen.
Ethernet ist ein "Broadcast-Medium". Das ist wie bei früheren Konferenz-Telefonen. Wenn man ein Paket an das Ethernet sendet, sieht es jeder Rechner in diesem Netzwerk. Daher muss es etwas geben, das sicherstellt, dass der richtige Rechner das Paket erhält. Wie du dir sicherlich vorstellen kannst, wird dies über den Ethernet-Header geregelt. Jedes Ethernet-Paket hat einen 14-Oktett-Header, der die Quelladresse, die Zieladresse und einen Type-Code enthält. Jeder Controller beachtet nur die Pakete, die ihre eigene Adresse im Zieladress-Feld aufweisen. (Man kann dieses Feld allerdings auch faken. Das ist der Grund, warum Ethernet nicht sonderlich sicher ist.) Beachte, dass es keine Verbindung zwischen Ethernet-Adressen und Internet-Adressen gibt. Jeder Rechner muss über eine Tabelle verfügen, mit der er feststellen kann, welche Ethernet-Adresse zu welcher Internet-Adresse gehört. (Wie eine solche Tabelle aufgebaut ist, wird später erlätert.) Zusätzlich zu diesen Adressen gibt es im Header einen Typen-Code. Durch diesen Typen-Code ist es möglich, mehrere verschiedene Protokoll-Familien im gleichen Netzwerk zu benutzen. Daher kannst du TCP/IP, DECnet, Xerox, NS usw. zur gleichen Zeit benutzen. Jedes von ihnen packt einen anderen Wert in das Typen-Code-Feld. Schlussendlich gibt es eine Checksumme. Der Ethernet-Controller berechnet eine Checksumme für das ganze Paket. Wenn der Empfänger das Paket erhält, berechnet diese Checksumme erneut und verwirft das Paket, wenn die beiden Checksummen nicht übereinstimmen. Die Checksumme wird an das Ende des Pakets angehängt und nicht in den Header geschrieben.
Wenn das Paket beim Empfänger ankommt, werden natürlich alle Header entfernt. Das Ethernet-Interface entfernt den Ethernet-Header und die Checksumme. Es schaut dann auf den Typen-Code. Gehört dieser Code zu IP, wird das Datagramm an IP weitergereicht. IP entfernt den IP-Header und schaut dann in das IP-Protokoll-Feld. Wenn der Protokoll-Typ TCP ist, wird das Datagramm an TCP weitergereicht. TCP untersucht nun die Sequenz-Nummer. Es benutzt die Sequenz-Nummer und andere Informationen, um aus den Datagrammen die original Datei wieder herzustellen. Damit sind wir am Ende unserer Einführung in TCP/IP angekommen. Natürlich konnte ich nicht auf alle Details eingehen. Wer weitere Informationen haben will, sollte zu den entsprechenden RFCs greifen (RFC 793 für TCP, RFC 791 für IP sowie RFC 894 und RFC 826 zum Senden von IP über das Ethernet.
