單機單IP最大tcp連接數
分類： TCP/IP
2012-04-17 22:22
在tcp應用中，server事先在某個固定端口監聽，client主動發起連接，經過三次握手后建立tcp連接。那么對單機，其最大並發tcp連接數是多少？
如何標識一個TCP連接 在確定最大連接數之前，先來看看系統如何標識一個tcp連接。系統用一個四維數組來唯一標識一個TCP連接：{local ip, local port,remote ip,remote port}。
client最大tcp連接數 client每次發起tcp連接請求時，除非綁定端口，通常會讓系統選取一個空閑的本地端口（local port），該端口是獨占的，不能和其他tcp連接共享。tcp端口的數據類型是unsigned short，因此本地端口個數最大只有65536，端口0是代表全部端口，不能使用，這樣可用端口最多只有65535，所以在作為client端的情況下，最大tcp連接數為65535，這些連接可以連到不同的server ip。 簡單的說就是單機單IP在作為客戶端時只允許同時連接65535個服務(每個服務一個連接的情況下)
server最大tcp連接數 server通常固定在某個本地端口上監聽，等待client的連接請求。不考慮地址重用（unix的SO_REUSEADDR選項）的情況下，即使server端有多個ip，本地監聽端口也是獨占的，因此server端tcp連接4維數組中只有remote ip（也就是client ip）和remote port（客戶端port）是可變的，因此最大tcp連接為客戶端ip數×客戶端port數，對IPV4，不考慮ip地址分類等因素，最大tcp連接數約為2的32次方（ip數）×2的16次方（port數），也就是server端單機最大tcp連接數約為2的48次方。 簡單的說就是單機單IP在作為服務端對外提供服務時可以允許同時有2的48次方個連接(每個客戶端都用上所有端口來連接)
實際的tcp連接數 上面給出的是理論上的單機最大連接數，在實際環境中，受到機器資源、操作系統等的限制，特別是sever端，其最大並發tcp連接數遠不能達到理論上限。在unix/linux下限制連接數的主要因素是內存和允許的文件描述符個數（每個tcp連接都要占用一定內存，每個socket就是一個文件描述符），另外1024以下的端口通常為保留端口。 對server端，通過增加內存、修改最大文件描述符個數等參數，單機最大並發TCP連接數超過10萬 是沒問題的，國外 Urban Airship 公司在產品環境中已做到 50 萬並發 。在實際應用中，對大規模網絡應用，還需要考慮C10K 問題。
CONNTRACK_MAX的默認值 ------------------------------
在i386架構上，CONNTRACK_MAX = RAMSIZE (以bytes記) / 16384 = RAMSIZE (以MegaBytes記) * 64， 因此，一個32位的帶512M內存的PC在默認情況下能夠處理512*1024^2/16384 = 512*64 = 32768個並發的netfilter連接。
但是真正的公式是： CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32) 這里x是指針的bit數，（例如，32或者64bit）
請注意： －默認的CONNTRACK_MAX值不會低於128 －對於帶有超過1G內存的系統，CONNTRACK_MAX的默認值會被限制在65536（但是可以手工設置成更大的值）
HASHSIZE的默認值 -------------------------
通常，CONNTRACK_MAX = HASHSIZE * 8。這意味着每個鏈接的列表平均包含8個conntrack的條目（在優化的情況並且CONNTRACK_MAX達到的情況下），每個鏈接的列表就是一個哈西表條目（一個桶）。
在i386架構上，HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes記) / 131072 = RAMSIZE (以MegaBytes記) * 8。 舉例來說，一個32位、帶512M內存的PC可以存儲512*1024^2/128/1024 = 512*8 = 4096 個桶（鏈接表）
但是真正的公式是： HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes記) / 131072 / (x / 32) 這里x是指針的bit數，（例如，32或者64bit）
請注意： －默認HASHSIZE的值不會小於16 －對於帶有超過1G內存的系統，HASHSIZE的默認值會被限制在8192（但是可以手工設置成更大的值）
了解了以上情況,就很容易理解負載均衡器和並發連接的問題了,這里最關鍵的問題是要分清楚客戶端和服務端,因為客戶端受端口數限制連接數只有6萬多,而當它作為服務端時是受系統硬件配置限制(當然軟件配置也非常重要)
我們假設一種經典的模型：
Client Side Server Side 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+)，這時負載均衡器作為服務端,見"Server最大tcp連接數"段落.因為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 這里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的三次握手完全有負載均衡器接管，這樣，服務器端的連接就成倍的減少。
單機最大tcp連接數 http://wanshi.iteye.com/blog/1256282
一個IP能建立的最大連接數是多少 http://hi.baidu.com/hawk418/blog/item/8377b86e8fe7b3c081cb4a84.html
如何標識一個TCP連接 在確定最大連接數之前，先來看看系統如何標識一個tcp連接。系統用一個四維數組來唯一標識一個TCP連接：{local ip, local port,remote ip,remote port}。
client最大tcp連接數 client每次發起tcp連接請求時，除非綁定端口，通常會讓系統選取一個空閑的本地端口（local port），該端口是獨占的，不能和其他tcp連接共享。tcp端口的數據類型是unsigned short，因此本地端口個數最大只有65536，端口0是代表全部端口，不能使用，這樣可用端口最多只有65535，所以在作為client端的情況下，最大tcp連接數為65535，這些連接可以連到不同的server ip。 簡單的說就是單機單IP在作為客戶端時只允許同時連接65535個服務(每個服務一個連接的情況下)
server最大tcp連接數 server通常固定在某個本地端口上監聽，等待client的連接請求。不考慮地址重用（unix的SO_REUSEADDR選項）的情況下，即使server端有多個ip，本地監聽端口也是獨占的，因此server端tcp連接4維數組中只有remote ip（也就是client ip）和remote port（客戶端port）是可變的，因此最大tcp連接為客戶端ip數×客戶端port數，對IPV4，不考慮ip地址分類等因素，最大tcp連接數約為2的32次方（ip數）×2的16次方（port數），也就是server端單機最大tcp連接數約為2的48次方。 簡單的說就是單機單IP在作為服務端對外提供服務時可以允許同時有2的48次方個連接(每個客戶端都用上所有端口來連接)
實際的tcp連接數 上面給出的是理論上的單機最大連接數，在實際環境中，受到機器資源、操作系統等的限制，特別是sever端，其最大並發tcp連接數遠不能達到理論上限。在unix/linux下限制連接數的主要因素是內存和允許的文件描述符個數（每個tcp連接都要占用一定內存，每個socket就是一個文件描述符），另外1024以下的端口通常為保留端口。 對server端，通過增加內存、修改最大文件描述符個數等參數，單機最大並發TCP連接數超過10萬 是沒問題的，國外 Urban Airship 公司在產品環境中已做到 50 萬並發 。在實際應用中，對大規模網絡應用，還需要考慮C10K 問題。
CONNTRACK_MAX的默認值 ------------------------------
在i386架構上，CONNTRACK_MAX = RAMSIZE (以bytes記) / 16384 = RAMSIZE (以MegaBytes記) * 64， 因此，一個32位的帶512M內存的PC在默認情況下能夠處理512*1024^2/16384 = 512*64 = 32768個並發的netfilter連接。
但是真正的公式是： CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32) 這里x是指針的bit數，（例如，32或者64bit）
請注意： －默認的CONNTRACK_MAX值不會低於128 －對於帶有超過1G內存的系統，CONNTRACK_MAX的默認值會被限制在65536（但是可以手工設置成更大的值）
HASHSIZE的默認值 -------------------------
通常，CONNTRACK_MAX = HASHSIZE * 8。這意味着每個鏈接的列表平均包含8個conntrack的條目（在優化的情況並且CONNTRACK_MAX達到的情況下），每個鏈接的列表就是一個哈西表條目（一個桶）。
在i386架構上，HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes記) / 131072 = RAMSIZE (以MegaBytes記) * 8。 舉例來說，一個32位、帶512M內存的PC可以存儲512*1024^2/128/1024 = 512*8 = 4096 個桶（鏈接表）
但是真正的公式是： HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes記) / 131072 / (x / 32) 這里x是指針的bit數，（例如，32或者64bit）
請注意： －默認HASHSIZE的值不會小於16 －對於帶有超過1G內存的系統，HASHSIZE的默認值會被限制在8192（但是可以手工設置成更大的值）
了解了以上情況,就很容易理解負載均衡器和並發連接的問題了,這里最關鍵的問題是要分清楚客戶端和服務端,因為客戶端受端口數限制連接數只有6萬多,而當它作為服務端時是受系統硬件配置限制(當然軟件配置也非常重要)
我們假設一種經典的模型：
Client Side Server Side 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+)，這時負載均衡器作為服務端,見"Server最大tcp連接數"段落.因為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 這里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的三次握手完全有負載均衡器接管，這樣，服務器端的連接就成倍的減少。
單機最大tcp連接數 http://wanshi.iteye.com/blog/1256282
一個IP能建立的最大連接數是多少 http://hi.baidu.com/hawk418/blog/item/8377b86e8fe7b3c081cb4a84.html