Grundlagen der Rechnernetze. Applikationsschicht

Transkript

1 Grundlagen der Rechnernetze Applikationsschicht

2 Übersicht Web und HTTP File Transfer: FTP Electronic Mail Domain Name System (DNS) Grundlagen der Rechnernetze Applikationsschicht 2

3 HTTP Übersicht Hyper Text Transfer Protocol (HTTP) Application Layer Protocol auf Basis von TCP HTTP definiert Formate und Austausch von Nachrichten zum aufrufen von Web Seiten (Request Response) Client Server Paradigma (Web Server und Web Client bzw. Web Browser) (Server Port meist 80, manchmal 8080) Web Server sind zustandslos (engl. stateless) Bzw. HTTP ist ein zustandsloses Protokoll HTTP definiert in RFC 1945 und RFC 2616 (definiert das Protokoll aber nicht die Darstellung von Webseiten auf dem Browser) Terminologie Web Seite beinhaltet Objekte z.b. HTML File, JPEG Image, Java Applet, Video Clip etc. Typischerweise ein Basis HTML File und mehrere darin referenzierte Objekte Objekte sind über Uniform Resource Locator (URL) adressierbar Besteht aus Host Name des Web Servers und Objekt Pfadname auf dem Server, z.b.: Host Name: Pfadname: /somedepartment/picture.gif Beispiel Webserver: Apache HTTP Server Nginx Microsoft Internet Information Services Google Web Server always on fixed IP address port 80 or 8080 Beispiel Webclients: Mosaic, Netscape, Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome, Microsoft Edge, Vivaldi Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 3

4 HTTP Beispiel 1. HTTP Client öffnet TCP Verbindung mit HTTP Server auf Port HTTP Client sendet Request /somedepartment/index.htm an HTTP Server 3. HTTP Server ermittelt Objekt /somedepartment/index.htm und sendet Response über die TCP Verbindung 4. HTTP Server schließt TCP Verbindung 5. HTTP Client empfängt Response und schließt die TCP Verbindung ebenfalls. HTTP Client findet in dem Objekt ein HTML File mit 10 referenzierten JPEG Objekten 6. Die ersten vier Schritte werden für jedes JPEG Objekt wiederholt Ist das immer so? H TCP Verbindung herstellen Request /somedepartment/index.htm Response HTML File TCP Verbindung abbauen S Dieselben Schritte für jedes JPEG Objekt Grundlagen der Rechnernetze Applikationsschicht 4

5 Persistente und Nicht Persistente Verbindung HTTP erlaubt zwei Verbindungsarten zwischen Client und Server: Persistent: eine TCP Verbindung für alle Request Response Paare (typischerweise genutzt); Server schließt TCP Verbindung, wenn vom Client bis zu einem Timeout keine weiteren Anfragen mehr kamen Nicht Persistent: separate TCP Verbindung für jedes Request Response Paar Nicht Persistente Verbindungen bedeuten mehr Overhead 2*RTT Verzögerung für TCP Verbindungsherstellung Ressourcen auf Client und Server für TCP Variablen und Puffer (insbesondere auf Server der gleichzeitig viele Clients bedienen muss problematisch) Aber: Nicht Persistente TCP Verbindungen ermöglichen Parallelität Moderne Browser erlauben eine Festlegung der maximal erlaubten parallelen TCP Verbindungen. Jede TCP Verbindung behandelt einen Request/Response (Default in der Regel 5 bis 10 parallele TCP Verbindungen) Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 5

6 HTTP Request Nachricht GET /somedir/page.html HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept-language: fr Allgemeines Format Beispiel Nachrichten sind in ASCII (Format definiert über sp, cr und lf) Request Line: Methoden: GET, POST, HEAD, PUT und DELETE Im Beispiel: Browser bittet um Objekt somedir/page.html. Brower verwendet HTTP Version 1.1 Header Lines: Host Im Beispiel: Request geht an Wieso nochmal? TCP Verbindung ist doch schon hergestellt?!? siehe Web Proxy Cache Header Lines: Connection: close Client will keine Persistente Verbindung Header Lines: User agent: Mozilla/4.0 Browser Typ Header Lines: Accept langugage: fr Beispiel eines Content Negotiation Headers (hier: falls vorhanden französische Variante des angefragten Contents) Es gibt noch viele weitere Header Lines. Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 6

7 HTTP Request Nachricht GET /somedir/page.html HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept-language: fr Allgemeines Format Beispiel Method GET: vorhin schon besprochen Method POST Auch Anfrage einer Web Seite, aber Antwort hängt von übergebenen Parametern ab Parameter stehen in Entity Body Beispiel: User hat ein Form ausgefüllt (z.b. Suchwort für Suchmaschine) Aber: Parameter können auch mittels GET in der URL übergeben werden (Beispiel Form mit zwei Eingabefeldern; ausfüllen mit monkeys und bananas; die URL ist dann Method HEAD: wie GET, nur Server lässt in seiner Antwort das angefragte Objekt weg (z.b. sinnvoll für Debugging) Method PUT: sinnvoll für Web Publishing Tools; User kann damit Objekt auf gegebenen Objekt Pfad hoch laden Method DELETE: offensichtlich sinnvoll, wenn es ein PUT gibt Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 7

8 HTTP Response Nachricht HTTP/ OK Connection: close Date: Thu, 07 Jul :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Sun, 6 May :23:24 GMT Content-Length: 6821 Content-Type: text/html (data data data data data...) Allgemeines Format Beispiel Im Unterschied zu Request steht bei Response im Header ein status Code; Übliche Status Codes 200 OK: Request erfolgreich 301 Moved Permanently: Objekt wurde verschoben; neue URL steht in Header Line Location: 400 Bad Request: Request wurde von Server nicht verstanden 404 Not Found: angefragtes Objekt existiert auf dem Server nicht 505 HTTP Version Not Supported: Angefragte HTTP Protokoll Version wird vom Server nicht unterstützt Header Lines des Beispiels offensichtlich Wozu eigentlich Last Modified? Last Modified ist für Caching (auf Client und auch Proxy) sinnvoll Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 8

9 Client Server Interaction: Cookies HTTP Server ist Stateless Wie kann sich z.b. Amazon Server meinen aktuellen Einkaufswagen (sogar über viele Tage hinweg) merken? Lösung: Cookies (siehe Beispiel) 1. Cookie Header Line im HTTP Response (Set cookie: <eindeutige Nummer>) 2. Cookie Header Line im HTTP Request (nachdem Cookie Nummer erlernt wurde) 3. Cookie File auf dem Client mit Einträgen (host Name: Identifikationsnummer) 4. Backend Datenbank auf Server Seite Damit lässt sich jede HTTP Aktivität des Clients mit der Cookie Nummer auf dem Web Server loggen. Wenn User sich auch noch registrieren muss, dann lässt sich jede HTTP Aktivität des Users auf dem Web Server loggen. Cookies vereinfachen vieles (z.b. Einkaufswagen) Aber: nicht unumstritten bzgl. Privacy Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 9

10 Motivation für Web Caching Beispiel Annahmen Mittlere Objekt Größe pro HTTP Reply: 1 Mbit Mittlere Anzahl an HTTP Requests: 15 Request/sec (HTTP Request Größe vernachlässigbar klein) Damit ergibt sich La = ankommende Bits pro Sekunde: La = 15/1 (req/sec / 1Mbit) Als Verkehrsintensität (d.h. ankommende Bits pro Sekunde La dividiert durch Übertragungsrate La/R(LAN) = 0.15 La/R(AccessLink) = 1.0 Queueing Theory: Mehrere 10 msec Delay im LAN Delay am Access Link wächst über jede Grenze Damit ist die mittlere Antwortzeit für einen HTTP Request in Bereich von Minuten oder gar mehr! Wie Lösen? Kapazität des Access Linkt erhöhen (z.b. auch 100 Mbps) Kostenfaktor! andere Lösung? R(access link) = 15 Mbps R(LAN) = 100 Mbps Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,

11 Web Caching Web Cache bzw. Proxy Server erfüllt HTTP Anfragen für Web Server. Browser des Users so konfiguriert, dass alle HTTP Anfragen erst an den Proxy laufen. Am Beispiel für Anfrage von 1. Browser stellt TCP Verbindung mit Proxy her uns sendet Request für das Objekt dort hin 2. Proxy prüft ob Objekt lokal gespeichert. Falls ja, antworte mit HTTP Response mit dem Objekt. 3. Falls nein, stelle TCP Verbindung mit Original Web Server ( her. Sende HTTP Request von Proxy an Web Server. Web Server antwortet mit Objekt auf Anfrage des Proxy. 4. Mit empfang des Objektes am Proxy, wird dieses an den Web Client per HTTP Response geantwortet und das Objekt für zukünftige Anfragen im Proxy lokal gespeichert. Damit können zukünftige Anfragen nach ohne Internet Verzögerung beantwortet werden. Außerdem: Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,

12 Web Caching Beispiel Annahmen Mittlere Objekt Größe pro HTTP Reply: 1 Mbit Mittlere Anzahl an HTTP Requests: 15 Request/sec Typische Cache Hit Raten = im Bereich 0,2 bis 0,7; Annahme hier 0,4 Annahme 2 Sekunden Internetverzögerung Damit ergibt sich La = ankommende Bits pro Sekunde: La = 15/1 (req/sec / 1Mbit) Als Verkehrsintensität (d.h. ankommende Bits pro Sekunde La dividiert durch Übertragungsrate La/R(LAN) = 0.15 La/R(AccessLink) = 1.0 * 0,6 (d.h. nur die Cache Misses) Queueing Theory: Mehrere 10 msec delay im LAN und Mehrere 10 msec am Access Link Mit Damit ist die mittlere Antwortzeit für einen HTTP Request: 0,4 * 0,01 sek + 0,6 * (2,0 + 0,01 sek) ~ 1,2 sek anstatt viele Minuten! R(access link) = 15 Mbps R(LAN) = 100 Mbps Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,

13 Web Caching: Conditional GET Problem: Objekt im Cache ist nicht mehr aktuell, wenn das Objekt auf dem Web Server verändert wurde. Lösung: condidional GET Request Nachricht verwendet GET Methode und beinhaltet Header Line If Modified Since: Beispiel: ( Zunächst sendet ein Proxy auf Anfrage eines Clients an den Web Server GET /fruit/kiwi.gif HTTP/1.1 Host: Darauf antwortet der Web Server an den Proxy HTTP/ OK Date: Thu, 7 Jul :39:29 Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 4 Jul :23:24 Content-Type: image/gif (data data data data data...) Grundlagen der Rechnernetze Applikationsschicht 13

14 Web Caching: Conditional GET Proxy leitet das Objet an Web Client und speichert das Objekt lokal inklusive der Last Modified Information Eine Woche später fragt derselbe oder irgend ein anderer Client das Objekt im Proxy nach Proxy macht dann einen Up to date Check und sendet hierzu an den Web Server GET /fruit/kiwi.gif HTTP/1.1 Host: exotiquecuisine.com If-modified-since: Wed, 4 Jul :23:24 Der Web Server antwortet immer mit einem Response, allerdings, wenn das Objekt nicht geändert wurde ist die Antwort einfach: HTTP/ Not Modified Date: Thu, 14 Jul :39:29 Server: Apache/1.3.0 (Unix) Leerer Body Grundlagen der Rechnernetze Applikationsschicht 14

15 Übersicht Web und HTTP File Transfer: FTP Electronic Mail Domain Name System (DNS) Grundlagen der Rechnernetze Applikationsschicht 15

16 File Transfer: FTP File Transfer Protocol (FTP): RFC 959: Bewegen von Dateien zwischen lokalem Dateisystem (FTP Client) und Remote Dateisystem (FTP Server) User authentifiziert sich per Username und Passwort Anschließend Dateiaustausch Zwei TCP Verbindungen (Control Connection und Data Connection) Port 21: Control Nachrichten (persistente TCP Verbindung) Port 20: Datennachrichten (nicht persistent, d.h. für jede Datei eine separate Verbindung) Control Nachrichten von FTP sind out of band (d.h. Trennung zwischen Control und Daten Kanal) Control Nachrichten z.b. von HTTP sind hingegen in band (d.h. ein Kanal für Control und Daten) Anders als HTTP speichert FTP während einer User Session Zustand (z.b. Position im Dateibaum) Damit FTP stärker limitiert bzgl. Gesamtanzahl erlaubter aktueller bedienter User Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 16

17 FTP: übliche Commands und Replies Commands und Replies über Control Kanal in lesbarer 7 Bit ASCII Codierung CRLF nach jedem Command Jeder Command besteht aus vier Buchstaben und Argument. Beispiele: USER username: zum senden der User Identifikation PASS password: zum Senden des User Passwortes LIST: Erfrage Liste aller Dateien/Unterverzeichnisse in aktuellem besuchten Verzeichnis RETR filename: Herunterladen der Datei STOR filename: Hochladen der Datei In der Regel erzeugt ein Command vom Client genau einen Reply vom Server. Reply besteht aus Drei Ziffern und optionalem erklärendem Text. Beispiele: 331 Username OK, password required 125 Data connection already open; transfer starting 425 Can t open data connection 452 Error writing file Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 17

18 Übersicht Web und HTTP File Transfer: FTP Electronic Mail Domain Name System (DNS) Grundlagen der Rechnernetze Applikationsschicht 18

19 eine High Level Sicht Drei wesentliche Komponenten User Agent Z.B. mit GUI: Outlook, Apple Mail, Thunderbird, Z.B. textbasiert: mail, pine, elm Mail Server Mailbox für jeden User Outgoing Message Queue Simple Mail Transfer Protocol (SMTP) Auf Basis von TCP Zur Kommunikation zwischen Mail Servern Client Seite zum Empfang von Mails Server Seite zum Senden von Mails Mail Server implementiert SMTP und agiert damit als Client und als Server Kommunikation zwischen User Agent und Mail Server Authentifizierung mittels Username und Passwort Zugriff auf Mailbox (siehe POP3, IMAP und Web) Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,

20 Simple Mail Transfer Protocol (SMTP) SMTP Fakten Definition in RFC 2821 Mail Body (d.h. der Inhalt) aus historischen Gründen auf 7 Bit ASCII eingeschränkt Aufwand für andere Zeichensätze und Binär Daten Normalerweise werden keine Intermediate Mail Server verwendet TCP Verbindungsherstellung von SMTP Client mit SMTP Server (z.b. Port 25) Nach TCP Verbindung Handshaking Phase: z.b. mitteilen von Sender und Ziel Mailadresse und Mailversand Prozess wird über dieselbe TCP Verbindung für weitere Nachrichten wiederholt (d.h. persistende TCP Verbindung) Was, wenn ein Mailserver nicht erreichbar? wiederholte TCP Verbindungsherstellungen und Zustellungsversuche Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,

21 Simple Mail Transfer Protocol (SMTP) Beispiel Transcript zu Nachrichtenaustausch nach TPC Verbindungsherstellung zwischen SMTP Client und Server: Client: crepes.fr Server: hamburger.edu Mail Text: Do you like ketchup? How about pickles? 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 Reply Code (und optionaler Text) auf jeden eingehenden Befehl. Jede Zeile endet mit CRLF. Textende durch CRLF.CRLF dargestellt. Danach kann erneut MAIL FROM: crepes.fr für weitere Mail stehen. Grundlagen der Rechnernetze Applikationsschicht Networking: A Top Down Approach,