dancecharts.at forums - Einzelnen Beitrag anzeigen

Webmaster · #9 29. April 2002, 20:40

Und hier dazu die Erklärung für FTP am Schluss

TCP/IP ist einer der typischen Begriffe, die in Verbindung mit Netzwerken immer wieder auftauchen, mit denen man allerdings wenig anfangen kann. Zunächst ist TCP/IP eine Abkürzung für TCP/IP eine Abkürzung für Transmission Control Protocol / Internet Protocol, was die Deutung allerdings auch nicht gerade vereinfacht. Es handelt sich hierbei nicht um ein einzelnes Protokoll sondern um eine Ansammlung von Protokollen, die im Verbund die gesamte Funktionalität des Internets zur Verfügung stellt.

(Quelle: Netzwerke von Guido Ehlert)

Adressierung im IP

Jeder Host im Netzwerk erhält eine eindeutige Adresse, die sogenannte IP-Adresse oder IP-Nummer. Das 'IP' in der Bezeichnung deutet darauf hin, dass hierfür das Internet Protocol zuständig ist.

In der aktuellen Version von TCP/IP wird jedem Rechner eine 32 Bit lange Adresse \index{IP-Adresse} zugeordnet, die der besseren Lesbarkeit halber in der Form xxx.xxx.xxx.xxx geschrieben wird. Hierbei werden die einzelnen Bytes durch Punkte getrennt. So sind IP-Adressen von 0.0.0.0 bis 255.255.255.255 möglich. Es sind nicht alle Nummern nutzbar, einige z.B. sind für die Netzadresse oder sogenannte Broadcasts reserviert.

Eine typische IP-Adresse könnte nun lauten

141.89.64.1

(ist in diesem Fall der Nameserver der Universität Potsdam). In Binärschreibweise wäre dies

10001101 1011001 1000000 00000001

Eine IP-Adresse gliedert sich nun in einen vorderen und einen hinteren Teil. Der vordere Teil stellt die Netzadresse dar, der hintere Teil die Host-Adresse. Die IP-Adresse bezeichnet das Netz, in dem sich ein Rechner befindet und seine Nummer in diesem Netz. Die Trennung dieser beiden Teile kann prinzipiell an jedem Bit der Adresse erfolgen. Dazu benötigt man aber noch die sogenannte Netzmaske. Diese Netzmaske ist genauso lang wie die IP-Adresse und wird bis zu einem bestimmten Bit mit Einsen gefüllt. Der Rest wird auf Null gesetzt. Alle Bits in der IP-Adresse, die in der Netzmaske belegt sind, zählen dann zum Netzanteil, der Rest zum Hostanteil.

Im ersten Beispiel verwenden wir als Netmask 255.255.0.0, d.h. die ersten 16 Bit der Adresse sind dem Netzteil vorbehalten, hier 141.89, die restlichen 16 Bit werden zur Adressierung des Hosts in diesem Netz verwendet, dazu bleiben 254*254, also gut 64.516 Möglichkeiten - praktisch können also über 64.000 Hosts in diesem Netz adressiert werden. Die Adresse 141.89.0.0 ist für das Netzwerk selbst reserviert, die Adresse 141.89.255.255 bezeichnet die sogenannte Broadcast-Adresse: Pakete an diese Adresse werden an alle Stationen im Netz verschickt.

Doch fahren wir mit unseren Beispielen fort. Unser Beispiel Nummer zwei beschreibt den Host 58.17.131.43 mit der Netmask 255.255.255.0. Hier sind also 24 Bit für den Netz- und 8 Bit für den Hostanteil reserviert. Theoretisch kann es in diesem Netz maximal 254 Hosts geben. Adresse für dieses Netzwerk ist 58.17.131.0, Broadcasts gehen an 58.17.131.0.

Das dritte Beispiel zeigt nun, dass man sich bei der Netzmaske keinesfalls auf ganze Bytes beschränken muss. Bei dieser Adresse macht der Netzanteil 20 Bit aus, der Hostanteil 12 Bit. Die Netzadresse ist hier 123.5.6.0 (bis zum 20. Bit), Broadcasts gehen an 123.5.112.255 (Alle Bits ab dem 21. sind auf 1 gesetzt).

Die verschiedenen Netzmasken lassen sich in verschiedene Klassen unterteilen: Class-A-Netz haben die Netmask 255.0.0.0, Class-B-Netze die Netmask 255.255.0.0 und Class-C-Netze die Netmask 255.255.255.0. Netze mit anderen Netmasks bezeichnet man als Subnetze. Möchte man Rechner im Internet betreiben, muss man dazu bei DeNIC (http://www.denic.de) entsprechend IP-Adressen beantragen.

IP - Das Internet Protocol

Das IP übernimmt die gesamte Paketvermittlung. Daten werden in gegebenenfalls mehrere IP-Pakete verpackt und an einen bestimmten Empfänger abgeschickt. Beim Empfänger können diese Pakete eventuell in falscher Reihenfolge ankommen. Das IP hat nun dafür zu sorgen, diese fragmentierten Pakete wieder ordentlich zusammenzusetzen.

Dabei arbeitet das Protokoll verbindungslos und ungesichert, d.h. vor dem Versenden der Pakete wird keine explizite Verbindung zum Empfänger hergestellt, sondern einfach abgeschickt. Es existieren auf IP-Ebene keine Sicherungsmechanismen, die sicher stellen, dass die Daten auch korrekt beim Empfänger ankommen. Dies ist auch gar nicht notwendig, denn das IP hat für die Vermittlung der Pakete zu sorgen, für die korrekte Übertragung sind die höheren Protokollschichten zuständig. Die weiter vorn beschriebene Adressierung in TCP/IP-Netzen wird ebenfalls durch das IP gehandhabt.

TCP - Transmission Control Protocol

Das Transmission Control Protocol ist im Gegensatz zu den bisher beschriebenen Protokollen ähnlich wie das Telefonnetz verbindungsorientiert aufgebaut. Bevor man also irgendwelche Daten per TCP an einen anderen Rechner senden kann, muss man eine Verbindung zu diesem aufgebaut haben. Da alle darunter liegenden Protokolle allerdings paketorientiert arbeiten, ist die Verbindung natürlich nur 'virtuell'. Durch diese festgelegte Verbindung können die zwei Verbindungspartner auch sicherstellen, dass die gesendeten Daten auch wirklich korrekt ankommen und zwar auch in der richtigen Reihenfolge und nicht doppelt. Dadurch ist es natürlich wesentlich komplexer aufgebaut als UDP, in der Regel gibt es in der Verbindung einen Client und einen Server. So verwenden auch die meisten Internetanwendungen TCP als Übertragungsprotokoll.

Eine typische TCP-Verbindung sieht so aus, dass der Client eine Verbindungsanforderung an den Server schickt. Dieser bestätigt diese Verbindung, wenn er dies möchte. Damit besteht eine feste Verbindung zwischen den beiden Partnern. Nun können fleißig Daten übertragen werden bis entweder der Server oder der Client die Zeit gekommen sehen, die Verbindung zu trennen. Dazu sendet er einfach eine Ende-Anforderung an den anderen Rechner und nach Bestätigung durch diesen wird die Verbindung beendet.

Ports

Sowohl UDP als auch TCP verwenden neben der IP-Adresse auch Portnummern. Diese sind sicher etwas erklärungsbedürftig. Da ein Rechner in der Regel mehr als einen Dienst anbietet (z.B. FTP, Telnet, POP, ...), muss man neben der IP-Adresse ein weiteres Merkmal der Adressierung finden. Dies sind die sogenannten Ports. So erreicht man z.B. den Dienst FTP auf einem Rechner in der Regel über Port 23, Telnet läuft über Port 21. Hinter jedem Port steht auf dem Rechner ein Prozess, der auf Anfragen wartet, hinter Port 21 entsprechend der FTP-Daemon. Bei allen Unix-ähnlichen Betriebssystemen sind in der Datei /etc/services alle Ports aufgeführt, die auf dem Rechner verfügbar sind.

Protokolle im Application Layer

In der Anwendungsschicht tauchen nun endlich die Protokolle auf, mit denen man auch langsam wirklich etwas anfangen kann. Die detaillierte Behandlung der Protokolle und deren Anwendung würde den Rahmen dieser Dokumentation sprengen, daher werde ich hier nur einige Protokolle und deren Funktion nennen und kann nur auf weiterführende Literatur verweisen.

DNS (Domain Name Service)
Dient zur Übersetzung von für Menschen leichter zu merkende Rechner-Namen in leichter zu merkende IP-Adressen, z.B. von 193.100.232.131 zu www.heise.de. Das DNS ist hierarchisch aufgebaut.

FTP (File Transfer Protocol)
FTP ist entworfen worden für die Übertragung von Dateien zwischen zwei Rechnern.

HTTP (Hypertext Transfer Protocol)
Das HTTP ist vor allem durch das World Wide Web bekannt geworden, denn alle Webseiten werden mit Hilfe von HTTP übertragen.

Telnet
Mit Telnet kann man sich auf einem entfernten Rechner einloggen und dort Befehle ausführen.
NFS (Network File System)

Mit dem hauptsächlich unter Unix verwendeten NFS kann man Dateisysteme im Netz verfügbar machen. So kann man mit NFS auf dem eigenen Rechner ein Verzeichnis einrichten, das eigentlich auf einer ganz anderen Maschine liegt. NFS arbeitet dabei völlig transparent. Neben dem DNS ist es eins der wenigen TCP/IP-Protokolle, die auf UDP aufbauen.

Zum Schluss ein kleines praktisches Beispiel:

Nach soviel Theorie möchte ich diese Dokumentation mit einem kleinen Beispiel enden lassen, das noch einmal praktisch (und stark vereinfacht) vor Augen führt, was denn nun eigentlich passiert, wenn wir TCP/IP verwenden.

Stellen wir uns vor, wir möchten vom Rechner 10.0.1.1 eine FTP-Verbindung zu 10.0.1.2 aufbauen. Intern passiert dabei folgendes: Der FTP-Protokollstack baut ein Paket zusammen, das die Anfrage auf einen Verbindungsaufbau zu 10.0.1.2 beinhaltet. Dieses Paket wird nun in ein TCP-Paket verpackt und auch mit der Portnummer 21 (FTP) und einer Prüfsumme versehen. Von der TCP-Ebene wird das Paket weitergeleitet zum IP, das prüft, wo es denn das Paket hinzuschicken hat. Fühlt es sich dazu in der Lage, fragmentiert es dieses Paket gegebenenfalls in mehrere Bestandteile und gibt es dann an den Link Layer, also die Hardware, weiter. Anderenfalls wird eine ICMP-Nachricht abgesetzt, dass etwas nicht funktioniert.
Handelt es sich im Link Layer um ein Ethernet, wird per ARP zuerst die Empfängeradresse in eine MAC-Adresse umgesetzt. Und dann kann das Paket, welches inzwischen viermal eingepackt wurde, endlich in das Kabel gehen.

Auf der Empfängerseite wiederholt sich dieses Spielchen in umgekehrter Richtung (wir erinnern uns an das OSI-Schichtenmodell?). Der Link Layer nimmt die Daten aus dem Kabel entgegen, das IP setzt sie gegebenenfalls wieder in der richtigen Reihenfolge zusammen und gibt sie an das TCP weiter, welches das Paket weiter entpackt und letztendlich erreicht das ursprüngliche FTP-Paket seinen Empfänger.

Für die Applikationsschicht, also in diesem Falle FTP, ist es völlig uninteressant, dass die beiden Rechner vorher eine TCP-Verbindung aufbauen oder das das IP-Paket über mehrere Router geht, bevor es den Empfänger erreicht. Die eine Schicht reicht ihre Daten in einer festgelegten Form an die andere durch und braucht von deren genauer Arbeitsweise exakt gar nichts zu wissen.

#9 29. April 2002, 20:40
Webmaster Administrator Status: Offline Beiträge: 448 Registriert seit: 13. September 2000 Ort: Wien	Und hier dazu die Erklärung für FTP am Schluss TCP/IP ist einer der typischen Begriffe, die in Verbindung mit Netzwerken immer wieder auftauchen, mit denen man allerdings wenig anfangen kann. Zunächst ist TCP/IP eine Abkürzung für TCP/IP eine Abkürzung für Transmission Control Protocol / Internet Protocol, was die Deutung allerdings auch nicht gerade vereinfacht. Es handelt sich hierbei nicht um ein einzelnes Protokoll sondern um eine Ansammlung von Protokollen, die im Verbund die gesamte Funktionalität des Internets zur Verfügung stellt. (Quelle: Netzwerke von Guido Ehlert) Adressierung im IP Jeder Host im Netzwerk erhält eine eindeutige Adresse, die sogenannte IP-Adresse oder IP-Nummer. Das 'IP' in der Bezeichnung deutet darauf hin, dass hierfür das Internet Protocol zuständig ist. In der aktuellen Version von TCP/IP wird jedem Rechner eine 32 Bit lange Adresse \index{IP-Adresse} zugeordnet, die der besseren Lesbarkeit halber in der Form xxx.xxx.xxx.xxx geschrieben wird. Hierbei werden die einzelnen Bytes durch Punkte getrennt. So sind IP-Adressen von 0.0.0.0 bis 255.255.255.255 möglich. Es sind nicht alle Nummern nutzbar, einige z.B. sind für die Netzadresse oder sogenannte Broadcasts reserviert. Eine typische IP-Adresse könnte nun lauten 141.89.64.1 (ist in diesem Fall der Nameserver der Universität Potsdam). In Binärschreibweise wäre dies 10001101 1011001 1000000 00000001 Eine IP-Adresse gliedert sich nun in einen vorderen und einen hinteren Teil. Der vordere Teil stellt die Netzadresse dar, der hintere Teil die Host-Adresse. Die IP-Adresse bezeichnet das Netz, in dem sich ein Rechner befindet und seine Nummer in diesem Netz. Die Trennung dieser beiden Teile kann prinzipiell an jedem Bit der Adresse erfolgen. Dazu benötigt man aber noch die sogenannte Netzmaske. Diese Netzmaske ist genauso lang wie die IP-Adresse und wird bis zu einem bestimmten Bit mit Einsen gefüllt. Der Rest wird auf Null gesetzt. Alle Bits in der IP-Adresse, die in der Netzmaske belegt sind, zählen dann zum Netzanteil, der Rest zum Hostanteil. Im ersten Beispiel verwenden wir als Netmask 255.255.0.0, d.h. die ersten 16 Bit der Adresse sind dem Netzteil vorbehalten, hier 141.89, die restlichen 16 Bit werden zur Adressierung des Hosts in diesem Netz verwendet, dazu bleiben 254*254, also gut 64.516 Möglichkeiten - praktisch können also über 64.000 Hosts in diesem Netz adressiert werden. Die Adresse 141.89.0.0 ist für das Netzwerk selbst reserviert, die Adresse 141.89.255.255 bezeichnet die sogenannte Broadcast-Adresse: Pakete an diese Adresse werden an alle Stationen im Netz verschickt. Doch fahren wir mit unseren Beispielen fort. Unser Beispiel Nummer zwei beschreibt den Host 58.17.131.43 mit der Netmask 255.255.255.0. Hier sind also 24 Bit für den Netz- und 8 Bit für den Hostanteil reserviert. Theoretisch kann es in diesem Netz maximal 254 Hosts geben. Adresse für dieses Netzwerk ist 58.17.131.0, Broadcasts gehen an 58.17.131.0. Das dritte Beispiel zeigt nun, dass man sich bei der Netzmaske keinesfalls auf ganze Bytes beschränken muss. Bei dieser Adresse macht der Netzanteil 20 Bit aus, der Hostanteil 12 Bit. Die Netzadresse ist hier 123.5.6.0 (bis zum 20. Bit), Broadcasts gehen an 123.5.112.255 (Alle Bits ab dem 21. sind auf 1 gesetzt). Die verschiedenen Netzmasken lassen sich in verschiedene Klassen unterteilen: Class-A-Netz haben die Netmask 255.0.0.0, Class-B-Netze die Netmask 255.255.0.0 und Class-C-Netze die Netmask 255.255.255.0. Netze mit anderen Netmasks bezeichnet man als Subnetze. Möchte man Rechner im Internet betreiben, muss man dazu bei DeNIC (http://www.denic.de) entsprechend IP-Adressen beantragen. IP - Das Internet Protocol Das IP übernimmt die gesamte Paketvermittlung. Daten werden in gegebenenfalls mehrere IP-Pakete verpackt und an einen bestimmten Empfänger abgeschickt. Beim Empfänger können diese Pakete eventuell in falscher Reihenfolge ankommen. Das IP hat nun dafür zu sorgen, diese fragmentierten Pakete wieder ordentlich zusammenzusetzen. Dabei arbeitet das Protokoll verbindungslos und ungesichert, d.h. vor dem Versenden der Pakete wird keine explizite Verbindung zum Empfänger hergestellt, sondern einfach abgeschickt. Es existieren auf IP-Ebene keine Sicherungsmechanismen, die sicher stellen, dass die Daten auch korrekt beim Empfänger ankommen. Dies ist auch gar nicht notwendig, denn das IP hat für die Vermittlung der Pakete zu sorgen, für die korrekte Übertragung sind die höheren Protokollschichten zuständig. Die weiter vorn beschriebene Adressierung in TCP/IP-Netzen wird ebenfalls durch das IP gehandhabt. TCP - Transmission Control Protocol Das Transmission Control Protocol ist im Gegensatz zu den bisher beschriebenen Protokollen ähnlich wie das Telefonnetz verbindungsorientiert aufgebaut. Bevor man also irgendwelche Daten per TCP an einen anderen Rechner senden kann, muss man eine Verbindung zu diesem aufgebaut haben. Da alle darunter liegenden Protokolle allerdings paketorientiert arbeiten, ist die Verbindung natürlich nur 'virtuell'. Durch diese festgelegte Verbindung können die zwei Verbindungspartner auch sicherstellen, dass die gesendeten Daten auch wirklich korrekt ankommen und zwar auch in der richtigen Reihenfolge und nicht doppelt. Dadurch ist es natürlich wesentlich komplexer aufgebaut als UDP, in der Regel gibt es in der Verbindung einen Client und einen Server. So verwenden auch die meisten Internetanwendungen TCP als Übertragungsprotokoll. Eine typische TCP-Verbindung sieht so aus, dass der Client eine Verbindungsanforderung an den Server schickt. Dieser bestätigt diese Verbindung, wenn er dies möchte. Damit besteht eine feste Verbindung zwischen den beiden Partnern. Nun können fleißig Daten übertragen werden bis entweder der Server oder der Client die Zeit gekommen sehen, die Verbindung zu trennen. Dazu sendet er einfach eine Ende-Anforderung an den anderen Rechner und nach Bestätigung durch diesen wird die Verbindung beendet. Ports Sowohl UDP als auch TCP verwenden neben der IP-Adresse auch Portnummern. Diese sind sicher etwas erklärungsbedürftig. Da ein Rechner in der Regel mehr als einen Dienst anbietet (z.B. FTP, Telnet, POP, ...), muss man neben der IP-Adresse ein weiteres Merkmal der Adressierung finden. Dies sind die sogenannten Ports. So erreicht man z.B. den Dienst FTP auf einem Rechner in der Regel über Port 23, Telnet läuft über Port 21. Hinter jedem Port steht auf dem Rechner ein Prozess, der auf Anfragen wartet, hinter Port 21 entsprechend der FTP-Daemon. Bei allen Unix-ähnlichen Betriebssystemen sind in der Datei /etc/services alle Ports aufgeführt, die auf dem Rechner verfügbar sind. Protokolle im Application Layer In der Anwendungsschicht tauchen nun endlich die Protokolle auf, mit denen man auch langsam wirklich etwas anfangen kann. Die detaillierte Behandlung der Protokolle und deren Anwendung würde den Rahmen dieser Dokumentation sprengen, daher werde ich hier nur einige Protokolle und deren Funktion nennen und kann nur auf weiterführende Literatur verweisen. DNS (Domain Name Service) Dient zur Übersetzung von für Menschen leichter zu merkende Rechner-Namen in leichter zu merkende IP-Adressen, z.B. von 193.100.232.131 zu www.heise.de. Das DNS ist hierarchisch aufgebaut. FTP (File Transfer Protocol) FTP ist entworfen worden für die Übertragung von Dateien zwischen zwei Rechnern. HTTP (Hypertext Transfer Protocol) Das HTTP ist vor allem durch das World Wide Web bekannt geworden, denn alle Webseiten werden mit Hilfe von HTTP übertragen. Telnet Mit Telnet kann man sich auf einem entfernten Rechner einloggen und dort Befehle ausführen. NFS (Network File System) Mit dem hauptsächlich unter Unix verwendeten NFS kann man Dateisysteme im Netz verfügbar machen. So kann man mit NFS auf dem eigenen Rechner ein Verzeichnis einrichten, das eigentlich auf einer ganz anderen Maschine liegt. NFS arbeitet dabei völlig transparent. Neben dem DNS ist es eins der wenigen TCP/IP-Protokolle, die auf UDP aufbauen. Zum Schluss ein kleines praktisches Beispiel: Nach soviel Theorie möchte ich diese Dokumentation mit einem kleinen Beispiel enden lassen, das noch einmal praktisch (und stark vereinfacht) vor Augen führt, was denn nun eigentlich passiert, wenn wir TCP/IP verwenden. Stellen wir uns vor, wir möchten vom Rechner 10.0.1.1 eine FTP-Verbindung zu 10.0.1.2 aufbauen. Intern passiert dabei folgendes: Der FTP-Protokollstack baut ein Paket zusammen, das die Anfrage auf einen Verbindungsaufbau zu 10.0.1.2 beinhaltet. Dieses Paket wird nun in ein TCP-Paket verpackt und auch mit der Portnummer 21 (FTP) und einer Prüfsumme versehen. Von der TCP-Ebene wird das Paket weitergeleitet zum IP, das prüft, wo es denn das Paket hinzuschicken hat. Fühlt es sich dazu in der Lage, fragmentiert es dieses Paket gegebenenfalls in mehrere Bestandteile und gibt es dann an den Link Layer, also die Hardware, weiter. Anderenfalls wird eine ICMP-Nachricht abgesetzt, dass etwas nicht funktioniert. Handelt es sich im Link Layer um ein Ethernet, wird per ARP zuerst die Empfängeradresse in eine MAC-Adresse umgesetzt. Und dann kann das Paket, welches inzwischen viermal eingepackt wurde, endlich in das Kabel gehen. Auf der Empfängerseite wiederholt sich dieses Spielchen in umgekehrter Richtung (wir erinnern uns an das OSI-Schichtenmodell?). Der Link Layer nimmt die Daten aus dem Kabel entgegen, das IP setzt sie gegebenenfalls wieder in der richtigen Reihenfolge zusammen und gibt sie an das TCP weiter, welches das Paket weiter entpackt und letztendlich erreicht das ursprüngliche FTP-Paket seinen Empfänger. Für die Applikationsschicht, also in diesem Falle FTP, ist es völlig uninteressant, dass die beiden Rechner vorher eine TCP-Verbindung aufbauen oder das das IP-Paket über mehrere Router geht, bevor es den Empfänger erreicht. Die eine Schicht reicht ihre Daten in einer festgelegten Form an die andere durch und braucht von deren genauer Arbeitsweise exakt gar nichts zu wissen. __________________ Das Letzte was man auf dieser Welt hören wird, ist das Wort des Technikers "das ist technisch absolut unmöglich"