| |
| * Link führt ins Internet |
|
| |
Protokolle der Anwendungsschicht
|
|
Hypertext Transfer Protocol (HTTP)
Das Hyptext Transfer Protocol, kurz HTTP, wurde für den Austausch von Hypertext-Dokumenten entwickelt. Es gibt zwei Versionen, 1.0 und 1.1, wobei die neuere Version 1.1 inzwischen von sämtlichen Browsern (ab Version 4.0) unterstützt wird, allerdings noch nicht allen HTTP-Servern zur Verfügung steht.
Das HTTP-Protokoll setzt auf TCP/IP auf und regelt die Kommunikation von WWW-Servern und WWW-Client. Das HTTP-Protokoll legt das Format, den Inhalt und die Abfolge von Mittelungen zwischen Client und Server fest.
Da sämtliche Mitteilungen als ASCII-Zeichenketten ausgetauscht werden, ist HTTP weitgehend plattformunabhängig.
HTTP ist ein verbindungsloses Protokoll, das bedeutet, dass Server und Client nach jedem Kommando den Prozess beenden und abhängig vom Inhalt von jeweils übermittelten Statusmeldungen im weiteren Verlauf des Kommunikationsprozesses für jedes weitere Kommando einen erneuten Prozess starten.
Die Kommunikation zwischen WWW-Client und WWW-Server erfolgt unter HTTP nach folgendem Ablaufschema:
Der WWW-Client sendet eine Request-Mitteilung an den WWW-Server. Diese wird vom Server mit einer Response-Mitteilung beantwortet. Das HTTP-Protokoll regelt hierbei den Aufbau dieser Mitteilungen. Grundsätzlich bestehen alle HTTP-Mitteilungen aus einer Reihe von Headern sowie, durch eine Leerzeile abgetrennt, dem eigentlichen Inhalt.
Zum Senden einer Request-Mitteilung wird eine TCP/IP-Verbindung zum WWW-Server aufgebaut. Kann der Webserver die angeforderte Seite zur Verfügung stellen, wird das Dokument über dieselbe Verbindung zurückgesendet und die Verbindung wieder geschlossen.
Aufbau eines HTTP-Request
Der Request besteht aus einem Uniform Resource Locator, kurz URL, dem Method-Token, den Header-Informationen sowie einem Entity-Body mit den zu versendenden Daten. Der Aufbau eines Request ist in drei Segmente unterteilt:
| Segment | Beschreibung |
| Status-Line | Enthält den Method-Token. |
| Header | Enthält die General, Request- und Entity-Header. |
| Entity-Body | Enthält die zu übertragenden Daten. |
Der Method-Token beschreibt die auf das Dokument anzuwendende Methode. Folgende Methoden stehen zur Verfügung. Die aktuelle HTTP-Spezifikation sieht zehn Methoden vor: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, LINK und UNLINK.
GET-Methode
Die mit Abstand wichtigste Methode ist GET. Sie dient zur Anforderung eines Dokuments oder einer anderen Quelle. Eine Quelle wird dabei durch den Request-URL identifiziert. Man unterscheidet zwei Typen: conditional GET und partial GET. Beim Conditional-GET-Typ ist die Anforderung von Daten an Bedingungen geknüpft. Die genauen Bedingungen sind dabei im Header-Feld "Conditional" hinterlegt. Oft gebrauchte Bedingungen sind zum Beispiel If-Modified-Since, If-Unmodified-Since oder If-Match. Mit Hilfe dieser Bedingung lässt sich die Netzbelastung deutlich verringern, da nur noch die wirklich benötigten Daten übertragen werden. In der Praxis nutzen zum Beispiel Proxyserver diese Funktion, um die mehrfache Übertragung von Daten, die sich bereits im Cache befinden, zu verhindern.
Das gleiche Ziel verfolgt die partielle GET-Methode. Sie verwendet das Range-Header-Feld, das nur Teile der Daten überträgt, die der Client jedoch noch verarbeiten kann. Diese Technik wird für die Wiederaufnahme eines unterbrochenen Datentransfers verwendet.
POST-Methode
Den umgekehrten Weg nimmt die POST-Methode: Sie übermittelt in erster Linie Formulareingaben an einen Webserver. Aber auch die Kommentierung bestehender Quellen, Übermittlung von Nachrichten an Foren und Erweiterung von Online-Datenbanken sind mit POST möglich. Die an den Server übermittelten Daten sind in der Entity-Sektion enthalten. Auch die POST-Methode übermittelt einen URL. In diesem Fall dient dieser lediglich als Referenz, welche Routine auf dem Server die Bearbeitung der Daten übernimmt.
OPTIONS-Methode
Über diese Methode kann der Client Informationen über verfügbare Kommunikationsoptionen abrufen. So lassen sich insbesondere Beschränkungen von Quellen auf einem HTTP-Server oder auch einem Proxyserver ermitteln, ohne das eine bestimmte Aktion eingeleitet oder gar ein Datentransfer stattfindet.
HEAD-Methode
Diese Methode ist GET in seiner Funktionsweise sehr ähnlich. Einziger Unterschied: HEAD fordert lediglich den Header eines Dokuments oder Quelle an. Im Gegensatz zu GET übermittelt der Server aber nicht die eigentlichen Daten. HEAD eignet sich insbesondere dazu, die Größe von Quellen, Typ oder Objektattribute ausfindig zu machen. Der Server übermittelt auf eine HEAD-Anfrage die Metainformationen, die identisch mit den Informationen der GET-Request sind.
PUT-Methode
Dieser Typ erlaubt die Modifikation bestehender Quellen beziehungsweise Erzeugung neuer Daten auf dem Server. Im Unterschied zur POST-Methode identifiziert der URL in der PUT-Request die mit der Anforderung gesendeten Daten selbst, und nicht die Quelle.
DELETE-Methode
Mit Hilfe dieses Typs werden Daten auf dem HTTP-Server gelöscht, die durch den URL identifiziert sind. Das Interessante dabei: Der Löschvorgang muss nicht unmittelbar nach dem Eingang der Anforderung, sondern kann auch zu einen späteren Zeitpunkt erfolgen. Der Server soll laut Spezifikation zumindest die Annahme der Request bestätigen.
TRACE-Methode
Über diese Methode kann der Client Requests verfolgen, die über mehrere Knotenpunkte laufen. Dies ist insbesondere bei der Übermittlung der Request über einen oder mehrere Proxyserver interessant. Das letzte Glied der Kette generiert die Antwort. Die TRACE-Methode dient in erster Linie der Diagnose von Client-Server-Verbindungen. Über das Max-Forwards-Header-Feld bestimmt der Client die maximale Anzahl an Hops. Im Header-Feld "Via" der Antwortnachricht sind alle durchlaufenen Server protokolliert.
CONNECT-Methode
Die CONNECT-Methode ist in der HTTP/1.1-Spezifikation für Verbindungen reserviert, bei denen Proxyserver dynamisch als Tunnel agieren. In der Praxis kann es sich beispielsweise um SSL-Tunnel handeln. Der Tunnelmechanismus ist in der ersten Linie als Durchgang für SSL-gesicherte Verbindungen durch eine Firewall gedacht. In Proxyserver wie MS Proxy, Netscape Proxyserver oder auch WinGate ist diese Methode bereits implementiert. Der Client bestimmt durch die CONNECT-Methode samt Portangabe den Zielrechner. Der Proxyserver baut dann einen Tunnel zum angegebenen Rechner auf, und übermittelt Daten und Kommandos zwischen Client und Server.
LINK-Methode
Stellt einen Beziehung zwischen zwei Webdokumenten her. Die Methode ist nicht genauer spezifiziert und wird praktisch nicht verwendet.
UNLINK-Methode
Hebt eine mit LINK hergestellte Beziehung zwischen zwei Webdokumenten wieder auf. Auch diese Methode ist nicht genauer spezifiziert und wird praktisch nicht verwendet.
HTTP-Requests beinhalten Header-Informationen, und zwar allgemeine Informationen (General Header) sowie weitere Informationen (Request Header und Entity Header).
Die diversen Header enthalten hierbei folgende Informationen:
| Header | Beschreibung |
| General-Header | Allgemeine Informationen, z.B. Cache-Informationen (no-cache, max-age, etc.), Datum von Request und Response (inkl. Zeitzone), zwischengeschaltete Server (Forwarded). |
| Request-Header | Informationen über Dateiformate, Zeichensätze, Sprachen (Accept-Felder), Angaben über Berechtigungen von Dateizugriffen (Authorization-Feld), Angaben für den Proxy-Cache-Server (If-Modified-Since-Feld), usw. |
| Entity-Header | Informationen über die im Entity-Body übertragenen Daten, z.B. Informationen, welche Methoden auf das referenzierte Dokument angewendet werden dürfen (Allow-Feld), Angaben mit Informationen über Sprache, Länge, Type und Encoding der zu übertragenden Daten (Content-Felder), Angaben zum Änderungsdatum des Dokuments (Last-Modified-Feld), usw. |
Die für die Übertragung vorgesehenen Daten sind im Entity-Body enthalten. Dieser ist bei einem HTTP-Request jedoch in aller Regel leer.
Hier die Struktur eines Request-Headers in einer allgemeinen Form:
METHOD URL HTTP/version
General Header
Request Headers
Entity Header (optional)
[Leerzeile]
Request Entity (falls vorhanden)
|
Beispiel: Request einer HTML-Seite
GET www.domain.de/verzeichnis1/seite1.html HTTP/1.1
Date Thursday, 20-Oct-03 14:15 GMT
User-agent: Mozilla/4.6
Accept: text/html, text/plain
|
In der ersten Zeile wird vom Client die Methode (GET), im Anschluss durch ein Leerzeichen getrennt der URL (www.domain.de/verzeichnis1/seite1.html) dahinter, ebenfalls durch ein Leerzeichen getrennt und die HTTP Version (HTTP/1.1) übermittelt.
Die darauf folgenden Zeilen bzw. Felder enthalten Datum und Uhrzeit, welcher Browser verwendet wird und die vom Client akzeptierten MIME-Typen. Bei diesem Nachrichtentyp wird übrigens kein Datenbereich übermittelt.
Aufbau einer HTTP-Response
Eine HTTP-Response ist ähnlich wie ein HTTP-Request aufgebaut, beinhaltet jedoch zusätzlich eine Status-Line und den Entity-Body, der das zu übertragende Dokument enthält. Die Status-Line besteht bei der HTTP-Response aus dem Status-Code und der Reason-Phrase, die eine kurze Erläuterung zum Status-Code enthält.
Hier die Struktur eines HTTP-Response in einer allgemeinen Form:
Die Struktur einer HTTP-Antwort gleicht der einer Anfrage:
HTTP/version Status-Code Reason-Zeile
General Header
Response Header
Entity Header (optional)
[Leerzeile]
Resource Entity (falls vorhanden)
|
Wie man sieht gleicht die Struktur der eines HTTP-Request.
Bespiel: Response auf einen HTML-Request
Die vom Server kommende Antwort auf einen HTTP-Request, kann zum Beispiel, wie folgt aussehen:
HTTP/1.1 200 OK
Via: HTTP/1.1 proxy_server_name
Server: Apache/1.3
Content-type: text/html, text, plain
Content-length: 78
<html>
<head>
<title>HTTP-Test</TITLE>
</head>
<body>
<p> Ein HTTP/1.1-Absatz</p>
</body>
</html>
|
Response Codes Kategorien
Die Status Codes sind in fünf Kategorien unterteilt und die erste Stelle des dreistelligen Status-Codes definiert die Art des Response.
| Kategorie | Beschreibung |
| 1xx | Informational - Informelle Meldungen: Request erhalten, Bearbeitung wird durchgeführt |
| 2xx | Success - Erfolg: Request wurde erfolgreich erhalten, verstanden und angenommen |
| 3xx | Redirection - Weiterleiten: Weitere Aktionen müssen eingeleitet werden, damit eine Request vollständig bearbeitet werden kann |
| 4xx | Client Error - Clientfehler: Die Request enthält ungültigen Syntax oder kann nicht bearbeitet werden |
| 5xx | Server Error - Serverfehler: Der Server kann eine gültige Request nicht bearbeiten |
Auflistung der Response Codes - 1xx
100 Continue
Der Client hat einen Teil seiner Anforderung erfolgreich gesendet und soll damit fortfahren
101 Switching protocols
Der Client wünscht ein anderes und im upgrade-Header angegebenes Protokoll
Auflistung der Response Codes - 2xx
200 OK
Die Anfrage war erfolgreich. Der Client hat eine erfolgreiche Anforderung gestellt. Der Server sendet die angeforderten Informationen mit header und body.
201 Created
Der Client hat mit seiner Anforderung den Server veranlaßt ein neues Dokument bzw. einen URL zu erzeugen.
202 Accepted
Der Client hat eine Anforderung gesendet, die der Server akzeptiert, aber nicht verarbeitet.
203 Non-authoritative information
Der Client erhält vom Server Daten aus einer externen Quelle, die nicht im unmittelbaren Einflußbereich des Servers liegen.
204 No Content
Der Client hat eine erfolgreiche Anforderung gestellt, der Server sendet aber nur header und keinen body zurück. Dies ist z.B. für CGI Programme nützlich, bei denen Web-Formular-Daten ausgelesen werden, die bereits dargestellte Seite aber nicht mehr verändert wird.
205 Reset Content
Der Browser sollte die Seite - z.B. Formularseite - neu aufbauen, um eine neue Eingabe zu ermöglichen.
206 Partial Content
Der Client hat in seiner Anfrage im range-Header angegeben, dass er nur einen Teil des geforderten Dokuments haben möchte. Daten können so in Teilen verarbeitet werden.
Auflistung der Response Codes - 3xx
300 Multiple Choice
Der Client hat eine Anforderung gestellt, für die mehrere Ressourcen in Frage kommen, z.B. Dokumente in mehreren Sprachen. Im Datenbereich kann der Server ggf. diese Quellen aufschlüsseln und dem Client bzw. dem Benutzer damit eine Auswahl ermöglichen.
301 Moved Permanently
Die Client hat einen URL angefordert, die der Server nicht länger benutzt. Die neue Adresse der angeforderten Ressource ist aber bekannt und wird dem Client mitgeteilt, der auch in Zukunft nur noch diese nutzen soll.
302 Moved Temporarily (Found)
Die angeforderte Seite wurde an einen anderen Ort verschoben. Die neue URL ist in URI und Location vermerkt (veraltet - jetzt 307).
303 See other
Der Client hat eine Ressource angefordert, die an anderer Stelle zu finden ist.
304 Not Modified
Der Client hat nachgefragt, ob eine ihm bereits bekannte Ressource zwischenzeitlich verändert ist. Verneint der Server dies, so kann der Client seine lokale Kopie nutzen.
305 Use Proxy
Der Client soll die angeforderte Ressource nicht vom Server, sondern über den angegebenen Proxy beziehen.
306
Wurde in früheren Versionen benutzt, ist jetzt lediglich reserviert.
307 Moved Temporarily
Der Client hat einen URL angefordert, den der Server zur Zeit verschoben hat. Die neue Adresse der angeforderten Ressource wird dem Client mitgeteilt, diese ist jedoch nur temporär gültig und der Client soll in Zukunft die ursprüngliche Adresse nutzen.
Auflistung der Response Codes - 4xx
400 Bad Request
Der Client hat eine syntaktisch falsche Anforderung gestellt.
401 Unauthorized
Der Client hat eine Anforderung auf eine geschützte Ressource gestellt. Dies ist keine Fehlermeldung im engeren Sinne. Der Server sendet mit diesem Status-Code Informationen über die Art der notwendigen Authentifizierung. Web-Browser verlangen daraufhin in der Regel vom Benutzer die Eingabe eines Benutzernamens und eines Passworts und stellen mit diesen Angaben die Anforderung erneut. Schlägt dies dann fehl, so antwortet der Server mit Code 403.
402 Payment required
Der Client hat eine kostenpflichtige Ressource angefordert. Dieser Statuscode ist (noch) nicht HTTP-Bestandteil.
403 Forbidden
Der Client hat eine Anforderung gestellt, die der Server ohne Angaben von Gründen verweigert.
404 Not found
Der Client hat ein Dokument angefordert, das an der angegebenen Stelle nicht existiert.
405 Method not allowed
Der Client hat eine Methode benutzt, die der Server an dieser Adresse nicht erlaubt (z.B. GET statt POST)
406 Not acceptable
Der Client hat ein Dokument angefordert, dessen Format er nach eigenen Angaben im Accept Header nicht unterstützt.
407 Proxy authentication required
Der Client hat eine Anfrage gestellt, die vom Proxy autorisiert werden muss, bevor er ihn weiterleiten kann.
408 Request time-out
Der Client hat in der vom Server vorgegebenen Zeit keine vollständige Anfrage stellen können. Der Server beendet die Verbindung.
409 Conflict
Der Client hat eine Anfrage gestellt, die der Server wegen eines Konflikts, z.B. mit einem anderen Request, nicht wie gewünscht verarbeiten kann bzw. wird. Nähre Angaben sind im Datenbereich enthalten.
410 Gone
Der Client hat einen URL angefordert, der auf dem Server nicht mehr existiert (siehe auch 301, 307 und 404)
411 Length required
Der Client hat an den Server Daten übermittelt, den dieser nicht ohne die im Header Content-length angegebene Größe akzeptiert.
412 Precondition failed
Der Client hat eine oder mehrere If... - Header übermittelt und die darin formulierten Bedingungen konnten nicht erfüllt werden.
413 Request Entity Too Large
Der Client hat eine Anforderung gestellt, die dem Server zu groß ist, z.B. beim Upload von Dateien. Der Server verweigert die Verarbeitung.
414 Request URL too long
Der Client hat einen URL übermittelt, der dem Server zu groß ist, z.B. bei der Übergabe von Formularwerten mittels GET. Der Server verweigert die Verarbeitung.
415 Unsupported Media type
Der Client hat Daten übermittelt, die der Server nicht unterstützt.
416 Request range not satisfiable
Der Client hat in seiner Anfrage im range-Header einen Teilbereich des Dokuments angegeben, der nicht existiert (siehe 206).
417 Expectation failed
Der Client hat im Expect-Header Wünsche geäußert, die der Server nicht erfüllen kann oder will.
Auflistung der Response Codes - 5xx
500 Internal Server Error
Der Server hat bei sich einen Fehler entdeckt, z.B. durch eine fehlerhafte Konfiguration oder durch ein abgestürztes CGI-Programm. In den Log-Files des Servers sollten sich genauere Angaben finden.
501 Not Implemented
Der Server kann die Anforderung des Clients nicht ausführen, weil die nicht unterstützt wird.
502 Bad Gateway
Der Server oder eher der Proxy hat formal ungültige Antworten von einem anderen Server oder Proxy bekommen.
503 Service unavailable
Der Server kann die Anforderung des Clients momentan nicht ausführen. Gegebenenfalls gibt der Server in einem Retry-After-Header zurück, wann der Dienst wieder zur Verfügung steht.
504 Gateway time-out
Der Client hat selbst eine Anfrage an einen Gateway oder Proxy gestellt, die innerhalb der auf dem Server definierten Zeit nicht beantwortet wurde (siehe 408)
505 HTTP version not supported
Der Server unterstützt die in der Anforderung des Clients angegebene HTTP-Version nicht. Im Datenbereich sollte ein Grund dafür angegeben sein.
File Transfer Protocol (FTP)
FTP ist als MIL-STD 1780 spezifiziert und ermöglicht einen vom Betriebssystem unabhängigen Austausch von Dateien zwischen zwei entfernten Rechnern. FTP setzt auf TCP auf und nutzt den Port 20 für die FTP Datenverbindung bzw. Port 21 für FTP Steuerverbindungen. Der FTP-Client hat die Möglichkeit, zwischen verschiedenen Datenformaten zu wählen, z.B. ASCII oder Binär.
Telnet
Das Protokoll Telnet ist im MIL-STD 1782 spezifiziert und ermöglicht den Zugriff auf die am Netz angeschlossenen Rechner in Form einer Terminalsitzung. Hierzu wird eine TCP-Verbindung über Port 23 aufgebaut. Telnet ermöglicht den Zugriff auf die Resourcen eines entfernten Rechners, wobei der Rechner des Clients als Terminal dient. Bei einer Telnet-Verbindung arbeitet der Client so, als wäre er direkt an den entfernten Rechner angeschlossen, dessen Rechnerleistung und dessen Programme er nutzt.
Simple Mail Transfer Protocol (SMTP)
SMTP ist ein auf TCP aufgesetztes einfaches Protokoll für den Austausch von elektronischer Post zwischen verschiedenen Rechnern. Der durch das SMTP-Protokoll geregelte Austausch von E-Mails läuft hierbei wie folgt ab:
Der SMTP-Client baut eine TCP-Verbindung zum Port 25 des SMTP-Servers auf und wartet auf die Reaktion des Servers. Der SMTP-Server senden eine Textzeile, über die er sich identifiziert und mitteilt, ob er bereit ist, Post zu empfangen. Antwortet der Server nicht, wir die Verbindung vom SMTP-Client aufgelöst.
Antwortet der SMTP-Server, gibt der SMTP-Client an, von wem die Nachricht stammt und an wen sie gesendet werden soll. Falls der Empfänger existiert, gibt der Server das Signal zum Senden der E-Mail. Der Client sendet anschliessend die E-Mail, was vom Server bestätigt werden muss. Nach dem Austausch der E-Mails wird die Verbindung wieder abgebaut.
Post Office Protocol (POP)
Bei POP handelt es sich um das Standardprotokoll, mit dem derzeit E-Mail-Clients Nachrichten vom Server lesen. POP wurde bereits 1984 im Zusammenhang mit TCP/IP definiert. Aktuell ist derzeit die Version 3 (POP3).
Ein POP3-fähiger E-Mail-Client stellt die Verbindung zum POP3-Server her und löst die Übertragung der Nachrichten aus. Mit POP3 ist er möglich zu bestimmen, ob gelesene Nachrichten auf dem Server verbleiben oder nach der Übertragung gelöscht werden sollen. Die Löschung einer Nachricht ohne vorherige Übertragung ist ebenfalls möglich.
Internet Message Access Protocol (IMAP)
IMAP ist ein erweitertes E-Mail-Protokoll, welches wesentlich leistungsfähiger ist als POP3. Es wurde entwickelt, um Nachrichten nach Bedarf übertragen zu können. Unter Verwendung von IMAP kann - anders als bei POP3 - ausgewählt werden, welche Daten übertragen werden sollen. Dazu werden zunächst nur die Kopfzeilen übertragen.
Darüber hinaus können mit IMAP hierarchische Mailboxen direkt auf dem Server eingerichtet werden. Unter IMAP ist auch der Zugriff auf verschiedene Mailboxen während einer Verbindung möglich.
IMAP gestattet dem Client auch die Veränderung des Status einer Nachricht, um beispielsweise gelesene Mails als ungelesen zu markieren und umgekehrt sowie das Speichern, Kopieren oder Löschen von Nachrichten direkt auf dem Server, ohne dass diese zuvor dem Client übermittelt werden müssen. Weitere Möglichkeiten von IMAP sind Suchoptionen auf dem Server zur Selektion von Nachrichten.
|
|
|
|
|
|
|
SELFPHP
SELFPHP - Damir Enseleit, info@selfphp.de, Impressum, Kontakt