Backend Development 7 min read

Why Keep-Alive Isn’t Enough: From Ajax Polling to WebSocket Mastery

This article explains the limits of HTTP keep-alive, compares Ajax polling and long‑polling techniques for server push, and then details how the WebSocket protocol establishes a full‑duplex connection through a handshake and data‑transfer phase.

Efficient Ops
Efficient Ops
Efficient Ops
Why Keep-Alive Isn’t Enough: From Ajax Polling to WebSocket Mastery

1. Warm‑up: Keep‑Alive

Keep‑alive is a client‑side suggestion to reuse the TCP connection after an HTTP request/response finishes, indicated by the request header

Connection: keep-alive

. It is merely a hint; the server may ignore it or close the connection for other reasons.

In plain terms, keep‑alive just asks the server not to hang up, but the server decides based on its own policy.

Keep‑alive is part of the HTTP protocol; the client can initiate requests, while the server only responds, so it cannot be used for server‑initiated push messages.

2. How the server can send messages to the client

Historically, servers could not push messages directly. Techniques such as Ajax polling and long‑polling simulate push behavior.

What is Ajax polling?

Ajax polling repeatedly sends a request every few seconds to ask the server whether new information is available.

<code>Client: Any new info? (Request)
Server: No (Response)
Client: Any new info? (Request)
Server: No (Response)
...</code>

This approach greatly increases server load and is relatively slow.

What is Long Poll?

Long poll works similarly but the request blocks until the server has a message to return.

<code>Client: Any new info? Wait until you have something (Request)
Server: (Response when a message arrives)</code>

Long poll reduces load but requires the server to handle many concurrent blocked connections, typically using asynchronous non‑blocking models such as Nginx.

Having both blocking behavior and high concurrency is almost impossible.

Summary

Both Ajax polling and long poll achieve real‑time notification but each has drawbacks; a more efficient solution is needed.

3. WebSocket arrives

WebSocket provides full‑duplex communication between client and server, solving the limitations of Ajax polling and long poll.

Handshake

The handshake consists of an upgrade request from the client and a 101 Switching Protocols response from the server. Important request headers include:

<code>Connection: Upgrade
Upgrade: websocket
Host: 0.0.0.0:9501
Sec-WebSocket-Key: K8o1cNIxO2pR6inTIDBSgg==
Sec-WebSocket-Version: 13</code>

The server replies with:

<code>Connection: Upgrade
Sec-WebSocket-Accept: GnoYH/ip/ZMh+a5rX5P/YR6e68g=
Sec-WebSocket-Version: 13
Upgrade: websocket</code>

When the status code 101 is received, the handshake succeeds and data transmission can begin.

Data Transfer

Modern browsers (Chrome, Firefox, Edge, Safari) have built‑in JavaScript WebSocket clients. Server‑side implementations can use libraries such as PHP’s Swoole or Workerman.

Non‑WebSocket clients cannot communicate with a WebSocket server.
WebSocketHTTPKeep-AliveAJAXlong polling
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.