Wenn HTTP nicht mehr reicht
Warum Echtzeit-Apps eine andere Verbindung brauchen
⏱ ca. ~7 Min
01 · Lesen
Du hast einen Server gebaut, der auf Anfragen antwortet. Der Browser fragt nach einer Seite, der Server schickt sie zurück. Ein Formular schickt Daten, der Server verarbeitet sie. Dieser Request-Response-Zyklus ist, wie das Web zum größten Teil funktioniert.
Aber was, wenn der Server zuerst mit dir sprechen will, ohne dass du gefragt hast?
Der Schachgegner zieht. Eine Chatnachricht trifft ein. Der Aktienkurs ändert sich. Mit normalem HTTP kann der Server nicht aktiv werden — er muss warten, bis du fragst. Beim Bau von Echtzeit-Sachen ist das ein Problem.
💡 Stell dir das so vorHTTP ist wie Briefe hin und her schicken. Du schreibst einen Brief, schickst ihn, wartest auf Antwort. Es funktioniert, aber jedes Mal entsteht Verzögerung. WebSocket ist wie ein Telefonat — die Leitung ist offen, beide Seiten können jederzeit sprechen. Kein Warten auf Briefe.
Kernpunkte
- HTTP ist Request-Response: der Client beginnt immer
- Der Server kann mit HTTP niemals von sich aus Daten an den Client senden
- Echtzeit-Funktionen wie Spiele, Chat, Live-Updates brauchen etwas anderes
- WebSocket löst das mit einer persistenten, bidirektionalen Verbindung
02 · Lesen
Bevor es WebSocket gab, haben Entwickler Echtzeit-Funktionen mit einem Trick namens Polling gehackt. Der Browser fragt den Server alle ein, zwei Sekunden: "Gibt es Updates?" Gibt es welche, schickt der Server sie; gibt es keine, schickt der Server eine leere Antwort.
Polling funktioniert technisch. Aber es ist verschwenderisch. Stell dir vor, du rufst alle 30 Sekunden bei der Pizzeria an und fragst "Ist meine Bestellung fertig?" Meistens lautet die Antwort nein, und du verschwendest deine und deren Zeit.
WebSocket ersetzt diesen Hack durch eine echte Lösung: eine persistente Verbindung, bei der beide Seiten jederzeit Nachrichten senden können, ohne fragen zu müssen.
Kernpunkte
- Polling: der Client fragt per Timer "Gibt es Updates?" — verschwenderisch
- Die meisten Poll-Antworten sind leer — Verschwendung von Bandbreite und Serverlast
- WebSocket: eine Verbindung, bleibt offen, beide Seiten senden frei
- Jede große Echtzeit-App nutzt WebSocket: Slack, Discord, Google Docs, Multiplayer-Spiele
03 · Schritt für Schritt
Unten siehst du, wie eine WebSocket-Verbindung aufgebaut wird — sie beginnt als normaler HTTP-Request und wird hochgestuft.
1. Der Client schickt einen HTTP-Request
Der Browser schickt einen normalen HTTP-Request an den Server, aber mit einem speziellen Header: 'Upgrade: websocket'. Das sagt dem Server: "Ich will von HTTP auf WebSocket umschalten."
2. Der Server stimmt dem Upgrade zu
Unterstützt der Server WebSocket, antwortet er mit Statuscode 101 (Switching Protocols). Die HTTP-Verbindung wird auf eine WebSocket-Verbindung hochgestuft.
3. Die persistente Verbindung ist offen
Jetzt können beide Seiten jederzeit Nachrichten senden. Der Server schickt Daten an den Client, ohne gefragt zu werden. Der Client schickt Daten an den Server, ohne auf eine Antwort zu warten.
4. Nachrichten fließen frei
Jede Seite schickt kleine Datenpakete, sogenannte 'Frames'. Kein Request-Response-Muster — einfach Nachrichten hin und her, wie sie gebraucht werden. So erscheint der Schachzug sofort auf dem Bildschirm des Gegners.
5. Bei Abschluss wird die Verbindung geschlossen
Jede Seite kann die Verbindung jederzeit schließen. Der Browser schließt sie, wenn du weggehst. Der Server schließt sie, wenn du dich abmeldest. Bis dahin bleibt sie offen.
04 · Ziehen zum Sortieren
Ordne jede Funktion zu: nutzt sie HTTP oder WebSocket?
(Diese Sektion ist interaktiv — aktiviere JavaScript, um sie zu nutzen.)
05 · Quiz
Was ist der entscheidende Vorteil von WebSocket gegenüber HTTP bei Multiplayer-Spielen?
- Der Server kann Updates sofort an Spieler pushen, ohne dass sie fragen
- WebSocket ist sicherer als HTTP
- WebSocket nutzt weniger Bandbreite beim ersten Laden der Seite
- WebSocket braucht überhaupt keinen Server
06 · Ausfüllen
Anders als der HTTP-Request-Response-Zyklus baut WebSocket eine _____ Verbindung auf, bei der beide Seiten jederzeit Nachrichten senden können.
Andere Lektionen aus diesem Kapitel
⚠ Das volle interaktive Erlebnis braucht JavaScript. Bitte aktiviere es und lade die Seite neu.
※ Diese Seite ist ein unabhängiges Bildungsprojekt — kein offizielles Anthropic-Produkt. Claude™ ist eine eingetragene Marke von Anthropic, PBC.