Webserver, © Till Hänisch 2001 HTTP HyperText Transfer Protocol - Wie kommen die Seiten vom Server zum Browser ?

Präsentation zum Thema: "Webserver, © Till Hänisch 2001 HTTP HyperText Transfer Protocol - Wie kommen die Seiten vom Server zum Browser ?"—  Präsentation transkript:

1 Webserver, © Till Hänisch 2001 HTTP HyperText Transfer Protocol - Wie kommen die Seiten vom Server zum Browser ?

2 Webserver, © Till Hänisch 2001 Prinzip Server ist passiv wartet auf eingehende Anfragen stateless Anfragen sind unabhängig voneinander Messages vom Client zum Server: Anforderungen (Request) vom Server zum Client: Antwort (Response) Methoden (GET, POST,...) Server liefert (Informations-) Resourcen an Clients aus beliebige Daten aus beliebigen Quellen (Dateisystem, Datenbanken, Sensoren,...)

3 Webserver, © Till Hänisch 2001 Servertypen

4 Webserver, © Till Hänisch 2001 Servertypen contd.

5 Webserver, © Till Hänisch 2001 Was haben alle Webserver gemeinsam ? HTTP Clients senden HTTP-Requests Server antwortet mit HTTP-Response TCP/IP Verbindung über TCP/IP untere Schichten verschieden (Ethernet, ISDB, GSM,...) Zugang zu (Informations-) Resourcen Webserver liefert Informationen statische/dynamische (Word-Datei/Webcam,....) Seiteneffekte HTTP-Anfragen können Daten auf dem Server verändern Daten oder Zustand

6 Webserver, © Till Hänisch 2001 Was ist unterschiedlich ? HTTP Version, Request-Typen Netzanbindung permanent/nach Bedarf Datenquellen Servertypen/Optimierung General purpose hohe Leistung (www.t-online.de) Flexibilität (Datenquellen,...) Spezialaufgaben (Webcam) klein HTTP nur teilweise implementiert

7 Webserver, © Till Hänisch 2001 HTTP Request GET /index.html HTTP/1.0 Connection: Keep-Alive User-Agent: Mozilla/4.51 [de]C-CCK-MCD DT (WinNT; I) Host: dbserv Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: de Accept-Charset: iso-8859-1,*,utf-8 Unterschiedliche Request Typen, u.A.  GET (liefert Resource aus)  POST (Resource an Webserver, i.A. Parameter)  TRACE (Route verfolgen)  DELETE (Resource auf dem Server löschen)  PUT (Resource an Server schicken)

8 Webserver, © Till Hänisch 2001 Response HTTP/1.1 200 OK Date: Thu, 17 May 2001 09:12:50 GMT Server: Apache/1.3.12 (Unix) (SuSE/Linux) Last-Modified: Thu, 17 May 2001 09:05:17 GMT ETag: "3aed8-40-3b03944d" Accept-Ranges: bytes Content-Length: 64 Connection: close Content-Type: text/html X-Pad: avoid browser bug.... Status codes, z.B.  200 OK  204 No Content  400 Bad Request  404 Not found  500 Internal server error

9 Webserver, © Till Hänisch 2001 Was tut der Server ? auf eingehende (TCP) Anfrage warten Server Socket HTTP Anfrage analysieren HTTP Parser Anfrage bearbeiten Zugriff auf (Dateisystem) Daten Anfrage an anderes System weiterleiten Mit HTTP Response antworten HTTP Header Daten an Client schicken

10 Webserver, © Till Hänisch 2001 Ablauf BrowserServer Request User Resource 'holen' Response Inhalt analysieren Request Resource 'holen' Response Transaktion 1 Transaktion 2

11 Webserver, © Till Hänisch 2001 Ablauf GET Methode URL: http://www.uni-ulm.de/index.html Ablauf im Client: Host aus URL extrahieren www.uni-ulm.de IP Adresse durch DNS Abfrage auflösen 134.60.246.2 Port Nummer extrahieren 80 (default) TCP Verbindung (Socket) herstellen zu 134.60.246.2, Port 80 Message an Server schicken GET /index.html HTTP/1.0 Vom Socket lesen, bis Verbindung vom Server geschlossen wird Header (Statuscode,...) auswerten, ggf. Inhalt extrahieren und darstellen

12 Webserver, © Till Hänisch 2001 Ablauf contd. GET Methode URL: http://www.uni-ulm.de/index.html Ablauf im Server: Ein Prozess auf 134.60.246.2 wartet auf eine Verbindung an Port 80 Wenn Verbindungsaufbau erfolgt, dann Vom Socket bis zur ersten Leerzeile lesen Request analysieren (Method und Resource extrahieren) Resource holen (z.B. aus Dateisystem) Request Header (Status) auf dem Socket ausgeben Inhalt der Resource auf den Socket schreiben Socket schließen (Verbindung trennen)

13 Webserver, © Till Hänisch 2001 Ablauf im Detail BrowserServer GET /index.html HTTP/1.0 URL Socket öffnen Request schicken Verbindung akzeptieren vom Socket lesen CR/LF request bearbeiten Methode GET Resource /index.html Header senden HTTP/1.0 200 OK CR/LF.... Inhalt senden Socket schließen Inhalt darstellen

14 Webserver, © Till Hänisch 2001 Images und co. BrowserServer User Inhalt analysieren... HTML-Seiten enthalten typ. mehrere Images,... deshalb mehrere Verbindungen

15 Webserver, © Till Hänisch 2001 TCP Handshake ClientServer SYN SYN, ACK ACK Übertragung von Daten FIN ACK FIN Client initiiert Verbindung durch SYN Anfrage, Server bestätigt Empfang durch ACK und SYN (er möchte auch), Client bestätigt durch ACK Client möchte Verbindung schließen, signalisiert durch FIN. Server bestätigt dies durch ACK und schließt auch Verbindung (FIN), Client bestätigt dies durch ACK

16 Webserver, © Till Hänisch 2001 Problem Beim Aufruf einer URL durch z.B. GET müssen übertragen werden: 3 Pakete (TCP Verbindungsaufbau) 1 Paket (HTTP Request) 1 Paket (HTTP Response) 1 Paket (Bestätigung) 4 Pakete (TCP Verbindungsende) insgesamt also 10 Pakete Bei Latenz von 70 ms (z.B. TDSL) vergehen 700 msec bis Daten übertragen sind (Für jede Request !!!!) Seite mit 10 Bildern braucht also 7000 ms !!! (Natürlich nicht, die einzelnen Dateien werden parallel geholt) Client und Server warten also im wesentlichen !!! Abhilfe: HTTP 1.1: Verbindung muß nicht sofort geschlossen werden, kann wiederverwendet werden

17 Webserver, © Till Hänisch 2001 Resource 'holen' ? Wie findet der Webserver eine Resource ? http://lomi.e-technik.uni-ulm.de/lomiweb/index.html Pfad wird ausgewertet hier: /lomiweb Falls Abbildung (Alias) definiert, wird dieser transformiert (z.B. lomiweb -> web) Server geht von der DocumentRoot aus, z.B. c:\InetPub (ist im Webserver konfiguriert) und hängt den Pfad an, sucht also in c:\InetPub\web nach der Datei, hier index.html Webserver öffnet die Datei c:\InetPub\web\index.html wenn diese existiert, wird sie ausgeliefert

18 Webserver, © Till Hänisch 2001 Resource holen contd. Ist das Verzeichnis für ausführbare Dateien konfiguriert (CGI), wird die Datei nicht gelesen, sondern ausgeführt und das Ergebnis an den Client geschickt z.B. http://www.uni-ulm.de/cgi-bin/printenv Verzeichnis wird extrahiert (/cgi-bin) Server prüft (in seiner Konfiguration), ob hier Dateien ausgeführt werden sollen (CGI: Common Gateway Interface), falls ja wird das Programm printenv (in einem eigenen Prozeß) ausgeführt, (Parameter werden im Environment übergeben) Ergebnis an den Client übertragen

19 Webserver, © Till Hänisch 2001 Uniform Resource Locator Verweis auf eine Resource, enthält Protokoll (z.B. http://, ftp://,...) Host (DNS-Name oder IP-Adresse) Port (:80, :8080, Default ist 80) Name (/index.html, /cgi-bin/printenv,...) Beispiele http://www.uni-ulm.de http://134.60.246.2:80/index.html http://134.60.246.2:80/cgi-bin/../index.html http://www.uni-ulm.de/struktur_organisation/index.html#fakul http://vts.uni-ulm.de/query/longview.meta.asp?document_id=630

20 Webserver, © Till Hänisch 2001 Parameter Wie erhält z.B. Suchprogramm das zu suchende Wort URL der Form: http://server/pfad/script?Parameter=Wert z.B....suche?Begriff=Internet QueryString QUERY_STRING="Begriff=Internet" mehrere mit ?p1w1&p2=w2... Eingabe durch Benutzer ? HTML Forms, INPUT Tags

21 Webserver, © Till Hänisch 2001 Parameter contd. Problem: viele/lange Parameter Länge von URL ist begrenzt Platz im Environment ist begrenzt (OS spezifisch) Lösung: POST GET /Suche?Begriff=Internet HTTP/1.0 Connection: Keep-Alive User-Agent: Mozilla/4.51 [de]C-CCK-MCD DT (WinNT; I) Host: localhost Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: de Accept-Charset: iso-8859-1,*,utf-8 POST /Suche HTTP/1.0 Connection: Keep-Alive Content-type: application/x-www-form-urlencoded Content-length: 16 Begriff=Internet

22 Webserver, © Till Hänisch 2001 Methoden Auswahl im Tag xxx=GET xxx=POST GET maximale Länge von Parametern beschränkt Probleme bei Sonderzeichen (blank,...) URL encoding können als Bookmark gespeichert werden besser nicht für Bestellungen,... POST unbeschränkte Länge der Parameter auch ganze Dateien,...

23 Webserver, © Till Hänisch 2001 Typische Anwendung Suchmaschine Telefonbuch Telefonbuch Name:

24 Webserver, © Till Hänisch 2001 Ergebnis Telefonbuch Liste Suchergebnis Müller, Hans Müller, Hugo Müller, Karin

25 Webserver, © Till Hänisch 2001 HTTP 1.0 Basic Authentication Nicht jeder Client soll jede Resource sehen können Für jede Resourcen können Zugriffsrechte festgelegt werden basic authentication einfaches username/password Schema unverschlüsselt, Kennwörter werden im Klartext übertragen !!! Ablauf: Client fordert Resource an Server antwortet mit Statuscode 401 unauthorized Client fragt Benutzer nach Benutzername/Kennwort und fordert die Resource nochmal an, mit Header Authorization: : Server prüft wenn korrekt, wird Resource ausgeliefert Internet Explorer kann auch automatisch (OS) Auth. senden Sicherheitsproblem !!!

26 Webserver, © Till Hänisch 2001 Virtual hosts jeder will seine eigene Website -www.ich-bin-der-groesste.de - aber keinen eigenen Server betreiben: mehrere Webserver auf einem Rechner z.B. Webspace Provider der oder die Webserver soll - je nach URL - die entsprechenden Daten liefern www.Firma-A.de www.Firma-B.de www.Firma-C.de www.Verein.org... Provider Computer: server1.provider.de Internet /Firma-A /Firma-B /Firma-C /Verein

27 Webserver, © Till Hänisch 2001 Lösung verschiedene Ports jeder Webserver hat eigenen Port, z.B. 80, 81, 82, 83, 84,... Nur einer kann den (Default- ) Port 80 haben, alle anderen müssen explizit den Port angeben: http://www.Firma-A.de http://www.Firma-B.de:81 http://www.Firma-C.de:82... verschiedene IP-Adressen Jeder Kunde/Domain hat eigene IP-Adresse Server hat mehrere IP-Adressen (auf einem Interface) Zahl von Adressen je Rechner begrenzt Verschwendung von Adressen (IP V4 Adressen sind knapp) Non-IP basierte virtual Hosts (HTTP 1.1) Alle Domains haben gleiche Adresse und gleichen Port Webserver holt aus HTTP-Protokoll die Domain GET /index.html HTTP/1.1 Host: www.Firma-A.de

28 Webserver, © Till Hänisch 2001 Server Basics Verbindungsorientiert (TCP) Iterative Server Anfragen werden nacheinander beabeitet einfach (embedded devices) Wenn neue Anfrage kommt, während andere bearbeitet wird --> Fehler Concurrent Server gleichzeitig können mehrere Anfragen bearbeitet werden komplex(er) verschiedene Techniken multi process (neuer Prozeß für jede Anfrage) multi threaded (neuer Thread für jede Anfrage) thread/process pool (dispatcher/worker,...) while (true) { // Auf eingehende Verbindung warten Socket sockClient = sockListen.accept(); System.out.println("Connection created"); // Neue Verbindung, Thread starten ChatConnection C = new ChatConnection(sockClient); C.start(); }

29 Webserver, © Till Hänisch 2001 Proxy Browser Proxy www.uni-ulm.de/index.html www.t-online.de/index.html www.uni-ulm.de/fak/Ing.html vts.uni-ulm.de/index.html Client fordert Seiten vom Proxy an, dieser holt sie vom Web-Server und behält lokale Kopie (Cache) Browser Bei jedem Zugriff prüft der Proxy, ob er eine aktuelle Kopie im Cache hat und liefert ggf. diese aus. Dadurch wird der Server entlastet (er muß die Seite nur einmal ausliefern) Falls die Verbindung zum Server (zum Internet) langsam ist (z.B. ISDN,...) werden die (wiederholten) Zugriffe erheblich schneller !! Steuerung durch HTTP Header