HTTP. Hypertext Transfer Protocol. 4. Februar 2004

Transkript

1 HTTP Hypertext Transfer Protocol Bernhard Möller René Tünnermann 4. Februar Einleitung Das Hypertext Transfer Protokoll wird bereits seit 1990 für die Übermittlung von Daten im Web benutzt. Es befindet sich im Applikationslayer des OSI-Schichtenmodells und benutzt aus dem Transportlayer das TCP, um eine Verbindung zu einem anderen Rechner aufzubauen. Der große Vorteil des HTTP liegt darin, daß der User sich einfach durch Klicken auf Hyperlinks durch die Inhalte navigiert, ohne wissen zu müssen, wo sich die Inhalte befinden und welche Verzeichnisstruktur ihnen zugrundeliegt. Ein weiteres Protokoll mit diesen angenehmen Eigenschaften neben HTTP war Gopher, welches beinahe zeitgleich zum HTTP fertiggestellt wurde. Gopher ist aber mehr und mehr durch das Hypertext Transfer Protokoll verdrängt worden, obwohl es neben Text im ASCII-Format ebenfalls die Darstellung von Bildern im Gif-Format zuläßt. Aber auch andere Protokolle wie FTP, NNTP, u.s.w. sind rückläufig, wie die folgende Tabelle zeigt. Month HTTP NNTP FTP Telnet SMTP DNS #Packets x Jan Apr Jul Oct Jan Apr Hier sind die prozentualen Anteile versendeter Pakete nach verwendeten Protokollen des NFSnet-Backbones gelistet. Der Rückgang des Totaldurchsatzes erklärt sich durch die Inbetriebnahme weiterer Back-Bones. 1.1 Verbindungsablauf In der Regel baut ein Web-Client (Browser) zu einem Webserver eine Verbindung auf, indem er (meistens) einen GET-Request abschickt. Hierdurch wird eine TCP- Verbindung über über Port 80 zum Server aufgebaut, der mit einem HTTP-Response antwortet. Die jeweiligen TCP-Verbindungen werden nach dem Versenden der Inhalte wieder beendet. 1

2 2 HTTP Wie bereits oben weiter erwähnt, wird das Hypertext Transfer Protokoll für die Kommunikation zwischen Webclient und Webserver benutzt. Es besitzt folgende Charakteristika: Das HTTP operiert auf dem Applikationslayer. Das Protokoll selbst sorgt nicht für eine stabile Verbindung zum Server/Client; diese wird durch verwendung des TCP induziert. Request / Response: Eine HTTP-Kommunikation wird stets mit einem Request (gewöhnlich von Brouser) eröffnet und schließ mit einem Response der gegenseite ab. Frühere Requests werden nicht in Betracht gezogen, so daß kein Request in einem Kontext stehen könnte. (Stateless) Bidirektional: Daten können auch vom Client an den Server übermittelt werden, beispielsweise die Übermittling von Formulardaten. (POST -Request) HTTP erlaubt Browsern und Servern Details wie verwendete Character sets, Sprachen und Filetypen auszuhandeln. Hinzu kommt noch die Unterstützung für Caching und Zwischenhändlern wie Proxy-Server. 2.1 HTTP Request Um an Daten vom Server zu gelangen, richtet der Web-Client einen Request an den entsprechenden Server ab. Hauptsächlich werden dafür drei unterschiedliche Requests verwendet. 1. Der GET-Request, welchem der Inhalt der entsprechenden Seite zurückgeliefert wird. Er besteht nur aus einer Request line und gegebenenfalls einem Header. 2. Der HEAD-Request ist zu dem GET-Request ähnlich. Nur wird hier ausschließlich der Header der geforderten Seite zurückgeliefert. Dieser Request wird häufig verwendet, um die URL zu testen und nach möglichen Modifikationen zu sehen. 3. Der POST-Request wird verwendet, um s, News und Daten von Formularen, die ein interaktiver User zuvor ausgefüllt hat, zu versenden. Dies ist der einzige Request, der über einen Body verfügt. Das Format eines Requests sieht wie folgt aus: request-line headers (0 oder mehr) <blank line> body (nur bei POST-Request) Das Format der Request-line ist: request request-uri HTTP-Version In der folgenden Tabelle sind die einzelnen Header-Elemente aufgeführt und entsprechend gekennzeichnet, in welchen Request-Methoden sie vorkommen können. 2

3 Header name Request Response Body Allow Authorization Content-Encoding Content-Length Content-Type Date Expires From If-Modified-Since Last-Modified Location MIME-Version Pragma Referer Server User-Agent WWW-Authenticate 2.2 HTTP Response Das Format einer Response sieht wie folgt aus: status-line headers (0 oder mehr) <blank line> body Das Format der Status-line ist: HTTP-Version response-code response-phrase Dabei besteht der Responsecode aus drei Ziffern. In der folgenden Tabelle sind die einzelnen Response-Codes mit den zugehörigen Phrasen aufgeführt. 3

4 Response 1yz Description Informational. Not currently used Success. 200 OK, request succeeded. 201 OK, new resource creaded. (POST command) 202 Request accepted but processing not completed. 204 OK, but no content to return. Redirection; further action need be taken by user agent. 301 Requested resource has been assined a new permanent URL. 302 Requested resource resides temporarily under a different URL. 304 Document has not been modified. (conditional GET) Client error 400 Bad request. 401 Unorthorized; request requires user authentication. 403 Forbidden for unspezified reason. 404 Not found. Server error 500 Internal server error. 501 Not implemented. 502 Bad gateway; invalid response from gateway or upstream server. 503 Service temporarily unavailable. 3 HTTP/1.1 Die Protokollversion HTTP/1.1 enthält eine Reihe von Neuerungen und Verbesserungen zur Steigerung von Performance und Effizienz des Protokolls. Die Negotiations also die Verhandlungen zwischen Client und Server wurden grundlegend erweitert. Die wesentlichen Änderungen sollen im folgenden als Übersicht aufgeführt werden. Eine ausführliche Abhandlung kann in diesem Rahmen leider nicht gegeben werden. 3.1 Caching Bereits HTTP/1.0 unterstützte Caching Funktionen. Der QuellServer hatte die Möglichkeit einen expire header oder einen no-cache header zu setzten. Der Expire Header enthält einen absoluten Zeitstempel bis zur welchem das Dokument gültig ist. Der Cache kann zusätzlich einen conditional request an den Quellservers stellen. Mit diesem wird mittels dem Last-Modified Header aus dem gecacheten Dokument ermittelt ob das Dokument sich geändert hat. Der Quellserver antwortet auf diesen Request zum Beispiel mit Response Code 304 (Not Modified) worauf der Cache das bereits vorhandene Dokument an den Client schickt. Bei Code 200 (OK) sendet der Quellserver das aktuelle Dokument, welches im Cache ersetzt und an den Client weiter gereicht wird. Diese Implementation bot zwar Grundlegende Caching Möglichkeiten, brachte aber im Detail einige Schwierigkeiten mit sich. Bei HTTP/1.1 ist ein Dokument im Cache entweder fresh oder wenn die expiration time in der Vergangenheit liegt stale. Wenn ein Dokument stale ist, muss es nicht zwangsläufig aus dem Cache entfernt sondern nur revalidiert werden. Dieser Vorgang ähnelt zwar dem Prozess bei HTTP/1.0, der Unterschied aber ist dass nicht absolute Zeitstempel benutzt werden muessen, sondern anstatt der expiration time auch ein 4

5 Max Age Header eine relative Cachedauer angeben kann. Dies umgeht die Problematik der nicht immer syncronen Zeiten auf den Servern/Rechnern. Eine weitere Neuheit war dass diese Regeln von dem Client/Server überschrieben werden kann. Der User kann also sicher gehen eine aktuelle Version des gewünschten Dokuments zu erhalten. Ausserdem führt HTTP/1.1 einen Age Header ein, der angibt wie lange sich das Dokument bereits im Cache befindet. Quellserver sowie Client können einen no-store header erreichen dass das Dokument nicht gecached wird. 3.2 Transport Range Requests Range Request erlauben dem Client bestimmte Bereiche einer Datei vom Server anzufordern. Mit der Einführung von Range Requests ist es nicht mehr nötig Dokumente (Text,Bilder andere Daten) die z.b. durch einen Netzwerkfehler nicht komplett übertragen werden konnten erneut komplett zu übertragen. Es müssen nur noch die fehlenden Daten übertragen werden. Der Response Code einer solchen Übertragung ist Pipelining Beim Pipelining werden bei HTTP/1.1 gegenüber HTTP/1.0 mehrere HTTP Request über eine TCP Connection geschickt. So werden weniger Verbindungen gebraucht und sommit eine Performancesteigerung erzielt Persistent Connections Persistent Connetions bedeutet dass die aufgebauten TCP Connection offen bleiben, bis sie explizit durch ein Connection: Close geschlossen werden. Der Vorteil bei dieser Vorgehensweise in Verbindung mit Pipelining liegt darin, dass z.b. die Bilder eines HTML Dokuments über eine einzige TCP Connection übertragen werden, und nicht für jedes Bild eine neue TCP Connection iniziert werden muss. 3.3 Virtual Hosts Vor der Einführung von HTTP/1.1 konnte ein HTTP Server auf einer IP Adresse nur eine Domain/Host (z.b. hosten. Ein Request unter HTTP/1.0 sah somit wie folgt aus: GET / HTTP/1.0 Unter HTTP/1.1 wird (wie unten angeben) der Host/die Domain mit im Request angegeben, somit kann ein Server (mittels einer einzigen IP-Adresse) mehrere so genannte Virtual Hosts beherbergen. GET / HTTP/1.1 Host: 5

6 3.4 Basic und Digest Auth Unter HTTP/1.1 gab es nur eine Möglichkeit der Authentifizierung, das sogennante Basic Auth Verfahren. Bei diesem Verfahren sendet der Client Username/Passwort im Klartext an den Server welcher bei richtiger Kombination das Dokument überträgt. Diese Authentifizierung ist probematisch da man durch einfaches mitschneiden des Netzwerkverkehrs Username und Passwort erhält. Seit HTTP/1.1 gibt es die Möglichkeit des Digest Auth. Bei dieser Methode schickt der Server dem Client einen nur einmal gültigen Wert ( nonce value ). Aus diesem Wert, dem Username, dem Passwort, der HTTP Methode (GET,POST,...) und der URI berechnet der Client eine Checksumme (default: MD5). Der Vorteil hierbei ist, dass Username/Passwort nicht mehr im Klartext übertragen werden, und dass die Checksumme nur für diese eine Transaktion gilt! Diese Methode gewährleistet aber nicht die Authentizität des Dokuments, des Servers sowie die Sicherheit der Übertragung. Wenn diese Funktionen gefordert sind muss auf HTTPS verwiesen werden. 3.5 Neue Responsecodes (Eine Auswahl) Response Description 100 Continue, z.b nach erfolgreichem Auth 206 Partial Content, siehe Range Request 409 Conflict, z.b. ein fehlgeschlagenes PUT 410 Gone, temporarily moved 4 Server und Useragents Der führende HTTP Server ist laut Webserver Survey der Firma Netcraft der Apache Webserver welcher 31,040,922 der 47,173,415 überprüften Domains (67%) hostet. Mit 21% liegen die Internet Information Server der Firma Microsoft auf Platz 2 mit Domains. Angemerkt sei dass Domain nicht gleich Server ist. Diese Statistiken sind somit mit einer gewissen Vorsicht zu betrachten. Auf der Seite der Useragents führt der Internet Explorer der Firma Microsoft mit über 60%. Gefolgt von Netscape, Mozilla, Opera und Konqueror. 5 Anmerkung Bei differenzierter Auslegung der RFC Keywords ( MUST, MAY, SHOULD, etc) können die Protokollabläufe auch variieren. 6