在做Socket 編程時，我們經常會要問，單機最多可以建立多少個 TCP 連接，本文將介紹如何調整系統參數來調整單機的最大TCP連接數。
Windows 下單機的TCP連接數有多個參數共同決定，下面一一介紹：
最大TCP連接數
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
TcpNumConnections = 0x00fffffe (Default = 16,777,214)
以上注冊表信息配置單機的最大允許的TCP連接數，默認為 16M。這個數值看似很大，這個並不是限制最大連接數的唯一條件，還有其他條件會限制到TCP 連接的最大連接數。
最大動態端口數
TCP客戶端和服務器連接時，客戶端必須分配一個動態端口，默認情況下這個動態端口的分配范圍為 1024-5000 ，也就是說默認情況下，客戶端最多可以同時發起3977 個Socket 連接。我們可以修改如下注冊表來調整這個動態端口的范圍
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
MaxUserPort = 5000 (Default = 5000, Max = 65534)
最大TCB 數量
系統為每個TCP 連接分配一個TCP 控制塊(TCP control block or TCB)，這個控制塊用於緩存TCP連接的一些參數，每個TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool，也就說，每個TCP連接會占用 1KB 的系統內存。
系統的最大TCB數量由如下注冊表設置決定
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]
MaxFreeTcbs = 2000 (Default = RAM dependent, but usual Pro = 1000, Srv=2000)
非Server版本，MaxFreeTcbs 的默認值為1000 （64M 以上物理內存）
Server 版本，這個的默認值為 2000。
也就是說，默認情況下，Server 版本最多同時可以建立並保持2000個TCP 連接。
最大TCB Hash table 數量
TCB 是通過Hash table 來管理的，下面注冊表設置決定了這個Hash table 的大小
HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters]
MaxHashTableSize = 512 (Default = 512, Range = 64-65536)
這個值指明分配 pagepool 內存的數量，也就是說，如果MaxFreeTcbs = 1000 , 則 pagepool 的內存數量為 500KB
那么 MaxHashTableSize 應大於 500 才行。這個數量越大，則Hash table 的冗余度就越高，每次分配和查找 TCP 連接用時就越少。這個值必須是2的冪，且最大為65536.
IBM WebSphere Voice Server 在windows server 2003 下的典型配置
這是IBM WebSphere Voice Server 的典型配置，大家可以做個參考。原文參見
IBM Web Sphere Voice Server 配置
- MaxUserPort = 65534 (Decimal)
- MaxHashTableSize = 65536 (Decimal)
- MaxFreeTcbs = 16000 (Decimal)
這里我們可以看到 MaxHashTableSize 被配置為比MaxFreeTcbs 大4倍，這樣可以大大增加TCP建立的速度。
一。什么是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過“四次握手”（過程就不細寫了，就是服務器和客戶端交互，最終確定斷開）
二。利用Socket建立網絡連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket，另一個運行於服務器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：服務器監聽，客戶端請求，連接確認。
1。服務器監聽：服務器端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網絡狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和端口號，然后就向服務器端套接字提出連接請求。
3。連接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式建立連接。而服務器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol)，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。
四。TCP和UDP的區別（考得最多。。快被考爛了我覺得- -\\）
1。TCP是面向鏈接的，雖然說網絡的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知道了TCP和UDP的區別，就不難理解為何采用TCP傳輸協議的MSN比采用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然后由接收方進行驗證啊什么的，即使是這樣，UDP因為在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。