Dieser Text befasst sich mit dem Thema, wie eine Verbindung zwischen zwei Rechnern überhaupt erst entsteht, wie diese funktioniert, und welche Protokolle und Dienste dazu von Nöten sind. Erstmal sei gesagt, dass bei einer Verbindung über das Internet mit einem Protokollstapel gearbeitet wird. Der genaue Aufbau und die Unterteilung dieses Stapels in die verschiedenen Schichten wird weiter unten aufgezeigt. Wird eine Verbindung aufgebaut, so wird der Stapel Schicht um Schicht erstellt. Kommen die Daten beim Empfänger an, so werden die Schichten in umgekehrter Richtung wieder abgebaut, um die entsprechenden Prozesse in Gang zu leiten
 
 

Nachdem wir nun die Aufgaben der einzelnen Schichten kennengelernt haben, werden wir auf die einzelnen Schichten genauer eingehen, um auch die verschiedenen Protokolle der jeweiligen Schichten kennen zu lernen. Hier auf alle Schichten Protokolle wirklich detailiert einzugehen würde den Rahmen aber deutlich sprengen. Trotzdem werden die Beschreibungen ausreichen, um ein recht gutes Wissen über diesen Protokollstapel zu erhalten
 
 

Diese Bitübertragungsschicht ist für die Herstellung einer physikalischen Verbindung zwischen zwei Kommunikationsendpunkten, wie etwa Programmen auf Rechner A und B verantwortlich. Dazu benötigt sie Kabel, Controller oder Modulierungsverfahren. Die physikalische Schicht wird in der Regel auch von der Treibersoftware für die netzwerkbezogene Hardware repräsentiert
 
 

MAC (Media Access Control) übernimmt in Ethernet wie auch Token Ring die Zugriffssteuerung für das jeweils verwendete Medium. Es ist für die Adressierung der Netzwerkstationen zuständig und überwacht deren Zustand. Es gibt daruner drei verschiedene Typen von MAC-Adressen, auf welche wir aber nicht genauer eingehen werden
 

LLC (Logical Link Control) ist gegenüber MAC unabhängig vom jeweiligen Medium. Es ist also nicht ausschlaggebend, auf welchem Netzwerk es verwendet wird und bildet einen eigenen Standart. Gerade die Tatsache dieser Flexibilität macht es für TCP/IP interessant. Auch von LLC gibt es gesammthaft drei verschiedene Typen
 

SNAP (Sub Network Access Protocol) schafft als Erweiterung von LLC die Möglichkeit auch Protokolle, welche nicht den ISO-Standarts entsprechen in Netzwerken zu benutzen. Durch das von LLC verwendete SAP(Service Access Point) wird die Multiprotokollfähigkeit noch stärker erweitert
 
 

Hier kommen wir nun also zu einem der Kernpunkte des Themas. Ich werde hier nur auf IP genauer eingehen und ICMP, ARP sowie RARP nur eher am Rande beschreiben.
 

IP (Internet Protocol) bildet zusammen mit dem später erklärten TCP das zentrale Protokollpaar der TCP/IP Architektur. Die Transporteinheit im IP ist das Datagramm. Sein Aufbau wird in 32 Bit-Blöcken dargestellt, wobei der Header mindestens 20Bytes umfasst. Folgendes wird im Header angegeben:

- "Version": IP-Version (momentan version 4)
- "Packet Length; IHL": Angabe über die Länge des Headers inkl. Länge der (später noch erwähnten) "Options"
- "Packet Length; Total Length": Gesammtlänge des Datagramms, welches maximal 65535 Bytes gross sein darf
- "Identification": Ein Wert, welcher zur Nummerierung fragmentierter Datagramme verwendet wird
- "Flags": Hier wird die Fragmentierung an sich gesteuert, falls sie überhaupt zum Zuge kommt
- "Fragment Offset": Gibt die Position des fragmentierten Datagramms im originalen Datagramm an
- "TTL(Time to Live)": Gibt an, nach wieviel Zeit ein Datagramm verfallen soll (um im Netz kreisenden Datenmüll zu verhinden)
- "Protocol": Bestimmt das Protokoll (z.B. UDP) der Transportschicht, an welches das Datagramm übergeben wird
- "Header Checksum": Hier werden bei jedem passieren eines Routers die Werte von TTL, Flags und Flag Offset geändert
- "Source IP-Adress": Die Adresse des sendenden Rechners
- "Destination IP-Adress": Die Adresse des Zielrechners
- "Options": Ist nicht unbedingt von Nöten, kann aber Informationen zu Raouting, Diagnose und Statistik enthalten
 

ICMP(Internet Control Message Protocol) ist dafür verantwortlich, Meldungen (z.B. Fehlermeldungen) zu übermitteln. Es benutzt zwar IP als wäre es selbst ein übergeordnetes Protokoll, ist jedoch ein fester Bestandteil vom IP. Hier noch eine kleine Liste der Meldungen, welche von ICMP gesendet werden:

Fehlermeldungen:

3   Destination unreachable (Zielstation nicht erreichbar)
4   Source quench (Buffer-Ressourcen verbraucht)
5   Redirect (Pfadumleitung)
11 Time exceeded (Timer abgelaufen)
12 Parameter Problem (Parameter Problem)

Informationsmeldungen:

0   Echo reply
8   Echo request
13 Time stamp
14 Time stamp reply
15 Information request
16 Information reply
17 Adress mask request
18 Adress mask reply

IP wird dann entsprechend modifiziert, und an den Rechner zurückgesendet. Auf die einzelnen Header-Modifikationen einzugehen, wäre nun etwas übertrieben
 

ARP (Adress Resolutin Protocol)
In einem Netzwerk hat jeder Rechner eine durch die firmware bereits vordefinierte physikalische Adresse. Für die Kommunikation mit einem Partner-Rechner wird jedoch nicht die physikalische, sondern eine logische Adresse verwendet, welche man beispielsweise im Internet findet. Der Netzwerktreiber alleine ist nun nicht fähig, diesen Rechner über diese logische Adresse anzusprechen, da sie in keinster Weise in Verbindung mit der hardware-Adresse des Controllers steht. Es muss nun also die logische Adresse in die physikalische Adresse umgesetzt werden. Dazu dient ARP. Es setzt sich aus einem MAC-Header und dem ARP-Packet zusammen, und enhält die nötigen Daten zu logischer Quell-Protokolladresse, als auch der physikalischen Adresse
 

RARP (Reverse Adress Resolution Protocol) funktioniert genau in die entgegen gesetzte Richtung. Anstatt anhand der logischen Adresse die physikalische zu ermitteln, sendet hier der Host einen RARP request mit der physikalischen Adresse aus, worauf dann RARP-Server im Netz ihre eigenen Referenz-Tabellen durchsehen, und einen RARP request zurücksendet, welcher die logische Adresse an den anfragenden Host zurücksendet. Diese Methode wird eigentlich nur von Rechnern verwendet, welche kein Medium besitzen, wo sie ihre dauerhafte, logische Adresse speichern können, und somit immer nur mit der Kenntnis ihrer physikalischen Adresse ins Netz booten.
 
 

Wir haben bislang wohl am ausführlichsten IP besprochen. Wer genau gelesen hat, dem viel auf, dass es keine Sicherung der Verbindung bei IP gibt. In diesem Layer kommen wir zu jenen Protokollen, welche zum Teil auch für die Sicherung verantwortlich sind. Hier eine kleine Liste, was ein Protokoll der Transportschicht gewährleisten sollte:

- Ermöglichung von Datentransfer über dedizierte Transportverbindungen
- Kontrollierter Auf- und Abbau von Verbindungen
- Verwaltung mehrer zu einem Rechner zur gleichen Zeit (Multiplexing)
- Kontrolle, Fehlererkennung und Flusssteuerung über die gesammte Verbindung
- Optimierter Datenfluss (Windowing)
- Priorisierung im Datenfluss

Wärend das ach so bekannte Protokoll namens TCP all diese Bedingungen erfüllt, treffen eben diese bei dem zweiten, recht markanten Protokoll namens UDP so gut wie gar nicht zu. Weshalb UDP trotzdem zur Transportschicht gehört, wird weiter unten erklärt

Nun kommen wir aber zu den zwei Protokollen an sich. Als erstes werden wir TCP ziemlich ausführlich beschreiben, danach noch eher kurz gehalten das UDP, welches auch nicht so viele Optionen enthält
 

TCP (Transmission Control Protocol) besitzt folgende Hauptmerkmal, welche es Charakterisieren:

- Datenstrom Transfer
- Virtuelle Full-Duplex Verbindungen
- Datenflusssteuerung
- Fehlererkennungen
- Prioritätensteuerung

Eine Anwendung kann TCP zum Aufbau einer Verbindung veranlassen und übergibt die Daten. TCP teilt dann die Daten auf bzw. segmentiert sie, und versieht jedes Segment mit einem eigenen Header. Nun erfolgt die Übergabe an das Internet Protocol. Sobald IP seinen Header nach dem transport durchs Netz wieder abgestreift hat, werden die Daten wieder an TCP übergeben, welches die Packete wieder sauber zusammensetzt und auf Fehler überprüft. Nun werden die Daten noch der entsprechenden Anwendung zugewiesen, und nach dem entsprechenden Befehl der Anwendung die Verbindung aufgelöst.
Wie bereits erwähnt, sorgt TCP für Datensicherheit. Jedes TCP-Segment von Host A wird von Host B bestätigt. Das nachfolgende Packet in einer Reihe von Packeten würde also erst dann versendet, wenn das vorangehende bestätigt wurde. Dies schafft zwar die grösst mögliche Sicherheit, lässt jedoch die Netz-Performance nahezu völlig ausser Acht. Aus diesem Grund hat man einen Mittelweg gefunden. Anstatt jedes einzelne Packet zu quittieren, wird immer eine kleine Gruppe von Sendungen quittiert. Dieses Verfahren trägt einen bestimmten Namen und funktioniert folgendermassen:

Sliding Windows bzw. Windowing:Das empfangen einer bestimmten Anzahl an TCP-Segmenten, benötigt beim Empfänger auch eine entsprechende Anzahl Buffer. Sobald diese Buffer voll sind, wird ein ACK(acknowlegement) gesendet. Die Grösse des zur Verfügung stehenden Speichers kann jedoch nicht beliebig vergrössert werden, da auch nicht beliebig Ressourcen zur Verfügung stehen. Die Grösse kann jedoch mit jedem gesendeten ACK vom Empfänger der Daten neu definiert werden. Diese "Window-Size" kann sogar bis auf den Wert 0 verringert werden, doch würde dies einen Stop des Datentransfers bedeuten. Tritt die Bestätigung für ein gesendetes Segment nich innerhalb einer bestimmten Zeit ein, so wird es einfach erneut übertragen
 

UDP (User Datagram Protocol) ist ein ungesichertes Protokoll, welches keine der oben unter TCP erwähnten Eigenschaften besitzt. Es ist ebenso ungesichert wie die Protokolle der unter der Transportschicht liegenden Layer. Die Begründung, wesshalb UDP trotzdem zur Transportschicht gehört, lautet folgendermassen: IP kann zwar Verbindungen herstellen, jedoch keine Daten an Anwedungen weitergeben. UDP kann das, genauso wie TCP. Allerdings erwartet UDP keine Bestätigung des Empfangs. UDP ist also s.z.s. eine Anwendungsschnittstelle zu IP. Auch der UDP-Header ist sehr kurz gehalten. Er enthält Informationen zum Ursprungs-Port, Ziel-Port, Länge des Datagramms und die Checksumme der Daten des UDP-Headers.

Hier eine kleine Tabelle mit Beispielen, welche Dienste mit UDP bzw. TCP erreichbar sind:
 
 

Die Sitzungs- und Darstellungsschicht lassen wir hier deswegen aus, weil sie eigentlich nicht definiert werden können. Diese Layer stellen Schichten dar, welche in der Regel einfach Services zur Verfügung stehen, welche in der über- bzw- untergeordneten Schicht angesiedelt sind. Bei der Sitzungsschicht spricht man zum Beispiel von einer TCP-Session (TCP-Sitzung), welche in ihrer Form weder in Schicht 4 noch in Schicht 5 eingeordnet werden kann. Bei der Darstellungsschicht ist das in etwa das Selbe. Die grafische Oberfläche von Xwindows stellt hier als Präsentationslevel einen integralen Bestandteil des Darstellungs-Schicht dar.
Die Anwendungsschicht ist jene Schicht, in welcher der Benutzer seine Befehle quasi direkt über eine Anwendung eingeben kann, um eine Verbindung zu einem Rechner zu öffnen, oder entsprechende Befehle zu geben. Im umgekehrten Sinne ist also die Anwendungschicht auch jene Schicht, von der eine Anwendung auf Rechner A auch seine Befehle von Rechner B erhält. In der Anwedungsschicht gibt es eine ganze Menge Protokolle, und dem sind nach oben hin auch keine Grenzen gesetzt. Es gibt auch keine klar definierte "Boarderlinie". Gewisse Anwedungen können hier auch auf andere Anwendungen aufsetzen. Dies ist beispielsweise bei einem SNMP-basierenden Tool von HP mit dem Namen "Open View" der Fall. Nun aber zur Anwendungsschicht an sich:
 

TELNET: Anfangs der 80-Jahre, als die Zeit des PCs erst begann, gab es noch keine echten Netzwerke. Meist standen dort Grossrechner, an die "dumme" Terminals angehängt waren. Ein Terminal konnte dann also über eine Sammlung an Kabeln mit dem Grossrechner Daten austauschen, nicht jedoch mit weiteren Terminals. Um der Anschaffung von unmengen neuer Kabel aus dem Weg zu gehen, musste eine Software-Lösung her. So kam es dann zu telnet, welches dem Benutzer die Möglichkeit gab, Daten zu editieren etc. als sitze er vor der Shell des anderen Rechners selbst. Das Öffnen einer Verbindung erfolgt direkt durch den Befehl des Benutzers an die Anwendung. Wir könnten nun hier noch alle Basisbefehle von telnet auflisten, doch würde dies wohl keinen grossen Sinn machen.
 

FTP (File Transfer Protocol) ist ein Dienst der es ermöglicht, innerhalb aller Betriebssysteme Daten zu pebrtragen und sie in den jeweiligen Dateiformaten abzuspeichern. Bekanntlich benutzen die meisten Betriebssysteme unterschiedliche Dateiformate. UNIX und UNIX-Klone verwenden oft NFS (Network File System), O/S2 normalerweise HPFS (High Performance File System) und DOS ausschliesslich FAT (File Allocation Table). Die Kommunikation über FTP basiert wie bei telnet auf dem Client-Server-Modell, ist jedoch um einiges komplexer. Wir wollen nicht ganz genau darauf eingehen. Folgende Punkte seien trotzdem erwähnt: Die Kommunikation ist in 5 Phasen eingeteilt:

1. Phase: Verbindungsaufbau
Hier wird vom Client die Anfrage auf Verfügbarkeit des Dienstes an den Rechner gesendet und von diesem bestätigt, User und Passwort verifiziert und die Übertragungsoptionen sowie der bzw. die Dateinamen werden übermittelt

2. Phase: Erstellung einer Datenverbindung
Hier werden die Informationen bezüglich der Ports ausgetauscht, und der eigentliche Datentransfer vorbeireitet. Nachdem dies festgelegt ist, kann der eigentliche Datentransfer beginnen

3. Phase: Datenübertragung
Die Datenübertragung erfolgt nun via FTP in der Form, wie es im entsprechenden Abschnitt bereits erklärt wurde

4. Phase: Einleitung vom Übertragungsende
Der Rechner übermittelt die letzten Daten der gesammten Datei, der Client bestätigt den Empfang dieser Dateien. Nun wird vom Rechner ein Close-Befehl an den Client gesendet, welcher den Befehl entgegennimmt und akzeptiert.

5. Phase: Übertragungsende
Der Server-Datenprozess zeigt seinem Kontrollprozess (Port 21) das Ende der Übertragung an und beendet. Der Client-DatenProzess terminiert ebenfalls, lässt den Kontrollprozess jedoch noch aktiv für weitere Transfers.

Auf die nahezu 60 unter FTP zur Verfügung stehenden Befehle möchte ich hier nicht weiter eingehen, da dies den Rahmen sprengen würde.
 

TFTP (Trivial File Transmission Protocol) basiert nicht wie das vorhin behandelte FTP auf TCP sondern auf UDP. Es Dient zwar auch der Übertragung von Daten, ist jedoch nicht für den Endverbraucher bestimmt. Im Grunde genommen gibt es bei diesen Transfers auch keine Passwortabfrage, sondern höchstens die Hinterlegung der Source-IP, damit man über den möglichen Befehlsumfang zu verfügen. Die wichtigsten sind hierbei connect, mode, get, put, verbose und quit.

Ich werde nun kurz erklären, wie eine Datenübertragung hier abläuft, obwohl die Verbindung ungesichert ist. TFTP basiert ebenfalls auf dem Client-Server Prinzip. Der Client sendet hierbei einen Request an den Server, dieser Bestätigt den Request und beginnt die Datenübertragung. Jeder Datensatz beträgt hierbei 512 Byte und wird vom Server bestätigt. Das Ende der Übertragung wird vom Client automatisch dann angenommen, wenn ein entgegen genommener Satz weniger als 512 Byte lang ist.
 

BOOTP (Boot Protocol) ist UDP basierend, und wurde eigentlich nur dazu entwickelt, um Boot-Vorgänge zu aktivieren. Dies wird nur dort nötig, wo discless-workstations betrieben werden, da diese, wie schonmal erwähnt, ihre logische Adresse nicht speichern können. Mit Booten ist hier übrigens nicht das eigentliche Booten gemeint, sondern lediglich die Übernahme wichtiger Konfigurationsdaten. Eigentlich brauchen wir darauf auch nicht genauer einzugehen, da dies heute nicht mehr von grosser Relevanz ist.
 

SMTP (Simple Mail Transfer Protocol) ist das im Internet wohl am meisten benutzte Protokoll. Seit frühester Zeit hat sich SMTP bereits auf UNIX-Systemen etabliert und mitlerweile auch auf normalen PCs seinen platz gefunden. Hier bedient der Anwender seine Mailsoftware und bereitet eine Nachricht vor. Schickt er dann seine Nachricht ab, so wird diese solange zwischengespeichert, bis TCP die gesammte Nachricht übertragen wurde. Auch hier stehen dem Client als auch dem Server eine Reihe von Befehlen bzw. Reaktionen zur Verfügung, welche ich nicht auflisten werde. Stattdessen werde ich hier einen kleinen Dialog zwischen Server und Client wiedergeben (wir gehen dabei immer von einer positiven Antwort seitens des Servers aus):

- Client baut eine Session zum Server auf
- Server bestätigt die Verfügbarkeit des Services, oder verweigert, da der Service nicht verfügbar ist
- Client identifiziert sich
- Server identifiziert sich
- Client übergibt den eigentlichen Befehl der einen Mail-Versand ankündigt.
- Der Server gibt sein Einverständnis
- Client übermittelt den Empfänger
- Server antwortet mit: Mailbox erreichbar bzw. Mailbox nicht erreichbar
- Client iniziiert die Datenübertragung
- Server nimmt die Daten auf, und verlangt zur Beendung den Befehl <crlf><crlf>
- Client sendet nach Beendung der Übermittlung wie vereinbart <crlf><crlf>
- Client beendet die Verbindung mit dem entsprechenden Befehl
- Server antwortet darauf mit "service closing"

Als in den 80-er Jahren noch andere Mail-Systeme eingeführt wurden, kam es zu Kompatibilitätsproblemen. Die Übergänge waren nicht einfach so zu bewältigen und so musste man sehr umständliche Konverter einsetzen. Seit 1992 Ist nun hauptsächlich MIME (Multipurpose Internet Mail Extensions) im Einsatz, welches sich nicht mehr nur auf den reinen Textversand beschränkt, sondern verschiedenste Datentypen wie Grafiken, Audiodaten u.s.w. zu versenden vermag.
 

RPC (Remote Procedure Calls) wird verwendet, wenn mehrere Rechner mit verschieden gestalteten Kapazitäten zur Verfügung stehen und eine Aufgabe zu erledigen ist, welche sehr grosse Systemressourcen ausschöpfen. Mit RPC können nun Teilaufgaben spezifisch an die dafür am besten qualifizierten Rechner zugewiesen werden und die verschiedenen Rechner verschmelzen s.z.s. zu einem Multi-Computer. Dieses Verfahren findet heutzutage übrigens je länger je mehr Anklang bei grossen Unternehmen. Auf die genauere Struktur wird hier nicht eingegangen.
 

NIS (Network Information Services) wird zur Verwaltung der Operationen, Security-Objekte und Zugriffsrechte verwendet. Dieses ursprünglich von SUN entwickelte System (damals Yellow Pages) ermöglicht die zentrale Administration dezentraler UserIDs, GroupIDs und Passwörter. Um NIS zu betreiben sind folgende Komponenten vorrausgesetzt:

NIS-Datenbank: Sie stellt quasi eine übergrosse /etc/passwd-Datei für das Netzwerk dar
NIS-Master-Server: Er verwaltet die NIS-Datenbank für die entsprechende Domäne
NIS-Slave-Server: Enthält Sicherungskopie der Datenbank für Ausfälle des Master-Servers
NIS-Domäne: Eine Gruppe von auf der NIS-Datenbank abgebildeten Rechnern
NIS-Client: Rechner, welcher Daten vom Server beziehen, jedoch nicht ändern kann

Somit hätten wären dann die wichtigsten Protokolle beschrieben, welche für den Verbindungsaufbau nötig sind. Natürlich sind es längst nicht alle. Wer Neuerungen bezüglich Protokollen nachschlagen will, kann das über den FTP Server 192.112.36.5 (NIC.DDN.MIL) über den gewohnten anonymous-zugang. Dort werden immer wieder Berichte zur Festlegung der neuesten Standarts veröffentlicht.

written by m|azma '99
mail
distributed & redesigned by DukeCS [KryptoCrew]