Compare RSocket's TCP and WebSocket transports in Spring, and explain what session resumption (resume) is and how it interacts with security.

**Transports.** RSocket is transport-agnostic and Spring ships two: - **TCP** — a raw TCP socket with RSocket framing. Server: `TcpServerTransport`; client: `TcpClientTransport`. In Boot, `spring.rsocket.server.transport=tcp` and `spring.rsocket.server.port=7000`. Characteristics: lowest overhead, full duplex, ideal for **internal service-to-service** links. Not reachable from browsers; may be blocked by corporate firewalls/proxies that only allow HTTP(S). - **WebSocket** — RSocket framed inside WebSocket frames, which ride on an HTTP upgrade. Server: `WebsocketServerTransport`, integrated with WebFlux and mapped at a path (`spring.rsocket.server.transport=websocket`, `spring.rsocket.server.mapping-path=/rsocket`). Characteristics: traverses HTTP proxies, load balancers, and firewalls; reachable from **browser** clients (rsocket-js); slightly more overhead. Runs on the same server port as the HTTP app when embedded in WebFlux. - You can also run **standalone vs WebFlux-embedded** servers; TLS (TCP) or WSS (WebSocket) provides transport encryption — mandatory when carrying auth metadata. **Resume (session resumption).** RSocket connections are long-lived; transports drop (network blips, LB failover, mobile handover). **Resume** is a protocol capability that lets a client transparently **reconnect and continue the same logical session** instead of tearing down all streams and re-establishing. How it works: - The connection is created **resumable**: both peers agree during SETUP (a resume token is negotiated). In Spring/RSocket-Java you enable it with `RSocketServer.resume(new Resume())` on the server side (often via an `RSocketServerCustomizer`) and, on the requester, `RSocketConnector`/`RSocketRequester.Builder.rsocketConnector(c -> c.resume(new Resume()))`. - Each side keeps a **frame cache/implied-position buffer** of sent frames. On disconnect, the client opens a new transport connection and sends a **RESUME frame** carrying the **resume token** and its last-received position. The server matches the token to the retained session, retransmits missing frames from its buffer, and the in-flight request-streams/channels continue **without re-running SETUP**. - `Resume` is configurable: session duration/timeout, retry/backoff strategy, and the store (in-memory by default; the frame buffer is bounded). **Security interaction (the principal-level insight):** - Because resume **skips a fresh SETUP handshake**, the **authentication established at setup persists** across reconnects — the resume token effectively represents an authenticated session. That's convenient (no re-auth on every network blip) but means the **resume token is a bearer secret**: anyone who steals it could resume the authenticated session. Therefore: - **Always** run resumable connections over **TLS/WSS** so the token can't be sniffed. - **Bound** the resume session (timeout) so a stolen token has a limited window, and bound the **frame buffer size** to prevent memory-exhaustion DoS from a peer that never resumes. - Consider **per-request authentication** for sensitive routes so identity is re-asserted per frame, not solely inherited from the resumed session. - Token rotation/regeneration semantics are limited — treat resume tokens like session cookies: protect, scope, and time-box them. - New request frames after a resume still pass through the `PayloadSocketAcceptorInterceptor` authorization rules, so route-level authorization continues to apply; it's the *authentication identity* that is carried, not a bypass of authorization. **Edge cases / gotchas:** - **Buffer sizing**: too small and resume fails (frames evicted → session can't be recovered, client must reconnect fresh and re-SETUP); too large and it's a memory/DoS vector. - **Both peers must enable resume**; asymmetric config means the server rejects the RESUME frame and the client falls back to a new connection (losing streams). - **Load balancers**: resume requires reconnecting to a server that holds the session state. With multiple instances, sticky routing or a shared/session-aware layer is needed — naive round-robin LBs break resume. - **WebSocket + LB idle timeouts** can silently drop connections; resume mitigates the stream loss but you must tune keepalive. - Resume is **not** message durability/guaranteed delivery — it recovers a live session over a transient drop, not messages across a full session-timeout or server restart (unless a persistent frame store is used). **When to use:** resume shines for **mobile/unreliable networks** and long-lived streams where re-establishing (and re-authenticating) is expensive; internal, stable data-center links often skip it. Choose **TCP** for internal high-throughput services, **WebSocket** for browser reach or firewall traversal.