Intro

HighGames ist eine große Datenbank mit Informationen zu PC-Spielen und Hardware. Helfen Sie mit, und senden Sie Ihre eigenen Erfahrungen.

Weitere Informationen

Auf diesen Hardware-Guide zu Netzwerktechnologie TCP/IP von www.HighGames.com sind Sie durch Klick auf den Packshot gekommen.
Viel Spaß beim Lesen!

Hardware-View: Netzwerktechnologie TCP/IP

Netzwerktechnologie TCP/IP

Titel: Netzwerktechnologie TCP/IP
Thema: Netzwerktechnologien
Zielgruppe: Fortgeschrittene
Artikelversion: 1.10
Zurück

Hinweis: Für die Korrektheit oder Aktualität der Informationen kann nicht garantiert werden. Der Autor übernimmt daher keine Haftung für Schäden, die durch Nutzung der Informationen entstanden sind.

In diesem Artikel soll der Protokollkomplex Hardware-Glossar: TCP/Hardware-Glossar: IP beschrieben werden. Neben Informationen zur Protokollfamilie selbst, sollen Einführungen zu weiteren wichtigen Komponenten, wie dem Hardware-Glossar: OSI-Referenzmodell und den RFC-Dokumenten gegeben werden. Der Artikel stellt keinesfalls eine ausführliche Abhandlung des Themas dar, er soll die wichtigsten Informationen vielmehr zusammenfassen und strukturiert wiedergeben. Informationen zu den einzelnen Protokollen können Sie unserem Glossar entnehmen.


Die TCP/IP-Protokollfamilie

Der Terminus TCP/IP bezeichnet zunächst zwei Protokolle: Das Transmission Control Protocol (TCP) und das Internet Protocol (IP). Diese beiden Protokolle sind jedoch nur ein Teil einer weitaus größeren Protokollsammlung, der TCP/IP-Protokollfamilie. TCP/IP ist heute und vermutlich auch in ferner Zukunft die Standardmethode zur systemübergreifenden Datenkommunikation. Sie ermöglicht das Verbinden unterschiedlicher Betriebssysteme und Netzwerkkomponenten. Hierzu bietet sie Protokolle, die den meisten Diensten ihre Datenkommunikation ermöglichen. Solche Dienste sind beispielsweise:

- E-Mail-Verkehr
- Dateitransfers
- Nachrichten-Dienste
- Zugriff auf das WWW


Die Geschichte von TCP/IP

Wir befinden uns im Jahre 1969. Der zweite Weltkrieg ist bereits lange vorbei, an dessen stelle tritt der alte neue Ost-West-Konflikt, vorwiegend geprägt durch die beiden Hegemonialmächte Amerika und die Sowjetunion. Zu jener Zeit war an ein Internet, wie wir es heute kennen, nur schwer zu denken. Jedenfalls an dessen Realisierung. Netzwerktechnologien waren dürftig, teuer und grundsätzlich kaum vorhanden. Die DARPA (Defense Advanced Research Projects Agency, US-amerikanische Behörde für Forschungsprojekte im Verteidigungsbereich) gab schließlich die Entwicklung eines Netzwerkes für ihre Forschungszentren in Auftrag. Vielleicht sollte man es trefflicher als Wettstreit verschiedener Softwarehersteller bezeichnen, denn der enorme Zeitdruck zu jener Zeit und das bemerkenswert hohe Honorar durch die USA trieben Firmen und Universitäten gleichermaßen an, neueste Methoden für die systemübergreifende Datenkommunikation und analog hierzu passende Datenbeschreibungsmodelle zu entwickeln. Als wichtigste Anforderung an das Netzwerk stellte die DARPA eine Garantie, dass es einen atomaren Anschlag, beispielsweise durch die Sowjetunion, unbeschadet überstehen könne. Eine weitere wichtige Anforderung war, das Netzwerk dezentral betreiben zu können. Nach wenigen Monaten (teilweise gemeinsamer) Forschungsarbeit, entstand nun der Prototyp des vermutlich teuersten Netzwerksystem aller Zeiten, das „ARPANET“. Am Rande sei bemerkt, dass die hierfür betriebenen Analyse- und Forschungsarbeiten heute eher als adaptiv zu denjenigen Ergebnissen bezeichnet werden, welche bereits in den Jahren 1962 und 1963 verzeichnet wurden. Das ARPANET arbeitete prinzipiell zufrieden stellend. Es erwies sich über einen längeren Zeitraum jedoch als zu kostenintensiv in Implementierung, Wartung und Weiterentwicklung. Zudem brach das System regelmäßig zusammen. Hauptsächlich aus diesen Gründen wurde bis Ende der Siebziger ein zuverlässigeres und vor allem günstigeres System entwickelt: Die TCP/IP-Protokollfamilie. Durch das schlanke Design und die vergleichsweise simple Wartung gewann TCP/IP zunehmend an Beliebtheit. 1983 war es bereits fester Bestandteil einiger Unix-Distributionen, beispielsweise der Berkeley Software Distribution („BSD Unix“) ab der Version 4.2. Die Implementierung in kommerzielle Unix-Ausprägungen folgte sehr bald. Auch Microsofts späte DOS-Versionen und frühe Windows-Versionen implementieren TCP/IP in Form von WATTCP/WATT-32 und KA9Q. TCP/IP etablierte sich als Standard für die systemübergreifende Datenkommunikation - und blieb dies bis heute.


Das OSI-Referenzmodell

Die Entwicklung der TCP/IP-Protokollfamilie, die generelle Entwicklung von Netzwerktechnologien an sich, fordert ein gemeinsames Modell zur Beschreibung dieser Technologien. Auch wenn bislang diverse unterschiedliche Modelle vorhanden waren, so erwiesen sich diese oftmals als nicht abhängig, systemübergreifend oder schlichtweg plausibel genug. Ende der 1970er schließlich wurde das OSI-Referenzmodell (Open Systems Interconnection, Verbindung offener Systeme) entwickelt. Dieses Modell hatte und hat von Vorteil, dass die zu beschreibende Netzwerktechnologie über verschiedene, aufeinander liegende und miteinander kommunizierende Schichten komfortabel eingeordnet und erläutert werden kann. Das OSI-Modell hat sich heute als ein Standardisierungsvehikel zur Beschreibung unterschiedlichster Netzwerksysteme bzw. -technologien etabliert. Es besteht aus insgesamt sieben Schichten. Die Schichten liegen aufeinander und können mit der jeweils benachbarten Schicht kommunizieren. Sie repräsentieren die Architektur für unterschiedliche Datenkommunikationsprotokolle, dabei bezeichnet jede Schicht im OSI-Modell eine bestimmte Netzwerkfunktion. Das Modell besteht aus folgenden Schichten:

Schicht 7: Anwendungsschicht
Die Anwendungsschicht ist die oberste Schicht des OSI-Modells. Sie legt fest, wie Anwendungen systemübergreifend durch das Netzwerk interagieren. Protokolle: Hardware-Glossar: HTTP, Hardware-Glossar: FTP, Hardware-Glossar: SMTP, Hardware-Glossar: POP3, X-Window uvm.

Schicht 6: Darstellungsschicht
Protokolle dieser Schicht sind in der Regel Bestandteil des Betriebssystems. Sie legen fest, wie Daten für die Anzeige formatiert werden. Die Datenkryptographie und -übersetzung finden hier unter anderem statt. Protokolle lassen sich nicht eindeutig der Darstellungsschicht zuordnen, da hierfür geeignete meistens ebenso Aufgaben übernehmen, welche Protokollen der Anwendungsschicht vorbehalten sind.

Schicht 5: Sitzungsschicht
Die Sitzungsschicht koordiniert die Kommunikation zwischen den Endpunkten. Unter anderem wird hier der Sitzungsstatus (wichtig für Protokollierungs- und Administratorfunktionen) eingerichtet und aufrechterhalten. Protokolle: Hardware-Glossar: DNS, LDAP, BGMP, NetBIOS/IP uvm.

Schicht 4: Transportschicht
Die Transportschicht steuert den systemübergreifenden Datenfluss und definiert die Struktur von Daten in Meldungen. Komplexe Fehlerprüfungen werden in dieser Schicht ebenfalls durchgeführt. Protokolle: TCP, Hardware-Glossar: UDP, ISTP uvm.

Schicht 3: Netzwerk- oder Vermittlungsschicht
Hauptsächlich findet in dieser Schicht die Endpunktadressierung statt. Es wird sichergestellt, dass die Daten am gewünschtem Ort ankommen. Protokolle der Netzwerkschicht legen das systemübergreifende Datenrouting fest. Protokolle: Hardware-Glossar: DHCP, IP, IPv6, Hardware-Glossar: ICMP, ICMPv6 uvm.

Schicht 2: Sicherungsschicht
Protokolle der Sicherungsschicht beschreiben die Regeln für die Übertragung von Daten zwischen den Netzwerkknoten. Protokolle: ARP, RARP, DCAP

Schicht 1: Physikalische Schicht oder Bitübertragungsschicht
Die physikalische Schicht bestimmt die Hardwareverbindungen und die Kodierung des Datenstroms zur Übertragung. Daten werden hier quasi endgültig in das Netzwerk gesendet. Es ist die einzige Schicht dieser Art im OSI-Modell. Protokolle: Hardware-Glossar: Ethernet, Token Ring, FDDI

TCP/IP ist älter als das OSI-Referenzmodell. Es lässt sich zwar mit dessen Schichten beschreiben, relevant sind hierzu jedoch nicht alle. Für die Beschreibung von TCP/IP sind die Anwendungs-, die Transport-, die Netzwerk- und die Sicherungsschicht die wichtigsten.

Analog zum OSI-Modell lassen sich die Protokolle in zwei unterschiedliche Typen unterteilen.


Netzwerkprotokolle

Netzwerkprotokolle dienen zur Verwaltung von Datenübertragungsmechanismen. Sie umfassen die Protokolle der physikalischen Schicht bis einschließlich derjenigen der Transportschicht. Aktivitäten dieser Protokolle sind in der Regel vor dem Anwender verborgen, es sei denn, er verwendet bestimmte Programme, die den Datenverkehr abhören können, beispielsweise Sniffer, wie Tcpdump und Windump.


Anwendungsprotokolle

Anders als Netzwerkprotokolle, sind Anwendungsprotokolle durchaus für den Anwender sichtbar. Beim HTTP-Protokoll beispielsweise werden die Ergebnisse der Datenkommunikation in dem Moment sichtbar, in dem sie stattfinden. Es ist ein so genanntes „interaktives Protokoll“. Zu den Anwendungsprotokollen gehören die Protokolle aus den Schichten fünf bis sieben.


Funktionsweise von TCP/IP

Mit dem OSI-Modell lässt sich die Funktionsweise von TCP/IP vorzüglich erklären. TCP/IP arbeitet, analog zum OSI-Modell, mit einem Protokollstapel. Dieser Stapel stellt die Summe aller Protokolle dar, die zur Übertragung von Daten zwischen den Rechnern benötigt werden. Gleichzeitig wird der Weg beschrieben, den die Daten aus dem einem Rechner hinaus und in den anderen hinein nehmen. Im Folgenden soll ein regulärer Fortgang von Daten aus einem Netzwerkrechner textuell dargestellt werden.

Rechner initiiert Datentransfer:

- Anwendungsschicht
Leitet die Anforderung an die Transportschicht weiter.

- Transportschicht
Fügt den Daten einen Header hinzu; Weiterleitung an die Vermittlungsschicht. (Die Daten werden in Form von Paketen gesendet. Jedes Paket erhält einen Header)

- Vermittlungsschicht
Fügt dem Header die IP-Ursprungs- und -Zieladresse hinzu; Weiterleitung an die Sicherungsschicht.

- Sicherungsschicht
Komplexe Fehlerprüfungen werden am Datenstrom vorgenommen; Weiterleitung an die physikalische Schicht.

- Physikalische Schicht
Überträgt die Daten über das Übertragungsmedium (z.B. Ethernet oder Moden usw.)

Beachten Sie, dass dieser Ablauf nur sehr schemenhaft dargestellt ist, denn in Wirklichkeit werden unzählige Arbeitsschritte durchgeführt, deren Aufzählung den Rahmen dieses Artikels sprengen würden. Sind die Daten am Zielort angekommen, wandern sie den Stapel in umgekehrter Folge ab. Die Daten werden dabei Schicht für Schicht wieder „ausgepackt“. Der Vorgang ist vergleichbar mit einem zu versendenden Brief: Der Absender, also Initiator, hat seine Daten in Form eines beschrifteten Papiers. Dieses kommt in einen Briefumschlag mit wichtigen Informationen bezüglich des Absenders und Empfängers. Diese Informationen sind vergleichbar mit dem Header eines Datenpaketes, denn der Header beinhaltet in der Regel Grundinformationen, wie Ursprungs- und Zielport und Ursprungs- und Ziel-Hardware-Glossar: IP-Adresse. Der Brief kann mithilfe dieser Informationen weitergeleitet werden. Ist er angekommen, wird er wieder ausgepackt, und zwar (im Idealfall) von dem Empfänger. Dieser kann die Daten nun lesen bzw. verwerten.


Die RFC-Dokumente

Die Protokolle der TCP/IP-Protokollfamilie werden in der Regel in Dokumenten definiert, die als RFCs (Request for Comments, Grundlagenpapiere) bezeichnet werden. Jeder kann RFCs verfassen und vorschlagen, ferner editieren und kommentieren. Der Vorgang zur Billigung von RFCs wird durch die IESG (Internet Engineering Steering Group, Steuergruppe für Internettechnologien) verwaltet. Dies geschieht auf Basis von Empfehlungen, die von der IETF (Internet Engineering Task Force) ausgesprochen werden. Die IETF ist in erster Linie für die Bildung von Arbeitsgruppen zuständig, die sich mit unterschiedlichen, vorwiegend strategischen Aspekten von TCP/IP beschäftigen. Solche Arbeitsgruppen setzen sich aus unterschiedlichen Personen mit unterschiedlichen Interessen am Internet zusammen. Sie stellen Entwürfe („Drafts“) vor, die dann in monatelangen Diskussion bearbeitet und eventuell zum Standard-RFC werden. An den Diskussionen kann jeder Interessierte, beispielsweise über Mailing-Listen, teilnehmen.

Wesentliche RFCs für die Definition von TCP/IP sind:
- RFC 768: UDP (User Datagram Protocol)
- RFC 791: IP (Internet Protocol)
- RFC 792: ICMP (Internet Control Message Protocol)
- RFC 793: TCP (Transmission Control Protocol)
- RFC 1122: Anforderungen an Internethosts – Kommunikationsebene
- RFC 1123: Anforderungen an Internethosts – Anwendung und Support

Umfassende Informationen zum Standardisierungsvorgang können Sie dem RFC 2026 entnehmen. Die IETF stellt des weiteren ein Archiv für RFC-Dokumente bereit, zu finden unter www.ietf.org/rfc.html.

Nicht alle RFCs legend Standards fest. Manche beinhalten Hintergrundinformationen, andere wiederum sind Dokumentationen oder auch Tipps zur Verwaltung von TCP/IP-Netzwerken. Und manch ein Dokument ist auch lediglich als Scherz gemeint.


Die Hardware-Glossar: SNA-Netzwerkarchitektur

SNA (Systems Network Architecture, Systemnetzwerk-Architektur) ist eine in den 1970ern von IBM entwickelte Netzwerkarchitektur. Vorgestellt wurde sie erstmals 1974. SNA wurde ursprünglich entwickelt, um eine einheitliche Kommunikationsbasis für IBM-Rechner zu schaffen. Heute wird es auch verwendet, um allgemeine Netzwerktechnologien und Datenkommunikationsprotokolle zu beschreiben. Dabei unterscheidet es sich oberflächlich nur geringfügig vom OSI-Modell. Das SNA-Modell bietet, gleich dem OSI-Modell, sieben Schichten zur Beschreibung. Diese Schichten sind:

- Schicht 7: Transaktionsdienste
- Schicht 6: Präsentationsdienste
- Schicht 5: Datenflussteuerung
- Schicht 4: Übertragungskontrolle
- Schicht 3: Pfadkontrolle
- Schicht 2: Sicherungskontrolle
- Schicht 1: Physikalische Schicht

SNA ist tatsächlich jedoch ein sehr komplexes und durchaus kompliziertes Modell. Hinter den sieben Schichten verbergen sich zahlreiche weitere Beschreibungskomponenten, beispielsweise die „Physical Units“ (Physikalische Einheiten) und die „Logical Units“ (Logische Einheiten). Im Vergleich zum OSI-Modell kommt es daher weniger zum Einsatz, OSI ist schlichtweg einfacher zu implementieren. Trotzdem haben bereits zahlreiche Softwarefirmen, kleine und größere, ihre Produkte SNA-kompatibel gestaltet.

Autor: Stefano Albrecht
Datum: 06.07.2006