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

Webserver, © Till Hänisch 2001

HTTP

HyperText Transfer Protocol-

Wie kommen die Seiten vom Server zum Browser ?


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,...)


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

GET /index.html HTTP/1.0Connection: Keep-AliveUser-Agent: Mozilla/4.51 [de]C-CCK-MCD DT (WinNT; I)Host: dbservAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*Accept-Encoding: gzipAccept-Language: deAccept-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)


ResponseHTTP/1.1 200 OKDate: Thu, 17 May 2001 09:12:50 GMTServer: Apache/1.3.12 (Unix) (SuSE/Linux)Last-Modified: Thu, 17 May 2001 09:05:17 GMTETag: "3aed8-40-3b03944d"Accept-Ranges: bytesContent-Length: 64Connection: closeContent-Type: text/htmlX-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

RequestUser

Resource 'holen'

ResponseInhaltanalysieren Request

Resource 'holen'

Response

Transaktion 1

Transaktion 2


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ösen134.60.246.2

Port Nummer extrahieren80 (default)

TCP Verbindung (Socket) herstellenzu 134.60.246.2, Port 80

Message an Server schickenGET /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

GET /index.html HTTP/1.0

URLSocket öffnen

Request schickenVerbindung akzeptieren

vom Socket lesenCR/LF CR/LF

request bearbeitenMethode GETResource /index.html

Header sendenHTTP/1.0 200 OK CR/LF

<HTML>.... Inhalt senden

Socket schließen

Inhalt darstellen


Images und co.

Browser Server

User

Inhaltanalysieren

...HTML-Seiten enthalten typ.mehrere Images,...deshalb mehrere Verbindungen


TCP Handshake

Client Server

SYN

SYN, ACK

ACK

Übertragung von DatenFIN

ACK

ACK

FIN

Client initiiert Verbindungdurch SYN Anfrage, Serverbestätigt Empfang durch ACK und SYN (er möchte auch),Client bestätigt durch ACK

Client möchte Verbindungschließen, signalisiert durchFIN. Server bestätigt diesdurch ACK und schließt auchVerbindung (FIN), Clientbestä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 msecbis 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 sofortgeschlossen 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.dehttp://134.60.246.2:80/index.htmlhttp://134.60.246.2:80/cgi-bin/../index.htmlhttp://www.uni-ulm.de/struktur_organisation/index.html#fakulhttp://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 !!!


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.dewww.Firma-B.dewww.Firma-C.dewww.Verein.org

...

Provider

Computer: server1.provider.de

Internet

/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.dehttp://www.Firma-B.de:81http://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.1Host: www.Firma-A.de


Proxy

Browser

Proxy

www.uni-ulm.de/index.htmlwww.t-online.de/index.htmlwww.uni-ulm.de/fak/Ing.htmlvts.uni-ulm.de/index.html

Client fordert Seiten vom Proxy an,dieser holt sie vom Web-Serverund behält lokale Kopie (Cache)

Browser

Bei jedem Zugriff prüft derProxy, ob er eine aktuelleKopie im Cache hat undliefert ggf. diese aus.Dadurch wird der Serverentlastet (er muß die Seitenur einmal ausliefern)

Falls die Verbindung zum Server (zum Internet) langsamist (z.B. ISDN,...) werden die(wiederholten) Zugriffe erheblichschneller !!

Steuerung durch HTTP Header

Documents

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