View
109
Download
1
Category
Preview:
Citation preview
Lehrstuhl für Kommunikationssysteme - Systeme II 1
Systeme II – 8te Vorlesung
Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät
Universität Freiburg2009
Lehrstuhl für Kommunikationssysteme - Systeme II 2
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 II 3
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 II 4
Letzte Vorlesung
‣ DNS:• UDP-basierter Dienst der TCP/IP-Anwendungsschicht,
implementiert in den Basisbibliotheken des Betriebssystems
• Damit von fast allen Diensten implizit mitgenutzt (ping www.google.de 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 – Email, E.164 – VoIP, ..., TXT, ...)
Lehrstuhl für Kommunikationssysteme - Systeme II 5
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. www.uni-freiburg.de und www.ks.uni-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 www.rz.uni-freiburg.de
Lehrstuhl für Kommunikationssysteme - Systeme II 6
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 “www.*” anfangen, wenn dieses in keinster Weise zwingend
Lehrstuhl für Kommunikationssysteme - Systeme II 7
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 II 8
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 II 9
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 II 10
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 II 11
WWW – Semantische Komponenten
‣ Semantische Komponenten•Adressierung der Ressourcen
- Uniform Resource Identifier (URI)- Syntax <protocol>://<address>[<:port>]/<filename>
- Beispiel http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28
- URL: Uniform Resource Locator
- URN: Uniform Resource Name
- z.B urn:isbn:0-395-36341-1
Lehrstuhl für Kommunikationssysteme - Systeme II 12
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 II 13
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 II 14
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 II 15
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 II 16
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 II 17
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 II 18
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 II 19
WWW – HTTP Response
‣ Request / Response-Messages bei Anfrage auf www.ks.uni-freiburg.de (Antwort abgeschnitten)
Lehrstuhl für Kommunikationssysteme - Systeme II 20
HTTP Authenfizierung
‣ Eingeführt mit HTTP 1.1 - 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: www.domain.de
‣ [Response]• HTTP/1.1 401 Unauthorized
• WWW-Authenticate: Basic realm="Geheimer Bereich"
Lehrstuhl für Kommunikationssysteme - Systeme II 21
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 II 22
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 II 23
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 II 24
Zustandsmanagement via Cookie
‣ [Request] GET /index.php HTTP/1.1 Host: www.html-world.de‣ [Response] HTTP/1.1 200 OK Set-Cookie: customer="12345";name=HTMLWorld; path=/; domain=www.html-world.de;...‣ [Erneuter Request] GET /program/http_1.php HTTP/1.1 Host: www.html-world.de Cookie: name=HTMLWorld
Lehrstuhl für Kommunikationssysteme - Systeme II 25
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 II 26
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 II 27
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 II 32
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 II 34
Ende der siebten VorlesungEnde 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” -
http://www.heise.de/newsticker/Pentagon-foerdert-Hacker--/meldung/138317
Lehrstuhl für Kommunikationssysteme - Systeme II 35
Ende der siebten VorlesungEnde 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 10.6. 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:
http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28
Vorbereitung: Lesen zu Email (SMTP, POP, IMAP) in der angegebenen Literatur!
Recommended