Introduction to Real-Time Communication

Some applications need to show new information the moment it happens. A chat message, a live cricket score, a rising stock price. Waiting even a few seconds feels broken. Delivering updates to the user as soon as they happen is called real-time communication.

This chapter explains the three most popular techniques for it: Long-Polling, WebSockets, and Server-Sent Events. Before we compare them, we need to understand the problem they all solve. The problem starts with how HTTP works.

How a Regular HTTP Request Works

HTTP is a simple conversation with one strict rule: the client always speaks first. A regular HTTP request follows three steps:

1. The client opens a connection and requests data from the server.
2. The server prepares the response.
3. The server sends the response back, and the exchange is complete.

This model works well for loading web pages. You ask for a page, you get a page.

Now notice the limitation: the server can never speak first. If new data appears on the server, such as a new chat message for you, the server has no way to reach out and tell you. It must wait until your client asks again.

The Simplest Fix: Keep Asking (Polling)

The most obvious workaround is to ask again and again. The client sends a request to the server on a fixed schedule, for example every few seconds, to check for new data. This technique is called polling. Older web applications call it Ajax polling, because they use Ajax (a browser technique for sending requests in the background without reloading the page).

Here is how polling works:

1. The client requests data from the server using a regular HTTP request.
2. The server responds right away. If there is no new data, it returns an empty response.
3. The client waits for the polling interval (for example, two seconds).
4. The client repeats the same request, over and over.

Polling is like checking your mailbox every five minutes. Most trips, the box is empty, so the walk was wasted. And even with all that effort, a letter can still sit unseen for up to five minutes.

Why Polling Does Not Scale

Polling has three problems:

1. Wasted requests. Most responses are empty. Every request still pays the full HTTP cost: opening a connection, sending headers, and processing on the server.
2. Delayed updates. New data waits on the server until the next poll. On average, an update is delayed by half the polling interval.
3. Heavy server load. Ten thousand clients polling every two seconds means five thousand requests per second, even when nothing is happening.

You can shorten the polling interval to make updates fresher, but that makes the waste and the server load even worse. Polling forces you to trade freshness against cost.

What Is Next

The rest of this chapter covers three techniques that solve this problem in smarter ways:

• Long-Polling: the server holds your request open until it has news. Covered in What is Long-Polling?.
• WebSocket: one open connection where both sides can send messages at any time. Covered in What is WebSocket?.
• Server-Sent Events: one open connection where the server streams updates in one direction. Covered in What are Server-Sent Events?.

After that, we will put them side by side in Difference Between Long-Polling, WebSockets, and Server-Sent Events and learn how to pick the right one.