Real-Time Protocols: WebSocket, SSE and WebRTC

A chat message, a live score or a video call cannot wait for the client to ask. Request and response, the shape of everything in the previous topics, leaves the server with news and no way to deliver it, and three protocols exist to close that gap, each with a different idea of who may speak and what happens when the line goes quiet.

Every member here is described in the same four steps: how the connection starts, who may send, what one message looks like on the wire, and how it recovers from a drop. The topic opens on the family map, then takes WebSocket, server-sent events and WebRTC in turn, with the NAT traversal WebRTC depends on and one call followed candidate by candidate. A comparison sets the three side by side, and a gotcha covers the idle timeouts that cut quiet connections.

Building a chat or notification service on top of these, with its scaling and fan-out, belongs to system design rather than to this topic.

By the end you can trace a WebSocket upgrade, explain how an event stream resumes, order the steps that connect two browsers, tell STUN from TURN, and keep a quiet connection alive through a load balancer.