HTTP

Real-World Example: Der Instagram-Feed

Wenn du Instagram öffnest, passiert im Hintergrund ein Feuerwerk an HTTP-Anfragen:

1. GET /feed: "Gib mir die neuesten Bilder." -> Server sendet Liste mit Bild-URLs.
2. GET /image/123: "Lade dieses spezielle Foto." -> Server sendet die Bild-Daten.
3. POST /like: "Ich mag das Bild." -> Server speichert das Herz in der Datenbank.

Die "Verben" (Methoden)

HTTP definiert genau, was du tun willst. Das ist wie im Restaurant:

• GET: "Bringen Sie mir die Karte." (Daten abrufen). Ändert nichts auf dem Server.
• POST: "Ich bestelle die Nummer 12." (Daten senden/erstellen).
• PUT / PATCH: "Ich möchte doch lieber Pommes statt Reis." (Daten ändern/updaten).
• DELETE: "Stornieren Sie das." (Daten löschen).

Der Status Code (Die Ampel)

Jede Antwort hat einen Code. Die wichtigsten für den Alltag:

• 200 OK: Grün. Alles super.
• 404 Not Found: Gelb/Rot. Die Seite/Datei gibt es nicht (falsche Adresse).
• 500 Internal Error: Rot. Der Server ist kaputt (nicht deine Schuld).

1. Struktur eines HTTP-Requests

Ein Request ist reiner Text (außer bei HTTP/2+). Er besteht aus:

• Start Line: GET /index.html HTTP/1.1 (Was will ich, welches Protokoll).
• Headers: Metadaten.
  • Host: google.com (Wen rufe ich an?)
  • User-Agent: Mozilla/5.0... (Wer bin ich? Chrome auf Windows?)
  • Accept: text/html (Was verstehe ich?)
  • Cookie: session_id=xyz (Mein Ausweis).
• Body: (Optional) Die Daten bei POST/PUT.

2. Statelessness & State Management

HTTP ist zustandslos (stateless). Das ist eine der wichtigsten Eigenschaften. Der Server weiß bei Anfrage B nicht mehr, was du bei Anfrage A gemacht hast (wie ein Goldfisch). Das Problem: Beim Online-Shopping musst du aber über mehrere Seiten hinweg eingeloggt bleiben. Die Lösung: Cookies & Sessions. Der Server gibt dir beim ersten "Hallo" einen Keks (Cookie mit session_id). Bei jedem weiteren Aufruf zeigst du diesen Keks vor. So "erinnert" sich der Server wieder.

3. HTTP-Versionen: Die Evolution der Geschwindigkeit

• HTTP/1.1 (1997): Der alte Standard. Jede Datei (Bild, CSS, JS) braucht eine eigene TCP-Verbindung. Das ist langsam ("Head-of-Line Blocking").
• HTTP/2 (2015): Multiplexing. Über eine Leitung können viele Anfragen gleichzeitig flitzen. Wie eine Autobahn mit vielen Spuren statt einer Landstraße.
• HTTP/3 (QUIC): Basiert auf UDP statt TCP. Wenn ein Paket verloren geht, bremst das nicht mehr den ganzen Ladevorgang. Extrem wichtig für instabile Handynetze. YouTube und Google nutzen das fast überall.

1. HTTP/2 Frame Architecture

HTTP/1 war purer, von Menschen lesbarer Text über den TCP Socket. HTTP/2 ändert die Anatomie des Protokolls radikal in ein Binary Framing Format. Ein Request wird nicht als String geschickt, sondern in winzige binäre Datenpakete (Frames) zerhackt. Es gibt HEADERS-Frames, die kryptografisch hochkomprimiert werden (HPACK-Algorithmus schrumpft redundante Cookies extrem), und DATA-Frames für den Body. Alle Frames haben eine Stream-ID. Dadurch entsteht echtes Multiplexing: Das Bild A (Stream 1) und CSS B (Stream 2) werden in Frames zerhäckselt, chaotisch gemischt über dieselbe einzige TCP-Leitung gepumpt, und am Browser-Ende wieder mathematisch perfekt zusammengeflickt. Das "Head-of-Line Blocking" (langsame Bilder blockieren CSS) ist besiegt.

2. HTTP/3 (QUIC) und der Abschied von TCP

HTTP/2 war perfekt, bis auf einen Haken: Es lag auf TCP. Wenn im Mobilfunknetz auch nur ein einziges TCP-Datenpaket bei Tempo 150 km/h im Zug verloren geht, zwingt TCP die gesamte Congestion-Control zum Halten. Der Kernel blockiert alle Multiplex-Streams von HTTP/2 synchron, bis das Paket per Timeout (teils 300ms) re-transmitted wurde (TCP Head-of-Line Blocking). Google entwarf QUIC (HTTP/3). Es wirft TCP komplett in den Müll und läuft direkt über das schnellere UDP. QUIC baut seine eigene, clevere Stream-Control im Userspace auf. Geht bei UDP ein Datenpaket verloren, blockiert exakt nur dieser eine Bild-Stream. Die anderen CSS-Dateien laufen ungestört flüssig an dem Loch vorbei.

3. Connection Keep-Alive vs Pipelining

In den düsteren 90ern schloss HTTP/1.0 nach jedem 200 OK hart den TCP-Socket. Die CPU brannte bei neuen Handshakes und Slow-Starts. HTTP/1.1 führte Connection: keep-alive ein: Der TCP-Tunnel bleibt nach dem Download offen wie ein Strohhalm, bereit für Bild Nummer zwei. Das gescheiterte Experiment war HTTP Pipelining (mehrere GETs blind abschicken, ohne auf die 200 OK des ersten zu warten). Da FiFO-Queueing herrscht, blockierte ein langsamer Serverdurchlauf bei GET 1 (DB Query) alle nachfolgenden Bilder. Pipelining ist heute tot und wurde durch HTTP/2 Multiplexing ersetzt.