104 | Real-Time Revolution: Diving into the World of WebSockets and Long Polling

Introduction

Modern users expect web applications to work as fast and responsive as native software. Chats, stock quotes, collaborative document editing — all these scenarios require instant data exchange. In this article, we’ll break down how Long Polling works, why it was replaced by WebSockets, and how to properly configure these technologies on popular web servers.

The Real-Time Problem and the First Solution: Long Polling

HTTP was originally designed for the request-response model: the client contacts the server, the server replies, and the connection closes. For dynamic applications, this is inconvenient.

Long Polling

Long Polling became a compromise solution:

1. The client sends a request.
2. The server waits for data to appear and does not respond immediately.
3. As soon as data is available, the server responds.
4. The client receives the response and immediately opens a new connection.

Pros:

• fewer redundant requests compared to regular polling;
• data delivered with minimal delay.

Cons:

• HTTP overhead (headers, sessions);
• scalability issues with thousands of connections.

True Bidirectional Communication: WebSockets

WebSockets radically changed the approach. After an HTTP handshake, the connection is “upgraded,” stays open, and allows the server and client to exchange data both ways.

Key advantages:

• full-duplex — bidirectional communication without extra requests;
• single TCP connection — less overhead;
• low latency — ideal for chats, games, trading platforms;
• efficiency — only the payload is transmitted.

Configuring WebSocket Support

Nginx

In the configuration, it’s important to explicitly pass the Upgrade and Connection headers:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

• proxy_http_version 1.1; — required for Upgrade.
• proxy_set_header Upgrade $http_upgrade; — forwards the protocol.
• proxy_set_header Connection "upgrade"; — enables the upgrade.

HAProxy

HAProxy supports WebSockets out of the box, but it’s important to configure timeouts:

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server server1 10.0.0.10:8080 check
    timeout tunnel 1h

• timeout tunnel 1h; — prevents disconnections of long-lived connections.

Caddy

Caddy does everything automatically. A basic configuration is enough:

example.com {
    reverse_proxy localhost:8080
}

If more control is needed:

example.com {
    reverse_proxy /ws/* localhost:8080 {
        header_up -Origin
    }
}

Caddy handles Upgrade/Connection itself, removing the need for manual tweaks.

How Does This Make Sites Better?

• Interactivity: chats, notifications, and game actions happen instantly.
• Reduced load: no constant requests → resource savings.
• Efficiency: applications feel responsive and closer to “live.”

Conclusion

Long Polling was the first step toward real time, but today WebSockets are the de facto standard. Understanding how they work and properly configuring proxying on Nginx, HAProxy, or Caddy is an essential skill for modern DevOps engineers and web developers.

Resources

• RFC 6455 — The WebSocket Protocol
• Nginx Docs — WebSocket proxying
• HAProxy Docs
• Caddy Reverse Proxy