8. ANWENDUNGSSCHICHT (2)

Transkript

1 KOMMUNIKATIONSNETZE UND - PROTOKOLLE 8. ANWENDUNGSSCHICHT (2) 1 / v5

2 1. EINFÜHRUNG HEUTIGES LERNZIEL: als Beispiel für Anwendungsdienste MIME-Erweiterung Funktionsweise des http-protokolls http-erweiterung: WebSocket 2 / v5

3 8. ANWENDUNGSSCHICHT MIME-Erweiterung 8.3 HTTP-Protokoll 8.4 Web-Socket 3 / v5

4 ARCHITEKTUR EINES -SYSTEMS (1) -CLIENT -SERVER UA MTA USER AGENT MESSAGE TRANSFER AGENT Der Zugriff auf ein -System erfolgt über den UA (Benutzer-Agent = - Client) Jeder UA ist mit einem MTA (Nachrichten-Übertragungs-Agenten = -Server) verbunden, auf dem der Benutzer ein Konto (Zugriffsberechtigung) besitzt Der Sender-MTA überträgt eine an den Empfänger-MTA. Dort wird die Nachricht zwischen gespeichert, bis der UA des Empfängers diese dort abholt Ein UA muss keine ständige Verbindung zum MTA unterhalten 4 / v5

5 ARCHITEKTUR EINES -SYSTEMS (2) UA: USER AGENT UA UA UA MTA MTA MTA UA MTA MTA: MESSAGE TRANSFER AGENT 5 / v5

6 ERWEITERTE -ARCHITEKTUR -CLIENT -SERVER -CLIENT MUA MSA MTA MTA MDA MUA MAIL USER AGENT MESSAGE SUBMISSION AGENT MESSAGE TRANSFER AGENT MESSAGE DELIVERY AGENT MAIL USER AGENT MDA war ursprünglich zusammen mit MUA (= UA) Basis von -Systemen MSA nimmt s nur von berechtigten MUAs entgehen (z. B. über Port 587) Hier nimmt der MTA s nur vom MSA entgehen, nicht mehr direkt von MUAs MTA kann über DNS den MSA überprüfen (ist bei einem MUA nicht möglich) Meist sind mehrere Funktionen in einem Mail-Server vereint 6 / v5

7 PROTOKOLLE DES -SYSTEMS -CLIENT Senden: SMTP-Protokoll MSA -SERVER MUA Empfangen: POP-Protokoll IMAP-Protokoll MDA MTA SMTP: POP: IMAP: Simple Mail Transport Protocol Post Office Protocol Internet Message Access Protocol Zum Senden immer SMTP POP bzw. IMAP zum Abholen der s vom -Server POP ist einfaches Protokoll i. A. nur für einen Client IMAP erlaubt Zugriff von mehreren Clients und Ordner-Strukturen auf Server 7 / v5

8 -ZUGRIFF MIT POP UND IMAP POP: Post Office Protocol Ältestes und einfaches Zugriffsprotokoll, um s vom Server abzuholen Unterstützt nur einen einzigen Posteingangs-Ordner Für Zugriff von einem einzigen Client-Rechner ausgelegt Beim Zugriff mit verschiedenen -Clients kommt es häufig zu Problemen (z. B. beim Löschen der s im Postfach des -Servers) IMAP: Internet Message Access Protocol Modernes und leistungsfähiges Protokoll, um s vom Server abzuholen Unterstützt Ordner-Hierarchien im Postfach auf dem Server Zugriff mit wechselnden Clients möglich Ordner-Struktur und Inhalte werden automatisch auf allen Clients und auf dem Server synchron gehalten 8 / v5

9 WEBMAIL-ZUGANG -CLIENT -SERVER Web- Browser HTTP Web- Server MUA MSA MTA MDA HTML WEBMAIL-SERVER Webmail-Zugang erfolgt über Web-Browser -Client befindet sich auf Webmail-Server -Client wird mit Web-Browser über HTML bedient 9 / v5

10 GRUNDFUNKTIONEN EINES -SYSTEMS COMPOSITION TRANSFER REPORTING DISPLAYING DISPOSITION Erstellen und Beantworten von s Automatische Beförderung Information über aufgetretene Probleme bei Zustellung, z. B.: Empfänger unbekannt Bestätigung der Zustellung... Anzeigen von empfangenen Nachrichten, ggf. Konvertierung Lokale Verwaltung der empfangenen Nachrichten im UA: archivieren löschen / v5

11 ERWEITERTE -FUNKTIONEN NACHSENDEN STELLVERTRETER z. B. nach Umzug oder während des Urlaubs Kopie an andere Empfänger, wenn der eigentliche Empfänger z. Z. nicht erreichbar ist EINGESCHRIEBENE MAIL FILTER MAILING-LISTEN automatische Auswahl und Speicherung empfangener Mails in Ordner-Hierarchie, anhand von Auswahlkriterien Senden einer Mail an alle Adressen einer Verteilerliste 11 / v5

12 VERGLEICH BRIEF UND 32 Mr. Daniel Dumkopf 18 Willow Lane White Plains, NY United Gizmo 180 Main St Boston, MA March 1, 2012 Subject: Invoice 1081 Dear Mr. Dumkopf, Our computer records show that you still have not paid the above invoice of $0.00. Please send us a check for $0.00 promptly. Yours truly United Gizmo UMSCHLAG HEADER BODY Name: Mr. Daniel Dumkopf Street: 18 Willow Lane State: NY Zip code: Priority: Urgent From: United Gizmo Address: 180 Main St Location: Boston, MA Date: March 1, 2012 Subject: Invoice 1081 Dear Mr. Dumkopf, Our computer records show that you still have not paid the above invoice of $0.00. Please send us a check for $0.00 promptly. Yours truly United Gizmo 12 / v5

13 AUFBAU EINER WICHTIGES KONZEPT: Klare Trennung von Umschlag, Header und Body! Mail UMSCHLAG Immer unverschlüsselt Inhalt HEADER (BRIEFKOPF) BODY (TEXT) Evtl. verschlüsselt Wichtig z.b. für Verschlüsselung (nur der Inhalt wird verschlüsseln) Internet-Standard RCF 822 sieht keine Trennung von Umschlag und Header vor Header kann aber vertrauliche Informationen enthalten (u. a. im Betreff) 13 / v5

14 AUFBAU EINER WICHTIGES KONZEPT: Klare Trennung von Umschlag, Header und Body! Mail UMSCHLAG Im Internet (RFC 822) immer unverschlüsselt Inhalt HEADER (BRIEFKOPF) BODY (TEXT) Wichtig z.b. für Verschlüsselung (nur der Inhalt wird verschlüsseln) Internet-Standard RFC 822 sieht keine Trennung von Umschlag und Header vor Header kann aber vertrauliche Informationen enthalten (u. a. im Betreff) 14 / v5

15 ADRESSEN NACH RFC 822 Nutzt das allgemeine Internet-Adressierungsschema mittels DNS-Adressen (Domain Name Service) BENUTZERNAME DNS-ADRESSE Beispiel: 15 / v5

16 RFC 822 HEADER-FELDER FROM: SENDER: TO: CC: BCC: RECEIVE: RETURN-PATH: Ersteller der Adresse des tatsächlichen Absenders -Adressen der primären Empfänger -Adressen der sekundären Empfänger (Carbon Copy) -Adressen für "blinde" Kopien (Blind Carbon Copy) Zeile, die von jedem MTA auf dem Weg eingefügt wird auf welchem Weg eine Antwort zurück gesendet werden soll (selten genutzt, Einhaltung von MTA nicht garantiert) 16 / v5

17 WEITERE RFC 822 HEADER-FELDER DATE: REPLY-TO MESSAGE-ID: IN-REPLY-TO: REFERENCE: KEYWORDS: SUBJECT: Datum und Uhrzeit, wann die gesendet wurde Adresse, an die Antworten gesendet werden können Eindeutige Kennung der Kennung der Nachricht, der diese Antwort gilt Andere relevante -Kennungen Vom Benutzer gewählte Schlüsselwörter Kurzer einzeiliger Betreff der Nachricht 17 / v5

18 BENUTZER-DEFINIERTE HEADER-FELDER RFC 5322 beschreibt, dass Benutzer weitere, eigene Header definieren können Diese Header beginnen üblicherweise mit X- BEISPIEL: X-HRZ-JLUG-MailScanner-Information: Passed JLUG virus check X-HRZ-JLUG-MailScanner: No virus found X-Spam-Status: No 18 / v5

19 NACH RFC 822 (ASCII-VERSION) AUFBAU EINER HEADER-FELDER LEERZEILE NACHRICHTENTEXT Alle Angaben in reinem ASCII-Text (7 bit codiert) Jedes Header-Feld besteht aus einer Zeile (Feldname, Doppelpunkt, Wert) Header-Felder werden nicht nach Umschlag und eigentlichem Header unterschieden 19 / v5

20 ASCII 7-BIT CODE ASCII - American Standard Code for Information Interchange 7-Bit-Zeichenkodierung (erstmals 1963 veröffentlicht) 128 Zeichen (33 nicht druckbaren Steuerzeichen und 95 druckbaren Zeichen) 20 / v5

21 BEISPIEL EINER RFC 822 Received: from merkurneu.hrz.uni-giessen.de ([ ]) by fhfddvz1.rz.hs-fulda.de with ESMTP (NOT encrypted); Fri, 27 Jul :47: Return-Path: Received: from [ ] Received: from [ ] From: "Werner Winzerling" <Werner@Winzerling.de> To: <Werner.Winzerling@informatik.hs-fulda.de> Subject: Meeting am Date: Fri, 27 Jul :47: Message-Id: <000301cd6bf5$ec4aff70$c4e0fe50$@Winzerling.de> X-Mailer: Microsoft Outlook 14.0 Content-Language: de Das Meeting am muss leider ausfallen. Viele Gruesse an das Team. W. Winzerling 21 / v5

22 BEISPIEL EINER RFC 822 Received: from merkurneu.hrz.uni-giessen.de ([ ]) by fhfddvz1.rz.hs-fulda.de with ESMTP (NOT (NOT encrypted); Fri, 27 Jul :47: Return-Path: Received: from [ ] Gefordert ist ESMTPS Received: Extended from [ ] SMTP-Erweiterungen Erweiterungen zur sicheren, From: "Werner erlaubt Winzerling" u.a. verschlüsselte <Werner@Winzerling.de> verschlüsselten Übertragung To: <Werner.Winzerling@informatik.hs-fulda.de> Übertragung vom Mail-Client zwischen den -Server Subject: zum Meeting Mail-Server am Date: Fri, 27 Jul :47: Message-Id: <000301cd6bf5$ec4aff70$c4e0fe50$@Winzerling.de> X-Mailer: Microsoft Outlook 14.0 Content-Language: de Das Meeting am muss leider ausfallen. Viele Gruesse an das Team. W. Winzerling 22 / v5

23 SICHERE ÜBERTRAGUNG MAIL-SERVER UA: USER AGENT UA UA UA ESMTP MTA ESMTPS MTA MTA UA MTA MTA: MESSAGE TRANSFER AGENT 23 / v5

24 ZUSAMMENFASSUNG: Ein -System besteht aus User Agent (UA), dem Mail-Client sowie Message Transfer Agent (MTA), dem Mail-Server Funktional kann neben dem Message Transfer Agents (MTA) auch noch der Message Submission Agent (MSA) und der Message Delivery Agent (MDA) unterschieden werden Eine ist strukturiert und besteht (idealerweise) aus Umschlag, Header und Body Genutzt wird Internet-Mail-Standard RFC 822 Beim Webmail wird der -Client über Browser gesteuert In der ursprünglichen Form wurden im Internet nur 7-bit-ASCII-Zeichen für die Übertragung und damit auch für die s verwendet 24 / v5

25 8. ANWENDUNGSSCHICHT MIME-ERWEITERUNG 8.3 HTTP-Protokoll 8.4 Web-Socket 25 / v5

26 NACHRICHTENFORMAT MIME Übertragung im Internet ursprünglich (nur) in ASCII mit 7-bit PROBLEM Länderspezifische Sonderzeichen (z. B. Umlaute) Sprachen ohne Alphabet (Chinesisch, Japanisch) Multimedia-Daten (Bilder, Video, Audio,...) LÖSUNG: MIME MIME (Multipurpose Internet Mail Extensions) Erweiterungen der RFC 822-Kodierung Übertragung beliebiger 8-bit-kodierten Daten auch über 7-bit-Verbindungswege 26 / v5

27 ZUSÄTZLICHE MIME-HEADER-FELDER Die Header-Felder aus dem RFC 822 wurden für MIME erweitert: MIME-VERSION: CONTENT-DESCRIPTION: CONTENT-ID: CONTENT-TRANSFER-ENCODING: CONTENT-TYPE: Bezeichnet die verwendete MIME-Version Erläutert den Inhalt der Nachricht z. B. Foto von Barbaras Meerschwein Eindeutiger Bezeichner, analog zu Message-Id Beschreibt Kodierung des Nachrichteninhalts Beschreibt Typ und Format der Nachricht 27 / v5

28 CONTENT-TRANSFER-ENCODING Zur Auswahl stehen (mindestens) Kodierungsmöglichkeiten: ASCII 8-bit Binärkodierung Base64 Quoted-Printable MIME (HTML) 28 / v5

29 ENCODING: ASCII, 8-BIT ASCII nur aus ASCII-Zeichen (7-bit) 8. bit wird nicht berücksichtigt, da früher nur 7 bit von jedem Byte übertragen wurden max. Zeilenlänge: 1000 Zeichen Ursprünglicher Standard nach RFC bit Binärkodierung Übertragen werden 8-bit Verletzung des ursprünglichen Kodierschemas Nur möglich, wenn beide Mail-Server diese Erweiterung unterstützen und die Leitungen durchgängig 8 Bit übertragen 29 / v5

30 ENCODING: BASE64 Base64 Eine "richtige" Art Binärdaten zu kodieren Zerlegt Gruppen von 24 bit (3 * 8 bit) in 4 * 6 bit Einheiten Jede Einheit ergibt ein zulässiges ASCII-Zeichen Auch als "3-4" oder "3-zu-4-Kodierung" bezeichnet KODIERUNG: (Nicht benutzte 6-bit-Einheiten werden mit "=" bzw. "==" angezeigt) 6-bit-Einheit Kodierzeichen "A" "B"... "Z " "a " "b"... "z" "0" "1"... "9" "+" "/" 30 / v5

31 ENCODING: BASE64 Quelle: Lars Rohwedder, Wikipedia 6-bit-Einheit Kodierzeichen "A" "B"... "Z " "a " "b"... "z" "0" "1"... "9" "+" "/" 31 / v5

32 BEISPIEL: BASE64-KODIERUNG Grüße umkodiert zu R3L832U= 1. Gruppe mit 24-bit 2. Gruppe mit 24-bit AUS 3 * 8 BIT WIRD 4 * 6 BIT ASCII-CODE G r ü ß e E (00) R 3 L U = 32 / v5

33 ENCODING: QUOTED-PRINTABLE Quoted-Printable Weitere "richtige" Art Binärdaten zu kodieren Wenn Nachricht (fast) nur 7-bit-ASCII-Zeichen enthält und wenige ASCII-fremde Zeichen (wenige Umlaute) KODIERUNG: if (Zeichen > 127) /* das 8. Bit wird benutzt */ then Darstellung als Hexadezimalzahl in der Form: "=hexa" else "normale" Zeichendarstellung ü ß BEISPIEL: Grüße umkodiert zu G r = F C = D F e 33 / v5

34 ENCODING: HTML HTML CODE-BEISPIELE: als komplette HTML-Seite durch Internet-Einfluss neue Kodierungsform HTML kodiert Text (auch) in 7-bit-ASCII-Code Aber: Nicht bei (sehr) alten -Clients verfügbar Ausführbarer HTML-Code führt zu Sicherheitsproblemen 8-BIT-ZEICHEN UMKODIERUNG < < ä & ß ä & ß 34 / v5

35 ENCODING KODIERUNG 8-BIT, BINÄR BASE64 ASCII QUOTED-PRINTABLE HTML Sollten nie verwendet werden BEWERTUNG Wird zur Kodierung von Anhängen (Binärdateien) in s genutzt Wenn vom Empfänger nichts bekannt ist ( Hardcore-UNIX- Freaks nutzen dieses Format mitunter noch) sowie bei klassischen Newsgruppen Empfohlene Einstellung (aber nicht für klassischen Newsgruppen) Häufig die Standardeinstellung in -Programmen (aber nicht unproblematisch) 35 / v5

36 BEISPIEL FÜR ENCODING [...] Content-Type: text/plain Content-Transfer-Encoding: ASCII Das Meeting faellt leider aus. Viele Gruesse an das Team. [...] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: Quoted-Printable Das Meeting f=e4llt leider aus. Viele Gr=FC=DFe an das Team. 36 / v5

37 PROBLEME MIT QUOTED-PRINTABLE MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailer: dtmail Version SunOS 5.10 sun4u sparc 37 / v5

38 BEISPIEL FÜR ENCODING [...] Content-Type: text/plain Content-Transfer-Encoding: ASCII Das Meeting faellt leider aus. Viele Gruesse an das Team. [...] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: base64 RGFzIE1lZXRpbmcgZuRsbHQgbGVpZGVyIGF1cy4gVmllbGUgR3L832UgYW4gZGFzI FRlYW0uDQoNClByb2YuIERyLiBXZXJuZXIgV2luemVybGluZw0KRkggRnVsZGEgIC0g IEFuZ2V3YW5kdGUgSW5mb3JtYXRpaw0KDQo= 38 / v5

39 CLIENT-EINSTELLUNG: NEWS MIT ASCII Rich-Text entspricht hier Quoted-Printable 39 / v5

40 ZUSÄTZLICHE MIME-HEADER-FELDER Die Header-Felder aus dem RFC 822 wurden für MIME erweitert: MIME-VERSION: CONTENT-DESCRIPTION: CONTENT-ID: CONTENT-TRANSFER-ENCODING: CONTENT-TYPE: Bezeichnet die verwendete MIME-Version Erläutert den Inhalt der Nachricht z. B. Foto von Barbaras Meerschwein Eindeutiger Bezeichner, analog zu Message-Id Beschreibt Kodierung des Nachrichteninhalts Beschreibt Typ und Format der Nachricht 40 / v5

41 MIME-ERWEITERUNGEN TYP UNTERTYP BESCHREIBUNG text plain, html, xml, css Text in verschiedenen Formaten image gif, jpeg, tiff, png Bilder audio basic, mpeg, mp4 Audiodateien video Mpeg, mp4, quicktime Filme model Vrml 3-D-Modelle application octet-stream, pdf, javascript, zip Anwendungsdaten message http, rfc822 Eingeschlossene Nachricht multipart mixed, alternative, parallel, digest Kombination von Typen BEISPIELE: text/plain text/html image/jpeg multipart/alternative 41 / v5

42 MULTIPART NACHRICHT From: To: MIME-Version: 1.0 Message-Id: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm Subject: Earth orbits sun integral number of times This is the preamble. The user agent ignores it. Have a nice day. --qwertyuiopasdfghjklzxcvbnm Content-Type: text/html <p>happy birthday to you<br> Happy birthday to you<br> Happy birthday dear <b> Bob </b><br> Happy birthday to you</p> --qwertyuiopasdfghjklzxcvbnm C: Content-Type: message/external-body; access-type="anon-ftp" site="bicycle.cs.washington.edu" directory="pub" name="birthday.snd" content-type: audio/basic content-transfer-encoding: base64 --qwertyuiopasdfghjklzxcvbnm / v5

43 ZUSAMMENFASSUNG: MIME-ERWEITERUNG In der ursprünglichen Form wurden im Internet nur 7-bit-ASCII-Zeichen für die Übertragung und damit auch für die s verwendet MIME erweitert den ursprünglichen Standard, um auch komplette Bytes (8 Bit) über 7-bit-Übertragungswege zu versenden Zusätzlicher MIME-Header Content-Transfer-Encoding beschreibt die Kodierung des Nachrichteninhalts Die Kodierungen Base64, Quoted-Printable und HTML erlauben die Übertragung von 8-bit Werten über 7-bit Übertragungswege Der Content-Type beschreibt Typ und Format der Nachricht 43 / v5

44 7. Anwendungsschicht Internet-Standard: RFC Avian Carrier 44 / v5

45 Übertragungs-Protokoll: RFC 1149 Network Working Group Request for Comments: 1149 D. Waitzman BBN STC 1 April 1990 Ein Standard zur Übertragung von IP Paketen mittels Vogel-Übertragungsträger (Avian Carriers) Status des Dokumentes Dieses Dokument beschreibt eine experimentelle Methode für den Transport von IP Paketen mittels eines Vogel- Übertragungsträgers. [ ] 45 / v5

46 Ergebnis der Implementierung Ping ping -i PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=255 time= ms 64 bytes from : icmp_seq=4 ttl=255 time= ms 64 bytes from : icmp_seq=2 ttl=255 time= ms 64 bytes from : icmp_seq=1 ttl=255 time= ms ping statistics packets transmitted, 4 packets received, 55% packet loss round-trip min/avg/max = / / ms vegard@gyversalen:~$ exit 1 H 27 MIN. 46 / v5

47 8. ANWENDUNGSSCHICHT MIME-Erweiterung 8.3 HTTP-PROTOKOLL 8.4 Web-Socket 47 / v5

48 PRINZIP DES HTTP-PROTOKOLLS CLIENT MIT WEB-BROWSER Request (URL-Link) WEB-SERVER Response (Web-Seite) Zustandsloses Request / Response-Protokoll Netzwerk 48 / v5

49 EIGENSCHAFTEN DES HTTP-PROTOKOLLS (Hypertext Transfer Protocol ) Protokoll der Anwendungsschicht Nutzt TCP der Transportschicht (verbindungsorientiert, zuverlässig) Typisches Client-Server-Protokoll: Aktivität geht immer vom Client aus, Server wartet passiv (am Port 80) auf eine Client-Anfragen Protokoll ist zustandslos (keine Sitzungsverwaltung), d. h. nach Abbau einer TCP- Verbindung behält der Server keine Informationen über den Client In Anlehnung an MIME-Formate Derzeit wird (meist) HTTP-Version 1.1 genutzt Version HTTP 2.0 in Arbeit, u. a. für schnelleren Web-Seitenaufruf und Unterstützung von Sitzungen 49 / v5

50 FUNKTIONEN DES HTTP-PROTOKOLLS Übertragung beliebiger Daten zwischen Client und Server (nicht nur HTML-Seiten) Aushandeln der zu übertragenden Datenformate Unterstützung des Caching METHODE GET HEAD POST BESCHREIBUNG Anforderung zum Lesen einer Webseite Anforderung zum Lesen (nur) des Headers einer Webseite Anhängen von Daten an eine Webseite 50 / v5

51 BEISPIEL GET-REQUEST DES CLIENTS Request-Methode Request-URI HTTP-Version GET /buch/kapitel-1/abschnitt-1-3.htm HTTP/1.1 Host: If-Modified-Since: Tuesday, 01-Jan-13 00:00:00 GMT... Accept: image/gif, image/x-bitmap, image/jpeg Accept-Language: de, en Accept-Charset: iso ,*,utf-8 Request- Header Leerzeile 51 / v5

52 RESPONSE DES SERVERS HTTP-Version Status-Code Status Text HTTP/ OK Content-length: 1500 Content-type: text/html Date: Wednesday, 2-Jan-13 12:12:12 GMT Server: Apache Weitere Parameter Leerzeile <HTML> <HEAD>... HTML-Objekt 52 / v5

53 RESPONSE DES SERVERS HTTP-Version Status-Code Status Text HTTP/ OK Content-length: 1500 Content-type: text/html Date: Wednesday, 2-Jan-13 12:12:12 GMT Server: Apache Weitere Parameter Leerzeile <HTML> <HEAD> Beliebiger Inhalt (kodiert in:????)... HTML-Objekt 53 / v5

54 STATUSCODE EINES HTTP-RESPONSE CODE BEDEUTUNG BEISPIELE 1xx Information 100 : Server stimmt zu, Client-Anforderung zu bearbeiten 2xx Erfolgreich 200 : Anforderung erfolgreich, 204 : kein Inhalt vorhanden 3xx Umleitung 301 : Seite umgezogen, 304 : Seite im Cache noch gültig 4xx Client-Fehler 403 : verbotene Seite, 404 : Seite nicht gefunden 5xx Server-Fehler 500 : interner Server-Fehler, 503 : später erneut versuchen 54 / v5

55 REQUEST-/ RESPONSE-ABLAUF BROWSER-CLIENT DNS-Adresse ( IP-Adresse ( ) DNS-SERVER WEB-SERVER TCP HTTP Aufbau einer Transport-Verbindung ( ) Operation 1 Response HTML-Objekt Request (GET /allgem/news.htm..) Request (GET /allgem/bilder/logo.gif..) Operation 2... Beenden der Transport-Verbindung 55 / v5

56 REQUEST-/ RESPONSE-ABLAUF Ist Speicherort ein DNS-Name, erfragt Client dessen IP-Adresse beim DNS-Server Anschließend baut Client mit IP-Adresse eine TCP-Verbindung zum Server auf Client bestimmt Servers-Port anhand der Zugriff-Methode (http = Port 80) Nachdem TCP-Verbindung aufgebaut wurde, startet das HTTP-Protokoll Client fordert mit GET die gewünschte HTML-Seite an Der Server antwortet mit der gewünschten HTML-Seite, die dann im Browser angezeigt wird Enthält der HTML-Code Verweise auf weitere Objekte des selben Servers (Bilder oder auszuführende Anwendungen), dann fordert der Client diese Objekte innerhalb der bestehenden TCP-Verbindung mit weiteren GET-Aufrufen an (HTTP/1.1) Wurden alle Objekte übertragen, beendet der Client die Transportverbindung Erkennt Browser im HTML-Code Verweise auf andere Web-Server, dann baut er auch zu diesen Servern TCP-Verbindungen auf und fordert die Objekte an 56 / v5

57 HEADER-FELD HOST GET /buch/kapitel-1/abschnitt-1-3.htm HTTP/1.1 Host: If-Modified-Since: Tuesday, 01-Jan-00 00:00:00 GMT... Accept: image/gif, image/x-bitmap, image/jpeg Accept-Language: de, en Accept-Charset: iso ,*,utf-8 Leerzeile Header-Feld Host ist seit Version HTTP/1.1 ein Pflicht-Parameter 57 / v5 Lücke+

58 DARSTELLBARE CODIERUNGEN GET /buch/kapitel-1/abschnitt-1-3.htm HTTP/1.1 Host: If-Modified-Since: Tuesday, 01-Jan-00 00:00:00 GMT... Accept: image/gif, image/x-bitmap, image/jpeg Accept-Language: de, en Accept-Charset: iso ,*,utf-8 Leerzeile 58 / v5

59 ALTERNATIVEN FÜR UMFANGREICHE DATEN PROBLEM: Übertragung von Audio- und Video-Daten, aber auch von Bildern verursachen im Internet ein sehr hohes Verkehrsaufkommen und führt so zu Verzögerungen Ursprungs-Server hat hohe Last zu bewältigen (Unicast-Verkehr) Internetleitungen zwischen Kontinenten sind überlastet Antwortzeiten steigen LÖSUNG: Dezentrale Verteilung (Spiegelung) der großen und häufig geladenen Dateien, nahe am Nutzer Caching: Eine einmal geladene Ressource verbleibt in einem Cache und wird von dort geladen (Aktualität: HEAD-Methode) Big Player : Zentraler Anbieter betreibt ein Servernetz (Content Delivery Networks - CDN) Ressourcen-Sharing: Peer-to-Peer-Netze (P2P) 59 / v5

60 ZUSAMMENFASSUNG: HTTP-PROTOKOLL Nutzt TCP-Dienst der Transportschicht (verbindungsorientiert, zuverlässig) Aktivität gehen immer vom Client aus, Server wartet passiv (am Port 80) Protokoll ist zustandslos (keine Sitzungsverwaltung), d. h. nach Abbau einer TCP- Verbindung behält der Server keine Informationen über den Client Für die Übertragung von HTML-Seiten entwickelt, aber auch für andere Daten nutzbar (in Anlehnung an MIME-Formate) Wichtige Methodenaufrufe sind GET, HEAD, POST Für effizient Übertragung großer (Multimedia)-Dateien werden Ressourcen dezentral verteilt (Spiegelung) 60 / v5

61 8. ANWENDUNGSSCHICHT MIME-Erweiterung 8.3 HTTP-Protokoll 8.4 WEB-SOCKET 61 / v5

62 WEITERE PROBLEME DES HTTP-PROTOKOLLS CLIENT MIT WEB-BROWSER Frage (Request) WEB-SERVER Antwort (Response) Zustandsloses Request / Response-Protokoll Netzwerk 62 / v5

63 WEITERE PROBLEME DES HTTP-PROTOKOLLS CLIENT: AKTIV, SERVER: PASSIV Übertragungen werden immer nur vom Client ausgelöst Server kann von sich aus keine Übertragung zum Client auslösen Damit sind keine Echtzeit -Anwendungen möglich, die vom Server ausgehen Z. B.: Spiele in HTML/http, Chat-Anwendungen, Live-Ticker, kollaborative Web- Seiten usw. BISHERIGE LÖSUNGEN: POLLING Client fragt regelmäßig beim Server nach neuen Informationen Großer Overhead (jeder http-request/response mehrere hundert Bytes) Keine Echtzeit möglich (Warten bis zum nächsten Polling) 63 / v5

64 POLLING-VERFAHREN POLLING Regelmäßiger Verbindungsaufbau und Server-Abfragen WEB-CLIENT request WEB-SERVER response EVENT Verzögerte Reaktion EVENT request response EVENT Verzögerte Reaktion EVENT request response 64 / v5

65 POLLING-VERFAHREN LONG POLLING Verbindung wird so lange offen gehalten, bis Server Daten sendet Dann neue Verbindung EVENT WEB-CLIENT request request response WEB-SERVER x EVENT EVENT (verloren) EVENT response EVENT request 65 / v5

66 WEB-SOCKET ÜBER HTTP-PROTOKOLL Web-Anwendung Client Web-Anwendung Server Browser http Web-Server Socket TCP Socket Web-Anwendung kommuniziert mittels HTTP (über Browser und Web-Server) Kein direkter Zugriff auf Socket-Verbindung der Transportschicht 66 / v5

67 RFC 6455 THE WEBSOCKET PROTOCOL Derzeit in der Standardisierung als RFC 6455 The WebSocket Protocol Aufwärts-kompatible Erweiterung des HTTP-Protokolls Aufbau einer ständige TCP-Verbindung zwischen Client und Server Dadurch bidirektionale Kommunikation (vom Server zum Client ohne vorheriges Polling) möglich Nutzt (weiterhin) HTTP-Protokoll über Port 80 Sehr geringer Overhead (2 Byte) Löst zusätzlich auch das Problem der HTTP-Sitzungen Einige Browser beherrschen bereits Web Sockets Erste Implementierungen für Web-Server vorhanden 67 / v5

68 VERBINDUNGSAUFBAU FÜR WEB SOCKET ws://server.example.de/drawservice CLIENT-REQUEST: GET /drawservice HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: [ ] Sec-WebSocket-Origin: Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: [ ] SERVER-RESPONSE: HTTP/ Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: [ ] Sec-WebSocket-Protocol: superchat URL auf Web-Socket Client wünscht Upgrade des http- Protokolls auf Web-Socket Welche WebSocket-Protokolle beherrscht Client Server akzeptiert Upgrade auf WebSocket-Protokoll Server beherrscht ebenfalls superchat-protokoll 68 / v5

69 WEB SOCKET WEB-CLIENT WEB-SERVER upgrade request WebSocket-Verbindung wurde aufgebaut EVENT upgrade DATA exchange WebSocket message EVENT EVENT WebSocket message EVENT CLIENT-EVENT WebSocket message EVENT 69 / v5

70 ZUSAMMENFASSUNG: WEB SOCKET Web Socket ist neue Erweiterung des HTTP-Protokolls Ermöglich bidirektionale Kommunikation auch vom Web-Server zum Browser Erlaubt Echtzeit-Anwendungen und Sitzungen im HTTP-Protokoll Noch in der Entwicklung, nicht überall verfügbar 70 / v5