Równoważenie obciążenia WebSocket
Skonfiguruj load balancery, takie jak Nginx i HAProxy, aby prawidłowo obsługiwały sesje sticky oraz przełączanie na WebSocket.
Równoważenie obciążenia WebSocket to bezpłatna lekcja WebSockets & Realtime Systems Programming na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej WebSockets & Realtime Systems Programming, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs WebSockets & Realtime Systems Programming zawiera 4 lekcji w sumie.
Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.
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: UpgradeUpgrade: websocketSec-WebSocket-KeySec-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 checkHAProxy: 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 s2Check 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.
Często zadawane pytania
Czy lekcja „Równoważenie obciążenia WebSocket” jest bezpłatna?
Tak — pełny tekst „Równoważenie obciążenia WebSocket” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu WebSockets & Realtime Systems Programming, przejdź na CoddyKit PRO. Kurs WebSockets & Realtime Systems Programming zawiera 4 lekcji w sumie.
Co nauczysz się w „Równoważenie obciążenia WebSocket”?
Skonfiguruj load balancery, takie jak Nginx i HAProxy, aby prawidłowo obsługiwały sesje sticky oraz przełączanie na WebSocket. Ćwiczysz WebSockets & Realtime Systems Programming z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć WebSockets & Realtime Systems Programming?
Nie wymagamy żadnego doświadczenia. WebSockets & Realtime Systems Programming w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.
Ile czasu zajmuje lekcja „Równoważenie obciążenia WebSocket”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji WebSockets & Realtime Systems Programming?
Tak. Każda lekcja WebSockets & Realtime Systems Programming zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Strategie skalowania horyzontalnego
- Równoważenie obciążenia WebSocket
- Rozproszone zarządzanie stanem
- Magistrala Pub/Sub z Redis