Anwendungsschicht

Inhalt der Vorlesung ! 
! 
! 
! 
! 
! 
Einführung Anwendungsschicht Transportschicht Netzwerkschicht Verbindungsschicht Physikalische Schicht [RN] Sommer 2014 Anwendungsschicht 1 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 2 Einführung ! 
Netzwerkanwendung ! 
! 
! 
! 
! 
! 
Anwendungsprozesse auf verschiedenen Endsystemen (Hosts), die miSels Nachrichten über ein Netzwerk kommunizieren kann direkt unter Verwendung der Dienste der Transportschicht implemenOert werden standardisierte Anwendungen benutzen ein Anwendungsprotokoll, das das Format der Nachrichten und das Verhalten beim Empfang von Nachrichten festlegt z.B: Web-­‐Browser und -­‐Server die unteren Schichten und der Netzwerkkern benöOgen keine Kenntnis der Anwendung einfache Verbreitung, große Dynamik [RN] Sommer 2014 Anwendungsschicht application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
3 Einführung ! 
Client-­‐Server-­‐Paradigma ! 
! 
! 
Server stellt Dienst zur Verfügung, der von Client angefordert wird übliches Paradigma von vielen tradiOonellen Anwendungen, wie z.B. Web-­‐Browser und –Server typische Eigenscha]en des Servers !   leistungsfähig !   immer verfügbar ! 
typische Eigenscha]en der Clients !   nur manchmal verbunden !   kommunizieren mit Server, nicht untereinander [RN] Sommer 2014 Anwendungsschicht 4 Einführung ! 
! 
Client-­‐Server-­‐Paradigma ist zentralisierte Architektur Weitere Paradigmen ! 
! 
! 
! 
wechselnde Rolle von Client und Server: Hosts übernehmen mal die eine, mal die andere Rolle (z.B. bei Web-­‐Caching oder SMTP) verteilte Anwendung: besteht aus mehreren unabhängigen Anwendungen, die zusammen wie eine einzelne Anwendung erscheinen (z.B. WebShop mit Web-­‐Server, ApplikaOons-­‐Server und Datenbank), KoordinaOon ist zwar verteilt, findet aber für das Gesamtsystem staS noch stärker dezentrale Architektur: autonome sich selbst organisierende Systeme ohne globale Steuerung (z.B. einige Peer-­‐to-­‐Peer-­‐Anwendungen wie Gnutella, Chord) Hybridarchitektur: zur IniOalisierung ist eine zentrale Architektur nöOg, die Anwendung findet dann dezentral direkt zwischen Hosts staS (z.B. bei Session IniOaOon Protocol, SIP oder bei manchen Peer-­‐to-­‐Peer-­‐
Anwendungen wie BiSorrent) [RN] Sommer 2014 Anwendungsschicht 5 Einführung ! 
Varianten des Client-­‐Server-­‐Paradigmas Client-Computer
Thin Client
Benutzungsschnittstelle
Fat Client
Benutzungsschnittstelle
Benutzungsschnittstelle
Benutzungsschnittstelle
Benutzungsschnittstelle
Anwendung
Anwendung
Anwendung
Datenbank
Benutzungsschnittstelle
Anwendung
Anwendung
Anwendung
Datenbank
Datenbank
Datenbank
Fat Server
Datenbank
Datenbank
Thin Server
Server-Computer
[RN] Sommer 2014 Anwendungsschicht 6 Einführung ! 
Dienste der Transportschicht ! 
im Internet gibt es zwei dominierende Transportprotokolle !   TCP: verbindungsorienOert (abstrakte Sicht des Versendens eines Bytestroms), zuverlässig !   UDP: verbindungslos (Versenden einzelner Datagramme), unzuverlässig ! 
! 
! 
werden meist im Betriebssystem realisiert die meisten Betriebssysteme bieten Socket-­‐SchniBstelle, die durch Programmiersprachen als API angeboten wird mit Socket kann festgelegt werden !   Transportprotokoll (TCP oder UDP) !   IP-­‐Adresse von Sende-­‐ und Zielhost !   Portnummern (um Anwendungen auf Hosts zu unterscheiden) ! 
und so können Anwendungen programmiert werden … [RN] Sommer 2014 Anwendungsschicht 7 Einführung ! 
QuanOtaOve Anforderungen von Anwendungen ! 
Verlust !   nicht tolerierbar bei Dateitransfer, Online-­‐Banking etc. !   teilweise tolerierbar bei MulOmedia ! 
Bitrate !   tradiOonelle Anwendungen wie FTP, e-­‐mail und HTTP benöOgen keine feste Bitrate, sind aber „besser“, wenn sie viel Bitrate erhalten („Best-­‐Effort-­‐Verkehr“, „elasOsche Anwendungen“) !   Echtzeit-­‐MulOmedia benöOgt Mindest-­‐Bitrate ! 
Verzögerungszeit !   tradiOonelle Anwendungen benöOgen keine maximale Verzögerungszeit, sind aber wieder „besser“ bei kurzen Zeiten !   Echtzeit-­‐MulOmedia und interakOve Spiele benöOgen kurze Verzögerungszeit !   Steuerungen technischer Geräte benöOgen o] GaranOe einer maximalen Verzögerungszeit [RN] Sommer 2014 Anwendungsschicht 8 Einführung ! 
QuanOtaOve Anforderungen von Anwendungen Anwendung
Verlust
Bitrate
Verzögerungszeit
Dateitransfer
kein Verlust
elastisch
keine harte Grenze
e-mail
kein Verlust
elastisch
keine harte Grenze
Web-Dokumente
kein Verlust
elastisch
keine harte Grenze
Echtzeit-Multimedia
Verlust tolerierbar
Audio: Kbps - Mbps
Video: 10 Kbps - 5 Mbps
150 ms
Einwegverzögerung
unbemerkt
Streaming von
Multimedia
Verlust tolerierbar
wie oben
einige s
Interaktive Spiele
Verlust tolerierbar
Kbps – 10 Kbps
einige 100 ms
Automatisierung
kein Verlust
Kbps
oft harte Grenzen,
z.B. einige ms
Instant Messaging
kein Verlust
elastisch
„kommt darauf an“
[RN] Sommer 2014 Anwendungsschicht 9 Einführung ! 
Einige bekannte Anwendungsprotokolle und das darunterliegende Transportprotokoll Anwendung
Anwendungsprotokoll
verwendetes
Transportprotokoll
e-mail
SMTP [RFC 2821]
TCP
Remote Terminal Access
Telnet [RFC 854]
TCP
Web
HTTP [RFC 2616]
TCP
Dateitransfer
FTP [RFC 959]
TCP
Remote File Server
NFS [McKusik 1996]
UDP or TCP
Streaming Multimedia
RTP, proprietär
UDP or TCP
Internettelefonie
RTP, proprietär
meistens UDP
[RN] Sommer 2014 Anwendungsschicht 10 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 11 HTTP ! 
Ablauf ! 
! 
! 
! 
! 
Benutzer gibt Uniform Resource Locator (URL) in Web-­‐Browser ein URL enthält Host-­‐Namen eines Web-­‐Servers und den Pfad zu einem Objekt (Datei) dort Web-­‐Browser stellt Anfrage an Web-­‐Server für dieses Objekt Web-­‐Server liefert Objekt an Web-­‐Browser zurück Web-­‐Browser stellt Objekt in für den Benutzer lesbarer Form dar [RN] Sommer 2014 Anwendungsschicht PC mit
MS Explorer
Server
mit
Apache WebServer
Mac mit
Firefox
12 HTTP: Anfragenachrichten ! 
Format der Anfragenachrichten Anfragezeile
method
sp
URL
sp
version
header field name: sp
value
cr lf
header field name: sp
value
cr lf
cr lf
Kopfzeilen
Leerzeile
cr lf
Rumpf
[RN] Sommer 2014 Anwendungsschicht 13 HTTP: Anfragenachrichten ! 
Methoden ! 
! 
! 
! 
! 
Kopfzeilen ! 
! 
Typ/Wert-­‐Paare, Typen: Host, User-­‐agent, … Rumpf ! 
! 
GET: Abruf eines Dokuments, besteht aus Methode, URL, Version HEAD: Abruf von MetainformaOonen eines Dokuments POST: Ausgabe von InformaOonen an Server Put, Delete, Trace, OpQons leer bei GET, kann bei POST Inhalt haben Beispiel Anfragenachricht: [RN] Sommer 2014 Anwendungsschicht GET /somedir/page.html HTTP/
1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
14 HTTP: Antwortnachrichten ! 
Format der Antwortnachrichten Statuszeile
version
sp status code sp
phrase
header field name: sp
value
cr lf
header field name: sp
value
cr lf
cr lf
Kopfzeilen
Leerzeile
cr lf
Rumpf
[RN] Sommer 2014 Anwendungsschicht 15 HTTP: Antwortnachrichten ! 
Mögliche Codes in der Statuszeile ! 
! 
! 
! 
! 
! 
200 OK („alles klar“) 301 Moved Permanently (RedirecOon: Objekt zu finden unter LocaOon: …) 400 Bad Request (Anfragenachricht nicht verstanden) 404 Not Found (Objekt nicht gefunden) 505 HTTP Version Not Supported Beispiel-­‐ Antwortnachricht: [RN] Sommer 2014 HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15
GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …
Content-Length: 6821
Content-Type: text/html
data data data data data ...
Anwendungsschicht 16 HTTP: Ablauf ! 
HTTP-­‐Ablauf ! 
nicht-­‐persistentes HTTP !   für jedes Objekt wird einzelne TCP-­‐Verbindung geöffnet, Server beendet sie sofort nach dem Senden eines Objekts !   entweder Basis-­‐Seite und eingebeSete Objekte sequenOell !   oder parallele einzelne Verbindungen für die eingebeSeten Objekte ! 
persistentes HTTP !
!
!
!
! 
! 
  Server läßt Verbindung bestehen   alle Objekte werden über eine TCP-­‐Verbindung gesendet   ohne Pipelining: nach jedem Objekt Anfrage für nächstes Objekt   mit Pipelining: eine Anfrage für alle eingebeSeten Objekte Was sind die Vor-­‐ und Nachteile? Standardport des Web-­‐Servers: 80 [RN] Sommer 2014 Anwendungsschicht 17 HTTP: Ablauf ! 
Beispiel-­‐Ablauf von nicht-­‐persistentem HTTP ! 
! 
URL: www.someSchool.edu/someDepartment/home.index Basis-­‐Seite enthält 10 eingebeSete Objekte (jpeg) 1a. HTTP-Client-Prozeß initiiert TCP-
Verbindung zu HTTP-Server-Prozeß
auf Host www.someSchool.edu an
Port 80
1b. HTTP-Server-Prozeß auf Host
www.someSchool.edu wartet auf
TCP-Verbindungen an Port 80,
nimmt TCP-Verbindung an,
benachrichtigt Client
2. HTTP-Client übergibt HTTP-Anfrage
an TCP-Socket, enthält URL mit
Verweis auf Objekt
someDepartment/home.index
3. HTTP-Server empfängt HTTP-
Anfrage, erstellt HTTP-Antwort mit
dem gewünschten Objekt und
übergibt diese TCP-Socket
Zeit
[RN] Sommer 2014 Anwendungsschicht 18 HTTP: Ablauf 4. HTTP-Server schließt TCP-Verbindung
5. HTTP-Client erhält HTTP-Antwort mit
dem HTML-Inhalt, analysiert ihn,
stellt ihn auf dem Bildschirm dar,
erkennt 10 eingebettete jpegObjekte
Zeit
6. die Schritte 1-5 werden für jedes
eingebettete Objekt wiederholt
[RN] Sommer 2014 Anwendungsschicht 19 HTTP: Ablauf ! 
Antwortzeit ! 
Basis-­‐Seite !   Autau der TCP-­‐Verbindung erfordert eine Initialisierung
Round Trip Time (RTT) der TCPVerbindung
!   Anfragenachricht hin, RTT
Antwortnachricht zurück, Senden der
erfordert noch eine RTT HTTP-Anfrage
!   insgesamt: RTT
2 RTT + Zeit zum Senden Antwort
+ weitere Wartezeiten erhalten
durch TCP ! 
wie ist es bei den anderen HTTP-­‐Varianten? [RN] Sommer 2014 Anwendungsschicht Übertragungszeit
HTTPAntwort
Zeit
Zeit
20 HTTP: Dynamische Inhalte ! 
Senden von InformaOon vom Browser zum Server ! 
! 
! 
in Rumpf von Anfragenachricht mit POST häufig: als Typ/Wert-­‐Paare angehängt an die URL in einer Anfragenachricht mit GET Dynamische Inhalte mit CGI-­‐Skripten ! 
Common Gateway Interface (CGI) verarbeitet als externer Prozeß die InformaOon und liefert neue HTML-­‐Seite an Server User
Server
Browser
1
2
3
8
7
6
[RN] Sommer 2014 Anwendungsschicht 1. User füllt Formular aus
CGI
2. mit HTTP an Server
Script Datenbank 3. wird CGI übergeben
4. CGI fragt DB
4
5. DB-Eintrag gefunden
6. CGI erstellt HTML
7. mit HTTP an User
5
8. HTML darstellen
21 HTTP: Dynamische Inhalte ! 
Dynamische Inhalte durch ScripOng ! 
! 
! 
durch InterpretaOon von eingebeSeten Skripten können dynamische Inhalte erzeugt werden Server-­‐seiQges ScripQng: im HTML ist Code eingebeSet, der vom Server interpreOert wird und dabei HTML erzeugt, z.B. PHP Client-­‐seiQges ScripQng: im HTML ist Code eingebeSet, der vom Client interpreOert wird, z.B. JavaScript Browser
User
Server
Browser
User
1
2
1
4
3
2
PHP-Modul
[RN] Sommer 2014 Anwendungsschicht Server
JavaScript
22 HTTP: Caching ! 
Web-­‐Caching ! 
! 
! 
Verringerung der Wartezeit des Benutzers und des Netzwerkverkehrs durch Zwischenspeicher Cache ist Server für Web-­‐Browser und Client für Web-­‐Server möglich an vielen Stellen: Browser, angeschlossenes LAN, ISP, … Proxy
server
[RN] Sommer 2014 Client
Origin
server
Client
Origin
server
Anwendungsschicht 23 HTTP: Caching ! 
Cache kann bei Server erfragen, ob sein Objekt noch aktuell ist: Server
Cache
HTTP-Anfrage
If-modified-since:
<date>
Objekt
unverändert
HTTP-Antwort
HTTP/1.0
304 Not Modified
HTTP-Anfrage
If-modified-since:
<date>
Objekt
verändert
HTTP-Antwort
HTTP/1.0 200 OK
<data>
[RN] Sommer 2014 Anwendungsschicht 24 HTTP: Caching ! 
Beispiel für Nutzen eines Caches ! 
!   miSlere Objektgröße = 100.000 Bits ! miSlere Rate von HTTP-­‐Anfragen der Clients im LAN = 15/s ! Internetverzögerung zwischen LAN und HTTP-­‐Server = 2 s ! 
HTTPServer
Annahmen Internet
Folgen !   Auslastung des LANs 15/s ⋅ 100.000 Bits / 10 ⋅ 106 Bits/s = 0,15 = 15 % !   Auslastung der Zugangsleitung 15/s ⋅ 100.000 Bits / 1,5 ⋅ 106 Bits/s = 1 = 100 % !   Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + Minuten + 2 s = Minuten [RN] Sommer 2014 Anwendungsschicht 1,5 Mbps
Zugangsleitung
10 Mbps LAN
25 HTTP: Caching ! 
1. Lösung: Upgrade des Zugangs ! 
!
! 
HTTPServer
Zugangsleitung mit 10 Mbps möglich, aber mit Kosten verbunden Folgen !   Auslastung des LANs = 15 % !   Auslastung der Zugangsleitung 15/s ⋅ 100.000 Bits / 10 ⋅ 106 Bits/s = 0,15 = 15 % !   Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + ms + 2 s = Sekunden Internet
10 Mbps
Zugangsleitung
10 Mbps LAN
[RN] Sommer 2014 Anwendungsschicht 26 HTTP: Caching ! 
2. Lösung: Verwendung eines Caches ! 
! 
! 
Annahme: Cache-­‐Hitrate ist 0,4 realisOsch: 40 % der abgefragten Seiten befinden sich langfrisOg im Cache, 60% müssen bei HTTP-­‐Servern angefordert werden Folgen !   Auslastung des LANs = 15 % !   Auslastung der Zugangsleitung 0,6 ⋅ 15/s ⋅ 100.000 Bits / 1,5 ⋅ 106 Bits/s = 0,6 = 60 % !   Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + ms + 0,6 ⋅ 2 s < 2 s HTTPServer
Internet
1,5 Mbps
Zugangsleitung
10 Mbps LAN
Cache
[RN] Sommer 2014 Anwendungsschicht 27 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 28 E-­‐Mail ! 
Simple Mail Transfer Protocol (SMTP) ! 
! 
! 
! 
! 
Nachrichten im ASCII-­‐Format, Kopf, Rumpf andere Daten (Word-­‐Dateien u.ä.) werden in ASCII umgewandelt angehängt: mulOmedia mail extension (MIME) Versenden mit SMTP über TCP (lesbar) Abholen mit POP3, IMAP, HTTP (lesbar) mehr Einzelheiten in der Übung Alice's
agent
[RN] Sommer 2014 SMTP
Bob's
Alice's
mail server SMTP mail server
Anwendungsschicht POP3,
IMAP,
HTTP
Bob's
agent
29 E-­‐Mail: SMTP [RFC 821] ! 
! 
! 
nutzt TCP zur zuverlässigen Übertragung der Nachrichten vom Client zum Server, dazu wird Port 25 verwendet. direkte Übertragung: vom sendenden Server zu empfangendem Server drei Phasen der Übertragung ! 
! 
! 
! 
InterakOon miSels Befehlen und Antworten ! 
! 
! 
Handshaking (Begrüßung) Nachrichtenübertragung Abschlussphase Befehle: ASCII-­‐Text Antworten: Statuscode und Text Nachrichten müssen 7-­‐bit ASCII-­‐Text sein [RN] Sommer 2014 Anwendungsschicht 30 Beispiel für einen SMTP-­‐Dialog S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... 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 [RN] Sommer 2014 Anwendungsschicht 31 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 32 Netzwerkmanagement ! 
Aufgaben des Netzwerkmanagements ! 
! 
Überwachung und Verwaltung eines Netzwerks = komplexes HW/SW-­‐
Gebilde (zahlreiche Geräte, Leitungen, Datenstrukturen, …) nach ISO 5 Einsatzbereiche !   Leistung: Monitoring von Auslastung, Durchsatz, Antwortzeiten, DokumentaOon (z.B. für die Überwachung von Service Level Agreements), ReakOonsmaßnahmen !   Fehler: Monitoring, DokumentaOon, ReakOonsmaßnahmen !   KonfiguraQon: Übersicht über Geräte und deren HW/SW-­‐KonfiguraOonen !   Zugang: Festlegung, Kontrolle, DokumentaOon des Zugangs von Benutzern und Geräten !   Sicherheit: Monitoring und Kontrolle des Zugangs, Schlüsselverwaltung, z.B. Filterregeln für Firewalls, Intrusion DetecOon ! 
diverse komplexe Standards, z.B. TMN, TINA [RN] Sommer 2014 Anwendungsschicht 33 Netzwerkmanagement ! 
Simple Network Management Protocol (SNMP) ! 
! 
! 
! 
! 
! 
einfach und verbreitet Managing EnQty, Prozeß auf zentraler Management StaOon, ≈ Client Managed Device, Gerät im Netz Managed Object, HW oder SW im Managed Device, z.B. RouOng-­‐Tabelle Management Agent, Prozeß auf Managed Device, kann lokale AkOonen ausführen, ≈ Server Anfrage/Antwort-­‐Protokoll zwischen Management EnOty und Management Agent über UDP Agent
Managing
Data
entity
Managed
device
Agent Data
Network
management
protocol
Anwendungsschicht Managed
device
Agent
Agent
Managed
device
[RN] Sommer 2014 Data
Data
Data
Managed
device
34 Netzwerkmanagement ! 
SNMP Nachrichten (Version 2) ! 
! 
! 
! 
GET: Anfrage der Managing EnOty einer Variable des Managed Objects SET: Setzen der Variable eines Managed Objects durch Managing EnOty auch GET-­‐NEXT and GET-­‐BULK für Datenstrukturen TRAP: Nachricht des Managing Agents über FehlersituaOon Get/set header
PDU
type
(0-3)
PDU
type
(4)
Variables to get/set
Error
Status
(0-5)
Error
Index
Agent
Enterprise
Addr
Trap
Type
(0-7)
Request
ID
Trap header
[RN] Sommer 2014 Anwendungsschicht Name
Value
…
Specific Time
Name
code stamp
Value
…
Name
Value
Trap information
35 Netzwerkmanagement ! 
Management InformaOon Base (MIB) ! 
! 
! 
! 
MIB-­‐Module enthalten Datenstrukturen für die Managed Objects, von der IETF genormt Syntax wird in Structure of Management InformaOon (SMI) der IETF festgelegt, die wiederum die Abstract Syntax NotaQon One (ASN.1) der ISO benutzt (im wesentlichen wie C ohne Referenzen) ASN.1 besitzt auch ein Nummerierungsschema zur eindeuOgen Objekt-­‐IdenOfizierung, damit wird jedes MIB-­‐Modul eindeuOg bezeichnet mit den Basic Encoding Rules (BER) wird noch das genaue binäre Format für die Übertragung festgelegt [RN] Sommer 2014 Anwendungsschicht 36 Netzwerkmanagement ! 
Nummerierung von ASN.1 ITU-T (0)
Standard (0)
ISO (1)
Joint ISO/ITU-T(2)
ISO member
body (2)
US
DoD (6)
ISO identified
organization (3)
Open Software
Foundation (22)
NATO
identified(57)
Internet (1)
directory management experimentalprivate security snmpv2
(4)
(1)
(2)
(3)
(5)
(6)
mail
(7)
MIB-2 (1)
system interface address
ip
(1)
(2) translation (4)
(3)
[RN] Sommer 2014 icmp
(5)
Anwendungsschicht tcp
(6)
udp egp
(7) (8)
cmot transmission snmp
(9)
(10)
(11)
rmon
(16)
37 Netzwerkmanagement ! 
MIB-­‐Modul für UDP Object Identifier
Name
Type
Description (from RFC 2013)
1.3.6.1.2.1.7.1
udpInDatagrams
Counter32
“total number of UDP datagrams delivered to UDP
users“
1.3.6.1.2.1.7.2
udpNoPorts
Counter32
“total number of received UDP datagrams for which
there was no application at the destination port“
1.3.6.1.2.1.7.3
udpInErrors
Counter32
“number of received UDP datagrams that could not
be delivered for reasons other than the lack of an
application at the destination port“
1.3.6.1.2.1.7.4
udpOutDatagrams
Counter32
“total number of UDP datagrams sent from this
entity“
1.3.6.1.2.1.7.5
udpTable
SEQUENCE of
UdpEntry
“a sequence of UdpEntry objects, one for each port
that is currently open by an application, giving the IP
address and the port number used by application“
[RN] Sommer 2014 Anwendungsschicht 38 Netzwerkmanagement ! 
Basic Encoding Rules (BER) ! 
! 
RepräsentaOon zur Übertragung Tag, Length, Value (TLV) !   Tag = Nummer für Typ !   Length = Länge in Bytes ! 
Übertragung von „smith“ !   Tag 4 für OCTET STRING !   Length 5 !   ASCII-­‐Werte der Zeichen ! 
Übertragung von 282 !   Tag 2 für INTEGER !   Length 2 !   0x011a (hexadezimal), höherwerOges Byte zuerst („Big Endian“) lastname ::= OCTET STRING
weight ::= INTEGER
Module of data type
declarations written
in ASN.1
{weight, 282}
{lastname, “smith“}
Instances of data type
specified in module
Basic Encoding Rules
(BER)
1a
01
02
02
'h'
Transmitted
byte stream
't'
'i'
'm'
's'
05
04
[RN] Sommer 2014 Anwendungsschicht 39 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 40 DNS ! 
Domain Name System (DNS) ! 
! 
! 
! 
! 
! 
Host-­‐Namen bzw. Domain-­‐Namen lesbar DNS bildet Domain-­‐Namen auf Werte ab diese Werte sind u.a. IP-­‐Adressen DNS ist verteilte Datenbank, besteht aus vielen Namen-­‐Servern, die über ein Anwendungsprotokoll kommunizieren eine wesentliche Aufgabe, um die Infrastruktur zu nutzen z.B. Namens-­‐Auflösung beim Versenden einer e-­‐mail: 2
cs.princeton.edu
Name
server
Mail
program
192.12.69.5
3
[RN] Sommer 2014 User
1
user @ cs.princeton.edu
Anwendungsschicht 192.12.69.5
4
TCP
41 DNS ! 
Domain-­‐Struktur ! 
! 
! 
! 
DNS implemenOert hierarchischen Namensraum für Internet-­‐
Objekte von links nach rechts lesen, von rechts nach links verarbeiten eine Zone wird von einem Name-­‐Server verwaltet die Hierarchie wird durch die Namen-­‐Server implemenOert edu
princeton … mit
cs
ee
com
gov
cisco … yahoo nasa … nsf
mil
org
arpa … navy
acm … ieee
net
de
eu
physics
ux01 ux04
[RN] Sommer 2014 Anwendungsschicht 42 DNS ! 
Hierarchie von Name-­‐Servern ! 
! 
! 
! 
Root
name server
Root Name Server einige wenige …
Princeton
name
server
Top-­‐level Domain-­‐Server für com, org, net, edu, uk, de, eu, … …
CS
EE
… name server
name server
autoritaQver Name-­‐Server unterste Ebene, für einzelne OrganisaOon [RN] Sommer 2014 Anwendungsschicht Cisco
name server
43 DNS: Resource Records ! 
Resource Records ! 
! 
! 
Datensätze der Namenserver (Domainname, Wert, Typ, TTL) TTL: Time to Live, Dauer der GülOgkeit Typ = A !   Wert = IP-­‐Adresse !   Bsp.: (ns.cisco.com, 128.96.32.20, A, TTL) ! 
Typ = NS !   Wert = Domainname eines Hosts, auf dem ein Namen-­‐Server läu], der Namen in der Domain auflösen kann !   Bsp.: (princeton.edu, cit.princeton.edu, NS, TTL) ! 
Typ = CNAME (Canonical Name) !   Wert = kanonischer Name eines Hosts, ermöglicht Aliasnamen !   Bsp.: (cic.cs.princeton.edu, cicada.cs.princeton.edu, CNAME, TTL) ! 
Typ = MX (Mail Exchange) !   Wert = Domain-­‐Name des Hosts, auf dem Mail-­‐Server läu] !   Bsp.: (cs.princeton.edu, opOma.cs.princeton.edu, MX, TTL) [RN] Sommer 2014 Anwendungsschicht 44 DNS: Resource Records ! 
Bsp: Resource Records ! 
Root Name Server (princeton.edu, cit.princeton.edu, NS, TTL) (cit.princeton.edu, 128.196.128.233, A, TTL) (cisco.com, ns.cisco.com, NS, TTL) (ns.cisco.com, 128.96.32.20, A, TTL) … ! 
enthält einen NS-­‐Datensatz für jeden Server der nächsten Ebene und einen A-­‐Datensatz mit der IP-­‐Adresse diese bilden zusammen einen Verweis auf die Server der zweiten Ebene ! 
[RN] Sommer 2014 Anwendungsschicht 45 DNS: Protokoll ! 
DNS-­‐Protokoll ! 
! 
Anfrage-­‐ und Antwortnachrichten, gleiches Format: Kopf !   IdenOficaOon: Zuordnung Anfrage, Antwort !   Flags: Art der Anfrage bzw. Antwort ! 
Rumpf !   QuesOons: Domainnamen !   Answers: Resource Records !   Authority: Antworten von autoritaOven Servern [RN] Sommer 2014 Anwendungsschicht Identification
Flags
Number of questions
Number of answers RRs
Number of authority RRs Number of additional RRs
Questions
(variable number of questions)
Answers
(variable number of resource records)
Authority
(variable number of resource records)
Additional information
(variable number of resource records)
46 DNS: Protokoll ! 
Anfragearten ! 
iteraQv !   Antwort: anderer Server, der Namen evtl. auflösen kann (oder keine Antwort) !   NS-­‐ und A-­‐Datensatz !   Antwort wird sofort geliefert, es muß keine InformaOon gespeichert werden, gut für hochfrequenOerte Server ! 
rekursiv !   Antwort: Auflösung des Namens, die u.U. von anderen Servern geholt wird !   A-­‐Datensatz !   bei Anfrage an einen anderen Server muß die InformaOon gespeichert werden [RN] Sommer 2014 Anwendungsschicht 47 DNS: Protokoll ! 
root DNS server
Beispiel für iteraOve Anfrage: 2
3
4
TLD DNS server
5
local DNS server
dns.poly.edu
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
[RN] Sommer 2014 Anwendungsschicht 48 DNS: Protokoll ! 
root DNS server
Beispiel für rekursive Anfrage: 2
3
7
6
TLD DNS server
local DNS server
dns.poly.edu
1
5
4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
[RN] Sommer 2014 Anwendungsschicht 49 DNS: Protokoll ! 
root name server
KombinaOon aus rekursiver und iteraOver Anfrage: 2
iterated query
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
[RN] Sommer 2014 Anwendungsschicht 50 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 51 Content DistribuQon Networks ! 
Content DistribuOon Networks (CDNs) ! 
! 
! 
! 
Ziel: Vermeiden längerer Wartezeiten beim Laden von Web-­‐
Seiten, z.B. bei Flash-­‐Crowds (Millionen Benutzer greifen auf eine Seite zu) 3 Engpässe: erste Meile, letzte Meile, Peering-­‐Punkte (Übergänge zwischen ISPs) Idee: sehr viele (Hunderte) Spiegel-­‐
Server geografisch verteilen (diese sind wie Web-­‐Caches, der Inhalt wird aber proakOv auf sie repliziert) bekannte CDNs: Akamai, Digital Island [RN] Sommer 2014 Anwendungsschicht Origin server
in North America
CDN distribution
node
CDN server
in South America
CDN server
in Asia
CDN server
in Europe
52 Content DistribuQon Networks ! 
Verteilung der Anfragen ! 
! 
! 
! 
! 
Server-­‐basierte HTTP RedirecQon: Server liefert aufgrund der IP-­‐
Adresse des Clients einen geeigneten anderen Server, erfordert zusätzliche RTT, Gefahr der Überlast für Server Client-­‐nahe HTTP-­‐RedirecQon: z.B. durch Web-­‐Proxy, schwieriger zu verwirklichen DNS-­‐basierte RedirecQon: DNS-­‐Server bildet den Domain-­‐Namen des Servers auf die IP-­‐Adresse eines geeigneten Servers ab URL-­‐RewriQng: Server liefert Basisseite, die URLs der eingebeSeten Objekte werden umgeschrieben, mit dem Domain-­‐
Namen eines geeigneten anderen Servers kommerzielle CDNs verwenden meist KombinaOon aus DNS-­‐
basierter RedirecOon und URL-­‐RewriOng [RN] Sommer 2014 Anwendungsschicht 53 Content DistribuQon Networks ! 
Bsp. für URL-­‐RewriOng ! 
! 
! 
! 
www.foo.com ist Content-­‐Provider, Video-­‐Dateien werden auf den CDN-­‐
Servern von cdn.com verteilt 1. HTTP-­‐Anfrage für HTML-­‐Basisseite, Antwort enthält eingebeSete Video-­‐Datei www.cdn.com/www.foo.com/sports/ruth.mpg 2. DNS-­‐Anfrage für IP-­‐Adresse von www.cdn.com, DNS-­‐Server liefert aufgrund der IP-­‐Adresse des Clients und einer internen Tabelle die IP-­‐
Adresse eines geeigneten Servers r
3. HTTP-­‐Anfrage an diesen Server est fo html
requ ports.
/s
HTTPom/sports
Origin server
.foo.c
www
1
DNS query for
2
3
www.cdn.com
www
H
.cdn
.com TTP re
/www que
.foo. st for
co m
/spo
r
CDN‘s authoritative
DNS server
ts/ru
th.m
p
[RN] Sommer 2014 Anwendungsschicht g
54 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 55 Socket-­‐Programmierung ! 
Socket-­‐SchniSstelle ! 
! 
! 
verbreitetes API für Transportdienste Festlegung von TCP/UDP, IP-­‐Adressen, Portnummern Architektur: Kontrolle durch
Anwendungsprogramm
Kontrolle durch
Betriebssystem
Prozeß
Prozeß
Socket
Socket
TCP mit
Puffern,
Variablen
Internet
Kontrolle durch
Betriebssystem
Host oder
Server
Host oder
Server
[RN] Sommer 2014 TCP mit
Puffern,
Variablen
Kontrolle durch
Anwendungsprogramm
Anwendungsschicht 56 Socket-­‐Programmierung ! 
! 
! 
Client liest Zeile aus Standardeingabe (inFromUser stream) und sendet ihn über ein TCP-­‐Socket zum Server Server liest Zeile aus TCP-­‐
ClientProzeß
Socket Server konverOert in Großbuchstaben (seine Dienstleistung) und sendet diese ZeichenkeSe über TCP-­‐
Socket zurück an Client Client liest ZeichenkeSe aus TCP-­‐Socket und gibt diese auf Standardausgabe aus [RN] Sommer 2014 Anwendungsschicht Bildschirm
Eingabestrom
Ausgabestrom
inFromServer
! 
Tastatur
inFromUser
Beispiel für einfache Client-­‐
Server-­‐Anwendung outToServer
! 
clientSocket
zur
Transportschicht
Eingabestrom
TCP-Socket
von der
Transportschicht
57 Socket-­‐Programmierung !
Ein Ausflug in die Programmierpraxis [RN] Sommer 2014 Anwendungsschicht 58 Anwendungsschicht ! 
! 
Einführung Verbreitete Anwendungen ! 
! 
! 
! 
! 
! 
! 
! 
! 
Hypertext Transfer Protocol (HTTP) E-­‐Mail Netzwerkmanagement Domain Name System (DNS) Content DistribuOon Networks Real-­‐Time Protocol (RTP) Session IniOaOon Protocol (SIP) Socket-­‐Programmierung Peer-­‐to-­‐Peer-­‐Systeme [RN] Sommer 2014 Anwendungsschicht 59 P2P ! 
Peer-­‐to-­‐Peer ! 
! 
! 
bekannt von Anwendungen zum Filesharing Grundidee: Inhalte nicht nur von zentralem Server, sondern auch von anderen Peers Upload-­‐Bitrate der Peers wird mitgenutzt File: F
Server
u5
u1
d1
u2
d2
u3
d3
Internet
u4
dN
uN
[RN] Sommer 2014 d6
Anwendungsschicht u6
d5
d
uU5 4
60 P2P ! 
Peer-­‐to-­‐Peer ! 
! 
! 
! 
! 
Anwendungen wie Napster und KaZaA zum direkten Austausch von Musikdateien (MP3) haben P2P populär gemacht Napster aus jurisOschen Gründen sOllgelegt, diverse Nachfolger (Gnutella, Pastry, eDonkey, …) HaupSeil des Netzverkehrs wird heute durch P2P erzeugt Peers kommunizieren direkt miSels TCP oder UDP P2P-­‐Netze bilden Overlay-­‐Netz: logisches Netz aus Peers über dem physikalischen Netz [RN] Sommer 2014 Anwendungsschicht 61 P2P: Architekturen ! 
Unstrukturiert (1st/2nd GeneraOon) ! 
Zentralisierte P2P Netze (z.B. Napster) !   Datenaustausch P2P, Verzeichnis aber zentral ! 
Reine P2P Netze (z.B. Gnutella 0.4) !   Keine Zentrale, vollständige Vermaschung der Peers (Skalierbarkeit?!) ! 
Hybride P2P Netze (z.B. Gnutella 0.6, JXTA) !   Inseln mit Serverstruktur, Vermaschung der Inseln ! 
Strukturiert ! 
! 
! 
DHT (Distributed Hash Table) basiert Z.B. Chord, CAN Keine zentralen Server, hochgradig skalierbar [RN] Sommer 2014 Anwendungsschicht 62 P2P: Unstrukturiert (Zentralisiert) ! 
Zentralisiertes Verzeichnis ! 
! 
! 
! 
! 
Architektur von Napster EintriS eines Peers: er informiert zentralen Server über seine IP-­‐Adresse und seine Inhalte Suche nach Inhalt: über zentralen Server Dateiübertragung: direkt zwischen Peers zentraler Server !   jurisOscher „Schwachpunkt“ !   Leistungs-­‐ und Zuverlässigkeitsproblem [RN] Sommer 2014 Anwendungsschicht Bob
centralized
directory server
1
peers
1
3
1
2
1
Alice
63 P2P: Unstrukturiert (Rein P2P) ! 
Dezentralität durch Fluten von Anfragen ! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
Architektur von Gnutella Peers bilden Overlay-­‐Netzwerk über TCP-­‐Verbindungen anfragender Peer sendet Anfrage an alle Nachbarn diese vergleichen Anfrage mit den von ihnen angebotenen Inhalten Fluten: wenn sie die Anfrage nicht beantworten können, wird sie an mehrere Nachbarn weitergeleitet (aber nicht an den Peer, von dem die Anfrage kommt) das Fluten wird durch einen maximalen Hopcount begrenzt wenn ein Peer den Inhalt anbieten kann, antwortet er dem anfragenden Peer, dieser leitet wiederum zurück (die IdenOtät des ursprünglich anfragenden Peers bleibt so unbekannt) die Antwort findet zur Quelle zurück, diese kontakOert direkt einen der Peers, der die Anfrage beantworten kann, die Übertragung erfolgt miSels HTTP kein zentraler Server benöOgt EintriS in das Overlay-­‐Netzwerk: Nachricht an eine veröffentlichte Liste von möglichen Peers schicken Skalierbarkeit ist wegen des Flutens problemaOsch [RN] Sommer 2014 Anwendungsschicht 64 P2P: Unstrukturiert (Hybrid) ! 
Hierarchie ! 
! 
! 
! 
! 
! 
! 
Architektur von KaZaA proprietäres Protokoll, Kontrollnachrichten verschlüsselt Peers bilden Gruppen, einer ist Group Leader Group Leader kennt Inhalte aller Peers aus Gruppe (Gruppe ≈ „Mini-­‐
Napster“) Overlay-­‐Netzwerk zwischen Group Leadern Austausch zwischen Group Leadern ähnlich wie bei Gnutella bessere Skalierbarkeit, ebenfalls keine zentrale Kontrolle [RN] Sommer 2014 Anwendungsschicht 65 P2P: Strukturiert ! 
Verteilte Hash-­‐Tabellen (Distributed Hash Tables, DHT) ! 
! 
! 
! 
! 
dezentrales Verfahren für Speicherung und Lookup von Datenelementen, bekannt aus Chord-­‐System Peers bilden ringförmiges Overlay-­‐Netz jedem Peer wird zufälliger Bezeichner p (0 ≤ p ≤ 2m-­‐1) aus Bezeichnerraum mit m Bits zugewiesen jedem Datenelement wird miSels Hash-­‐FunkOon ein Schüssel k ebenfalls aus diesem Raum zugewiesen Nachfolger von k !   Datenelement mit Schlüssel k wird auf Nachfolger p von k gespeichert, p = succ(k) !   dies ist der Peer mit dem kleinstem Bezeichner p ≥ k (die ≥-­‐RelaOon gilt bis auf Modulo 2m-­‐1) !   Lookup für ein Datenelement mit Schlüssel k erfolgt auf Peer succ(k) [RN] Sommer 2014 Anwendungsschicht 66 P2P: Strukturiert (Beispiel Chord) ! 
RouOng ! 
! 
Finden des gesuchten Eintrags in der DHT Chord verwaltet Ringstruktur über alle Einträge !   Jeweils Vorgänger und Nachfolger ! 
! 
Neue Knoten ! 
! 
! 
Voraussetzung: ein bekannter Knoten N in der DHT Neue ID wählen größer als N, kleiner als Nachfolger von N; Aktualisieren der Verzeigerung Knoten en‚ernen ! 
! 
RouOng entlang des Rings (ineffizient) oder durch Sprungtabellen (Finger-­‐
Tabelle, siehe nächste Folie) Daten migrieren?; ID en‚ernen und Verzeigerung aktualisieren Selbststabilisierung ! 
KonOnuierliche Überprüfung aller Knoten, evtl. Verzeigerung reparieren [RN] Sommer 2014 Anwendungsschicht 67 P2P: Strukturiert (Beispield Chord) ! 
Finger-­‐Tabelle ! 
! 
! 
jeder Peer p unterhält Finger-­‐Tabelle FTp mit maximal m Einträgen i-­‐ter Eintrag der Finger-­‐Tabelle: FTp[i] = succ(p+2i-­‐1) enthält Nachfolger mit exponenOell steigenden Distanz Lookup für Datenelement mit Schlüssel k !   Start mit beliebigem Peer p !   Wiederhole bis p ≥ k: – 
– 
– 
– 
wenn k ≤ FTp[1], dann q = FTp [1] wenn FTp [m] ≤ k, dann q = FTp [m] sonst q = FTp [i] ≤ k < FTp [i+1] p = q !   succ(k) = p ! 
Beispiel (nächste Folie) ! 
! 
m = 5, Bezeichnerraum 0 ≤ p ≤ 2m-­‐1= 31 farbige Peers gehören zum Overlay [RN] Sommer 2014 Anwendungsschicht 68 Eigentlicher Knoten
1
2
3
4
5
30
1
1
1
4
14
1
2
Finger-Tabelle
i
1
2
3
4
5
3
4
28
Lookup von k =12
auf Peer 28
27
5
9
9
9
14
20
6
25
7
24
8
28
28
28
1
9
23
1
2
3
4
5
21
28
28
28
4
[RN] Sommer 2014 0
4
4
9
9
18
29
26
1
2
3
4
5
31
1
2
3
4
5
Lookup von k = 26
auf Peer 1
9
22
10
21
11
20
12
19
1
2
3
4
5
20
20
28
28
4
18
17
Anwendungsschicht 16
15
14
13
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
11
11
14
18
28
14
14
18
20
28
18
18
18
28
1
69 P2P: Strukturiert (Beispiel Chord) ! 
Lookup von k = 26 auf Peer 1 ! 
! 
! 
! 
! 
! 
Lookup von k = 12 auf Peer 28 ! 
! 
! 
! 
! 
! 
Lookup auf Peer 1 ergibt p = 18 = FT1[5] ≤ 26 Lookup auf Peer 18 ergibt p = 20 = FT18[2] ≤ 26 < FT18[3] Lookup auf Peer 20 ergibt p = 21 = FT20[1] ≤ 26 < FT20[2] Lookup auf Peer 21 ergibt p = 28 = FT21[1] ≥ 26 Ergebnis: succ(26) = 28 Lookup auf Peer 28 ergibt p = 4 = FT28[4] ≤ 12 < FT28[5] Lookup auf Peer 4 ergibt p = 9 = FT4[3] ≤ 12 < FT4[4] Lookup auf Peer 9 ergibt p = 11 = FT9[2] ≤ 12 < FT9[3] Lookup auf Peer 11 ergibt p = 14 = FT11[1] ≥ 12 Ergebnis: succ(12) = 14 Diverse weitere OperaOonen notwendig ! 
Aktualisierung des Overlays, OpOmierung [RN] Sommer 2014 Anwendungsschicht 70 P2P: PrakQsche Anwendung ! 
Hybridarchitektur mit Tracker (Verwaltung) und Strukturiertem P2P Netz Tracker
Peer
Obtain
list of
peers
Trading chunks
Alice
[RN] Sommer 2014 Anwendungsschicht 71