Grundlagen der Rechnernetze

Grundlagen der Rechnernetze
Applikationsschicht
Übersicht
•
•
•
•
Web und HTTP
File Transfer: FTP
Electronic Mail
Domain Name System (DNS)
Grundlagen der Rechnernetze ‐ Applikationsschicht
2
HTTP Übersicht
Hyper Text Transfer Protocol (HTTP)
• Application Layer Protocol auf Basis von TCP
• HTTP definiert Formate und Austausch von Nachrichten zum aufrufen von Web‐Seiten (Request‐Response)
• Client‐Server‐Paradigma (Web‐Server und Web‐Client bzw. Web‐Browser) (Server‐Port meist 80, manchmal 8080)
• Web‐Server sind zustandslos (engl. stateless)
• Bzw. HTTP ist ein zustandsloses Protokoll
HTTP definiert in RFC 1945 und RFC 2616 (definiert das Protokoll aber nicht die Darstellung von Webseiten auf dem Browser)
Terminologie
• Web‐Seite beinhaltet Objekte
• z.B. HTML‐File, JPEG‐Image, Java‐Applet, Video‐Clip etc.
• Typischerweise ein Basis‐HTML‐File und mehrere darin referenzierte Objekte
• Objekte sind über Uniform Resource Locator (URL) adressierbar
• Besteht aus Host‐Name des Web‐Servers und Objekt‐
Pfadname auf dem Server, z.B.:
• www.someSchool.edu/someDepartment/picture.gif
• Host‐Name: www.someSchool.edu/
• Pfadname: /someDepartment/picture.gif
Beispiel‐Webserver:
• Apache HTTP Server
• Nginx
• Microsoft Internet Information Services
• Google Web Server
• always on
• fixed IP address
• port 80 or 8080
Beispiel‐Webclients:
Mosaic, Netscape, Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome, Microsoft Edge, Vivaldi
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
3
HTTP‐Beispiel
1.
2.
3.
4.
5.
6.
HTTP‐Client öffnet TCP‐Verbindung mit HTTP‐Server www.someSchool.edu auf Port 80
HTTP‐Client sendet Request /someDepartment/index.htm an HTTP‐
Server
HTTP‐Server ermittelt Objekt /someDepartment/index.htm und sendet Response über die TCP‐
Verbindung
HTTP‐Server schließt TCP‐Verbindung
HTTP‐Client empfängt Response und schließt die TCP‐Verbindung ebenfalls. HTTP‐Client findet in dem Objekt ein HTML‐File mit 10 referenzierten JPEG‐
Objekten
Die ersten vier Schritte werden für jedes JPEG‐Objekt wiederholt
H
S
TCP‐Verbindung herstellen
Request
/someDepartment/index.htm
Ist das immer so?
Grundlagen der Rechnernetze ‐ Applikationsschicht
Response
HTML‐File
TCP‐Verbindung
abbauen
Dieselben Schritte für jedes JPEG‐Objekt
4
Persistente und Nicht‐Persistente Verbindung
HTTP erlaubt zwei Verbindungsarten zwischen Client und Server:
• Persistent: eine TCP‐Verbindung für alle Request‐Response‐
Paare (typischerweise genutzt); Server schließt TCP‐
Verbindung, wenn vom Client bis zu einem Timeout keine weiteren Anfragen mehr kamen
• Nicht‐Persistent: separate TCP‐Verbindung für jedes Request‐Response‐Paar
Nicht‐Persistente Verbindungen bedeuten mehr Overhead
• 2*RTT Verzögerung für TCP‐Verbindungsherstellung
• Ressourcen auf Client und Server für TCP‐Variablen und Puffer (insbesondere auf Server der gleichzeitig viele Clients bedienen muss problematisch)
Aber: Nicht‐Persistente TCP‐Verbindungen ermöglichen Parallelität
Moderne Browser erlauben eine Festlegung der maximal erlaubten parallelen TCP‐Verbindungen.
• Jede TCP‐Verbindung behandelt einen Request/Response
• (Default in der Regel 5 bis 10 parallele TCP‐Verbindungen)
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
5
HTTP‐Request‐Nachricht
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr
Allgemeines Format
•
•
•
•
•
•
•
Beispiel
Nachrichten sind in ASCII (Format definiert über sp, cr und lf)
Request‐Line:
•
Methoden: GET, POST, HEAD, PUT und DELETE
•
Im Beispiel: Browser bittet um Objekt somedir/page.html. Brower verwendet HTTP Version 1.1
Header‐Lines: Host
•
Im Beispiel: Request geht an www.someschool.edu
•
Wieso nochmal? TCP‐Verbindung ist doch schon hergestellt?!?  siehe Web‐Proxy‐Cache
Header‐Lines: Connection: close  Client will keine Persistente Verbindung
Header‐Lines: User‐agent: Mozilla/4.0  Browser‐Typ
Header‐Lines: Accept‐langugage: fr  Beispiel eines Content‐Negotiation‐Headers (hier: falls vorhanden französische Variante des angefragten Contents)
Es gibt noch viele weitere Header‐Lines….
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
6
HTTP‐Request‐Nachricht
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr
Allgemeines Format
•
•
•
•
•
Beispiel
Method GET: vorhin schon besprochen
Method POST
•
Auch Anfrage einer Web‐Seite, aber Antwort hängt von übergebenen Parametern ab
•
Parameter stehen in Entity Body
•
Beispiel: User hat ein Form ausgefüllt (z.B. Suchwort für Suchmaschine)
•
Aber: Parameter können auch mittels GET in der URL übergeben werden (Beispiel Form mit zwei Eingabefeldern; ausfüllen mit monkeys und bananas; die URL ist dann www.somesite.com/animalsearch?monkeys&bananas)
Method HEAD: wie GET, nur Server lässt in seiner Antwort das angefragte Objekt weg (z.B. sinnvoll für Debugging)
Method PUT: sinnvoll für Web‐Publishing‐Tools; User kann damit Objekt auf gegebenen Objekt‐Pfad hoch laden
Method DELETE: offensichtlich sinnvoll, wenn es ein PUT gibt
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
7
HTTP‐Response‐Nachricht
HTTP/1.1 200 OK
Connection: close
Date: Thu, 07 Jul 2007 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 6 May 2007 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
Allgemeines Format
Beispiel
Im Unterschied zu Request steht bei Response im Header ein status Code; Übliche Status‐Codes
• 200 OK: Request erfolgreich
• 301 Moved Permanently: Objekt wurde verschoben; neue URL steht in Header‐Line Location:
• 400 Bad Request: Request wurde von Server nicht verstanden
• 404 Not Found: angefragtes Objekt existiert auf dem Server nicht
• 505 HTTP Version Not Supported: Angefragte HTTP‐Protokoll‐Version wird vom Server nicht unterstützt
Header‐Lines des Beispiels offensichtlich
Wozu eigentlich Last‐Modified?
Last‐Modified ist für Caching (auf Client und auch Proxy) sinnvoll
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
8
Client‐Server‐Interaction: Cookies
HTTP‐Server ist Stateless
Wie kann sich z.B. Amazon‐Server meinen aktuellen Einkaufswagen (sogar über viele Tage hinweg) merken?
Lösung: Cookies (siehe Beispiel)
1. Cookie‐Header‐Line im HTTP‐Response
(Set‐cookie: <eindeutige Nummer>)
2. Cookie‐Header‐Line im HTTP‐Request
(nachdem Cookie‐Nummer erlernt wurde)
3. Cookie‐File auf dem Client mit Einträgen
(host‐Name: Identifikationsnummer)
4. Backend‐Datenbank auf Server‐Seite
Damit lässt sich jede HTTP‐Aktivität des Clients mit der Cookie‐Nummer auf dem Web‐Server loggen.
Wenn User sich auch noch registrieren muss, dann lässt sich jede HTTP‐Aktivität des Users auf dem Web‐Server loggen.
Cookies vereinfachen vieles (z.B. Einkaufswagen)
Aber: nicht unumstritten bzgl. Privacy
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
9
Motivation für Web‐Caching
Beispiel‐Annahmen
• Mittlere Objekt‐Größe pro HTTP‐Reply: 1 Mbit
• Mittlere Anzahl an HTTP‐Requests: 15 Request/sec
• (HTTP‐Request‐Größe vernachlässigbar klein)
Damit ergibt sich La = ankommende Bits pro Sekunde:
La = 15/1 (req/sec / 1Mbit)
Als Verkehrsintensität (d.h. ankommende Bits pro Sekunde La dividiert durch Übertragungsrate R(access link) =
15 Mbps
R(LAN) = 100 Mbps
La/R(LAN) = 0.15
La/R(AccessLink) = 1.0
Queueing‐Theory:
Mehrere 10 mSec Delay im LAN
Delay am Access‐Link wächst über jede Grenze
Damit ist die mittlere Antwortzeit für einen HTTP‐Request in Bereich von Minuten oder gar mehr!
Wie Lösen?  Kapazität des Access‐Linkt erhöhen (z.B. auch 100 Mbps)  Kostenfaktor!  andere Lösung?
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
10
Web‐Caching
Web‐Cache bzw. Proxy‐Server erfüllt HTTP‐Anfragen für Web‐
Server.
Browser des Users so konfiguriert, dass alle HTTP‐Anfragen erst an den Proxy laufen.
Am Beispiel für Anfrage von http://www.someschool.edu/campus.gif
1. Browser stellt TCP‐Verbindung mit Proxy her uns sendet Request für das Objekt dort hin
2. Proxy prüft ob Objekt lokal gespeichert. Falls ja, antworte mit HTTP‐Response mit dem Objekt.
3. Falls nein, stelle TCP‐Verbindung mit Original‐Web‐Server (www.someschool.edu) her. Sende HTTP‐Request von Proxy an Web‐Server. Web‐Server antwortet mit Objekt auf Anfrage des Proxy.
4. Mit empfang des Objektes am Proxy, wird dieses an den Web‐
Client per HTTP‐Response geantwortet und das Objekt für zukünftige Anfragen im Proxy lokal gespeichert.
Damit können zukünftige Anfragen nach http://www.someschool.edu/campus.gif
ohne „Internet‐Verzögerung“ beantwortet werden. Außerdem: 
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
11
Web‐Caching
Beispiel‐Annahmen
• Mittlere Objekt‐Größe pro HTTP‐Reply: 1 Mbit
• Mittlere Anzahl an HTTP‐Requests: 15 Request/sec
• Typische Cache‐Hit‐Raten = im Bereich 0,2 bis 0,7; Annahme hier 0,4
• Annahme 2 Sekunden‐Internetverzögerung
Damit ergibt sich La = ankommende Bits pro Sekunde:
La = 15/1 (req/sec / 1Mbit)
R(access link) =
15 Mbps
R(LAN) = 100 Mbps
Als Verkehrsintensität (d.h. ankommende Bits pro Sekunde La dividiert durch Übertragungsrate La/R(LAN) = 0.15
La/R(AccessLink) = 1.0 * 0,6 (d.h. nur die Cache‐Misses)
Queueing‐Theory:
Mehrere 10 mSec delay im LAN und Mehrere 10 mSec am Access‐Link Mit Damit ist die mittlere Antwortzeit für einen HTTP‐Request:
0,4 * 0,01 sek + 0,6 * (2,0 + 0,01 sek) ~ 1,2 sek anstatt viele Minuten!
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
12
Web‐Caching: Conditional GET
Problem: Objekt im Cache ist nicht mehr aktuell, wenn das Objekt auf dem Web‐Server verändert wurde.
Lösung: condidional GET
• Request‐Nachricht verwendet GET‐Methode und beinhaltet
• Header‐Line If‐Modified‐Since: Beispiel: (www.exotiquecuisine.com/fruit/kiwi.gif)
Zunächst sendet ein Proxy auf Anfrage eines Clients an den Web‐Server
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
Darauf antwortet der Web‐Server an den Proxy
HTTP/1.1 200 OK
Date: Thu, 7 Jul 2007 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 4 Jul 2007 09:23:24
Content-Type: image/gif
(data data data data data ...)
Grundlagen der Rechnernetze ‐ Applikationsschicht
13
Web‐Caching: Conditional GET
Proxy leitet das Objet an Web‐Client und speichert das Objekt lokal inklusive der Last‐
Modified‐Information
Eine Woche später fragt derselbe oder irgend ein anderer Client das Objekt im Proxy nach
Proxy macht dann einen Up‐to‐date‐Check und sendet hierzu an den Web‐Server GET /fruit/kiwi.gif HTTP/1.1
Host: exotiquecuisine.com
If-modified-since: Wed, 4 Jul 2007 09:23:24
Der Web‐Server antwortet immer mit einem Response, allerdings, wenn das Objekt nicht geändert wurde ist die Antwort einfach:
HTTP/1.1 304 Not Modified
Date: Thu, 14 Jul 2007 15:39:29
Server: Apache/1.3.0 (Unix)
Leerer Body
Grundlagen der Rechnernetze ‐ Applikationsschicht
14
Übersicht
•
•
•
•
Web und HTTP
File Transfer: FTP
Electronic Mail
Domain Name System (DNS)
Grundlagen der Rechnernetze ‐ Applikationsschicht
15
File Transfer: FTP
File Transfer Protocol (FTP): RFC 959:
• Bewegen von Dateien zwischen lokalem Dateisystem (FTP‐Client) und Remote‐Dateisystem (FTP‐
Server)
• User authentifiziert sich per Username und Passwort
• Anschließend Dateiaustausch
Zwei TCP‐Verbindungen (Control‐Connection und Data‐Connection)
• Port 21: Control‐Nachrichten (persistente TCP‐Verbindung)
• Port 20: Datennachrichten (nicht‐persistent, d.h. für jede Datei eine separate Verbindung)
Control‐Nachrichten von FTP sind out‐of‐band (d.h. Trennung zwischen Control‐ und Daten‐Kanal)
Control‐Nachrichten z.B. von HTTP sind hingegen in‐band (d.h. ein Kanal für Control und Daten)
Anders als HTTP speichert FTP während einer User‐Session Zustand (z.B. Position im Dateibaum)
Damit FTP stärker limitiert bzgl. Gesamtanzahl erlaubter aktueller bedienter User
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
16
FTP: übliche Commands und Replies
Commands und Replies über Control‐Kanal in lesbarer 7‐Bit‐ASCII‐Codierung
CRLF nach jedem Command
Jeder Command besteht aus vier Buchstaben und Argument. Beispiele:
USER username: zum senden der User‐Identifikation
PASS password: zum Senden des User‐Passwortes
LIST: Erfrage Liste aller Dateien/Unterverzeichnisse in aktuellem besuchten Verzeichnis
RETR filename: Herunterladen der Datei
STOR filename: Hochladen der Datei
In der Regel erzeugt ein Command vom Client genau einen Reply vom Server.
Reply besteht aus Drei Ziffern und optionalem erklärendem Text. Beispiele:
331 Username OK, password required
125 Data connection already open; transfer starting
425 Can‘t open data connection
452 Error writing file
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
17
Übersicht
•
•
•
•
Web und HTTP
File Transfer: FTP
Electronic Mail
Domain Name System (DNS)
Grundlagen der Rechnernetze ‐ Applikationsschicht
18
Email: eine High‐Level‐Sicht
Drei wesentliche Komponenten
• User Agent
• Z.B. mit GUI: Outlook, Apple Mail, Thunderbird, …
• Z.B. textbasiert: mail, pine, elm
• Mail‐Server
• Mailbox für jeden User
• Outgoing‐Message‐Queue
• Simple Mail Transfer Protocol (SMTP)
• Auf Basis von TCP
• Zur Kommunikation zwischen Mail‐Servern
• Client‐Seite zum Empfang von Mails
• Server Seite zum Senden von Mails
Mail‐Server implementiert SMTP und agiert damit als Client und als Server
Kommunikation zwischen User‐Agent und Mail‐
Server
• Authentifizierung mittels Username und Passwort
• Zugriff auf Mailbox (siehe POP3, IMAP und Web)
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
19
Simple Mail Transfer Protocol (SMTP)
SMTP‐Fakten
• Definition in RFC 2821
• Mail‐Body (d.h. der Inhalt) aus historischen Gründen auf 7‐Bit‐ASCII eingeschränkt 
Aufwand für andere Zeichensätze und Binär‐
Daten
• Normalerweise werden keine Intermediate‐Mail‐
Server verwendet
• TCP‐Verbindungsherstellung von SMTP‐
Client mit SMTP‐Server (z.B. Port 25)
• Nach TCP‐Verbindung Handshaking‐Phase: z.B. mitteilen von Sender‐ und Ziel‐
Mailadresse und Mailversand
• Prozess wird über dieselbe TCP‐Verbindung für weitere Nachrichten wiederholt (d.h. persistende TCP‐Verbindung)
• Was, wenn ein Mailserver nicht erreichbar?  wiederholte TCP‐
Verbindungsherstellungen und Zustellungsversuche
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
20
Simple Mail Transfer Protocol (SMTP)
Beispiel‐Transcript zu Nachrichtenaustausch nach TPC‐
Verbindungsherstellung zwischen SMTP‐Client und ‐Server:
Client: crepes.fr
Server: hamburger.edu
Mail‐Text: „Do you like ketchup? How about pickles?“
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected] ... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with „.“ on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Reply‐Code (und optionaler Text) auf jeden eingehenden Befehl.
Jede Zeile endet mit CRLF. Textende durch „CRLF.CRLF“ dargestellt.
Danach kann erneut MAIL FROM: crepes.fr für weitere Mail stehen.
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
21
Mail‐Nachrichtenformate und MIME
Mail‐Content (Achtung: nicht SMTP) beinhaltet neben dem eigentlichen Text – d.h. dem Body – zusätzliche Informationen:
• Zusätzliche Header‐Lines (separiert durch CRLF)
• Format wie aus HTTP bekannt (lesbarer Text mit Keyword‐
Value‐Paar durch „:“ getrennt)
• Definiert in RFC 822
• Immer erforderliche Keywords sind To: und From:
• Optionale Keywords z.B. Subject:
• Body folgt nach einer Blank‐Line
• Beispiel:
From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.
Text text text
Grundlagen der Rechnernetze ‐ Applikationsschicht
22
Mail‐Nachrichtenformate und MIME
Multipurpose Internet Mail Extensions (MIME) zum Versenden von Multimedia und non‐ASCII‐Text
• Verwendung weitere Header definiert in RFC 2045 und 2046 als MIME‐
Extensions zu RFC 822
• Zwei wesentliche MIME‐Header
• Content‐Type: erforderlich zur Darstellung auf dem User‐Agent
• Content‐Transfer‐Encoding: erforderlich für den Transport von Binary‐
Data über 7‐Bit ASCII (Beispiel base64)
• Beispiel
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
(base64 encoded data ...............
.............. base64 encoded data )
Grundlagen der Rechnernetze ‐ Applikationsschicht
23
Mail‐Nachrichtenformate und MIME
Empfangender SMTP‐Server fügt noch Recived: Header‐Line(s) hinzu
Beispiel:
Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39
GMT
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
(base64 encoded data ...............
.............. base64 encoded data )
Durch Mail‐Forwarding kann auch ein ganzer Pfad von Received angehangen sein.
Beislpielsweise: Mail‐Frowarding von hamburger.edu nach sushi.jp
Received: from hamburger.edu by sushi.jp; 3 Jul 01 15:30:01
GMT
Received: from crepes.fr by hamburger.edu; 3 Jul 01 15:17:39
GMT
Grundlagen der Rechnernetze ‐ Applikationsschicht
24
Mail‐Access‐Protokolle
Warum eigentlich die Trennung zwischen User‐Agent und Mail‐Server
• User‐Agent des Empfängers muss sonst immer an sein
• User‐Agent des Senders braucht im Falle nicht‐Erreichbarkeit die Übertragungsversuche (z.B. alle 30 Minuten) nicht selbst zu unternehmen
Damit werden aber Mail‐Access‐Protokolle notwendig
• POP3 (Post Office Protocol – Version 3)
• IMAP (Internet Mail Access‐Protocol)
• Web‐Basiert (HTTP)
Aber auch SMTP wird auf User‐Agent verwendet: zum versenden von Mail auf den eigenen Mail‐Server
POP3,
IMAP,
HTTP
SMTP,
HTTP
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
25
Mail‐Access‐Protokolle: POP3
Einfaches Protokoll definiert in RFC 1939
• TCP‐Verbindungsherstellung mit Mail‐Server auf Port 110
• Anschließend drei Phasen: authorization, transaction, update
Authorization: Authentifizierung des User mittels Username und Passwort
• user <username>
• pass <password>
Transaction: Nachrichten empfangen, Nachrichten zur Löschung markieren, Löschungsmarkierungen aufheben, Mail‐Statistiken erfragen
Update: nachdem Client quit gesendet hat; Mail‐Server löscht die mit delete
markierten Nachrichten
Im Prinzip zwei Varianten möglich:
• Variante: download‐and‐delete
• Variante: downlad‐and‐keep
Grundlagen der Rechnernetze ‐ Applikationsschicht
26
Mail‐Access‐Protokolle: POP3
Beispiel einer Download‐and‐Delete‐Transaction (c: client, s: server)
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: (blah blah blah .........
S: .........................
S: ......... blah blah blah)
S: .
C: dele 1
C: retr 2
S: (blah blah blah .........
S: .........................
S: ......... blah blah blah)
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
Grundlagen der Rechnernetze ‐ Applikationsschicht
27
Mail‐Access‐Protokolle: IMAP, Web‐basiert
POP3 und mehrere Client‐Rechner (z.B. Desktop‐PC, Notebook)?
• Nur downlad‐and‐keep sinnvoll
• Mailbox aufräumen und in Foldern verwalten ist kompliziert, wenn alle Rechner konsistent gehalten werden sollen
Bessere Lösung: IMAP (RFC 3501)
• Nachrichten verbleiben auf dem Server und werden dort verwaltet
(herunter geladene Nachrichten liegen aber auch lokal vor)
• Jede Mail‐Nachricht ist einem Folder zugeordnet (z.B. Inbox)
• User kann Nachrichten auf dem Server löschen und in Folder verschieben
• Nachrichten können auf dem Server durchsucht werden
• Nachrichten können nur Teilweise herunter geladen werden (z.B. nur Header oder nur ein Teil einer Multipart‐MIME‐Message)
Alternative Lösung: Web‐basiert (HTTP)
• Email‐Zugang über Browser (z.B. Google‐Mail oder SoGo an unserer Uni)
• Kommunikation mit der Mailbox über Browser (HTTP‐basiert)
• HTTP‐Kommunikation aber nur zwischen User‐Agent und Mail‐Server
• Kommunikation der Mail‐Server weiterhin über SMTP
Grundlagen der Rechnernetze ‐ Applikationsschicht
28
Übersicht
•
•
•
•
Web und HTTP
File Transfer: FTP
Electronic Mail
Domain Name System (DNS)
Grundlagen der Rechnernetze ‐ Applikationsschicht
29
DNS Übersicht
Problem:
• IP braucht IP‐Adressen (z.B. 121.7.106.83)
• Menschen brauchen Host‐Namen (www.uni‐koblenz.de)
Aufgabe von DNS: Directory‐Service zur Übersetzung von Host‐Name in IP‐
Adresse
• DNS ist eine verteilte Datenbank auf Basis einer Hierarchie von DNS‐Servern (häufig UNIX‐Maschinen auf denen Berkeley Internet Name Domain (BIND) läuft)
• DNS ist ein Protokoll zur Abfrage von Übersetzungen auf den DNS‐Servern
DNS ist auf der Anwendungsschicht
• Läuft nur auf den End‐Systemen (Client, Server) nicht auf Routern
• Verwendet UDP (Port 53)
Spezifikation: RFC 1034, RFC 1035 und Aktualisierungen in weiteren RFCs
Grundlagen der Rechnernetze ‐ Applikationsschicht
30
DNS Übersicht
• Client‐Server‐Prinzip
• Beispiel: HTTP‐Anfrage an Web‐Server www.someschool.edu erfordert DNS Abfrage der IP
1. Client‐Seitig: DNS‐Anwendung
2. Browser extrahiert Host‐Name www.someschool.edu aus der URL und ruft damit DNS‐Anwendung auf (z.B. UNIX‐System: gethostbyname())
3. DNS‐Client sendet Anfrage mit dem Hostnamen an DNS‐Server
4. DNS‐Client empfängt irgendwann (typischerweise im Bereich Millisekunden bis Sekunden) eine DNS‐Antwort mit der IP‐Adresse zu www.someschool.edu 5. Browser kann TCP‐Verbindung auf Basis von IP‐Adresse und Port (z.B. Port 80 für HTTP‐Server) herstellen
H
N
Client:
DNS‐Client und
z.B. Web‐Browser
S
Server:
DNS‐Server
Grundlagen der Rechnernetze ‐ Einführung
31
DNS Übersicht
DNS macht/kann aber noch mehr
• Host Aliasing
• Beispiel eines Canonical Host‐Namens: relay1.wes‐coast.enterprise.com
• Beispiel eines Alias‐Host‐Namens: enterprise.com, www.enterprise.com
• DNS zur Abfrage des Canonical‐Host‐Names zu einem Alias‐Host‐Name
• Mail Server Aliasing
• Beispiel eines Canonical‐Host‐Name eines Mail‐Servers: relay1.west‐
coast.hotmail.com
• Beipiel einer Email‐Adresse: [email protected]
• DNS übersetzt Alias‐Host‐Name Hotmail.com ist den Canonical‐Host‐
Name
• (Bemerkung: Mail‐Server und Web‐Server können identische (aliased) Host‐Namen haben)
• Load Distribution
• Replizierte Server (z.B. für stark frequentierte Seiten wie cnn.com)
• DNS liefert liste von IP‐Adressen; Client nimmt in der Regel die erste IP
• Rotiere IP‐Reihenfolge
Grundlagen der Rechnernetze ‐ Applikationsschicht
32
DNS Übersicht
Philosophisches
• Normalerwiese interagiert der User direkt mit den Application‐Layer‐
Protokollen (Web, Mail, FTP etc.)
• DNS ist für viele andere Dienste ein Core‐Internet‐Service auf der auf Anwendungsebene
• Typisches Beispiel der Internet Philosophie: vieles der Komplexität des Internets ist am Rand des Internets
Grundlagen der Rechnernetze ‐ Applikationsschicht
33
DNS: verteilte, hierarchische Datenbank
Warum nicht ein zentraler DNS‐Server?
• Single‐Point‐of‐Failure (SPOF) – ein Serverausfall legt das gesamte Internet lahm
• Verkehrsaufkommen – fast jeder Internet‐Host braucht DNS
• Kommunikationsdistanz – Problem den einen DNS‐Server sinnvoll auf dem Globus zu plazieren
• Verwaltung – fast jeder Server‐Host muss über DNS auffindbar sein
Also: wie immer, ein Skalierbarkeitsproblem. Es kommt nur eine verteilte Lösung in Frage.
Außerdem nicht ein einziger Provider: hierarchische Organisation
Grundlagen der Rechnernetze ‐ Applikationsschicht
34
DNS: verteilte, hierarchische Datenbank
Root
DNS‐Server
com
DNS‐Server
yahoo.com
DNS‐Server
amazon.com
DNS‐Server
org
DNS‐Server
pbs.org
DNS‐Server
Root DNS Server
edu
DNS‐Server
poly.edu
DNS‐Server
umass.edu
DNS‐Server
Top‐Level‐Domain
(TLD) DNS Server
Authoritative
DNS Server
Kleiner Ausschnitt aus der DNS Server‐Hierarchie(*)
Root‐DNS‐Server
• Root‐Server werden von verschiedenen Institutionen betrieben. Die Internet Corporation for Assigned Names and
Numbers (ICANN) koordiniert den Betrieb
• 13 Root‐DNS‐Server (A bis M)
• Allerdings steht jeder Buchstabe für einen Cluster von replizierten Servern
• (Bemerkung: Anycast, Alternative Roots)
(*) Beispiel und Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Grundlagen der Rechnernetze ‐ Applikationsschicht
35
DNS: verteilte, hierarchische Datenbank
Root
DNS‐Server
com
DNS‐Server
yahoo.com
DNS‐Server
amazon.com
DNS‐Server
org
DNS‐Server
pbs.org
DNS‐Server
Root DNS Server
edu
DNS‐Server
poly.edu
DNS‐Server
umass.edu
DNS‐Server
Top‐Level‐Domain
(TLD) DNS Server
Authoritative
DNS Server
Kleiner Ausschnitt aus der DNS Server‐Hierarchie(*)
Top‐Level‐Domain‐Server
• Beispiel: com, org, net, edu, gov
• Beispiel für Länder‐Top‐Level‐Domains: de, uk, fr, ca, jp
• Verwaltet durch Unternehmen
Authoritative DNS Server
• Öffentlich erreichbare Server eines Unternehmens / einer Einrichtung müssen über solche DNS‐Server erreichbar sein
• Kann über eigene DNS‐Server oder über einen Dienstleister realisiert sein
(*) Beispiel und Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Grundlagen der Rechnernetze ‐ Applikationsschicht
36
DNS: verteilte, hierarchische Datenbank
Root
DNS‐Server
org
DNS‐Server
com
DNS‐Server
yahoo.com
DNS‐Server
Root DNS Server
amazon.com
DNS‐Server
edu
DNS‐Server
pbs.org
DNS‐Server
poly.edu
DNS‐Server
umass.edu
DNS‐Server
Top‐Level‐Domain
(TLD) DNS Server
Authoritative
DNS Server
Kleiner Ausschnitt aus der DNS Server‐Hierarchie(*)
H
N
S
Ein weiterer wichtiger DNS‐Server: Local DNS‐Server
• Durch ISP (z.B. Uni/Campus, Unternehmen, lokaler ISP) realisiert
• Bekannt gemacht in der Regel über DHCP (siehe z.B. Netzstatus des Betriebssystems)
• In der Regel nahe am Host
• Agiert als Proxy zwischen Host und DNS‐Infrastruktur
(*) Beispiel und Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Grundlagen der Rechnernetze ‐ Applikationsschicht
37
Beispiel DNS‐Anfrage
1.
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Anfrage „gaia.cs.umass.edu“ am local
DNS‐Server dns.poly.edu
2. Anfrage „gaia.cs.umass.edu“ am Root‐DNS
3. Ergebnis: Liste von TLD‐Server, die für edu zuständig sind
4. Anfrage „gaia.cs.umass.edu“ an einen der TLD‐Server
5. Ergebnis: IP des zuständigen auth. DNS‐Server dns.cs.umass.edu
6. Anfrage „gaia.cs.umass.edu“ an DNS‐
Server dns.cs.umass.edu
7. Ergebnis: IP von gaia.cs.umass.edu
8. Zurücksenden des Ergbnisses von dns.poly.edu an cis.poly.edu
Damit: 4 Anfragenachrichten und 4 Antwortnachrichten für eine einzige DNS‐
Abfrage!?! Noch schlimmer:
Grundlagen der Rechnernetze ‐ Applikationsschicht
38
Beispiel DNS‐Anfrage
TLD‐Server muss den auth. Server nicht unbedingt schon kennen; TLD‐Server kennt nur einen intermediate DNS‐Server
• Beispiel: intermediate‐Server dns.umass.edu und jedes Department hat einen eigenen DNS‐Server, z.B. dns.cs.umass.edu
Damit: 5 Anfragenachrichten und 5 Antwortnachrichten für eine einzige DNS‐
Abfrage!?!
Lösung? Caching!
• DNS‐Server‐Antworten werden in Cache gespeichert
• Signifikante Reduktion von Nachrichten und Latenz
• Zuordnung von Domain‐Name auf IP ist nicht permanent; Einträge verweilen in Cache bis zu einem Timeout (z.B. zwei Tage)
•
dns.umass.edu
dns.cs.umass.edu
Abbildung nach Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Grundlagen der Rechnernetze ‐ Applikationsschicht
39
DNS‐Anfrage: rekursiv versus iterativ
Iterative
Query
Rekursive
Query
In der Regel:
• Anfrage an Local DNS‐Server rekursiv
• Der Rest Iterativ
• (Am häufigsten jedoch Cache‐Hit)
Abbildungen aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Grundlagen der Rechnernetze ‐ Applikationsschicht
40
DNS‐Records
DNS‐Server speichern Ressource‐Records (RRs)
DNS‐Reply‐Nachrichten beinhalten ein oder mehrere auf die Anfrage passende RRs.
RRs bestehen aus 4‐Tupel (Name, Value, Type, TTL)
TTL ist die Lebensdauer des RR (wird danach aus Cache entfernt)
(Name, Value) hängt von Type ab
• Type = A: Name ist Host‐Name und Value ist IP‐Adresse
Beispiel: (relay1.bar.foo.com, 145.37.93.126, A)
• Type = NS: Name ist Domain und Name ist der Name eines auth. DNS‐Server, der die IP‐Adressen der Hosts bestimmen kann
Beispiel: (foo.com, dns.foo.com, NS)
• Type = CNAME: Name ist der canonical Host‐Name für den Alias‐Host‐Name
Beispiel: (foo.com, relay1.bar.foo.com, CNAME)
• Type = MX: Name ist der canonical Name eines Mail‐Servers zu einem Alias‐Host‐Name
Beispiel: (foo.com, mail.bar.foo.com, MX)
• Erlaubt ein und denselben Alias für Mail‐Server und z.B. Web‐Server
Beispiel: foo.com für [email protected] und ww.foo.com
• Unterscheidung durch Anfrage entweder MX oder CNAME
Grundlagen der Rechnernetze ‐ Applikationsschicht
41
DNS‐Nachrichten
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
DNS‐Query und ‐Reply‐Nachrichten haben dasselbe Format
12 Byte Header
• Identification: Client kann damit Replay seinem Request zuordnen (z.B. mehrere gleichzeitige ausstehende Requests)
• Flags:
• 1‐Bit Query/Reply‐Flag: Unterscheidung von Query‐ und Reply‐Nachricht
• 1‐Bit Authoritative‐Flag: 1, wenn Server authoritative für den angefragten Namen
• 1‐Bit Recursion: in Query: Recursion‐Desired in Reply: Recursion‐Available
• Number‐Fields: Anzahl Vorkommen der folgenden vier möglichen Datentypen
Grundlagen der Rechnernetze ‐ Applikationsschicht
42
DNS‐Nachrichten
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
Questions: Einträge der Form (Name, Type) (z.B. Type A oder Type MX)
Answers: Antwort in Form von RRs (Name, Value, Type, TTL)
• Reply kann mehrere RRs enthalten
• z.B. Host mit mehreren IP‐Adressen für Load‐Balancing
Authority: Reply‐Einträge über zuständige Authoritative‐Server
Additional Information: Beispiel „Reply auf MX‐Query: Ergebnis = canonical Name des Mail‐Servers und zusätzlich Type A Record für dessen IP‐Adresse“
Grundlagen der Rechnernetze ‐ Applikationsschicht
43
Eintragen von RR in die DNS Datenbank
Beispiel: Neue Firma Network Utopia mit Domain‐Namen networkutopia.com
Networkutopia.com muss über einen Registrar angemeldet werden
• Registrar bietet solche kostenpflichtige Dienstleistung an
• Registrare können auf www.internic.net gefunden werden
Ggf. wird auch IP eines primären und sekundären Authoritativen DNS‐Server angegeben
• Zum Beispiel: dns1.networkutopia.com und dns2.networkutopia.com mit 212.212.212.1 und 212.212.212.2
• Registrar veranlasst Eintragung von Type NS und Type A Eintrag in TLD com, d.h. für primary authoritative Server networkutopia.com:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
Dann noch ein Web‐Server und Mail‐Server‐Eintrag in den eigenen authoritativen DNS‐
Server
• Type A Eintrag für Web‐Server www.networkutopia.com und
• Type MX Eintrag für Mail‐Server mail.networkutopia.com
In der Regel alles noch einfacher: Provider stellt für Kunden die Server zur Verfügung. Kunde registriert über Provider (der ist dann auch der Registrar) einfach eine Domain.
Grundlagen der Rechnernetze ‐ Applikationsschicht
44
Robustheit von DNS
DNS ist eine kritische Komponente der Internet‐Infrastruktur
Diskussion möglicher Angriffe
• DDoS‐Attacke gegen DNS‐Root‐Server
• Auf Basis von ICMP‐Ping oder
• Fluten mit DNS‐Anfragen bzgl. Top‐Level‐Domains (z.B. alle Server für die Top‐Level‐Domain com)
• Man‐in‐the‐Middle‐Attack
• Abfangen von Client‐Queries oder
• Eintragen von falschen Cache‐Einträgen
• Nutzen der DNS‐Infrastruktur, für DDoS‐Attacke auf authoritative
DNS‐Server mit gefälschten Source‐Adressen
DNS ist aber sehr robust
• DNS‐Server Konfiguration
• Caching
Grundlagen der Rechnernetze ‐ Applikationsschicht
45
Zusammenfassung und Literatur
Grundlagen der Rechnernetze ‐ Applikationsschicht
46
Zusammenfassung
• Anwendung versus Anwendungsprotokoll (z.B. Email‐Client und Server versus SMTP, POP3, IMAP, HTTP)
• Anwendungen und deren Anwendungsprotokolle haben unterschiedliche Anforderungen an das Transport‐Protokoll:
Besonderheit DNS: Dienst auf Anwendungsebene, welcher von fast allen anderen Anwendungen genutzt wird
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
47
Zusammenfassung
• Damit ergibt sich in der Regel Auswahl zwischen TCP oder UDP
• Was ist mit Sicherheit? Erweiterung von TCP für Sicherheit auf Anwendungsebene mittels SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security)
• Was ist mit Bandbreiten‐ und Latenz‐Garantien? Anwendungen mit solchen Anforderungen „laufen in der Regel“; können mit nichtvorhandenen Garantien im gewissen Rahmen umgehen.
Grundlagen der Rechnernetze ‐ Applikationsschicht
Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008
48
Literatur
• James F. Kurose, Keith W. Ross, „Computer Networking: A Top‐Down Approach“, 4th Edition, 2008
– 2.1.4 Transport Services Provided by the Internet
– 2.2 The Web and HTTP
– 2.3 File Transfer: FTP
– 2.4 Electronic Mail in the Internet
– 2.5 DNS‐The Internet‘s Directory Service
– 2.9 Summary
Grundlagen der Rechnernetze ‐ Applikationsschicht
49