next up previous contents
Nächste Seite: Die Protokolle FTP, SMTP Aufwärts: Adressierung, Routing und Multiplexing Vorherige Seite: Die Routing Tabelle   Inhalt

Protokolle, Ports und Sockets

Sind nun die Daten erfolgreich durch das WWW gewandert und am Zielrechner angelangt, muüssen die Daten an den richtigen Benutzer oder den geünschten Prozess abgeliefert werden. Wenn die Daten vertikal durch die TCP/IP Schichten wandern, ist ein Mechanismus notwendig, der dafür sorgt, daß die Daten an das korrekte Protokoll in jeder Schicht weitergegeben werden. Das System muß in der Lage sein, Daten aus den verschiedensten Anwendungen zu bündeln und in wenige Protokolle der Transport Layer zu übergeben. Diese müssen dann in die IP Schicht weitergegeben werden. Man nennt das Zusammenführen von Daten aus vielen Quellen in einen einzigen Datenstrom Multiplexing. Umgekehrt müssen natürlich die aus dem Netz kommenden Daten demultiplexed werden. Dabei werden die einlaufenden Daten auseinanderdividiert, um sie dann an die erforderlichen Prozesse weiterzuleiten. IP benutzt zu diesem Zweck die Protokoll Nummern, um die Protokolle der Transportschicht zu identifizieren, die Transport Protokolle (wie TCP oder UDP) benutzen die Port Nummern, um die Anwendungen zu identifizieren. Eine Reihe von Protokoll- und Port-Nummern sind reserviert. Sie dienen dazu, sogenannte well-known sevices zu identifizieren. Darunter versteht man Standard-Netzwerkprotokolle wie FTP oder TELNET, die im Netz weit verbreitet sind und sehr häufig benutzt werden. Diese Nummern fallen nun nicht vom Himmel, sondern sind in den RFC 1340 bzw. 1600 dokumentiert. UNIX Systeme hinterlegen Port- und Protokollnummern einfach in zwei Textdateien.

Abbildung 5.18: Protokollnummern auf einem Linux System.
\begin{figure}
\scriptsize
\begin{verbatim}
...

Die Protokollnummer steht in einem Feld im Header des IP Datagramms. Im Header der Abbildung 5.4 ist dies das Feld Transport. Dieses Feld hat die Länge eines Bytes. Der Wert, der in diesem Feld eines Datagramms steht, informiert die IP Layer darüber, an welches Protokoll der Transportschicht das aktuelle Datagramm abzuliefern ist. Auf UNIX Systemen können die Protokollnummern in der Datei /etc/protocols nachgesehen werden. Dort findet man eine einfach strukturierte Tabelle (siehe Abbildung 5.18), in der die Zuordnung Protokoll $ \Longleftrightarrow$ Protokollnummer $ \Longleftrightarrow$ Aliasname geschieht. Wie ein Blick in die RFC 1340 zeigt5.24, gibt es natürlich sehr viel mehr Protokollnummern als in Abbildung 5.18 aufgelistet sind. Die UNIX Maschinen verwalten natürlich auch nur die Protokolle, die aktuell gebraucht werden. Wozu dient nun diese Tabelle mit den Protokollnummern? Wenn ein Datagramm eintrifft und die Zieladresse stimmt mit der lokalen IP Adresse überein, dann weiß die IP Layer, daß das Datagramm an eines der Transport Protokolle in der darüberliegenden Layer abgeliefert werden muß. Um zu entscheiden, an welches Protokoll das Datagramm weitergegeben werden soll, wird der Inhalt des Feldes Transport des IP Headers gelesen. Anhand der Tabelle in /etc/protocols identifiziert IP einen Wert 6 mit dem Transportprotokoll TCP, ein Eintrag 17 im Header veranlaßt IP das Datagramm an UDP weiterzugeben. Nachdem IP das Datagramm an die Transportschicht weitergegeben hat, obliegt es dem Transportprotokoll, das Datagramm an die korrekte Applikation weiterzugeben. Applikationsprozesse - diese nennt man auch Netzwerkdienste (engl.: network services) - werden durch die Port Nummer identifiziert, dies ist eine 16 Bit Zahl. Sowohl im TCP Header als auch im UDP Header (siehe Abbildungen 5.9 und 5.8) besteht das erste Word aus der source port number, die den Prozess identifiziert, der das Datagramm abgesendet hat und der destination port number, das ist die Portnummer der Applikation, für die das Datagramm bestimmt ist.

Abbildung 5.19: Ausschnitt der Datei /etc/services einer LINUX Maschine.
\begin{figure}
\scriptsize
\begin{verbatim}
...

Auf UNIX Systemen werden die Ports in der Datei /etc/services definiert. Die Abbildung 5.19 zeigt einen Ausschnitt aus dieser Datei auf einem LINUX System. Diese Datei ist sehr ähnlich aufgebaut wie die /etc/protocols - Datei; wie man aus der Dateigröße schon ahnen kann, gibt es viel mehr Ports als Protokolle. Die Portnummern unterhalb 256 sind reserviert für Standarddienste wie FTP oder TELNET und im RFC 1340 dokumentiert. Jenseits der 256 bis 1.024 ist reichlich Platz für jede Menge Ports für UNIX spezifische Dienste, z.B. rlogin.

Abbildung 5.20: Das Zusammenspiel der Protokoll- und Portnummern.
\begin{figure}
\scriptsize
\centering
\unitlength 0.8mm
\linethickness {0....
...67){\framebox (147.67,117.00)[cc]{}}
\end{picture}
\normalsize
\end{figure}

Die Port Nummern sind nicht eindeutig zwischen Transport Layer Protokollen, sie sind nur eindeutig für jeweils ein spezielles Transportprotokoll. Anders ausgedrückt, TCP und UDP greifen auf die gleichen Portnummern zu.
Die Kombination aus Protokoll- und Portnummer identifiziert eindeutig den Prozess, an den die Daten abgegeben werden müssen.
Die beiden Tabellen 5.18 und 5.19 liefern alle Informationen, die notwendig sind, die einlaufenden Daten an den Prozess abzuliefern, der angesprochen werden soll. Ein einlaufendes Datagramm wird anhand des Eintrags im fünften Word des Haeders - das ist nichts anderes als die Empfänger IP Adresse - empfangen. Anhand der Protokollnummer im dritten Word des Datagrammheaders liefert IP die Daten aus dem Datagramm an das geeignete Protokoll in der Transportschicht. Das erste Word der an das Protokoll ausgelieferten Daten enthält die Portnummer, an die die Daten abgeliefert werden sollen. Anhand dieser Nummer erkennt das Transportprotokoll, an welche Applikation die Daten zu senden sind. Die Abbildung 5.20 zeigt schematisch nochmals, wie dieser Ablieferungsprozess funktioniert. Sockets Well-known ports sind die Standard Portnummern, die es remote Systemen ermöglicht, auf bestimmte Standard Netzwerkdienste zuzugreifen. Eine derartige Architektur vereinfacht natürlich die Verbindungsprozedur, da Sender und Empfänger vorab wissen, daß Daten einem bestimmten Prozess zugewiesen sind. So nutzen beispielsweise alle Systeme den Port mit der Nummer 23 für TELNET. Es gibt eine weitere Art von Port - Nummern, die den Prozessen bei Bedarf zugewiesen werden. Das sind die sogenannten dynamically allocated ports. Das System5.25 stellt selbst sicher,
  1. daß nicht die gleiche Portadresse zwei Prozessen zugewiesen werden
  2. und die dynamisch zugewiesenen Portnummern nicht mit den Standardnummern in Konflikt geraten.
Dynamisch zugewiesene Portnummern sind Grundvoraussetzung für die erforderliche Flexibilität in einer Multiuserumgebung. Ist einem TELNET-Benutzer die Portnummer 23 sowohl auf der Sende- als auch auf der Empfängerstation zugewiesen, dann stellt sich die Frage, welche Nummern ein zweiter Benutzer zugewiesen bekommt, der gleichzeitig TELNET nutzt. Um jede Verbindung eindeutig zu identifizieren, wird dem Sendeport eine Nummer dynamisch zugewiesen, die well-known Portnummer wird für den Bestimmungsport benutzt. Im aktuellen Beispiel zweier TELNET Benutzer wird dem ersten Benutzer eine zufällige Nummer für den Sendeport zugewiesen, die Portnummer für die Zielanwendung bleibt die 23. Dem zweiten User wird eine Zufallszahl für den Sendeport zugewiesen, der Bestimmungsport hat ebenfalls die Nummer 23. Das Paar (Portnummer Quelle,Portnummer Ziel) identifiziert jede Netzwerkverbindung eindeutig. Der Zielhost kennt den Quellport, da dessen Nummer sowohl im TCP als auch UDP Header eingetragen ist, beide Hosts kennen den Zielport, da er ein well-known Port ist.

Abbildung 5.21: Austausch von Portnummern während des Verbindungsaufbaus (handshake)
\begin{figure}
\centering
\unitlength 1mm
\linethickness {0.4pt}
\begin{pic...
...7}}
\put(91.33,12.67){\makebox(0,0)[lc]{23,3044}}
\end{picture}
\end{figure}

Die Abbildung 5.21 zeigt den Austausch der Portnummern während des TCP Handshakes. Der Sendehost generiert zufällig eine Nummer für den Sendeport - hier die 3.044. Der Host sendet nun ein Segment los mit der 3.044 als Quellport und der 23 als Zielport. Der Empfängerhost nimmt das Segment entgegen und antwortet mit einer 23 als Sendeport und der 3.044 als Zielport. Die Kombination einer IP Adresse mit der Portnummer nennt man einen Socket. Ein Socket identifiziert eindeutig einen einzelnen Netzwerkprozess im gesamten Internet. Ein Socketpaar - ein Socket für den Sendehost, ein Socket des Empfängers - definiert die Verbindung für verbindungsorientierte Protokolle wie TCP. Sehen wir uns das Konzept anhand der dynamisch zugewiesenen und well-known Ports genauer an. Dazu nehem wir an, ein Benutzer des Hosts 172.16.12.2 benutzt TELNET, um mit dem Host 198.164.12.5 Verbindung aufzunehmen. Der Host 172.16.12.2 ist also der Quellhost. Dem Benutzer auf dem Quellhost wird nun dynamisch die eindeutige Portnummer zugewiesen - 3854 (z.B.). Die Verbindung wird nun zum TELNET Dienst des Zielhosts hergestellt, es wird dabei die Zielportnummer 23 gewählt. Der Socket der Verbindung auf der Quellhost Seite ist nun die 172.16.12.2.3854, der Socket auf dem remote Host ist 198.164.12.5.23. Der Port des Empfängersockets ist beiden Systemen bekannt, da es ein well-known Port ist. Der Port des Quellsystems ist dem Zielsystem bekannt, da das Quellsystem dem Zielhost die Portnummer während des Verbindungsaufbaus mitteilt. Das Socketpaar ist demnach beiden Systemen bekannt. Die Kombination beider Sockets identifiziert daher genau diese Verbindung, keine andere Verbindung im Internet hat genau dieses Socketpaar.
next up previous contents
Nächste Seite: Die Protokolle FTP, SMTP Aufwärts: Adressierung, Routing und Multiplexing Vorherige Seite: Die Routing Tabelle   Inhalt
Yasar Arman
2000-05-15