我們通過了解 TCP各個狀態 ，可以排除和定位網絡或系統故障時大有幫助。

一、TCP狀態

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. /*The socket is actively attempting to establish a connection. 在發送連接請求后等待匹配的連接請求 */

當請求連接時客戶端首先要發送同步信號給要訪問的機器，此時狀態為SYN_SENT，如果連接成功了就變為ESTABLISHED，正常情況下SYN_SENT狀態非常短暫。例如要訪問網站http://www.baidu.com,如果是正常連接的話，用TCPView觀察 IEXPLORE .EXE(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(拒絕服務攻擊)攻擊了。

● SYN Flood的攻擊原理是：

在進行三次握手時，攻擊軟件向被攻擊的服務器發送SYN連接請求(握手的第一步)，但是這個地址是偽造的，如攻擊軟件隨機偽造了51.133.163.104、65.158.99.152等等地址。 服務器 在收到連接請求時將標志位 ACK和 SYN 置1發送給客戶端(握手的第二步)，但是這些客戶端的IP地址都是偽造的，服務器根本找不到客戶機，也就是說握手的第三步不可能完成。

這種情況下服務器端一般會重試(再次發送SYN+ACK給客戶端)并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級(大約為30秒-2分鐘);一個用戶出現異常導致服務器的一個線程等待1分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接，即使是簡單的保存并遍歷也會消耗非常多的 CPU 時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。此時從正?？蛻舻慕嵌瓤磥?，服務器失去響應，這種情況我們稱做： 服務器端受到了SYN Flood攻擊(SYN洪水攻擊 )

● 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的連接中斷請求，或先前的連接中斷請求的確認 */

● FIN-WAIT-2：從遠程TCP等待連接中斷請求

主動關閉端接到ACK后，就進入了FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 從遠程TCP等待連接中斷請求 */

這就是著名的半關閉的狀態了，這是在關閉連接時，客戶端和服務器兩次握手之后的狀態。在這個狀態下，應用程序還有接受數據的能力，但是已經無法發送數據，但是也有一種可能是，客戶端一直處于FIN_WAIT_2狀態，而服務器則一直處于WAIT_CLOSE狀態，而直到應用層來決定關閉這個狀態。

● CLOSE-WAIT：等待從本地用戶發來的連接中斷請求

被動關閉(passive close)端TCP接到FIN后，就發出ACK以回應FIN請求(它的接收也作為文件結束符傳遞給上層應用程序),并進入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待從本地用戶發來的連接中斷請求 */

● CLOSING：等待遠程TCP對連接中斷的確認

比較少見./* Both sockets are shut down but we still don't have all our data sent. 等待遠程TCP對連接中斷的確認 */

● LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認

被動關閉端一段時間后，接收到文件結束符的應用程序將調用CLOSE關閉連接。這導致它的TCP也發送一個 FIN,等待對方的ACK.就進入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原來發向遠程TCP的連接中斷請求的確認 */

● TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認

在主動關閉端接收到FIN后，TCP就發送ACK包，并進入TIME-WAIT狀態。/* The socket is waiting after close to handle packets still in the network.等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認 */

TIME_WAIT等待狀態，這個狀態又叫做2MSL狀態，說的是在TIME_WAIT2發送了最后一個ACK數據報以后，要進入TIME_WAIT狀態，這個狀態是防止最后一次握手的數據報沒有傳送到對方那里而準備的(注意這不是四次握手，這是第四次握手的保險狀態)。這個狀態在很大程度上保證了雙方都可以正常結束，但是，問題也來了。

由于插口的2MSL狀態(插口是IP和端口對的意思，socket)，使得應用程序在2MSL時間內是無法再次使用同一個插口的，對于客戶程序還好一些，但是對于服務程序，例如httpd，它總是要使用同一個端口來進行服務，而在2MSL時間內，啟動httpd就會出現錯誤(插口被使用)。為了避免這個錯誤，服務器給出了一個平靜時間的概念，這是說在2MSL時間內，雖然可以重新啟動服務器，但是這個服務器還是要平靜的等待2MSL時間的過去才能進行下一次連接。

● CLOSED：沒有任何連接狀態

被動關閉端在接受到ACK包后，就進入了closed的狀態。連接結束./* The socket is not being used. 沒有任何連接狀態 */#p#

二、TCP狀態遷移路線圖

client/server兩條路線講述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狀態并等待關閉。

 

 

怎樣牢牢地將這張圖刻在腦中呢?那么你就一定要對這張圖的每一個狀態，及轉換的過程有深刻的認識，不能只停留在一知半解之中。下面對這張圖的11種狀態詳細解析一下，以便加強記憶!不過在這之前，先回顧一下TCP建立連接的三次握手過程，以及關閉連接的四次握手過程。

三、TCP連接建立三次握手

TCP是一個面向連接的協議，所以在連接雙方發送數據之前，都需要首先建立一條連接。

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)，過程如下圖所示。

對應的函數接口：

 

#p#

 

2)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可靠的連接，每次通信都需要對方來確認。

#p#四、TCP連接的終止(四次握手釋放)

由于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狀態。

這樣每個方向上都有一個FIN和ACK。

1 .為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢?

這是因為服務端的 LISTEN 狀態下的 SOCKET 當收到 SYN 報文的建連請求后，它可以把 ACK和 SYN ( ACK 起應答作用，而 SYN 起同步作用)放在一個報文里來發送。但關閉連接時，當收到對方的 FIN 報文通知時，它僅僅表示對方沒有數據發送給你了;但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉 SOCKET, 也即你可能還需要發送一些數據給對方之后，再發送 FIN 報文給對方來表示你同意現在可以關閉連接了，所以它這里的 ACK 報文和 FIN 報文多數情況下都是分開發送的。

2 .為什么 TIME_WAIT 狀態還需要等 2MSL 后才能返回到 CLOSED 狀態?

這是因為雖然雙方都同意關閉連接了，而且握手的 4 個報文也都協調和發送完畢，按理可以直接回到 CLOSED 狀態(就好比從 SYN_SEND 狀態到 ESTABLISH狀態那樣)：

一方面是可靠的實現TCP全雙工連接的終止，也就是當最后的ACK丟失后，被動關閉端會重發FIN，因此主動關閉端需要維持狀態信息，以允許它重新發送最終的ACK。

另一方面，但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK 報文會一定被對方收到，因此對方處于 LAST_ACK 狀態下的 SOCKET 可能會因為超時未收到 ACK 報文，而重發 FIN 報文，所以這個 TIME_WAIT 狀態的作用就是用來重發可能丟失的 ACK 報文。

TCP在2MSL等待期間，定義這個連接(4元組)不能再使用，任何遲到的報文都會丟棄。設想如果沒有2MSL的限制，恰好新到的連接正好滿足原先的4元組，這時候連接就可能接收到網絡上的延遲報文就可能干擾最新建立的連接。

五、同時打開

兩個應用程序同時執行主動打開的情況是可能的，雖然發生的可能性較低。每一端都發送一個SYN,并傳遞給對方，且每一端都使用對端所知的端口作為本地端口。例如：

主機a中一應用程序使用7777作為本地端口，并連接到主機b 8888端口做主動打開。

主機b中一應用程序使用8888作為本地端口，并連接到主機a 7777端口做主動打開。

tcp協議在遇到這種情況時，只會打開一條連接。

這個連接的建立過程需要4次數據交換，而一個典型的連接建立只需要3次交換(即3次握手)

但多數伯克利版的tcp/ip實現并不支持同時打開。

 

 

六、同時關閉

如果應用程序同時發送FIN，則在發送后會首先進入FIN_WAIT_1狀態。在收到對端的FIN后，回復一個ACK，會進入CLOSING狀態。在收到對端的ACK后，進入TIME_WAIT狀態。這種情況稱為同時關閉。

同時關閉也需要有4次報文交換，與典型的關閉相同。

 

 

#p#七. TCP通信中服務器處理客戶端意外斷開

如果TCP連接被對方正常關閉，也就是說，對方是正確地調用了closesocket(s)或者shutdown(s)的話，那么上面的Recv或Send調用就能馬上返回，并且報錯。這是由于close socket(s)或者shutdown(s)有個正常的關閉過程，會告訴對方“TCP連接已經關閉，你不需要再發送或者接受消息了”。

但是，如果意外斷開，客戶端(3g的移動設備)并沒有正常關閉socket。雙方并未按照協議上的四次揮手去斷開連接。

那么這時候正在執行Recv或Send操作的一方就會因為沒有任何連接中斷的通知而一直等待下去，也就是會被長時間卡住。

像這種如果一方已經關閉或異常終止連接，而另一方卻不知道，我們將這樣的TCP連接稱為半打開 的。

解決意外中斷辦法都是利用?；顧C制。而?；顧C制分又可以讓底層實現也可自己實現。

1、 自己編寫心跳包程序

簡單的說也就是在自己的程序中加入一條線程，定時向對端發送數據包，查看是否有ACK，如果有則連接正常，沒有的話則連接斷開

2、 啟動TCP編程里的keepAlive機制

一）雙方擬定心跳(自實現)

一般由客戶端發送心跳包，服務端并不回應心跳，只是定時輪詢判斷一下與上次的時間間隔是否超時(超時時間自己設定)。服務器并不主動發送是不想增添服務器的通信量，減少壓力。

但這會出現三種情況：

情況1.

客戶端由于某種網絡延遲等原因很久后才發送心跳(它并沒有斷)，這時服務器若利用自身設定的超時判斷其已經斷開，而后去關閉socket。若客戶端有重連機制，則客戶端會重新連接。若不確定這種方式是否關閉了原本正常的客戶端，則在ShutDown的時候一定要選擇send,表示關閉發送通道，服務器還可以接收一下，萬一客戶端正在發送比較重要的數據呢，是不?

情況2.

客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端已經判斷出其超時，并主動close，則四次揮手成功交互。

情況3.

客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端的輪詢還未判斷出其超時，在未主動close的時候該客戶端已經重新連接。

這時候若客戶端斷開的時候發送了FIN包，則服務端將會處于CLOSE_WAIT狀態;

這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態;

而新連接上來的客戶端(也就是剛才斷掉的重新連上來了)在服務端肯定是ESTABLISHED;這時候就有個問題，若利用輪詢還未檢測出上條舊連接已經超時(這很正常，timer總有個間隔吧)，而在這時，客戶端又重復的上演情況3，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。

最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，并顯示ESTABLISHED，但始終無法進入程序代碼。個人最初感覺導致這種情況是因為假的ESTABLISHED連接和 CLOSE_WAIT連接會占用較大的系統資源，程序無法再次創建連接(因為每次我發現這個問題的時候我只連了10個左右客戶端卻已經有40多條無效連接)。而最近幾天測試卻發現有一次程序內只連接了2，3個設備，但是有8條左右的虛連接，此時已經連接不了新客戶端了。這時候我就覺得我想錯了，不可能這幾條連接就占用了大量連接把，如果說幾十條還有可能。但是能肯定的是，這個問題的產生絕對是設備在不停的重啟，而服務器這邊又是簡單的輪詢，并不能及時處理，暫時還未能解決。

二）利用KeepAlive

其實keepalive的原理就是TCP內嵌的一個心跳包,

以服務器端為例，如果當前 server 端檢測到超過一定時間(默認是 7,200,000 milliseconds ，也就是 2 個小時)沒有數據傳輸，那么會向 client 端發送一個 keep-alive packet (該 keep-alive packet 就是 ACK和 當前 TCP 序列號減一的組合)，此時 client 端應該為以下三種情況之一：

1. client 端仍然存在，網絡連接狀況良好。此時 client 端會返回一個 ACK 。server 端接收到 ACK 后重置計時器(復位存活定時器)，在 2 小時后再發送探測。如果 2 小時內連接上有數據傳輸，那么在該時間基礎上向后推延 2 個小時。

2. 客戶端異常關閉，或是網絡斷開。在這兩種情況下， client 端都不會響應。服務器沒有收到對其發出探測的響應，并且在一定時間(系統默認為 1000 ms )后重復發送 keep-alive packet ，并且重復發送一定次數( 2000 XP 2003 系統默認為 5 次 , Vista 后的系統默認為 10 次)。

3. 客戶端曾經崩潰，但已經重啟。這種情況下，服務器將會收到對其存活探測的響應，但該響應是一個復位，從而引起服務器對連接的終止。

對于應用程序來說，2小時的空閑時間太長。因此，我們需要手工開啟Keepalive功能并設置合理的Keepalive參數。

全局設置可更改 /etc/sysctl.conf ,加上:

net.ipv4.tcp_keepalive_intvl = 20

net.ipv4.tcp_keepalive_probes = 3

net.ipv4.tcp_keepalive_time = 60

在程序中設置如下:

#include <sys/socket.h>  
 #include <netinet/in.h>  
 #include <arpa/inet.h>  
 #include <sys/types.h>  
 #include <netinet/tcp.h>  
  
 int keepAlive = 1; // 開啟keepalive屬性  
 int keepIdle = 60; // 如該連接在60秒內沒有任何數據往來,則進行探測   
 int keepInterval = 5; // 探測時發包的時間間隔為5 秒  
 int keepCount = 3; // 探測嘗試的次數.如果第1次探測包就收到響應了,則后2次的不再發.  
  
 setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));  
 setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));  
 setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));  
 setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));  

在程序中表現為,當tcp檢測到對端socket不再可用時(不能發出探測包,或探測包沒有收到ACK的響應包),select會返回socket可讀,并且在recv時返回-1,同時置上errno為ETIMEDOUT.