docAnwendungsschicht
download 
Report Transcription
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: <[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 [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
