rustification-server/docs/realtime/research/03-ws-auth-reconnect.md

# Recherche: WS-Auth, Heartbeat und Reconnect

Ticket: [`../issues/03-research-ws-auth-reconnect.md`](../issues/03-research-ws-auth-reconnect.md)
Parent: [`../map.md`](../map.md)
Stand: 14.08.2026

> **Dieses Dokument gibt bewusst keine Empfehlung ab.** Es stellt pro Teilfrage die Optionen
> mit ihren belegten Vor- und Nachteilen gegenüber. Die Entscheidung fällt im Ticket
> *Verbindungsaufbau & Auth über WS*.

## Vorbemerkung zum Bedrohungsmodell

Die Map setzt fest: **der Serverbetreiber ist der Angreifer.** Für die Token-Frage folgt
daraus eine Klarstellung, die im weiteren Text nicht wiederholt wird: **kein
Token-Transportweg schützt vor dem Serverbetreiber selbst** — der Server muss das Token
sehen, um es zu prüfen. Der Unterschied zwischen den Optionen ist ausschließlich die
**Persistenz- und Streubreite** des Geheimnisses: was landet in Logfiles, Log-Backups,
Reverse-Proxy-Logs, APM/Tracing-Systemen und deren Subprozessoren — also in Artefakten, die
den Handshake überleben und mehr Leute sehen als der Prozess, der das Token validiert.

Vertraulichkeit *gegenüber* dem Betreiber ist eine Aufgabe der E2EE-Schicht, nicht der
Auth-Schicht. RFC 6455 sagt dazu selbst nichts vor: §10.5 —
> „This protocol does not prescribe any particular way that servers can authenticate clients
> during a WebSocket handshake."
(https://datatracker.ietf.org/doc/html/rfc6455#section-10.5)

Ein zweites, für das Projekt relevantes Faktum vorab: **die Browser-API verschluckt alle
Fehlerdetails.** WHATWG WebSockets Standard, „Feedback from the protocol":
> „User agents must not convey any failure information to scripts in a way that would allow a
> script to distinguish the following situations […] Allowing a script to distinguish these
> cases would allow a script to probe the user's local network in preparation for an attack."
(https://websockets.spec.whatwg.org/#feedback-from-the-protocol)

Zu den nicht unterscheidbaren Fällen gehören DNS-Fehler, Connection-Refused, TLS-Fehler,
**Subprotocol-Mismatch** und Abbruch nach erfolgreichem Handshake. Das Skript sieht in allen
Fällen `CloseEvent.code === 1006`, `wasClean === false`; das `error`-Event ist ein generisches
`Event` ohne Payload (https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/error_event).
**Im WebView ist „Token abgelaufen" nicht von „Server down" unterscheidbar. Im Rust-Layer
schon** — `tungstenite::Error::Http` trägt die vollständige HTTP-Response inklusive
Statuscode und Body (https://docs.rs/tungstenite/latest/tungstenite/error/enum.Error.html).
Diese Asymmetrie zieht sich durch fast jede Teilfrage.

---

## 1. Token-Übergabe beim Handshake

### 1.1 Ausgangslage

Der Handshake ist ein normaler HTTP-Request. RFC 6455 §4.1:
> „If the status code received from the server is not 101, the client handles the response per
> HTTP [RFC2616] procedures. In particular, the client might perform authentication if it
> receives a 401 status code"
(https://datatracker.ietf.org/doc/html/rfc6455#section-4.1)

Ein Axum-Handler kann also regulär mit 401/403 samt JSON-Body ablehnen. Ob der Client das
*sieht*, hängt daran, wo die Verbindung lebt (siehe Vorbemerkung).

### 1.2 Option A — Token im Query-String (`wss://host/ws?token=…`)

**Normative Ablehnung.** RFC 6750 §2.3:
> „Because of the security weaknesses associated with the URI method (see Section 5), including
> the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be
> used unless it is impossible to transport the access token in the 'Authorization' request
> header field or the HTTP request entity-body."
(https://datatracker.ietf.org/doc/html/rfc6750#section-2.3)

RFC 6750 §5.3:
> „Bearer tokens SHOULD NOT be passed in page URLs […] Browsers, web servers, and other
> software may not adequately secure URLs in the browser history, web server logs, and other
> data structures."
(https://datatracker.ietf.org/doc/html/rfc6750#section-5.3)

OWASP REST Security Cheat Sheet: „Passwords, security tokens, and API keys should not appear
in the URL, as this can be captured in web server logs"
(https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)

**Das Log-Verhalten in Default-Konfigurationen — der eigentliche Beleg:**

| Proxy/Server | Query-String im Default-Log? | Header im Default-Log? | Quelle |
|---|---|---|---|
| nginx (`combined`) | **Ja** — `$request` ist die Request-Line inkl. Query | Nein (nur Referer + User-Agent) | https://nginx.org/en/docs/http/ngx_http_log_module.html |
| Apache httpd (`common`/`combined`) | **Ja** — `%r` = „The request line from the client" | Nein (außer explizit `%{Header}i`) | https://httpd.apache.org/docs/2.4/logs.html |
| Caddy (JSON) | **Ja** — `request.uri` = „Absolute path and query of the URI" | **Ja, alle Header** — außer `Cookie`, `Set-Cookie`, `Authorization`, `Proxy-Authorization` (→ `REDACTED`) | https://caddyserver.com/docs/logging |

Caddy wörtlich:
> „By default, access logs […] with headers that contain potentially sensitive information
> (`Cookie`, `Set-Cookie`, `Authorization` and `Proxy-Authorization`) will be logged as
> `REDACTED`."

**Befund:** In allen drei Default-Konfigurationen ist der `Authorization`-Header der leisere
Kanal. Bei Caddy ist er sogar aktiv redigiert, `request.uri` dagegen nicht. Das ist der einzige
belastbare technische Unterschied im Log-Kanal — und für dieses Projekt der entscheidende, weil
der Betreiber-Angreifer genau über solche Artefakte an Tokens kommt, die er im Prozess nur
flüchtig sieht.

**Wer es trotzdem so macht — und wie ehrlich die Doku dazu ist.** Microsoft SignalR
(`ms.date: 2026-07-29`):
> „In standard web APIs, bearer tokens are sent in an HTTP header. However, SignalR is unable to
> set these headers in browsers when some transports are used. When WebSockets and Server-Sent
> Events are used, the token is transmitted as a query string parameter."

und auf der Security-Seite:
> „Many web servers log the URL for each request, including the query string. Logging the URLs
> may log the access token. ASP.NET Core logs the URL for each request by default […] you can
> write middleware to log the data that you require and filter out the `access_token` query
> string value (if present)."
(https://learn.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz,
https://learn.microsoft.com/en-us/aspnet/core/signalr/security)

Azure Web PubSub unterstützt beides parallel: `/client/?hub={hub}&access_token={token}` **oder**
`Authorization: Bearer {token}`
(https://learn.microsoft.com/en-us/azure/azure-web-pubsub/concept-client-protocols).
AWS AppSync unterstützt drei Wege gleichzeitig: Query-Param, Subprotocol und echte Header
(https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html).

python-websockets bewertet den Query-Param als „fully reliable but less secure", weil
„URIs end up in logs, which leaks credentials"
(https://websockets.readthedocs.io/en/stable/topics/authentication.html).

**Zwei verbreitete Nachteils-Behauptungen, die sich NICHT belegen ließen** — bitte nicht ins
Entscheidungsticket übernehmen:
- **Referrer-Leak:** RFC 6750 §5.3 nennt Referrer, spricht aber von „page URLs". Für
  `new WebSocket(url)` konnte keine Quelle gefunden werden. Der Handshake ist eine
  Subresource-Request; im Referrer landet die *Seiten*-URL, nicht die WS-URL.
- **Browser-History:** `new WebSocket(url)` erzeugt keinen History-Eintrag. Kein Beleg gefunden.

Belegbar bleiben: **Access-Logs, Log-Aggregation/APM, und deren Backups.** Das reicht.

| | |
|---|---|
| **Pro** | Funktioniert in jeder WebSocket-Implementierung inklusive Browser-API; keine Sonderbehandlung nötig; als `Query<T>`-Extractor in Axum trivial. |
| **Contra** | RFC 6750 sagt explizit „SHOULD NOT"; landet per Default in nginx-, Apache- und Caddy-Logs; verschärft sich linear mit erzwungenen Reconnects (siehe §2). |

### 1.3 Option B — `Sec-WebSocket-Protocol`-Missbrauch

**Ist ein JWT ein legaler Subprotocol-Token?** RFC 6455 §4.1:
> „The elements that comprise this value MUST be non-empty strings with characters in the range
> U+0021 to U+007E not including separator characters as defined in [RFC2616]."

RFC 2616 §2.2 definiert als Separatoren: `( ) < > @ , ; : \ " / [ ] ? = { }`, SP, HT
(https://datatracker.ietf.org/doc/html/rfc2616#section-2.2).

`.`, `-` und `_` sind **keine** Separatoren → ein kompakt serialisiertes JWT
(`base64url.base64url.base64url`) ist ein **gültiger** Subprotocol-Token. **Aber `=` ist ein
Separator** → Base64 *mit* Padding wäre illegal. Genau deshalb schreibt Kubernetes
base64url-ohne-Padding vor.

**Die zwingende Echo-Semantik ist der eigentliche Haken.** RFC 6455 §4.2.2: Der Server wählt
„one or none of the acceptable protocols". RFC 6455 §4.1: Gibt der Server ein Subprotokoll
zurück, das der Client nicht angeboten hat, „the client MUST _Fail the WebSocket Connection_".
Browser sind **strenger** als RFC 6455 — WHATWG:
> „If protocols is not the empty list and extracting header list values given
> `Sec-WebSocket-Protocol` and response's header list results in null, failure, or the empty
> byte sequence, then fail the WebSocket connection."
(https://websockets.spec.whatwg.org/#establish-a-websocket-connection)

Bietet der Browser-Client also Subprotokolle an, **muss** der Server eines zurückgeben —
aber er darf natürlich nicht das Token echoen. Daraus folgt zwingend das Kubernetes-Muster:
**mindestens zwei Subprotokolle anbieten**, eines ist das Token, eines das echte Protokoll.

**Kubernetes API-Server, der kanonische Präzedenzfall.**
`bearerProtocolPrefix = "base64url.bearer.authorization.k8s.io."`
> „ProtocolAuthenticator allows a websocket connection to provide a bearer token as a
> subprotocol in the format
> `base64url.bearer.authorization.<base64url-without-padding(bearer-token)>`"
(https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/request/websocket/protocol.go)

Der Handler verlangt mindestens ein weiteres Subprotocol, entfernt bei Erfolg das
Token-Subprotocol und echot die verbleibenden zurück. Motivation aus dem ursprünglichen PR:
„Browser clients do not have the ability to set an Authorization header programmatically on
websocket requests" (https://github.com/kubernetes/kubernetes/pull/47740).

AWS AppSync macht dasselbe mit `header-<base64url(JSON)>` zusätzlich zu `graphql-ws`.

**Log-Verhalten — hier kippt der Vorteil:**
- nginx / Apache: `Sec-WebSocket-Protocol` steht **nicht** im Default-Format.
- **Caddy: der Header wird per Default vollständig geloggt** — `request.headers` ist eine
  komplette Map, und `Sec-WebSocket-Protocol` steht **nicht** auf der Redaction-Liste. Bei Caddy
  ist dieser Weg damit **schlechter** als `Authorization: Bearer`.

**IANA:** Subprotocol-Namen sind „First Come First Served" registriert
(https://www.iana.org/assignments/websocket/websocket.xhtml); ein Token-Präfix wie das von
Kubernetes ist **nicht** registriert. Registrierung ist optional, Kollisionsrisiko theoretisch.

| | |
|---|---|
| **Pro** | Funktioniert in der Browser-API ohne Custom-Header; landet nicht in nginx-/Apache-Default-Logs; von Kubernetes und AWS AppSync in Produktion belegt. |
| **Contra** | Erzwingt das Zwei-Subprotokoll-Konstrukt, sonst schlägt der Browser-Handshake fehl (WHATWG, strenger als RFC); Base64url-Padding muss weg (`=` ist Separator); **bei Caddy per Default im Log**; Proxy-Header-Längenlimits gelten (nginx `large_client_header_buffers`, Default 4×8k — **nicht verifiziert**, vor einer Entscheidung prüfen). |

### 1.4 Option C — Cookie

**Cookies fließen beim Handshake automatisch mit**, normativ: WHATWG „establish a WebSocket
connection" setzt den Request auf „mode is 'websocket', credentials mode is **'include'**"
(https://websockets.spec.whatwg.org/#establish-a-websocket-connection) — auch cross-origin.
Genau daraus entsteht **CSWSH** (Cross-Site WebSocket Hijacking).

RFC 6455 §10.2 zur Origin-Prüfung, und wörtlich zur Grenze des Modells:
> „when the WebSocket Protocol is used by a dedicated client directly […] the origin model is
> not useful, as the client can provide any arbitrary origin string."
(https://datatracker.ietf.org/doc/html/rfc6455#section-10.2)

RFC 6455 §4.1: „This header field is sent by browser clients; for non-browser clients, this
header field may be sent if it makes sense in the context of those clients."

OWASP WSTG-CLNT-10: „It is the server's responsibility to verify the `Origin` header in the
initial HTTP WebSocket handshake."
(https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets)

Microsoft SignalR Security dagegen: „The protections provided by CORS don't apply to
WebSockets." und „The `Origin` header is controlled by the client and, like the `Referer`
header, can be faked. These headers should **not** be used as an authentication mechanism."

**Gilt SameSite für WS-Handshakes? — Ableitung, nicht wörtlich belegt.**
draft-ietf-httpbis-rfc6265bis §5.6.7.1 lässt Lax nur gelten, „if and only if they are top-level
navigations which use a 'safe' […] HTTP method"
(https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis). Ein WS-Handshake ist
keine Top-Level-Navigation → Lax und Strict blocken den cross-site Handshake. **Das Wort
„WebSocket" kommt in rfc6265bis nicht vor.** Die Aussage stützt sich zusätzlich auf das OWASP
WebSocket Security Cheat Sheet („Use SameSite cookies […] to strengthen CSWSH defenses",
https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) — diese
Seite trägt allerdings **kein verifizierbares Datum**.

**Tauri-spezifische Komplikation — zwei getrennte Cookie-Stores:**
- WebView hat eine eigene Cookie-Jar; Tauri v2.4.0 führte `Webview::cookies()` /
  `cookies_for_url()` ein (https://v2.tauri.app/release/tauri/v2.4.0/).
- `tauri-plugin-http` nutzt den reqwest-Store — dokumentiertes offenes Problem, dass beide
  nicht synchron sind: https://github.com/tauri-apps/tauri/issues/13045
- Origin im Tauri-WebView ist ein Custom-Scheme (`tauri://localhost`, unter Windows
  `http://tauri.localhost`) — Origin-Allowlisting muss das kennen:
  https://github.com/tauri-apps/tauri/discussions/4912
- `tokio-tungstenite` hat **keine** Cookie-Jar; Cookies müssten manuell als Header gesetzt werden.

| | |
|---|---|
| **Pro** | `HttpOnly` schützt gegen XSS-Auslesen; wird per Default nicht geloggt (Caddy redigiert explizit); im Browser vollautomatisch. |
| **Contra** | CSWSH — CORS greift nicht, Origin-Prüfung ist die einzige Verteidigung und ist bei Nicht-Browser-Clients wertlos (RFC 6455 §10.2 sagt das selbst); SameSite-Wirksamkeit ist abgeleitet, nicht wörtlich belegt; in Tauri zwei inkonsistente Cookie-Stores; im Rust-Client-Layer gar kein natürliches Konstrukt; passt schlecht zum Multi-Server-Modell der Map (N Server = N Cookie-Domains). |

### 1.5 Option D — Erstes Auth-Frame nach dem Handshake

**Wer macht das, mit belegten Timeouts und Close-Codes:**

| System | Ablauf | Timeout | Fehler-Code | Quelle |
|---|---|---|---|---|
| **graphql-ws** | `ConnectionInit` mit `payload` → `ConnectionAck` | `connectionInitWaitTimeout`, `@default 3_000` (3 s) | `4408` Init-Timeout; `4401` Unauthorized, `4403` Forbidden (empfohlen) | https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md |
| **Centrifugo** | `connect`-Command mit `{"token":"<JWT>"}` | `client.stale_close_delay`, Default `"10s"` | `3502 "stale"`, `3500 "invalid token"` (terminal) | https://centrifugal.dev/docs/server/codes |
| **Home Assistant** | Server: `auth_required` → Client: `{"type":"auth","access_token":…}` → `auth_ok`/`auth_invalid` | nicht dokumentiert | — | https://developers.home-assistant.io/docs/api/websocket/ |
| **Discord Gateway** | Nach `Hello` (op 10) sendet der Client `Identify` (op 2) | nicht dokumentiert | `4003` Not authenticated (reconnect **true**), `4004` Authentication failed (reconnect **false**) | https://docs.discord.com/developers/events/gateway |
| **Pusher Channels** | `pusher:signin` über den offenen Socket | impliziert | `4009` (Bereich 4000–4099 = „SHOULD NOT be re-established unchanged") | https://pusher.com/docs/channels/library_auth_reference/pusher-websockets-protocol/ |
| **Socket.IO** | `auth`-Option → `socket.handshake.auth.token`, Middleware vor Connect | — | „the connection will be refused and the client will receive a `connect_error` event" | https://socket.io/docs/v4/middlewares/ |

**Korrektur zu einer verbreiteten Annahme:** *Phoenix Channels* wird oft als Beispiel für dieses
Muster genannt, ist aber keines — Phoenix übergibt den Token als Socket-**Param**, also im
Query-String (`new Socket("/socket", {authToken: window.userToken})`, geprüft in `connect/3` via
`Phoenix.Token.verify(…, max_age: 1209600)`, https://phoenix.hexdocs.pm/channels.html). Als
Beleg für Option D nicht verwendbar.

python-websockets bewertet diesen Weg als „fully reliable and the most secure mechanism", merkt
aber an, dass Auth damit auf der **Anwendungsschicht** stattfindet, nach abgeschlossenem
Handshake (https://websockets.readthedocs.io/en/stable/topics/authentication.html).

| | |
|---|---|
| **Pro** | Token verlässt nie die HTTP-Schicht → **landet in keinem Access-Log**, egal welcher Proxy; funktioniert in Browser-API und Rust-Client identisch; erlaubt strukturierte Fehler statt `1006`; derselbe Kanal trägt später den Re-Auth (§2.2). |
| **Contra** | Unauthentifizierte Sockets belegen Ressourcen bis zum Timeout → DoS-Fläche (genau dagegen existieren graphql-ws' 3 s und Centrifugos `3502 "stale"`); kein HTTP-401 mehr möglich, nur Close-Codes; Auth wandert in die Applikationsschicht und muss dort selbst gegen Missbrauch gehärtet werden (Centrifugo hat dafür eigene Codes `3013 too many requests`, `3509 too many errors`). |

### 1.6 Option E — Rust-Client mit voller Header-Kontrolle (`Authorization: Bearer`)

Wenn die Verbindung im Tauri-Rust-Layer lebt (siehe Ticket *Wo lebt die WS-Verbindung im
Client*), entfällt die Browser-Beschränkung vollständig.

`tungstenite::client::IntoClientRequest` ist implementiert für `&str`, `String`, `Uri`, `Url`,
**`http::Request<()>`**, `httparse::Request`, `ClientRequestBuilder`
(https://docs.rs/tungstenite/latest/tungstenite/client/trait.IntoClientRequest.html).

`ClientRequestBuilder`
(https://docs.rs/tungstenite/latest/tungstenite/client/struct.ClientRequestBuilder.html):
> „Builder for a custom `IntoClientRequest` with options to add custom additional headers and
> sub protocols."
> `with_header()`: „Adds (`key`, `value`) as an additional header to the handshake request"
> `with_sub_protocol()`: „Adds `protocol` to the handshake request subprotocols"

Praxis-Pattern:
```rust
let mut request = "wss://api.example.com/ws".into_client_request()?;
request.headers_mut().insert("Authorization", "Bearer token123".parse()?);
let (ws_stream, response) = connect_async(request).await?;
```

**Fehlerdetails sind hier verfügbar** — `tungstenite::Error::Http(Box<Response<Option<Vec<u8>>>>)`
trägt Statuscode und Body
(https://docs.rs/tungstenite/latest/tungstenite/error/enum.Error.html). Ein 401 mit
strukturiertem JSON-Grund ist auswertbar; im WebView nicht (siehe Vorbemerkung).

**Auch aus dem React-Frontend erreichbar, ohne eigenen Rust-Command:**
`tauri-plugin-websocket` — „Open a WebSocket connection using a Rust client in JavaScript"
(https://v2.tauri.app/plugin/websocket/). Die `ConnectionConfig` enthält laut Referenz das Feld
**`headers?`** neben `maxMessageSize`, `maxFrameSize` etc.
(https://v2.tauri.app/reference/javascript/websocket/). Preis: es ist nicht die
Browser-`WebSocket`-API — kein `WebSocket`-Objekt, keine `wasClean`-Semantik, IPC-Bridge im
Datenpfad. *(Der exakte Feldtyp und das Verhalten bei verbotenen Headern wurden nicht verifiziert.)*

**Proxy-Einschränkung, relevant für Firmenkunden:** tokio-tungstenite bringt **keinen** eigenen
HTTP-/SOCKS-Proxy-Support mit — `connect_async` ist nur mit „Connect to a given URL"
dokumentiert (https://docs.rs/tokio-tungstenite/). Ein CONNECT-Tunnel muss selbst aufgebaut und
der fertige Stream an `client_async` übergeben werden.

| | |
|---|---|
| **Pro** | Der einzige Weg, der von RFC 6750 §2.3 ausdrücklich als der richtige benannt wird; **wird von nginx und Apache per Default nicht geloggt, von Caddy explizit redigiert**; volle Fehlerdetails (401 mit Body) statt `1006`; keine Zwei-Subprotokoll-Akrobatik. |
| **Contra** | Setzt voraus, dass die Verbindung im Rust-Layer lebt (Kopplung an ein anderes Ticket); kein Proxy-Support in tokio-tungstenite → CONNECT-Tunnel selbst bauen, was bei Firmenkunden mit expliziter Proxy-Konfiguration Arbeit ist; über `tauri-plugin-websocket` verliert man die Browser-`WebSocket`-Semantik im Frontend. |

### 1.7 Querschnitt-Option — kurzlebige Einweg-„Ticket"-Tokens

Nicht exklusiv zu A–E, sondern **kombinierbar**: ein Ticket per authentifiziertem REST-Call
holen und dieses (statt des langlebigen JWT) an den Handshake hängen.

- **Azure Web PubSub „Client Access URL"**, Lebensdauer explizit konfigurierbar
  (`expirationTimeInMinutes: 5`):
  > „The client negotiates with your application server. The application server contains the
  > authorization middleware, which handles the client request and signs a JWT for the client to
  > connect to the service. […] The client tries to connect to the Web PubSub service by using
  > the URL and the JWT returned from the application server."
  (https://learn.microsoft.com/en-us/azure/azure-web-pubsub/howto-generate-client-access-url,
  `ms.date: 2024-10-17`)
- **Slack RTM:** „The Websocket URLs provided by `rtm.connect` are single-use and are only valid
  for **30 seconds**" (https://docs.slack.dev/legacy/legacy-rtm-api/) — Achtung, RTM ist als
  Legacy markiert.
- **Ably** — Token-Request-Flow via `authUrl`/`authCallback` (https://ably.com/docs/auth/token).
- python-websockets nennt Single-Use-Tokens ausdrücklich als Mitigation für den Query-Param-Weg.

**Es gibt dafür keine RFC-/OWASP-Quelle** — das ist Herstellerpraxis, kein Standard.

| | |
|---|---|
| **Pro** | Reduziert den Schaden eines Log-Leaks von „Sitzungsdauer" auf „Sekunden bis Minuten"; entkoppelt das langlebige JWT vom Handshake-Kanal; macht Option A dadurch deutlich weniger heikel. |
| **Contra** | Zusätzlicher REST-Roundtrip vor jedem (Re-)Connect — verschärft den Thundering Herd (§4); zusätzlicher serverseitiger Zustand (Einmal-Verbrauch, Ablauf) — steht in Spannung zur „eine Binary + Postgres"-Regel der Map; kein Standard, jede Implementierung ist eigen. |

### 1.8 Close-Codes für Auth-Fehler

IANA-Registry (https://www.iana.org/assignments/websocket/websocket.xhtml), Policy:
1000–2999 „Standards Action, Specification Required or IESG Review"; **3000–3999 „First Come
First Served"; 4000–4999 „Reserved for Private Use"**. RFC 6455 §7.4.2 formuliert dasselbe.

Registriert und relevant: `1008 Policy Violation`, `1011 Internal Error`. Im 3000er-Bereich
existieren `3000 Unauthorized`, `3003 Forbidden`, `3008 Timeout` — **alle ohne Reference-Spalte**,
also private First-Come-First-Served-Einträge ohne Spezifikation, keine Standardsemantik.

**Etablierte Praxis im privaten Bereich:**

| System | Codes |
|---|---|
| graphql-ws | `4400` Bad Request, `4401` Unauthorized, `4403` Forbidden, `4408` Init-Timeout, `4429` Too many init requests |
| Discord | `4003` Not authenticated (reconnect true), **`4004` Authentication failed (reconnect false)**, `4005` Already authenticated |
| Pusher | Bereichs-Semantik: **4000–4099** „SHOULD NOT be re-established unchanged"; **4100–4199** „SHOULD be re-established after backing off"; **4200–4299** „SHOULD be re-established immediately" |
| Centrifugo | nicht-terminal: `3005` connection expired, `3011` force reconnect. Terminal: `3500` invalid token, `3502` stale, `3507` permission denied |

**Musterbefund:** Alle vier Systeme kodieren nicht nur *warum*, sondern auch **ob der Client
reconnecten darf**. Das ist die tragende Semantik, nicht die Fehlerbenennung — und sie ist die
Voraussetzung dafür, dass §4.4 (Reconnect-Klassen) überhaupt funktioniert.

---

## 2. Token-Ablauf bei stundenlanger Verbindung

### 2.1 Die Grundsatzfrage: gilt Auth nur beim Handshake?

Die klarste Primärquelle ist Microsofts SignalR-Doku
(https://learn.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz, `updated_at: 2026-08-12`):
> „SignalR captures the authenticated user when a connection is established and caches it for the
> lifetime of the connection. […] **SignalR doesn't automatically revalidate the user during the
> life of the connection, regardless of the authentication scheme.** This behavior applies to all
> schemes, including cookie authentication and bearer token authentication."
> „Changes to a user's identity, roles, or claims that occur after the connection is established
> aren't reflected on an existing connection."
> „If a token expires during the lifetime of a connection, by default the connection continues to
> work."

Konkretes Szenario aus derselben Seite: Nutzer verliert die `Editor`-Rolle → „The user can keep
calling `Editor`-only hub methods until the connection is closed." Die dort genannten
Gegenmittel sind wörtlich:
> „Close affected connections so that clients reconnect and reauthenticate. For bearer token
> authentication, the `CloseOnAuthenticationExpiration` option closes connections when the
> authentication token expires."
> „Perform authorization checks in hub methods against current data, such as the user's current
> roles or claims from a data store, instead of relying only on the cached principal."

OWASP WebSocket Security Cheat Sheet (kein verifizierbares Datum):
> „Close WebSocket connections when sessions expire. Re-validate user sessions periodically
> (every 30 minutes is common)…"
> „Rotate tokens in long-lived connections to prevent hijacked sessions from persisting."
> „When users log out, close all their WebSocket connections immediately."
> „Don't assume WebSocket connection equals unlimited access. Check authorization for each action."

**Negativer Befund:** Auth0/Okta haben **keine** auffindbare WebSocket-spezifische Dokumentation
zum Token-Ablauf. Alle Treffer waren Community-Inhalte. Nicht als Beleg verwenden.

### 2.2 Option A — Verbindungs-TTL / erzwungener Reconnect

**AWS API Gateway WebSocket API**, harte, **nicht erhöhbare** Quotas
(https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-execution-service-websocket-limits-table.html):

| Quota | Wert | Erhöhbar |
|---|---|---|
| Connection duration for WebSocket API | **2 Stunden** | Nein |
| Idle Connection Timeout | **10 Minuten** | Nein |
| WebSocket frame size | 32 KB | Nein |
| Message payload size | 128 KB | Nein |

**AWS AppSync Realtime:** „AWS AppSync keeps sending these messages and servicing the registered
subscriptions until it shuts down the connection automatically (**after 24 hours**)"
(https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html).

| | |
|---|---|
| **Pro** | Einfachste denkbare Implementierung — ein Timer pro Verbindung; Auth-Zustand kann nie länger gültig sein als das Token; Revocation greift spätestens nach einer TTL, ohne dass der Server eine Liste führen muss. |
| **Contra** | **Multipliziert die Anzahl der Handshakes** — bei 2 h TTL sind das 12 Handshakes pro Tag pro Client statt einem. In Kombination mit Option 1.2 (Query-String) heißt das 12 Log-Zeilen mit Token statt einer. Das ist die direkte Wechselwirkung zwischen §1 und §2: **kurze TTL verschlimmert den Query-String-Nachteil linear.** Zusätzlich: jeder erzwungene Reconnect ist ein Backfill-Zyklus (`?since`) und, wenn alle TTLs synchron ablaufen, ein selbstgemachter Thundering Herd (§4.3). |

### 2.3 Option B — In-Band-Re-Auth über den offenen Socket

| System | Mechanismus | Semantik | Quelle |
|---|---|---|---|
| **Centrifugo** | `refresh`-Command (und `sub_refresh` für Subscriptions): „Renew an expiring connection / subscription token." Client bekommt beim Connect ein `ttl`; „Centrifugo SDKs handle this `ttl` internally and automatically begin the refresh process." Nach Ablauf: Grace Period (Default 25 s), dann Disconnect `3005 connection expired` | Verbindung bleibt bestehen | https://centrifugal.dev/docs/server/authentication |
| **Ably** | `authUrl`/`authCallback`: „the SDK automatically: 1. Calls your auth endpoint when connecting 2. Requests a new token **before** the current token expires 3. Maintains the connection seamlessly during refresh". `authorize()` „maintains the existing connection while updating permissions". Ohne `authUrl`/`authCallback`: „if your token expires and an SDK has no way to get a new token […] the connection will enter the `FAILED` state" | Verbindung bleibt bestehen | https://ably.com/docs/auth/token |
| **AWS AppSync** | Authorization wird **pro Subscription-Registrierung** erneut mitgesendet (`start`-Message hat `extensions.authorization`) | Pro-Operation-Auth | https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html |
| **SignalR** | `accessTokenFactory` wird „before **every** HTTP request made by SignalR" aufgerufen — bei WebSockets faktisch nur beim (Re-)Connect, da es nur einen Request gibt | de facto nur beim Reconnect | https://learn.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz |

Ablys Fehlercodes: `40140` = „token error (unspecified)", Bereich `40140 ≤ code < 40150` =
Token-Fehler, `40142` = „token expired"; dokumentierte Client-Regel: **einen** automatischen
Reissue-Versuch, dann Request wiederholen
(https://github.com/ably/ably-common/blob/main/protocol/errors.json).

| | |
|---|---|
| **Pro** | Das neue Token wird **im WS-Frame** übertragen und landet damit in **keinem** Access-Log — der wesentliche Vorteil gegenüber reconnect-basiertem Refresh im gegebenen Bedrohungsmodell; keine Verbindungsabbrüche, kein Backfill-Zyklus, kein Reconnect-Sturm. |
| **Contra** | Application-Layer-Auth statt HTTP-Statuscode; der Server muss den Refresh-Pfad selbst gegen Missbrauch härten (Rate-Limiting — Centrifugo braucht dafür eigene Codes `3013 too many requests`, `3509 too many errors`); zusätzliche Protokoll-Nachrichten im ansonsten als „Dumb Pipe" gesetzten Kanal (siehe Map: die Naht verläuft entlang *persistiert vs. flüchtig* — ein Re-Auth-Frame ist weder das eine noch das andere und braucht eine Einordnung). |

### 2.4 Option C — Serverseitige Revocation-Liste

Firebase (https://firebase.google.com/docs/auth/admin/manage-sessions):
> „Firebase ID tokens are short lived and last for an hour; the refresh token can be used to
> retrieve new ID tokens."
> „Because Firebase ID tokens are stateless JWTs, you can determine a token has been revoked only
> by requesting the token's status from the Firebase Authentication backend."

Revocation-Check ist dort **opt-in** (`verifyIdToken(idToken, checkRevoked)`); für die Realtime
Database wird stattdessen ein Security-Rules-Muster dokumentiert
(`auth.token.auth_time > root.child('metadata').child(auth.uid).child('revokeTime').val()`).
**Die Doku sagt nirgends, dass RTDB/Firestore bei Revocation eine bestehende Verbindung
terminiert.**

| | |
|---|---|
| **Pro** | Einziger Mechanismus, der auf „Logout auf allen Geräten" und Gerätediebstahl *sofort* reagiert, ohne die TTL abzuwarten; erlaubt lange Verbindungen ohne kurze Token-TTL. |
| **Contra** | **Im Bedrohungsmodell dieses Projekts per Definition wirkungslos gegen den Betreiber** — er kontrolliert die Liste. Sie adressiert ausschließlich „gestohlenes Token bei ansonsten korrektem Server", also ein anderes Bedrohungsmodell, das im Entscheidungsticket getrennt geführt werden sollte. Praktisch: serverseitiger Zustand bei jedem Check (DB-Lookup pro Frame wäre teuer, Cache bringt Konsistenzfenster zurück). |

### 2.5 Randnotiz: RFC 8441 (WebSockets über HTTP/2)

https://datatracker.ietf.org/doc/html/rfc8441 — Extended CONNECT mit `:protocol = "websocket"`,
ausgehandelt via `SETTINGS_ENABLE_CONNECT_PROTOCOL`. Für Auth ändert sich **nichts**:
> „The Origin, Sec-WebSocket-Version, Sec-WebSocket-Protocol, and Sec-WebSocket-Extensions header
> fields are used in the CONNECT request."
> „Other HTTP request and response-header fields, such as those for manipulating cookies, may be
> included […] as usual."
> „The security considerations of [RFC6455], Section 10 continue to apply."

`Sec-WebSocket-Key`/`Sec-WebSocket-Accept` entfallen. Axum 0.8 unterstützt das (siehe §5.1);
relevant vor allem, weil sich unter H2 die Logging-Formate ändern (`:path` statt Request-Line)
— **nicht separat verifiziert**.

---

## 3. Heartbeat

### 3.1 Protokoll-Ebene (RFC 6455)

**§5.5 Control Frames:**
> „All control frames MUST have a payload length of 125 bytes or less and MUST NOT be fragmented."

**§5.5.2 Ping** (Opcode `0x9`):
> „Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in response, unless it already
> received a Close frame. It SHOULD respond with Pong frame as soon as is practical."
> „An endpoint MAY send a Ping frame any time after the connection is established and before the
> connection is closed. A Ping frame may serve either as a keepalive or as a means to verify that
> the remote endpoint is still responsive."

**§5.5.3 Pong** (Opcode `0xA`):
> „A Pong frame sent in response to a Ping frame must have identical Application data as found in
> the message body of the Ping frame being replied to."
> „A Pong frame MAY be sent unsolicited. This serves as a unidirectional heartbeat."

(https://www.rfc-editor.org/rfc/rfc6455.txt)

Konsequenz: Der Ping-Payload (≤125 B) ist der einzige Korrelationsmechanismus auf Protokollebene
— z. B. Sequenz-Counter oder Timestamp für RTT-Messung. Unsolicited Pong ist normkonform,
erzeugt aber **keine Antwort** und taugt daher nur zum Idle-Timer-Reset, nicht zur
Liveness-Prüfung.

### 3.2 Die Browser-Beschränkung — hart belegt

WHATWG WebSockets Standard, §5 „Ping and Pong frames" (https://websockets.spec.whatwg.org/):
> „The WebSocket protocol defines Ping and Pong frames that can be used for keep-alive,
> heart-beats, network status probing, latency instrumentation, and so forth. **These are not
> currently exposed in the API.**
> User agents may send ping and unsolicited pong frames as desired […] User agents must not use
> pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs
> whenever appropriate for the server's needs."

Die IDL kennt nur `send()` und `close()` — kein `ping()`, kein `pong`-Event; MDN listet exakt
diese zwei Instance Methods und erwähnt Ping/Pong-Frames überhaupt nicht
(https://developer.mozilla.org/en-US/docs/Web/API/WebSocket).

Browser *antworten* auf Server-Pings automatisch (RFC-konform), zeigen die Auto-Pongs aber nicht
in den DevTools; Chrome sendet selbst keine Ping-Frames, sondern nutzt `SO_KEEPALIVE` auf
TCP-Ebene (Issue-Tracker, keine normative Doku:
https://issues.chromium.org/issues/41309915, https://bugzilla.mozilla.org/show_bug.cgi?id=920074).

**Konsequenz für Tauri:** Läuft die Verbindung im WebView (WebView2 / WKWebView / WebKitGTK,
https://v2.tauri.app/reference/webview-versions/), ist ein **Application-Level-Heartbeat** (z. B.
`{"type":"ping"}` als Text-Frame) der **einzige** Weg, clientseitig Liveness festzustellen.
Genau deshalb bauen Socket.IO/Engine.IO eigene Ping-Packet-Typen statt RFC-6455-Control-Frames.
Läuft sie im Rust-Layer, sind Protokoll-Pings verfügbar.

**Negativer Befund:** Weder https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API noch
„Writing WebSocket client applications" enthalten heute einen Abschnitt „Proxy servers and
firewalls" oder überhaupt eine Erwähnung von Proxies/Ping-Pong. Die früher oft zitierte
MDN-Passage existiert nicht mehr und ist nicht zitierfähig.

### 3.3 Rust-Ebene — automatisches Pong

axum 0.8 `Message`-Doku
(https://docs.rs/axum/0.8.9/axum/extract/ws/enum.Message.html), wörtlich:
> `Ping`: „Ping messages will be automatically responded to by the server, so you do not have to
> worry about dealing with them yourself."
> `Pong`: „Pong messages will be automatically sent to the client if a ping message is received,
> so you do not have to worry about constructing them yourself **unless you want to implement a
> unidirectional heartbeat**."

tungstenite (https://docs.rs/tungstenite/latest/tungstenite/protocol/struct.WebSocket.html):
> „upon receiving ping messages tungstenite queues pong replies automatically. […] This means you
> should not respond to ping frames manually."
> „Note that if `read` returns a ping, you should `flush` before passing a custom pong to `write`,
> otherwise the automatic queued response to the ping will not be sent as it will be replaced by
> your custom pong message."
> (an `read`) „This will also queue responses to ping and close messages. These responses will be
> written and flushed on the next call to `read`, `write` or `flush`."

Drei praktische Fallstricke daraus: (a) Das Auto-Pong wird nur **gequeued** — ohne
nachfolgendes `read`/`write`/`flush` geht es nicht raus (in einer dauerhaft gepollten
Split-Stream-Schleife erfüllt); (b) der Handler *sieht* `Ping`/`Pong` trotzdem im Stream, muss
aber nicht reagieren; (c) ein eigener Pong-Send kann das Auto-Pong verdrängen.

### 3.4 Warum TCP-Keepalive nicht reicht — vier belegte Gründe

`man 7 tcp` (https://man7.org/linux/man-pages/man7/tcp.7.html):
> `tcp_keepalive_time (integer; default: 7200)` — „The number of seconds a connection needs to be
> idle before TCP begins sending out keep-alive probes. **Keep-alives are sent only when the
> SO_KEEPALIVE socket option is enabled.** […] **Note that underlying connection tracking
> mechanisms and application timeouts may be much shorter.**"

1. **Per Default aus** — greift erst nach explizitem `SO_KEEPALIVE`.
2. **7200 s ist länger als jeder Proxy-Timeout** aus der Tabelle in §3.5 (30 s … 600 s). Der
   erste Probe kommt, wenn die Verbindung längst tot ist.
3. **Keepalive-Probes tragen keine Nutzdaten** und resetten L7-Idle-Timer nicht. AWS Classic ELB
   wörtlich: „TCP keep-alive probes do not prevent the load balancer from terminating the
   connection because they do not send data in the payload."
   (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-idle-timeout.html)
4. **L7-Terminierung trennt die Verbindungen** — nginx/ALB/AppGW halten zwei getrennte
   TCP-Sessions; ein Keepalive auf dem Client-Leg erreicht das Origin nie.

Gegenprobe: Bei L4-Load-Balancern (NLB, TCP-Listener) *resetten* TCP-Keepalives den Idle-Timer.
HTTP/2-PING-Frames zählen beim ALB dagegen explizit **nicht**: „Application Load Balancers do not
support HTTP/2 PING frames. These do not reset the connection idle timeout."
(https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html)

### 3.5 Verhalten hinter Proxies und Corporate-Firewalls

**Der härteste Beleg für „wss statt ws" — RFC 6455 §1.8:**
> „At the time of writing of this specification, it should be noted that **connections on ports
> 80 and 443 have significantly different success rates, with connections on port 443 being
> significantly more likely to succeed**, though this may change with time."

**RFC 6455 §4.1 zum expliziten Proxy:**
> „If the client is configured to use a proxy when using the WebSocket Protocol to connect to host
> /host/ and port /port/, then the client SHOULD connect to that proxy and ask it to open a TCP
> connection" (Beispiel: `CONNECT example.com:80 HTTP/1.1`, optional mit `Proxy-authorization`)
> „Implementations […] are encouraged to use a SOCKS5 [RFC1928] proxy for WebSocket connections,
> if available, or failing that, **to prefer the proxy configured for HTTPS connections over the
> proxy configured for HTTP connections**."

**RFC 6455 §10.3** erklärt, warum Client-Masking überhaupt existiert: damit Intermediaries
WS-Frames nicht als HTTP-Requests fehlinterpretieren („a client MUST mask all frames that it
sends to the server […] whether or not the WebSocket Protocol is running over TLS").

**Idle-Timeouts der Infrastruktur — die Zahlen, die das Heartbeat-Intervall bestimmen:**

| Hop | Default | Konfigurierbar | Quelle |
|---|---|---|---|
| **Azure Application Gateway request timeout** (gilt für die WS-Session!) | **20 s** | 1–86400 s | https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-websocket |
| **GCP ALB backend service timeout** | **30 s** | 1 s–… | https://docs.cloud.google.com/load-balancing/docs/https/request-distribution |
| **nginx `proxy_read_timeout`** | **60 s** | ja | https://nginx.org/en/docs/http/ngx_http_proxy_module.html |
| **AWS ALB / Classic ELB idle** | **60 s** | 1–4000 s | https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html |
| **Azure Load Balancer TCP idle** | **4 min** | 4–100 min | https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout |
| **AWS NLB TCP/TLS** | **350 s** | 60–6000 s (TCP) | AWS-Doku |
| **AWS API Gateway WS idle** | **10 min** | **nein** | s. §2.2 |
| **AWS API Gateway WS max. Dauer** | **2 h** | **nein** | s. §2.2 |
| **GCP global ext. ALB, aktive WS** | **24 h** (fix) | nein | GCP-Doku |
| **Linux `tcp_keepalive_time`** | **7200 s** | ja | `man 7 tcp` |

nginx, Schlusssatz der WebSocket-Seite (https://nginx.org/en/docs/http/websocket.html), wörtlich:
> „By default, the connection will be closed if the proxied server does not transmit any data
> within 60 seconds. This timeout can be increased with the `proxy_read_timeout` directive.
> Alternatively, **the proxied server can be configured to periodically send WebSocket ping frames
> to reset the timeout and check if the connection is still alive.**"

Azure Application Gateway, wörtlich — der einzige Anbieter, der eine konkrete Faustregel für das
Heartbeat-Intervall nennt:
> „Ensure that your timeout value is greater than your server-defined ping/pong interval to avoid
> experiencing timeout errors before a ping is sent from the client. **A typical value for a
> WebSocket is 20 seconds, so, for example, a timeout value of 40 seconds** ensures that the
> gateway doesn't send a timeout error before the client sends a ping. Otherwise, this condition
> throws a **1006 error** on the client side."

GCP, wichtige Unterscheidung:
> Global external ALB: „Active websocket connections don't use the configured backend service
> timeout […] closed after 24 hours (86,400 seconds). This 24-hour limit is fixed […] **Idle
> websocket connections are closed after the backend service times out.**"
> Classic ALB: „Websocket connections, **whether idle or active**, automatically close after the
> backend service times out." (Default 30 s!)

**Cloudflare — Korrektur einer verbreiteten Zahl:** Die kursierenden „100 Sekunden" stehen in
**keiner** Cloudflare-Primärquelle. https://developers.cloudflare.com/network/websockets/
dokumentiert nur qualitativ:
> „Cloudflare will close a WebSocket connection when no data is transmitted in either direction
> for a period of time. Enterprise customers can contact their account team to configure a custom
> idle timeout. **To keep long-lived connections alive during periods of inactivity, implement a
> client-side heartbeat (ping/pong) mechanism.**"
> „When Cloudflare releases new code to its global network, we may restart servers, **which
> terminates WebSockets connections.**"

**HAProxy — Korrektur:** Es gibt **keine** dokumentierten numerischen Defaults für
`timeout client`/`server`/`tunnel`; die oft zitierten „50s" stammen aus Distro-Beispiel-Configs.
Die Doku (https://docs.haproxy.org/3.0/configuration.html §4.2) sagt zu `timeout tunnel`:
> „This timeout **supersedes both the client and server timeouts** once the connection becomes a
> tunnel. […] In HTTP, this timeout is used when a connection is upgraded (e.g. when switching to
> the WebSocket protocol…)" — Doku-Beispiel: `timeout tunnel 1h`

**Tauri-spezifisch:** Der System-WebView respektiert die OS-Proxy-Konfiguration; eine Tauri-API
zum Setzen von Proxy-Einstellungen fehlte lange (https://github.com/tauri-apps/tauri/issues/4263,
wry-Limitierung). Bei WebView2 lässt sich `--proxy-server` über `AdditionalBrowserArguments`
setzen. Für den Rust-seitigen WS-Client gilt §1.6: CONNECT-Tunnel selbst bauen.

### 3.6 Übliche Intervalle etablierter Systeme

| System | Intervall | Timeout | Quelle |
|---|---|---|---|
| **Socket.IO v4** | `pingInterval` **25000 ms** | `pingTimeout` **20000 ms**, `connectTimeout` 45000 ms | https://socket.io/docs/v4/server-options/ |
| **Phoenix JS** | `heartbeatIntervalMs` **30000 ms** | `DEFAULT_TIMEOUT` 10000 ms | https://github.com/phoenixframework/phoenix/blob/main/assets/js/phoenix/socket.js |
| **Centrifugo** | `client.ping_interval` **„25s"** | `client.pong_timeout` **„8s"**, `stale_close_delay` „10s" | https://centrifugal.dev/docs/server/configuration |
| **Discord Gateway** | server-diktiert via `heartbeat_interval` (Doku-Beispiel `45000`) | kein ACK → Reconnect | https://docs.discord.com/developers/events/gateway |
| **Slack RTM (legacy)** | „every few seconds" | — | https://docs.slack.dev/legacy/legacy-rtm-api/ |
| **MQTT v5.0** | `Keep Alive` (client-gewählt) | **1,5 × Keep Alive** | https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html (07.03.2019) |

Socket.IO, wörtlich — die klarste Formulierung der beidseitigen Erkennung:
> „The server sends a ping packet every `pingInterval` ms, and if the client does not answer with
> a pong within `pingTimeout` ms, the server considers that the connection is closed. Similarly,
> if the client does not receive a ping packet from the server within
> `pingInterval + pingTimeout` ms, then the client also considers that the connection is closed."
> Warnung: „Using a small value like `1000` (one heartbeat per second) will incur some load on
> your server, which might become noticeable with a few thousands connected clients."

Discord, wörtlich — **Jitter schon beim ersten Heartbeat**:
> „your app should wait `heartbeat_interval * jitter` where `jitter` is any random value between
> 0 and 1, then send its first Heartbeat."
> „If a client does not receive a heartbeat ACK between its attempts at sending heartbeats, this
> may be due to a failed or 'zombied' connection. The client should **immediately terminate the
> connection with any close code besides `1000` or `1001`**, then reconnect and attempt to Resume."

MQTT v5.0 §3.1.2.10:
> „If the Keep Alive value is non-zero and the Server does not receive an MQTT Control Packet from
> the Client within one and a half times the Keep Alive time period, it MUST close the Network
> Connection"

Slack RTM zeigt zusätzlich das Latenz-Muster: „a client could include a local timestamp in the
ping message so it can calculate round-trip latency" (Server echot die Felder zurück) — das
entspricht der RFC-6455-Payload-Korrelation aus §3.1.

**Korrektur:** Der oft genannte Discord-Wert **41250 ms** ist nicht dokumentiert; die aktuelle
Doku zeigt `45000` im Beispiel. Der Wert ist server-diktiert und nicht garantiert.

### 3.7 Optionen-Gegenüberstellung Heartbeat

| Option | Pro | Contra |
|---|---|---|
| **Protokoll-Ping/Pong (RFC 6455)** | Vom Standard vorgesehen; von axum/tungstenite serverseitig **automatisch** beantwortet, also kein Applikationscode für die Antwort; Payload-Korrelation für RTT; resettet L7-Idle-Timer, weil es echte Frames sind (im Gegensatz zu TCP-Keepalive) | **Im Browser-WebView nicht auslösbar und nicht beobachtbar** (WHATWG: „not currently exposed in the API") → clientseitige Liveness-Erkennung unmöglich; unsolicited Pong erzeugt keine Antwort und beweist nichts |
| **Application-Level-Heartbeat (JSON-Frame)** | Funktioniert in WebView und Rust-Layer identisch; beidseitige Liveness-Erkennung; kann Nutzlast tragen (Cursor, Server-Zeit, `reconnect_after`-Hinweis); von Socket.IO, Phoenix, Centrifugo, Discord durchgehend so gebaut | Zusätzliche Protokoll-Nachrichten im als „Dumb Pipe" gesetzten Kanal; kostet Serverlast bei vielen Verbindungen (Socket.IO warnt explizit ab ~1 s Intervall bei „a few thousands connected clients"); doppelt sich mit dem Protokoll-Ping, wenn beides läuft |
| **Nur TCP-Keepalive** | Kein Applikationscode | Vier belegte Gründe dagegen (§3.4) — Default 7200 s, per Default aus, kein L7-Timer-Reset, greift nicht über L7-Terminierung hinweg |

**Intervall-Korridor aus den Zahlen:** Die kleinsten dokumentierten Infrastruktur-Timeouts liegen
bei 20 s (Azure AppGW) bzw. 30 s (GCP Classic ALB Default). Die etablierten
Application-Heartbeats liegen bei 25–30 s. Azures eigene Faustregel („typical value for a
WebSocket is 20 seconds […] timeout value of 40 seconds") beschreibt dasselbe Verhältnis von
etwa 1:2 zwischen Heartbeat und Idle-Timeout.

---

## 4. Reconnect-Strategie

### 4.1 Exponentielles Backoff mit Jitter — die Referenz

**Marc Brooker, „Exponential Backoff And Jitter", AWS Architecture Blog, 4. März 2015**
(https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/), mit
Autoren-Update: *„Update (May 2023): After 8 years, this solution continues to serve as a pillar
for how Amazon builds remote client libraries for resilient systems."*

**Verifikationshinweis:** Die Formeln stehen im Artikel nicht als Text, sondern als PNGs mit
leerem `alt`-Attribut. Die kursierenden Textvarianten (`random(...)`, `tmp = ...`) sind falsch.
Aus den Bildern ausgelesen:

```
# Capped Exponential Backoff ("No Jitter"), Figure 3
sleep = min(cap, base * 2 ** attempt)

# Full Jitter, Figure 6
sleep = random_between(0, min(cap, base * 2 ** attempt))

# Equal Jitter, Figure 10
temp  = min(cap, base * 2 ** attempt)
sleep = temp / 2 + random_between(0, temp / 2)

# Decorrelated Jitter, Figure 11
sleep = min(cap, random_between(base, sleep * 3))
```

**Zweiter Verifikationshinweis:** Der Artikel enthält **keine Ergebnistabelle** — nur 13 Grafiken
und Fließtext. Die quantitativen Aussagen sind qualitativ formuliert:
> „With N clients contending, the total amount of work done by the system increases with N²."
> „In the case with 100 contending clients, we've reduced our call count by more than half."
> „**The no-jitter exponential backoff approach is the clear loser.** It not only takes more work,
> but also takes more time than the jittered approaches."
> „Of the jittered approaches, '**Equal Jitter' is the loser.** It does slightly more work than
> 'Full Jitter', and takes much longer. The decision between 'Decorrelated Jitter' and 'Full
> Jitter' is less clear. **The 'Full Jitter' approach uses less work, but slightly more time.**"
> „It's worth noting that none of these approaches fundamentally change the N² nature of the work
> to be done, but do substantially reduce work at reasonable levels of contention. **The return on
> implementation complexity of using jittered backoff is huge, and it should be considered a
> standard approach for remote clients.**"

Simulator-Code: https://github.com/awslabs/aws-arch-backoff-simulator

### 4.2 Weitere Anbieter-Formeln und -Regeln

**Google Cloud, „truncated exponential backoff"**
(https://docs.cloud.google.com/memorystore/docs/redis/exponential-backoff, Stand 2026-07-29):
> „The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n`
> incremented by 1 for each iteration (request)."
> „`random_number_milliseconds` is a random number of milliseconds less than or equal to 1000.
> **This helps to avoid cases where many clients get synchronized by some situation and all retry
> at once, sending requests in synchronized waves.**"
> `maximum_backoff` „is typically **32 or 64 seconds**."
> „It's okay to continue retrying once you reach the `maximum_backoff` time."

Konkrete GCP-Client-Library-Defaults
(https://docs.cloud.google.com/storage/docs/retry-strategy): Go 1 s / ×2.0 / max 30 s;
Java 1 s / ×2.0 / max 32 s / total 50 s; Node.js 1 s / ×2 / max 64 s / total 600 s.

**AWS SDK Retry Behavior**
(https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) — Achtung, die
Seite beschreibt inzwischen das 2026er-Verhalten (Opt-in via `AWS_NEW_RETRIES_2026=true`):
`retry_mode` = **standard**, `max_attempts` = **3**. Formel wörtlich:
`delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)` — „The SDK uses **exponential
backoff with full jitter**." Base delay: transient **50 ms**, throttling **1000 ms**. Zusätzlich
ein **Retry-Quota-Token-Bucket** (500 Tokens, 14 pro transientem Retry, 5 pro Throttling-Retry,
+1 bei Erfolg ohne Retry) — d. h. Retries sind global gedeckelt, nicht nur pro Request.

**Azure Transient-Fault-Guidance**
(https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults,
`ms.date: 2026-02-26`) — die dichteste Sammlung harter Regeln:
> „**Add jitter, which is a small random delay, to each retry interval to prevent multiple clients
> from syncing their retries and creating load spikes on the target service.**"
> „**Use an exponential back-off strategy with jitter for background operations, and use immediate
> or regular interval retry strategies for interactive operations.**"
> „**Never implement an endless retry mechanism.** This approach typically prevents the resource or
> service from recovering from overload situations."
> „**Never do an immediate retry more than once.**"
> „Implement a **retry budget** to limit the total number of retries across all requests within a
> process or service… For example, you might allow a process to do no more than **60 retries per
> minute** against a specified dependency."
> „When a response includes a `Retry-After` header, follow it and wait at least the specified
> duration before the next attempt. This server-provided signal reflects the service's recovery
> timeline and **takes precedence over your client-side back-off calculation**."
> „Most 4xx client errors, like 400, 401, 403, and 404, indicate problems that a retry doesn't
> resolve."

**Korrektur:** `learn.microsoft.com/.../best-practices/retry-service-specific` liefert HTTP 301 —
die alten service-spezifischen Default-Tabellen sind nicht mehr zitierbar.

### 4.3 Konkrete Parameter dokumentierter WS-Clients

**Socket.IO v4** (https://socket.io/docs/v4/client-options/):

| Option | Default | Doku-Text |
|---|---|---|
| `reconnectionAttempts` | `Infinity` | — |
| `reconnectionDelay` | `1000` | „The initial delay before reconnection in milliseconds (affected by the randomizationFactor value)." |
| `reconnectionDelayMax` | `5000` | „The maximum delay between two reconnection attempts. **Each attempt increases the reconnection delay by 2x.**" |
| `randomizationFactor` | `0.5` | „The randomization factor used when reconnecting (**so that the clients do not reconnect at the exact same time after a server crash**, for example)." |
| `timeout` | `20000` | „The timeout in milliseconds for each connection attempt." |

Rechenbeispiel aus der Doku: 1. Versuch zwischen 500 und 1500 ms, 2. zwischen 1000 und 3000 ms,
3. zwischen 2000 und 5000 ms, danach 5000 ms. *(Die Doku enthält an dieser Stelle einen
Tippfehler — der Multiplikator ist uniform in [0.5, 1.5], nicht „-0.5 and 1.5". Beim 3. Versuch
ist die Obergrenze 5000 statt 6000, weil `reconnectionDelayMax` die **gejitterte** Zahl deckelt.)*

**Phoenix JS**
(https://github.com/phoenixframework/phoenix/blob/main/assets/js/phoenix/socket.js):
```javascript
this.reconnectAfterMs = (tries) => { … return [10, 50, 100, 150, 200, 250, 500, 1000, 2000][tries - 1] || 5000 }
this.rejoinAfterMs    = (tries) => { … return [1000, 2000, 5000][tries - 1] || 10000 }
```
**Korrektur zur Ticket-Formulierung:** Es ist ein **9-elementiges** Array mit Fallback 5000 ab
Versuch 10 — nicht 10 Elemente. `rejoinAfterMs`-Fallback ist 10000. Kein `maxReconnectAttempts`,
Phoenix reconnected unbegrenzt. Bemerkenswert: **kein Jitter**, dafür ein sehr aggressiver Start
(10 ms) für den häufigsten Fall — den kurzen Netz-Glitch.

**centrifuge-js** (https://github.com/centrifugal/centrifuge-js):
> `minReconnectDelay`: „When client disconnected from a server it will automatically try to
> reconnect using a **backoff algorithm with jitter**. […] Default is `500` milliseconds."
> `maxReconnectDelay`: „sets an upper reconnect delay value. Default is `20000` milliseconds"
> `maxServerPingDelay`: „sets the maximum delay of server pings after which connection is
> considered broken and client reconnects. […] Default is `10000`."

**Ably** (https://ably.com/docs/connect/states):
> „if the connection drops at any time it will attempt to re-establish it by making repeated
> connection attempts **every 15 seconds for up to two minutes**."
> `suspended`: „In the suspended state, an SDK will periodically attempt to open a new connection
> **every 30 seconds**."
(`disconnectedRetryTimeout` 15000 ms, `suspendedRetryTimeout` 30000 ms.)

**Spannbreite der dokumentierten Praxis:** Startverzögerung 10 ms (Phoenix) bis 15 s (Ably);
Obergrenze 5 s (Socket.IO) bis 30 s (Ably) bis 64 s (GCP). Jitter: Socket.IO ±50 %, GCP +≤1000 ms,
AWS Full Jitter, centrifuge-js „mit Jitter" (Faktor nicht dokumentiert), Phoenix gar keiner.

### 4.4 Welcher Fehler rechtfertigt welchen Reconnect?

**RFC 6455 §7.4.1**, die für dieses Projekt relevanten Codes:

| Code | Bedeutung |
|---|---|
| 1000 | Normal Closure |
| 1001 | Going Away (Server-Shutdown oder Browser-Navigation) |
| 1005 | No Status Rcvd — **nur intern, nie auf dem Draht** |
| 1006 | Abnormal Closure — **nur intern, kein Close-Frame empfangen** |
| 1008 | Policy Violation |
| 1009 | Message Too Big |
| 1011 | Internal Error |

**1006 ist der Code, den man bei jedem stillen Proxy-Kill sieht** — genau der Fall, den Azure
AppGW dokumentiert („throws a 1006 error on the client side", §3.5). 1005/1006/1015 dürfen nie in
einem Close-Frame gesendet werden.

**Discord Gateway Close Event Codes** — die einzige öffentlich vollständige
`reconnect: true/false`-Tabelle (https://docs.discord.com/developers/topics/opcodes-and-status-codes):

| Code | Beschreibung | Reconnect |
|---|---|---|
| 4000 | Unknown error | true |
| 4003 | Not authenticated | true |
| **4004** | **Authentication failed** | **false** |
| 4005 | Already authenticated | true |
| 4008 | Rate limited | true |
| 4009 | Session timed out | true |
| 4010–4014 | Invalid shard / Sharding required / Invalid API version / Invalid+Disallowed intents | **false** |

Discords Leitsatz: „In order to prevent broken reconnect loops, you should consider some close
codes as a signal to stop reconnecting. This can be because your token expired, or your
identification is invalid."

**Das dokumentierte Muster ist eine 3-Klassen-Einteilung:**
(a) **sofort/schnell** — server-initiierte Umverteilung (Discord Opcode 7, 4009, 1001 Going Away),
(b) **Backoff** — transiente Fehler, 1006, 1011, Rate-Limits,
(c) **gar nicht** — Auth-/Konfigurationsfehler, analog zu Azures „Most 4xx client errors […]
indicate problems that a retry doesn't resolve."

Pusher kodiert dieselbe Dreiteilung in Code-**Bereichen** (4000–4099 / 4100–4199 / 4200–4299,
§1.8), Centrifugo in terminal/nicht-terminal.

### 4.5 Thundering Herd beim Server-Neustart

**Discord, „You've Got (Too Much) Mail: Behind the Scenes of the 3/25/26 Voice Outage", publiziert
29. April 2026** (https://discord.com/blog/behind-the-scenes-of-the-3-25-26-voice-outage) — der
aktuellste datierte Praxisbericht zum Thema:
- Auslöser: „17% of sessions across Discord were ungracefully stopped." → „each gateway process
  for each affected user gets a `:DOWN` message, signaling to the client that their session is now
  invalid and requires a reconnection."
- Verstärkung: „a selective receive on a supervisor with a ~100k mailbox queue adds ~1ms to
  process spawn time" — die Supervisor-Mailbox erreichte ~1 Mio. Einträge; „new connections are
  blocked because they cannot be opened within the connection timeout."
- Mitigationen: **Rate-Limiting** („low syncer spawn limits"), Architektur (`PartitionSupervisor`
  statt einzelnem GenServer), Kapazität, und **gestaffelte Wiederaufnahme statt Vollneustart**.
- Kernaussage: **Der Recovery-Verkehr selbst war das Problem.** Erholung durch Reduktion
  eingehender Arbeit und schrittweises Zurückholen der Systeme.

**Slack, „Migrating Millions of Concurrent Websockets to Envoy", 15. März 2021** (Update
21. Juni 2021), Ariane van der Stedt & Radha Kumari
(https://slack.engineering/migrating-millions-of-concurrent-websockets-to-envoy/) — relevant fürs
Deployment-Design:
> „We'd keep running the old process for many hours to allow long-lived websocket connections to
> drain and avoid frequent disconnections of users."

*Einschränkung: Der Artikel behandelt Reconnect-Stürme und Client-Backoff nicht. Die verbreiteten
Aussagen über Slacks „Flannel"- und „Governor"-Komponenten stammen aus Sekundär-Blogs und sind
nicht zitierfähig.*

*Negativbefund: „How Discord Handles Two and Half Million Concurrent Voice Users using WebRTC"
(12.09.2018, https://discord.com/blog/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc)
behandelt WebRTC-Voice-Skalierung, **nicht** WebSocket-Reconnect-Stürme.*

**Server-gesteuerte Reconnects — dokumentierte Muster:**

| Muster | Beleg |
|---|---|
| **Server sagt „reconnect jetzt"** — Discord Opcode 7 „Reconnect": „You should attempt to reconnect and resume immediately." Der Server verteilt Verbindungen gestaffelt selbst um, statt sie alle gleichzeitig zu droppen | https://docs.discord.com/developers/topics/opcodes-and-status-codes |
| **Server gibt die Ziel-URL vor** — Discord `resume_gateway_url` im Ready-Event → Lastverteilung beim Reconnect ist serverseitig steuerbar | ebd. |
| **`Retry-After` beim 503 auf den Handshake** — RFC 9110 §10.2.3: „The 'Retry-After' header field indicates how long a user agent ought to wait before making a follow-up request." ABNF: `Retry-After = HTTP-date / delay-seconds`. §15.6.4: „The server SHOULD generate a 'Retry-After' header field to indicate when the client may retry the request." Da der WS-Handshake ein normaler HTTP-Request ist, voll anwendbar — und laut Azure überstimmt er die Client-Backoff-Berechnung | https://www.rfc-editor.org/rfc/rfc9110.txt |
| **Verbindungs-Draining statt Hard-Cut** — alten Prozess stundenlang weiterlaufen lassen | Slack, 15.03.2021 |
| **Rate-Limiting des Recovery-Pfads** | Discord, 29.04.2026 |

**Optionen-Gegenüberstellung Thundering Herd:**

| Option | Pro | Contra |
|---|---|---|
| **Nur Client-Jitter** | Kein Serverzustand, kein Protokoll; von AWS als „standard approach for remote clients" bezeichnet | Ändert laut Brooker die N²-Natur des Problems **nicht**, reduziert sie nur; hilft nicht, wenn der Server nach dem Neustart sofort wieder überlastet ist |
| **Server-gesteuerter Reconnect-Hinweis** (Close-Code + `reconnect_after`, oder `Retry-After` beim 503) | Der Server kennt seinen Zustand; Azure sagt explizit, dass dieser Wert die Client-Berechnung überstimmt; erlaubt gestaffeltes Zurückholen wie bei Discord | Braucht ein Protokollfeld bzw. einen 503-Pfad und Client-Logik, die ihn respektiert; nützt nichts, wenn der Server gar nicht antwortet (Neustart-Fenster) |
| **Draining beim Deployment** | Vermeidet den Sturm ganz statt ihn abzufedern | Zwei Prozessgenerationen parallel — kollidiert mit der Map-Regel „eine Binary + Postgres" und der In-Process-Fan-out-Entscheidung |
| **Rate-Limiting der Accept-Rate** | Schützt den Server unabhängig vom Client-Verhalten; Discords wirksamste Maßnahme im Vorfall vom 25.03.2026 | Verschiebt das Problem in die Client-Backoff-Schleife; braucht sinnvolle 503-/Close-Code-Antworten, sonst produziert es blindes Retry |

### 4.6 Netzwerkwechsel-Erkennung

MDN `Navigator.onLine`
(https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine), wörtlich:
> „On Windows, the online status is determined by whether it can reach a Microsoft home server,
> **which may be blocked by firewalls or VPNs**, even if the computer has Internet access.
> Therefore, this property is inherently unreliable, and you should not disable features based on
> the online status, only provide hints when the user may seem offline."

Praktische Asymmetrie (MDN `Window: offline_event`): `offline` ist verlässlich, `online` nicht
(Netz ja, Internet vielleicht). → `online` taugt als **Trigger, den Backoff-Timer
zurückzusetzen**, nicht als Beweis für Konnektivität. Für Firmen-VPNs ist die Windows-Heuristik
zusätzlich unzuverlässig — direkt relevant für die Zielgruppe.

**Tauri v2** hat kein Core-API für Netzwerk-Status. Community-Plugins:
`tauri-plugin-network-information` (iOS/Android, `connection()` + Change-Listener,
https://github.com/wtto00/tauri-plugin-network-information),
`tauri-plugin-network` (Desktop, https://github.com/HuakunShen/tauri-plugin-network).
Auf Mobile im Foreground gilt zusätzlich: OS-seitige App-Suspension beendet die WS-Verbindung
**ohne Close-Frame** → `1006` beim Wiederaufwachen.

---

## 5. Axum 0.8 konkret

### 5.0 Bestandsaufnahme rustification-server

Gelesen, nichts geändert. Relevante Dateien:
- `C:\Projekte\Privat\Rustification\rustification-server\Cargo.toml`
- `C:\Projekte\Privat\Rustification\rustification-server\src\main.rs`
- `C:\Projekte\Privat\Rustification\rustification-server\src\route.rs`
- `C:\Projekte\Privat\Rustification\rustification-server\src\middleware.rs`
- `C:\Projekte\Privat\Rustification\rustification-server\src\model.rs` (`Claims { sub: String, exp: usize }`)

```toml
edition = "2024"
axum = "0.8.9"                # KEIN features = ["ws"]
tokio = { version = "1", features = ["full"] }
sqlx = { version = "0.9", features = ["runtime-tokio","tls-rustls-ring-webpki","postgres","chrono","uuid"] }
jsonwebtoken = "9"
```

Nicht vorhanden und für WS nötig: `axum`-Feature `ws`; `futures`/`futures-util` (für
`StreamExt::split`); `tokio-util` (für `CancellationToken`/`TaskTracker`); `axum-extra` (für
`TypedHeader`).

- **AppState** (`main.rs:14-17`): `pub struct AppState { pub db: PgPool, pub jwt_secret: String }`
  — **nicht** `Clone`, überall als `Arc<AppState>`; State-Typ ist also `State<Arc<AppState>>`.
- **Router** (`main.rs:46-48`): `Router::new().nest("/api/v1", route::router(state.clone())).with_state(state)`.
- **Auth-Middleware**: `axum::middleware::from_fn_with_state(state, require_auth)` als `.layer(...)`
  auf dem `protected`-Subrouter (`route.rs:104`). `require_auth` validiert das Bearer-JWT und macht
  `req.extensions_mut().insert(data.claims)` (`middleware.rs:31`). **Kein**
  `FromRequestParts`-Extractor.
- **Auffällig:** `Extension<Claims>` wird in **keinem** Handler gelesen — die eingefügte Extension
  ist derzeit ungenutzt.
- **Graceful Shutdown existiert nicht:** `main.rs:52` ist `axum::serve(listener, app).await.unwrap();`
  Auch kein `into_make_service_with_connect_info` — `ConnectInfo` würde zur Laufzeit fehlschlagen.

### 5.1 WebSocket-Upgrade mit State

`axum::extract::ws` ist „available via the `ws` crate feature"
(https://docs.rs/axum/0.8.9/axum/extract/ws/index.html).

**Breaking Changes 0.7 → 0.8** (https://github.com/tokio-rs/axum/blob/main/axum/CHANGELOG.md):
> **breaking:** `axum::extract::ws::Message` now uses `Bytes` in place of `Vec<u8>`, and a new
> `Utf8Bytes` type in place of `String`, for its variants (#3078)
> **changed:** Upgraded `tokio-tungstenite` to 0.26 (#3078)
> **breaking:** Remove `WebSocket::close`. Users should explicitly send close messages themselves. (#2974)
> **added:** Add support for WebSockets over HTTP/2. They can be enabled by changing
> `get(ws_endpoint)` handlers to `any(ws_endpoint)` (#2894)
> **breaking:** Make `serve` generic over the listener and IO types (#2941)

*(Hinweis: Die Überschrift im Repo lautet `# 0.8.0 (27. November, 2023)` — ein Tippfehler im
axum-Repo; das echte 0.8.0-Release ist https://tokio.rs/blog/2025-01-01-announcing-axum-0-8-0
vom 01.01.2025. Der Blogpost erwähnt WebSockets nicht; die WS-Änderungen stehen nur im CHANGELOG.)*

**`Message`-Varianten:** `Text(Utf8Bytes)`, `Binary(Bytes)`, `Ping(Bytes)`, `Pong(Bytes)`,
`Close(Option<CloseFrame>)`.

**Extractor-Reihenfolge — `WebSocketUpgrade` ist `FromRequestParts`.** Quellcode
(https://github.com/tokio-rs/axum/blob/main/axum/src/extract/ws.rs):
```rust
impl<S> FromRequestParts<S> for WebSocketUpgrade<DefaultOnFailedUpgrade> where S: Send + Sync {
    type Rejection = WebSocketUpgradeRejection;
    async fn from_request_parts(parts: &mut Parts, _state: &S) -> Result<Self, Self::Rejection> {
        // HTTP/1.1: Methode MUSS GET sein, Connection: upgrade, Upgrade: websocket, Sec-WebSocket-Key
        // HTTP/2:   Methode MUSS CONNECT sein, hyper::ext::Protocol == "websocket"
        // Sec-WebSocket-Version MUSS "13" sein
        let on_upgrade = parts.extensions.remove::<hyper::upgrade::OnUpgrade>()
            .ok_or(ConnectionNotUpgradable)?;
        …
    }
}
```

Die Regel „Extractors always run in the order of the function parameters, from left to right"
und „der letzte Extractor muss `FromRequest` implementieren" gilt in 0.8 unverändert
(https://docs.rs/axum/0.8.9/axum/extract/index.html) — **betrifft WS aber nicht**, weil
`WebSocketUpgrade`, `State`, `Extension`, `Query`, `Path`, `TypedHeader`, `ConnectInfo` und
`HeaderMap` **alle** `FromRequestParts` sind. Die Reihenfolge ist frei:
```rust
async fn ws_handler(
    ws: WebSocketUpgrade,
    State(state): State<Arc<AppState>>,
    Extension(claims): Extension<Claims>,
    ConnectInfo(addr): ConnectInfo<SocketAddr>,
) -> Response { ws.on_upgrade(move |socket| handle(socket, state, claims, addr)) }
```

**Handshake-Konfiguration in 0.8.9**
(https://docs.rs/axum/0.8.9/axum/extract/ws/struct.WebSocketUpgrade.html):

| Methode | Default / Semantik |
|---|---|
| `max_message_size(usize)` | **Default 64 MB** |
| `max_frame_size(usize)` | **Default 16 MB** |
| `read_buffer_size(usize)` | 128 KiB |
| `write_buffer_size(usize)` / `max_write_buffer_size(usize)` | 128 KiB / unlimited |
| `accept_unmasked_frames(bool)` | `false` |
| `protocols<I>(I)` | Subprotokoll-Negotiation |
| `requested_protocols()` / `set_selected_protocol(HeaderValue)` | **neu in 0.8.9** (#3597) — erlaubt eigene Auswahl-Logik, relevant für Option 1.3 |
| `selected_protocol()` | gewähltes Subprotokoll |
| `on_failed_upgrade<C>(C)` | Callback, wenn das Upgrade in der Hintergrund-Task fehlschlägt |

Struct-Doku: „For HTTP/1.1 requests, this extractor requires the request method to be `GET`; in
later versions, `CONNECT` is used instead. **To support both, it should be used with `any`.**"

Serverseitig das ausgehandelte Subprotokoll lesen: `WebSocket::protocol() -> Option<&HeaderValue>`
— „Return the selected WebSocket subprotocol, if one has been chosen."
(https://docs.rs/axum/0.8.9/axum/extract/ws/struct.WebSocket.html)

**`close_code`-Konstanten** (aus `axum/src/extract/ws.rs`) — der Name für 1001 ist in axum
**`AWAY`**, nicht `GOING_AWAY`:
```rust
NORMAL = 1000, AWAY = 1001, PROTOCOL = 1002, UNSUPPORTED = 1003, STATUS = 1005,
ABNORMAL = 1006, INVALID = 1007, POLICY = 1008, SIZE = 1009, EXTENSION = 1010,
ERROR = 1011, RESTART = 1012 /* "the server is restarting" */, AGAIN = 1013 /* overloaded */
```
`1012 RESTART` und `1013 AGAIN` sind für §4.5 (Thundering Herd) unmittelbar relevant.

**Verbindungsdaten:** `ConnectInfo<T>` — „Note this extractor requires you to use
`Router::into_make_service_with_connect_info` to run your app **otherwise it will fail at
runtime**" (https://docs.rs/axum/0.8.9/axum/extract/struct.ConnectInfo.html). Das fehlt im
aktuellen `main.rs`. `TypedHeader<T>` lebt seit 0.7 in `axum-extra` (Feature `typed-header`).

**Offizielle Beispiele (alle vorhanden):**
- `examples/websockets/src/main.rs` — `WebSocketUpgrade` + `TypedHeader<UserAgent>` +
  `ConnectInfo`, `into_make_service_with_connect_info::<SocketAddr>()`, `Message::Ping` als
  Probe, `socket.split()` + zwei Tasks + `tokio::select!`
  (https://github.com/tokio-rs/axum/blob/main/examples/websockets/src/main.rs)
- `examples/websockets-http2/src/main.rs` — Route ist `any(ws_handler)`; setzt
  `server.http_builder().http2().enable_connect_protocol();`
  (https://github.com/tokio-rs/axum/blob/main/examples/websockets-http2/src/main.rs)
- `examples/chat/src/main.rs` — **nutzt `tokio::sync::broadcast`**:
  `struct AppState { user_set: Mutex<HashSet<String>>, tx: broadcast::Sender<String> }`,
  `broadcast::channel(100)`, `split()` + `tokio::select!` mit `abort()`
  (https://github.com/tokio-rs/axum/blob/main/examples/chat/src/main.rs)
- Weiter relevant: `examples/testing-websockets`, `examples/graceful-shutdown`.

### 5.2 Greift `middleware::from_fn_with_state` beim Upgrade-Request? — **Ja.**

Der Beleg steckt im Quellcode von `on_upgrade`
(https://github.com/tokio-rs/axum/blob/main/axum/src/extract/ws.rs):
```rust
pub fn on_upgrade<C, Fut>(self, callback: C) -> Response {
    tokio::spawn(async move {
        let upgraded = match on_upgrade.await { … };          // hyper::upgrade::OnUpgrade
        let socket = WebSocketStream::from_raw_socket(TokioIo::new(upgraded), Role::Server, Some(config)).await;
        callback(WebSocket { inner: socket, protocol }).await;
    });

    let mut response = Response::builder()
        .status(StatusCode::SWITCHING_PROTOCOLS)
        .header(header::CONNECTION, UPGRADE)
        .header(header::UPGRADE, WEBSOCKET)
        .header(header::SEC_WEBSOCKET_ACCEPT, sign(sec_websocket_key.as_bytes()))
        .body(Body::empty()).unwrap();
    …
    response
}
```

**Der Handler kehrt sofort mit einem gewöhnlichen `Response` (101) zurück.** Der Upgrade-Request
ist bis dahin ein normaler HTTP/1.1-`GET` (bzw. HTTP/2-`CONNECT`) und durchläuft die volle
Tower-Kette wie jede REST-Route. Erst `hyper::upgrade::OnUpgrade` resolved in der separaten
`tokio::spawn`-Task, nachdem hyper die 101 geschrieben und die IO gehijackt hat
(https://docs.rs/hyper/latest/hyper/upgrade/index.html).

**Kann Middleware mit 401 ablehnen? Ja.** Die bestehende `require_auth` gibt
`Err((StatusCode::UNAUTHORIZED, …))` zurück, bevor `next.run(req)` läuft — der Handler wird nie
aufgerufen, `on_upgrade` nie erreicht, hyper sendet keine 101. Standard-Tower-Pfad, nichts
WS-Spezifisches. Was der Client davon sieht, hängt an der Vorbemerkung (WebView: nur `1006`).

**Extensions — zwei Fallstricke:**
1. Von der Middleware via `extensions_mut().insert(claims)` eingefügte Werte sind im Handler über
   `Extension<Claims>` sichtbar (Standardmechanik von `from_fn`).
2. **`WebSocketUpgrade::from_request_parts` macht `parts.extensions.remove::<hyper::upgrade::OnUpgrade>()`.**
   Baut eine Middleware den Request neu, ohne `extensions` zu übernehmen, ist `OnUpgrade` weg →
   Rejection `ConnectionNotUpgradable`. **Das ist der wichtigste Middleware-Fallstrick bei WS.**
3. **Die `on_upgrade`-Closure ist `'static`** (`C: FnOnce(WebSocket) -> Fut + Send + 'static`).
   Request-Extensions überleben **nicht** — `Parts` wird nach dem Handler gedroppt. Alles, was die
   Task braucht (Claims, `Arc<AppState>`, `SocketAddr`), muss vorher extrahiert/geklont und per
   `move` hineingezogen werden.

**Response-Middleware nach 101 / Timeouts:** `tower_http::timeout::TimeoutLayer` misst bis zum
Response — bei WS ist das **sofort** (101 mit `Body::empty()`). Die spätere WS-Task ist davon
nicht betroffen; `ResponseBodyTimeoutLayer` greift auf einem leeren Body ebenfalls nicht
(https://docs.rs/tower-http/latest/tower_http/timeout/index.html).
⚠️ **Nicht belegbar:** Es wurde **kein** Issue gefunden, das nachweist, dass `TimeoutLayer` eine
bereits geupgradete WS-Verbindung abbricht. Gefundene, aber andere Probleme betreffende Issues:
[axum#1260](https://github.com/tokio-rs/axum/issues/1260) („server stucks when large of websocket
connection closed"), [axum Discussion #2597](https://github.com/tokio-rs/axum/discussions/2597),
[axum#2964](https://github.com/tokio-rs/axum/issues/2964). Das realere Risiko ist Middleware, die
den **Request-Body puffert** oder den Request rekonstruiert und dabei Extensions verliert.

**Alternative: Auth im Handler per eigenem `FromRequestParts`-Extractor**
(https://docs.rs/axum/0.8.9/axum/extract/trait.FromRequestParts.html):

| | Middleware (`from_fn_with_state`) | Eigener `FromRequestParts`-Extractor |
|---|---|---|
| **Pro** | Ein Ort für die ganze Route-Gruppe; kann 401 senden, ohne den Handler zu bauen; **ist der heutige Bestandscode** | Typsicher — kein `Extension<Claims>`-Panic bei vergessenem Layer; kann Query-/Subprotokoll-Token im selben Schritt lesen (relevant für Optionen 1.2/1.3); pro Handler komponierbar |
| **Contra** | `Extension<Claims>` panikt zur Laufzeit, wenn der Layer fehlt; liest Token nur aus dem Header, es sei denn man baut das aus | Muss an jeden Handler geschrieben werden; State-Zugriff braucht `FromRef` oder `S = Arc<AppState>` |

Beide sind kombinierbar: Middleware für REST, zusätzlicher Extractor für WS mit anderem
Token-Kanal.

### 5.3 Verbindungsverwaltung und Graceful Shutdown

**Was `axum::serve(...).with_graceful_shutdown(...)` tut** — Quellcode
`axum/src/serve/mod.rs` (https://github.com/tokio-rs/axum/blob/main/axum/src/serve/mod.rs):
```rust
let (signal_tx, signal_rx) = watch::channel(());
executor.execute(async move { signal.await; drop(signal_rx); });
let (close_tx, close_rx) = watch::channel(());

loop {
    let (io, remote_addr) = match select(pin!(listener.accept()), pin!(signal_tx.closed())).await {
        Either::Left((conn, _)) => conn,
        Either::Right(_) => break,          // keine neuen Verbindungen mehr
    };
    handle_connection(&mut make_service, &signal_tx, &close_rx, io, remote_addr, &executor).await;
}
drop(close_rx); drop(listener);
close_tx.closed().await;                     // wartet auf die Connection-Tasks
```

**Belege, dass upgegradete Verbindungen NICHT beendet und NICHT abgewartet werden:**

1. Der `close_rx`-Guard hängt **nur** an der hyper-Connection-Task. Die WS-Task ist ein
   eigenständiges `tokio::spawn` in `on_upgrade` **ohne** `close_rx` ⇒ `close_tx.closed().await`
   wartet nicht auf sie.
2. `hyper_util`-`UpgradeableConnection::graceful_shutdown`
   (https://docs.rs/hyper-util/latest/hyper_util/server/conn/auto/struct.UpgradeableConnection.html):
   > „This should only be called while the `Connection` future is still pending. **If called after
   > `UpgradeableConnection::poll` has resolved, this does nothing.**"
   Nach dem Hijack ist die Connection-Future resolved ⇒ der Aufruf ist ein No-op; das Socket
   gehört jetzt dem `WebSocketStream`.
3. **[axum Issue #3003 — „Graceful Shutdown ignores Websocket handler task"](https://github.com/tokio-rs/axum/issues/3003)**,
   eröffnet **21.10.2024**, **Status offen**:
   > „the task spawned in `ws.on_upgrade` is not connected to the graceful shutdown future at all"
   Und: selbst mit eigenem `CancellationToken` ist nicht garantiert, dass die Verbindung
   geschlossen ist, wenn die Shutdown-Future resolved.
4. **[axum PR #3831 — „fix(serve): include WebSocket tasks in graceful shutdown"](https://github.com/tokio-rs/axum/pull/3831)**,
   eingereicht **11.07.2026**, letzte Aktivität **28.07.2026**, **Status offen**:
   > „WebSocket handlers escape all of it … the shutdown future then resolves while sockets are
   > still live, so handler state outlives 'shutdown'"
   Der PR fügt eine `GracefulPeer`-Struktur mit Connection-Guards in die Request-Extensions ein
   und sendet beim Shutdown einen Close-Frame.
5. Gegenbeispiel zur Abgrenzung: [axum#2673](https://github.com/tokio-rs/axum/issues/2673) — **SSE
   blockiert** den Graceful Shutdown (kein Upgrade, hyper-Connection bleibt offen), **WS nicht**.

⇒ **Faktenlage:** Solange #3831 nicht gemerged ist, muss das Projekt WS-Verbindungen **selbst**
tracken und beenden. `WithGracefulShutdown`-Doku
(https://docs.rs/axum/0.8.9/axum/serve/struct.WithGracefulShutdown.html) sagt zu Upgrades
**nichts**; `axum::serve` ist dokumentiert als „intentionally simple and doesn't support any
configuration" (https://docs.rs/axum/0.8.9/axum/fn.serve.html).

**Tracking-Bausteine, jeweils belegt:**

| Baustein | Doku-Zitat | Eignung |
|---|---|---|
| **`tokio_util::sync::CancellationToken`** (https://docs.rs/tokio-util/latest/tokio_util/sync/struct.CancellationToken.html) | `cancelled()`: „Returns a Future that gets fulfilled when cancellation is requested. […] **This method is cancel safe.**" · `child_token()`: „Creates a CancellationToken which will get cancelled whenever the current token gets cancelled." (Cancel eines Childs cancelt den Parent nicht) · `cancelled_owned()` für `'static`-Closures | Ein Token pro Verbindung, abgeleitet vom globalen Shutdown-Token |
| **`tokio_util::task::TaskTracker`** (https://docs.rs/tokio-util/latest/tokio_util/task/task_tracker/struct.TaskTracker.html) | „A task tracker used for waiting until tasks exit." · `wait`: „Waits until this `TaskTracker` is both closed and empty" (cancel safe) · gegenüber `JoinSet`: „When tasks exit, a `TaskTracker` will allow the task to immediately free its memory"; „does not require mutable access to insert tasks"; „can be cloned to share it with many tasks" | Warten auf N WS-Tasks beim Shutdown; die Doku enthält ein vollständiges Beispiel `TaskTracker` + `CancellationToken` genau dafür |
| **`tokio::sync::watch`** (https://docs.rs/tokio/latest/tokio/sync/watch/index.html) | „`Sender::is_closed` and `Sender::closed` allow the producer to detect when all `Receiver` handles have been dropped." | Genau das Muster, das `axum::serve` intern benutzt (`signal_tx`/`close_tx`) |
| **`JoinSet`** (https://docs.rs/tokio/latest/tokio/task/struct.JoinSet.html) | braucht `&mut`, hält Rückgabewerte | Laut TaskTracker-Doku für viele lang laufende unabhängige Tasks die schlechtere Wahl |

**Muster in der Verbindungsschleife** (Ableitung aus den obigen Docs + axum-Beispiel):
```rust
let token = shutdown_token.child_token();
loop {
    tokio::select! {
        _ = token.cancelled() => {                       // cancel safe (Doku oben)
            let _ = sender.send(Message::Close(Some(CloseFrame {
                code: close_code::AWAY,                  // 1001 "going away"
                reason: "server shutting down".into(),
            }))).await;
            break;
        }
        msg = receiver.next() => { … }
        ev  = rx.recv()      => { … }                    // broadcast::Receiver::recv, cancel safe
    }
}
```
`WebSocket::close` existiert seit 0.8 **nicht mehr** (CHANGELOG #2974) → Close-Frame explizit
über `send`. Für einen Neustart wäre alternativ `close_code::RESTART` (1012) protokollierbar
(§5.1) — was direkt an §4.4 anschließt.

**Cancel-Safety** — `tokio::select!`-Doku
(https://docs.rs/tokio/latest/tokio/macro.select.html):
> „Cancellation safety describes what happens when a future is dropped before it completes."
> Grundregel: „If you have a future that has not yet completed, then it must be a no-op to drop
> that future and recreate it"

Als cancel-**sicher** gelistet: `mpsc::Receiver::recv`, **`broadcast::Receiver::recv`**,
`watch::Receiver::changed`, `AsyncReadExt::read`, sowie pauschal „Stream operations via
`tokio_stream` and `futures` crates". **Nicht** cancel-sicher: `read_exact`, `read_to_end`,
`write_all`, `Mutex::lock`, `RwLock::read`/`write`, `Semaphore::acquire`, `Notify::notified`.

`broadcast::Receiver::recv` explizit
(https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html):
> „**Cancel safety:** This method is cancel safe. If `recv` is used as a branch in `tokio::select!`
> and another branch completes first, it is guaranteed that no messages were received on this
> channel."

⚠️ **`SplitStream::next()` ist nur indirekt belegt.**
https://docs.rs/futures/latest/futures/stream/trait.StreamExt.html#method.next dokumentiert nur
„Creates a future that resolves to the next item in the stream" — **keine explizite
Cancel-Safety-Aussage**. Der einzige Beleg ist die pauschale Zeile in der `select!`-Doku. Das ist
vermutlich der Grund, warum die axum-Beispiele (`chat`, `websockets`) durchweg **split-in-zwei-Tasks**
verwenden statt `select!` über den Socket-Stream — dieser Ansatz umgeht die Frage.

---

## 6. `tokio::sync::broadcast` und langsame Empfänger

Doku: Modul https://docs.rs/tokio/latest/tokio/sync/broadcast/index.html ·
`Sender` https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Sender.html ·
`Receiver` https://docs.rs/tokio/latest/tokio/sync/broadcast/struct.Receiver.html ·
`RecvError` https://docs.rs/tokio/latest/tokio/sync/broadcast/error/enum.RecvError.html

### 6.1 Grundsemantik

> „A multi-producer, multi-consumer broadcast queue. Each sent value is seen by all consumers."
> „When a value is sent, **all** `Receiver` handles are notified and will receive the value. The
> value is stored once inside the channel and **cloned on demand for each receiver**."
> „When a `Receiver` handle is dropped, any messages not read by the receiver will be marked as read."

Kapazität: „The provided `capacity` is rounded **up** to the next power of two." (3 → 4);
`capacity == 0` panikt.

**Senden blockiert nie.** `Sender::send` ist nicht `async`: „Attempts to send a value to all active
Receiver handles, returning it back if it could not be sent." Bei vollem Ring gilt (Modul-Doku):
**„the oldest value currently held by the channel is overwritten."** Rückgabe `Ok(usize)` = Anzahl
aktiver Receiver; `Err(SendError<T>)` „when there is no active `Receiver` handle" — der Wert kommt
zurück. `Sender::receiver_count`: „It is not guaranteed that a sent message will reach this number
of receivers."

### 6.2 `RecvError::Lagged(u64)` — exakte Semantik

> `Lagged(u64)`: „The receiver lagged too far behind: one or more messages were overwritten in the
> ring buffer before this receiver could read them. **The receiver remains subscribed. Its internal
> cursor has been advanced to the oldest message still retained by the channel;** the next
> successful `recv` call returns that message (unless further sends overwrite it first). The `u64`
> is the number of messages that were skipped."

`Receiver::recv`:
> „If the `Receiver` handle falls behind, once the channel is full, newly sent values overwrite old
> values in the ring buffer. The next call to `recv` then returns `Err(RecvError::Lagged(n))`,
> where `n` is the number of overwritten messages the receiver missed."
> „The receiver stays subscribed; its internal cursor is advanced to the oldest value still held by
> the channel."

**Antwort auf die drei Teilfragen des Tickets:** (a) `n` = Anzahl übersprungener Nachrichten;
(b) der Receiver bleibt **brauchbar**, `Lagged` ist kein Abbruch; (c) er springt auf die **älteste
noch vorhandene** Nachricht — er verliert also genau `n` Nachrichten, nicht mehr und nicht weniger.

### 6.3 Weitere API, die für das „Resync"-Problem relevant ist

- **`Receiver::len`:** „Returns the number of messages that were sent into the channel and that this
  `Receiver` has yet to receive." → **direkt als Backlog-Metrik/Frühwarnung nutzbar, bevor `Lagged`
  eintritt.**
- **`Receiver::resubscribe`:** „This `Receiver` handle will receive a clone of all values sent
  **after** it has resubscribed." → verwirft explizit alles Alte; das ist der „Cursor auf jetzt
  zurücksetzen"-Reset.
- **`Receiver::try_recv`** — nicht blockierend, `TryRecvError::{Closed, Empty, Lagged(n)}`.
- **Speicher:** Der Wert wird **einmal** gespeichert und „cloned on demand for each receiver" ⇒ `T`
  sollte billig klonbar sein (`Arc<Event>`, `bytes::Bytes`). ⚠️ Ob der Ring bei `channel(n)` sofort
  vollständig alloziert wird, sagt die Doku **nicht** ausdrücklich — nur die
  Power-of-Two-Rundung und der Hinweis „Allocation failure may result in a panic".

### 6.4 „Lagged = Resync jetzt" — Optionen

⚠️ **Wichtiger Negativbefund:** Es wurde **keine** tokio-Issue, -Discussion oder Doku-Passage
gefunden, die „Lagged als Resync-Trigger" als *empfohlenes* Muster benennt. Es ist gängige
Community-Praxis, aber ohne Primärquelle. Belegbar sind nur die einzelnen Bausteine.

| Ansatz | Belegter Baustein | Pro | Contra |
|---|---|---|---|
| **Kapazität erhöhen** | `channel(n)`-Doku (Power-of-Two-Rundung) | Trivial; verschiebt die Schwelle | Löst nichts, verschiebt nur; Speicher × Kapazität; ein dauerhaft langsamer Client laggt trotzdem |
| **`resubscribe()` + REST-Backfill** | `resubscribe`-Doku (s. o.) + Map-Entscheidung „`?since`-Backfill, die DB *ist* die Queue" | Passt exakt zur bereits gesetzten Zustellsemantik der Map; der Client hat mit `?since` ohnehin den Mechanismus, um die Lücke zu schließen; `Lagged(n)` liefert sogar die Größe der Lücke | Backfill-Last auf der DB genau dann, wenn der Server ohnehin unter Druck steht; braucht einen sauberen Cursor (siehe Council-Risiko „Cursor-Lücke") |
| **`Receiver::len()` als Frühwarnung** | `len`-Doku (s. o.) | Erlaubt Reaktion *vor* dem Datenverlust (z. B. Client drosseln oder trennen) | Zusätzlicher Zustand pro Verbindung; Schwellenwert ist Tuning |
| **Per-Verbindung-Puffer-Task** (broadcast → `mpsc::try_send`) | `mpsc::Sender::try_send`: „differs from `send` by returning immediately if the channel's buffer is full" (https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.html) | **Drop-/Trenn-Entscheidung pro Client** statt global; ein langsamer Client trifft nur sich selbst | Ein Channel + Fan-out-Loop pro Verbindung; `T` wird pro Client geklont |
| **Coalescing / latest-only** | `watch` (s. §6.5) | Kein Lag-Fehler möglich | Nur sinnvoll, wenn Zwischenwerte entbehrlich sind |

Referenz-Implementierung im Repo von axum selbst: `examples/chat/src/main.rs` mit
`broadcast::channel(100)`.

### 6.5 Alternative Kanaltypen

| Option | Doku | Semantik | Trade-off |
|---|---|---|---|
| **`tokio::sync::watch`** | https://docs.rs/tokio/latest/tokio/sync/watch/index.html | „a multi-producer, multi-consumer channel that **only retains the last sent value**"; `changed()` ist cancel safe; `borrow_and_update()` „should be preferred […] if the receiver intends to await notifications from `changed` in a loop […] avoids a potential race where a new value is sent between `changed` being ready and the value being read" | **Kein Lag-Fehler möglich**, aber Zwischenwerte gehen verloren ⇒ taugt als reines **Resync-Signal / Versionszähler** (z. B. „Cursor der Conversation X ist jetzt N, hol dir den Rest per REST"), ungeeignet als Event-Stream, in dem jede Nachricht zählt. Passt bemerkenswert gut zur Map-Entscheidung „Dumb Pipe `{conversation, cursor}`" |
| **`tokio::sync::mpsc` + `try_send` pro Verbindung** | https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.html | `send`: „Sends a value, waiting until there is capacity."; `try_send`: sofortiges `TrySendError::Full`/`Closed`; `reserve`: „Waits for channel capacity. Once capacity […] is available, it is reserved for the caller." | Backpressure- bzw. Drop-Entscheidung **pro Client**; erlaubt „langsamen Client trennen" statt globalem Lag. Kosten: ein Channel + Fan-out-Loop pro Verbindung |
| **`async_broadcast` 0.7.2** | https://docs.rs/async-broadcast/latest/async_broadcast/ | `broadcast`: „If the channel is full, this method waits until there is space for a message" (echte Backpressure, `async`). `set_overflow(true)`: „broadcasting […] will succeed even if the channel is full. It achieves that by removing the oldest message". `InactiveReceiver` hält den Kanal offen ohne zu konsumieren. Eigene Abgrenzung zu tokio in der Doku: „While this implementation does provide overflow mode, it is the default behavior and not opt-in. There is no equivalent of inactive receivers." | **Backpressure statt Drop** — ein langsamer WS-Client kann den **gesamten Producer** bremsen (Head-of-Line-Blocking über alle Clients). Nur sinnvoll, wenn Verlust teurer ist als Latenz — was der Map-Entscheidung „Best-effort + `?since`-Backfill" widerspricht |
| **`flume`** | https://docs.rs/flume, https://crates.io/crates/flume | „A blazingly fast multi-producer, multi-consumer channel" mit „MPMC support". Crates.io: „in casual maintenance mode … critical security and bug fixes, but heavy feature development has stopped" | ⚠️ **Kein Broadcast** — MPMC heißt hier Work-Queue: jede Nachricht geht an genau **einen** Receiver. Für Fan-out an N WS-Clients ungeeignet, nur als Worker-Queue. *(„genau ein Receiver" konnte in der flume-Doku nicht wörtlich belegt werden.)* |
| **`postage::broadcast`** | https://docs.rs/postage/latest/postage/broadcast/ | „Provides a **lossless**, MPMC channel. All receivers are guaranteed to recieve each message." | Lossless impliziert Backpressure. ⚠️ **Nicht belegbar:** Die Modul-Doku sagt **nicht** explizit, ob der Sender bei langsamem Receiver wartet oder was sonst geschieht. Kleinere Community |

### 6.6 PostgreSQL `LISTEN/NOTIFY` als zweite Fan-out-Implementierung

Die Map sieht `LISTEN/NOTIFY` als zweite Implementierung hinter dem Fan-out-Trait vor. Faktenlage:

`sqlx::postgres::PgListener` (https://docs.rs/sqlx/latest/sqlx/postgres/struct.PgListener.html):
> „A stream of asynchronous notifications from Postgres."
> „This listener will **auto-reconnect**. If the active connection being used ever dies, this
> listener will detect that event, create a new connection, will re-subscribe to all of the
> originally specified channels, and will resume operations as normal."
> `recv()`: „If the connection to PostgreSQL is lost, it is automatically reconnected on the next
> call to `recv()`, and should be entirely transparent (as long as it was just an intermittent
> network failure or long-lived connection reaper)."
> `listen()`: „The channel name is quoted here to ensure case sensitivity."

PostgreSQL `NOTIFY` (https://www.postgresql.org/docs/current/sql-notify.html):
> „In the default configuration it must be shorter than **8000 bytes**."
> „There is a queue that holds notifications that have been sent but not yet processed by all
> listening sessions. **If this queue becomes full, transactions calling `NOTIFY` will fail at
> commit.** The queue is quite large (8GB in a standard installation)."

| | |
|---|---|
| **Pro** | Multi-Instanz-fähiger Fan-out ohne zusätzlichen Broker — hält die Map-Regel „eine Binary + Postgres"; `PgListener` reconnected selbst; `NOTIFY` ist transaktional (feuert erst bei COMMIT), was die Konsistenz mit der DB als Queue erzwingt; der Dumb-Pipe-Payload `{conversation, cursor}` liegt weit unter 8 kB |
| **Contra** | 8000-Byte-Payload-Grenze — nur IDs/Deltas, Volldaten per Query nachladen; die Notify-Queue kann Transaktionen **beim Commit fehlschlagen** lassen, wenn Listener hängen; jeder `PgListener` belegt eine **dedizierte** Postgres-Connection außerhalb des `PgPool` (aktuell `max_connections = 10`) — muss beim Sizing eingeplant werden; `NOTIFY` liefert keine Historie, ein verpasstes Signal ist weg (dieselbe Resync-Frage wie bei `broadcast`, nur eine Ebene tiefer) |

---

## Anhang: Was nicht belegt werden konnte

Diese Punkte sollten im Entscheidungsticket **nicht** als Fakt behandelt werden:

1. **Referrer-Leak und Browser-History für WS-URLs** (§1.2) — RFC 6750 §5.3 spricht von „page
   URLs"; für `new WebSocket(url)` kein Beleg gefunden.
2. **APM/Tracing-Leak** — plausibel (OpenTelemetry `url.full`), aber keine Semantic-Convention-Seite
   geprüft.
3. **OWASP WebSocket Security Cheat Sheet** trägt kein verifizierbares Datum/keine Version.
4. **SameSite-Wirksamkeit für WS-Handshakes** (§1.4) — aus rfc6265bis §5.6.7.1 abgeleitet, das Wort
   „WebSocket" kommt dort nicht vor.
5. **Auth0/Okta** haben keine auffindbare WS-spezifische Doku zum Token-Ablauf.
6. **Header-Größenlimits** von nginx/Caddy für lange JWTs im `Sec-WebSocket-Protocol` (§1.3).
7. **`tauri-plugin-websocket` `headers`-Feldtyp** — nur der Feldname aus der JS-Referenz belegt.
8. **Cloudflare „100 s WS-Idle-Timeout"** — in keiner Cloudflare-Primärquelle; sie dokumentieren
   bewusst keinen Zahlenwert.
9. **MDN „Proxy servers and firewalls"** — dieser Abschnitt existiert in der aktuellen MDN-Fassung
   nicht mehr.
10. **HAProxy numerische Timeout-Defaults** — upstream nicht dokumentiert; kursierende „50 s"
    stammen aus Distro-Beispiel-Configs.
11. **Slack-Reconnect-Sturm mit Datum** — der Envoy-Artikel (15.03.2021) behandelt das Thema nicht;
    „Flannel/Governor"-Aussagen sind nur sekundärbelegt.
12. **Discord `heartbeat_interval` = 41250 ms** — nicht dokumentiert; die Doku zeigt `45000` im
    Beispiel, der Wert ist server-diktiert.
13. **`tower_http::timeout` bricht geupgradete WS ab** — kein Issue gefunden, das das nachweist.
14. **`SplitStream::next()` Cancel-Safety** — nur indirekt über die pauschale `select!`-Doku-Zeile.
15. **„Lagged als Resync-Trigger"** — kein tokio-Doku- oder Issue-Beleg als empfohlenes Muster.
16. **broadcast-Ring: Sofort-Allokation** — Doku sagt dazu nichts.
17. **flume: „jede Nachricht an genau einen Receiver"** — in der flume-Doku nicht wörtlich belegt.

---

## Quellenverzeichnis

**Spezifikationen**
- RFC 6455 (The WebSocket Protocol) — https://www.rfc-editor.org/rfc/rfc6455.txt · §1.8, §4.1, §4.2.2, §5.5, §5.5.1–3, §7.4.1–2, §10.2, §10.3, §10.5
- RFC 6750 (Bearer Token Usage) — https://datatracker.ietf.org/doc/html/rfc6750 · §2.3, §5.3
- RFC 8441 (Bootstrapping WebSockets with HTTP/2) — https://datatracker.ietf.org/doc/html/rfc8441
- RFC 9110 (HTTP Semantics) — https://www.rfc-editor.org/rfc/rfc9110.txt · §10.2.3, §15.6.4
- RFC 2616 §2.2 (Separatoren) — https://datatracker.ietf.org/doc/html/rfc2616#section-2.2
- draft-ietf-httpbis-rfc6265bis — https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis
- WHATWG WebSockets Standard — https://websockets.spec.whatwg.org/
- IANA WebSocket Registries — https://www.iana.org/assignments/websocket/websocket.xhtml
- MQTT v5.0 (OASIS, 07.03.2019) — https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
- MDN WebSocket / error_event / Navigator.onLine — https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
- `man 7 tcp` — https://man7.org/linux/man-pages/man7/tcp.7.html
- PostgreSQL `NOTIFY` — https://www.postgresql.org/docs/current/sql-notify.html

**Rust-Bibliotheken**
- axum 0.8.9 `extract::ws` — https://docs.rs/axum/0.8.9/axum/extract/ws/index.html
- axum CHANGELOG — https://github.com/tokio-rs/axum/blob/main/axum/CHANGELOG.md
- axum 0.8.0 Announcement (01.01.2025) — https://tokio.rs/blog/2025-01-01-announcing-axum-0-8-0
- axum Quellcode `extract/ws.rs`, `serve/mod.rs` — https://github.com/tokio-rs/axum/blob/main/axum/src/
- axum Beispiele `websockets`, `websockets-http2`, `chat` — https://github.com/tokio-rs/axum/tree/main/examples
- axum Issue #3003 (21.10.2024, offen) — https://github.com/tokio-rs/axum/issues/3003
- axum PR #3831 (11.07.2026, offen) — https://github.com/tokio-rs/axum/pull/3831
- axum Issue #2673 (SSE-Gegenbeispiel) — https://github.com/tokio-rs/axum/issues/2673
- tokio `sync::broadcast` / `watch` / `mpsc` / `select!` — https://docs.rs/tokio/latest/tokio/sync/
- tokio-util `CancellationToken` / `TaskTracker` — https://docs.rs/tokio-util/latest/tokio_util/
- tungstenite / tokio-tungstenite — https://docs.rs/tungstenite/, https://docs.rs/tokio-tungstenite/
- hyper `upgrade`, hyper-util `UpgradeableConnection` — https://docs.rs/hyper/latest/hyper/upgrade/
- tower-http `timeout` — https://docs.rs/tower-http/latest/tower_http/timeout/
- sqlx `PgListener` — https://docs.rs/sqlx/latest/sqlx/postgres/struct.PgListener.html
- async-broadcast — https://docs.rs/async-broadcast/latest/async_broadcast/
- postage — https://docs.rs/postage/latest/postage/broadcast/

**Infrastruktur / Proxies**
- nginx WebSocket + Log-Modul + Proxy-Modul — https://nginx.org/en/docs/http/websocket.html
- Apache httpd Logs — https://httpd.apache.org/docs/2.4/logs.html
- Caddy Logging — https://caddyserver.com/docs/logging
- HAProxy 3.0 Configuration §4.2 — https://docs.haproxy.org/3.0/configuration.html
- AWS ALB / Classic ELB Idle Timeout — https://docs.aws.amazon.com/elasticloadbalancing/
- AWS API Gateway WebSocket Limits — https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-execution-service-websocket-limits-table.html
- Azure Load Balancer / Application Gateway WebSocket — https://learn.microsoft.com/en-us/azure/
- GCP Load Balancing Request Distribution — https://docs.cloud.google.com/load-balancing/docs/https/request-distribution
- Cloudflare WebSockets — https://developers.cloudflare.com/network/websockets/

**Auth-/Realtime-Anbieter und -Frameworks**
- Microsoft SignalR Auth + Security — https://learn.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz
- Azure Web PubSub — https://learn.microsoft.com/en-us/azure/azure-web-pubsub/
- AWS AppSync Realtime WebSocket Client — https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html
- AWS SDK Retry Behavior — https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html
- Kubernetes apiserver WebSocket-Protocol-Authenticator — https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/request/websocket/protocol.go
- graphql-ws PROTOCOL.md — https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md
- Centrifugo (Auth, Codes, Configuration) — https://centrifugal.dev/docs/
- centrifuge-js — https://github.com/centrifugal/centrifuge-js
- Discord Gateway + Opcodes — https://docs.discord.com/developers/events/gateway
- Pusher Channels Protocol — https://pusher.com/docs/channels/library_auth_reference/pusher-websockets-protocol/
- Socket.IO Server/Client Options + Middlewares — https://socket.io/docs/v4/
- Phoenix Channels + `socket.js` — https://phoenix.hexdocs.pm/channels.html
- Ably Auth + Connection States — https://ably.com/docs/auth/token
- Firebase Manage Sessions — https://firebase.google.com/docs/auth/admin/manage-sessions
- Home Assistant WebSocket API — https://developers.home-assistant.io/docs/api/websocket/
- Slack RTM (Legacy) — https://docs.slack.dev/legacy/legacy-rtm-api/
- python-websockets Authentication — https://websockets.readthedocs.io/en/stable/topics/authentication.html
- OWASP: WSTG-CLNT-10, REST Security Cheat Sheet, WebSocket Security Cheat Sheet

**Praxisberichte (mit Datum)**
- Marc Brooker, „Exponential Backoff And Jitter", AWS Architecture Blog, **04.03.2015** (Update Mai 2023) — https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
- Simulator-Code — https://github.com/awslabs/aws-arch-backoff-simulator
- Discord, „Behind the Scenes of the 3/25/26 Voice Outage", **29.04.2026** — https://discord.com/blog/behind-the-scenes-of-the-3-25-26-voice-outage
- Slack, „Migrating Millions of Concurrent Websockets to Envoy", **15.03.2021** — https://slack.engineering/migrating-millions-of-concurrent-websockets-to-envoy/
- Azure, „Transient fault handling", `ms.date: 26.02.2026` — https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults
- Google Cloud, „Exponential backoff", Stand **29.07.2026** — https://docs.cloud.google.com/memorystore/docs/redis/exponential-backoff

**Tauri**
- Tauri v2 WebSocket-Plugin — https://v2.tauri.app/plugin/websocket/
- Tauri v2 JS-Referenz WebSocket — https://v2.tauri.app/reference/javascript/websocket/
- Tauri WebView-Versionen — https://v2.tauri.app/reference/webview-versions/
- Tauri v2.4.0 Release (Cookie-API) — https://v2.tauri.app/release/tauri/v2.4.0/
- Tauri Issue #13045 (Cookie-Store-Divergenz) — https://github.com/tauri-apps/tauri/issues/13045
- Tauri Issue #4263 (Proxy-Konfiguration) — https://github.com/tauri-apps/tauri/issues/4263