0Pricing
WebSockets & Realtime Systems Programming · 课时

WebSockets 负载均衡

配置负载均衡器（例如 Nginx、HAProxy），以正确处理会话粘滞和 WebSocket 升级。

WebSockets 负载均衡 是 CoddyKit 上的免费 WebSockets & Realtime Systems Programming 课时。 这是第 2 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 WebSockets & Realtime Systems Programming 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 WebSockets & Realtime Systems Programming 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Scaling WebSockets with Load Balancers

When your WebSocket application grows, a single server might not handle all connections efficiently. Load balancing helps by distributing these connections across multiple servers.

This improves performance, reliability, and allows your application to handle more users. It's a crucial step for high-traffic realtime systems to ensure availability and responsiveness.

The WebSocket Handshake

Unlike regular HTTP connections, WebSockets begin with a special "handshake" process that uses HTTP. Your client sends an initial HTTP request to the server, asking to "upgrade" the connection.

This request includes specific HTTP headers that signal the intent to switch protocols. If the server agrees, it responds with an HTTP 101 Switching Protocols status, and the connection then becomes a full-duplex WebSocket.

Load Balancers & Upgrade Headers

A standard HTTP load balancer might not correctly process the WebSocket upgrade request. It needs specific configuration to properly forward the special HTTP headers essential for the handshake. These headers include:

  • Connection: Upgrade
  • Upgrade: websocket
  • Sec-WebSocket-Key
  • Sec-WebSocket-Version

Without proper forwarding, the WebSocket handshake will fail, preventing the connection from establishing.

Sticky Sessions: Essential for WebSockets

Once a WebSocket connection is established, it's persistent. It's often critical that all subsequent messages from a client go to the same backend server that handled the initial handshake and established the connection.

This is known as a "sticky session" or "session persistence." If a client's messages are routed to a different server, the connection will break or behave unexpectedly, as the new server won't recognize the existing WebSocket session.

How Sticky Sessions Work

Load balancers use different methods to ensure sticky sessions:

  • IP Hash: The load balancer uses the client's IP address to consistently route them to the same backend server. This is simple but less effective if many users share an IP (e.g., behind a NAT).
  • Cookie-Based: The load balancer sets a special cookie in the client's browser. Subsequent requests include this cookie, allowing the load balancer to route them to the correct server. This method is generally more robust.

Nginx: Proxying WebSocket Upgrades

Nginx is a popular, high-performance web server that also excels as a reverse proxy and load balancer. To handle WebSockets, Nginx needs configuration to correctly forward the upgrade headers, ensuring the initial HTTP handshake completes successfully.

The proxy_set_header directives for Upgrade and Connection are crucial. Also, a long proxy_read_timeout is recommended for persistent WebSocket connections.

http {
    upstream websocket_backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location /ws/ {
            proxy_pass http://websocket_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_read_timeout 86400s; # Long timeout for WebSockets
        }
    }
}

Nginx: Implementing Sticky Sessions

To ensure sticky sessions with Nginx, you can use the ip_hash directive in your upstream block. This directive ensures that requests from the same client IP address are consistently routed to the same backend server.

While straightforward, remember that IP hash might not be ideal for all scenarios, especially when multiple users share a single public IP address.

http {
    upstream websocket_backend {
        ip_hash; # Enables sticky sessions by client IP
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location /ws/ {
            proxy_pass http://websocket_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_read_timeout 86400s;
        }
    }
}

HAProxy: Basic WebSocket Configuration

HAProxy is another powerful and widely used open-source load balancer, especially known for its high availability and advanced routing capabilities. Configuring HAProxy for WebSockets involves setting the correct operating mode (mode http) and creating rules to identify and route WebSocket traffic.

An Access Control List (ACL) is often used to detect the Upgrade: websocket header and direct traffic to a specific backend server pool.

frontend http_front
    bind *:80
    mode http
    default_backend ws_backend

backend ws_backend
    mode http
    option http-server-close
    acl is_websocket hdr(Upgrade) -i websocket
    use_backend ws_servers if is_websocket
    default-server inter 1s fall 2 rise 5

backend ws_servers
    mode http
    balance roundrobin
    server web1 192.168.1.1:8000 check
    server web2 192.168.1.2:8000 check

HAProxy: Cookie-Based Sticky Sessions

For more robust sticky sessions, HAProxy can insert a cookie into the client's browser that identifies the specific backend server the client is connected to. The client then sends this cookie with all subsequent requests, ensuring they are consistently routed to the same server.

This method provides better stickiness than IP hash, especially in environments where client IPs might change or be shared.

backend ws_servers
    mode http
    balance roundrobin
    cookie SERVERID insert indirect nocache # Insert a cookie
    server web1 192.168.1.1:8000 check cookie s1
    server web2 192.168.1.2:8000 check cookie s2

Check Your Understanding

Which of the following are essential considerations when configuring a load balancer for WebSocket traffic?

Load Balancing WebSockets Recap

In this lesson, we explored the critical aspects of load balancing WebSocket applications:

  • WebSockets initiate with an HTTP upgrade handshake, requiring specific headers to be properly forwarded by the load balancer.
  • Sticky sessions are vital to ensure a client maintains its persistent connection with the same backend server throughout its lifecycle.
  • Load balancers like Nginx and HAProxy can be configured to handle WebSocket upgrades and implement sticky sessions using methods such as IP hash or cookie-based routing.

Mastering these configurations is key to building scalable, resilient, and high-performance realtime systems.

常见问题解答

「WebSockets 负载均衡」课时是免费的吗？

是的 — 「WebSockets 负载均衡」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 WebSockets & Realtime Systems Programming 课程的其余内容，请升级到 CoddyKit PRO。 WebSockets & Realtime Systems Programming 课程共包含 4 节课。

「WebSockets 负载均衡」这节课中我会学到什么？

配置负载均衡器（例如 Nginx、HAProxy），以正确处理会话粘滞和 WebSocket 升级。 你通过在浏览器中直接运行的动手代码来练习 WebSockets & Realtime Systems Programming，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 WebSockets & Realtime Systems Programming 需要有经验吗？

无需任何先前经验。CoddyKit 上的 WebSockets & Realtime Systems Programming 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 2 节课，共 4 节。

「WebSockets 负载均衡」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 WebSockets & Realtime Systems Programming 课中编写并运行代码吗？

能。每节 WebSockets & Realtime Systems Programming 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 横向扩展策略
  2. WebSockets 负载均衡
  3. 分布式状态管理
  4. 使用 Redis 构建发布/订阅后端
← 返回 WebSockets & Realtime Systems Programming