» SelfLinux » Linux im Netzwerk - Einführung »  TCP/IP  » Abschnitt 6 SelfLinux-0.10.0
zurück   Startseite Kapitelanfang Inhaltsverzeichnis GPL   Dynamic Host Configuration Protocol

SelfLinux-Logo
Dokument TCP/IP - Abschnitt 6 Revision: 1.1.2.7
Autor:  Steffen Dettmer
Formatierung:  Matthias Nuessler
Lizenz:  GPL
 

7 Protokolle im Application Layer

Wie bereits angedeutet, ist der Begriff Application Layer vom gleichnamigen Begriff des OSI Referenzmodelles zu unterscheiden. Hiermit wird in etwa die Zusammenfassung der OSI Layer Session, Presentation und Application gemeint.

Viele Protokolle setzen auf TCP oder UDP auf. Beispiele für UDP basierte Protokolle sind zum Beispiel DNS (DomainNameService), verschiedene Windows-Protokolle und RIP (Routing Information Protocol). Beispiele für TCP basierte Protokolle sind HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol) und SSH (Secure Shell).



8 Beispiel

Zum Abschluß soll ganz kurz eine Verbindung erklärt werden. Angenommen, es gibt mehrere Ethernet-Netzwerke. Weiterhin einen Host CLIENT, der an einen IP-Router ROUTER1 angeschlossen ist. Dieser Router hat eine zweite Netzwerkkarte. In diesem zweiten Ethernet-Netzwerk steht ein DNS Server und ein Router ROUTER2. An dessen anderem Netz steht ein Server SERVER, der Webseiten über HTTP anbietet. Die folgende Beschreibung ist natürlich stark vereinfacht.

Auf CLIENT läuft eine Anwendung, die Webseiten von SERVER holen soll (es könnte sich um einen Browser handeln). Der CLIENT weiß, daß es dazu HTTP verwenden muß, und dass dieses Protokoll auf TCP aufsetzt. Er weiß weiterhin, dass er dazu die IP-Adresse von SERVER kennen muß, um das Paket adressieren zu können.

Zunächst muß CLIENT also die IP-Adresse von SERVER herauskriegen. Dazu kennt er das DNS-Protokoll, welches über UDP verwendet wird. CLIENT sieht in /etc/services nach, und erkennt, daß DNS (domain) Port 53 verwendet. Er sieht in /etc/resolv.conf nach, und kennt die IP-Adresse des Nameservers. Er sendet nun ein UDP Paket mit der Anfrage nach der Adresse von SERVER. Um das UDP Paket verschicken zu können, muß IP einen Router verwenden, da IP an Hand der IP Adresse erkennt, dass der DNS Server in einem anderen Netzwerk liegt. Hierzu schaut IP nun in der sogenannten Routingtabelle nach, und stellt fest, dass ROUTER1 verwendet werden muß, und das Netzwerk zu erreichen. CLIENT packt das IP Paket mit dem UDP Paket (welches wiederum die eigentliche Anfrage enthält) in ein Ethernetframe. Über ARP bekommt CLIENT heraus, wie die Ethernetadresse (MAC Adresse) von ROUTER1 ist (bisher kennt CLIENT ja aus der Routingtabelle nur dessen IP Adresse). Diese setzt er dann in das Ethernetframe ein. Das Frame sieht dann wie folgt aus:

Ethernetframe
     
+---------------------------------------------------------------+
|            +------------------------------------------------+ |
|            |          +-----------------------------------+ | |
|            |          |                      +----------+ | | |
| MAC -> MAC | IP -> IP | UDP-Port -> UDP-Port | A?SERVER | | | |
|            |          |                      | [Daten]  | | | |
|            |          |                      +----------+ | | |
|            |          |                      [UDP Paket]  | | |
|            |          +-----------------------------------+ | |
|            |                                 [IP Paket]     | |
|            +------------------------------------------------+ |
|                                             [Ethernet Frame]  |
+---------------------------------------------------------------+
     
    

In diesem Beispiel sieht man auch gut, wieviel zusätzliche Daten benötigt werden! Die hier dargestellten Kästchen entsprechen den Layern des TCP/IP Modells (Daten gehören zum Application Layer).

Der ROUTER1 empfängt dieses Paket, da er die MAC Zieladresse ist. Er entpackt das Ethernetframe und reicht dessen Inhalt an IP weiter. IP erkennt, dass das Paket an DNS-Server adressiert ist. IP erkennt auch, dass DNS-Server im selben Netz liegt, und das kein Router verwendet werden muß. Über ARP wird die MAC Adresse vom DNS-Server bestimmt, und das IP Paket wird in ein an diese MAC Adresse adressiertes Ethernetframe verpackt und verschickt.

DNS-Server empfängt das Ethernetframe und packt es aus. IP erkennt, dass das Paket nicht weiterverschickt werden muß. Es packt es aus und reicht es an UDP weiter. UDP erkennt an der Portnummer, dass es an den DNS Prozeß weitergereicht werden muß. Der DNS Prozeß erkennt eine Adressanfrage für SERVER. Er schaut die IP Adresse in seiner Datenbank nach und erzeugt ein UDP-Antwort-Paket. Das IP erkennt nun, dass wieder ROUTER1 verwendet werden muß und schickt ein entsprechendes Ethernetframe. ROUTER1 sendet das UDP/IP Paket über ein neues Ethernetframe wiederum weiter zu CLIENT. Der empfängt dies und gibt die Antwort letztlich an die Anwendung weiter.

So, nun kennt die Anwendung die Adresse von SERVER. Über /etc/services findet es TCP Port 80 für HTTP. Sie schickt ein TCP-Verbindungsaufbaupaket an SERVER, Port 80. IP erkennt, das ein Router verwendet werden muß, und findet ROUTER1 als zuständig. Diesem wird also ein Ethernetframe geschickt. Das IP erkennt hier jedoch, dass die Zieladresse (immer noch) in einem anderen Netzwerk liegt. Anhand der Routingtabelle findet IP heraus, dass ROUTER2 verwendet werden muß und macht eine entsprechende ARP Anfrage. Über die gelernte MAC Adresse wird nun das Paket zu ROUTER2 geschickt, der wiederrum eine ARP Anfrage für die MAC Adresse von SERVER macht, und letztendlich das Paket an diese verschickt.

Endlich hat SERVER ein Paket empfangen. Hier wird geschaut, ob es einen Dienst für Port 80 bekannt ist. In diesem Fall wird eine Bestätigung geschickt (ansonsten eine entsprechende Meldung als Paket verschickt). Ist SERVER überhaupt nicht erreichbar (ROUTER2 bekommt zum Beispiel keine Antwort auf seine ARP Anfrage), so würde ein ICMP Paket von ROUTER2 an CLIENT geschickt werden. Diese Antwort wird über ROUTER2 und ROUTER1 entsprechend an CLIENT geschickt, der sie bestätigt (über ROUTER1 und ROUTER2). Nun kann CLIENT anfangen, TCP Nutzdaten zu schicken. Die Pakete gelangen dann zu SERVER und werden nun an die Anwendung weitergereicht.

In der Praxis hat man oft nicht nur zwei, sondern 10 oder manchmal 20 und mehr Router auf dem Weg! Die Beschreibung hier hat viele viele Details weggelassen; in der Praxis ist der Vorgang weitaus komplexer.

Mit diesem Wissen ärgert man sich vielleicht nicht mehr so sehr über langsamen Webseitenaufbau, da man bedenkt, welche komplexen Vorgänge hier ablaufen...



zurück   Seitenanfang Startseite Kapitelanfang Inhaltsverzeichnis GPL   Dynamic Host Configuration Protocol