Routing strategies at your load balancer
Your load balancer can present a number of different strategies for choosing which Diffusion™ server a new client connection is routed to. After a client connection has been routed to a Diffusion server, ensure that the client is always routed to the Diffusion server that its session exists on.
The routing strategies that are available to you depend on the load balancer that you choose to use. The following table lists some examples of routing strategies:
Name | Description |
---|---|
Round-robin | Each available Diffusion server is chosen in turn, with none favored. |
Fewest clients | The Diffusion server with the fewest number of client connections in progress is chosen. |
Least loaded | The Diffusion server with the lowest CPU load is chosen. |
Routing connection that use HTTP protocols
To route HTTP traffic, the load balancer must be able to inspect the HTTP headers and extract session information.
Diffusion sets an HTTP cookie named session with a connection-specific ID specifically for this purpose. Your load balancer can use this cookie to maintain a table of client to server mappings.
The session cookie is flagged with HttpOnly, which prevents scripts accessing the cookie. The session cookie is not flagged with Secure, which prevents the cookie from being sent over non-secure connections.
Sample HTTP conversation, cookie highlighted:
POST /diffusion/ HTTP/1.1 Host: localhost:8080 Connection: keep-alive Content-Length: 0 tt: 90 Origin: http://localhost:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/48.0.2564.82 Chrome/48.0.2564.82 Safari/537.36 m: 0 ty: B v: 4 Content-Type: text/plain;charset=UTF-8 Accept: */* Referer: http://localhost:8080/tools/DhtmlClient.html Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 HTTP/1.1 200 OK Set-Cookie: session=c04815df73a1646d-0000000000000000; HttpOnly Access-Control-Allow-Origin:http://localhost:8080 Cache-Control:no-store, no-cache Content-Type:text/plain; charset=UTF-8 Content-Length:41 4.100.4.c04815df73a1646d-0000000000000000 POST /diffusion/ HTTP/1.1 Host: localhost:8080 Connection: keep-alive Content-Length: 0 Origin: http://localhost:8080 c: c04815df73a1646d-0000000000000000 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/48.0.2564.82 Chrome/48.0.2564.82 Safari/537.36 m: 1 Content-Type: text/plain;charset=UTF-8 Accept: */* Referer: http://localhost:8080/tools/DhtmlClient.html Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Cookie: session=c04815df73a1646d-0000000000000000
Diffusion uses a session ID for the cookie. This enables the load balancer to maintain a map of each session ID to its target Diffusion server.
Instead, you can disable the Diffusion cookie and configure the load balancer to set a cookie that identifies the target server instead of the session. While the overhead of transmitting a cookie is still present between client and load balancer, the identifier can be smaller because there are a smaller number of servers than client sessions. Load balancers that use the cookie to identify the Diffusion server can send less data down the wire and consume fewer resources.
If you want to configure your load balancer to inject its own cookie, you can disable this Diffusion cookie. To disable the Diffusion cookie, set the <disable-cookie> element in the WebServer.xml configuration file of your Diffusion to true.
Routing connections that use streaming protocols
Streaming protocols that open a single socket and remain connected until they are no longer required appear immune to requiring any special routing considerations. However, in the event that connection keep-alive is enabled to handle reconnections in case of temporary connection loss, it is important that the reconnection attempt is routed to the original server.
Without the ability to parse headers (and indeed, the absence of a session ID at all), the most common method for routing a streaming protocol such as WebSocket is to create a client/server mapping based on the IP addresses of the endpoints. This technique is generally referred to as Sticky-IP, and has the advantage of also working with HTTP transports, if required.
For F5® 's Sticky IP, ensure that the Source Address Translation option is set to Auto Map.
The drawback of this approach is that multiple users masquerading behind a proxy or access point can have the same IP address, and all requests from clients with that IP address are routed to the same Diffusion instance. Load balancing still occurs, but some hosts might be unfairly loaded.