pdf, 85KB - geekin.de

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
Inhaltsverzeichnis
1 Überblick
1
2 Geschichte
1
3 Einordnung
2
4 Technische Aspekte
4.1 Request . . . . . . . . .
4.2 Response . . . . . . . . .
4.3 Header . . . . . . . . . .
4.4 Caching . . . . . . . . .
4.5 Connection-Management
4.6 SHTTP . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
. 4
. 6
. 8
. 10
. 11
. 12
5 Zusammenfassung
13
6 Ausblick
13
Literatur
14
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
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
• Gateway
Ist in der Reinform ein Übersetzer“ zwischen Anfragen aus dem Inter”
net und hinter“ ihm stehenden Servern, die das HTT-Protokoll nicht
”
beherrschen. (Beispiel: Web-Interface für EMail, 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
4
-
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
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
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:
Header-Fields
Schema
<Methode><Request-URL>
<Version>
<Header>
Body
<Entity-Body>
Startline
Beispiel
GET /index.html
HTTP/1.1
User-Agent: Mozilla/5.0
[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 RequestMessage übergeben werden. (Beispiel: HTML-Formulardaten)
• OPTIONS
Erfragt Informationen über den Server und seinen Funktionsumfang.
4
• 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 ’501 - 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 >
|
{z
}
Scheme
Wie oben dargestellt gibt der Scheme-Teil einer URL das zu benutzende
Protokoll an. In unserem Fall also immer http://. 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
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:
Header-Fields
Schema
<Version><Status>
<Reason-Phrase>
<Header>
Body
<Entity-Body>
Startline
Beispiel
HTTP/1.1 200 OK
Content-Type:
text/html
<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
Code
100
Reason-Phrase
Continue
101
Switching Protocols
200
OK
201
Created
204
No Content
300
Multiple Choices
301
Moved Permanently
304
Not Modified
307
Temporary Redirect
400
401
Bad Request
Unauthorized
403
Forbidden
404
Not Found
405
Method Not Allowed
415
Unsupported Media
Type
Beschreibung
Der Client soll fortfahren, den Request
zu senden.
Der Server ist einverstanden, das Protokoll zu wechseln.
Alles hat geklappt. Der Response hängt
von der Request-Method ab.
Antwort auf erfolgreichen PUTRequest.
Wird benutzt um Meta-Informationen
zu senden, ohne daß sich das Dokument
im Client ändert. Enthält nie einen Body.
Die Anfrage kann sich auf mehrere Repräsentationen beziehen.
Die angefragte Resource ist dauerhaft
umgezogen.
Die Datei hat sich, seit einem im
Request angegebenen Zeitpunkt, nicht
geändert. Hat keinen Body.
Die Resource ist nur vorübergehend
umgezogen.
Der Request war fehlerhaft.
Der User hat sich noch nicht, oder nicht
korrekt authenifiziert.
Zugang verwehrt. Es ist auch keine Authorization möglich.
Unter der angegebenen URL wurde
nichts gefunden.
Die Request-Methode ist fuer die URL
nicht zulässig.
Das im Body enthaltene Datenformat
wird nicht unterstützt.
7
500 Internal Server Error
501 Not Implemented
505 HTTP Version not
supported
4.3
Der Request ist in Ordnung, aber der
Server arbeitet fehlerhaft.
Die Request-Methode ist im Server
nicht implementiert.
Die HTTP-Version des Requests wird
nicht unterstützt.
Header
Ein Header hat die Form:
Schema
<name>:<value>[CRLF]
Beispiel
Date: Sat, 11 Oct 2003 13: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 MessageTypen 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
Header
Date
Via
Connection
Upgrade
From
Host
UA-OS
User-Agent
Accept
Accept-Language
If-Modified-Since
Authorization
Proxy-Authorization
Beschreibung
General
Genaue Zeitangabe, wann die Message generiert wurde
Gibt an welchen Weg die Message gegangen
ist
Client/Server können Wünsche angeben
(mehr bei 4.5)
Signal, daß Client/Server gern eine höhere
Protokoll-Version nutzen würde
Request
EMail-Adresse des Users, der den Client
nutzt
Name und Port des Servers an den sich die
Anfrage richtet
Name und Version des Betriebssystems auf
dem der Client läuft
Name des Clients, des Programms, das den
Request schickt
Sagt dem Server welche Dateiformate gesendet werden dürfen
Sagt dem Server welche Sprachen gesendet
werden dürfen
Die Datei soll nur geschickt werden, wenn sie
sich seit dem anzugebenden Datum geändert
hat
Enthält Daten, mit denen sich der Client
beim Server ausweist
Das gleiche wie ’Authorization’ nur auf einen
Proxy bezogen
9
Age
Retry-After
Server
Warning
Set-Cookie
Allow
Location
Content-Language
Content-Length
Content-Type
Expires
Last-Modified
4.4
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
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
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 1.0+. 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 Connec11
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 http:// zu https://. 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 Server12
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
Literatur
[1] RFC
RFC
RFC
RFC
1945
2068
2616
2817
—
—
—
—
HTTP/1.0
HTTP/1.1
HTTP/1.1
Upgrading to TLS Within HTTP/1.1
Alle RFCs sind online verfügbar unter:
http://www.rfc-editor.de
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] http://www.w3c.org/
Hier gibt es Informationen zu fast jedem internetrelevanten Standard
(auch denen der Zukunft).
14