Tcp/ip
Grundlagen
Was ist ein Rechnernetz?
Diese Frage habe ich mir auch längere Zeit gestellt. Die Literatur äußert sich hierzu leider auch nicht so ganz klar. Tanenbaum "definiert" ein Rechnernetz in [Ta96] wie folgt:
"Das ganze Buch hindurch wird der Begriff Rechnernetze für mehrere
miteinander verbundene autonome Computer verwendet. Zwei Computer gelten als miteinander verbunden, wenn sie Informationen austauschen können. Die Verbindung muß nicht aus einem Kupferkabel bestehen - es können auch Lichtwellenleiter, Mikrowellen oder Kommunikationssatelliten benutzt werden. Die Vorgabe, daß die Computer autonom sein müssen schließt Systeme, bei denen ein eindeutiges Master/Slave-Verhältnis herrscht, von vornherein aus unserer Definition aus. Kann ein Computer einen anderen beliebig ein- oder ausschalten oder steuern, besteht keine Unabhängigkeit. Ein System mit einer Steuereinheit als Master und vielen Slaves ist kein Netz, ebensowenig wie ein Großrechner mit entfernten Druckern und Terminals."
Nach dieser Definition ist ein Netz, das aus einer Anzahl von Java-Rechnern (oder sind es doch nur Terminals) besteht kein Rechnernetz. Die Java- Rechner müssen ihr System erst aus dem Netz laden, bevor mit ihnen "autonom" gearbeitet werden kann. Die Frage ist hier zusätzlich: arbeiten Java-Rechner wirklich autonom? Deshalb möchte ich noch eine allgemeinere "Definition" eines Rechnernetzes aus [Co98] geben:
"Das alte Modell, bei dem ein Großrechner den gesamten Rechenaufwand
eines Unternehmens bewältigte, wurde durch eines ersetzt, bei dem eine große Anzahl einzelner miteinander verbundener Rechner die Arbeit übernimmt. Ein solches System nennt man Rechnernetz."
Protokolle, Protokollhierarchien
Protokolle sind Regeln, die den Nachrichtenaustausch - oder allgemeiner das Verhalten - zwischen (Kommunikations)Partnern regeln ("Protocols are formal rules of behaviour"). Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar gänzlich unmöglich. Ein Beispiel für ein Protokoll "aus dem täglichen Leben" ist z.B. der Funkverkehr: Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit Roger und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung schließlich mit Over and out. Ähnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern benötigt - auch wenn hier die Komplexität der Anforderungen etwas höher ist. Aufgrund dieser höheren Komplexität werden viele Aufgabe nicht von einem einzigen Protokoll abgewickelt. In der Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen Teilaufgaben, zum Einsatz. Diese Protokolle sind dann in Form von Protokollschichten mit jeweils unterschiedlichen Funktionen angeordnet.
Anordnung von Protokollen zu einem Protokollstapel.
Eine kurze Geschichte des Internet
From small things, big things sometimes come (Tittel E., Robbins M.) Gegen Ende der sechziger Jahre, als der "kalte Krieg" seinen Höhepunkt erlangte, wurde vom US-Verteidigungsministerium (Department of Defence - DoD) eine Netzwerktechnologie gefordert, die in einem hohen Maß gegenüber Ausfällen sicher ist. Das Netz sollte dazu in der Lage sein, auch im Falle eines Atomkrieges weiter zu operieren. Eine Datenübermittlung über Telefonleitungen war zu diesem Zweck nicht geeignet, da diese gegenüber Ausfällen zu verletzlich waren (sind). Aus diesem Grund beauftragte das US-Verteidigungsministerium die Advanced Research Projects Agency (ARPA) mit der Entwicklung einer zuverlässigen Netztechnologie. Die ARPA wurde 1957 als Reaktion auf den Start des Sputniks durch die UdSSR gegründet. Die ARPA hatte die Aufgabe Technologien zu entwickeln, die für das Militär von Nutzen sind. Zwischenzeitlich wurde die ARPA in Defense Advanced Research Projects Agency (DARPA) umbenannt, da ihre Interessen primär militärischen Zwecken dienten. Die ARPA war keine Organisation, die Wissenschaftler und Forscher beschäftigte, sondern verteilte Aufträge an Universitäten und Forschungsinstitute.
Um die geforderte Zuverlässigkeit des Netzes zu erreichen, fiel die Wahl darauf, das Netz als ein paketvermitteltes Netz (packet-switched network) zu gestalten. Bei der Paketvermittlung werden zwei Partner während der Kommunikation nur virtuell miteinander verbunden. Die zu übertragenden Daten werden vom Absender in Stücke variabler oder fester Länge zerlegt und über die virtuelle Verbindung übertragen; vom Empfänger werden diese Stücke nach dem Eintreffen wieder zusammengesetzt. Im Gegensatz dazu werden bei der Leitungsvermittlung (circuit switching) für die Dauer der Datenübertragung die Kommunikationspartner fest miteinander verbunden. Ende 1969 wurde von der University of California Los Angeles (UCLA), der University of California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der University of Utah ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen. Diese vier Universitäten wurden von der (D)ARPA gewählt, da sie bereits eine große Anzahl von ARPA-Verträgen hatten. Das ARPA-Netz wuchs rasant (siehe Abbildung) und überspannte bald ein großes Gebiet der Vereinigten Staaten
Wachstum des ARPANET a)Dezember 1969 b)July 1970 c)März 1971 d)April 1971 e)September 1972.(Quelle: A.S. Tanenbaum: Computernetworks ) Mit der Zeit und dem Wachstum des ARPANET wurde klar, daß die bis dahin gewählten Protokolle nicht mehr für den Betrieb eines größeren Netzes, das auch mehrere (Teil)Netze miteinander verband, geeignet war. Aus diesem Grund wurden schließlich weitere Forschungsarbeiten initiiert, die 1974 zur Entwicklung der TCP/IP-Protokolle bzw. des TCP/IP-Modells führten. TCP/IP wurde mit mit der Zielsetzung entwickelt, mehrere verschiedenartige Netze zur Datenübertragung miteinander zu verbinden. Um die Einbindung der TCP/IP-Protokolle in das ARPANET zu forcieren beauftragte die (D)ARPA die Firma Bolt, Beranek & Newman (BBN) und die University of California at Berkeley zur Integration von TCP/IP in Berkeley UNIX. Dies bildete auch den Grundstein des Erfolges von TCP/IP in der UNIX-Welt. Im Jahr 1983 wurde das ARPANET schließlich von der Defence Communications Agency (DCA), welche die Verwaltung des ARPANET von der (D)ARPA übernahm, aufgeteilt. Der militärische Teil des ARPANET, wurde in ein separates Teilnetz, das MILNET, abgetrennt, das durch streng kontrollierte Gateways vom Rest des ARPANET - dem Forschungsteil - separiert wurde. Nachdem TCP/IP das einzige offizielle Protokoll des ARPANET wurde, nahm die Zahl der angeschlossenen Netze und Hosts rapide zu. Das ARPANET wurde von Entwicklungen, die es selber hervorgebracht hatte, überrannt. Das ARPANET in seiner ursprünglichen Form existiert heute nicht mehr, das MILNET ist aber noch in Betrieb. (Zum Wachstum des Internet in Deutschland siehe: http://www.nic.de/Netcount/netStatHosts.html) Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Netzverbund betrachtet. Dieser Netzverbund wird heute allgemein als das Internet bezeichnet. Der Leim, der das Internet zusammenhält, sind die TCP/IP-Protokolle.
RFCs
Eine wichtige Rolle bei der Entstehung und Entwicklung des Internet spielen die sogenannten RFCs - Request for Comments. RFCs sind Dokumente, in denen die Standards für TCP/IP bzw. das Internet veröffentlicht werden. Einige RFCs beschreiben Dienste und Protokolle sowie deren Implementierung, andere fassen Regeln und Grundsätze (policies) zusammen. Standards für TCP/IP werden immer als RFCs veröffentlicht, aber nicht alle RFCs beschreiben Standards (siehe z.B. RFC1180 - A TCP/IP Tutorial, RFC527 - ARPAWOCKY, RFC968 - 'Twas the Night Before Start-up etc.) Die Standards für TCP/IP werden im wesentlichen nicht durch ein Komitee entwickelt, sondern durch Diskussion und Konsens beschlossen. Jeder hat die Möglichkeit ein Dokument als RFC zu veröffentlichen und so zur Diskussion zu stellen. Ist ein Dokument veröffentlicht, wird ihm eine RFC- Nummer zugewiesen. Die Dokumente werden von einer Arbeitsgruppe und/oder dem RFC-Editor geprüft. Dabei durchläuft das Dokument verschiedene Stufen, die Stufen der Entwicklung, Testung und Akzeptanz. Die Stufen bilden den sogenannten Standards Process. Die Stufen werden formal als maturity levels (Reifestufen) bezeichnet.
| Maturity Level | |
|---|---|
| Proposed Standard (PS) | Diese Stufe dauert mindestens 6 Monate und
erfordert zwei unabhängige Implementierungen. |
| Draft Standard (DS) | Diese Stufe dauert mindestens 4 Monate mit
Demonstrationen und einem Erfahrungsbericht mit midestens zwei unabhängigen Implementierungen. |
| Standard (S oder STD) | Das RFC ist zum offiziellen Standard erhoben.
Internet-Standards erhalten neben der RFC- Nummer eine sogenannte STD-Nummer (z.B. Internet Protocol, RFC791, STD-5). |
Zusätzlich zu seiner Stufe bekommt ein RFC einen Status
| Status | |
|---|---|
| Required | Muß bei allen TCP/IP-basierten Hosts und Gateways
implementiert werden. |
| Recommended | Es wird empfohlen, daß alle TCP/IP-basierten Hosts
und Gateways die Spezifikationen des RFCs implementieren. Diese RFCs werden üblicherweise auch immer implementiert. |
| Elective | Die Implementierung ist optional. Der Anwendung
wurde zugestimmt, ist aber nicht erforderlich. |
| Limited Use | Nicht für die generelle Nutzung gedacht. |
| Not recommended | Nicht zur Implementierung empfohlen. |
Ein RFC, das einmal veröffentlicht ist,wird nie verändert oder aktualisiert. Es kann nur durch ein neues RFC ersetzt werden. Bei einer Ersetzung wird das alte RFC mit der Bezeichnung "Obsoleted by RFC xxx" gekennzeichnet, das neue RFC beinhaltet einen Hinweis "Obsolets RFC xxx" auf das alte RFC. Korrekturen an einem RFC werden durch "Updates RFC xxx" und "Updated by RFC xxx" gekennzeichnet. Einige RFCs beschreiben Protokolle, die durch bessere ersetzt wurden, diese RFCs werden durch die Bezeichnung "historic" gekennzeichnet. Ein entsprechender Standard erhält den Status "not recommended". RFCs, die sich in einer experimentellen Phase der Entwicklung befinden werden mit der Bezeichnung "experimental" versehen. Protokolle, die von anderen Organisationen oder von Firmen entwickelt wurden und von Interesse für das Internet sind werden zum Teil auch in RFCs veröffentlicht mit den Bezeichnungen "informational" oder "best current practice". Das 'System' der RFCs leistet einen wesentlichen Beitrag zum Erfolg von TCP/IP und dem Internet. In der Referenzliste findet sich eine Angaben zu Quellen, bei denen die RFCs bezogen werden können. Anm.: Wer weitere Quellen zur Geschichte des Internet sucht, wird hier fündig:
Internet Society - ISOC: History of the Internet
Musch J.: Die Geschichte des Netzes: ein historischer Abriß
Hauben M.: Behind the Net: The Untold History of the ARPANET and Computer Science
Hauben R.: The Birth and Development of the ARPANET
w3history: Die Geschichte des World Wide Web
Referenzmodelle
Das OSI-Referenzmodell
Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, daß auf einem Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI-Modells ist in der folgenden Abbildung dargestellt.
OSI-Referenzmodell
Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von
Protokollcharakteristika und -funktionen (Ta96). Das OSI-Modell (die
offizielle Bezeichnung lautet ISO-OSI-Referenzmodell) besteht aus
sieben Schichten. Die Schichtung beruht auf dem Prinzip, daß eine
Schicht der jeweils über ihr angeordneten Schicht bestimmte
Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da
die Protokolle und Dienste der einzelnen Schichten vom Modell nicht
definiert werden. Das Modell beschreibt lediglich, welche Aufgaben die
Schichten erledigen sollen. Die folgenden Prinzipien haben zur
Siebenschichtigkeit des OSI-Modells geführt (Ta96):
Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad
benötigt wird.
Jede Schicht sollte eine genau definiert Funktion erfüllen.
Bei der Funktionswahl sollte die Definition international genormter
Protokolle berücksichtigt werden.
Die Grenzen zwischen den einzelnen Schichten sollten so gewählt
werden, daß der Informationsfluß über die Schnittstellen möglichst
gering ist.
Die Anzahl der Schichten sollte so groß sein, daß keine Notwendigkeit
besteht, verschiedene Funktionen auf eine Schicht zu packen, aber so
klein, daß die gesamte Architektur nicht unhandlich wird.



