1 / 23

HTTP

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)

leda
Download Presentation

HTTP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HTTP HyperText Transfer Protocol - Wie kommen die Seiten vom Server zum Browser ?

  2. 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. Servertypen

  4. Servertypen contd.

  5. 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

  6. 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. 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. 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

  9. 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. Ablauf Browser Server Request User Resource 'holen' Transaktion 1 Response Inhaltanalysieren Transaktion 2 Request Resource 'holen' Response

  11. Ablauf • GET Methode • URL:http://www.uni-ulm.de/index.html • Ablauf im Client: • Host aus URL extrahierenwww.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

  12. 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. Ablauf im Detail Browser Server URL Socket öffnenRequest 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

  14. Images und co. Browser Server User Inhaltanalysieren ... HTML-Seiten enthalten typ. mehrere Images,... deshalb mehrere Verbindungen

  15. TCP Handshake Client Server Client initiiert Verbindungdurch 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 durchFIN. Server bestätigt dies durch ACK und schließt auchVerbindung (FIN), Client bestätigt dies durch ACK ACK FIN ACK

  16. 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. 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. 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. 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

  20. 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 !!!

  21. 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.de www.Firma-C.de www.Verein.org ... Provider /Firma-A /Firma-B /Firma-C /Verein Internet Computer: server1.provider.de

  22. 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 DomainGET /index.html HTTP/1.1Host: www.Firma-A.de

  23. 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 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) Client fordert Seiten vom Proxy an, dieser holt sie vom Web-Server und behält lokale Kopie (Cache) Proxy Steuerung durch HTTP Header Falls die Verbindung zum Server (zum Internet) langsam ist (z.B. ISDN,...) werden die (wiederholten) Zugriffe erheblich schneller !!

More Related