在探討這個問題前，我們先假設一種經典的連接模型：
Client -> Load Balancer-> RealServer Pool
並且我們假設這里使用NAT模式的負載均衡，在這種模式下:
1.負載均衡器只留給客戶端一個公網IP地址(VIP);
2.客戶端發來的請求都被負載均衡器端截，然后通過調度算法轉發到RealServer Pool里面的某台服務器;
3.這些RealServer都在一個私有網絡里面，對外不可見;
4.負載均衡器轉發請求到真實服務器(RealServer)的時候同時做了NAT，真實服務器看到的連接都是來自負載均衡器的(和真實服務器在一個私有網絡的IP)。
首先，我們從Client Side(Client->Load Balancer)來分析：
這端的連接都由SourceIP:SoucePort->DesIP:DesPort唯一標識，所以對我們來說，能支持的連接數僅僅受限於負載均衡器的內存數(連接數可以是65000+)，因為DesIP和DesPort都是已知的唯一的(比如IP:80).
然后再從Server Side(Load Balancer->RealServer)來分析：
這端的連接數剛好相反，每個連接都由負載均衡器的IP(這里稱MIP:Mapped IP)和隨機的端口進行標識。即： MIP:RandomPort -> RealServerIP:80
這樣，因為負載均衡器的端口也受限於TCP/IP的最大端口數64k(65536)限制，因此最多只能建立64k的服務器連接(server connnections).
由於瓶頸很可能就出現在服務器端連接上，針對這種情況，各負載均衡器廠家是怎么解決的呢？
1. NetScaler
我們首先來看NetScaler的解決辦法，NetScaler的解決辦法很簡單，增加MIP的個數，這樣最大的服務器連接數將變成：
MaxServerConnections = 65536 * MIP數
2. F5
F5其實也使用了一樣的辦法，但是F5首先建立一個Source-NAT pool,然后在SNAT Pool里面加入多個IP地址。這樣得到的最大連接數和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: 這里10.1.1.1和10.1.1.2都在一個SNAT pool里面。
上述情況都是理論計算值，真實環境下的最大連接數還受限於各種因素：
1. 每個連接都要耗費一定的資源，比如CPU、MEM，所以，真實值往往很難達到理論值；
2. 根據協議的不同，能達到的最大連接數也不一樣，比如HTTP/1.0連接的創建和關閉都非常快，而且瀏覽器對並發連接數有限制，所以，很難達到最大的理論 值。HTTP/1.1支持流線技術，多個請求可以復用一個連接，這樣就大大減少了並發連接數。FTP或者telnet連接都是長連接，很容易達到最大值；
3. 很多設備(比如NetScaler)在服務器端都支持連接池(連接復用)，里面的連接都是長連接，一樣實現了HTTP/1.1里面的流線技術，一個連接就可以處理多個客戶端連接。這樣除了減少連接資源，同時還減少了負載均衡器的其他資源開銷，同時減低了內網的帶寬；
4. 一些設備(比如NetScaler的TCP-OFFLOAD)支持TCP卸載，僅僅把已經建立的連接發到服務器端，而TCP的三次握手完全有負載均衡器接管，這樣，服務器端的連接就成倍的減少。
轉自：http://www.tektea.com/archives/4140.html ，茶話匯