---
term: 'WebSockets und Echtzeit-Synchronisierung'
seoTitle: 'WebSockets erklärt: Echtzeit-Synchronisierung verstehen'
headline: 'Was sind WebSockets?'
slug: websockets
category: api-realtime
shortDefinition: 'Ein WebSocket ist eine dauerhafte, bidirektionale Verbindung zwischen Client und Server, über die beide Seiten Nachrichten sofort senden können.'
relatedTerms:
  - real-time-live-queries
  - event-driven-architecture
  - webhooks
  - push-notifications-apns-fcm
  - sse-vs-websockets-vs-polling
contrastsWith:
  - webhooks
aboutTerms:
  - 'WebSockets'
  - 'Real-Time Synchronization'
faq:
  - question: 'Was ist ein WebSocket, einfach erklärt?'
    answer: 'Ein Telefonat statt eines Briefwechsels. HTTP ist Anfrage-Antwort – der Client fragt, der Server antwortet, die Leitung wird geschlossen. Ein WebSocket öffnet eine dauerhafte Verbindung, über die beide Seiten jederzeit Nachrichten senden können, mit wenigen Byte Framing pro Nachricht statt vollständiger Header. Es ist das Standardtransport (RFC 6455) für Chat, Live-Daten und Zusammenarbeit.'
  - question: 'Worin unterscheidet sich ein WebSocket von HTTP?'
    answer: 'In Richtung und Lebensdauer. HTTP ist zustandslos und clientinitiiert: Jeder Austausch ist eine neue Anfrage mit vollständigen Headern, und der Server kann nie zuerst sprechen. Ein WebSocket beginnt als HTTP-Anfrage, führt ein Upgrade durch und wird zu einem zustandsbehafteten Full-Duplex-Kanal, über den der Server ungefragt sendet – und genau darum geht es bei allem, was sich ändert, während der Nutzer zusieht.'
  - question: 'Wie funktioniert der WebSocket-Handshake?'
    answer: 'Er beginnt als höfliches HTTP: Der Client sendet ein GET mit den Headern Upgrade und Connection sowie einem zufälligen Sec-WebSocket-Key; der Server antwortet mit 101 Switching Protocols und einem Accept-Hash, der aus diesem Schlüssel abgeleitet ist. Von diesem Moment an spricht die TCP-Verbindung kein HTTP mehr und transportiert leichtgewichtige WebSocket-Frames in beide Richtungen, bis eine Seite sie schließt.'
  - question: 'Was ist der Unterschied zwischen ws:// und wss://?'
    answer: 'Derselbe wie zwischen http und https: wss führt die Verbindung über TLS. Produktionsverkehr läuft immer über wss – aus Gründen der Vertraulichkeit und ganz pragmatisch, weil verschlüsselte Verbindungen Proxys und Middleboxen in Unternehmensnetzen passieren, die unverschlüsselte Upgrades zerstören. Es gibt keinen legitimen Grund, ws in Produktion auszuliefern.'
  - question: 'Was ist der Unterschied zwischen WebSockets und Server-Sent Events?'
    answer: 'Die Richtung. SSE ist einseitig – der Server streamt über gewöhnliches HTTP zum Client, mit eingebauter automatischer Wiederverbindung – ideal für Feeds, Ticker und Benachrichtigungen. WebSockets sind bidirektional, für alles, bei dem auch der Client spricht: Chat, Spiele, kollaboratives Bearbeiten. SSE ist einfacher, wo es genügt; WebSockets sind das allgemeine Werkzeug.'
  - question: 'Wie funktionieren Wiederverbindung und Heartbeats?'
    answer: 'Das Protokoll enthält Ping-/Pong-Steuerframes, mit denen jede Seite prüfen kann, ob die andere noch lebt; Anwendungen legen Heartbeats darüber, um halbtote Verbindungen zu erkennen, und verbinden sich dann mit exponentiellem Backoff plus Jitter neu und abonnieren ihren Zustand erneut. Verwaltete Echtzeit-Schichten übernehmen diese Schleife für Sie – handgeschriebener WebSocket-Code, der sie auslässt, funktioniert genau so lange, bis Netzwerke sich wie Netzwerke verhalten.'
  - question: 'Skalieren WebSockets?'
    answer: 'Ja, aber mit anderer Mechanik als HTTP: Verbindungen sind zustandsbehaftet, also brauchen Load Balancer Session-Affinität; das Senden an viele Clients braucht ein Pub/Sub-Backplane, damit jeder Server-Knoten Nachrichten per Fan-out verteilen kann; und langsame Konsumenten brauchen Backpressure-Behandlung, damit ein blockierter Client nicht den Speicher aufbläht. Das sind gelöste Probleme – in einer Infrastruktur, die Sie entweder bauen oder mieten.'
  - question: 'Wann sollten Sie WebSockets NICHT einsetzen?'
    answer: 'Wenn Anfrage-Antwort bereits passt: cachefähige Ressourcen abrufen, gewöhnliches CRUD, seltene Aktualisierungen. Eine dauerhafte Verbindung erkauft sofortigen Push und bezahlt ihn mit Zustandshaltung – sinnlos für Daten, die sich selten ändern. Die Faustregel: Wenn alle 30 Sekunden zu pollen ehrlich gesagt reichen würde, sparen Sie sich den Socket.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 6455 — The WebSocket Protocol'
    url: 'https://www.rfc-editor.org/rfc/rfc6455'
  - name: 'WebSockets API — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API'
  - name: 'LiveQuery protocol specification'
    url: 'https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification'
  - name: 'Back4app Live Query documentation'
    url: 'https://www.back4app.com/docs/platform/parse-server-live-query-example'
cta:
  title: 'Echtzeit, ohne Sockets zu betreiben'
  text: 'Back4app Live Queries legen eine Query-Schicht über verwaltete WebSockets: Abonnieren Sie die Daten, die Sie interessieren, und empfangen Sie Änderungen als Ereignisse – Verbindungen, Heartbeats, Wiederverbindung und Fan-out übernimmt die Plattform.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-23'
translationKey: websockets-real-time-sync
---

**Ein WebSocket ist eine dauerhafte, bidirektionale Verbindung zwischen Client und Server, über die beide Seiten Nachrichten sofort senden können.** HTTP hat das Web durch Fragen groß gemacht; WebSockets haben es durch *Zuhören* lebendig gemacht – ein standardisiertes Upgrade ([RFC 6455](https://www.rfc-editor.org/rfc/rfc6455)) verwandelt eine Anfrage in einen offenen Kanal, und alles Echtzeitfähige im Web – Chat, Präsenz, Ticker, kollaborative Cursor – läuft darüber.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Was es ist | Eine dauerhafte Full-Duplex-Verbindung – Server-Push, Client-Senden, dieselbe Leitung |
| vs. HTTP | Zustandslose Anfrage-Antwort vs. zustandsbehafteter offener Kanal |
| Der Handshake | HTTP-GET + Upgrade → 101 Switching Protocols → Frames |
| Die Produktionsregeln | Immer wss://, Heartbeats + Wiederverbindung mit Backoff, Fan-out einplanen |
| Die höhere Schicht | Echtzeit-*Synchronisierung* – Queries und Zustand über den Socket, keine rohen Nachrichten |

## So funktioniert das WebSocket-Handshake-Upgrade (HTTP 101)

```text
GET /chat HTTP/1.1                      ← beginnt als gewöhnliches HTTP
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← und ist ab hier kein HTTP mehr
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Ab jetzt: winzige Frames (2–14 Byte Overhead), in beide Richtungen,
# statt ~500+ Byte Header bei jeder einzelnen HTTP-Abfrage.
```

Die meisten Anwendungen sollten das, was danach kommt, nicht selbst schreiben – die Produktionspraxis ist eine verwaltete Echtzeit-Schicht, in der Socket, Heartbeats und Wiederverbindung fremder Code sind:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');

final sub = await liveQuery.client.subscribe(query); // wss:// under the hood
sub.on(LiveQueryEvent.create, (msg) => appendToChat(msg));
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
let query = Message.query("room" == "general")

let subscription = query.subscribeCallback   // wss:// under the hood
subscription?.handleEvent { _, event in
  if case .created(let msg) = event { appendToChat(msg) }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")

val handling = client.subscribe(query)       // wss:// under the hood
handling.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
  appendToChat(msg)
}
```

## WebSockets vs. alles andere, was Daten bewegt

| Transport | Richtung | Funktionsweise | Am besten für |
| --- | --- | --- | --- |
| Polling | Client fragt wiederholt | Volle Anfrage pro Prüfung | Nur als Legacy-Rückfalloption |
| Long Polling | Client fragt, Server hält hin | Eine offene Anfrage pro Nachricht | Rückfall aus Kompatibilitätsgründen |
| SSE | Nur Server → Client | Gestreamtes HTTP, automatische Wiederverbindung | Feeds, Ticker, Benachrichtigungen |
| **WebSocket** | **Beide Richtungen** | **Dauerhaftes TCP nach Upgrade** | **Chat, Spiele, Zusammenarbeit, Sync** |
| WebRTC | Peer ↔ Peer | UDP-Medien-/Datenkanäle | Anrufe, Video – Signalisierung *über* WebSockets |

```mermaid
flowchart LR
  accTitle: HTTP-Polling im Vergleich zu einer WebSocket-Verbindung
  accDescr: Beim Polling sendet der Client immer wieder vollständige HTTP-Anfragen, die meist nichts Neues zurückgeben; bei einem WebSocket bleibt eine einzige hochgestufte Verbindung offen, und der Server sendet jede Nachricht in dem Moment, in dem sie entsteht.
  subgraph P["Polling"]
    c1["Client"] -->|"Anfrage #1 …leer"| s1["Server"]
    c1 -->|"Anfrage #2 …leer"| s1
    c1 -->|"Anfrage #3 …Nachricht!"| s1
  end
  subgraph W["WebSocket"]
    c2["Client"] <-->|"ein offener Kanal<br/>Nachrichten in beide Richtungen, sofort"| s2["Server"]
  end
```

## Sockets im Produktivbetrieb

Vier Konzepte tragen die operative Last. **Session-Affinität:** Verbindungen sind zustandsbehaftet, also müssen Load Balancer jeden Client an seinen Server-Knoten binden. **Fan-out:** Eine Nachricht an zehntausend Abonnenten über viele Knoten hinweg zu verteilen, erfordert ein Pub/Sub-Backplane zwischen den Servern – die Nachricht reist von Server zu Server, bevor sie von Server zu Client reist. **Backpressure:** Ein langsames Telefon in einem schlechten Netz darf nicht unbegrenzt Nachrichten im Speicher Ihres Servers puffern; verwerfen, zusammenfassen oder trennen. **Lebendigkeit:** Ping-/Pong-Frames plus anwendungsseitige Heartbeats erkennen halbtote Verbindungen, und Clients verbinden sich mit exponentiellem Backoff und Jitter neu und *abonnieren dann ihren Zustand erneut* – der Schritt, den naive Implementierungen vergessen. Nichts davon ist exotisch; all das ist der Grund, warum aus "wir öffnen einfach einen Socket" eine Plattformentscheidung wird.

## Von Nachrichten zur Synchronisierung: die Schicht darüber

Rohe WebSockets bewegen Bytes; Anwendungen wollen *Zustand*. Die nächste Stufe ist Echtzeit-**Synchronisierung**: Statt Nachrichtentypen und clientseitige Buchführung selbst zu bauen, abonnieren Sie Daten – eine Query, ein Dokument, einen Kanal – und die Schicht liefert präzise Änderungsereignisse, kümmert sich um Wiederverbindung samt Nachholen und wendet serverseitige Berechtigungen pro Abonnent an. Das ist das Modell der [Live Queries](/glossary/de/live-queries-echtzeit/): WebSockets als Transport, eine Query-Engine als Gehirn. Wenn Ihr WebSocket-Code switch-Anweisungen über Nachrichtentypen anhäuft, bauen Sie diese Schicht gerade von Hand nach.

## Typische Anwendungsfälle

- **Chat und Messaging** – der kanonische Fall: beide Seiten sprechen, sofort.
- **Präsenz** – wer ist online, wer tippt gerade: winzige Nachrichten, hohe Frequenz, beide Richtungen.
- **Kollaboratives Bearbeiten** – gemeinsame Dokumente und Whiteboards, in denen Cursorpositionen und Änderungen fortlaufend strömen.
- **Live-Dashboards und Ticker** – Server-Push sich ändernder Zahlen; wo es einseitig bleibt, passt auch SSE.
- **Multiplayer und Standort** – Spielzustand und bewegte Kartenmarker, wo Latenz das Produkt ist.

## Brauchen Sie einen Socket? Eine Entscheidungsmatrix

| Greifen Sie zu WebSockets, wenn … | Gewöhnliches HTTP ist richtig, wenn … |
| --- | --- |
| Nutzer Daten betrachten, die sich jetzt ändern | Daten sich selten oder nur auf Abruf ändern |
| Beide Seiten Nachrichten anstoßen | Immer nur der Client fragt |
| Latenz für Nutzer sichtbar ist (Chat, Spiele) | Eine Abfrage alle 30 Sekunden ehrlich genügen würde |
| Ständig viele kleine Nachrichten fließen | Antworten groß und cachefähig sind |
| Sie das Fan-out betreiben (oder mieten) | Niemand den Socket-Betrieb verantwortet |

Und der Mittelweg, den die Matrix verschweigt: Fälle, die nur vom Server zum Client laufen (Feeds, Benachrichtigungen), passen zu SSE mit weniger Maschinerie – der vollständige Transportvergleich hat einen eigenen Eintrag im Register dieses Glossars.

## Grenzen und Trade-offs

- **Zustandshaltung ist der Preis für Push.** Jede offene Verbindung ist Serverspeicher und eine Einschränkung für die Lastverteilung; die Zustandslosigkeit von HTTP hat mehr getragen, als es den Anschein hatte.
- **Netzwerke hassen langlebige Verbindungen.** Proxys, Mobilfunkmodems und zugeklappte Laptops trennen ständig Sockets – Wiederverbindungslogik ist kein Sonderfall, sie ist die Hauptschleife.
- **Sicherheit wandert an die Verbindung.** Beim Verbindungsaufbau authentifizieren, jede Nachricht validieren, Autorisierung pro Abonnement durchsetzen – und immer wss.
- **Caching gibt es hier nicht.** Alles Gesendete wird pro Client berechnet und zugestellt; das CDN hilft Ihnen nicht.
- **Selbstgebaute Synchronisierung ist eine Falle.** Die Lücke zwischen "Socket geöffnet" und "korrekter, wiederverbindender, berechtigungsgeprüfter Zustandsabgleich" ist der Ort, an dem die eigentliche Ingenieursarbeit steckt – und genau diese Schicht lohnt es sich zu mieten.

## WebSockets mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Seine Echtzeit-Schicht ist [Live Query](https://www.back4app.com/docs/platform/parse-server-live-query-example): WebSocket-Transport, Heartbeats, Wiederverbindung und Fan-out über mehrere Knoten laufen als verwaltete Infrastruktur (darunter das [offene LiveQuery-Protokoll](https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification)), während Ihr Code *Queries* abonniert und typisierte Änderungsereignisse empfängt – mit ACLs, die pro Abonnent durchgesetzt werden, sodass Echtzeit das Berechtigungsmodell nie umgeht. Die Code-Tabs oben sind die gesamte Geschichte auf Client-Seite.