目錄
1、TCP連接的狀態詳解以及故障排查 要看全文源地址
2、tcp連接占滿，修改tcp連接數
3、重要的：阿里雲 Linux TCP隊列相關參數的總結
TCP連接的狀態詳解以及故障排查
WEB產品的性能測試，有很多tcp連接方面的問題，也因為這方面的問題，導致性能出現不穩定等情況，客戶端和服務器之間數據傳輸，以及之間連接狀態的轉變，哪些狀態是正常的狀態，哪些狀態是異常的狀態，怎樣去定位這些問題，以及常用的工具，今天針對這些問題簡單的總結了一下；
1、TCP狀態獲取
1）netstat -nat 查看TCP各個狀態的數量
2）lsof -i:port 可以檢測到打開套接字的狀況
3) sar -n SOCK 查看tcp創建的連接數
4) tcpdump -iany tcp port 9000 對tcp端口為9000的進行抓包
2、TCP狀態遷移路線圖
http://dl.iteye.com/upload/attachment/0077/6056/bdf8d214-c8de-3b2a-8a53-219a0dce3259.png
http://dl.iteye.com/upload/attachment/0077/6058/5d4e8c89-fc42-3862-bdb8-399bc982f410.png
CLOSED：沒有任何連接狀態；
LISTENING：偵聽來自遠方的TCP端口的連接請求；
首先服務端需要打開一個socket進行監聽，狀態為LISTEN。
有提供某種服務才會處於LISTENING狀態，TCP狀態變化就是某個端口的狀態變化，提供一個服務就打開一個端口，例如：提供www服務默認開的是80端口，提供ftp服務默認的端口為21，當提供的服務沒有被連接時就處於LISTENING狀態。FTP服務啟動后首先處於偵聽（LISTENING）狀態。處於偵聽LISTENING狀態時，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經敞開的，但還沒有人進來。
看LISTENING狀態最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關閉不必要的端口是保證安全的一個非常重要的方面，服務端口都對應一個服務（應用程序），停止該服務就關閉了該端口，例如要關閉21端口只要停止IIS服務中的FTP服務即可。
如果你不幸中了服務端口的木馬，木馬也開個端口處於LISTENING狀態。
SYN-SENT：客戶端SYN_SENT狀態：
再發送連接請求后等待匹配的連接請求:客戶端通過應用程序調用connect進行active open.於是客戶端tcp發送一個SYN以請求建立一個連接.之后狀態置為SYN_SENT. 在發送連接請求后等待匹配的連接請求
當請求連接時客戶端首先要發送同步信號給要訪問的機器，此時狀態為SYN_SENT，如果連接成功了就變為ESTABLISHED，正常情況下SYN_SENT狀態非常短暫。例如要訪問網站http://www.baidu.com,如果是正常連接的話，用TCPView觀察IE建立的連接會發現很快從SYN_SENT變為ESTABLISHED，表示連接成功。SYN_SENT狀態快的也許看不到。
如果發現有很多SYN_SENT出現，那一般有這么幾種情況，一是你要訪問的網站不存在或線路不好，二是用掃描軟件掃描一個網段的機器，也會出出現很多SYN_SENT，另外就是可能中了病毒了，例如中了"沖擊波"，病毒發作時會掃描其它機器，這樣會有很多SYN_SENT出現。
SYN-RECEIVED：服務器端狀態SYN_RCVD
再收到和發送一個連接請求后等待對方對連接請求的確認
當服務器收到客戶端發送的同步信號時，將標志位ACK和SYN置1發送給客戶端，此時服務器端處於SYN_RCVD狀態，如果連接成功了就變為ESTABLISHED，正常情況下SYN_RCVD狀態非常短暫。
如果發現有很多SYN_RCVD狀態，那你的機器有可能被SYN Flood的DoS(拒絕服務攻擊)攻擊了。
ESTABLISHED：代表一個打開的連接。
ESTABLISHED狀態是表示兩台機器正在傳輸數據，觀察這個狀態最主要的就是看哪個程序正在處於ESTABLISHED狀態。
服務器出現很多ESTABLISHED狀態： netstat -nat |grep 9502或者使用lsof -i:9502可以檢測到。
當客戶端未主動close的時候就斷開連接：即客戶端發送的FIN丟失或未發送。
這時候若客戶端斷開的時候發送了FIN包，則服務端將會處於CLOSE_WAIT狀態；
這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態；
結果客戶端重新連接服務器。
而新連接上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED; 如果客戶端重復的上演這種情況，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。
最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，並顯示ESTABLISHED，但始終無法進入程序代碼
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
主動關閉(active close)端應用程序調用close，於是其TCP發出FIN請求主動關閉連接，之后進入FIN_WAIT1狀態./* The socket is closed, and the connection is shutting down. 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認 */
如果服務器出現shutdown再重啟，使用netstat -nat查看，就會看到很多FIN-WAIT-1的狀態。就是因為服務器當前有很多客戶端連接，直接關閉服務器后，無法接收到客戶端的ACK。
FIN-WAIT-2：從遠程TCP等待連接中斷請求
主動關閉端接到ACK后，就進入了FIN-WAIT-2，從遠程TCP等待連接中斷請求
這就是著名的半關閉的狀態了，這是在關閉連接時，客戶端和服務器兩次握手之后的狀態。在這個狀態下，應用程序還有接受數據的能力，但是已經無法發送數據，但是也有一種可能是，客戶端一直處於FIN_WAIT_2狀態，而服務器則一直處於WAIT_CLOSE狀態，而直到應用層來決定關閉這個狀態。
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
被動關閉(passive close)端TCP接到FIN后，就發出ACK以回應FIN請求(它的接收也作為文件結束符傳遞給上層應用程序),並進入CLOSE_WAIT.等待從本地用戶發來的連接中斷請求
CLOSING：等待遠程TCP對連接中斷的確認
等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認
被動關閉端一段時間后，接收到文件結束符的應用程序將調用CLOSE關閉連接。這導致它的TCP也發送一個 FIN,等待對方的ACK.就進入了LAST-ACK 等待原來發向遠程TCP的連接中斷請求的確認
使用並發壓力測試的時候，突然斷開壓力測試客戶端，服務器會看到很多LAST-ACK。
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
在主動關閉端接收到FIN后，TCP就發送ACK包，並進入TIME-WAIT狀態，等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認 */
TIME_WAIT等待狀態，這個狀態又叫做2MSL狀態，說的是在TIME_WAIT2發送了最后一個ACK數據報以后，要進入TIME_WAIT狀態，這個狀態是防止最后一次握手的數據報沒有傳送到對方那里而准備的（注意這不是四次握手，這是第四次握手的保險狀態）。這個狀態在很大程度上保證了雙方都可以正常結束，但是，問題也來了。由於插口的2MSL狀態（插口是IP和端口對的意思，socket），使得應用程序在2MSL時間內是無法再次使用同一個插口的，對於客戶程序還好一些，但是對於服務程序，例如httpd，它總是要使用同一個端口來進行服務，而在2MSL時間內，啟動httpd就會出現錯誤（插口被使用）。為了避免這個錯誤，服務器給出了一個平靜時間的概念，這是說在2MSL時間內，雖然可以重新啟動服務器，但是這個服務器還是要平靜的等待2MSL時間的過去才能進行下一次連接。
TCP的狀態遷移圖看似復雜，但是仔細觀察，是有兩條線路的：客戶端應用程序的狀態遷移圖、服務器的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以后，客戶端就打開了數據交互地連接。而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以后，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。
服務器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連接的時候，服務器端是在第三次握手之后才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以后（注意不是第四次）。而關閉以后還要等待客戶端給出最后的ACK包才能進入初始的狀態。
其他狀態遷移
還有一些其他的狀態遷移，這些狀態遷移針對服務器和客戶端兩方面的總結如下
LISTEN->SYN_SENT，對於這個解釋就很簡單了，服務器有時候也要打開連接的嘛。
SYN_SENT->SYN收到，服務器和客戶端在SYN_SENT狀態下如果收到SYN數據報，則都需要發送SYN的ACK數據報並把自己的狀態調整到SYN收到狀態，准備進入ESTABLISHED
SYN_SENT->CLOSED，在發送超時的情況下，會返回到CLOSED狀態。
SYN_收到->LISTEN，如果受到RST包，會返回到LISTEN狀態。
SYN_收到->FIN_WAIT_1，這個遷移是說，可以不用到ESTABLISHED狀態，而可以直接跳轉到FIN_WAIT_1狀態並等待關閉。
3、TCP連接建立三次握手
http://my.csdn.net/uploads/201204/10/1334045728_5744.png
Client連接Server：
當Client端調用socket函數調用時，相當於Client端產生了一個處於Closed狀態的套接字。
1）第一次握手：Client端又調用connect函數調用，系統為Client隨機分配一個端口，連同傳入connect中的參數(Server的IP和端口)，這就形成了一個連接四元組，客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。connect調用讓Client端的socket處於SYN_SENT狀態，等待服務器確認；SYN：同步序列編號(Synchronize Sequence Numbers)。
2)第二次握手： 服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
3)第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶器和客務器進入ESTABLISHED狀態，完成三次握手。連接已經可以進行讀寫操作。
一個完整的三次握手也就是： 請求---應答---再次確認。
TCP協議通過三個報文段完成連接的建立，這個過程稱為三次握手(three-way handshake)，過程如下圖所示。
對應的函數接口：
Server：
當Server端調用socket函數調用時，相當於Server端產生了一個處於Closed狀態的監聽套接字
Server端調用bind操作，將監聽套接字與指定的地址和端口關聯，然后又調用listen函數，系統會為其分配未完成隊列和完成隊列，此時的監聽套接字可以接受Client的連接，監聽套接字狀態處於LISTEN狀態。
當Server端調用accept操作時，會從完成隊列中取出一個已經完成的client連接，同時在server這段會產生一個會話套接字，用於和client端套接字的通信，這個會話套接字的狀態是ESTABLISH。
從圖中可以看出，當客戶端調用connect時，觸發了連接請求，向服務器發送了SYN J包，這時connect進入阻塞狀態；服務器監聽到連接請求，即收到SYN J包，調用accept函數接收請求向客戶端發送SYN K ，ACK J+1，這時accept進入阻塞狀態；客戶端收到服務器的SYN K ，ACK J+1之后，這時connect返回，並對SYN K進行確認；服務器收到ACK K+1時，accept返回，至此三次握手完畢，連接建立。
我們可以通過網絡抓包的查看具體的流程：
比如我們服務器開啟9502的端口。使用tcpdump來抓包：
tcpdump -iany tcp port 9502
然后我們使用telnet 127.0.0.1 9502開連接.:
telnet 127.0.0.1 9502
14:12:45.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378, win 32792, options [mss 16396,sackOK,TS val 255474104 ecr 0,nop,wscale 3], length 0（1）
14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379, win 32768, options [mss 16396,sackOK,TS val 255474104 ecr 255474104,nop,wscale 3], length 0 （2）
14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1, win 4099, options [nop,nop,TS val 255474104 ecr 255474104], length 0 （3）
14:13:01.415407 IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7
14:13:01.415432 IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0
14:13:01.415747 IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18
14:13:01.415757 IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0
我們看到 （1）（2）（3）三步是建立tcp：
第一次握手：
14:12:45.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378
客戶端IP localhost.39870 (客戶端的端口一般是自動分配的) 向服務器localhost.9502 發送syn包(syn=j)到服務器》
syn的seq= 2927179378
第二次握手：
14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379,
服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包
SYN（ack=j+1）=ack 2927179379 服務器主機SYN包（syn=seq 1721825043）
第三次握手：
14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,
客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)
客戶端和服務器進入ESTABLISHED狀態后，可以進行通信數據交互。此時和accept接口沒有關系，即使沒有accepte，也進行3次握手完成。
連接出現連接不上的問題，一般是網路出現問題或者網卡超負荷或者是連接數已經滿啦。
紫色背景的部分：
IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7
客戶端向服務器發送長度為7個字節的數據，
IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0
服務器向客戶確認已經收到數據
IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18
然后服務器同時向客戶端寫入數據。
IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0
客戶端向服務器確認已經收到數據
這個就是tcp可靠的連接，每次通信都需要對方來確認。
4、TCP連接終止（四次握手）
http://my.csdn.net/uploads/201204/10/1334046363_4881.jpg
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉(half-close)造成的，如圖：
（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。
（2）服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。
（4）客戶端A發回ACK報文確認，並將確認序號設置為收到序號加1（報文段7）。
調用過程如下：
-
1) 當client想要關閉它與server之間的連接。client（某個應用進程）首先調用close主動關閉連接，這時TCP發送一個FIN M；client端處於FIN_WAIT1狀態。
-
2) 當server端接收到FIN M之后，執行被動關閉。對這個FIN進行確認，返回給client ACK。當server端返回給client ACK后，client處於FIN_WAIT2狀態，server處於CLOSE_WAIT狀態。它的接收也作為文件結束符傳遞給應用進程，因為FIN的接收 意味着應用進程在相應的連接上再也接收不到額外數據；
-
3) 一段時間之后，當server端檢測到client端的關閉操作(read返回為0)。接收到文件結束符的server端調用close關閉它的socket。這導致server端的TCP也發送一個FIN N；此時server的狀態為LAST_ACK。
-
4) 當client收到來自server的FIN后 。 client端的套接字處於TIME_WAIT狀態，它會向server端再發送一個ack確認，此時server端收到ack確認后，此套接字處於CLOSED狀態。
tcp連接占滿，修改tcp連接數
修改上述限制的最簡單的辦法就是使用ulimit命令：
[speng@as4 ~]$ ulimit -n
上述命令中，在中指定要設置的單一進程允許打開的最大文件數。如果系統回顯類似於“Operationnotpermitted”之類的話，說明上述限制修改失敗，實際上是因為在中指定的數值超過了Linux系統對該用戶打開文件數的軟限制或硬限制。因此，就需要修改Linux系統對用戶的關於打開文件數的軟限制和硬限制。
第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪個用戶的打開文件數限制，可用’*'號表示修改所有用戶的限制；soft或hard指定要修改軟限制還是硬限制；10240則指定了想要修改的新的限制值，即最大打開文件數(請注意軟限制值要小於或等於硬限制)。修改完后保存文件。
第二步，修改/etc/pam.d/login文件，在文件中添加如下行：
session required /lib/security/pam_limits.so
這是告訴Linux在用戶完成系統登錄后，應該調用pam_limits.so模塊來設置系統對該用戶可使用的各種資源數量的最大限制(包括用戶可打開的最大文件數限制)，而pam_limits.so模塊就會從/etc/security/limits.conf文件中讀取配置來設置這些限制值。修改完后保存此文件。
第三步，查看Linux系統級的最大打開文件數限制，使用如下命令：
[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158
這表明這台Linux系統最多允許同時打開(即包含所有用戶打開文件數總和)12158個文件，是Linux系統級硬限制，所有用戶級的打開文件數限制都不應超過這個數值。通常這個系統級硬限制是Linux系統在啟動時根據系統硬件資源狀況計算出來的最佳的最大同時打開文件數限制，如果沒有特殊需要，不應該修改此限制，除非想為用戶級打開文件數限制設置超過此限制的值。修改此硬限制的方法是修改/etc/rc.local腳本，在腳本中添加如下行：
echo 22158 > /proc/sys/fs/file-max
這是讓Linux在啟動完成后強行將系統級打開文件數硬限制設置為22158。修改完后保存此文件。
完成上述步驟后重啟系統，一般情況下就可以將Linux系統對指定用戶的單一進程允許同時打開的最大文件數限制設為指定的數值。如果重啟后用ulimit-n命令查看用戶可打開文件數限制仍然低於上述步驟中設置的最大值，這可能是因為在用戶登錄腳本/etc/profile中使用ulimit-n命令已經將用戶可同時打開的文件數做了限制。由於通過ulimit-n修改系統對用戶可同時打開文件的最大數限制時，新修改的值只能小於或等於上次ulimit-n設置的值，因此想用此命令增大這個限制值是不可能的。所以，如果有上述問題存在，就只能去打開/etc/profile腳本文件，在文件中查找是否使用了ulimit-n限制了用戶可同時打開的最大文件數量，如果找到，則刪除這行命令，或者將其設置的值改為合適的值，然后保存文件，用戶退出並重新登錄系統即可。
通過上述步驟，就為支持高並發TCP連接處理的通訊處理程序解除關於打開文件數量方面的系統限制。
2、修改網絡內核對TCP連接的有關限制（參考對比下篇文章“優化內核參數”）
在Linux上編寫支持高並發TCP連接的客戶端通訊處理程序時，有時會發現盡管已經解除了系統對用戶同時打開文件數的限制，但仍會出現並發TCP連接數增加到一定數量時，再也無法成功建立新的TCP連接的現象。出現這種現在的原因有多種。
第一種原因可能是因為Linux網絡內核對本地端口號范圍有限制。此時，進一步分析為什么無法建立TCP連接，會發現問題出在connect()調用返回失敗，查看系統錯誤提示消息是“Can’tassignrequestedaddress”。同時，如果在此時用tcpdump工具監視網絡，會發現根本沒有TCP連接時客戶端發SYN包的網絡流量。這些情況說明問題在於本地Linux系統內核中有限制。其實，問題的根本原因在於Linux內核的TCP/IP協議實現模塊對系統中所有的客戶端TCP連接對應的本地端口號的范圍進行了限制(例如，內核限制本地端口號的范圍為1024~32768之間)。當系統中某一時刻同時存在太多的TCP客戶端連接時，由於每個TCP客戶端連接都要占用一個唯一的本地端口號(此端口號在系統的本地端口號范圍限制中)，如果現有的TCP客戶端連接已將所有的本地端口號占滿，則此時就無法為新的TCP客戶端連接分配一個本地端口號了，因此系統會在這種情況下在connect()調用中返回失敗，並將錯誤提示消息設為“Can’tassignrequestedaddress”。有關這些控制邏輯可以查看Linux內核源代碼，以linux2.6內核為例，可以查看tcp_ipv4.c文件中如下函數：
static int tcp_v4_hash_connect(struct sock *sk)
請注意上述函數中對變量sysctl_local_port_range的訪問控制。變量sysctl_local_port_range的初始化則是在tcp.c文件中的如下函數中設置：
void __init tcp_init(void)
內核編譯時默認設置的本地端口號范圍可能太小，因此需要修改此本地端口范圍限制。
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_local_port_range = 1024 65000
這表明將系統對本地端口范圍限制設置為1024~65000之間。請注意，本地端口范圍的最小值必須大於或等於1024；而端口范圍的最大值則應小於或等於65535。修改完后保存此文件。
第二步，執行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系統沒有錯誤提示，就表明新的本地端口范圍設置成功。如果按上述端口范圍進行設置，則理論上單獨一個進程最多可以同時建立60000多個TCP客戶端連接。
第二種無法建立TCP連接的原因可能是因為Linux網絡內核的IP_TABLE防火牆對最大跟蹤的TCP連接數有限制。此時程序會表現為在connect()調用中阻塞，如同死機，如果用tcpdump工具監視網絡，也會發現根本沒有TCP連接時客戶端發SYN包的網絡流量。由於IP_TABLE防火牆在內核中會對每個TCP連接的狀態進行跟蹤，跟蹤信息將會放在位於內核內存中的conntrackdatabase中，這個數據庫的大小有限，當系統中存在過多的TCP連接時，數據庫容量不足，IP_TABLE無法為新的TCP連接建立跟蹤信息，於是表現為在connect()調用中阻塞。此時就必須修改內核對最大跟蹤的TCP連接數的限制，方法同修改內核對本地端口號范圍的限制是類似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_conntrack_max = 10240
這表明將系統對最大跟蹤的TCP連接數限制設置為10240。請注意，此限制值要盡量小，以節省對內核內存的占用。
第二步，執行sysctl命令：
[speng@as4 ~]$ sysctl -p
如果系統沒有錯誤提示，就表明系統對新的最大跟蹤的TCP連接數限制修改成功。如果按上述參數進行設置，則理論上單獨一個進程最多可以同時建立10000多個TCP客戶端連接。
3、使用支持高並發網絡I/O的編程技術
在Linux上編寫高並發TCP連接應用程序時，必須使用合適的網絡I/O技術和I/O事件分派機制。
可用的I/O技術有同步I/O，非阻塞式同步I/O(也稱反應式I/O)，以及異步I/O。在高TCP並發的情形下，如果使用同步I/O，這會嚴重阻塞程序的運轉，除非為每個TCP連接的I/O創建一個線程。但是，過多的線程又會因系統對線程的調度造成巨大開銷。因此，在高TCP並發的情形下使用同步I/O是不可取的，這時可以考慮使用非阻塞式同步I/O或異步I/O。非阻塞式同步I/O的技術包括使用select()，poll()，epoll等機制。異步I/O的技術就是使用AIO。
從I/O事件分派機制來看，使用select()是不合適的，因為它所支持的並發連接數有限(通常在1024個以內)。如果考慮性能，poll()也是不合適的，盡管它可以支持的較高的TCP並發數，但是由於其采用“輪詢”機制，當並發數較高時，其運行效率相當低，並可能存在I/O事件分派不均，導致部分TCP連接上的I/O出現“飢餓”現象。而如果使用epoll或AIO，則沒有上述問題(早期Linux內核的AIO技術實現是通過在內核中為每個I/O請求創建一個線程來實現的，這種實現機制在高並發TCP連接的情形下使用其實也有嚴重的性能問題。但在最新的Linux內核中，AIO的實現已經得到改進)。
綜上所述，在開發支持高並發TCP連接的Linux應用程序時，應盡量使用epoll或AIO技術來實現並發的TCP連接上的I/O控制，這將為提升程序對高並發TCP連接的支持提供有效的I/O保證。
內核參數sysctl.conf的優化
/etc/sysctl.conf是用來控制linux網絡的配置文件，對於依賴網絡的程序（如web服務器和cache服務器）非常重要，RHEL默認提供的最好調整。
推薦配置（把原/etc/sysctl.conf內容清掉，把下面內容復制進去）：
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
這個配置參考於cache服務器varnish的推薦配置和SunOne服務器系統優化的推薦配置。
varnish調優推薦配置的地址為：http://varnish.projects.linpro.no/wiki/Performance
不過varnish推薦的配置是有問題的，實際運行表明“net.ipv4.tcp_fin_timeout=3”的配置會導致頁面經常打不開；並且當網友使用的是IE6瀏覽器時，訪問網站一段時間后，所有網頁都會打不開，重啟瀏覽器后正常。可能是國外的網速快吧，我們國情決定需要調整“net.ipv4.tcp_fin_timeout= 10”，在10s的情況下，一切正常（實際運行結論）。
修改完畢后，執行：
/sbin/sysctl -p /etc/sysctl.conf
/sbin/sysctl -w net.ipv4.route.flush=1
命令生效。為了保險起見，也可以reboot系統。
調整文件數：
linux系統優化完網絡必須調高系統允許打開的文件數才能支持大的並發，默認1024是遠遠不夠的。
執行命令：
Shell代碼
echo ulimit -HSn 65536 >> /etc/rc.local
echo ulimit -HSn 65536 >>/root/.bash_profile
ulimit -HSn 65536