Building a Low-Latency Multiplayer Game Backend with WebRTC

A WebSocket runs over TCP, which guarantees ordered, reliable delivery — every byte arrives, in the order sent, or the connection stalls until it does. For a chat app or a turn-based game, that's exactly right: you never want message 5 to render before message 4. For a real-time multiplayer game sending position updates 20-60 times per second, that guarantee actively hurts: TCP's retransmission-and-reorder behavior means one lost packet head-of-line-blocks every packet behind it, so a single dropped position update can freeze the whole stream for one to two round trips while TCP recovers it — and by the time it arrives, three newer position updates have already been generated and are now stale.

WebRTC's RTCDataChannel runs over SCTP inside DTLS, and critically exposes ordered: false and maxRetransmits: 0 as configuration — an unordered, unreliable mode where a lost packet is simply gone, and the next one arrives as soon as it's ready, with no blocking. For position updates, that's correct: you want the latest state, and an update from three frames ago that finally arrives late is worse than useless, it's actively wrong. Reserve a second, reliable channel (ordered: true) for events that must not be dropped — a player firing a weapon, joining, or disconnecting — and keep position/velocity updates on the unreliable channel.

WebRTC connects two peers directly, but neither peer has a public address to connect to before the connection exists — that's the chicken-and-egg problem signaling solves. A signaling server (a plain WebSocket or HTTP server you run — WebRTC intentionally doesn't specify this part) relays each peer's session description (SDP: codecs, media/data capabilities) and ICE candidates (possible network paths: local IP, public IP via STUN, relay via TURN) to the other peer, so each side can attempt to open a direct connection once it has learned the other's addresses.

Most home and corporate NATs let a direct peer-to-peer connection through once both sides have exchanged the right candidates — a STUN server tells a client its own public IP:port as seen from outside its NAT, which is usually enough for the two peers to punch through to each other. Some NAT configurations (symmetric NAT, restrictive corporate firewalls) never allow a direct path, and the connection falls back to a TURN server, which relays every packet between the two peers — functionally identical to a game server, but at TURN-relay latency and bandwidth cost instead of direct peer latency. Budget for TURN fallback in production: a meaningful fraction of real-world connections (often cited around 10–20% depending on network mix) cannot connect peer-to-peer and need it.

Even a direct peer connection has real network latency — 40-100ms is typical between two home connections on different continents' edges of a region. If a player's own input only visibly moves their character after a round trip to the peer and back, the game feels laggy even though the network is working correctly; the fix is client-side prediction: the local client applies its own input to its own character immediately, without waiting for any network round trip, while also sending that input to the remote peer(s).

The remote peer receives the position update slightly late and needs to reconcile: for the other player's character, simple interpolation between the last two received states is enough (render slightly in the past, smoothly). For your own character if a server-authoritative correction ever disagrees with your prediction (common in server-relayed architectures, less so in pure peer-to-peer where there's no arbiter), reconciliation means snapping to the corrected state and replaying any inputs sent after that state was generated — the same technique competitive shooters use over WebSockets to servers, applied here at the peer level.

The realistic failure: two players are both behind restrictive corporate firewalls that block the UDP ports WebRTC needs, and even the TURN relay (which typically needs a reachable UDP or TCP port) can't establish a session — pc.connectionState stays "connecting" and then transitions to "failed" after ICE gathering times out, typically 20-30 seconds by default. A game that just spins on "connecting…" forever gives the player no actionable information and looks broken rather than explained.

The recovery: set an explicit client-side timeout shorter than the browser's own ICE timeout (10-15 seconds is reasonable for a game lobby), and on connectionState === "failed" or your own timeout firing, surface a specific message ("Could not establish a direct connection — this can happen on restrictive networks") with a fallback path, which for many production games means a server-relayed mode (send state through your own backend over a WebSocket instead of peer-to-peer) rather than leaving the player stuck. This mirrors the broader lesson in graceful degradation patterns: a hard network dependency needs an explicit degraded mode, not just a longer timeout.