Das InfoTip Kompendium

Ein kostenloser Service der InfoTip Service GmbH

Zum Anfang der
Seite scrollen

Referenzmodelle und Protokolle - Netzwerktechnologie

Inhaltsverzeichnis

1. Referenzmodelle

Der Begriff "Netzwerk" umfasst eine Unmenge an Aspekten einer sehr komplexen Technologie. Es beginnt mit dem Anwendungsprogramm, dessen aktives Fenster wir auf unserem Computer-, TV-, Blackberry- oder Mobiltelefon-Bildschirm sehen. Es geht weiter mit der Software, die die gewünschten Informationen an die spezifische Hardware des Gerätes weiterleitet (Treiber) und dem Hardwareaspekt des Verbindungaufbaus über das Übertragungsmedium. So unterschiedlich auch die Geräte, die an ein Netzwerk angeschlossen werden sollen und auch so unterschiedlich die Aufgaben, die diese Geräte zu erfüllen haben, müssen sie sich letztendlich an die gleichen Regeln halten. Auch Sicherheitsaspekte spielen natürlich bei der Kommunikation unter Computern eine außerordentlich große Rolle. Die Sicherheit umfasst einmal, dass die Daten korrekt übertragen werden, dann muss natürlich auch der Zugriff auf die Daten geregelt werden.

So wie Protokolle im diplomatischen Leben auch die unterschiedlichsten Parteien zusammenführen können und geregelte Verhandlungen erlauben, regeln Protokolle die Kommunikation in Netzwerken. In der Informatik (und der modernen Telekommunikation) regeln sie das Format, den Inhalt, die Bedeutung und die Reihenfolge der Nachrichten, die zwischen Netzwerkstationen oder Prozessen übertragen werden sollen.

1.1. OSI-Referenzmodell

Um die unterschiedlichsten Netzwerkprotokolle systematisch einordnen zu können, hat die Standardisierungsorganisation ISO Anfang der 80er Jahre das OSI-Schichtenmodell (Open System Interconnect Reference Model) entworfen. Das Modell besteht aus sieben Schichten (Layern), die jeweils einen Aspekt der Netzwerkkommunikation beschreiben. So gehört  jedes Protokoll zu einer bestimmten Schicht und hat darin bestimmte Aufgaben zu erfüllen. Die Schichtung beruht auf dem Prinzip, dass eine Schicht einer ihr zugeordneten Schicht bestimmte "Dienstleistungen" anbietet.

Schicht 7, die Anwendungsschicht, erlaubt den Zugriff von Prozessen und Dialogen der Anwenderprogramme.
Schicht 6, die Darstellungsschicht (Presentation Layer) interpretiert die Daten für die Anwendung. Überwachung des Informationsaustausches und Codierung/Decodierung (ASCII, UNICODE ...) der Daten und sorgt für die Festlegung der Formate und Steuerzeichen. Diese Schicht bildet oft eine Einheit mit der Anwendungsschicht oder sie fehlt gänzlich.
Schicht 5, die Kommunikationssteuerung oder Session Layer,  steuert den Aufbau, die Durchführung und Beendigung der Verbindung. Im Fehlerfall erfolgt ein Wiederaufbau der Verbindung.
In der Transportschicht (Schicht 4) werden die Daten in Pakete unterteilt, sowie mit der Information (Ports) versehen, welche Anwendung auf dem einen Host diese Daten an welche Anwendung auf dem anderen sendet.
Schicht 3, die Vermittlungsschicht (Network), dient hauptsächlich der Datenpaket-Übertragung. Sie ist zuständig für die Wahl der Datenwege (Routing),  für Fehlerbehandlung und Flusskontrolle zwischen den Endpunkten einer Verbindung (nicht zwischen den Anwenderprozessen).
Die Flusskontrolle auf dieser Ebene schützt den Endpunkt einer Verbindung vor Überlastung. Die Fehlerbehandlung in dieser Schicht bezieht sich nicht auf Übertragungsfehler (dafür ist Schicht 2 zuständig), sondern auf das Erkennen und Beseitigen von Duplikaten, Beseitigen permanent kreisender Blöcke, Wiederherstellen der richtigen Datenpaket-Reihenfolge, usw.
Schicht 2, die Sicherungsschicht (Data Link Layer), soll die sichere Verbindung zu den anderen Stationen des Netzwerks gewährleisten. Die Daten aus den darüber liegenden Schichten werden in Datenblöcke, sog. Frames, mit geeigneter Größe (z.B. Ethernet mindestens 64Byte, maximal 1500 Bytes Länge) unterteilt und mit Prüfsummen für eine spätere Fehlererkennung versehen. Hier erfolgt auch die Synchronisation der Daten und die Flusskontrolle statt. Bei lokalen Netzwerken werden die MAC-Absender- und Empfängeradresse eingefügt. 
Die unterste Schicht 1, die Bitübertragungsschicht oder Physical Layer,  definiert, wie die Daten physikalisch übertragen werden. Pegel, Kabel, Modulation werden für jeden Netzwerktyp festgelegt.

Abb. 1.01: Das OSI- und das TCP/IP-Referenzmodell
Abb. 1.01: Das OSI- und das TCP/IP-Referenzmodell

1.2. TCP/IP-Referenzmodel

Das TCP/IP-Referenzmodell, benannt nach den primären Protokollen TCP (Transport Control Protocol) und IP (Internet Protocol) stellt in vereinfachter Form das 7-schichtige OSI-Referenzmodell in vier Schichten dar. Da in realen Anwendungen die Anwendungsprogramme direkt mit der Transportschicht kommunizieren, sind in diesem Modell die Schichten 5 bis 7 zu einer Anwendungsschicht zusammengefasst. Auch die Sicherungsschicht und die Bitübertragungsschicht werden gemeinsam als Netzzugangsschicht betrachtet, da hier keine TCP/IP-spezifischen Protokolle enthalten sind (Sie sind "protokolltransparent").

2. Host-to-Host-Kommunikation in einem TCP/IP-Netz

Jegliche Kommunikation zwischen zwei Partnern ist an bestimmte Voraussetzungen gebunden. Zum einen muss die Hardware der Partner und der Datenübertragungseinrichtungen über kompatible Schnittstellen verfügen und zum anderen müssen Vereinbarungen über die Art und Weise des Informationsaustausches getroffen werden. Dieses gewährleisten die fest in den Schichten der Referenzmodelle angesiedelten Protokolle. Nach außen hin erscheint es so, als ob die entsprechenden Schichten zweier miteinander kommunizierender Stationen eine logische Verbindung haben (Abb. 2.01, gestrichelte Linie).  Lediglich bei der untersten Schicht 1, der Bitübertragungsebene in der Netzzugangsschicht, handelt es sich um eine physikalische Verbindung.

Abb. 2.01: Host-to-Host-Kommunikation in einem TCP/IP-Netz
Abb. 2.01: Host-to-Host-Kommunikation in einem TCP/IP-Netz

Prinzip der Datenübertragung

Um das Prinzip der Datenübertragung zwischen zwei Stationen zu erläutern, soll der Weg eines Datenpaketes, das HOST_1 an HOST_2 schickt, verfolgt werden.
Aus dem Nutzdatenstrom eines Anwendungsprogramms gelangt eine definierte Datenmenge, ein Datenpaket, über einen Port (Schnittstelle zum Anwendungsprogramm) in die Transportschicht. Hier wird den reinen Nutzdaten der 20 Bytes lange TCP-Header vorangestellt. In diesem Header stehen u.a. der Ausgangsport, also die Schnittstelle zum Anwendungsprogramm im HOST_1 und der Zielport, das ist die Schnittstelle zur Anwendung auf HOST_2. Weiterhin steht im TCP-Header auch die Sequenznummer. Alle zu übertragenden Datenpakete werden vom Sender (HOST_1) sequentiell durchnummeriert damit der Empfänger (HOST_2) alle Paket wieder in die richtige Reihenfolge anordnen kann.
Das jetzt als TCP-Segment bezeichnete Datenpaket gelangt nun in die Vermittlungsschicht. Auch hier wird dem TCP-Segment ein 20 Bytes langer Header, der IP-Header vorangestellt. Die wichtigsten Informationen im IP-Header sind die Quelladresse, also die IP-Adresse von HOST_1 als Absender und die Zieladresse, welche die von HOST_2 ist. Ist die IP-Adresse der Zielstation nicht bekannt, kann sie durch ein weiteres Protokoll, dem DNS (Dynamic Name System) beschafft werden. Damit HOST_2 weiß, wie dieses Paket in der Transportschicht zu behandeln ist, wird ein entsprechender Verweis in den Header eingefügt. Um zu verhindern, dass "verirrte" Datenpakete für immer im Netz kreisen, ist im IP-Header ein Zähler vorgesehen, der die Anzahl der erlaubten "Hops" (Durchgänge durch Router) angibt.
Das jetzt als IP-Paket bezeichnete Datenpaket gelangt nun in die Netzzugangsschicht, die in diesem Beispiel auf Ethernet beruhen soll. Wie zuvor wird dem IP-Paket ein weiterer Header, der Ethernet- (MAC-) Header vorangestellt. In diesem 16 Bytes langen Header stehen die Hardware- (MAC-) Adresse von HOST_1 als Absender und die Hardware-Adresse des Ziels, also HOST_2. Sollte HOST_1 die Hardwareadresse von HOST_2 nicht bekannt sein, kann er sie über das ARP-Protokoll beschaffen. Damit HOST_2 weiß, wie dieses Paket in der Vermittlungsschicht zu behandeln ist, wird ein entsprechender Verweis in den MAC-Header eingefügt. Zum Schluss wird eine vier Byte lange Prüfsumme über den MAC-Header plus IP-Paket berechnet und angefügt. Das als Ethernet-Frame bezeichnete Datagramm kann nun über das Übertragungsmedium (Kabel, Glasfaser, ...) zum HOST_2 geschickt werden.

Anhand der Ziel-MAC-Adresse weiß HOST_2, dass dieses Ethernet-Frame für ihn bestimmt ist. Er streift den Header und die Prüfsumme ab und reicht das verbleibende IP-Paket mit einer entsprechenden Information wie damit weiter zu verfahren ist in die Vermittlungsschicht weiter.
In der Vermittlungsschicht werden Absender-IP-Adresse und Ziel-IP-Adresse überprüft und die Information selektiert, wie weiter mit dem verbleibenden Datenpaket, in diesem Fall ein TCP-Segment, zu verfahren ist. Das vom IP-Header befreite Datenpaket wird mit der Information, das es ein  TCP-Segment ist, in die Transportschicht weitergereicht.
In der Transportschicht wird der Zielport aus dem TCP-Header ausgelesen und die reinen Nutzdaten über diesen Port an die Anwendung weitergereicht.

3. Netzwerkprotokolle

Abb. 3.01: Die wichtigsten Protokolle im TCP/IP-Referenzmodell
Abb. 3.01: Die wichtigsten Protokolle im TCP/IP-Referenzmodell

3.1. Die Protokolle in der Netzzugangsschicht

Die unterste Schicht beim Internet-Protokoll ist der Netzzugang (nicht die Netzwerk-Hardware). Dies stellt sicher, dass sich die Internetprotokolle auf fast jeder Hardware implementieren lassen. Die wohl wichtigen Protokolle in dieser Schicht sind CSMA/CD für das Ethernet, PPP für Punkt-zu-Punkt-Verbindungen (für Analog-Modem, ISDN und DSL) und das ARP-Protokoll.

ATM (Asynchronous Transfer Mode)

ATM ist eine Technik der Datenübertragung, bei der der Datenverkehr in kleine Pakete – Zellen oder Slots genannt – mit fester Länge (53 Byte, davon 48 Byte Daten, 5 Byte Zellkopf) codiert und über asynchrones Zeitmultiplexing übertragen wird.
Fast alle Betreiber von Kommunikationsnetzen setzen ATM-Netze im Backbone-Bereich und in breitbandigen Zugangsnetzen (DSLAM, RAS) ein.
Im Broadcast-Bereich (TV, Radio, ...) wird die ATM-Technik von Sende- und Rundfunkanstalten genutzt. Produktionsfirmen und Sender versenden ihr Ton- und Bildmaterial in Echtzeit über Glasfasernetze an die verschiedenen Sendeanstalten.

CSMA/CD

Die Abkürzung "CSMA/CD" steht für "Carrier Sense Multiple Access/Collision Detect". Dieses Verfahren findet häufig bei logischen Busnetzen (z.B. Ethernet ) und ähnlich auch beim WLAN Anwendung, kann aber prinzipiell bei allen Topologien eingesetzt werden.
Bevor eine Station sendet, hört sie zunächst die Leitung ab, um festzustellen, ob nicht schon ein Datenverkehr zwischen anderen Stationen stattfindet. Erst bei freier Leitung wird gesendet und auch während der Sendung wird mitgehört, um festzustellen, ob eine Kollision mit einer Station auftritt, die zufällig zum gleichen Zeitpunkt mit dem Senden begonnen hat (Collision Detect). Wurde eine Kollision bemerkt, wird sofort die Aussendung von Datenpaketen beendet. Ein Zufallsgenerator bestimmt dann denn Zeitpunkt wann wieder gesendet werden darf. Das CSMA/CD-Verfahren findet im Ethernet nur bei Verbindungen im Halbduplex-Modus Einsatz. Im Vollduplex-Modus sind Stationen über Switches verbunden, die eine kollisionsfreie Kommunikation gewährtleisten.

Ethernet

Ethernet ist eine Technologie, die Software (Protokolle usw.) und Hardware (Kabel, Verteiler, Netzwerkkarten usw.) für kabelgebundene Datennetze spezifiziert. Diesem Thema ist ein eigener Artikel "Ethernet" gewidmet.

PPP/PPPoE

Das PPP ( Point-to-Point Protocol) ist ein Protokoll zum Verbindungsaufbau über Wählleitungen. Es sorgt nach der Einwahl für die Authentifizierung des Benutzers indem Benutzername und Passwort gesendet werden. Anschließend handeln die direkt miteinander verbundenen Punkte die Konfiguration des Vermittlungsschichtprotokolls aus. Hierbei erhält der einwählende Rechner vom Einwahlknoten automatisch eine IP-Adresse, die im ganzen Internet gültig ist.
Die Variante PPPoE steht für "PPP over Ethernet", also die Nutzung des Netzwerkprotokolls PPP über eine Ethernet-Verbindung. PPPoE wird heute bei ADSL-Anschlüssen in Deutschland verwendet. PPPoE ermöglicht u.a. Authentifizierung und Netzwerkkonfiguration (IP-Adresse, Gateway) auf dem schnelleren Ethernet.

ARP (Address Resolution Protocol)

Ein weiteres wichtiges Protokoll der Netzzugangsschicht ist das ARP. Die Umsetzung der von einem Administrator oder vom DHCP-Dienst vergebenen IP-Adresse in eine Hardware-Adresse (auch MAC-Adresse oder Physikalische Adresse) erfolgt durch Tabellen und auf Hardware-Ebene (z. B. Ethernet) automatisch über ARP. Dazu ein Beispiel: Die Station Client_A will Daten an Station Client_C mit der Internetadresse IP(C) senden, deren physikalische Adresse IP(C) sie noch nicht kennt. Sie sendet ein ARP-Request (ein sog. Broadcast-Datenpaket mit der speziellen Ziel-IP-Adresse 255.255.255.255 im Header) an alle Stationen im Netz, der die eigene physikalische Adresse und die IP-Adresse von Client_C enthält. Alle Stationen erhalten und überprüfen den ARP-Request und die angesprochene Station Client_C antwortet, indem sie einen ARP-Reply mit ihrer eigenen physikalischen Adresse an die Station Client_A sendet.

Abb. 3.02: Funktionsprinzip von ARP
Abb. 3.02: Funktionsprinzip von ARP

Letztere speichert die Zuordnung in einer Tabelle (Address Resolution Cache) welche zyklisch alle paar Minuten komplett neu erstellt wird. Dadurch werden alle alten Einträge gelöscht und Platz geschaffen. Auch werden hierdurch alle nicht erfolgreichen Verbindungsversuche mit Computern, die zu dem Zeitpunkt nicht erreichbar waren, entfernt.

Abb. 3.03: Mit dem Befehl arp -a kann der ARP-Cache eines Hosts angezeigt werden
Abb. 3.03: Mit dem Befehl arp -a kann der ARP-Cache eines Hosts angezeigt werden

Es können vier unterschiedliche ARP-Nachrichten vom ARP-Protokoll verschickt werden:

  • ARP-Request
  • ARP-Reply
  • RARP-Request
  • RARP-Reply

RARP (Reverse ARP) ist die Umkehrung des ARP: Die Hardware-Adresse ist dem sendenden Host bekannt, die Protokoll- (IP-) Adresse aber nicht.
Hier sendet die Station A unter Angabe ihrer physikalischen Adresse MAC(A) einen RARP-Request. Wenn im Netz eine Station als RARP-Server eingerichtet ist, antwortet diese mit einem RARP-Reply an die anfragende Station, der die IP-Adresse der Station A enthält. Diese Funktion ist z. B. für sogenannte "Diskless Workstations" wichtig, die ihre gesamte Software von einem Server laden.
 
Aufbau einer ARP-Nachricht
Eine ARP-Nachricht besteht aus 28 Byte.

Abb. 3.04: Aufbau einer ARP-Nachricht
Abb. 3.04: Aufbau einer ARP-Nachricht

Hardware Type
Jeder Typ von Bitübertragungsschicht (Link Layer) ist in diesem Feld mit einer Zahl gekennzeichnet. Zum Beispiel hat Ethernet die "1".

Protocol Type
Jedes Protokoll ist in diesem Feld mit einer Zahl gekennzeichnet. Zum Beispiel hat IPv4 die "0x0800".

Hardware Length
Länge der Hardware-Adresse in Bytes. Ethernet-Adressen (MAC-Adressen) sind sechs Bytes lang.

Protocol Length
Länge der Logischen Adresse in Bytes. IPv4-Adressen sind vier Bytes lang.

Operation
Spezifiziert die Operation, die der Sender durchführt:
1 für ARP-Request (Abfrage)
2 für ARP-Reply (Antwort)
3 für RARP-Request
4 für RARP-Reply

Sender Hardware Address
Hardware- (MAC-) Adresse des Senders

Target Hardware Address
Hardware-Adresse des gesuchten Empfängers. Bei Requests ist dieses Feld mit Null gefüllt.

Target Protocol Address
Protokoll- (IP-) Adresse des gesuchten Empfängers.

3.2. Die Protokolle in der Vermittlungsschicht

Die Protokolle der Vermittlungsschicht (OSI-Schicht 3, TCP/IP Schicht 2) regeln die Adressierung der Rechner und die Übertragung der Daten an den korrekten Rechner im Netzwerk. Darüber hinaus kümmern sie sich darum, dass Daten bei Bedarf in andere Teilnetze weitergeleitet werden, sie übernehmen also das so genannte Routing.

3.2.1.IP-Protokoll

Auf der Netzwerkschicht aufbauend liegt die Internet-Schicht. Auf dieser Schicht stellt das Internet-Protokoll ( IP) den grundlegenden Netzdienst 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. Nehmen wir als Beispiel das Ethernet: Von der Ethernet-Karte werden die vom Netz kommenden Daten an die Treibersoftware für die Karte weitergereicht. Diese 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 eingekapselt. Aber auch das IP-Paket selbst enthält wieder ein Datenpaket für eine höhere Protokollebene (TCP oder UDP), dessen Header auf der IP-Ebene als Bestandteil der Daten erscheint.

IP ist ein verbindungsloses Protokoll. Es ist also nicht notwendig, eine IP-Verbindung zu einem Rechner zu 'öffnen', bevor man Daten zu diesem Rechner senden kann, sondern es genügt, das IP-Paket einfach abzusenden und darauf zu vertrauen, dass es schon ankommen wird. Bei einem verbindungsorientierten Protokoll, wie z.B. TCP, wird beim Öffnen einer Verbindung getestet, ob der Zielrechner überhaupt erreichbar ist. Ein verbindungsloses Protokoll macht das nicht und kann demnach auch nicht garantieren, dass ein Datenpaket überhaupt beim Empfänger ankommt. IP garantiert auch nicht, dass von einem einmal abgeschickten Datenpaket nur eine Kopie beim Empfänger ankommt oder dass in einer bestimmten Reihenfolge abgeschickte Datenpakete auch wieder in dieser Reihenfolge empfangen werden.
Normalerweise laufen die IP-Pakete über mehrere Zwischenstationen (" Hops"), bis sie am Zielrechner ankommen. Bricht irgendwann während der Übertragung ein Übertragungsweg zusammen, so wird ein neuer Weg zum Ziel gesucht und benutzt. Da der neue Weg zeitlich länger oder kürzer sein kann als der alte, kann man keine allgemeingültigen Aussagen darüber machen, in welcher Reihenfolge IP-Pakete beim Empfänger eintreffen. Das Beheben der so entstehenden Probleme überlässt das IP-Protokoll anderen, höher liegenden Schichten (TCP oder UDP).
Ein IP-Datagramm besteht aus einem Header und einem nachfolgenden Datenblock, der seinerseits dann z. B. in einem Ethernet-Frame "verpackt" wird. Die maximale Datenlänge wird auf die maximale Rahmenlänge des physikalischen Netzes (z.B. 1500 Byte bei Ethernet) abgestimmt.

Der IP-Header (IPv4)

Jedes IP-Datagramm besteht aus den Nutzdaten und dem vorangestellten IP-Header. Der IP-Header besteht meist aus fünf 32-Bit-Worten und enthält Informationen über Quelle, Ziel usw. Die Kopfdaten von den höher liegenden Protokollen, z.B. TCP oder UDP sind Teil der Nutzdaten.

Abb. 3.05: IP-Header in IPv4-Format
Abb. 3.05: IP-Header in IPv4-Format
Aufbau des IP-Headers:

Version: Kennzeichnet die IP-Protokollversion
IHL (Internet Header Length): Die Angabe der Länge des IP-Headers erfolgt in 32-Bit-Worten (normalerweise 5). Da die Optionen nicht unbedingt auf Wortlänge enden, wird der Header gegebenenfalls aufgefüllt.
Type of Service: Alle Bits haben nur "empfehlenden" Charakter. 'Precedence'("Vorrangigkeit" / Bits 0-3) bietet die Möglichkeit, Steuerinformationen oder Echtzeitströme vorrangig zu befördern. Dies ist z.B. bei Streaming oder VoIP von besonderem Interesse ( QoS = Quality of Service).
Total Length: Gesamtlänge des Datagramms in Bytes (max. 64 KByte).
Identification: Dieses und die beiden folgenden Felder steuern die Reassembly. Eindeutige Kennung eines Datagramms. Anhand dieses Feldes und der 'Source Address' ist die Zusammengehörigkeit von Fragmenten zu detektieren.
Flags: Die beiden niederwertigen Bits haben folgende Bedeutung:
Don't fragment: Für Hosts, die keine Fragmentierung unterstützen
More fragments: Zum Erkennen, ob alle Fragmente eines Datagramms empfangen wurden
Fragment Offset: Die Daten-Bytes eines Datagramms werden nummeriert und auf die Fragmente verteilt. Das erst Fragment hat Offset 0, für alle weiteren erhöht sich der Wert um die Länge des Datenfeldes eines Fragments. Anhand dieses Wertes kann der Empfänger feststellen, ob Fragmente fehlen.
Time-to-live (TTL): Jedes Datagramm hat eine vorgegebene maximale Lebensdauer, die hier angegeben wird. Auch bei Routing-Fehlern (z. B. Schleifen) wird das Datagramm irgendwann aus dem Netz entfernt. Da Zeitmessung im Netz problematisch ist, und keine Startzeit im Header vermerkt ist, dekrementiert jeder Router oder Gateway dieses Feld --> defacto ein 'Hop Count'.
Protocol: Da sich unterschiedliche Protokolle auf IP stützen, muss das übergeordnete Protokoll (ULP, Upper Layer Protocol) angegeben werden. Wichtige ULPs sind:
  1: ICMP Internet Control Message Protocol
  3: GGP Gateway-to-Gateway Protocol
  6: TCP Transmission Control Protocol
  8: EGP Exterior Gateway Protocol
17: UDP User Datagram Protocol
Header Checksum: 16-Bit-Längsparität über den IP-Header (nicht die Daten)
Source Address: Internet-Adresse der Quellstation
Destinantion Address: Internet-Adresse der Zielstation
Options: Optionales Feld für weitere Informationen
Padding: Füllbits

 

3.2.2. ICMP (Internet Control Message Protocol)

Das ICMP  ermöglicht den Austausch von Kontroll- und Fehlerpaketen. Die meisten ICMP-Pakete enthalten Diagnose-Informationen, sie werden vom Router zur Quelle zurückgeschickt, wenn der Router Pakete verwirft, z.B. weil das Ziel nicht erreichbar ist oder die erlaubte Paketlaufzeit abgelaufen ist, usw.
ICMP wurde jedoch nicht für die Kommunikation von Routern untereinander geschaffen, hierfür gibt es eigene Protokolle.
ICMP benutzt die Basisdienste des Internet Protokolls und arbeitet deshalb wie ein Protokoll der höheren Transportschicht. Andererseits ist ICMP ein integraler Teil des Internet Protokolls. Das bedeutet, dass IP nicht ohne ICMP implementiert werden kann. Aus diesem Grund wird es meist der Schicht 3 zugeordnet.

Die Felder Type, Code und Checksum des ICMP Protokolls sind obligatorisch. Type definiert den Meldungstyp, Code definiert den Status oder Zustand eines Systems oder es definiert weitere Details einer Meldung. Checksum ist eine Prüfsumme über die gesamte ICMP-Meldung.
Die 32 Bit von ICMP Data 1 sind bei manchen Meldungen ungenutzt. Dennoch ist es obligatorisch. Falls das Feld ungenutzt ist, wird es mit Fülldaten belegt. Die Bedeutung dieses Felds ist abhängig vom Meldungstyp. Bei manchen Meldungen wird es in weitere Teilfelder aufgespalten. ICMP Data 2 ist dagegen optional. Wo es nicht gebraucht wird, kann es auch entfallen. Auch ist die Größe von ICMP Data 2 nicht festgelegt.

Abb. 3.06: Aufbau einer ICMP-Nachricht
Abb. 3.06: Aufbau einer ICMP-Nachricht

Es sind 27 verschiedene ICMP-Pakettypen definiert. Die wichtigsten ICMP-Pakettypen:
Echo Request und Echo Reply
Diese Pakettypen werden vom Ping Befehl genutzt, um festzustellen, ob eine Station erreichbar ist.
Destination Unreachable
Hierüber teilt eine Station oder ein Router mit, dass ein Ziel nicht erreichbar ist. Über den Code wird genauer definiert, was nicht erreichbar ist: Ein ganzes Netzwerk, eine Station oder ein Dienst. Eventuell ist auch ein Paket zu groß für eine bestimmte Transferstrecke.
Parameter Problem
Diese Nachricht wird versandt, wenn ein Paket einen fehlerhaften Header hat.
Source Quench
Diese Nachricht wird versandt, wenn ein Router an seine Kapazitätsgrenze kommt und keine weiteren Datenpakete mehr zwischenspeichern kann.
Time Exceeded
Zeitlimit überschritten (Lebensdauer eines Pakete (TTL = Time to Live) abgelaufen)
Traceroute
Dokumentiert den Weg eines Pakets.

 

3.3. Protokolle in der Transportschicht (Host-to-Host Layer)

3.3.1. UDP (User Datagram Protocol)

UDP ist ein Protokoll der Schicht 4, dessen einzige Aufgabe es ist, eine Verbindung zur Applikationsschicht bereitzustellen. Dazu dienen die Ports. Ein Port definiert einen Dienst eines Servers bzw. ein Anwendungsprogramm einer Arbeitsstation. UDP wird als „ verbindungsloses Protokoll“ bezeichnet. Das bedeutet  dass zur Datenübertragung mittels UDP kein vorheriger Verbindungsaufbau zwischen den Kommunikationspartnern stattfindet, sondern dass der Sender einfach die UDP Pakete losschickt.
Damit kann über UDP nicht geprüft werden, ob alle Daten vollständig angekommen sind, bzw. ob der Partner überhaupt empfangsbereit ist. UDP wird dann benutzt, wenn ein Verbindungsaufbau zu aufwendig wäre, oder wenn es keinen Sinn macht, verlorene Pakete nachzusenden. Dies ist beispielsweise bei Media Streaming oder bei Internettelefonie der Fall da bei solchen Anwendungen das Warten auf nachgesendete Datenpakete zu Ton- oder Bildaussetzern führen würde.
Die Felder im UDP-Header sind:

Source Port
Destination Port
Length
Checksum
  Der Port des Absenders
Der Port des Empfängers
Die Länge des UDP-Datagramms, inklusive dem UDP-Header
Prüfsumme
Abb. 3.07: Aufbau eines UDP-Headers
Abb. 3.07: Aufbau eines UDP-Headers

Die maximale Größe eines UDP-Datagrammes beträgt 65.535 Bytes, da das Length-Feld des UDP-Headers 16 Bit lang ist und die größte mit 16 Bit darstellbare Zahl gerade 65.535 ist. Solch große Segmente werden jedoch von IP fragmentiert übertragen.

3.3.2. TCP (Transmission Control Protocol)

Das Transmission Control Protocol, kurz TCP, ist wie UDP ein Protokoll der Schicht 4. Im Gegensatz zu UDP ist TCP ein "verbindungsorientiertes Protokoll" und es kann somit ein gesicherter Datenaustausch zwischen zwei Netzwerkteilnehmern gewährleistet werden, auch wenn das darunterliegende Kommunikationsmedium unzuverlässig ist. Dazu wird vor der eigentlichen Datenübertragung eine logische Verbindung aufgebaut. Vor dem Senden wird die Menge der zu übertragenden Daten ausgehandelt.
Die gesendeten Daten werden im Feld „Sequence Number“ durchnummeriert, sodass ein Empfänger die Daten in der richtigen Reihenfolge wieder zusammensetzen kann, falls Pakete durch Laufzeitunterschiede in falscher Reihenfolge ankommen. Durch die Sequenznummern kann der Empfänger auch erkennen, wenn Pakete verlorengehen.
Der Empfänger muss den Empfang der Daten im Feld „Acknowledgement Number“ bestätigen; Daten die er nicht bestätigt, werden erneut gesendet.
Über das Feld „Window“ teilt der Empfänger dem Sender die Größe seines Empfangspuffers mit. Die Verbindung zur Anwendungsschicht wird wie bei UDP über die Port-Felder hergestellt.
Das Feld „Options“ ermöglicht es, zusätzliche Informationen zu versenden.
Über das Feld „Data Offset“ wird die Größe des TCP-Headers angegeben. Dadurch können die optionalen Informationen im TCP-Header unterschiedlich groß sein oder auch ganz entfallen.
Die Kontrollbits URG, ACK, PST, etc. dienen der Datenflusskontrolle.
Über „Urgent Pointer“ kann ein Empfänger dringend benötigte Daten anfordern. Der Sender zeigt dann im gleichen Feld an, wo diese Daten innerhalb des Datenstroms zu finden sind.

Abb. 3.08: Aufbau eines TCP-Headers
Abb. 3.08: Aufbau eines TCP-Headers
Die Größe von TCP-/IP-Segmenten

Ein TCP-Segment hat typischerweise eine Größe von maximal 1500 Bytes. Ein TCP-Segment muss jedoch in die Struktur der darunter liegenden Übertragungsschicht, dem Internetprotokoll (IP), passen. IP-Pakete wiederum dürfen zwar theoretisch bis 65.535 Bytes (64 KiB) groß sein, werden aber selbst meist über Ethernet übertragen, und bei Ethernet ist die Frame-Größe (abgesehen von Jumbo Frames) auf 1500 Bytes festgelegt.
TCP- und IP-Protokoll fügen jeweils einen Header von 20 Bytes Größe hinzu. Für die Nutzdaten bleiben in einem TCP/IP-Paket also 1460 Bytes (= 1500 Bytes [Nutzdaten] − 20 Bytes Headerdaten TCP − 20 Bytes Headerdaten IP) übrig. Da die meisten Internet-Anschlüsse DSL verwenden, kommt dort zusätzlich noch das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung, was weitere acht Bytes für den PPP-Rahmen verbraucht. Die Nutzdaten reduzieren sich also auf insgesamt 1500 − 20 − 20 − 8 = 1452 Bytes MSS (Maximum Segment Size). Dies entspricht einer Nutzdatenrate von 96,8 %.

 

3.3.3. SSL / TLS (Secure Sockets Layer / Transport Layer Security)

SSL (Secure Sockets Layer), seit der Version 3.1 auch als TLS (Transport Layer Security) bezeichnet, ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet.
Dabei kommt eine Ende-zu-Ende-Verschlüsselung mittels symmetrischer Algorithmen zur Anwendung. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (z.B. SSL Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden. SSL unterstützt für die symmetrische Verschlüsselung u.a. mit DES, Triple DES und AES.
Zur Sicherung der Nachrichten-Integrität und Authentizität wird eine kryptografische Prüfsumme meist unter SHA-1 oder MD5 gebildet. Zusätzlich werden zu sichernde Daten in Blöcken von maximal 65.536 (216) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße 16384 (214) Byte nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt - dann darf die Blockgröße um 1024 bzw. 2048 Byte größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem SSL Handshake-Protokoll ausgehandelt.
SSL-Verschlüsselung wird heute vor allem mit der sicheren Variante des HTTP-Protokolls, dem HTTPS, POP3, SMTP, SIP, IMAP und FTP (FTPS) eingesetzt.

 

3.3.4. SCTP (Stream Control Transmission Protocol)

Das Stream Control Transmission Protocol wurde ursprünglich entworfen um die Signalisierung eines leitungsgebundenen Telefonfestnetze über IP-Netzwerke zu übertragen. Aber das Konzept von SCTP unterstützt auch andere Anwendungen.
SCTP arbeitet auf der Transportschicht des TCP/IP-Referenzmodells und vereinigt die Eigenschaften von TCP und UDP, die in der selben Ebene angesiedelt sind. Wie TCP ist SCTP ein zuverlässiges, verbindungsorientiertes Transportprotokoll, das, wie UDP, auf einem potenziell unzuverlässigen verbindungslosen Paketdienst aufsetzt. Die grundlegende Funktion von SCTP ist die verlässliche Übertragung von Nachrichten (messages) zwischen zwei SCTP-Endpunkten. Eine SCTP-Verbindung zwischen zwei SCTP-Endpunkten wird als association (Verbund) bezeichnet.
in einer association können mehrere Message-Streams in sich reihenfolgenerhaltend transportiert werden. Zusätzlich können einzelne, zum Beispiel dringende, Datagramme separat und „out-of-order“ verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“.
SCTP kennt außerdem Multistreaming und Multihoming (ein Host mit mehreren gültigen IP-Adressen). Es wird eine spezielle Signalisierung ("Heartbeats") verwendet, um aktiv auf Verbindungsabriss zu testen.
(Quellen: [1], [3], [4])

 

3.4. Die Protokolle in der Anwendungsschicht ("Höhere Protokolle")

3.4.1. DHCP ( Dynamic Host Configuration Protocol)

Um in einem IP-basierten Netzwerk Kontakt mit anderen Rechnern aufnehmen zu können, benötigt jeder Computer eine eigene, eindeutige IP-Adresse. Je größer das Netzwerk wird und je mehr verschiedene Rechnerplattformen darin vereint sind, desto höher ist der Aufwand für den Administrator: Wann immer ein neuer Rechner in das Netzwerk integriert wird, muss er zuerst konfiguriert werden. Ändert einer der zentralen Server seine Adresse oder wird er auf eine andere Maschine verlegt, müssen alle Netzwerk-Clients umkonfiguriert werden.
Einen zweiten Aspekt bringen sogenannte "nomadische" Systeme, z. B. Laptops, die irgendwo ins Netz eingebunden werden sollen. Dabei bieten sich verschiedene Zugangsmöglichkeiten für Rechner in das Intranet:

  • Anschluss über einen Ethernet-Switch
  • Zugang durch drahtlose Netze (und evtl. einen Router zum drahtlosen Subnetz)
  • Zugang aus Internet per VPN (Virtual Private Network, eine verschlüsselte Verbindung) über eine Firewall

Der Zugang eines Rechners zum Netz sollte gewissen Anforderungen genügen:

  • automatisiert (ohne manuellen Eingriff)
  • authentifiziert, d. h. nur zugelassene Systeme erhalten Zugriff
  • vollständig (Netz-, System- und Anwendungskonfiguration)
  • standardisiert, d. h. für alle Systeme in einheitlicher Form

Eine Lösung für dieses Problem bietet DHCP (Dynamic Host Configuration Protocol). Dieser Dienst ermöglicht es, einem Client dynamisch eine IP-Adresse und andere Netzwerkparameter, wie den Netzwerknamen, die Gateway-Adresse etc., zuzuweisen ohne dass der Administrator den Rechner überhaupt zu Gesicht bekommt. DHCP ist dabei völlig unabhängig von der eingesetzten Plattform. Das heißt, es kann sowohl Windows-Maschinen wie auch zum Beispiel Linux-Rechner mit den Netzwerkeinstellungen versorgen.

DHCP arbeitet nach den Server-Client-Prinzip. Ein oder mehrere DHCP-Server verwalteten alle in einem Netz verfügbaren IP-Adressen ("Adresspool"). Jede vergebene IP-Adresse wird vom DHCP-Server protokolliert und eine eventuell zugewiesene Gültigkeitszeit (Lease) überwacht.
Der DHCP-Client ist ein Programm, das auf einem lokalen Rechner läuft und durch eine Freigabe ("Automatischer Bezug von Netzwerkadresse") aktiviert werden kann.

Abb. 3.09: Freigabe des DHCP-Clients unter Windows 7
Abb. 3.09: Freigabe des DHCP-Clients unter Windows 7

Wird der Rechner mit einem Netzwerk verbunden und das System neu gestartet, schickt der DHCP-Client ein DISCOVER (= finden)-Datenpaket mit seiner MAC-Adresse an die Broadcast-Adresse 255.255.255.255. Dabei ist der UDP-Quellport 68 und der UDP-Zielport 67 eingetragen.
Der (oder die) DHCP-Server lauschen auf UDP-Port 67 und antworten indem sie ein OFFER (= Angebot)-Paket ebenfalls an die Broadcastadresse 255.255.255.255 mit Zielport 68 schicken. In dem OFFER-Datenpaket steht ein Vorschlag für eine IP-Adresse und eine Lease-Zeit.
Der Client kann das zuerst eintreffende OFFER-Paket mit eventuell folgenden vergleichen und das günstigste Angebot, z.B. die längste Lease-Zeit, auswählen. Dem gewählten Server sendet er nun per Broadcast ein REQUEST (= Anfrage)-Paket. Alle eventuellen weiteren DHCP-Server werten das als Absage für ihre Angebote. Der vom Client ausgewählte Server bestätigt in einer ACKNOWLEDGED (= Bestätigung)-Nachricht die IP-Adresse mit den weiteren relevanten Daten (z.B. Netzwerknamen, IP-Adressen vom DNS-Server und dem Standard-Gateway).
Nach der Bestätigung der IP-Adresse überprüft der Client diese mittels eines ARP-REQUEST. Antwortet ein anderer Host im Netz, weist der DHCP-Client die vorgeschlagene IP-Adresse mit einem DECLINE (= Ablehnung)-Paket an den DHCP-Server zurück.
Wird die vorgeschlagene Adresse nicht verwendet, konfiguriert der Client sein Netzwerkinterface mit den vorgegebenen Einstellungen.

Abb. 3.10: Ablauf der Zuweisung einer IP-Adresse per DHCP
Abb. 3.10: Ablauf der Zuweisung einer IP-Adresse per DHCP [2]

3.4.2. DNS - Dynamic Name System

Um mit einem Computer in einem Netz Verbindung aufnehmen zu können, muss man dessen IP-Adresse kennen. Solange IP-Adressen nur von Computern verwendet werden um entfernte Rechner zu erreichen, ist alles recht einfach. Für die Verwendung durch Menschen ist das System weniger gut geeignet (außer man kann sich auch Telefonnummern gut merken). Um z.B. die InfoTip-Homepage www.infotip.de aufzurufen, wäre die Eingabe von 213.218.170.150 als Adresse recht umständlich.
Computernamen, deren Namen vom DNS in die entsprechenden IP-Adressen aufgelöst werden sollen, werden als Domain Names bezeichnet. Sie sind in eine vorgegebene Struktur eingebunden, die URL (Uniform Resource Locator) genannt wird.
In den frühen Jahren des Internets, als die Anzahl der Computer noch begrenzt war, wurden Listen Computernamen und deren IP-Adressen lokal auf dem Computer gespeichert. Diese Liste, die „hosts“-Datei, gibt es auch heute noch (z.B. bei Windows im Verzeichnis C:\Windows\System32\drivers\etc\), sie wird jedoch nur noch in Ausnahmefällen verwandt. Stattdessen wurden vernetzte Datenbanken (DNS = Dynamic Name System) eingeführt, deren Server auf Anfrage die zu einem Hostnamen gehörende IP-Adresse (oder umgekehrt) zurück liefern. Diese Namen- oder DNS-Server sind hierarchisch in sogenannte Zonen, die definierten Teilen der einzelnen Level der Domain Names entsprechen, angeordnet. So gibt es für die Rootebene insgesamt 13 Server (zehn in den USA und jeweils einen in London, Stockholm und Tokio), die von der ICANN unterhalten werden. Die "DE"-Domäne wird von Servern an 16 Standorten (Frankfurt am Main, Amsterdam, Berlin, Peking, Hongkong, London, Los Angeles, Miami, Paris, Redwood City, São Paulo, Stockholm, Ulm und Wien) der DENIC aufgelöst. T-Online als ISP (Internet Service Provider = Internet Dienstanbieter) betreibt mindestens neun lokale DNS-Server um Anfragen ihrer Kunden zu beantworten.
Selbst in jedem DSL-Router befindet sich ein DNS-Server, der zum Einen für die Computer im eigenen, lokalen Netz zuständig ist, zum Anderen Anfragen aus dem lokalen Netz an die nächst höhere DNS-Instanz, z.B. zum DNS-Server des ISP weiterleitet und die Antwort empfängt.
Das Gegenstück zu den DNS-Servern ist der DNS-Client oder Resolver, der lokal auf dem Rechner läuft. Der Resolver ist der Mittler zwischen dem DNS und dem Anwendungsprogramm, z.B. einem Browser.

Ablauf der Namensauflösung

Grundsätzlich wird zwischen der rekursiven und der iterativen Namensauflösung unterschieden.
Wird in einem Programm auf dem lokalen Computer ein DNS-Domänenname verwendet., wird die Abfrage zunächst an den DNS-Clientdienst (Resolver) weitergeleitet, um eine Auflösung mithilfe lokal zwischengespeicherter Daten durchzuführen. Wenn der abgefragte Name aufgelöst werden kann, wird die Abfrage beantwortet, und der Prozess ist abgeschlossen. Der lokale Auflösungscache kann Namensdaten enthalten, die aus zwei möglichen Quellen stammen:

  • Wenn eine "hosts"-Datei lokal konfiguriert wurde, werden beim Starten des DNS-Clientdienstes alle Zuordnungen von Namen zu Adressen aus dieser Datei in den Cache geladen.
  • Ressourceneinträge, die in Antworten aus vorherigen DNS-Abfragen enthalten sind, werden dem Cache hinzugefügt und für eine bestimmte Zeit gespeichert.

Wenn für die Abfrage kein passender Eintrag im Cache vorhanden ist, wird der Auflösungsprozess fortgesetzt, indem der Client zum Auflösen des Namens den "bevorzugten DNS-Server" abfragt. Die Adresse des "bevorzugten DNS-Servers" erhält der Client entweder manuell vom Netzwerkadministrator in die Netzwerkkonfiguration eingetragen oder automatisch zusammen mit der dynamischen IP-Adresse wenn sich der Computer beim ISP anmeldet.
Wenn ein DNS-Server eine Abfrage empfängt, überprüft er zunächst, ob er die Abfrage auf der Grundlage von Ressourceneinträgen, die in einer lokal konfigurierten Zone auf dem Server enthalten sind, vollständig beantworten kann. Entspricht der abgefragte Name einem entsprechenden Ressourceneintrag in den lokalen Zonendaten, antwortet der Server, indem er diese Daten zum Auflösen des abgefragten Namens verwendet.
Stehen für den abgefragten Namen keine Zonendaten zur Verfügung, überprüft der Server als Nächstes, ob er den Namen mithilfe lokal zwischengespeicherter Daten aus vorherigen Abfragen auflösen kann. Wird hier eine Entsprechung gefunden, antwortet der Server mit diesen Daten. Auch in diesem Fall ist die Abfrage abgeschlossen, wenn der bevorzugte Server mit einer entsprechenden Antwort aus dem Cache auf den anfragenden Client reagieren kann.

Abb. 3.11: Rekursive DNS-Abfrage
Abb. 3.11: Rekursive DNS-Abfrage
Rekursive DNS-Abfrage

Wird auf dem bevorzugten Server weder in den Daten des Caches noch in den Zonendaten eine entsprechende Antwort für den abgefragten Namen gefunden, kann der Abfragevorgang fortgesetzt werden, indem der Name mit einem Rekursionsprozess vollständig aufgelöst wird. Für diese Art der Namensauflösung werden weitere DNS-Server zur Unterstützung herangezogen. Standardmäßig wird der Server vom DNS-Clientdienst aufgefordert, einen Rekursionsprozess zu verwenden, um vor dem Antworten die Namen für den Client vollständig aufzulösen.

Iterative Abfrage

Eine Iterative DNS-Abfrage findet statt, wenn der Client das Verwenden der Rekursion anfordert, aber die Rekursion auf dem DNS-Server deaktiviert ist oder der Client beim Abfragen des DNS-Servers das Verwenden der Rekursion nicht anfordert.
Die iterative Abfrage an den DNS-Server liefert nur die Adresse des nächsten abzufragenden DNS-Servers zurück. Der Resolver muss sich dann um die weiteren Anfragen kümmern, bis der Domain-Name vollständig aufgelöst ist.

 

3.4.3.FTP

Das File Transfer Protocol (engl. für "Dateiübertragungsverfahren", kurz FTP), ist ein Netzwerkprotokoll zur Dateiübertragung über TCP/IP-Netzwerke. Es wird benutzt, um Dateien vom Server zum Client (Download ), vom Client zum Server ( Upload) oder clientgesteuert zwischen zwei Servern zu übertragen. FTP nutzt zur Kommunikation mehr als eine Verbindung: Zunächst wird zum Port 21 des Servers, dem Control Port, eine Verbindung zur Authentifizierung und Befehlsübertragung aufgebaut. Hier reagiert der Server auf jeden Befehl des Clients mit einem Statuscode, oft mit einem angehängten, erklärenden Text. Zur eigentlichen Datenübertragung wird dann im Bedarfsfall eine separate Verbindung initiiert. FTP kennt dazu zwei Modi:

Abb. 3.12: FTP-Verbindungen
Abb. 3.12: FTP-Verbindungen

Beim Active Mode baut der Client von einem unprivilegierten Port N (normalerweise ein Port > 1023) eine Datenverbindung zum Kontroll-Port 21 des FTP-Servers auf. Dann spezifiziert der Client den Port N+1 als Datenport. Der Server schickt seine Daten an den spezifizierten Port des Client von seinem Port 20 aus.
Die Kommunikation mit Befehlen erfolgt auf dem Port 21. Man spricht auch von der Steuerung "Out of Band" (= außerband). Somit bleibt es möglich, dass während der Übertragung von Daten die Partner noch immer miteinander kommunizieren können.
Beim Passive Mode baut der Client von einem beliebigen unprivilegierten Port eine Datenverbindung zum Kontroll-Port 21 des Servers auf. Der FTP-Server gibt dem Client daraufhin über den Kontroll-Port einen freien unprivilegierten Port zur Datenübertragung bekannt. Nun baut der Client wiederum von einem eigenen Port der eins (N + 1) über dem Kontroll-Port liegt, zum Datenport des FTP-Servers eine Verbindung zum Datenaustausch auf.
Diese Technik wird eingesetzt, wenn der Client z.B. hinter einem Router sitzt, da ihm nicht eindeutig eine IP-Adresse zugeordnet werden kann.

Die gesamte Kommunikation beim Verbindungsaufbau zwischen Client und FTP-Server und auch die Übertragung der Nutzdaten findet bei FTP völlig unverschlüsselt statt. Eine FTP-Übertragung kann somit durch einfaches Mithören kompromittiert werden. In Verbindung mit dem SSL-Protokoll führt das FTPS-Protokoll zumindest den Verbindungsaufbau verschlüsselt durch. Dadurch wird das Mithören erschwert.

 

3.4.4. HTTP

Das Hypertext Transfer Protocol (HTTP) wird hauptsächlich im Rahmen des World Wide Web zur Übertragung von Webseiten verwendet (Web-Browser greifen fast ausschließlich mit diesem Protokoll auf Web- Server zu). Durch Erweiterung seiner Anfragemethoden, Headerinformationen und Fehlercodes ist es allerdings nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet.
Das Protokoll wurde 1989 von Tim Berners-Lee am CERN zusammen mit dem URL und HTML entwickelt und bildet eines der Kernbestandteile des World Wide Web. HTTP ist ein Kommunikationsschema, um Webseiten (oder Bilder oder prinzipiell jede andere beliebige Datei) von einem entfernten Computer auf den eigenen zu übertragen.
Wenn auf einer Webseite der Link (oder URL) www.example.net:80/infotext.html angeklickt wird, so wird an den Computer mit dem Namen www.example.net die Anfrage gerichtet, die Datei infotext.html zurückzusenden. Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse umgesetzt. Zur Übertragung wird über das TCP-Protokoll auf Port 80 eine HTTP-GET Anforderung gesendet. Zusätzliche Informationen wie Angaben über den Browser, gewünschte Sprache etc. können über einen Header in jeder HTTP-Kommunikation übertragen
werden. Sobald der Header mit einer Leerzeile abgeschlossen wird, sendet dann der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Diese besteht aus Headerinformationen des Servers, einer Leerzeile und dem Inhalt der Datei infotext.html. Die Datei ist normalerweise im Hypertext-Format HTML, das vom Browser in eine lesbare und ansprechende Darstellung gebracht wird. Es kann jedoch jede andere Datei in jedem beliebigen Format sein, zum Beispiel Bildinformationen, Audio- und Videodateien.

 

3.4.5 NTP (Network Time Protocol)

Das Network Time Protocol (NTP) ist ein Standard zur Synchronisierung von Uhren in Computersystemen über paketbasierte Kommunikationsnetze. NTP verwendet das verbindungslose Transportprotokoll UDP. Die Zeitstempel im NTP sind 64 Bits lang. 32 Bits kodieren die Sekunden seit dem 1. Januar 1900 00:00:00 Uhr, weitere 32 Bits den Sekundenbruchteil. Auf diese Weise lässt sich ein Zeitraum von 232 Sekunden (etwa 136 Jahre) mit einer Auflösung von 2−32 Sekunden (etwa 0,23 Nanosekunden) darstellen.
Der NTP-Dienst auf einem Server oder Host synchronisiert die lokale Uhr mit Hilfe von externen Zeitsignalen, die er entweder direkt von einer lokalen Atomuhr (Caesium-Uhr, Rubidium-Uhr usw.) oder einem lokalen Funkempfänger (DCF77, GPS), oder selbst per NTP von einem NTP-Server (z. B. time.microsoft.com,  de.pool.ntp.org,  ptbtime1.ptb.de (Physikalisch-Technische Bundesanstalt)) erhält. In manchen Betriebssystemen (z.B. Unix, Linux, Windows ab XP/Server2003) korrigiert der NTP-Dienst, damit die lokale Uhrzeit nicht nur zu den zyklischen Synchronisationszeitpunkten präzise mit dem externen Signal übereinstimmt, nicht nur die Phase, sondern auch die Frequenz des lokalen Zeitgebers mit Hilfe einer Software-PLL im Betriebssystem-Kernel.

 

Abb. 3.14: Synchronisation der Systemzeit mit NTP unter Windows 7
Abb. 3.14: Synchronisation der Systemzeit mit NTP unter Windows 7

 

 

3.4.6. POP3 (Post Office Protocol Version 3)

POP3 ist ein Übertragungsprotokoll, über welches ein Client E-Mails von einem E- Mail-Server abholen kann. POP3 ist ein ASCII-Protokoll, wobei die Steuerung der Datenübertragung durch Kommandos geschieht, die standardmäßig an den Port 110 geschickt werden. Eine ständige Verbindung zum Mailserver ist bei POP3 nicht notwendig. Die Verbindung wird bei Bedarf vom Client zum Server erzeugt und danach wieder beendet. POP3 ist in der Funktionalität sehr beschränkt und erlaubt nur das Abholen und Löschen von E-Mails am E-Mail-Server. Für weitere Funktionalitäten wie hierarchische Mailboxen direkt am Mailserver, Zugriff auf mehrere Mailboxen während einer Sitzung, Vorselektion der E-Mails, usw. müssen Protokolle wie IMAP verwendet werden.
Als Gegenstück zu POP3 zum Versenden von E-Mails ist üblicherweise in Clients und Servern das SMTP-, bzw. ESMTP-Protokoll implementiert.

3.4.7. RTCP (Real-Time Control Protocol)

Das Real-Time Control Protocol (RTCP) ist ein Protokoll zur Außerband-Übertragung von statistischen und Kontrollinformationen über einen RTP-Datenstrom. RTCP arbeitet mit RTP und RTSP zusammen, überträgt aber keine multimedialen Daten.
Die Aufgabe von RTCP ist die Rückmeldung von Information über die Verbindungsqualität (QoS = Quality of Service)einer (Multi-) Mediaübertragung. RTCP sammelt Informationen über die übertragene Datenmenge, Anzahl der übertragenen Pakete,  Anzahl der verlorengegangenen Pakete, Jitter und Laufzeiten und überträgt sie periodisch an die Mediaquelle und weitere Teilnehmer. Entsprechende Anwendungen können  somit Dienstparameter wie Bandbreite des Streams oder das Kodierverfahren (Codec) an die Bedürfnisse anpassen. 

3.4.8. RTMP (Real Time Messaging Protocol)

Das Real Time Messaging Protocol (RTMP) ist ursprünglich ein von Macromedia entwickeltes proprietäres Multimedia-Streaming-Protokoll. Es wird verwendet um Daten von einem Mediaserver zu einem Flash-Player zu übertragen. Nachdem Macromedia von Adobe Systems übernommen wurde, wurden 2009 die Spezifikationen des Protokolls offengelegt.
Das RTMP-Protokoll hat mehrere Varianten:

  1. Das "normale" RTMP arbeitet auf TCP und verwendet Port 1935
  2. RTMPS ("secure" = sicher) ist RTMP über eine sichere SSL-Verbindung über HTTPS
  3. RTMPE ("encrypted" = verschlüsselt) ist RTMP mit einer Adobe-eigenen Verschlüsselung, die allerdings sehr schwach ist.
  4. RTMPT ("tunneling" = tunneln) wird in HTTP-Requests eingebettet um Firewalls durchdringen zu können. RTMPT verwendet Requests im Klartext auf TCP-Ports 80 und 443 um die Filterung zu umgehen. In der eingebetteten Session werden normale RTMP-, RTMPS- oder RTMPE-Pakete übertragen.

RTMP ist ein auf TCP beruhendes Protokoll, das permanente Verbindungen aufbaut und sich durch kurze Latenzzeiten auszeichnet. In einer Verbindung werden mehrere virtuelle Kanäle geöffnet, die völlig unabhängig voneinander sind. So gibt es Kanäle für Audio und Video, Kanäle um entferne Prozesse aufzurufen oder Datenraten auszuhandeln. Um einen gleichmäßigen Datenfluss zu erlangen, wird der Stream in Fragmente aufgeteilt, deren Größe dynamisch zwischen Client (Flash-Player) und dem Server ausgehandelt werden. Die Defaultgrößen sind 64 Byte für Audiostream und 128 Byte für Videostreams.
Ein spezieller Paket-Header enthält Informationen wie Kanal-ID, wenn nötig einen Zeitstempel und die Größe der Nutzdaten im Paket. Der Header ist in zwei Bereiche unterteilt: den Basic Header und den Chunk Message Header.
Der Basic Header ist nur ein Byte lang Die ersten beiden Bits sind der Chunk Type (FMT), der Rest bilden die Stream ID. Bei Bedarf kann der Basic Header um zwei Byte auf drei Byte erweitert werden.

Abb. 3.15: Struktur des RTMP-Header
Abb. 3.15: Struktur des RTMP-Header
Der Chunk Header Type (FMT) gibt die Länge des ganzen RTMP-Headers an:
  00 = 12 Bytes (Vollständiger Header
01 =   8 Bytes - wie Typ 00, nur ohne Message Stream ID
10 =   4 Bytes - Basic Header und Timestamp (3 Bytes)
11 =   1 Byte - nur Basic Header
 
Byte 9 "Message Type ID" beschreibt den Inhalt des Pakets:
  0x01 = "Setze Paketgröße"-Nachricht
0x04 = Ping-Nachricht
0x05 = Server Bandbreite
0x06 = Client Bandbreite
0x08 = Audio Paket
0x09 = Video Paket
0x11 = Ein AMF3 Befehl
0x12 = Invoke-Nachricht (einfache Steuerfehle)
0x14 = Ein AMF0 Befehl

 

3.4.9. RTP (Real-Time Transport Protocol)

Das Real-Time Transport Protocol (RTP) ist ein Protokoll zur kontinuierlichen Übertragung von echtzeitsensitiven Daten wie audiovisuellen Streams. RTP ist ein paketbasiertes Protokoll und wird normalerweise über UDP betrieben. Es findet Anwendung in vielen Bereichen, u.a. wird es bei den IP-Telefonie-Technologien H.323 und SIP dazu verwendet die Audio-/Videoströme des Gespräches zu übertragen.

Der RTP-Standard definiert den gepaarten Einsatz von RTP mit RTCP, wobei nur die Multimedia-Daten ausschließlich per RTP übertragen werden.

Abb. 3.16: Aufbau des RTP-Headers
Abb. 3.16: Aufbau des RTP-Headers
Feld Länge Funktion
Version (V) 2 Bit Version des RTP-Protokolls
Padding (P) 1 Bit Füllbit
Extentions (X) 1 Bit Wird gesetzt, wenn der Header eine Erweiterung (Extention) hat.
CSRC Count (CC) 4 Bit Der CSRC-Zähler gibt die Anzahl der CSRC-Identifier an
Marker (M) 1 Bit Markiert anwendungsspezifische Ereignisse
Payload Type (PT) 7 Bit Dieses Feld beschreibt das Format des zu transportierenden RTP-Inhalts, also der Nutzdaten. Beispiele:
  Payload-Nr. Codec Audio/
Video
Samples/s Audio-
Kanäle
0
3
15
18
26
31
33
34
PCMU
GSM
G728
Q729
JPEG
H261
MP2T
H263
A
A
A
A
V
V
AV
V
8000
8000
16000
8000
90000
90000
90000
90000
1
1
1
1
-
-
1
-
Sequence Number 16 Bit Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen.
Timestamp 32 Bit Der Zeitstempel gibt den Zeitpunkt des ersten Oktetts des RTP-Datenpakets an. Der Zeitpunkt muss sich an einem Takt orientieren, der kontinuierlich und linear ist, damit die Synchronität des Streams sichergestellt und Laufzeitunterschiede der Übertragungsstrecke (Jitter) ermittelt werden können. Der Startwert sollte wie die Sequenznummer ein zufälliger Wert sein. Aufeinanderfolgende Pakete können den gleichen Zeitstempel haben, wenn die transportierten Daten z. B. zum selben Videoframe gehören.
SSRC 32 Bit Das Feld Synchronization Source Identifier dient zur Identifikation der Synchronisationsquelle.
CSRC 0-15 Felder á 32 Bit Die Contributing Source Identifier-Liste dient zur Identifikation der Quellen, die im RTP-Payload enthalten sind. Die Anzahl der Listenfelder wird im CC-Feld angegeben. Falls mehr als 15 Quellen vorkommen, werden nur 15 identifiziert. Die Liste wird von Mixern eingefügt, die dazu den Inhalt des SSRC-Feldes der beteiligten Quellen einsetzen.
Extention Header   Optionale Erweiterung des Headers
Tabelle 1: Struktur des RTP-Headers
 

3.4.10 RTSP

Das Real-Time Streaming Protocol ist ein Netzwerkprotokoll zur Steuerung der kontinuierlichen Übertragung von audiovisuellen Daten (Streams) über IP-basierte Netzwerke. Mit ihm wird die Session zwischen Empfänger und Server gesteuert. Es basiert auf HTTP. Das Protokoll wurde von der IETF MMUSIC Group entwickelt. Während in der Praxis meistens das Real- Time Transport Protocol (RTP) oder UDP zur Übertragung echtzeitsensitiver Daten dient (RTSP ist protokollunabhängig), besteht die Funktion von RTSP hauptsächlich in der Steuerung der Datenströme; über RTSP selbst werden keine Nutzdaten übertragen, daher wird RTSP gelegentlich auch als »Netzwerk-Fernbedienung« bezeichnet. Die Überwachung der Übertragung erfolgt durch das Real-Time Control Protocol.
RTSP ist für multimediale Datenströme etwa das, was HTTP für HTML-Dokumente ist; im Gegensatz zu HTTP kennt RTSP jedoch Zustände und ist bidirektional, das heißt, sowohl Client als auch Server können Anfragen absetzen. Ansonsten werden in RTSP wie auch bei HTTP die Nachrichten in Request (zum Initialisieren einer Sitzung) und Response (zur Beantwortung der Anfrage durch eine Statusmeldung) aufgeteilt.

3.4.11 SIP

Das Session Initiation Protocol ist ein Netzprotokoll zum Aufbau einer Kommunikationssitzung zwischen zwei und mehr Teilnehmern. Das SIP-Protokoll wird unter anderem beim Internettelefon (VoIP = Voice over IP) eingesetzt. Eine detaillierte Beschreibung des Verbindungsaufbaus unter SIP ist hier zu finden.

3.4.12 SMTP

SMTP steht für Simple Mail Transfer Protocol und ist ein Protokoll das den Versand von E-Mails in Computer-Netzwerken regelt. Der SMTP-Server belegt in der Regel den dafür registrierten Port 25. Ein Benutzer wird zumeist vom Ablauf des SMTP-Protokolls nichts mitbekommen, da dies sein Mailprogramm im Hintergrund für ihn erledigt. Dieses Programm verbindet sich zu einem SMTP-Server (MTA), der die Mail zum Empfänger weiterleitet. SMTP setzt voraus, dass eine Übertragung vom Sender initiiert wird, aus diesem Grund wird es nicht dazu benutzt eine Mail von einem Server auf den Arbeitsplatzrechner zu übertragen. Dazu werden Post Office Protokolle wie das POP3-Protokoll, das IMAP-Protokoll oder andere verwendet.

3.4.13 SSH (Secure Shell)

SSH ist sowohl ein Programm als auch ein Netzwerkprotokoll, mit dessen Hilfe man sich auf einem entfernten Computer einloggen und dort Programme ausführen kann. SSH ermöglicht eine sichere, authentifizierte und verschlüsselte Verbindung zwischen zwei Rechnern über ein unsicheres Netzwerk.

3.4.14 STUN

STUN (STUN = Session Traversal Utilities for NAT = Werkzeuge zum Durchqueren von NATs) ist ein Dienst, der von VoIP-Telefonen benötigt wird, wenn sie sich hinter Routern befinden. Über STUN erfahren sie ihre öffentliche IP-Adresse. STUN-Server werden von den Internet Service Providern betrieben, wenn VoIP im Netz gestattet ist.

 

Referenzen

Abbildungen

[2] Abb. 3.10: "Ablauf der Zuweisung einer IP-Adresse per DHCP"; Lizenz: Creative Commons (BY-NC-SA 4.0)
Quelle: Skripte Prof. Jürgen Plate FH München (http://www.netzmafia.de/skripten/netze/)

Rechtshinweis

Sofern auf dieser Seite markenrechtlich geschützte Begriffe, geschützte (Wort- und/oder Bild-) Marken oder geschützte Produktnamen genannt werden, weisen wir ausdrücklich darauf hin, dass die Nennung dieser Marken, Namen und Begriffe hier ausschließlich der redaktionellen Beschreibung bzw. der Identifikation der genannten Produkte und/oder Hersteller bzw. der beschriebenen Technologien dienen.

Alle Rechte an den in diesem Kompendium erwähnten geschützten Marken- und/oder Produktnamen sind Eigentum der jeweiligen Rechteinhaber und werden hiermit ausdrücklich anerkannt. Alle in unseren Artikeln genannten und ggfs. durch Dritte geschützte Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts sowie den Besitzrechten der jeweiligen eingetragenen Eigentümer.

Die Nennung von Produktnamen, Produkten und/oder der jeweiligen Produkthersteller dient ausschließlich Informationszwecken und stellt keine Werbung dar. InfoTip übernimmt hinsichtlich der Auswahl, Leistung oder Verwendbarkeit dieser Produkte keine Gewähr.

Sollten dennoch wider unserer Absicht Rechte Dritter verletzt werden, so bitten wir um eine Benachrichtigung ohne Kostennote.