轉：TCP鏈接的狀態詳解以及故障排查

https://blog.csdn.net/m0_37886429/article/details/82620868

1、TCP狀態

一、linux查看tcp的狀態命令

1) netstat -nat 查看TCP各個狀態的數量

2) lsof -i:port 能夠檢測到打開套接字的情況

3) sar -n SOCK 查看tcp建立的鏈接數

4) tcpdump -iany tcp port 9000 對tcp端口爲9000的進行抓包

二、網絡測試經常使用命令

1) ping:檢測網絡鏈接的正常與否,主要是測試延時、抖動、丟包率。

可是不少服務器爲了防止攻擊，通常會關閉對ping的響應。因此ping通常做爲測試連通性使用。 ping命令後，會接收到對方發送的回饋信息，其中記錄着對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄以前容許經過的最大網段數量。 TTL是IPv4包頭的一個8 bit字段。例如IP包在服務器中發送前設置的TTL是64，你使用ping命令後，獲得服務器反饋的信息，其中的TTL爲56，說明途中一共通過了8道路由器的轉發，每通過一個路由，TTL減1。

2）traceroute：raceroute 跟蹤數據包到達網絡主機所通過的路由工具

traceroute hostname

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

pathping www.baidu.com

4）mtr：以結合ping nslookup tracert 來判斷網絡的相關特性

5) nslookup:用於解析域名，通常用來檢測本機的DNS設置是否配置正確。

---

狀態分析：

①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.10四、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狀態。等待遠程TCP的鏈接中斷請求，或先前的鏈接中斷請求的確認

若是服務器出現shutdown再重啓，使用netstat -nat查看，就會看到不少FIN-WAIT-1的狀態。就是由於服務器當前有不少客戶端鏈接，直接關閉服務器後，沒法接收到客戶端的ACK。

⑥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的鏈接中斷請求的確認

使用併發壓力測試的時候，忽然斷開壓力測試客戶端，服務器會看到不少LAST-ACK。

⑩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時間的過去才能進行下一次鏈接。

詳情請看：TIME_WAIT引發Cannot assign requested address報錯

⑪ CLOSED：沒有任何鏈接狀態

被動關閉端在接受到ACK包後，就進入了closed的狀態。鏈接結束

The socket is not being used. 沒有任何鏈接狀態

2、TCP狀態遷移路線圖

client/server兩條路線講述TCP狀態遷移路線圖：

 

3、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)。

　　鏈接出現鏈接不上的問題，通常是網路出現問題或者網卡超負荷或者是鏈接數已經滿啦。

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

因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。

首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。

創建一個鏈接須要三次握手，而終止一個鏈接要通過四次握手，這是由TCP的半關閉(half-close)形成的，

（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送。  

（2）服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。和SYN同樣，一個FIN將佔用一個序號。  

（3）服務器B關閉與客戶端A的鏈接，發送一個FIN給客戶端A。  

（4）客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1。

5、爲何創建鏈接協議是三次握手，而關閉鏈接倒是四次握手

服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它能夠把ACK和SYN（ACK起應答做用，而SYN起同步做用）放在一個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；

但未必你全部的數據都所有發送給對方了，因此你能夠未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

6、爲何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元組，這時候鏈接就可能接收到網絡上的延遲報文就可能干擾最新創建的鏈接。

7、大量TIME_WAIT狀態問題解決

發現系統存在大量TIME_WAIT狀態的鏈接，能夠經過調整內核參數解決：vi /etc/sysctl.conf 加入如下內容：

net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30

而後執行 /sbin/sysctl -p 讓參數生效。

net.ipv4.tcp_syncookies = 1 表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN攻擊，默認爲0，表示關閉；

net.ipv4.tcp_tw_reuse = 1 表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；

net.ipv4.tcp_tw_recycle = 1 表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。

net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間

　　備註：這種方式不是很好，我以前試過修改內核參數只是一會沒有問題，可是時間長了仍是沒有效果，建議採用長鏈接方式。

8、同時打開

兩個應用程序同時執行主動打開的狀況是可能的，雖然發生的可能性較低。每一端都發送一個SYN,並傳遞給對方，且每一端都使用對端所知的端口做爲本地端口。例如： 主機a中一應用程序使用7777做爲本地端口，並鏈接到主機b 8888端口作主動打開。 主機b中一應用程序使用8888做爲本地端口，並鏈接到主機a 7777端口作主動打開。 tcp協議在遇到這種狀況時，只會打開一條鏈接。 這個鏈接的創建過程須要4次數據交換，而一個典型的鏈接創建只須要3次交換（即3次握手） 但多數tcp/ip實現並不支持同時打開。

9、同時關閉

若是應用程序同時發送FIN，則在發送後會首先進入FIN_WAIT_1狀態。在收到對端的FIN後，回覆一個ACK，會進入CLOSING狀態。在收到對端的ACK後，進入TIME_WAIT狀態。這種狀況稱爲同時關閉。 同時關閉也須要有4次報文交換，與典型的關閉相同。

10、TCP的FLAGS說明

在TCP層，有個FLAGS字段，這個字段有如下幾個標識：SYN, FIN, ACK, PSH, RST, URG. 其中，對於咱們平常的分析有用的就是前面的五個字段。

字段含義：

一、SYN表示創建鏈接： 步序列編號(Synchronize Sequence Numbers)欄有效。該標誌僅在三次握手創建TCP鏈接時有效。它提示TCP鏈接的服務端檢查序列編號，該序列編號爲TCP鏈接初始端(通常是客戶端)的初始序列編號。在這裏，能夠把TCP序列編號看做是一個範圍從0到4，294，967，295的32位計數器。經過TCP鏈接交換的數據中每個字節都通過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個字節的序列編號。

二、FIN表示關閉鏈接：

三、ACK表示響應： 確認編號(Acknowledgement Number)欄有效。大多數狀況下該標誌位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1，Figure-1)爲下一個預期的序列編號，同時提示遠端系統已經成功接收全部數據。

四、PSH表示有DATA數據傳輸：

五、RST表示鏈接重置：復位標誌有效。用於復位相應的TCP鏈接。

字段組合含義：

其中，ACK是可能與SYN，FIN等同時使用的，好比SYN和ACK可能同時爲1，它表示的就是創建鏈接以後的響應， 若是隻是單個的一個SYN，它表示的只是創建鏈接。 TCP的幾回握手就是經過這樣的ACK表現出來的。 但SYN與FIN是不會同時爲1的，由於前者表示的是創建鏈接，然後者表示的是斷開鏈接。

RST通常是在FIN以後纔會出現爲1的狀況，表示的是鏈接重置。 通常地，當出現FIN包或RST包時，咱們便認爲客戶端與服務器端斷開了鏈接；

RST與ACK標誌位都置一了，而且具備ACK number，很是明顯，這個報文在釋放TCP鏈接的同時，完成了對前面已接收報文的確認。

而當出現SYN和SYN＋ACK包時，咱們認爲客戶端與服務器創建了一個鏈接。

PSH爲1的狀況，通常只出如今 DATA內容不爲0的包中，也就是說PSH爲1表示的是有真正的TCP數據包內容被傳遞。

TCP的鏈接創建和鏈接關閉，都是經過請求－響應的模式完成的。

11、TCP通訊中服務器處理客戶端意外斷開

若是TCP鏈接被對方正常關閉，也就是說，對方是正確地調用了closesocket(s)或者shutdown(s)的話，那麼上面的Recv或Send調用就能立刻返回，而且報錯。這是因爲close socket(s)或者shutdown(s)有個正常的關閉過程，會告訴對方「TCP鏈接已經關閉，你不須要再發送或者接受消息了」。

可是，若是意外斷開，客戶端（3g的移動設備）並無正常關閉socket。雙方並未按照協議上的四次揮手去斷開鏈接。

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

像這種若是一方已經關閉或異常終止鏈接，而另外一方殊不知道，咱們將這樣的TCP鏈接稱爲半打開的。

解決意外中斷辦法都是利用保活機制。而保活機制分又可讓底層實現也可本身實現。

一、本身編寫心跳包程序

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

二、啓動TCP編程裏的keepAlive機制

1）雙方擬定心跳（自實現） 通常由客戶端發送心跳包，服務端並不迴應心跳，只是定時輪詢判斷一下與上次的時間間隔是否超時（超時時間本身設定）。服務器並不主動發送是不想增添服務器的通訊量，減小壓力。

2）利用KeepAlive 其實keepalive的原理就是TCP內嵌的一個心跳包,

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

client端仍然存在，網絡鏈接情況良好。此時client端會返回一個ACK。server端接收到ACK後重置計時器（復位存活定時器），在2小時後再發送探測。若是2小時內鏈接上有數據傳輸，那麼在該時間基礎上向後推延2個小時。
  客戶端異常關閉，或是網絡斷開。在這兩種狀況下，client端都不會響應。服務器沒有收到對其發出探測的響應，而且在必定時間（系統默認爲1000 ms）後重復發送keep-alive packet，而且重複發送必定次數（2000 XP 2003 系統默認爲5次, Vista後的系統默認爲10次）。
  客戶端曾經崩潰，但已經重啓。這種狀況下，服務器將會收到對其存活探測的響應，但該響應是一個復位，從而引發服務器對鏈接的終止。

對於應用程序來講，2小時的空閒時間太長。所以，咱們須要手工開啓Keepalive功能並設置合理的Keepalive參數。

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

net.ipv4.tcp_keepalive_intvl = 20 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_time = 60

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