我們通過了解 TCP各個狀態(tài) ，可以排除和定位網(wǎng)絡(luò)或系統(tǒng)故障時大有幫助。

一、TCP狀態(tài)

LISTENING ：偵聽來自遠方的TCP端口的連接請求 .

首先服務(wù)端需要打開一個 socket 進行監(jiān)聽，狀態(tài)為LISTEN。

有提供某種服務(wù)才會處于LISTENING狀態(tài)， TCP狀態(tài)變化就是某個端口的狀態(tài)變化，提供一個服務(wù)就打開一個端口，例如：提供www服務(wù)默認開的是80端口，提供ftp服務(wù)默認的端口為21，當(dāng)提供的服務(wù)沒有被連接時就處于LISTENING狀態(tài)。FTP服務(wù)啟動后首先處于偵聽(LISTENING)狀態(tài)。處于偵聽LISTENING狀態(tài)時，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經(jīng)敞開的，但還沒有人進來。

看LISTENING狀態(tài)最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關(guān)閉不必要的端口是保證安全的一個非常重要的方面，服務(wù)端口都對應(yīng)一個服務(wù)(應(yīng)用程序)，停止該服務(wù)就關(guān)閉了該端口，例如要關(guān)閉21端口只要停止IIS服務(wù)中的FTP服務(wù)即可。關(guān)于這方面的知識請參閱其它文章。

如果你不幸中了服務(wù)端口的木馬，木馬也開個端口處于LISTENING狀態(tài)。

● SYN-SENT： 客戶端SYN_SENT狀態(tài)：

再發(fā)送連接請求后等待匹配的連接請求:

客戶端通過應(yīng)用程序調(diào)用connect進行active open.于是客戶端tcp發(fā)送一個SYN以請求建立一個連接.之后狀態(tài)置為SYN_SENT. /*The socket is actively attempting to establish a connection. 在發(fā)送連接請求后等待匹配的連接請求 */

當(dāng)請求連接時客戶端首先要發(fā)送同步信號給要訪問的機器，此時狀態(tài)為SYN_SENT，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_SENT狀態(tài)非常短暫。例如要訪問網(wǎng)站http://www.baidu.com,如果是正常連接的話，用TCPView觀察 IEXPLORE .EXE(IE)建立的連接會發(fā)現(xiàn)很快從SYN_SENT變?yōu)镋STABLISHED，表示連接成功。SYN_SENT狀態(tài)快的也許看不到。

如果發(fā)現(xiàn)有很多SYN_SENT出現(xiàn)，那一般有這么幾種情況，一是你要訪問的網(wǎng)站不存在或線路不好，二是用掃描軟件掃描一個網(wǎng)段的機器，也會出出現(xiàn)很多SYN_SENT，另外就是可能中了病毒了，例如中了"沖擊波"，病毒發(fā)作時會掃描其它機器，這樣會有很多SYN_SENT出現(xiàn)。

● SYN-RECEIVED： 服務(wù)器端狀態(tài)SYN_RCVD

再收到和發(fā)送一個連接請求后等待對方對連接請求的確認

當(dāng)服務(wù)器收到客戶端發(fā)送的同步信號時，將標(biāo)志位ACK和

SYN置1發(fā)送給客戶端，此時服務(wù)器端處于SYN_RCVD狀態(tài)，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_RCVD狀態(tài)非常短暫。

如果發(fā)現(xiàn)有很多SYN_RCVD狀態(tài)，那你的機器有可能被SYN Flood的DoS(拒絕服務(wù)攻擊)攻擊了。

● SYN Flood的攻擊原理是：

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

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

● ESTABLISHED：代表一個打開的連接。

ESTABLISHED狀態(tài)是表示兩臺機器正在傳輸數(shù)據(jù)，觀察這個狀態(tài)最主要的就是看哪個程序正在處于ESTABLISHED狀態(tài)。

服務(wù)器出現(xiàn)很多 ESTABLISHED狀態(tài)： netstat -nat |grep 9502或者使用lsof -i:9502可以檢測到。

當(dāng)客戶端未主動close的時候就斷開連接：即客戶端發(fā)送的FIN丟失或未發(fā)送。

這時候若客戶端斷開的時候發(fā)送了FIN包，則服務(wù)端將會處于CLOSE_WAIT狀態(tài);

這時候若客戶端斷開的時候未發(fā)送FIN包，則服務(wù)端處還是顯示ESTABLISHED狀態(tài);

結(jié)果客戶端重新連接服務(wù)器。

而新連接上來的客戶端(也就是剛才斷掉的重新連上來了)在服務(wù)端肯定是ESTABLISHED; 如果客戶端重復(fù)的上演這種情況，那么服務(wù)端將會出現(xiàn)大量的假的ESTABLISHED連接和CLOSE_WAIT連接。

最終結(jié)果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經(jīng)建立，并顯示ESTABLISHED，但始終無法進入程序代碼。

● FIN-WAIT-1： 等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認

主動關(guān)閉(active close)端應(yīng)用程序調(diào)用close，于是其TCP發(fā)出FIN請求主動關(guān)閉連接，之后進入FIN_WAIT1狀態(tài)./* The socket is closed, and the connection is shutting down. 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認 */

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

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

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

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

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

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

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

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

被動關(guān)閉端一段時間后，接收到文件結(jié)束符的應(yīng)用程序?qū)⒄{(diào)用CLOSE關(guān)閉連接。這導(dǎo)致它的TCP也發(fā)送一個 FIN,等待對方的ACK.就進入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原來發(fā)向遠程TCP的連接中斷請求的確認 */

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

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

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

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

● CLOSED：沒有任何連接狀態(tài)

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

二、TCP狀態(tài)遷移路線圖

client/server兩條路線講述TCP狀態(tài)遷移路線圖：

 

 

這是一個看起來比較復(fù)雜的狀態(tài)遷移圖，因為它包含了兩個部分---服務(wù)器的狀態(tài)遷移和客戶端的狀態(tài)遷移，如果從某一個角度出發(fā)來看這個圖，就會清晰許多，這里面的服務(wù)器和客戶端都不是絕對的，發(fā)送數(shù)據(jù)的就是客戶端，接受數(shù)據(jù)的就是服務(wù)器。

客戶端應(yīng)用程序的狀態(tài)遷移圖

客戶端的狀態(tài)可以用如下的流程來表示：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

以上流程是在程序正常的情況下應(yīng)該有的流程，從書中的圖中可以看到，在建立連接時，當(dāng)客戶端收到SYN報文的ACK以后，客戶端就打開了數(shù)據(jù)交互地連接。而結(jié)束連接則通常是客戶端主動結(jié)束的，客戶端結(jié)束應(yīng)用程序以后，需要經(jīng)歷FIN_WAIT_1，F(xiàn)IN_WAIT_2等狀態(tài)，這些狀態(tài)的遷移就是前面提到的結(jié)束連接的四次握手。

服務(wù)器的狀態(tài)遷移圖

服務(wù)器的狀態(tài)可以用如下的流程來表示：

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

在建立連接的時候，服務(wù)器端是在第三次握手之后才進入數(shù)據(jù)交互狀態(tài)，而關(guān)閉連接則是在關(guān)閉連接的第二次握手以后(注意不是第四次)。而關(guān)閉以后還要等待客戶端給出最后的ACK包才能進入初始的狀態(tài)。

其他狀態(tài)遷移

還有一些其他的狀態(tài)遷移，這些狀態(tài)遷移針對服務(wù)器和客戶端兩方面的總結(jié)如下

LISTEN->SYN_SENT，對于這個解釋就很簡單了，服務(wù)器有時候也要打開連接的嘛。

SYN_SENT->SYN收到，服務(wù)器和客戶端在SYN_SENT狀態(tài)下如果收到SYN數(shù)據(jù)報，則都需要發(fā)送SYN的ACK數(shù)據(jù)報并把自己的狀態(tài)調(diào)整到SYN收到狀態(tài)，準(zhǔn)備進入ESTABLISHED

SYN_SENT->CLOSED，在發(fā)送超時的情況下，會返回到CLOSED狀態(tài)。

SYN_收到->LISTEN，如果受到RST包，會返回到LISTEN狀態(tài)。

SYN_收到->FIN_WAIT_1，這個遷移是說，可以不用到ESTABLISHED狀態(tài)，而可以直接跳轉(zhuǎn)到FIN_WAIT_1狀態(tài)并等待關(guān)閉。

 

 

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

三、TCP連接建立三次握手

TCP是一個面向連接的協(xié)議，所以在連接雙方發(fā)送數(shù)據(jù)之前，都需要首先建立一條連接。

Client連接Server：

當(dāng)Client端調(diào)用socket函數(shù)調(diào)用時，相當(dāng)于Client端產(chǎn)生了一個處于Closed狀態(tài)的套接字。

( 1) 第一次握手 ： Client端又調(diào)用 connect 函數(shù)調(diào)用，系統(tǒng)為Client隨機分配一個端口，連同傳入connect中的參數(shù)(Server的IP 和 端口)，這就形成了一個連接四元組，客戶端發(fā)送一個帶SYN標(biāo)志的TCP報文到服務(wù)器。這是三次握手過程中的報文1。connect調(diào)用讓Client端的socket處于 SYN_SENT

狀態(tài)，

等待服務(wù)器確認;SYN：同步序列編號( Synchronize Sequence Numbers)。

( 2) 第二次握手 ： 服務(wù)器收到syn包，必須確認客戶的SYN(ack=j+1)，同時自己也發(fā)送一個SYN包(syn=k)，即SYN+ACK包，此時服務(wù)器進入 SYN_RECV 狀態(tài);

( 3) 第三次握手 ： 客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶器和客務(wù)器進入 ESTABLISHED 狀態(tài)，完成三次握手。 連接已經(jīng)可以進行讀寫操作。

一個完整的三次握手也就是： 請求---應(yīng)答---再次確認 。

TCP協(xié)議通過三個報文段完成連接的建立，這個過程稱為三次握手(three-way handshake)，過程如下圖所示。

對應(yīng)的函數(shù)接口：

 

#p#

 

2)Server

當(dāng)Server端調(diào)用socket函數(shù)調(diào)用時，相當(dāng)于Server端產(chǎn)生了一個處于Closed狀態(tài)的監(jiān)聽套接字

Server端調(diào)用 bind 操作，將監(jiān)聽套接字與指定的地址和 端口關(guān)聯(lián)，然后又調(diào)用listen 函數(shù)，系統(tǒng)會為其分配未完成隊列和

完成隊列，此時的監(jiān)聽套接字可以接受Client的連接，監(jiān)聽套接字狀態(tài)處于LISTEN狀態(tài)。

當(dāng)Server端調(diào)用accept操作時，會從完成隊列中取出一個已經(jīng)完成的client連接，同時在server這段會產(chǎn)生一個會話套接字，用于和

client端套接字的通信，這個會話套接字的狀態(tài)是ESTABLISH。

從圖中可以看出，當(dāng)客戶端調(diào)用 connect 時，觸發(fā)了連接請求，向服務(wù)器發(fā)送了SYN J包，這時connect進入阻塞狀態(tài);服務(wù)器監(jiān)聽到連接請求，即收到SYN J包，調(diào)用 accept 函數(shù)接收請求向客戶端發(fā)送SYN K ，ACK J+1，這時accept進入阻塞狀態(tài);客戶端收到服務(wù)器的SYN K ，ACK J+1之后，這時connect返回，并對SYN K進行確認;服務(wù)器收到ACK K+1時，accept返回，至此三次握手完畢，連接建立。

我們可以通過網(wǎng)絡(luò)抓包的查看具體的流程：

比如我們服務(wù)器開啟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 (客戶端的端口一般是自動分配的) 向服務(wù)器localhost.9502 發(fā)送syn包(syn=j)到服務(wù)器》

syn的seq= 2927179378

第二次握手：

14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379,

服務(wù)器收到syn包，必須確認客戶的SYN(ack=j+1)，同時自己也發(fā)送一個SYN包(syn=k)，即SYN+ACK包

SYN(ack=j+1)= ack 2927179379 服務(wù)器主機SYN包(syn= seq 1721825043)

第三次握手：

14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,

客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=k+1)

客戶端 和 服務(wù)器進入ESTABLISHED狀態(tài)后，可以進行通信數(shù)據(jù)交互。此時 和accept接口沒有關(guān)系，即使沒有accepte，也進行3次握手完成。

連 接出現(xiàn)連接不上的問題，一般是網(wǎng)路出現(xiàn)問題或者網(wǎng)卡超負荷或者是連接數(shù)已經(jīng)滿啦。

紫色背景的部分：

IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7

客戶端向服務(wù)器發(fā)送長度為7個字節(jié)的數(shù)據(jù)，

IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0

服務(wù)器向客戶確認已經(jīng)收到數(shù)據(jù)

IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18

然后服務(wù)器同時向客戶端寫入數(shù)據(jù)。

IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0

客戶端向服務(wù)器確認已經(jīng)收到數(shù)據(jù)

這個就是tcp可靠的連接，每次通信都需要對方來確認。

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

由于TCP連接是全雙工的，因此每個方向都必須單獨進行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方執(zhí)行被動關(guān)閉。

建立一個連接需要三次握手，而終止一個連接要經(jīng)過四次握手，這是由TCP的半關(guān)閉(half-close)造成的，如圖：

 

 

( 1 )客戶端 A 發(fā)送一個 FIN ，用來關(guān)閉客戶 A 到服務(wù)器 B 的數(shù)據(jù)傳送(報文段 4 )。

( 2 )服務(wù)器 B 收到這個 FIN ，它發(fā)回一個 ACK ，確認序號為收到的序號加 1(報文段 5 )。和 SYN 一樣，一個 FIN 將占用一個序號。

( 3 )服務(wù)器 B 關(guān)閉與客戶端 A 的連接，發(fā)送一個 FIN 給客戶端 A (報文段 6)。

( 4 )客戶端 A 發(fā)回 ACK 報文確認，并將確認序號設(shè)置為收到序號加 1 (報文段 7 )。

對應(yīng)函數(shù)接口如圖：

 

 

調(diào)用過程如下：

1) 當(dāng)client想要關(guān)閉它與server之間的連接。client(某個應(yīng)用進程)首先調(diào)用 close 主動關(guān)閉連接，這時TCP發(fā)送一個FIN M;client端處于 FIN_WAIT1 狀態(tài)。

2) 當(dāng)server端接收到FIN M之后，執(zhí)行被動關(guān)閉。對這個FIN進行確認，返回給client ACK。當(dāng)server端返回給client ACK后，client處于 FIN_WAIT2 狀態(tài)，server處于 CLOSE_WAIT 狀態(tài)。它的接收也作為文件結(jié)束符傳遞給應(yīng)用進程，因為FIN的接收 意味著應(yīng)用進程在相應(yīng)的連接上再也接收不到額外數(shù)據(jù);

3) 一段時間之后，當(dāng)server端檢測到client端的關(guān)閉操作(read返回為0)。接收到文件結(jié)束符的server端調(diào)用 close 關(guān)閉它的socket。這導(dǎo)致server端的TCP也發(fā)送一個FIN N;此時server的狀態(tài)為 LAST_ACK。

4) 當(dāng)client收到來自server的FIN后 。 client端的套接字處于 TIME_WAIT 狀態(tài)，它會向server端再發(fā)送一個ack確認，此時server端收到ack確認后，此套接字處于CLOSED狀態(tài)。

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

1 .為什么建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢?

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

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

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

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

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

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

五、同時打開

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

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

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

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

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

但多數(shù)伯克利版的tcp/ip實現(xiàn)并不支持同時打開。

 

 

六、同時關(guān)閉

如果應(yīng)用程序同時發(fā)送FIN，則在發(fā)送后會首先進入FIN_WAIT_1狀態(tài)。在收到對端的FIN后，回復(fù)一個ACK，會進入CLOSING狀態(tài)。在收到對端的ACK后，進入TIME_WAIT狀態(tài)。這種情況稱為同時關(guān)閉。

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

 

 

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

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

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

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

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

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

1、 自己編寫心跳包程序

簡單的說也就是在自己的程序中加入一條線程，定時向?qū)Χ税l(fā)送數(shù)據(jù)包，查看是否有ACK，如果有則連接正常，沒有的話則連接斷開

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

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

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

但這會出現(xiàn)三種情況：

情況1.

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

情況2.

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

情況3.

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

這時候若客戶端斷開的時候發(fā)送了FIN包，則服務(wù)端將會處于CLOSE_WAIT狀態(tài);

這時候若客戶端斷開的時候未發(fā)送FIN包，則服務(wù)端處還是顯示ESTABLISHED狀態(tài);

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

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

二）利用KeepAlive

其實keepalive的原理就是TCP內(nèi)嵌的一個心跳包,

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

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

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

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

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

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

net.ipv4.tcp_keepalive_intvl = 20

net.ipv4.tcp_keepalive_probes = 3

net.ipv4.tcp_keepalive_time = 60

在程序中設(shè)置如下:

#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秒內(nèi)沒有任何數(shù)據(jù)往來,則進行探測   
 int keepInterval = 5; // 探測時發(fā)包的時間間隔為5 秒  
 int keepCount = 3; // 探測嘗試的次數(shù).如果第1次探測包就收到響應(yīng)了,則后2次的不再發(fā).  
  
 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));  

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