simulations

Keeping the line open

Request/response ends the conversation on purpose. Everything here — polling, long-polling, SSE, WebSockets, gRPC streams, QUIC, webhooks — is a different answer to one question: how does the server speak when it has something to say?

Keeping the line open

topic

One question, seven answers, and every one of them is a trade the map below makes visible.

hold the questionhold the answerspeak both waysmultiplex itdrop TCPor invert itPollingask again, and again＋Long pollingask, and wait＋SSEone-way stream＋WebSocketsboth ways, one socket＋HTTP/2 · gRPCstreams in one pipe＋QUIC · HTTP/3streams without TCP＋Webhooksthe server calls you＋

HTTP's native shape is a transaction: the client asks, the server answers, the conversation is over. The moment your product needs the server to speak first — a message arrived, a price moved, a build finished — that shape fails you, and everything on this map is a workaround, an inversion, or a replacement for it.

The answers arrange themselves by two questions. Who can start a message: only the client (polling, long-polling), the server on a one-way channel (SSE), or either side (WebSockets, gRPC streams)? And what carries it: ordinary HTTP requests, one held-open HTTP response, an upgraded TCP socket, or multiplexed streams over HTTP/2 and QUIC?

The trade that never goes away: an open line is state. A million idle request/response clients cost a server nothing; a million open sockets are a million entries in somebody's memory, heartbeats on somebody's timer, and a stampede when a balancer restarts. Every stop below is partly about who holds that state and what it costs.

a ＋ goes one level deeper — click the box

go deeper

references

High Performance Browser Networking — Real-TimeChapters 15–17: XHR, SSE and WebSocket, with the transport costs measured.