HTTP HyperText Transfer Protocol - Wie kommen die Seiten vom Server zum Browser ?
Prinzip Server ist passiv stateless Messages 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,...)
Servertypen
Servertypen contd.
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
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
HTTP Request Unterschiedliche Request Typen, u.A. 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)
Response Status codes, z.B. 200 OK 204 No Content 400 Bad Request 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
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
Ablauf Browser Server Transaktion 1 Transaktion 2 Request User Resource 'holen' Transaktion 1 Response Inhalt analysieren Transaktion 2 Request Resource 'holen' Response
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
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)
Ablauf im Detail Browser Server URL Socket öffnen Request schicken Verbindung akzeptieren GET /index.html HTTP/1.0 vom Socket lesen CR/LF CR/LF request bearbeiten Methode GET Resource /index.html HTTP/1.0 200 OK CR/LF Header senden Inhalt senden <HTML>.... Socket schließen Inhalt darstellen
... Images und co. Browser Server HTML-Seiten enthalten typ. User Inhalt analysieren ... HTML-Seiten enthalten typ. mehrere Images,... deshalb mehrere Verbindungen
TCP Handshake Client Server Übertragung von Daten Client initiiert Verbindung durch SYN Anfrage, Server bestätigt Empfang durch ACK und SYN (er möchte auch), Client bestätigt durch ACK SYN SYN, ACK ACK Übertragung von Daten FIN 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 ACK FIN 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
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
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
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
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: <user>:<passwd> Server prüft <user><password> wenn korrekt, wird Resource ausgeliefert Internet Explorer kann auch automatisch (OS) Auth. senden Sicherheitsproblem !!!
www.Firma-A.de www.Firma-B.de 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 /Firma-A /Firma-B /Firma-C /Verein Internet Computer: server1.provider.de
Lösung verschiedene Ports verschiedene IP-Adressen 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
Proxy Proxy Browser Browser Client fordert Seiten vom Proxy an, 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) Steuerung durch HTTP Header Falls die Verbindung zum Server (zum Internet) langsam ist (z.B. ISDN,...) werden die (wiederholten) Zugriffe erheblich schneller !! 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)