Before discussing this issue, let's assume a classic connection model:
Client -> Load Balancer -> RealServer Pool
And we assume that the load balancing in NAT mode is used here, in this mode:
1. The load balancer only leaves the client with a public IP address (VIP);
2. The requests sent by the client are intercepted by the load balancer, and then forwarded to a server in the RealServer Pool through the scheduling algorithm;
3 . These RealServers are all in a private network and are not visible to the outside world;
4. When the load balancer forwards requests to the real server (RealServer), NAT is performed at the same time, and the connections seen by the real server are all from the load balancer (and the real server). IP of the server on a private network).
First, we analyze from the Client Side (Client->Load Balancer):
the connections on this side are uniquely identified by SourceIP:SoucePort->DesIP:DesPort, so for us, the number of connections that can be supported is only limited by the load balancer number of memory (connections can be 65000+), since both DesIP and DesPort are known to be unique (eg IP:80).
Then analyze it from the Server Side (Load Balancer->RealServer):
the number of connections on this side is just the opposite, and each connection is identified by the IP of the load balancer (called MIP: Mapped IP here) and a random port. That is: MIP: RandomPort -> RealServerIP: 80 In
this way, because the port of the load balancer is also limited by the maximum number of ports of TCP/IP 64k (65536), it can only establish a maximum of 64k server connections (server connections).
Since the bottleneck is likely to appear on the server-side connection, how do the load balancer manufacturers solve this situation?
1. NetScaler
Let's first look at the solution of NetScaler. The solution of NetScaler is very simple. Increase the number of MIPs, so that the maximum number of server connections will become:
MaxServerConnections = 65536 * number of MIPs
2. F5
F5 actually uses the same method, but F5 first establishes a Source-NAT pool, and then adds multiple IP addresses to the SNAT Pool. This gives the exact same maximum number of connections as NetScaler:
SA:SP -> DA:DP
10.1.1.1:1024 -> 10.1.1.100:80
10.1.1.2:1024 -> 10.1.1.100:80
PS: here 10.1.1.1 and 10.1.1.2 are all in a SNAT pool.
The above situations are all theoretical calculation values. The maximum number of connections in the real environment is also limited by various factors:
1. Each connection consumes certain resources, such as CPU and MEM, so the actual value is often difficult to reach the theoretical value. ;
2. Depending on the protocol, the maximum number of connections that can be reached is different. For example, the creation and closing of HTTP/1.0 connections are very fast, and the browser has a limit on the number of concurrent connections, so it is difficult to reach the maximum theoretical value. . HTTP/1.1 supports streamlining technology, and multiple requests can reuse one connection, which greatly reduces the number of concurrent connections. FTP or telnet connections are long connections, which can easily reach the maximum value;
3. Many devices (such as NetScaler) support connection pooling (connection multiplexing) on the server side, and the connections inside are all long connections, which also implement HTTP/1.1 With the streamlined technology inside, one connection can handle multiple client connections. This not only reduces connection resources, but also reduces other resource overhead of the load balancer and reduces the bandwidth of the intranet;
4. Some devices (such as NetScaler's TCP-OFFLOAD) support TCP offload, and only send established connections to On the server side, the three-way handshake of TCP is completely taken over by the load balancer, so that the connection on the server side is reduced exponentially.
Reprinted from: http://www.tektea.com/archives/4140.html , Tea Talk