Inhalt der Vorlesung

Transkript

1 Einführung Anwendungsschicht Transportschicht Netzwerkschicht Verbindungsschicht Physikalische Schicht Inhalt der Vorlesung [RN] Sommer 2013 Anwendungsschicht 1

2 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 2

3 Einführung Netzwerkanwendung Anwendungsprozesse auf verschiedenen Endsystemen (Hosts), die mittels Nachrichten über ein Netzwerk kommunizieren kann direkt unter Verwendung der Dienste der Transportschicht implementiert 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ötigen keine Kenntnis der Anwendung einfache Verbreitung, große Dynamik application transport network data link physical application transport network data link physical application transport network data link physical [RN] Sommer 2013 Anwendungsschicht 3

4 Client-Server-Paradigma Einführung Server stellt Dienst zur Verfügung, der von Client angefordert wird übliches Paradigma von vielen traditionellen Anwendungen, wie z.b. Web-Browser und Server typische Eigenschaften des Servers leistungsfähig immer verfügbar typische Eigenschaften der Clients nur manchmal verbunden kommunizieren mit Server, nicht untereinander [RN] Sommer 2013 Anwendungsschicht 4

5 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, Applikations-Server und Datenbank), Koordination ist zwar verteilt, findet aber für das Gesamtsystem statt 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 Initialisierung ist eine zentrale Architektur nötig, die Anwendung findet dann dezentral direkt zwischen Hosts statt (z.b. bei Session Initiation Protocol, SIP oder bei manchen Peer-to-Peer- Anwendungen wie Bittorrent) [RN] Sommer 2013 Anwendungsschicht 5

6 Einführung Varianten des Client-Server-Paradigmas Client-Computer Thin Client Fat Client Benutzungsschnittstelle Benutzungsschnittstelle Benutzungsschnittstelle Benutzungsschnittstelle Benutzungsschnittstelle Anwendung Anwendung Anwendung Datenbank Benutzungsschnittstelle Anwendung Anwendung Anwendung Datenbank Datenbank Datenbank Datenbank Datenbank Fat Server Server-Computer Thin Server [RN] Sommer 2013 Anwendungsschicht 6

7 Einführung Dienste der Transportschicht im Internet gibt es zwei dominierende Transportprotokolle TCP: verbindungsorientiert (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-Schnittstelle, 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 2013 Anwendungsschicht 7

8 Einführung Quantitative Anforderungen von Anwendungen Verlust Bitrate nicht tolerierbar bei Dateitransfer, Online-Banking etc. teilweise tolerierbar bei Multimedia traditionelle Anwendungen wie FTP, und HTTP benötigen keine feste Bitrate, sind aber besser, wenn sie viel Bitrate erhalten ( Best-Effort-Verkehr, elastische Anwendungen ) Echtzeit-Multimedia benötigt Mindest-Bitrate Verzögerungszeit traditionelle Anwendungen benötigen keine maximale Verzögerungszeit, sind aber wieder besser bei kurzen Zeiten Echtzeit-Multimedia und interaktive Spiele benötigen kurze Verzögerungszeit Steuerungen technischer Geräte benötigen oft Garantie einer maximalen Verzögerungszeit [RN] Sommer 2013 Anwendungsschicht 8

9 Einführung Quantitative Anforderungen von Anwendungen Anwendung Verlust Bitrate Verzögerungszeit Dateitransfer kein Verlust elastisch keine harte Grenze 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 2013 Anwendungsschicht 9

10 Einführung Einige bekannte Anwendungsprotokolle und das darunterliegende Transportprotokoll Anwendung Anwendungsprotokoll verwendetes Transportprotokoll 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 2013 Anwendungsschicht 10

11 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 11

12 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 PC mit MS Explorer Mac mit Firefox Server mit Apache Web- Server [RN] Sommer 2013 Anwendungsschicht 12

13 HTTP: Anfragenachrichten Format der Anfragenachrichten Anfragezeile method sp URL sp version cr lf header field name: sp value cr lf Kopfzeilen header field name: sp value cr lf Leerzeile cr lf Rumpf [RN] Sommer 2013 Anwendungsschicht 13

14 Methoden HTTP: Anfragenachrichten GET: Abruf eines Dokuments, besteht aus Methode, URL, Version HEAD: Abruf von Metainformationen eines Dokuments POST: Ausgabe von Informationen an Server Put, Delete, Trace, Options Kopfzeilen Typ/Wert-Paare, Typen: Host, User-agent, Rumpf leer bei GET, kann bei POST Inhalt haben Beispiel Anfragenachricht: GET /somedir/page.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) [RN] Sommer 2013 Anwendungsschicht 14

15 HTTP: Antwortnachrichten Format der Antwortnachrichten Statuszeile version sp status code sp phrase cr lf header field name: sp value cr lf Kopfzeilen header field name: sp value cr lf Leerzeile cr lf Rumpf [RN] Sommer 2013 Anwendungsschicht 15

16 HTTP: Antwortnachrichten Mögliche Codes in der Statuszeile 200 OK ( alles klar ) 301 Moved Permanently (Redirection: Objekt zu finden unter Location: ) 400 Bad Request (Anfragenachricht nicht verstanden) 404 Not Found (Objekt nicht gefunden) 505 HTTP Version Not Supported Beispiel- Antwortnachricht: HTTP/ OK Connection: close Date: Thu, 06 Aug :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... [RN] Sommer 2013 Anwendungsschicht 16

17 HTTP-Ablauf nicht-persistentes HTTP HTTP: Ablauf für jedes Objekt wird einzelne TCP-Verbindung geöffnet, Server beendet sie sofort nach dem Senden eines Objekts entweder Basis-Seite und eingebettete Objekte sequentiell oder parallele einzelne Verbindungen für die eingebetteten 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 eingebetteten Objekte Was sind die Vor- und Nachteile? Standardport des Web-Servers: 80 [RN] Sommer 2013 Anwendungsschicht 17

18 HTTP: Ablauf Beispiel-Ablauf von nicht-persistentem HTTP URL: Basis-Seite enthält 10 eingebettete Objekte (jpeg) 1a. HTTP-Client-Prozeß initiiert TCP- Verbindung zu HTTP-Server-Prozeß auf Host an Port HTTP-Client übergibt HTTP-Anfrage an TCP-Socket, enthält URL mit Verweis auf Objekt somedepartment/home.index 1b. HTTP-Server-Prozeß auf Host wartet auf TCP-Verbindungen an Port 80, nimmt TCP-Verbindung an, benachrichtigt Client 3. HTTP-Server empfängt HTTP- Anfrage, erstellt HTTP-Antwort mit dem gewünschten Objekt und übergibt diese TCP-Socket Zeit [RN] Sommer 2013 Anwendungsschicht 18

19 HTTP: Ablauf 4. HTTP-Server schließt TCP-Verbindung Zeit 5. HTTP-Client erhält HTTP-Antwort mit dem HTML-Inhalt, analysiert ihn, stellt ihn auf dem Bildschirm dar, erkennt 10 eingebettete jpeg- Objekte 6. die Schritte 1-5 werden für jedes eingebettete Objekt wiederholt [RN] Sommer 2013 Anwendungsschicht 19

20 HTTP: Ablauf Antwortzeit Basis-Seite Aufbau der TCP-Verbindung erfordert eine Round Trip Time (RTT) Anfragenachricht hin, Antwortnachricht zurück, erfordert noch eine RTT insgesamt: 2 RTT + Zeit zum Senden + weitere Wartezeiten durch TCP wie ist es bei den anderen HTTP-Varianten? Initialisierung der TCP- Verbindung RTT Senden der HTTP-Anfrage RTT Antwort erhalten Zeit Zeit Übertragungszeit HTTP- Antwort [RN] Sommer 2013 Anwendungsschicht 20

21 HTTP: Dynamische Inhalte Senden von Information 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 Information und liefert neue HTML-Seite an Server User Browser Server CGI Script Datenbank 5 1. User füllt Formular aus 2. mit HTTP an Server 3. wird CGI übergeben 4. CGI fragt DB 5. DB-Eintrag gefunden 6. CGI erstellt HTML 7. mit HTTP an User 8. HTML darstellen [RN] Sommer 2013 Anwendungsschicht 21

22 HTTP: Dynamische Inhalte Dynamische Inhalte durch Scripting durch Interpretation von eingebetteten Skripten können dynamische Inhalte erzeugt werden Server-seitiges Scripting: im HTML ist Code eingebettet, der vom Server interpretiert wird und dabei HTML erzeugt, z.b. PHP Client-seitiges Scripting: im HTML ist Code eingebettet, der vom Client interpretiert wird, z.b. JavaScript User Browser Server User Browser Server PHP-Modul JavaScript [RN] Sommer 2013 Anwendungsschicht 22

23 Web-Caching HTTP: 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 Client Origin server Client Origin server [RN] Sommer 2013 Anwendungsschicht 23

24 HTTP: Caching Cache kann bei Server erfragen, ob sein Objekt noch aktuell ist: Cache HTTP-Anfrage If-modified-since: <date> Server Objekt unverändert HTTP-Antwort HTTP/ Not Modified HTTP-Anfrage If-modified-since: <date> HTTP-Antwort HTTP/ OK <data> Objekt verändert [RN] Sommer 2013 Anwendungsschicht 24

25 HTTP: Caching Beispiel für Nutzen eines Caches Annahmen Folgen mittlere Objektgröße = Bits mittlere Rate von HTTP-Anfragen der Clients im LAN = 15/s Internetverzögerung zwischen LAN und HTTP-Server = 2 s Auslastung des LANs 15/s Bits / Bits/s = 0,15 = 15 % Auslastung der Zugangsleitung 15/s Bits / 1, Bits/s = 1 = 100 % Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + Minuten + 2 s = Minuten 10 Mbps LAN Internet HTTP- Server 1,5 Mbps Zugangsleitung [RN] Sommer 2013 Anwendungsschicht 25

26 HTTP: Caching 1. Lösung: Upgrade des Zugangs Zugangsleitung mit 10 Mbps möglich, aber mit Kosten verbunden Folgen Auslastung des LANs = 15 % Auslastung der Zugangsleitung 15/s Bits / Bits/s = 0,15 = 15 % Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + ms + 2 s = Sekunden Internet HTTP- Server 10 Mbps Zugangsleitung 10 Mbps LAN [RN] Sommer 2013 Anwendungsschicht 26

27 HTTP: Caching 2. Lösung: Verwendung eines Caches Annahme: Cache-Hitrate ist 0,4 realistisch: 40 % der abgefragten Seiten befinden sich langfristig im Cache, 60% müssen bei HTTP-Servern angefordert werden Folgen Auslastung des LANs = 15 % Auslastung der Zugangsleitung 0,6 15/s Bits / 1, Bits/s = 0,6 = 60 % Gesamtverzögerung = Verzögerung im LAN + beim Zugang + im Internet = ms + ms + 0,6 2 s < 2 s 10 Mbps LAN Internet HTTP- Server 1,5 Mbps Zugangsleitung Cache [RN] Sommer 2013 Anwendungsschicht 27

28 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 28

29 Simple Mail Transfer Protocol (SMTP) Nachrichten im ASCII-Format, Kopf, Rumpf andere Daten (Word-Dateien u.ä.) werden in ASCII umgewandelt angehängt: multimedia mail extension (MIME) Versenden mit SMTP über TCP (lesbar) Abholen mit POP3, IMAP, HTTP (lesbar) mehr Einzelheiten in der Übung Alice's agent SMTP Alice's mail server SMTP Bob's mail server POP3, IMAP, HTTP Bob's agent [RN] Sommer 2013 Anwendungsschicht 29

30 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 Handshaking (Begrüßung) Nachrichtenübertragung Abschlussphase Interaktion mittels Befehlen und Antworten Befehle: ASCII-Text Antworten: Statuscode und Text Nachrichten müssen 7-bit ASCII-Text sein [RN] Sommer 2013 Anwendungsschicht 30

31 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: S: 250 Sender ok C: RCPT TO: S: 250 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 2013 Anwendungsschicht 31

32 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 32

33 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, Dokumentation (z.b. für die Überwachung von Service Level Agreements), Reaktionsmaßnahmen Fehler: Monitoring, Dokumentation, Reaktionsmaßnahmen Konfiguration: Übersicht über Geräte und deren HW/SW-Konfigurationen Zugang: Festlegung, Kontrolle, Dokumentation des Zugangs von Benutzern und Geräten Sicherheit: Monitoring und Kontrolle des Zugangs, Schlüsselverwaltung, z.b. Filterregeln für Firewalls, Intrusion Detection diverse komplexe Standards, z.b. TMN, TINA [RN] Sommer 2013 Anwendungsschicht 33

34 Netzwerkmanagement Simple Network Management Protocol (SNMP) Agent Data einfach und verbreitet Managing Entity, Prozeß auf zentraler Management Station, Client Managed Device, Gerät im Netz Managed Object, HW oder SW im Managed Device, z.b. Routing-Tabelle Management Agent, Prozeß auf Managed Device, kann lokale Aktionen ausführen, Server Anfrage/Antwort-Protokoll zwischen Management Entity und Management Agent über UDP Managed device Managing entity Network management protocol Agent Data Data Agent Agent Data Data Managed device Managed device Managed device [RN] Sommer 2013 Anwendungsschicht 34

35 Netzwerkmanagement SNMP Nachrichten (Version 2) GET: Anfrage der Managing Entity einer Variable des Managed Objects SET: Setzen der Variable eines Managed Objects durch Managing Entity auch GET-NEXT and GET-BULK für Datenstrukturen TRAP: Nachricht des Managing Agents über Fehlersituation Get/set header Variables to get/set PDU type (0-3) Request ID Error Status (0-5) Error Index Name Value Name Value PDU type (4) Enterprise Agent Addr Trap Type (0-7) Specific code Time stamp Name Value Trap header Trap information [RN] Sommer 2013 Anwendungsschicht 35

36 Netzwerkmanagement Management Information Base (MIB) MIB-Module enthalten Datenstrukturen für die Managed Objects, von der IETF genormt Syntax wird in Structure of Management Information (SMI) der IETF festgelegt, die wiederum die Abstract Syntax Notation One (ASN.1) der ISO benutzt (im wesentlichen wie C ohne Referenzen) ASN.1 besitzt auch ein Nummerierungsschema zur eindeutigen Objekt-Identifizierung, damit wird jedes MIB-Modul eindeutig bezeichnet mit den Basic Encoding Rules (BER) wird noch das genaue binäre Format für die Übertragung festgelegt [RN] Sommer 2013 Anwendungsschicht 36

37 Nummerierung von ASN.1 Netzwerkmanagement ITU-T (0) ISO (1) Joint ISO/ITU-T(2) Standard (0) ISO member body (2) ISO identified organization (3) US DoD (6) Internet (1) Open Software Foundation (22) NATO identified(57) directory (1) management (2) experimental private (3) (4) security (5) snmpv2 (6) mail (7) MIB-2 (1) system (1) interface address (2) translation (3) ip (4) icmp (5) tcp (6) udp (7) egp (8) cmot (9) transmission (10) snmp (11) rmon (16) [RN] Sommer 2013 Anwendungsschicht 37

38 MIB-Modul für UDP Netzwerkmanagement Object Identifier Name Type Description (from RFC 2013) udpindatagrams Counter32 total number of UDP datagrams delivered to UDP users udpnoports Counter32 total number of received UDP datagrams for which there was no application at the destination port 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 udpoutdatagrams Counter32 total number of UDP datagrams sent from this entity 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 2013 Anwendungsschicht 38

39 Netzwerkmanagement Basic Encoding Rules (BER) Repräsentation 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öherwertiges Byte zuerst ( Big Endian ) lastname ::= OCTET STRING weight ::= INTEGER Module of data type declarations written in ASN.1 Basic Encoding Rules (BER) 1a 'h' 't' 'i' 'm' 's' {weight, 282} {lastname, smith } Transmitted byte stream Instances of data type specified in module [RN] Sommer 2013 Anwendungsschicht

40 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 40

41 Domain Name System (DNS) 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 2 cs.princeton.edu User 1 cs.princeton.edu Name server Mail program TCP [RN] Sommer 2013 Anwendungsschicht 41

42 Domain-Struktur DNS DNS implementiert 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 implementiert edu com gov mil org net de eu princeton mit cisco yahoo nasa nsf arpa navy acm ieee cs ee physics ux01 ux04 [RN] Sommer 2013 Anwendungsschicht 42

43 DNS Hierarchie von Name-Servern Root Name Server einige wenige Top-level Domain-Server für com, org, net, edu, uk, de, eu, autoritativer Name-Server unterste Ebene, für einzelne Organisation CS name server Princeton name server Root name server EE name server Cisco name server [RN] Sommer 2013 Anwendungsschicht 43

44 DNS: Resource Records Resource Records Datensätze der Namenserver (Domainname, Wert, Typ, TTL) TTL: Time to Live, Dauer der Gültigkeit Typ = A Wert = IP-Adresse Bsp.: (ns.cisco.com, , A, TTL) Typ = NS Wert = Domainname eines Hosts, auf dem ein Namen-Server läuft, 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äuft Bsp.: (cs.princeton.edu, optima.cs.princeton.edu, MX, TTL) [RN] Sommer 2013 Anwendungsschicht 44

45 Bsp: Resource Records Root Name Server DNS: Resource Records (princeton.edu, cit.princeton.edu, NS, TTL) (cit.princeton.edu, , A, TTL) (cisco.com, ns.cisco.com, NS, TTL) (ns.cisco.com, , 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 2013 Anwendungsschicht 45

46 DNS: Protokoll DNS-Protokoll Anfrage- und Antwortnachrichten, gleiches Format: Kopf Rumpf Identification: Zuordnung Anfrage, Antwort Flags: Art der Anfrage bzw. Antwort Questions: Domainnamen Answers: Resource Records Authority: Antworten von autoritativen Servern Identification Number of questions Flags 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) [RN] Sommer 2013 Anwendungsschicht 46

47 Anfragearten iterativ DNS: Protokoll Antwort: anderer Server, der Namen evtl. auflösen kann (oder keine Antwort) NS- und A-Datensatz Antwort wird sofort geliefert, es muß keine Information gespeichert werden, gut für hochfrequentierte 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 Information gespeichert werden [RN] Sommer 2013 Anwendungsschicht 47

48 DNS: Protokoll Beispiel für iterative Anfrage: root DNS server TLD DNS server 5 local DNS server dns.poly.edu requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu [RN] Sommer 2013 Anwendungsschicht 48

49 DNS: Protokoll Beispiel für rekursive Anfrage: root DNS server TLD DNS server local DNS server dns.poly.edu requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu [RN] Sommer 2013 Anwendungsschicht 49

50 DNS: Protokoll Kombination aus rekursiver und iterativer Anfrage: 2 root name server iterated query local name server dns.eurecom.fr 1 8 intermediate name server dns.umass.edu 5 6 requesting host surf.eurecom.fr authoritative name server dns.cs.umass.edu gaia.cs.umass.edu [RN] Sommer 2013 Anwendungsschicht 50

51 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 51

52 Content Distribution Networks Content Distribution 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 proaktiv auf sie repliziert) bekannte CDNs: Akamai, Digital Island CDN server in South America Origin server in North America CDN distribution node CDN server in Europe CDN server in Asia [RN] Sommer 2013 Anwendungsschicht 52

53 Content Distribution Networks Verteilung der Anfragen Server-basierte HTTP Redirection: 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-Redirection: z.b. durch Web-Proxy, schwieriger zu verwirklichen DNS-basierte Redirection: DNS-Server bildet den Domain-Namen des Servers auf die IP-Adresse eines geeigneten Servers ab URL-Rewriting: Server liefert Basisseite, die URLs der eingebetteten Objekte werden umgeschrieben, mit dem Domain- Namen eines geeigneten anderen Servers kommerzielle CDNs verwenden meist Kombination aus DNSbasierter Redirection und URL-Rewriting [RN] Sommer 2013 Anwendungsschicht 53

54 Content Distribution Networks Bsp. für URL-Rewriting ist Content-Provider, Video-Dateien werden auf den CDN- Servern von cdn.com verteilt 1. HTTP-Anfrage für HTML-Basisseite, Antwort enthält eingebettete Video-Datei 2. DNS-Anfrage für IP-Adresse von DNS-Server liefert aufgrund der IP-Adresse des Clients und einer internen Tabelle die IP- Adresse eines geeigneten Servers 3. HTTP-Anfrage an diesen Server Origin server 1 2 DNS query for 3 CDN s authoritative DNS server [RN] Sommer 2013 Anwendungsschicht 54

55 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 55

56 Socket-Schnittstelle Socket-Programmierung verbreitetes API für Transportdienste Festlegung von TCP/UDP, IP-Adressen, Portnummern Architektur: Kontrolle durch Anwendungsprogramm Kontrolle durch Betriebssystem Prozeß Socket TCP mit Puffern, Variablen Internet Prozeß Socket TCP mit Puffern, Variablen Kontrolle durch Anwendungsprogramm Kontrolle durch Betriebssystem Host oder Server Host oder Server [RN] Sommer 2013 Anwendungsschicht 56

57 Socket-Programmierung Beispiel für einfache Client- Server-Anwendung Client liest Zeile aus Standardeingabe (infromuser stream) und sendet ihn über ein TCP-Socket zum Server Server liest Zeile aus TCP- Socket Server konvertiert in Großbuchstaben (seine Dienstleistung) und sendet diese Zeichenkette über TCP- Socket zurück an Client Client liest Zeichenkette aus TCP-Socket und gibt diese auf Standardausgabe aus Client- Prozeß Tastatur infromuser Eingabestrom outtoserver Ausgabestrom Bildschirm infromserver clientsocket zur Transportschicht von der Transportschicht Eingabestrom TCP-Socket [RN] Sommer 2013 Anwendungsschicht 57

58 Socket-Programmierung Ein Ausflug in die Programmierpraxis [RN] Sommer 2013 Anwendungsschicht 58

59 Einführung Verbreitete Anwendungen Anwendungsschicht Hypertext Transfer Protocol (HTTP) Netzwerkmanagement Domain Name System (DNS) Content Distribution Networks Real-Time Protocol (RTP) Session Initiation Protocol (SIP) Socket-Programmierung Peer-to-Peer-Systeme [RN] Sommer 2013 Anwendungsschicht 59

60 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 u 1 d 1 u 2 d 2 u 5 u 3 Internet d 3 u 4 d N u N d d 6 u uu d 5 [RN] Sommer 2013 Anwendungsschicht 60

61 Peer-to-Peer P2P Anwendungen wie Napster und KaZaA zum direkten Austausch von Musikdateien (MP3) haben P2P populär gemacht Napster aus juristischen Gründen stillgelegt, diverse Nachfolger (Gnutella, Pastry, edonkey, ) Hauptteil des Netzverkehrs wird heute durch P2P erzeugt Peers kommunizieren direkt mittels TCP oder UDP P2P-Netze bilden Overlay-Netz: logisches Netz aus Peers über dem physikalischen Netz [RN] Sommer 2013 Anwendungsschicht 61

62 P2P: Architekturen Unstrukturiert (1st/2nd Generation) 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 2013 Anwendungsschicht 62

63 P2P: Unstrukturiert (Zentralisiert) Zentralisiertes Verzeichnis Architektur von Napster Eintritt eines Peers: er informiert zentralen Server über seine IP-Adresse und seine Inhalte Suche nach Inhalt: über zentralen Server Dateiübertragung: direkt zwischen Peers centralized directory server Bob peers zentraler Server juristischer Schwachpunkt Leistungs- und Zuverlässigkeitsproblem Alice [RN] Sommer 2013 Anwendungsschicht 63

64 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 Identität des ursprünglich anfragenden Peers bleibt so unbekannt) die Antwort findet zur Quelle zurück, diese kontaktiert direkt einen der Peers, der die Anfrage beantworten kann, die Übertragung erfolgt mittels HTTP kein zentraler Server benötigt Eintritt in das Overlay-Netzwerk: Nachricht an eine veröffentlichte Liste von möglichen Peers schicken Skalierbarkeit ist wegen des Flutens problematisch [RN] Sommer 2013 Anwendungsschicht 64

65 Hierarchie P2P: Unstrukturiert (Hybrid) 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 2013 Anwendungsschicht 65

66 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 2 m-1 ) aus Bezeichnerraum mit m Bits zugewiesen jedem Datenelement wird mittels Hash-Funktion 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 -Relation gilt bis auf Modulo 2 m-1 ) Lookup für ein Datenelement mit Schlüssel k erfolgt auf Peer succ(k) [RN] Sommer 2013 Anwendungsschicht 66

67 P2P: Strukturiert (Beispiel Chord) Routing Finden des gesuchten Eintrags in der DHT Chord verwaltet Ringstruktur über alle Einträge Jeweils Vorgänger und Nachfolger Routing entlang des Rings (ineffizient) oder durch Sprungtabellen (Finger- Tabelle, siehe nächste Folie) 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 entfernen Daten migrieren?; ID entfernen und Verzeigerung aktualisieren Selbststabilisierung Kontinuierliche Überprüfung aller Knoten, evtl. Verzeigerung reparieren [RN] Sommer 2013 Anwendungsschicht 67

68 P2P: Strukturiert (Beispield Chord) Finger-Tabelle jeder Peer p unterhält Finger-Tabelle FT p mit maximal m Einträgen i-ter Eintrag der Finger-Tabelle: FT p [i] = succ(p+2i-1) enthält Nachfolger mit exponentiell steigenden Distanz Lookup für Datenelement mit Schlüssel k Start mit beliebigem Peer p Wiederhole bis p k: wenn k FT p [1], dann q = FT p [1] wenn FT p [m] k, dann q = FT p [m] sonst q = FT p [i] k < FT p [i+1] p = q succ(k) = p Beispiel (nächste Folie) m = 5, Bezeichnerraum 0 p 2 m-1 = 31 farbige Peers gehören zum Overlay [RN] Sommer 2013 Anwendungsschicht 68

69 Eigentlicher Knoten Lookup von k =12 auf Peer Finger-Tabelle i Lookup von k = 26 auf Peer [RN] Sommer 2013 Anwendungsschicht 69

70 P2P: Strukturiert (Beispiel Chord) Lookup von k = 26 auf Peer 1 Lookup auf Peer 1 ergibt p = 18 = FT 1 [5] 26 Lookup auf Peer 18 ergibt p = 20 = FT 18 [2] 26 < FT 18 [3] Lookup auf Peer 20 ergibt p = 21 = FT 20 [1] 26 < FT 20 [2] Lookup auf Peer 21 ergibt p = 28 = FT 21 [1] 26 Ergebnis: succ(26) = 28 Lookup von k = 12 auf Peer 28 Lookup auf Peer 28 ergibt p = 4 = FT 28 [4] 12 < FT 28 [5] Lookup auf Peer 4 ergibt p = 9 = FT 4 [3] 12 < FT 4 [4] Lookup auf Peer 9 ergibt p = 11 = FT 9 [2] 12 < FT 9 [3] Lookup auf Peer 11 ergibt p = 14 = FT 11 [1] 12 Ergebnis: succ(12) = 14 Diverse weitere Operationen notwendig Aktualisierung des Overlays, Optimierung [RN] Sommer 2013 Anwendungsschicht 70

71 P2P: Praktische Anwendung Hybridarchitektur mit Tracker (Verwaltung) und Strukturiertem P2P Netz Tracker Peer Obtain list of peers Alice Trading chunks [RN] Sommer 2013 Anwendungsschicht 71