通過linux查看tcp的狀態(tài)命令及故障排除

1、TCP狀態(tài)

了解TCP之前，先了解幾個(gè)命令：

linux查看tcp的狀態(tài)命令：

1)?netstat -nat?查看TCP各個(gè)狀態(tài)的數(shù)量
2)lsof ?-i:port?可以檢測到打開套接字的狀況
3)?sar -n SOCK?查看tcp創(chuàng)建的連接數(shù)
4)?tcpdump -iany tcp port 9000?對tcp端口為9000的進(jìn)行抓包

網(wǎng)絡(luò)測試常用命令;

1）ping：檢測網(wǎng)絡(luò)連接的正常與否,主要是測試延時(shí)、抖動(dòng)、丟包率。

但是很多服務(wù)器為了防止攻擊，一般會關(guān)閉對ping的響應(yīng)。所以ping一般作為測試連通性使用。

ping命令后，會接收到對方發(fā)送的回饋信息，其中記錄著對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄之前允許通過的最大網(wǎng)段數(shù)量。

TTL是IPv4包頭的一個(gè)8 bit字段。例如IP包在服務(wù)器中發(fā)送前設(shè)置的TTL是64，你使用ping命令后，得到服務(wù)器反饋的信息，其中的TTL為56，說明途中一共經(jīng)過了8道路由器的轉(zhuǎn)發(fā)，每經(jīng)過一個(gè)路由，TTL減1。

2）traceroute：raceroute 跟蹤數(shù)據(jù)包到達(dá)網(wǎng)絡(luò)主機(jī)所經(jīng)過的路由工具
traceroute hostname

3）pathping：是一個(gè)路由跟蹤工具，它將 ping 和 tracert 命令的功能與這兩個(gè)工具所不提供的其他信息結(jié)合起來，綜合了二者的功能

pathping www.baidu.com

4）mtr：以結(jié)合ping nslookup tracert 來判斷網(wǎng)絡(luò)的相關(guān)特性

5) nslookup:用于解析域名，一般用來檢測本機(jī)的DNS設(shè)置是否配置正確。

LISTENING：偵聽來自遠(yuǎn)方的TCP端口的連接請求.
首先服務(wù)端需要打開一個(gè)socket進(jìn)行監(jiān)聽，狀態(tài)為LISTEN。

有提供某種服務(wù)才會處于LISTENING狀態(tài)，TCP狀態(tài)變化就是某個(gè)端口的狀態(tài)變化，提供一個(gè)服務(wù)就打開一個(gè)端口。

例如：提供www服務(wù)默認(rèn)開的是80端口，提供ftp服務(wù)默認(rèn)的端口為21，當(dāng)提供的服務(wù)沒有被連接時(shí)就處于LISTENING狀態(tài)。

FTP服務(wù)啟動(dòng)后首先處于偵聽（LISTENING）狀態(tài)。處于偵聽LISTENING狀態(tài)時(shí)，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經(jīng)敞開的，但還沒有人進(jìn)來。

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

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

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

再發(fā)送連接請求后等待匹配的連接請求:客戶端通過應(yīng)用程序調(diào)用connect進(jìn)行active open.

于是客戶端tcp發(fā)送一個(gè)SYN以請求建立一個(gè)連接.之后狀態(tài)置為SYN_SENT.?

The socket is actively attempting to establish a connection. 在發(fā)送連接請求后等待匹配的連接請求?

當(dāng)請求連接時(shí)客戶端首先要發(fā)送同步信號給要訪問的機(jī)器，此時(shí)狀態(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)站不存在或線路不好。

二是用掃描軟件掃描一個(gè)網(wǎng)段的機(jī)器，也會出出現(xiàn)很多SYN_SENT，另外就是可能中了病毒了，例如中了”沖擊波”，病毒發(fā)作時(shí)會掃描其它機(jī)器，這樣會有很多SYN_SENT出現(xiàn)。

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

再收到和發(fā)送一個(gè)連接請求后等待對方對連接請求的確認(rèn)
當(dāng)服務(wù)器收到客戶端發(fā)送的同步信號時(shí)，將標(biāo)志位ACK和SYN置1發(fā)送給客戶端，此時(shí)服務(wù)器端處于SYN_RCVD狀態(tài)，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_RCVD狀態(tài)非常短暫。

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

SYN Flood的攻擊原理是：

在進(jìn)行三次握手時(shí)，攻擊軟件向被攻擊的服務(wù)器發(fā)送SYN連接請求（握手的第一步），但是這個(gè)地址是偽造的，如攻擊軟件隨機(jī)偽造了51.133.163.104、65.158.99.152等等地址。

服務(wù)器在收到連接請求時(shí)將標(biāo)志位ACK和SYN置1發(fā)送給客戶端（握手的第二步），但是這些客戶端的IP地址都是偽造的，服務(wù)器根本找不到客戶機(jī)，也就是說握手的第三步不可能完成。

這種情況下服務(wù)器端一般會重試（再次發(fā)送SYN+ACK給客戶端）并等待一段時(shí)間后丟棄這個(gè)未完成的連接，這段時(shí)間的長度我們稱為SYN Timeout，一般來說這個(gè)時(shí)間是分鐘的數(shù)量級（大約為30秒-2分鐘）；

一個(gè)用戶出現(xiàn)異常導(dǎo)致服務(wù)器的一個(gè)線程等待1分鐘并不是什么很大的問題，但如果有一個(gè)惡意的攻擊者大量模擬這種情況，服務(wù)器端將為了維護(hù)一個(gè)非常大的半連接列表而消耗非常多的資源——數(shù)以萬計(jì)的半連接。

即使是簡單的保存并遍歷也會消耗非常多的CPU時(shí)間和內(nèi)存，何況還要不斷對這個(gè)列表中的IP進(jìn)行SYN+ACK的重試。

此時(shí)從正?？蛻舻慕嵌瓤磥恚?wù)器失去響應(yīng)，這種情況我們稱做：服務(wù)器端受到了SYN Flood攻擊（SYN洪水攻擊）

ESTABLISHED：代表一個(gè)打開的連接。

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

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

當(dāng)客戶端未主動(dòng)close的時(shí)候就斷開連接：即客戶端發(fā)送的FIN丟失或未發(fā)送。
這時(shí)候若客戶端斷開的時(shí)候發(fā)送了FIN包，則服務(wù)端將會處于CLOSE_WAIT狀態(tài)；

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

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

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

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

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

如果服務(wù)器出現(xiàn)shutdown再重啟，使用netstat -nat查看，就會看到很多FIN-WAIT-1的狀態(tài)。就是因?yàn)榉?wù)器當(dāng)前有很多客戶端連接，直接關(guān)閉服務(wù)器后，無法接收到客戶端的ACK。

FIN-WAIT-2：從遠(yuǎn)程TCP等待連接中斷請求
主動(dòng)關(guān)閉端接到ACK后，就進(jìn)入了FIN-WAIT-2?

Connection is closed, and the socket is waiting for a shutdown from the remote end. 從遠(yuǎn)程TCP等待連接中斷請求?

這就是著名的半關(guān)閉的狀態(tài)了，這是在關(guān)閉連接時(shí)，客戶端和服務(wù)器兩次握手之后的狀態(tài)。

在這個(gè)狀態(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)閉這個(gè)狀態(tài)。

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

被動(dòng)關(guān)閉(passive close)端TCP接到FIN后，就發(fā)出ACK以回應(yīng)FIN請求(它的接收也作為文件結(jié)束符傳遞給上層應(yīng)用程序),并進(jìn)入CLOSE_WAIT.?

The remote end has shut down, waiting for the socket to close. 等待從本地用戶發(fā)來的連接中斷請求?

CLOSING：等待遠(yuǎn)程TCP對連接中斷的確認(rèn)

比較少見

Both sockets are shut down but we still don’t have all our data sent. 等待遠(yuǎn)程TCP對連接中斷的確認(rèn)?

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

被動(dòng)關(guān)閉端一段時(shí)間后，接收到文件結(jié)束符的應(yīng)用程序?qū)⒄{(diào)用CLOSE關(guān)閉連接。這導(dǎo)致它的TCP也發(fā)送一個(gè)
FIN,等待對方的ACK.就進(jìn)入了LAST-ACK .?

The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原來發(fā)向遠(yuǎn)程TCP的連接中斷請求的確認(rèn)?

使用并發(fā)壓力測試的時(shí)候，突然斷開壓力測試客戶端，服務(wù)器會看到很多LAST-ACK。

TIME-WAIT：等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請求的確認(rèn)

在主動(dòng)關(guān)閉端接收到FIN后，TCP就發(fā)送ACK包，并進(jìn)入TIME-WAIT狀態(tài)。

The socket is waiting after close to handle
packets still in the network.等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請求的確認(rèn)?

TIME_WAIT等待狀態(tài)，這個(gè)狀態(tài)又叫做2MSL狀態(tài)，說的是在TIME_WAIT2發(fā)送了最后一個(gè)ACK數(shù)據(jù)報(bào)以后，要進(jìn)入TIME_WAIT狀態(tài)，這個(gè)狀態(tài)是防止最后一次握手的數(shù)據(jù)報(bào)沒有傳送到對方那里而準(zhǔn)備的（注意這不是四次握手，這是第四次握手的保險(xiǎn)狀態(tài)）。

這個(gè)狀態(tài)在很大程度上保證了雙方都可以正常結(jié)束，但是，問題也來了。

由于插口的2MSL狀態(tài)（插口是IP和端口對的意思，socket），使得應(yīng)用程序在2MSL時(shí)間內(nèi)是無法再次使用同一個(gè)插口的，對于客戶程序還好一些，但是對于服務(wù)程序，例如httpd，它總是要使用同一個(gè)端口來進(jìn)行服務(wù)，而在2MSL時(shí)間內(nèi)，啟動(dòng)httpd就會出現(xiàn)錯(cuò)誤（插口被使用）。

為了避免這個(gè)錯(cuò)誤，服務(wù)器給出了一個(gè)平靜時(shí)間的概念，這是說在2MSL時(shí)間內(nèi)，雖然可以重新啟動(dòng)服務(wù)器，但是這個(gè)服務(wù)器還是要平靜的等待2MSL時(shí)間的過去才能進(jìn)行下一次連接。

詳情請看：TIME_WAIT引起Cannot assign requested address報(bào)錯(cuò)

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

被動(dòng)關(guān)閉端在接受到ACK包后，就進(jìn)入了closed的狀態(tài)。連接結(jié)束

The socket is not being used. 沒有任何連接狀態(tài)?

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

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

這是一個(gè)看起來比較復(fù)雜的狀態(tài)遷移圖，因?yàn)樗藘蓚€(gè)部分—-服務(wù)器的狀態(tài)遷移和客戶端的狀態(tài)遷移，如果從某一個(gè)角度出發(fā)來看這個(gè)圖，就會清晰許多，這里面的服務(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)該有的流程，從書中的圖中可以看到，在建立連接時(shí)，當(dāng)客戶端收到SYN報(bào)文的ACK以后，客戶端就打開了數(shù)據(jù)交互地連接。

而結(jié)束連接則通常是客戶端主動(dòng)結(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

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

其他狀態(tài)遷移

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

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

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

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

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

怎樣牢牢地將這張圖刻在腦中呢？那么你就一定要對這張圖的每一個(gè)狀態(tài)，及轉(zhuǎn)換的過程有深刻的認(rèn)識，不能只停留在一知半解之中。

下面對這張圖的11種狀態(tài)詳細(xì)解析一下，以便加強(qiáng)記憶！不過在這之前，先回顧一下TCP建立連接的三次握手過程，以及關(guān)閉連接的四次握手過程。

3、TCP連接建立三次握手

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

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

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

這是三次握手過程中的報(bào)文1。connect調(diào)用讓Client端的socket處于SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)；SYN：同步序列編號(Synchronize Sequence Numbers)。

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

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

一個(gè)完整的三次握手也就是：請求—-應(yīng)答—-再次確認(rèn)。
TCP協(xié)議通過三個(gè)報(bào)文段完成連接的建立，這個(gè)過程稱為三次握手(three-way handshake)，過程如下圖所示。

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

2)Server

當(dāng)Server端調(diào)用socket函數(shù)調(diào)用時(shí)，相當(dāng)于Server端產(chǎn)生了一個(gè)處于Closed狀態(tài)的監(jiān)聽套接字，Server端調(diào)用bind操作，將監(jiān)聽套接字與指定的地址和端口關(guān)聯(lián)，然后又調(diào)用listen函數(shù)，系統(tǒng)會為其分配未完成隊(duì)列和完成隊(duì)列，此時(shí)的監(jiān)聽套接字可以接受Client的連接，監(jiān)聽套接字狀態(tài)處于LISTEN狀態(tài)。

當(dāng)Server端調(diào)用accept操作時(shí)，會從完成隊(duì)列中取出一個(gè)已經(jīng)完成的client連接，同時(shí)在server這段會產(chǎn)生一個(gè)會話套接字，用于和client端套接字的通信，這個(gè)會話套接字的狀態(tài)是ESTABLISH。

從圖中可以看出，當(dāng)客戶端調(diào)用connect時(shí)，觸發(fā)了連接請求，向服務(wù)器發(fā)送了SYN J包，這時(shí)connect進(jìn)入阻塞狀態(tài)；

服務(wù)器監(jiān)聽到連接請求，即收到SYN J包，調(diào)用accept函數(shù)接收請求向客戶端發(fā)送SYN K ，ACK J+1，這時(shí)accept進(jìn)入阻塞狀態(tài)；客戶端收到服務(wù)器的SYN K ，ACK J+1之后，這時(shí)connect返回，并對SYN K進(jìn)行確認(rèn)；服務(wù)器收到ACK K+1時(shí)，accept返回，至此三次握手完畢，連接建立。

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

比如我們服務(wù)器開啟9502的端口。使用tcpdump來抓包：tcpdump -iany tcp port 9502

然后我們使用telnet 127.0.0.1 9502開連接：

我們看到 （1）（2）（3）三步是建立tcp：

第一次握手：

1445.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378
客戶端IP localhost.39870?(客戶端的端口一般是自動(dòng)分配的) 向服務(wù)器localhost.9502?發(fā)送syn包(syn=j)到服務(wù)器》

syn的seq=2927179378

第二次握手：

1445.104701 IP localhost.9502 > localhost.39870: Flags?[S.], seq 1721825043, ack 2927179379,
服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包
SYN（ack=j+1）=ack 2927179379 服務(wù)器主機(jī)SYN包（syn=seq 1721825043）

第三次握手：
1445.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,
客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)
客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)后，可以進(jìn)行通信數(shù)據(jù)交互。此時(shí)和accept接口沒有關(guān)系，即使沒有accepte，也進(jìn)行3次握手完成。

連接出現(xiàn)連接不上的問題，一般是網(wǎng)路出現(xiàn)問題或者網(wǎng)卡超負(fù)荷或者是連接數(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個(gè)字節(jié)的數(shù)據(jù)，

IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0
服務(wù)器向客戶確認(rèn)已經(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í)向客戶端寫入數(shù)據(jù)。

IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0
客戶端向服務(wù)器確認(rèn)已經(jīng)收到數(shù)據(jù)

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

4、TCP連接的終止（四次握手釋放）

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

首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

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

（1）客戶端A發(fā)送一個(gè)FIN，用來關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送（報(bào)文段4）。
（2）服務(wù)器B收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號為收到的序號加1（報(bào)文段5）。和SYN一樣，一個(gè)FIN將占用一個(gè)序號。
（3）服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個(gè)FIN給客戶端A（報(bào)文段6）。
（4）客戶端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號設(shè)置為收到序號加1（報(bào)文段7）。

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

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

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

2) 當(dāng)server端接收到FIN M之后，執(zhí)行被動(dòng)關(guān)閉。對這個(gè)FIN進(jìn)行確認(rèn)，返回給client ACK。

當(dāng)server端返回給client ACK后，client處于FIN_WAIT2狀態(tài)，server處于CLOSE_WAIT狀態(tài)。它的接收也作為文件結(jié)束符傳遞給應(yīng)用進(jìn)程，因?yàn)镕IN的接收 意味著應(yīng)用進(jìn)程在相應(yīng)的連接上再也接收不到額外數(shù)據(jù)；

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

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

這樣每個(gè)方向上都有一個(gè)FIN和ACK。

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

這是因?yàn)榉?wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的建連請求后，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個(gè)報(bào)文里來發(fā)送。但關(guān)閉連接時(shí)，當(dāng)收到對方的FIN報(bào)文通知時(shí)，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了；

但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了，所以你可以未必會馬上會關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報(bào)文給對方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。

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

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

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

另一方面，但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報(bào)文會一定被對方收到，因此對方處于LAST_ACK狀態(tài)下的SOCKET可能會因?yàn)槌瑫r(shí)未收到ACK報(bào)文，而重發(fā)FIN報(bào)文，所以這個(gè)TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報(bào)文。

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

3、發(fā)現(xiàn)系統(tǒng)存在大量TIME_WAIT狀態(tài)的連接，可以通過調(diào)整內(nèi)核參數(shù)解決：vi /etc/sysctl.conf 加入以下內(nèi)容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后執(zhí)行 /sbin/sysctl -p 讓參數(shù)生效。
net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時(shí)，啟用cookies來處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。
net.ipv4.tcp_fin_timeout 修改系統(tǒng)默認(rèn)的 TIMEOUT 時(shí)間

5、同時(shí)打開

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

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

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

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

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

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

6、同時(shí)關(guān)閉

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

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

7、TCP的FLAGS說明

在TCP層，有個(gè)FLAGS字段，這個(gè)字段有以下幾個(gè)標(biāo)識：SYN, FIN, ACK, PSH, RST, URG.

其中，對于我們?nèi)粘５姆治鲇杏玫木褪乔懊娴奈鍌€(gè)字段。

一、字段含義：

1、SYN表示建立連接：

步序列編號(Synchronize Sequence Numbers)欄有效。該標(biāo)志僅在三次握手建立TCP連接時(shí)有效。它提示TCP連接的服務(wù)端檢查序列編號，該序列編號為TCP連接初始端(一般是客戶端)的初始序列編號。在這里，可以把TCP序列編號看作是一個(gè)范圍從0到4，294，967，295的32位計(jì)數(shù)器。通過TCP連接交換的數(shù)據(jù)中每一個(gè)字節(jié)都經(jīng)過序列編號。在TCP報(bào)頭中的序列編號欄包括了TCP分段中第一個(gè)字節(jié)的序列編號。

2、FIN表示關(guān)閉連接：

3、ACK表示響應(yīng)：

確認(rèn)編號(Acknowledgement Number)欄有效。大多數(shù)情況下該標(biāo)志位是置位的。TCP報(bào)頭內(nèi)的確認(rèn)編號欄內(nèi)包含的確認(rèn)編號(w+1，F(xiàn)igure-1)為下一個(gè)預(yù)期的序列編號，同時(shí)提示遠(yuǎn)端系統(tǒng)已經(jīng)成功接收所有數(shù)據(jù)。

4、PSH表示有DATA數(shù)據(jù)傳輸：

5、RST表示連接重置：復(fù)位標(biāo)志有效。用于復(fù)位相應(yīng)的TCP連接。

二、字段組合含義：

其中，ACK是可能與SYN，F(xiàn)IN等同時(shí)使用的，比如SYN和ACK可能同時(shí)為1，它表示的就是建立連接之后的響應(yīng)，
如果只是單個(gè)的一個(gè)SYN，它表示的只是建立連接。
TCP的幾次握手就是通過這樣的ACK表現(xiàn)出來的。
但SYN與FIN是不會同時(shí)為1的，因?yàn)榍罢弑硎镜氖墙⑦B接，而后者表示的是斷開連接。

RST一般是在FIN之后才會出現(xiàn)為1的情況，表示的是連接重置。
一般地，當(dāng)出現(xiàn)FIN包或RST包時(shí)，我們便認(rèn)為客戶端與服務(wù)器端斷開了連接；

RST與ACK標(biāo)志位都置一了，并且具有ACK number，非常明顯，這個(gè)報(bào)文在釋放TCP連接的同時(shí)，完成了對前面已接收報(bào)文的確認(rèn)。

而當(dāng)出現(xiàn)SYN和SYN＋ACK包時(shí)，我們認(rèn)為客戶端與服務(wù)器建立了一個(gè)連接。

PSH為1的情況，一般只出現(xiàn)在 DATA內(nèi)容不為0的包中，也就是說PSH為1表示的是有真正的TCP數(shù)據(jù)包內(nèi)容被傳遞。

TCP的連接建立和連接關(guān)閉，都是通過請求－響應(yīng)的模式完成的。

8、TCP通信中服務(wù)器處理客戶端意外斷開

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

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

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

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

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

1、自己編寫心跳包程序

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

2、啟動(dòng)TCP編程里的keepAlive機(jī)制

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

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

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

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

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

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

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

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

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

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

個(gè)人最初感覺導(dǎo)致這種情況是因?yàn)榧俚腅STABLISHED連接和CLOSE_WAIT連接會占用較大的系統(tǒng)資源，程序無法再次創(chuàng)建連接（因?yàn)槊看挝野l(fā)現(xiàn)這個(gè)問題的時(shí)候我只連了10個(gè)左右客戶端卻已經(jīng)有40多條無效連接）。

而最近幾天測試卻發(fā)現(xiàn)有一次程序內(nèi)只連接了2，3個(gè)設(shè)備，但是有8條左右的虛連接，此時(shí)已經(jīng)連接不了新客戶端了。

這時(shí)候我就覺得我想錯(cuò)了，不可能這幾條連接就占用了大量連接把，如果說幾十條還有可能。但是能肯定的是，這個(gè)問題的產(chǎn)生絕對是設(shè)備在不停的重啟，而服務(wù)器這邊又是簡單的輪詢，并不能及時(shí)處理，暫時(shí)還未能解決。

二、利用KeepAlive

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

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

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

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

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

對于應(yīng)用程序來說，2小時(shí)的空閑時(shí)間太長。因此，我們需要手工開啟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è)置如下:

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

9、Linux錯(cuò)誤信息(errno)列表

經(jīng)常出現(xiàn)的錯(cuò)誤：

22：參數(shù)錯(cuò)誤，比如ip地址不合法，沒有目標(biāo)端口等

101：網(wǎng)絡(luò)不可達(dá)，比如不能ping通

111：鏈接被拒絕，比如目標(biāo)關(guān)閉鏈接等

115：當(dāng)鏈接設(shè)置為非阻塞時(shí)，目標(biāo)沒有及時(shí)應(yīng)答，返回此錯(cuò)誤，socket可以繼續(xù)使用。比如socket連接。

編輯：黃飛

?