5.3    Ablauf der Kommunikation

Ich möchte in diesem Abschnitt beschreiben, wie die einzelnen Schichten zusammenarbeiten, also wie die Kommunikation im Netzwerk funktioniert. Dazu werde ich mein Beispiel auf der Applikationsschicht beginnen.

[»]  Stellen Sie sich vor, Sie geben z.  B. die Adresse http://www.web.de im Adressfeld Ihres Browsers ein. Wenige Sekunden später ist die Webseite des Anbieters WEB.DE vollständig auf Ihren Bildschirm übertragen. Zwischen der Eingabe der Adresse in den Browser und dem Erscheinen der Webseite liegen viele übertragene Datenpakete und viel Netzwerkkommunikation.

Der Ablauf ist in Tabelle 5.4 dargestellt. Jedes Datenpaket wird auf die gleiche Art und Weise abgearbeitet.

Schritt	Beschreibung	ISO/OSI
1	Ihre Anfrage nach der Webseite wird in ein HTTP-Datenpaket verpackt und über eine Betriebssystemschnittstelle an TCP übergeben.	7
2	Sie möchten einen Webserver ansprechen, d.  h. HTTP-Pakete mit ihm austauschen. Es ist festgelegt, dass HTTP dem TCP-Port 80 entspricht. Entsprechend wird nun ein TCP-Paket erzeugt, in dessen Datenteil das HTTP-Paket enthalten ist und in dessen Verwaltungsteil (engl. header) die Zielnummer 80 (TCP-Serverport) steht. Zusätzlich wird dort ein zufälliger TCP-Port Ihres PCs eingetragen, z.  B. 1333, auf dem Ihr Browser horcht.	4
3	Der Webserver von WEB.DE hat eine IP-Adresse. Anhand dieser IP-Adresse kann der Weg zu ihm gefunden werden. Das IP-Paket enthält im Datenteil das TCP-Paket (mit dem HTTP-Paket aus Schritt 1) und im Verwaltungsteil (Header) die Ziel-IP-Adresse sowie die IP-Adresse Ihres PCs als Quell-IP-Adresse.	3
4	Sie senden das Datenpaket in Ihrem LAN aus, daher muss dieses Datenpaket mit dem Ethernet-Verfahren übertragen werden. Es entsteht ein Ethernet-Paket, das neben den ineinander verpackten Paketen aus den Schritten 1 bis 3 die Ziel-Quell-MAC-Adresse enthält. Dies ist die MAC-Adresse Ihres DSL-Routers. Die Netzwerkkarte führt nun das Ethernet-Verfahren durch und sendet erst, wenn die Leitung frei ist.	2
5	An Ihre Netzwerkkarte ist ein Kupferkabel angeschlossen, daher können Informationen über dieses Medium nur als elektrische Spannungen übertragen werden. Jede binäre Null wird durch keine Spannung und jede binäre Eins durch eine Spannung von 5 Volt dargestellt.	1
6	Das Paket wird über das Internet übertragen und passiert dabei viele Router. Schließlich wird das Paket vom Webserver empfangen.	–
7	Der Empfänger stellt an seiner Netzwerkkarte wechselnde Spannungen fest. Er interpretiert für 5 Volt eine binäre Eins und bei keiner Spannung eine binäre Null. Das Ergebnis ist eine Folge von Binärziffern.	1
8	Von der Netzwerkkarte erhält der Netzwerkkartentreiber ein Datenpaket im Ethernet-Format. Es enthält seine MAC-Adresse als Ziel-MAC-Adresse und eine Quell-MAC-Adresse. Im Datenteil befindet sich ein IP-Paket.	2
9	Das IP-Paket enthält als Ziel-IP-Adresse die IP-Adresse des Webservers und die Quell-IP-Adresse Ihres PCs zu Hause. Im Datenteil befindet sich ein TCP-Paket.	3
10	Das TCP-Paket wendet sich an den Serverport 80, also an den Webserver. Entsprechend wird der Datenteil an die Webserver-Applikation übergeben. Eine Antwort muss an den TCP-Clientport 1333 gerichtet werden.	4
11	Der Webserver-Prozess bekommt ein HTTP-Paket, in dem die Hauptwebseite angefordert wird.	7

Tabelle 5.4    Kommunikation im ISO/OSI-Modell

Ihre Anfrage an die Webseite geht von einer Applikation (einem Programm) aus, das ein Applikationsdatenpaket erzeugt (siehe HTTP-Paket). Dieses Paket wandert – logisch gesehen – die ISO/OSI-Schichten hinunter (Schicht 7, 4, 3, 2 und 1) und wird schließlich als elektrisches Signal übertragen. Der Webserver von WEB.DE empfängt ein elektrisches Signal mit seiner Netzwerkkarte und erzeugt daraus ein Datenpaket. Dieses beginnt seine Wanderung die ISO/OSI-Schichten hinauf (Schicht 1, 2, 3, 4 und 7) und wird auf der Applikationsschicht von der Anwendung Webserver verarbeitet.

[»]  Das Verfahren, das ich in Abbildung 5.1 beispielhaft für eine HTTP-Anfrage dargestellt habe, findet für jedes Datenpaket statt.

Das klingt alles sehr kompliziert. Warum also macht man es nicht einfacher? Es könnte doch direkt Anwendung mit Anwendung sprechen, oder? Denkbar, doch zwischen Ihnen und dem Webserver von WEB.DE liegen noch weitere Provider-Netzwerke. Alle Komponenten müssten die Anwendung bzw. das HTTP-Protokoll direkt verstehen. Die Anwendung, also z.  B. der Browser, müsste sich darum kümmern, wie sie den Eingang von Paketen überwacht und wie man zum Ziel http://www.web.de kommt. Außerdem müsste sie die Integrität der Daten überwachen und wie die Signale auf dem Kabel in elektrische Spannung umgesetzt werden. Das sind sehr viele Aufgaben, die diese Applikation erfüllen müsste. Wenn Sie nur das HTTP-Protokoll betrachten, ist der Aufwand gleich groß wie bei der Entwicklung selbständiger Schichten.

Abbildung 5.1    Datenkommunikation nach ISO/OSI-Modell

Über das Internet kommunizieren noch weitere Applikationen Ihres PCs (z.  B. FTP, SIP und SMTP), und jede dieser Anwendungen müsste sich um alle Teile der Netzwerkkommunikation kümmern. Dies würde bedeuten, dass einerseits die Entwicklung von Anwendungen sehr komplex und andererseits die Übermittlung von Daten über allgemeine Netzwerke (z.  B. das Internet) fast unmöglich würde – schließlich müsste jedes Netzwerkgerät, insbesondere der Router, z.  B. die programmspezifische Adressierung verstehen, denn IP-Adressen gäbe es dann ja nicht.