Browser Multiplayer Technology: WebSockets, WebRTC, and How Online Browser Games Work

When you play Agar.io, your browser is communicating with a server dozens of times per second. Other players' movements are arriving as data from that server, your movements are being sent up, and the server is arbitrating who ate whom. This all happens in real time, in a standard web browser, with latency low enough that the game feels responsive. The technology that makes this possible was not available until around 2012, which is why real-time browser multiplayer did not exist at scale in the Flash era.

The Fundamental Problem: HTTP Was Not Built for This

Standard HTTP, the protocol the web runs on, is request-response: your browser asks for a resource, the server sends it, the connection closes. This is efficient for loading web pages but completely inadequate for real-time games. If you used standard HTTP for an .io game, getting updated game state would require your browser to send a new request every frame, and the server would need to respond with the entire game state every frame. The overhead of opening and closing thousands of connections per second would make the system unusably slow.

Two technologies solve this problem in the browser: WebSockets for most multiplayer games, and WebRTC for the most latency-sensitive applications.

WebSockets: The Standard Solution

A WebSocket connection starts as an HTTP connection and then upgrades itself into a persistent bidirectional channel. Once the upgrade handshake completes, either end can send data at any time without waiting for a request. The connection stays open indefinitely, and the overhead per message is minimal — a few bytes of framing rather than a full HTTP header block.

For an .io game, WebSockets work like this: you load the game page (standard HTTP), the game code opens a WebSocket connection to the game server, and from that point on, all game communication travels over the persistent channel. The server sends game state updates to your client, typically 20 to 60 times per second. Your client sends your input, typically every frame or on change. The messages are small binary payloads, often custom-serialized for efficiency.

WebSocket servers for games need to handle thousands of simultaneous connections efficiently. Node.js with Socket.io, or a custom server in Go or Rust, are common choices because they can handle large numbers of concurrent WebSocket connections without the overhead that thread-per-connection architectures would impose.

WebRTC: Peer-to-Peer and Ultra-Low Latency

WebRTC (Web Real-Time Communication) is the technology originally designed for browser-to-browser video and audio calling. It establishes peer-to-peer connections directly between browsers, bypassing a central server for data transmission. The latency advantage over WebSockets is meaningful: a WebSocket message travels from your browser to a server and back to the other player, while a WebRTC message can travel directly from your browser to the other player's browser. For players on the same region, this cuts round-trip time by 30 to 60 percent.

WebRTC also offers UDP-like behavior through its data channel API. Standard WebSockets run over TCP, which guarantees delivery and ordering but retransmits lost packets before delivering subsequent ones. In a real-time game, a lost packet containing position data is often better discarded than retransmitted — by the time the retransmission arrives, the position is stale anyway. WebRTC data channels can operate in unreliable, unordered mode, behaving like UDP and avoiding the head-of-line blocking that TCP retransmission causes.

WebRTC complexity is significantly higher than WebSockets. Establishing a peer connection requires signaling (coordination through a server to exchange connection information), STUN/TURN server infrastructure to handle NAT traversal, and careful handling of connection failures. Most browser multiplayer games use WebSockets rather than WebRTC because the latency advantage does not justify the implementation complexity except for the most demanding applications.

Client-Side Prediction: Making Lag Invisible

The fundamental problem with any networked game is that the server is the authority on game state, but every player experiences some latency between sending input and seeing the result. If your browser must wait 80 milliseconds for the server to confirm your movement before showing it on screen, the game feels unacceptably laggy. The solution is client-side prediction.

With client-side prediction, your browser immediately applies your input to your local game state without waiting for server confirmation. Your character moves the moment you press the key. Simultaneously, the input is sent to the server. When the server's authoritative update arrives, the client compares its predicted state with the server-confirmed state and reconciles any differences. If they match (the common case), nothing visible changes. If they differ (your character was killed by another player while moving), the client corrects to the server state.

This reconciliation produces "rubber-banding" when it goes wrong — the brief jerk as your position snaps from where client prediction placed you to where the server says you actually are. Good rubber-banding is invisible because it happens rarely and the correction is small. Poor rubber-banding produces the lurching teleportation that characterizes a laggy multiplayer game.

Entity Interpolation: Smooth Other Players

Client-side prediction handles your own character. Other players' positions are a different problem. You receive position updates for other players 20 times per second (at a typical server tick rate), but your game renders at 60 frames per second. If you just snap other players to their server-reported positions, they move in jerky steps rather than smoothly.

Entity interpolation solves this by rendering other players slightly in the past, smoothly interpolating between known server-reported positions. If you received position updates at times T=0 and T=50ms, you can render the player's smooth path between those positions at any time in between. The cost is that other players appear 50 to 100 milliseconds behind where they actually are, which is imperceptible in most games but becomes a problem in games where precise position matters for interaction (hitting a fast-moving target, for example).

Server-Side Authority and Cheat Prevention

The most important architectural decision in a multiplayer game is keeping the server authoritative. The server validates all game actions: it checks whether a claimed collision actually happened, whether a resource collection was legitimate, whether a kill was valid given the positions it recorded. Clients can claim anything; the server only acts on what it can verify.

This architecture is inherently more cheat-resistant than client-authoritative designs. A client cannot lie about another player's position because the server tracks all positions independently. A client cannot claim to have killed a player who was out of range because the server knows the range and both positions. Speed hacks, position teleportation, and most automated aimbots (which require knowing the positions of all players, including those outside your visible range) are ineffective against a properly server-authoritative implementation.

The tradeoff is server cost. Processing all game logic server-side requires computational resources proportional to the number of players and the complexity of the game logic. The .io games that serve millions of simultaneous players invest heavily in server infrastructure and horizontal scaling — distributing players across many game servers with matchmaking logic routing players to servers with available capacity.

Understanding these systems changes how you experience online browser games. The smoothness of a well-implemented game is the result of multiple layers of latency compensation working together invisibly. The rubber-banding of a poorly implemented one is a window into the lag that the better systems hide. Browser multiplayer is technically sophisticated enough to hold its own against native game networking, and the best browser multiplayer games demonstrate it conclusively.