Was ist das HTTP-Protokoll?

Client-Server-Modell

HTTP folgt einem Client-Server-Modell, bei dem der Client eine Anfrage an den Server sendet und der Server mit der angeforderten Ressource antwortet. Der Client ist normalerweise ein Webbrowser und der Server ein Computer, der eine Website hostet. Wenn Sie eine URL in die Adressleiste Ihres Browsers eingeben, sendet der Browser einen HTTP-Request an den Server, der dann die angeforderte Webseite als HTTP-Response zurücksendet.

Hier ist ein Beispiel, wie das Client-Server-Modell funktioniert:

1. Sie geben https://www.example.com in Ihren Webbrowser ein.
2. Der Browser (Client) sendet einen HTTP-Request an den Server, der www.example.com hostet.
3. Der Server verarbeitet den Request und sendet einen HTTP-Response mit dem HTML-Inhalt der angeforderten Webseite zurück.
4. Der Browser erhält den Response und zeigt den HTML-Inhalt zur Ansicht an.

HTTP-Request- und Response-Format

HTTP verwendet ein Klartext-Format für Requests und Responses, was es Entwicklern leicht macht, damit zu arbeiten. Jeder HTTP-Request und -Response besteht aus einem Header und einem optionalen Body. Der Header enthält Daten über den Request oder Response, wie den Content-Type, während der Body die eigentlich übertragenen Daten enthält.

Ein HTTP-Request umfasst normalerweise folgende Komponenten:

Ein HTTP-Response umfasst folgende Komponenten:

Zustandsloses Protokoll

HTTP ist ein zustandsloses Protokoll, was bedeutet, dass jedes Request-Response-Paar unabhängig von vorherigen oder nachfolgenden ist. Dies ermöglicht Skalierbarkeit und Flexibilität in Webanwendungen, da Server mehrere Requests von verschiedenen Clients gleichzeitig bearbeiten können, ohne vorherige Interaktionen nachverfolgen zu müssen.

Viele Webanwendungen erfordern jedoch die Aufrechterhaltung eines Zustands zwischen Requests, wie Benutzer-Authentifizierung oder Warenkorb-Daten. Um dies zu adressieren, verwenden Entwickler Techniken wie Cookies, Sessions und Tokens, um Zustandsinformationen zwischen Client und Server zu speichern und zu übertragen.

HTTP-Request-Methoden

HTTP-Request-Methoden, auch als HTTP-Verben bekannt, zeigen die Aktion an, die mit der Ressource ausgeführt werden soll. Die am häufigsten verwendeten HTTP-Methoden sind:

1. GET: Ruft eine Ressource vom Server ab. GET-Requests sollten nur Daten abrufen und nicht ändern.

   • Beispiel: Abrufen einer Webseite, Abrufen von Daten von einem API-Endpoint oder Herunterladen einer Datei.
   • Beispiel-URL: https://api.example.com/users/123

2. POST: Sendet Daten zur Verarbeitung an den Server. Diese Methode wird oft beim Erstellen einer neuen Ressource oder beim Senden von Daten an einen Server verwendet.

   • Beispiel: Absenden eines Formulars, Erstellen eines neuen Benutzerkontos oder Posten eines Kommentars in einem Blog.
   • Beispiel-URL: https://api.example.com/users

3. PUT: Aktualisiert eine Ressource auf dem Server. Wenn die Ressource nicht existiert, kann der Server sie erstellen.

   • Beispiel: Aktualisieren eines Benutzerprofils oder Ersetzen eines Dokuments.
   • Beispiel-URL: https://api.example.com/users/123

4. DELETE: Entfernt eine Ressource vom Server.

   • Beispiel: Löschen eines Benutzerkontos, Entfernen eines Blog-Posts oder Stornieren einer Bestellung.
   • Beispiel-URL: https://api.example.com/users/123

Andere weniger verwendete HTTP-Methoden umfassen HEAD, OPTIONS, PATCH und TRACE.

HTTP-Request-Headers

HTTP-Request-Headers ermöglichen es dem Client, zusätzliche Informationen über den Request hinzuzufügen. Headers sind Schlüssel-Wert-Paare, die Metadaten über den Request bereitstellen und dem Server helfen zu verstehen, wie er verarbeitet werden soll. Einige häufige HTTP-Request-Headers sind:

1. User-Agent: Gibt die Client-Anwendung an, die den Request sendet, wie einen Webbrowser oder eine mobile App.

   • Beispiel: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

2. Accept: Zeigt die akzeptablen Content-Types für den Response an, wie text/html, application/json oder image/jpeg.

   • Beispiel: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

3. Content-Type: Gibt den Typ der Daten im Request-Body an, wie application/x-www-form-urlencoded oder application/json.

   • Beispiel: Content-Type: application/json

4. Authorization: Enthält Anmeldeinformationen zur Authentifizierung des Clients, wie ein Bearer-Token oder Basic-Authentifizierung.

   • Beispiel: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Andere Headers können Informationen über Caching, Cookies und andere Aspekte des Requests geben.

HTTP-Request-Body

Der HTTP-Request-Body enthält vom Client an den Server gesendete Daten. Er wird normalerweise bei POST- und PUT-Requests verwendet, um Daten zu senden, die auf dem Server hinzugefügt oder aktualisiert werden.

Der Request-Body kann verschiedene Datentypen enthalten, wie:

1. Formulardaten: Schlüssel-Wert-Paare, die beim Absenden von HTML-Formularen gesendet werden.

   • Beispiel: username=john_doe&password=secret

2. JSON (JavaScript Object Notation): Ein leichtgewichtiges Datenformat, das häufig in Web-APIs verwendet wird.

   • Beispiel:

     {
       "name": "John Doe", 
       "age": 30,
       "email": "john@example.com"
     }
     

3. XML (eXtensible Markup Language): Eine Markup-Sprachezur Kodierung von Dokumenten in einem Format, das sowohl für Menschen als auch für Maschinen lesbar ist.

   • Beispiel:

     <user>
       <name>John Doe</name>
       <age>30</age>
       <email>john@example.com</email>
     </user>
     

4. Binärdaten: Dateien, Bilder oder andere Nicht-Text-Daten.

   • Beispiel: Hochladen eines Profilbilds oder eines PDF-Dokuments.

Der Content-Type-Header wird verwendet, um das Format der Daten im Request-Body anzugeben, damit der Server weiß, wie er sie verarbeiten soll.

HTTP-Status-Codes

HTTP-Status-Codes sind dreistellige Zahlen, die das Ergebnis des HTTP-Requests anzeigen. Sie sind in fünf Klassen gruppiert:

1. 1xx (Informational): Der Request wurde empfangen und der Server setzt den Prozess fort.

   • Beispiel: 100 Continue, was bedeutet, dass der Client mit seinem Request fortfahren soll.

2. 2xx (Successful): Der Request wurde erfolgreich empfangen, verstanden und akzeptiert.

   • Beispiel: 200 OK, was bedeutet, dass der Request erfolgreich war und die angeforderte Ressource im Response-Body ist.

3. 3xx (Redirection): Weitere Maßnahmen müssen ergriffen werden, um den Request abzuschließen.

   • Beispiel: 301 Moved Permanently, was bedeutet, dass der angeforderten Ressource eine neue permanente URL zugewiesen wurde und zukünftige Verweise die neue URL verwenden sollten.

4. 4xx (Client Error): Der Request enthält fehlerhafte Syntax oder kann nicht erfüllt werden.

   • Beispiel: 404 Not Found, was bedeutet, dass der Server die angeforderte Ressource nicht finden konnte.

5. 5xx (Server Error): Der Server konnte einen offensichtlich gültigen Request nicht erfüllen.

   • Beispiel: 500 Internal Server Error, was bedeutet, dass der Server auf eine unerwartete Bedingung gestoßen ist, die ihn daran hinderte, den Request zu erfüllen.

Hier sind einige häufige HTTP-Status-Codes und ihre Beschreibungen:

HTTP-Response-Headers

HTTP-Response-Headers liefern zusätzliche Metadaten über den Response. Sie geben Informationen über den Server, die Response-Daten, Caching-Direktiven und mehr. Einige häufige HTTP-Response-Headers umfassen:

1. Content-Type: Gibt den Medientyp des Response-Bodys an, wie text/html, application/json oder image/jpeg.

   • Beispiel: Content-Type: text/html; charset=UTF-8

2. Content-Length: Gibt die Größe des Response-Bodys in Bytes an.

   • Beispiel: Content-Length: 1024

3. Cache-Control: Liefert Caching-Direktiven für den Response, wie lange der Response gecacht werden kann und von wem.

   • Beispiel: Cache-Control: max-age=3600, public

4. Set-Cookie: Sendet Cookies vom Server an den Client, die verwendet werden können, um den Zustand aufrechtzuerhalten oder Benutzer-Sessions zu verfolgen.

   • Beispiel: Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2023 07:28:00 GMT; Path=/

Hier sind einige andere häufige Response-Headers und ihre Beschreibungen:

Beispiel aus der Praxis: Wenn Sie eine Datei von einem Webserver herunterladen, kann der Content-Disposition-Header verwendet werden, um anzugeben, dass die Datei heruntergeladen und nicht im Browser angezeigt werden soll. Dieser Header könnte so aussehen: Content-Disposition: attachment; filename="example.pdf".

HTTP-Response-Body

Der HTTP-Response-Body enthält die eigentlichen Daten, die an den Client zurückgesendet werden. Dies kann verschiedene Datentypen umfassen, wie:

1. HTML (Hypertext Markup Language): Die Standard-Markup-Sprache zum Erstellen von Webseiten.

   • Beispiel:

     <!DOCTYPE html>
     <html>
       <head>
         <title>Beispielseite</title>
       </head>
       <body>
         <h1>Hallo Welt!</h1>
         <p>Dies ist eine Beispiel-HTML-Seite.</p>
       </body>
     </html>
     

2. JSON (JavaScript Object Notation): Ein leichtgewichtiges Datenaustauschformat, das für Menschen leicht zu lesen und zu schreiben und für Maschinen leicht zu parsen und zu generieren ist.

   • Beispiel:

     {
       "name": "John Doe",
       "age": 30,
       "email": "john@example.com"
     }
     

3. Bilder: Binärdaten, die visuellen Inhalt darstellen, wie JPEG-, PNG- oder GIF-Dateien.

4. Andere Datenformate: XML, CSV, Klartext oder jedes andere Datenformat, das vom Server und Client unterstützt wird.

Beispiel aus der Praxis: Wenn Sie eine Wetter-App auf Ihrem Smartphone verwenden, sendet sie wahrscheinlich einen HTTP-Request an eine Wetter-API. Der Response-Body der API könnte JSON-Daten mit aktuellen Wetterinformationen enthalten, wie Temperatur, Luftfeuchtigkeit und Windgeschwindigkeit, die die App dann analysiert und Ihnen in einem benutzerfreundlichen Format anzeigt.

HTTP/1.0 und HTTP/1.1

HTTP/1.0, veröffentlicht 1996, fügte die grundlegende Request-Response-Funktionalität hinzu, die die Grundlage der Web-Kommunikation ist. Es hatte jedoch einige Einschränkungen, wie die Notwendigkeit einer neuen TCP-Verbindung für jeden Request, was zu Leistungsproblemen führen konnte.

HTTP/1.1, veröffentlicht 1999, behob viele der Probleme von HTTP/1.0 und fügte mehrere neue Features hinzu:

1. Persistente Verbindungen: HTTP/1.1 fügte persistente Verbindungen hinzu, die es ermöglichen, mehrere Requests und Responses über eine einzelne TCP-Verbindung zu senden. Dies reduzierte den Overhead beim Erstellen neuer Verbindungen für jeden Request und verbesserte die Leistung.

   Beispiel: Eine Webseite mit 10 Bildern würde bei HTTP/1.0 11 separate TCP-Verbindungen benötigen (eine für das HTML und eine für jedes Bild), während HTTP/1.1 alle Ressourcen mit einer einzelnen Verbindung laden kann.

2. Pipelining: HTTP/1.1 fügte Unterstützung für Pipelining hinzu, was Clients ermöglicht, mehrere Requests zu senden, ohne auf die vorherigen Responses zu warten. Dies kann die Latenz reduzieren und die Leistung verbessern, besonders bei Verbindungen mit hoher Latenz.

   Beispiel: Ein Client kann Requests für mehrere Ressourcen (z.B. CSS, JavaScript, Bilder) schnell senden, und der Server kann sie gleichzeitig verarbeiten, wodurch die Gesamtladezeit reduziert wird.

3. Verbessertes Caching: HTTP/1.1 fügte neue Caching-Mechanismen hinzu, wie die Cache-Control- und ETag-Header, die bessere Kontrolle darüber bieten, wie Responses von Clients und Servern gecacht werden.

   Beispiel: Der Cache-Control: max-age=3600-Header weist den Client oder Server an, den Response bis zu einer Stunde zu cachen, wodurch wiederholte Requests reduziert werden.

HTTP/1.1 ist weit verbreitet und unterstützt verschiedene Leistungsoptimierungen, was es zur am häufigsten verwendeten Version von HTTP macht.

HTTP/2

HTTP/2, veröffentlicht 2015, ist eine große Änderung des HTTP-Protokolls, die sich auf die Verbesserung der Leistung und Reduzierung der Latenz konzentriert. Während HTTP/2 dieselbe Semantik wie HTTP/1.1 beibehält, fügt es mehrere neue Features hinzu:

1. Multiplexing: HTTP/2 ermöglicht es, mehrere Requests und Responses gleichzeitig über eine einzelne TCP-Verbindung zu senden. Dies eliminiert die Notwendigkeit mehrerer Verbindungen und reduziert die Auswirkungen von Netzwerk-Latenz.

   Beispiel: Eine Webseite mit 50 Ressourcen kann mit einer einzelnen Verbindung geladen werden, wobei Requests und Responses gleichzeitig gesendet werden, was zu schnelleren Seitenladezeiten führt.

2. Header-Komprimierung: HTTP/2 verwendet HPACK-Komprimierung, um den Overhead beim Senden redundanter Header-Informationen zu reduzieren. Dies kann die Menge der übertragenen Daten erheblich reduzieren, besonders bei Requests mit vielen Headern.

   Beispiel: Wiederholte Headers wie User-Agent, Accept und Cookie können komprimiert werden, wodurch die Gesamtgröße der Request- und Response-Headers reduziert wird.

3. Server-Push: HTTP/2 fügt Server-Push hinzu, der es Servern ermöglicht, Ressourcen an Clients zu senden, bevor sie angefordert werden. Dies kann die Leistung verbessern, indem die Notwendigkeit für Clients eliminiert wird, separate Requests für jede Ressource zu senden.

   Beispiel: Wenn ein Client eine HTML-Seite anfordert, kann der Server zugehörige CSS-, JavaScript- und Bilddateien pushen, wodurch die Notwendigkeit entfällt, dass der Client diese Ressourcen separat entdeckt und anfordert.

4. Binäres Framing: HTTP/2 verwendet eine binäre Framing-Schicht zum Verpacken und Senden von Daten, was effizienter und weniger fehleranfällig ist im Vergleich zum textbasierten Format von HTTP/1.1.

HTTP/2 ist so konzipiert, dass es rückwärtskompatibel mit HTTP/1.1 ist, was es Servern ermöglicht, beide Versionen gleichzeitig zu unterstützen. Viele moderne Webbrowser und Webserver unterstützen HTTP/2, und seine Verwendung wächst weiter, da mehr Websites und Webanwendungen von seinen Leistungsvorteilen profitieren.

HTTPS (HTTP Secure)

HTTPS (HTTP Secure) ist eine Erweiterung von HTTP, die SSL/TLS (Secure Sockets Layer/Transport Layer Security) verwendet, um eine verschlüsselte Verbindung zwischen Client und Server herzustellen. HTTPS bietet mehrere Sicherheitsvorteile:

1. Verschlüsselung: HTTPS verschlüsselt alle zwischen HTTP-Client und HTTP-Server gesendeten Daten und verhindert, dass unbefugte Parteien sensible Informationen wie Passwörter, Kreditkartennummern und persönliche Daten lesen können.

   Beispiel: Beim Absenden eines Login-Formulars über HTTPS werden Benutzername und Passwort verschlüsselt, was es Angreifern schwer macht, die Anmeldedaten zu stehlen, selbst wenn sie den Netzwerkverkehr abfangen.

2. Authentifizierung: HTTPS ermöglicht es Clients, die Identität des Servers zu überprüfen, mit dem sie kommunizieren, wodurch Man-in-the-Middle-Angriffe verhindert werden und sichergestellt wird, dass der Server echt und kein Betrüger ist.

   Beispiel: Beim Verbinden mit einer Banking-Website überprüft HTTPS, dass der Client mit dem echten Bank-Server kommuniziert und nicht mit einem gefälschten Server, der von Angreifern eingerichtet wurde.

3. Integrität: HTTPS überprüft, dass die zwischen Client und Server gesendeten Daten nicht während der Übertragung geändert oder verändert wurden, wodurch die Integrität der Informationen aufrechterhalten wird.

   Beispiel: Beim Herunterladen eines Software-Updates über HTTPS wird die Integrität der heruntergeladenen Datei überprüft, um sicherzustellen, dass sie nicht von Angreifern modifiziert wurde.

Um HTTPS zu aktivieren, müssen Server ein SSL/TLS-Zertifikat von einer vertrauenswürdigen Certificate Authority (CA) erhalten. Dieses Zertifikat enthält Informationen über die Identität des Servers und wird verwendet, um eine sichere Verbindung mit Clients herzustellen.

Wenn ein HTTP-Client sich mit einem HTTPS-Server verbindet, sendet der Server sein SSL/TLS-Zertifikat an den Client. Der Client überprüft die Authentizität des Zertifikats und verwendet, wenn es gültig ist, den öffentlichen Schlüssel im Zertifikat, um eine sichere, verschlüsselte Verbindung mit dem Server herzustellen.

HTTPS ist wichtig für den Schutz sensibler Daten und die Gewährleistung von Privatsphäre und Sicherheit im Web. Es wird weitgehend für E-Commerce-Websites, Online-Banking und alle anderen Webanwendungen verwendet, die vertrauliche Informationen verarbeiten.

Rolle von HTTP in Webanwendungen

HTTP ist das primäre Protokoll für die Kommunikation zwischen Webbrowsern und Servern. Wenn ein Benutzer mit einer Webanwendung interagiert, sendet sein Webbrowser HTTP-Requests an den Server, der dann die Requests verarbeitet und HTTP-Responses mit den angeforderten Daten oder dem Ergebnis einer Aktion zurücksendet.

Webentwickler verwenden HTTP, um:

1. Webseiten abrufen und anzeigen: Wenn ein Benutzer eine Webseite besucht, sendet der Webbrowser einen HTTP-GET-Request an den Server, der mit den HTML-, CSS- und JavaScript-Dateien antwortet, die zum Anzeigen der Seite benötigt werden.

2. Formulardaten senden und verarbeiten: Wenn ein Benutzer ein Formular absendet, sendet der Webbrowser einen HTTP-POST-Request mit den Formulardaten an den Server. Der Server verarbeitet die Daten und sendet einen Response zurück, wie eine Erfolgsmeldung oder eine Seite mit den Ergebnissen der Formularübermittlung.

3. Benutzer verifizieren und Sessions verwalten: HTTP-Requests und -Responses können Authentifizierungs-Token oder Session-Cookies enthalten, um die Identität eines Benutzers zu überprüfen und seinen angemeldeten Zustand über mehrere Seiten hinweg aufrechtzuerhalten.

4. Server-seitige Verarbeitung ermöglichen: Webanwendungen sind oft auf server-seitige Verarbeitung angewiesen, um Aufgaben wie das Abrufen von Daten aus Datenbanken, die Verarbeitung von Zahlungen oder das Erstellen dynamischer Inhalte durchzuführen. HTTP-Requests lösen diese server-seitigen Aktionen aus, und die Ergebnisse werden in HTTP-Responses zurückgesendet.

HTTP-Bibliotheken und -Tools

Um mit HTTP in der Webentwicklung zu arbeiten, verwenden Programmierer verschiedene Bibliotheken und Tools, die es einfacher machen, HTTP-Requests zu senden und Responses zu verarbeiten.

Beliebte HTTP-Bibliotheken umfassen:

1. urllib (Python): Eine eingebaute Python-Bibliothek zum Senden von HTTP-Requests und Verarbeiten von Responses.

   • Beispiel: urllib.request.urlopen('https://api.example.com/data').read()

2. HttpClient (Java): Eine Java-Bibliothek zum Senden von HTTP-Requests und Abrufen von Responses.

   • Beispiel: HttpClient client = HttpClientBuilder.create().build();

3. Axios (JavaScript): Ein promise-basierter HTTP-Client für JavaScript, verwendet sowohl in Webbrowser- als auch in Node.js-Umgebungen.

   • Beispiel: axios.get('https://api.example.com/data').then(response => { ... })

Neben Bibliotheken verwenden Webentwickler Tools wie cURL und Postman, um HTTP-Requests zu testen und zu debuggen:

1. cURL: Ein Kommandozeilen-Tool zum Senden von HTTP-Requests und Anzeigen von Responses.

   • Beispiel: curl -X POST -H "Content-Type: application/json" -d '{"key": "value"}' https://api.example.com/endpoint

2. Postman: Ein GUI-Tool (Grafische Benutzeroberfläche) zum Erstellen, Senden und Organisieren von HTTP-Requests sowie zum Anzeigen und Testen von API-Responses.

HTTP und RESTful APIs

HTTP ist die Grundlage von RESTful (Representational State Transfer) APIs, die in der Webentwicklung weit verbreitet sind, um skalierbare und wartbare Webservices zu erstellen. RESTful APIs verwenden HTTP-Methoden, um CRUD-Operationen (Create, Read, Update, Delete) auf Ressourcen durchzuführen.

Die wichtigsten in RESTful APIs verwendeten HTTP-Methoden sind:

1. GET: Ruft eine Ressource oder eine Sammlung von Ressourcen ab.
2. POST: Erstellt eine neue Ressource.
3. PUT: Aktualisiert eine vorhandene Ressource.
4. DELETE: Löscht eine Ressource.

Betrachten Sie zum Beispiel eine API zur Verwaltung von Benutzerkonten:

• GET /users: Ruft eine Liste aller Benutzer ab.
• GET /users/123: Ruft den Benutzer mit ID 123 ab.
• POST /users: Erstellt ein neues Benutzerkonto.
• PUT /users/123: Aktualisiert den Benutzer mit ID 123.
• DELETE /users/123: Löscht den Benutzer mit ID 123.

RESTful APIs verwenden normalerweise JSON (JavaScript Object Notation) oder XML (eXtensible Markup Language) für den Datenaustausch zwischen Client und Server. JSON ist aufgrund seiner Einfachheit und nativen Unterstützung in JavaScript zur beliebteren Wahl geworden.

Beispiel aus der Praxis: Social-Media-API

Eine Social-Media-Plattform könnte eine RESTful API für Entwickler anbieten, um Drittanbieter-Anwendungen zu erstellen. Die API könnte Endpoints umfassen für:

• Abrufen von Benutzerprofilen (GET /users/{id})
• Erstellen neuer Posts (POST /posts)
• Aktualisieren von Benutzerinformationen (PUT /users/{id})
• Löschen von Kommentaren (DELETE /posts/{postId}/comments/{commentId})

Durch das Befolgen von RESTful-Prinzipien und die Nutzung von HTTP-Methoden können Webentwickler APIs erstellen, die leicht zu verstehen, zu warten und zu skalieren sind. Diese APIs können von verschiedenen Clients verwendet werden, wie Webbrowsern, mobilen Apps oder anderen Webservices, was Interoperabilität und Flexibilität in der Webentwicklung fördert.