Mit Google fortfahren
HTTP einfach erklärt: Requests, Responses und HTTPS
HTTP ist ein Protokoll, mit dem ein Client Ressourcen bei einem Server anfordert und der Server darauf antwortet. Dein Browser nutzt diesen geregelten Austausch zum Beispiel, um Texte und Bilder einer Webseite abzurufen.
Du lernst, einen HTTP-Austausch zu verfolgen, Nachrichtenbestandteile zuzuordnen und typische Statuscodes zu deuten.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Vom Klick zur angezeigten Webseite
Wenn du eine Adresse eingibst oder auf einen Link klickst, beginnt ein Austausch zwischen zwei Rollen:
Client
Ein Client ist ein Programm, das Daten oder Dienste anfordert. Beim Surfen übernimmt meist dein Browser diese Rolle.
Server
Ein Server stellt Ressourcen oder Dienste bereit und beantwortet Anfragen von Clients. Ein Webserver kann beispielsweise eine Webseite oder ein Bild liefern.
HTTP bedeutet Hypertext Transfer Protocol. Ein Protokoll legt Regeln fest, nach denen Programme Nachrichten austauschen. HTTP gehört zur Anwendungsschicht: Es beschreibt, was der Client anfordert und wie der Server darauf antwortet. Die eigentliche Übertragung kann darunter beispielsweise TCP übernehmen.
Der Austausch folgt einem wiederkehrenden Muster:
- Eine Nutzeraktion löst eine Anfrage aus.
- Der Browser sendet einen Request an den Webserver.
- Der Server verarbeitet den Request.
- Der Server sendet eine Response zurück.
- Der Browser verarbeitet die Antwort und stellt den Inhalt dar.
Request
Ein Request ist die HTTP-Anfrage eines Clients an einen Server.
Response
Eine Response ist die HTTP-Antwort des Servers auf einen Request.
Du rufst eine Seite mit einem Produktbild auf. Zuerst fordert der Browser das Seitendokument an. Erkennt er darin das eingebundene Bild, kann er dafür einen weiteren Request senden. Eine sichtbare Webseite entsteht daher häufig durch mehrere Request-Response-Zyklen.
Der Client fragt an, der Server antwortet. Eingebundene Ressourcen können weitere Anfragen auslösen.
So sind HTTP-Nachrichten aufgebaut
Requests und Responses bestehen typischerweise aus drei Bereichen:
- Die Start-Line nennt die wichtigsten Angaben zur Nachricht.
- Die Header enthalten zusätzliche Angaben als Name-Wert-Paare.
- Der optionale Body transportiert Nutzdaten.
Die Start-Line eines Requests enthält die Methode, das Ziel der gewünschten Ressource und die HTTP-Version. Ein vereinfachtes Beispiel lautet: GET /produkte HTTP/1.1.
Danach können Header folgen. Host: beispiel.test bezeichnet etwa den Zielhost. Ein leerer Request-Body ist möglich, wenn keine zusätzlichen Daten übertragen werden müssen.
Bei einer Response sieht die Start-Line anders aus. Sie nennt die HTTP-Version und einen Statuscode, beispielsweise HTTP/1.1 200 OK. Header können den Inhalt näher beschreiben. Im Body kann anschließend das angeforderte Seitendokument stehen.
Ein Browser sendet gedanklich diese Angaben:
- Start-Line:
GET /bilder/logo.png HTTP/1.1 - Header:
Host: beispiel.test - Body: nicht erforderlich
Der Server antwortet:
- Start-Line:
HTTP/1.1 200 OK - Header: Angabe zum Inhaltstyp
- Body: Daten des Bildes
Der entscheidende Unterschied liegt in der Aufgabe der Nachrichten: Der Request beschreibt die Anforderung, die Response beschreibt das Ergebnis und kann die Ressource liefern.
Die Start-Line gibt die Richtung vor, Header beschreiben die Nachricht und der Body enthält gegebenenfalls Nutzdaten.
Methoden und Statuscodes richtig deuten
Eine HTTP-Methode beschreibt, was der Client mit seinem Request erreichen möchte.
GETfordert eine Ressource an, etwa eine Webseite oder ein Bild.POSTübermittelt Daten an den Server, etwa eingegebene Anmeldedaten.
POST bedeutet nicht automatisch, dass die Daten in einer Datenbank gespeichert werden. Aus dem hier behandelten Grundmodell folgt nur: Der Client übermittelt Daten, die der Server anschließend verarbeitet.
Die Response enthält einen dreistelligen Statuscode. Die erste Ziffer ordnet den Code einer Klasse zu. Für typische Webaufrufe sind unter anderem diese Codes wichtig:
| Code | Bedeutung |
|---|---|
200 | Die Anfrage wurde erfolgreich bearbeitet. |
301 | Die Ressource ist dauerhaft unter einer anderen Adresse erreichbar. |
401 | Für den Zugriff fehlt die erforderliche Authentifizierung. |
404 | Die angeforderte Ressource wurde nicht gefunden. |
Du öffnest eine vorhandene Artikelseite. Der Browser sendet einen GET-Request, und der Server antwortet mit 200 sowie dem Artikel im Body.
Vertippst du dich im Pfad und existiert dort keine Ressource, kann der Server mit 404 antworten. Der Server hat dann reagiert, aber nicht die gewünschte Ressource gefunden.
Ein Statuscode beschreibt das Ergebnis der Anfrage. 404 bedeutet daher nicht, dass überhaupt keine Kommunikation stattgefunden hat.
Warum HTTP allein keine Erinnerung hat
HTTP ist zustandslos. Das bedeutet: Jede Anfrage wird aus Sicht des Protokolls unabhängig behandelt. HTTP erinnert sich nach einem abgeschlossenen Austausch nicht von selbst daran, dass mehrere Requests vom selben Nutzer stammen.
Websites können dich trotzdem wiedererkennen. Dafür benötigen sie zusätzliche Mechanismen wie Cookies.
Cookie
Ein Cookie ist eine zusätzliche Information, die eine Website zur Wiedererkennung verwenden kann. Eine Response kann Angaben zum Setzen eines Cookies enthalten; bei späteren Anfragen kann der Browser passende Cookie-Informationen wieder mitsenden.
Du meldest dich auf einer Website an. Der POST-Request übermittelt deine Anmeldedaten. Damit spätere Requests einer bestehenden Anmeldung zugeordnet werden können, kann die Website Cookie-Informationen verwenden. Die Erinnerung stammt dann nicht aus dem zustandslosen HTTP-Grundmodell allein.
Zustandslos bedeutet nicht, dass eine Website niemals etwas wiedererkennen kann. Es bedeutet, dass HTTP jede Anfrage zunächst als eigenständigen Austausch behandelt.
Was HTTPS zusätzlich schützt
HTTPS verwendet denselben grundlegenden Request-Response-Ablauf wie HTTP, ergänzt ihn aber um Schutzmechanismen. Das S steht für secure.
Die Kommunikation zwischen Client und Server wird verschlüsselt. Dadurch sollen Dritte die übertragenen Daten nicht einfach mitlesen können. Außerdem authentifiziert sich der Webserver gegenüber dem Client.
Bei einer Anmeldung werden Daten vom Browser an den Server übertragen. Mit HTTPS wird dieser Übertragungsweg verschlüsselt. Request, Response, Methoden und Statuscodes bleiben weiterhin Teile des Austauschs.
HTTPS ersetzt HTTP nicht durch einen völlig anderen Ablauf. Es schützt den grundlegenden HTTP-Austausch zusätzlich durch Verschlüsselung und Serverauthentifizierung.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- HTTP-Kommunikation
- Client sendet Request
- Server sendet Response
- Nachricht enthält Start-Line, Header und optionalen Body
- GET fordert Ressourcen an
- POST übermittelt Daten
- Statuscode beschreibt das Ergebnis
- Cookies ergänzen Wiedererkennung
- HTTPS schützt die Übertragung
Abschluss-Check
Du hast den Kern verstanden, wenn du bei einem Webaufruf Client und Server, Request und Response, Nachrichtenbestandteile sowie einen Statuscode begründet zuordnen kannst.