HTTP / SHTTP. Schwerpunkt: Technische Aspekte. Ausarbeitung von Corinna Habets im Rahmen des Proseminars

Transkript

1 HTTP / SHTTP Schwerpunkt: Technische Aspekte Ausarbeitung von Corinna Habets im Rahmen des Proseminars Methoden und Werkzeuge an der RWTH Aachen im WS 2003/04 Stand: 16. Oktober 2003

2 Inhaltsverzeichnis 1 Überblick 1 2 Geschichte 1 3 Einordnung 2 4 Technische Aspekte Request Response Header Caching Connection-Management SHTTP Zusammenfassung 13 6 Ausblick 13 Literatur 14

3 1 Überblick Das WorldWideWeb in seiner heutigen Form wäre ohne HTTP - das Hyper Text Transfer Protocol - nicht möglich. Dieser Standard regelt zum einen wie ein Client (Beispiel: WebBrowser) über das Internet beliebige Dokumente bei einem WebServer anfordern kann. Zum anderen standardisiert er die möglichen Antworten des Servers. Und zwar völlig unabhängig von Plattform und Hardware der beiden Parteien. Diese Unabhängigkeit ist die Stärke von HTTP. Sie ist unabdingbar für die Kommunikation im Internet, das aus Millionen heterogenen Rechnern besteht. 2 Geschichte Vor HTTP wurde für Datentranfers hauptsächlich FTP (File Transfer Protocol) benutzt. Dieses Verfahren hat folgende Nachteile: man muß genau wissen was und wo man sucht keine erklärende grafische Oberfläche keine weiterführenden Hinweise Das Duo HTTP und HTML (HyperText Markup Language) - löste FTP in vielen Bereichen ab. (Per HTML lassen sich ansprechende grafische Oberfächen gestalten.) Folgendermaßen verlief die Entwicklung im Einzelnen: 0.9 Im Jahre 1991 erschien ein Prototyp von HTTP, der heute die Versionsnummer 0.9 trägt. Er war sehr primitiv und konnte ausschließlich HTML-Dateien anfordern bzw. liefern. Noch heute trägt HTTP die damalige Beschränkung im Namen. 1.0 Im Zuge der rasanten Entwicklung des Internets wurde Version 0.9 nur wenig später durch HTTP 1.0 ersetzt. Die wichtigste Neuerung war, daß HTTP MIME (Multipurpose Internet Mail Extensions) adaptierte und seitdem jedes beliebige Datenformat transportieren kann. HTTP 1.0 verbreitete sich weit. Da es jedoch kein Standard war, existieren viele verschiedene Implementierungen. 1

4 1.0+ Mitte der Neunziger Jahre hatte sich HTTP 1.0 durch mehrere Optimierungen zu einer, heute als 1.0+ erweiterten Version entwickelt, die 1.0 großflächig ersetzte. Die Verbesserungen betrafen vor allem Connection-Management (siehe 4.5) und VirtualHosting. 1.1 Diese Version wurde 1997 vorgestellt und 1999 offizieller Standard. In ihr wurden frühere architektonische Fehler beseitigt und die Performance optimiert. HTTP 1.1 ist immer noch aktuell. NG Im Herbst 97 nahm die Arbeitsgruppe HTTP-NG (NG steht für Next Generation ) die Weiterentwicklung von HTTP auf. Allerdings stellte sie die Arbeit schon ein Jahr später wieder ein. Sie waren zeitlich wohl zu dicht an HTTP 1.1 gewesen. Auf eine der daraus entstandenen Ideen gehe ich in Abschnitt 6 ein. 3 Einordnung Ein Großteil des gesamten Datenflusses im Internet wird per HTTP übertragen. Das Protokoll ist von dualer Natur: Einerseits gibt es den Client, der Daten anfragt (sogenannter Request) und empfängt. Andererseits den Server, der das Gewünschte (oder eine Fehlermeldung) liefert (sogenannter Response). Neben diesen beiden Parteien kann es noch zwischengeschaltete Instanzen geben, die sich für den Client wie ein Server verhalten, und für den Server wie ein Client. Diese Intermediaries müssen also beide Seiten des Protokolls beherrschen. Die wichtigen Intermediaries sind: Proxy Server Mit Proxy Servern lassen sich u. a. Filterfunktionen realisieren, indem man Messages von Client/Server bearbeitet weiterleitet. (Beispiel: Kinderschutzfilter) Viele Proxy Server sind Proxy Caches. Ein Cache ist ein Speicher in dem angeforderte Daten für zukünftige Zugriffe gespeichert werden können (zwecks Beschleunigung). 2

5 Gateway Ist in der Reinform ein Übersetzer zwischen Anfragen aus dem Internet und hinter ihm stehenden Servern, die das HTT-Protokoll nicht beherrschen. (Beispiel: Web-Interface für , HTTP <->POP3) (In der Praxis sind die Grenzen zwischen Proxy und Gateway fließend.) Tunnel Hierbei wird HTTP benutzt um ganz andere Protokolle zu transportieren, denn ein Tunnel leitet Nachrichten unbesehen und -bearbeitet weiter. (Beispiel: SSH durch Firewalls die kein SSH akzeptieren) HTTP regelt nicht den Daten-Transport an sich. Dazu braucht es ein Transportprotokoll. Dieses ist zwar nicht vorgegeben, wirklich gute Lösungen existieren aber nur für die Zusammenarbeit mit TCP/IP (Transmission Control Protocol/Internet Protocol). HTTP TCP IP Network Interfaces Physical Network Hardware - Application Layer - Transport Layer - Network Layer - Data Link Layer - Physical Layer 4 Technische Aspekte Wie bereits erwähnt regelt HTTP das Anfordern und Liefern von Dokumenten. Dies geschieht durch sogenannte Messages, die Clients und Server senden. Eine Message besteht aus: Start-Line Unterschiedlich, je nach Art der Message. Header-Fields Header sind optional. (Keiner oder beliebig viele.) Falls vorhanden enthalten sie zusätzliche Informationen (siehe 4.3). Body Der Body ist optional. (Kein- oder einmal.) Falls vorhanden kann er aus jeder Art Daten bestehen (binär, Text, etc.). 3

6 Es gibt genau zwei verschiedene Arten von Messages: Request und Response, die in den nächsten beiden Abschnitten behandelt werden. 4.1 Request Die Anfrage eines Clients bei einem Server bezeichnet man als Request. Er ist folgendermaßen aufgebaut: Schema Beispiel Startline <Methode><Request-URL> GET /index.html <Version> HTTP/1.1 Header-Fields <Header> User-Agent: Mozilla/5.0 Body <Entity-Body> [leer] Nach der Startline folgt ein CRLF (CarriageReturn, LineFeed). Header und Body sind optional. Mehrere Header werden durch CRLF von einander getrennt. Nach den Headern ist eine Leerzeile zwingend, selbst wenn kein Body folgt. Die Methode spezifiziert die Art der Anfrage an den Server: GET Ist die bei weitem häufigste Anfrage, denn so fordert ein Client eine Datei an. (Dies ist die einzige Methode die HTTP 0.9 beherrschte.) HEAD Auf diese Methode hin, liefert der Server nur die Start-Line und Header der angegebenen URL, ohne den Body (- also die Datei selbst). Diese Methode ist hauptsächlich beim Cachen von Bedeutung (mehr in Abschnitt 4.4). POST Hierbei soll der Server Daten verarbeiten, die im Body der Request- Message übergeben werden. (Beispiel: HTML-Formulardaten) OPTIONS Erfragt Informationen über den Server und seinen Funktionsumfang. 4

7 TRACE Vor allem zum Debuggen geeignet. Man bekommt Weg und Verarbeitung der Request-Message als Response zurück. PUT Veranlasst den Server eine neue Datei an der angegebenen URL zu erschaffen oder die dort vorhandene zu überschreiben. (Die URL muß natürlich auf dem Server liegen.) Der gewünschte Inhalt der Datei muß im Body gesendet werden. DELETE Das Gegenstück zu PUT. Die durch die URL spezifizierte Datei auf dem Server wird gelöscht. Es werden nicht alle Methoden von allen Servern unterstützt (vor allem nicht PUT und DELETE). Verpflichtend zu implementieren sind lediglich GET und HEAD. POST ist ebenfalls weit verbreitet. HTTP ist so offen konzipiert, daß über diese Standard-Methoden hinaus, eigene Methoden definiert werden können. Eine zwar reservierte, jedoch nicht offiziell definierte Methode, die breit unterstützt wird, ist CONNECT. Mit dieser Methode werden Tunnel realisiert (siehe Abschnitt 3). Versucht man eine Methode zu benutzen, die der angesprochene Server nicht unterstützt, bekommt man eine entsprechende Statusmeldung zurück (im Normalfall Not Implemented ). Mehr zu Responses und Statusmeldungen im Abschnitt 4.2. HTTP benutzt die üblichen URLs (Uniform Resource Locator) um anzugeben, mit welcher Datei gearbeitet werden soll. http : // < host >:< port > / < path >? < searchpart > } {{ } Scheme Wie oben dargestellt gibt der Scheme-Teil einer URL das zu benutzende Protokoll an. In unserem Fall also immer Nach der Host-Angabe gibt es die kaum genutzte Möglichkeit einen Port anzugeben. Geschieht dies nicht, wird bei HTTP der Standard-Port 80 benutzt. 5

8 Die Versionsnummer von HTTP besteht aus einer Nummer für grundlegende Änderungen und einer für kleinere Updates, die durch einen. getrennt werden: <major>.<minor> 4.2 Response Die Antwort eines Servers an einen Client bezeichnet man als Response. Er ist folgendermaßen aufgebaut: Schema Beispiel Startline <Version><Status> HTTP/ OK <Reason-Phrase> Header-Fields <Header> Content-Type: text/html Body <Entity-Body> <html><head>... Jeder Response enthält einen StatusCode, der Auskunft darüber gibt, wie es der Anfrage des Clients erging. Dieser StatusCode ist dreistellig, wobei die erste Ziffer eine Ober-Kategorie kennzeichnet und die letzten beiden Konkreteres angeben. 1** Zwischen-Informationen (selten) 2** Anfrage war erfolgreich 3** Umleitung 4** Clientseitiger Fehler 5** Serverseitiger Fehler Innerhalb der Ober-Kategorien können weitere Codes (auf freien Zahlen) definiert werden. Erhält ein Client einen StatusCode, den er nicht versteht, soll er ihn der Ober-Kategorie entsprechend interpretieren. Die Reason-Phrase wird nicht vom Client verarbeitet, sondern ist nur als Kommentar für Menschen gedacht. Daher sind die Texte nicht vorgegeben, sondern können frei gewählt werden. Hier ist eine Auswahl von StatusCodes und ihren üblichen Reason-Phrases. (Eine vollständige Liste finden Sie in [1] und [3].) 6

9 Code Reason-Phrase Beschreibung 100 Continue Der Client soll fortfahren, den Request zu senden. 101 Switching Protocols Der Server ist einverstanden, das Protokoll zu wechseln. 200 OK Alles hat geklappt. Der Response hängt von der Request-Method ab. 201 Created Antwort auf erfolgreichen PUT- Request. 204 No Content Wird benutzt um Meta-Informationen zu senden, ohne daß sich das Dokument im Client ändert. Enthält nie einen Body. 300 Multiple Choices Die Anfrage kann sich auf mehrere Repräsentationen beziehen. 301 Moved Permanently Die angefragte Resource ist dauerhaft umgezogen. 304 Not Modified Die Datei hat sich, seit einem im Request angegebenen Zeitpunkt, nicht geändert. Hat keinen Body. 307 Temporary Redirect Die Resource ist nur vorübergehend umgezogen. 400 Bad Request Der Request war fehlerhaft. 401 Unauthorized Der User hat sich noch nicht, oder nicht korrekt authenifiziert. 403 Forbidden Zugang verwehrt. Es ist auch keine Authorization möglich. 404 Not Found Unter der angegebenen URL wurde nichts gefunden. 405 Method Not Allowed Die Request-Methode ist fuer die URL nicht zulässig. 415 Unsupported Media Type Das im Body enthaltene Datenformat wird nicht unterstützt. 7

10 500 Internal Server Error Der Request ist in Ordnung, aber der Server arbeitet fehlerhaft. 501 Not Implemented Die Request-Methode ist im Server nicht implementiert. 505 HTTP Version not supported 4.3 Header Ein Header hat die Form: Die HTTP-Version des Requests wird nicht unterstützt. Schema <name>:<value>[crlf] Beispiel Date: Sat, 11 Oct :50:04 GMT Eine Message kann zwischen Null und unbegrenzt vielen Headern haben. Die Header enthalten Zusatz-Informationen. Es gibt verschiedene Typen: General Für beide Arten von Messages erlaubt (Beispiel: Date) Request Kann nur in Anfragen existieren Response Darf nur in Antworten vorkommen Entity Informationen über den Body-Inhalt - kann also in beiden Message- Typen stehen Extension Solche Header sind kein Standard, sondern sind selbst definiert Aus der Flut definierter Header hier nur exemplarisch einige wenige: (Eine vollständige Liste finden Sie in [1] und [3].) 8

11 Header Beschreibung General Date Genaue Zeitangabe, wann die Message generiert wurde Via Gibt an welchen Weg die Message gegangen ist Connection Client/Server können Wünsche angeben (mehr bei 4.5) Upgrade Signal, daß Client/Server gern eine höhere Protokoll-Version nutzen würde Request From -Adresse des Users, der den Client nutzt Host Name und Port des Servers an den sich die Anfrage richtet UA-OS Name und Version des Betriebssystems auf dem der Client läuft User-Agent Name des Clients, des Programms, das den Request schickt Accept Sagt dem Server welche Dateiformate gesendet werden dürfen Accept-Language Sagt dem Server welche Sprachen gesendet werden dürfen If-Modified-Since Die Datei soll nur geschickt werden, wenn sie sich seit dem anzugebenden Datum geändert hat Authorization Enthält Daten, mit denen sich der Client beim Server ausweist Proxy-Authorization Das gleiche wie Authorization nur auf einen Proxy bezogen 9

12 Age Retry-After Server Warning Set-Cookie Allow Location Content-Language Content-Length Content-Type Expires Last-Modified Response Alter der Antwort Zeitangabe fuer einen erneuten Versuch, falls die Resource unerreichbar war Name und Version der Server-Software Eine detaillierte Warnung, als Ergänzung zur Reason-Phrase Plaziert eine Datei auf dem Client-Rechner, mit der der Server den Client identifizieren kann Entity Welche Methoden sind mit der Datei zulässig Wo befindet sie sich - kann ein Verweis zu einer neuen URL sein In welcher Sprache ist die Datei verfaßt Die genaue Größe des Bodies Um welchen Datei-Typ handelt es sich Haltbarkeitsdatum Zeitpunkt der letzten Änderung 4.4 Caching Ein Proxy Cache Server behält Kopien der Daten, die ihn passieren. Dadurch kann er bei einer erneuten Anforderung diese Daten schneller liefern, als wenn er sie wieder beim Original-Server abholen müßte. Caching hat folgende Vorteile: Es wird weniger Bandbreite beansprucht. Der Original-Server muss weniger Anfragen bearbeiten. Kürzere Übertragungswege, daher Zeitersparnis. Dieses einfache Konzept ist der Praxis sehr ausgeklügelt wenn es darum geht, welche Dateien gespeichert werden sollen (z.b. nach Häufigkeit) oder wann sie neu gecacht werden sollen (die Datei auf dem Ursprungs-Server kann sich ändern). Schließlich sollen möglichst viele und möglichst aktuelle Kopien im Cache sein. Eine neu gecachte Datei gilt zunächst als frisch. In dieser Zeit liefert der 10

13 Proxy Cache auf Anfrage seine Kopie aus. Ist dieser Zustand abgelaufen, fragt der Cache mit der HEAD-Methode beim Server nach, ob sich die Datei seit dem Speichern verändert hat (If-Modified-Since-Header). Nur falls dies der Fall ist, wird die Datei neu gesendet. Andernfalls gilt die alte Kopie wieder als frisch. [Heutzutage haben auch alle gängigen WebBrowser einen eingebauten Cache auf der Festplatte.] 4.5 Connection-Management Oft zieht eine Anfrage an einen Server weitere nach sich. Beispielsweise, wenn man innerhalb eines Web-Auftritts mehrere Links besucht oder wenn eine HTML-Seite geladen wird, die viele Elemente (Bilder, Movies, etc.) einbindet. (Diese Elemente müssen zwar nicht auf demselben Server liegen, wie die Seite selbst, es ist jedoch wahrscheinlich.) Solche Anfrage-Serien wurden nicht immer effizient behandelt. Hier die verschiedenen Arten des Connection-Management von HTTP im Laufe seiner Entwicklung: Seriell Einfach und langsam. Jede Verbindung wird nach Beendigung eines Ladevorgangs geschlossen. Dann erst wird eine neue aufgemacht um das nächste Element zu laden, usw. Parallel Es können mehrere TCP-Verbindungen nebeneinander aufgemacht werden. [Deren Anzahl ist oft auf vier parallele Connections begrenzt.] Keep-Alive Eine inzwischen veraltete Technik aus HTTP Arbeitet prinzipiell wie die serielle Transaktion, allerdings wird durch einen speziellen Header signalisiert, dass die Verbindung nicht geschlossen werden soll. (Dies muß bei jeder Message gesendet werden.) Dennoch können beide Parteien die Verbindung jederzeit beenden. Leider gibt es große Probleme im Zusammenspiel mit Proxies. Persistent Gab es schon bei HTTP 1.0+ und ist in HTTP 1.1 Standard. Funktioniert im Prinzip wie Keep-Alive. Allerdings ist die Persistent Connec- 11

14 tion die Regel: man muß extra angeben, wenn die Verbindung geschlossen werden soll. Dadurch treten kaum noch Schwierigkeiten mit Proxies mehr auf. Diese Technik wird oft mit parallelen Verbindungen kombiniert. Pipelined Bei dieser Strategie können Latenzzeiten im Netzwerk ausgenutzt werden, indem mehrere Requests in Serie an den Server geschickt werden, die nacheinander abgearbeitet werden. Dies kann bei nicht idempotenten Methoden wie POST zu Problemen führen. [Ein Request ist idempotent, wenn es keine Rolle spielt, wie oft er ausgeführt wird. (Beispiel: GET)] 4.6 SHTTP Obwohl HTTP ein paar sicherheitsrelevante Features enthält (u.a. besteht die Möglichkeit zur Authentifizierung) ist es für vertrauliche Datentransfers (z.b. Bankgeschäfte) nicht geeignet. Deshalb kombiniert SHTTP (das S steht für Secure) HTTP mit einem kryptografischen Protokoll. Dabei werden alle Messages sowohl vom Client als auch vom Server, vor dem Versenden verschlüsselt. Das kryptografische Protokoll ist frei wählbar. HTTP SSL/TLS TCP IP Network Interfaces Physical Network Hardware - Application Layer - Security Layer - Transport Layer - Network Layer - Data Link Layer - Physical Layer In der Praxis benutzt man meist https, eine Entwicklung von Netscape. Diese Implementierung von SHTTP verwendet SSL (Secure Socket Layer) oder dessen Nachfolger TLS (Transport Layer Security) zum Verschlüsseln. Das URL-Scheme ändert sich von zu Der Standard-Port hierfür ist 443. Nach Etablierung der TCP-Verbindung tauschen Client und Server aufgrund des Verschlüsselungsprotokolls zunächst Sicherheits-Daten aus, danach erst erfolgt der eigentliche Datentransfer. Das ganze System stützt sich auf Server- 12

15 Zertifikate, mit denen sich ein Server Clients gegenüber identifiziert. 5 Zusammenfassung Seit Anfang der Neunziger Jahre haben HTTP und das Web eine rasant steigende Nutzung erfahren. Dabei ist HTTP immer wieder an die sich wandelnden Bedürfnisse angepaßt worden. Am Grundkonzept der Messages, mit Meta-Informationen in den Headern und der Fracht im Body, hat sich jedoch nichts geändert. Trotz der Erfolgsstory wird HTTP nicht weiterentwickelt. 6 Ausblick Die damalige HTTP-NG-Arbeitsgruppe gebar die Idee von XMLP (EXtensible Markup Language Protocol). Es soll eine standardisierte Schnittstelle zwischen verschiedenen Programmen bieten, über die Informationen im XML-Format ausgetauscht werden können. So etwas ähnliches existiert schon unter dem Namen WebServices. Dies bezeichnet einen losen Verbund von Absprachen und Protokollen, der es schon heute erlaubt anwendungsübergreifend Daten auszutauschen. WebServices setzen dazu vor allem auf SOAP (Simple Object Access Protocol). Dieses Protokoll regelt wie man XML-Informationen zu Messages hinzufügen kann... HTTP-Messages versteht sich. 13

16 Literatur [1] RFC 1945 HTTP/1.0 RFC 2068 HTTP/1.1 RFC 2616 HTTP/1.1 RFC 2817 Upgrading to TLS Within HTTP/1.1 Alle RFCs sind online verfügbar unter: Die RFCs sind relativ trocken, dafür aber sehr detailliert. [2] Unix Unleashed von Robin Burk erschienen 1998 bei SAMS Publishing Enthält einen gut geschriebenen Kurzüberblick, der alle wichtigen Themen und sogar ein bißchen geschichtlichen Hintergrund behandelt. [3] HTTP - The Definite Guide von David Gourley, Brain Totty u.a. erschienen 2002 bei O Reilly & Associates Sehr ausführliches, praxisnahes Buch das nur ein paar theoretische Fragen offenläßt. [4] Hier gibt es Informationen zu fast jedem internetrelevanten Standard (auch denen der Zukunft). 14