HTTP HyperText Transfer Protocol Wie kommen die Seiten vom Server zum Browser ? Webserver, © Till Hänisch 2001 Prinzip Server ist passiv stateless Anfragen sind unabhängig voneinander Messages wartet auf eingehende Anfragen 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,...) Webserver, © Till Hänisch 2001 Servertypen Webserver, © Till Hänisch 2001 Servertypen contd. 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, ISDN, 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 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 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) 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 <html> .... Status codes, z.B. 200 OK 204 No Content 400 Bad Request 404 Not found 500 Internal server error Webserver, © Till Hänisch 2001 Was tut der Server ? auf eingehende (TCP) Anfrage warten HTTP Anfrage analysieren HTTP Parser Anfrage bearbeiten Server Socket Zugriff auf (Dateisystem) Daten Anfrage an anderes System weiterleiten Mit HTTP Response antworten HTTP Header Daten an Client schicken Webserver, © Till Hänisch 2001 Ablauf Browser Server User Resource 'holen' Inhalt analysieren Transaktion 1 Transaktion 2 Response Resource 'holen' Response 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 Webserver, © Till Hänisch 2001 Ablauf contd. GET Methode URL: Ablauf im Server: http://www.uni-ulm.de/index.html 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) Webserver, © Till Hänisch 2001 Ablauf im Detail Browser Server URL Socket öffnen Verbindung akzeptieren Request schicken vom Socket lesen request bearbeiten Methode GET Resource /index.html Header senden Inhalt senden Socket schließen Inhalt darstellen Webserver, © Till Hänisch 2001 Images und co. Browser Server User Inhalt analysieren HTML-Seiten enthalten typ. mehrere Images,... deshalb mehrere Verbindungen Webserver, © Till Hänisch 2001 ... TCP Handshake Client Server SYN SYN, ACK ACK Client initiiert Verbindung durch SYN Anfrage, Server bestätigt Empfang durch ACK und SYN (er möchte auch), Client bestätigt durch ACK Übertragung von Daten FIN ACK FIN ACK Webserver, © Till Hänisch 2001 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 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 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 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 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 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 Ablauf: einfaches username/password Schema unverschlüsselt, Kennwörter werden im Klartext übertragen !!! 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: <user>:<passwd> Server prüft <user><password> wenn korrekt, wird Resource ausgeliefert Internet Explorer kann auch automatisch (OS) Auth. senden Sicherheitsproblem !!! 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 Provider Internet www.Firma-A.de www.Firma-B.de www.Firma-C.de www.Verein.org ... Computer: server1.provider.de Webserver, © Till Hänisch 2001 /Firma-A /Firma-B /Firma-C /Verein 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 Webserver, © Till Hänisch 2001 Proxy Steuerung durch HTTP Header Browser Proxy 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) 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) Webserver, © Till Hänisch 2001 Falls die Verbindung zum Server (zum Internet) langsam ist (z.B. ISDN,...) werden die (wiederholten) Zugriffe erheblich schneller !!