Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 8te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009

Lehrstuhl für Kommunikationssysteme - Systeme II2 Letzte Vorlesung Übungszettel #3 (hier oder online) Einstieg in die Anwendungsschicht (Stack von oben) Interaktion mit dem Benutzer bzw. von Diensten des Betriebs- systems/der Maschine, Nutzung der Dienste von Transport- und Verbindungsschicht

Lehrstuhl für Kommunikationssysteme - Systeme II3 Letzte Vorlesung DNS: Telefonbuch des Internets Weltweit verteilte, skalierbare Datenbank zur Übersetzung von Objekten ineinander Typischerweise Auflösung von Rechnernamen zu IP-Adressen

Lehrstuhl für Kommunikationssysteme - Systeme II4 Letzte Vorlesung DNS: UDP-basierter Dienst der TCP/IP-Anwendungsschicht, implementiert in den Basisbibliotheken des Betriebssystems Damit von fast allen Diensten implizit mitgenutzt (ping muss erst die IP ermitteln, ehe ICMP Pakete adressiert werden können) Weltweit verteilte, skalierbare Datenbank zur Übersetzung von Objekten ineinander Typischerweise Auflösung von Rechnernamen zu IP-Adressen, kann aber auch mehr (verschiedene weitere Resource Records für MX – , E.164 – VoIP,..., TXT,...)

Lehrstuhl für Kommunikationssysteme - Systeme II5 WWW – Das World Wide Web Das Domain Name System (DNS) wird uns weiter begleiten Nun vorgestellte Protokoll des WWW macht (mittelbar) heftigen Gebrauch von DNS, speziell auch vom CNAME Resource Record Letzteres erlaubt Betrieb sehr vieler Web-Präsenzen auf einzigen IP, Beispiel Uni-Freiburg Lange Zeit lösten bspw. und freiburg.de (und etliche weitere Namen) auf eine einzige IP- Adresse auf (bzw. zwei, da Load-Balancing) Vielfach bei Standard-Hostern so zu finden An der Uni – nun neues Konzept: -Eine IP per Auftritt für SSL (erfordert aufgrund des Protokolls Eindeutigkeit) -Zusammenfassung unterhalb einer gemeisamen Portal- adresse, so für

Lehrstuhl für Kommunikationssysteme - Systeme II6 WWW – Das World Wide Web Anwender sieht nur Anwendungen, daher für diese WWW als Inkarnation des Internet mit seinen durchaus sehr verschiedenartigen Diensten Komplettes Verstecken von Verbindungs- und Transport- schichtfunktionen Rechnernamen von der Sichtbarkeit dominierend gegenüber IP- Adressen Web-Adressen müssen daher mit anfangen, wenn dieses in keinster Weise zwingend

Lehrstuhl für Kommunikationssysteme - Systeme II7 WWW – Die Anfänge HTTP am Cern erfunden B. Lee Geschichte des Protokolls HTTP/0.9 - der erste Anlauf nur GET-Methode, die einfache Datei (HTML-Objekt) zurückliefert HTTP/1.0 Der Weg zum Standard -Mehrere Methoden -Multimedia-Objekte HTTP/1.0+ -Nicht standardisierte, erweiterte Version

Lehrstuhl für Kommunikationssysteme - Systeme II8 WWW – Die Anfänge Geschichte des Protokolls HTTP/1.1 Standardisierung und Evolution -Persistente Verbindungen -Cookies in den Header -Benutzerauthentifizierung -Methoden weiter entwickelt Dann ein Versuch HTTP-NG (HTTP/2.0) als zukünftige Entwicklung, die irgendwann abgebrochen wurde...

Lehrstuhl für Kommunikationssysteme - Systeme II9 WWW – Generelle Funktionsweise Klassische Client-Server-Architektur –Web-Server stellt Web-Seiten bereit –Web-Browser fragen Seiten vom Server ab

Lehrstuhl für Kommunikationssysteme - Systeme II10 WWW – Generelle Funktionsweise Terminologie Client-Server-Architektur –Web-Server stellt Web-Seiten bereit –Ressource -Quelle des Webinhalts -beliebige Datei -dynamisch-generierte Ressource Format: Hypertext Markup Language (HTML/X-HTML) –Web-Browser fragen Seiten vom Server ab –User Agent Server und Browser kommunizieren mittels Hypertext Transfer Protocol (HTTP)

Lehrstuhl für Kommunikationssysteme - Systeme II11 WWW – Semantische Komponenten Semantische Komponenten Adressierung der Ressourcen -Uniform Resource Identifier (URI) -Syntax :// [ ]/ -Beispiel freiburg.de/php_veranstaltungsdetail.php?id=28http:// freiburg.de/php_veranstaltungsdetail.php?id=28 -URL: Uniform Resource Locator -URN: Uniform Resource Name -z.B urn:isbn:

Lehrstuhl für Kommunikationssysteme - Systeme II12 WWW – Semantische Komponenten Darstellung der Informationen In den Anfängen -Hypertext Markup Language (HTML) -Seitenbeschreibungssprache angelehnt an Standard Generalized Markup Language (SGML) – aber nicht konform dazu -Ende der Entwicklung von HTML mit Version 4.01 Aktuell/zukünftig -Extensible HyperText Markup Language (XHTML) -Basierend auf Extensible Markup Language (XML) – konform zu SGML -Ergänzt durch Synchonized Multimedia Integration Language (SMIL) zur Darstellung und Steuerung multimedialer Inhalte

Lehrstuhl für Kommunikationssysteme - Systeme II13 WWW – HTTP Das HyperText Transport Protocol nutzt TCP (Standard: Serverport 80) für Datenaustausch HTTP ist nicht statusbehaftet Jede Folge von HTTP-Request und HTTP-Response wird unabhängig von vorangegangenen Übertragungen bearbeitet Aufhebung dieses Prinzips durch Cookies oder serverseitiges Session-Management auf Applikationsebene HTTP-Messages bestehen aus Header und Body Header enthält Kontrollinformationen – inline signaling Kontrollinformationen werden im Klartext (ASCII-Zeichen) übertragen Body enthält das übertragene Objekt HTTP-Requests können Nutzdaten enthalten, z. B. Eingaben aus Formular, Passworte,...

Lehrstuhl für Kommunikationssysteme - Systeme II14 WWW – HTTP Request/Response Methoden Messages -Einfache, line-orientierte Sequenzen vonZeichen -Zwei Typen: Request, Response Request-Kommandos (HEAD, GET, POST, PUT, TRACE, OPTIONS, DELETE, CONNECT)

Lehrstuhl für Kommunikationssysteme - Systeme II15 WWW – HTTP Request GET-Methode Holen aller Informationen aus Request-URI (beispielsweise Optionen zur Anzeigensprache, Characterset,...) Anfragen: keine Seiteneffekte Antworten: cache-bar (Cache später in der Vorlesung)

Lehrstuhl für Kommunikationssysteme - Systeme II16 WWW – HTTP Request HEAD Liefert nur die Header-Feldern zurück, sonst ähnlich zur GET- Methode Verwendung: -Überprüfung von Links -Abruf von Informationen über Ressource POST Schicken von Eingabedaten an den Server Häufig verwendet bei HTML-Formularen, CGI-Skripten

Lehrstuhl für Kommunikationssysteme - Systeme II17 WWW – HTTP Request PUT Schickt ein Document an dem Server Request-URI schon eine Ressource Existiert unter Request-URI keine Ressource Status-Code 5xx POST vs. GET & PUT POST erzeugt keine neue Ressource (im Gegensatz zu PUT) Antworten nicht in Caches abgelegt Signifikante Seiteneffekte (im Gegensatz zu GET, z.B. Probleme mit wiederholten Eingaben beim Formularabsenden)

Lehrstuhl für Kommunikationssysteme - Systeme II18 WWW – HTTP Response Status-Codes in den Response-Messages Numerischer Code mit 3 Ziffern im Response -Status-Code = 1xx Informationen - | 2xx Erfolgreiche Operation - | 3xx Umleitung - | 4xx Client Fehler - | 5xx Server Fehler - | extension-code (3DIGIT) Beispiele -200: OK -302: Redirect -404: Ressource nicht gefunden

Lehrstuhl für Kommunikationssysteme - Systeme II19 WWW – HTTP Response Request / Response-Messages bei Anfrage auf freiburg.de (Antwort abgeschnitten) freiburg.de

Lehrstuhl für Kommunikationssysteme - Systeme II20 HTTP Authenfizierung Eingeführt mit HTTP Ziel: Schutz sensibler Daten z.B. personalisierte/geschützte Bereiche von Web-Ressourcen Problem: HTTP ist zustandlos Mit zustandslosen Methoden realisiert Zwei Varianten: -Basic Authentication (RFC 2045) -Digest Authentication (RFC 2069) [Request] GET /geheim/index.php HTTP/1.1 Host: [Response] HTTP/ Unauthorized WWW-Authenticate: Basic realm="Geheimer Bereich"

Lehrstuhl für Kommunikationssysteme - Systeme II21 HTTP Authenfizierung Basic Authentication WWW-Authenticate-Header: Benutzername Passwort Realm (ggf. mehrere geschützte Bereiche) Nachteil: Nutzerdaten i.W. unverschlüsselt übertragen Durch Dritten verwertbar (selbst bei Hashing) Nutzdaten unverschlüsselt übertragen

Lehrstuhl für Kommunikationssysteme - Systeme II22 HTTP Authenfizierung Digest Authentication Verschlüsselung des Passworts (MD5) Mitversenden weiterer Digest-Informationen: -Benutzername -Real Value -Nonce (IP, Timestamp, priv. Schlüssel des Servers) -HTTP-Methode die der Client anwenden will -Adresse der Ressource Nachteil: Nutzdaten unverschlüsselt übertragen

Lehrstuhl für Kommunikationssysteme - Systeme II23 HTTP Zustandsmanagement HTTP ist zustandsloses Protokoll Problem für Sitzungsmanagement Bei Realisierung von Web-Shops, Content Management Systeme, Wikis,... Lösungsansätze: Cookies (Erfindung von Netscape) -Kein Teil von HTTP -Kleine Text-Datei auf dem jeweiligen Client Hidden form fields Parameter für URLs Produziert gewissen Overhead

Lehrstuhl für Kommunikationssysteme - Systeme II24 Zustandsmanagement via Cookie [Request] GET /index.php HTTP/1.1 Host: [Response] HTTP/ OK Set-Cookie: customer="12345";name=HTMLWorld; path=/; domain= [Erneuter Request] GET /program/http_1.php HTTP/1.1 Host: Cookie: name=HTMLWorld

Lehrstuhl für Kommunikationssysteme - Systeme II25 Zustandsmanagement via Cookie Parameter domain spezifiziert die Domains bei der Client das Cookie senden muss Ebefalls bei path Speicherung von (z.B. Formular-) Daten Lebensdauer eines Cookies steuern: expires=Datum Cookies inzwischen privacy-kritisch gesehen – Verfolgung von Benutzern weit über Session-Management hinaus Deshalb vielfach gefiltert oder gelöscht – wieder neue Methoden der Nutzerverfolgung...

Lehrstuhl für Kommunikationssysteme - Systeme II26 WWW – Software-Komponenten (Clients) WWW-Clients (typischerweise Browser) Interpretieren eingegebener URLs Abruf der Objekte von WWW-Servern Interpretieren des abgerufenen Seiten-(HTML)-Codes Darstellung der Inhalte/Informationen Automatischer Abruf eingebetteter Objekte Ausführen von Programmcode (JavaScript, ActiveX) Ausführen und Steuern zusätzlicher Programme (Plug-Ins)

Lehrstuhl für Kommunikationssysteme - Systeme II27 WWW – Software-Komponenten (Server) WWW-Server (inzwischen oft kom- plexe Softwarepakete) Empfang von HTTP-Requests Auswerten der URL nach dem gewünschten Objekt Ursprünglich: Lesen des Objekts aus dem Dateisystem Vielfach: Generieren des Objekts (Datenbank, Skriptsprachen,...) Übertragen des Objekts in einer HTTP-Response

28 Web-Server und Datenbanken Zeiten des statischen Webs weitgehend vorbei Dynamisch generierter Content in Abhängigkeit von User- Anfragen Klassischerweise auf Serverseite durch Skriptsprachen, die HTML-on-the-fly generieren (PHP, Perl, Phyton, Ruby-on-Rails,...) Web-Server stellen nicht nur statische Web-Seiten zur Verfügung Web-Seiten werden auch automatisch erzeugt Hierzu wird auf eine Datenbank zurückgegriffen Diese ist nicht statisch und kann durch Interatkionen verändert werden

29 Web-Server und Datenbanken Problem: Konsistenz der Daten Lösung Web-Service und Daten-Bank in einer 3-Stufen-Architektur Server farm Client1 Client n Server 1 Server 2 Server 3 Datenbank Web- Browser

30 Web-Server-Farm Große Dienste, wie beispielsweise Suchmaschinen, Nach-richtenseiten, Social Media,... nicht durch eine Maschine bedienbar Um die Leistungsfähigkeit auf der Server-Seite zu erhöhen wird eine Reihe von Web-Server eingesetzt Frontend nimmt Anfragen an reicht sie an separaten Host zur Weiterbearbeitung weiter

31 Web-Cache Trotz Server-Farm ist die Latenzzeit häufig kritisch Lösung: Cache (Proxy) WWW-Proxy-Server und WWW-Cache-Server Zwischen WWW-Server und WWW-Client geschaltete Server (damit in ihrer Funktion sowohl Clients als auch Server) Leiten HTTP-Requests von WWW-Clients an WWW-Server Leiten HTTP-Responses von WWW-Servern an WWW- Clients zurück Sind definierte Durchgangspunkte für WWW-Verkehr – interessant für Security

Lehrstuhl für Kommunikationssysteme - Systeme II32 Web-Cache und Web-Proxy (Server) Orte Beim Client Im lokalen Netzwerk (bei einem Proxy) Beim Internet-Service-Provider Fragen Plazierung, Größe, Aktualität Entwertung durch Timeout

33 Content Distribution Networks (CDN) Eine koordinierte Menge von Caches Die Last großer Web-Sites wird verteilt auf global verteilte Server-Farmen Diese übernehmen Web-Seiten möglichst verschiedener Organisationen -z.B. News, Software-Hersteller, Regierungen Beispiele: Akamai, Digital Island Cache-Anfragen werden auf die regional und lastmäßig bestgeeigneten Server umgeleitet Beispiel Akamai: Durch verteilte Hash-Tabellen ist die Verteilung effizient und lokal möglich

Lehrstuhl für Kommunikationssysteme - Systeme II34 Ende der siebten Vorlesung Ende der achten Vorlesung Sicherheitsfragen (Datenschutz, Manipulierbarkeit, Abhörsicherheit...): Wie auch DNS – nicht besonders sicher (gut mitlesbar) und recht gut manipulierbar Ein Ansatz: Absicherung durch SSL (bspw. in Systeme III,...) Thema Netzwerksicherheit gewinnt an Relevanz: Bspw. Thema auf Heise: Pentagon fördert Hacker - /meldung/138317

Lehrstuhl für Kommunikationssysteme - Systeme II35 Ende der siebten Vorlesung Ende der achten Vorlesung Nächste Vorlesung am Mittwoch an diesem Ort, gleiche Zeit: Weiter im Themenbereich – Ausgewählte Protokolle der Applikationsschicht (Electronic Mail) Nach der Pfingstpause: Übungen am 8.6. im Rechenzentrum, am dann Vorlesung, weiter zur Transportschicht Bitte theoretischen Übungszettel #3 ergreifen, steht auch wieder online zur Verfügung Lösungen zu Zettel #2 werden ebenfalls online bereitgestellt Alle relevanten Informationen auf der Webseite zur Vorlesung: freiburg.de/php_veranstaltungsdetail.php?id=28 freiburg.de/php_veranstaltungsdetail.php?id=28 Vorbereitung: Lesen zu (SMTP, POP, IMAP) in der angegebenen Literatur!