Folge uns

Folge uns auf Facebook Folge uns auf Twitter Folge uns auf Google Abonniere unseren RSS-Feed Abonniere unseren Newsletter

Das Buch zu dieser Webseite

Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel

Käufer der Netzwerktechnik-Fibel Kundenmeinung:
Die Netzwerktechnik-Fibel ist sehr informativ und verständlich. Genau das habe ich schon seit langem gesucht.

Netzwerktechnik-Fibel
jetzt bestellen!

 

Die Netzwerktechnik-Fibel ist im iBookstore erhältlich

Die Netzwerktechnik-Fibel für Amazon Kindle erhältlich

Die Netzwerktechnik-Fibel bei Google Play erhältlich

Netzwerktechnik-Fibel als PDF-Datei ohne DRM

Das Buch zu dieser Webseite

KommunikationstechnikFibel

Die Kommunikationstechnik-Fibel

Käufer der Kommunikationstechnik-Fibel Kundenmeinung:
Die Kommunikationstechnik-Fibel ist sehr informativ und verständlich. Genau das habe ich schon seit langem gesucht. Endlich mal ein Buch, das kurz und bündig die moderne Informationstechnik beleuchtet.

Kommunikationstechnik-Fibel
jetzt bestellen!

 

Die Kommunikationstechnik-Fibel ist im iBookstore erhältlich

Die Kommunikationstechnik-Fibel für Amazon Kindle erhältlich

Kommunikationstechnik-Fibel als eBook von Google Play Store

Kommunikationstechnik-Fibel als PDF-Datei ohne DRM

HTTP - Hypertext Transfer Protocol

HTTP ist das Kommunikationsprotokoll im World Wide Web (WWW). Die wichtigsten Funktionen sind Dateien vom Webserver anzufordern und in den Browser zu laden. Der Browser übernimmt dann die Darstellung von Texten und Bilder und kümmert sich um das Abspielen von Audio- und Video-Daten.

Das Hypertext Transfer Protocol (HTTP) im Schichtenmodell

Schicht Dienste / Protokolle / Anwendungen
Anwendung HTTP IMAP DNS SNMP
Transport TCP UDP
Internet IP (IPv4 / IPv6)
Netzzugang Ethernet, ...

Wie funktioniert HTTP?

Wie HTTP funktioniert
Die Kommunikation findet nach dem Client-Server-Prinzip statt. Der HTTP-Client (Browser) sendet seine Anfrage (HTTP-Request) an den HTTP-Server (Webserver/Web-Server). Dieser bearbeitet die Anfrage und schickt seine Antwort (HTTP-Response) zurück. Nach der Antwort durch den Server ist diese Verbindung beendet. Typischerweise finden gleichzeitig mehrere HTTP-Verbindungen statt.

Die Kommunikation zwischen Client und Server findet auf Basis von Meldungen im Text-Format statt. Die Meldungen werden standardmäßig über TCP auf dem Port 80 (Richtung Server) abgewickelt. Die Meldungen werden Request und Response genannt und bestehen aus einem Header und den Daten. Der Header enthält Steuerinformationen. Die Daten entsprechen einer Datei, die der Server an den Client schickt oder im umgekehrten Fall Nutzereingaben, die der Client zur Verarbeitung an den Server übermittelt. Dateien kann der Server aber nur mit Hilfe eines zusätzlichen Programms oder Skriptes entgegennehmen.

HTTP-Adressierung

Damit der Server weiß, was er dem HTTP-Client schicken soll, adressiert der HTTP-Client eine Datei, die sich auf dem HTTP-Server befinden muss. Dazu wird vom HTTP-Client ein URL (Uniform Resource Locator) im HTTP-Header an den HTTP-Server übermittelt:

http://Servername.Domainname.Top-Level-Domain:TCP-Port/Pfad/Datei
z. B. http://www.elektronik-kompendium.de:80/sites/kom/0902231.htm

Der URL besteht aus der Angabe des Transport-Protokolls "http://". Dann folgt der Servername (optional) und der Domainname mit anschließender Top-Level-Domain (TLD). Die Angabe zum TCP-Port ist optional und nur erforderlich, wenn die Verbindung über einen anderen Port, als dem Standard-Port 80 abgewickelt wird. Pfade und Dateien sind durch den Slash "/" voneinander und von der Server-Adresse getrennt. Folgt keine weitere Pfad- oder Datei-Angabe schickt der Server die Default-Datei der Domain. Sind Pfad und/oder Datei angegeben, schickt der HTTP-Server diese Datei zurück. Ist diese Datei nicht existent, versucht er es mit einer Alternative. Gibt es keine, wird die Standard-Fehlerseite (Error 404) an den HTTP-Client übermittelt.

HTTP-Request

Der HTTP-Request ist die Anfrage des HTTP-Clients an den HTTP-Server. Ein HTTP-Request besteht aus den Angaben Methode, URL und dem Request-Header. Die häufigste Methoden sind GET und POST. Dahinter folgt durch ein Leerzeichen getrennt der URL und die verwendete HTTP-Version. In weiteren Zeilen folgt der Header und bei der Methode POST durch eine Leerzeile (!) getrennt die Formular-Daten.

HTTP-Request-Header

Beispiel für einen HTTP-Request-Header

Im folgenden wird der HTTP-Request-Header dargestellt, den der Browser an den Webserver schickt.

GET / HTTP/1.1
Host: www.elektronik-kompendium.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP-Methoden

Jeder HTTP-Request durch den Client wird durch die Angabe einer Methode eingeleitet. Die Methode weißt den Server an, was er mit dem Request machen soll. Die HTTP Version 1.1 sieht die folgenden Methoden vor:

MethodeBeschreibung
GET Die GET-Methode dient der Anforderung einer HTML-Datei oder einer anderen Quelle. Die Quelle wird durch der URL adressiert. Im Header lassen sich Bedingungen hinterlegen, die die Netzlast reduzieren oder einen unterbrochenen Datentransfer wieder aufnehmen.
Über GET lassen sich auch Formular-Daten übermitteln. Diese werden in codierter Form der URL angehängt. URL und Formular-Daten sind durch ein Fragezeichen (?) voneinander getrennt.
POST Die POST-Methode funktioniert ähnlich wie die GET-Methode. POST wird jedoch zur Übermittlung von Formular-Daten an ein Programm oder Skript verwendet. Die Daten werden im Entity-Bereich getrennt durch eine Leerzeile vom Header übertragen.
HEAD Die HEAD-Methode fordert den Response-Header an, der üblicherweise vom Server nach einem GET-Request übermittelt wird.
PUT Diese Methode erlaubt das Erstellen oder Ändern von Dateien auf dem Server.
OPTIONS Die OPTIONS-Methode dient zur Ermittlung von Kommunikationsoptionen durch den HTTP-Client. Es werden jedoch keinerlei Aktionen ausgeführt oder Daten übertragen.
DELETE Diese Methode führt zur Löschung der Datei, die durch die URL adressiert ist.
TRACE Die TRACE-Methode dient der Verfolgung von HTTP-Requests, die zwischen Client und Server über einen oder mehrere Proxy-Server laufen.
Im Header-Feld "Via" des HTTP-Responses sind alle zwischengeschaltete Server protokolliert.
CONNECT Durch die CONNECT-Methode baut ein Proxy-Server einen Tunnel zum angegebenen Rechner auf und übermittelt darin Daten und Kommandos zwischen Client und Server.

HTTP-Response

Der HTTP-Response ist die Antwort des HTTP-Servers an den HTTP-Client. Der HTTP-Response besteht aus der verwendeten HTTP-Version, dem Status-Code der Responses und der Klartext-Meldung des Status-Codes. In den anschließenden Zeilen folgt der Header und durch eine Leerzeile (!) getrennt die HTML-Datei.

HTTP-Response-Header

Beispiel für einen HTTP-Response-Header

Im folgenden wird der HTTP-Response-Header dargestellt, den der Webserver an den Browser schickt und dem eine Datei folgt. Im folgenden wird nur die HTML-Datei zurück geliefert. Aufgrund Referenzierungen in der HTML-Datei schickt der Browser weitere HTTP-Requests an den Server. Er fordert weitere Dateien an. Zum Beispiel CSS, Javascript, Bilder, Audio oder Video.

HTTP/1.x 200 OK
Date: Tue, 08 Sep 2009 15:47:06 GMT
Server: Apache/1.3.34 Ben-SSL/1.55
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

HTTP-Response-Codes / HTTP-Status-Codes

Die Antwort des HTTP-Servers an den HTTP-Client enthält in der ersten Zeile den Status-Code und die Klartext-Meldung des HTTP-Responses, verursacht durch den HTTP-Request. Der Status-Code ist eine 3stellige Nummer, die dem HTTP-Client Informationen über die Verfügbarkeit der angeforderten Daten mitteilt. Z. B. wird über den Status-Code eine Fehlermeldung übermittelt.
Die Status-Codes sind in 5 Gruppen unterteilt, die über den HTTP-Response eine Grundaussage treffen.

Status-CodesBeschreibung
100-199 Status-Codes im 100er Bereich sind Meldungen informeller Art.
200-299 Status-Codes im 200er Bereich informieren den Client über eine erfolgreiche Anfrage.
300-399 Status-Codes im 300er Bereich deuten auf eine Umleitung hin und weisen den Client an, seine Anfrage auf das zurückgelieferte Ziel zu wiederholen oder den Benutzer die Entscheidung treffen zu lassen.
400-499 Status-Codes im 400er Bereich sind Fehlermeldungen, die vom Client ausgelöst werden. Meistens handelt es sich um eine Anfrage, die vom Server nicht beantwortet werden kann.
500-599 Status-Codes im 500er Bereich sind Fehlermeldungen, die vom Server direkt ausgelöst werden.

Liste der HTTP-Response-Codes

Status-Code Meldung EN Meldung DE HTTP-Version
100 Continue Weiterleitung 1.1
101 Switching Protocols Protokoll ändern 1.1
200 OK Alles in Ordnung / Standardmeldung 1.0
201 Created Erfolgreich erstellt 1.0
202 Accepted Akzeptiert 1.0
203 Non-Authoritative Information Die Daten sind von einem anderen Server 1.0
204 No Content Ausführung ohne Feedback 1.0
205 Reset Content Datenversendung nicht möglich 1.1
206 Partial Content Datenversendung in mehreren Teilen 1.1
300 Multiple Choices Datei ist mehrfach vorhanden 1.0
301 Moves Permanently Datei ist dauerhaft verschoben 1.0
302 Moves Temporarily Datei ist vorübergehend verschoben 1.0
303 See Other Datei ist an einem andern Ort 1.0
304 Not Modified Datei ist unverändert 1.0
305 Use Proxy Datei über Proxy anfordern 1.0
400 Bad Request Keine Bearbeitung 1.0
401 Unauthorized Nicht autorisiert 1.0
402 Payment Required Kostenpflichtige Daten 1.0
403 Forbidden Zugriff verweigert 1.0
404 Not Found Nicht gefunden 1.0
405 Method not Allowed Methode nicht erlaubt 1.1
406 Not Acceptable Anfrage nicht akzeptiert 1.1
407 Proy Authorisation Required Nicht autorisierter Proxy 1.1
408 Request Timeout Zeitüberschreitung 1.1
409 Conflict Zugriff gesperrt 1.1
410 Gone Daten wurden verschoben 1.1
411 Length Required Längenangaben erforderlich 1.1
412 Precondition Failed Vorbedingungen nicht erfüllt 1.1
413 Request Entity Too Long Anfrage zur Bearbeitung zu lang 1.1
414 Request URL Too Long Adresse zu lang 1.1
415 Unsupported Media Type Nicht unterstützter MIME-Type 1.1
416 Requested Range Not Satisfiable Angegebener Bereich ist falsch 1.1
417 Expectation Failed Vorraussetzung ist nicht erfüllt 1.1
500 Internal Server Error Interner Server Fehler 1.0
501 Not Implemented Nicht implementierte Anfrage 1.0
502 Bad Gateway Gatewayfehler 1.0
503 Service Unavailable Server ueberlastet 1.0
504 Gateway Timeout Zeitüberschreitung Gateway 1.1
505 HTTP Version not supported Nicht unterstützte HTTP-Version 1.1

Erläuterung der häufig auftretenden Status-Codes

Status-CodeBeschreibung
200 Dieser Status-Code wird bei jeder erfolgreich bearbeiteten Anfrage übermittelt.
401 Zugriffe auf passwortgeschützte Bereiche eines Servers werden dem Client mit diesem Code verwehrt. Nur wenn der Client sich nach diesem Code autorisiert, bekommt er Zugriff auf die Dateien und Verzeichnisse.
(Siehe unter HTTP-Authentifizierung)
404 Immer dann, wenn keine HTML-Datei zurückgeliefert werden kann, dann erfolgt die Rückmeldung eines 404-Errors. Meistens liefert der Server eine Standard-Fehlerseite zurück.
500 Ein HTTP-Server kann nicht nur HTML-Dateien schicken, sondern auch Programme und Skripte ausführen, die HTML-Daten zurückliefern. Kommt es bei der Ausführung zu einem Fehler, bricht der Server den Vorgang ab und liefert diese Fehlermeldung zurück.

HTTP-Authentifizierung

Manche Informationen und Daten auf einem Webserver sind nicht für jedermann bestimmt und sollen nur einer begrenzten Zahl von Personen zugänglich sein. Dazu gibt es das Basic-HTTP-Authentication-Schema, das einen Benutzernamen und ein Passwort für die Authentifizierung verwendet.
Der Ablauf der Authentifizierung beginnt mit einem normalen HTTP-Request durch den HTTP-Client. Ist der Zugriff auf das angefragte Verzeichnis durch Basic-HTTP-Authentication beschränkt, sendet der HTTP-Server den HTTP-Response mit einem WWW-Authentication-Header-Feld und dem Status-Code 401 (Nicht autorisiert). Der HTTP-Client wird damit zum Senden von Benutzernamen und Passwort aufgefordert. Der HTTP-Client öffnet dann ein Fensterchen, das den Benutzer zur Eingabe von Benutzername und Passwort auffordert. Nach abgeschlossener Eingabe schickt der HTTP-Client die Zugangsdaten an den Server. Sind die Daten korrekt, wird der Zugriff auf die angeforderten Inhalte freigegeben und vom Server ausgeliefert. Bei jedem erneuten HTTP-Request werden die Anmeldedaten erneut vom Client an den Server übermittelt.
Sind die Zugangsdaten inkorrekt, hat der Benutzer mehrmals die Möglichkeit für eine korrekte Eingabe zu sorgen. Gehen diese Anfragen alle schief, wird ein Status-Code von 403 und einer entsprechenden HTML-Datei vom Server geschickt, die den Besucher auf den fehlerhaften Zugriff des passwortgeschützten Bereichs hinweist.
Der Authentifizierungsvorgang mit Basic-HTTP-Authentication ist alles andere als sicher. Die Anmeldedaten werden in Klartext und damit protokollierbar und abhörbar übertragen. Um diese Schwäche zu vermeiden empfiehlt sich das Digest Access Authentication. Dieses benutzt mehrere Parameter zur Verschlüsselung.

HTTP-ABR - HTTP Adaptive Bit Rate

HTTP-ABR ist ein Verfahren, um Videostreaming per HTTP zu übertragen. Eigentlich ist HTTP ein Kommunikationsprotokoll, dass einzelne Dateien überträgt, die irgendwann vollständig übertragen sind. Beim Videostreaming findet eine Ende der Übertragung erst sehr viel später statt. Hier gibt es im Prinzip kein Ende, es sei denn Sender und Empfänger beenden die Verbindung.
Beim Videostreaming kommen jedoch noch weitere besondere Anforderungen zum Tragen, um dem Nutzer das multimediale Erlebnis so angenehm wie möglich zu machen.
Die Anforderungen an das Video-Material können je nach Teilnehmer seht unterschiedlich sein. So kann die Bildschirmgröße von Smartphone bis Full-HD-TV reichen. Und die Bandbreite von vielleicht 100 kBit/s bis 100 MBit/s. Konsequenterweise müsste der HTTP-Server die unterschiedlichen Qualitäts- und Geschwindigkeitsanforderungen berücksichtigen. Mit HTTP-ABR lässt sich die Übertragungsrate an die verfügbare Bandbreite und unterschiedliche Auflösungen anpassen. Dazu ist auf beiden Seiten ein HTTP-ABR-fähiger Client bzw. Server notwendig.
Neben dem normalen HTTP-ABR gibt es noch verschiedene propritäre Varianten.

Aufgaben und Übungen mit dem Raspberry Pi

Für den Raspberry Pi gibt es verschiedene Webserver. Am einfachsten ist es mit dem "lighttpd". Hier muss man am wenigsten konfigurieren und die Installation ist effektiv mit einem Befehl auf der Kommandozeile erledigt.

Übersicht: HTTP

Weitere verwandte Themen:

Die Netzwerktechnik-Fibel

Die Netzwerktechnik-Fibel ist im iBookstore erhältlich Die Netzwerktechnik-Fibel für Amazon Kindle erhältlich