TCP connections and traffic routing under HTTP load balancing

user_1732769 0
Viewed 756

I'm trying to get my head around what type of load (e.g. in terms of network traffic) a load balancer for HTTP traffic can be expected to receive / forward / redirect.

Consider the following two different HTTP traffic scenarios.

  1. Single HTTP request with a payload that exceeds significantly in size what fits on a single TCP IP packet (i.e. request requires many network packets)
  2. Multiple HTTP requests over a single persistent TCP connection

For each of them:

  • Would all network traffic (e.g. TCP IP packets) go through the load balancer itself? (i.e. load balancer "acting like a cable" seeing and forwarding all traffic so-to-speak)
  • Or would the load balancer get the client to establish a direct TCP connection with the IP address of the app servers alleviating the LB of the network traffic?

Does this depend on the protocol? (e.g. say HTTP requests vs WebSocket)? Or do these protocols require that a TCP connection is always available with the load balancer receiving and forwarding all IP traffic throughout the full duration of the WebSocket connection or request-response HTTP transmission?

             

haproxy load-balancing tcp http websocket
1 Answers

It depends.

There are application layer load balancers like HAProxy, where the full HTTP request and response is passed through the proxy. There are two separate TCP connections here: one between client and load balancer and another between load balancer and upstream server. The choice of the upstream server can be done based on the contents of the HTTP request, for example the Host header and/or path but also session cookies - to make sure that the same session is always handled by the same upstream server. If the decision for the upstream server is done on the HTTP request then the connection to the upstream server can only be established after the HTTP request was read, since it is not known before. But the request does not need to be inside a single packet.

There are network or transport layer load balancers which do not act on the packet payload at all. Instead the choice of upstream server is usually done based on the client IP, so that the same client ends up on the same upstream server. In this case the decision which upstream to use is already done on the first packet (i.e. the SYN starting the TCP handshake) and the client essentially establishes the connection directly with the upstream proxy - the load balancer only forwards the packets like a router does. The size of the HTTP request does not matter here either since the TCP payload is not even inspected to make the routing decision.

With a network or transport layer load balancer there can be asymmetric routing, i.e. the response might go a different way and not pass through the load balancer. With application layer load balancing the response goes back through the load balancer instead.

user_30810180
Related