TCP連線的狀態詳解以及故障排查
我們通過了解TCP各個狀態，可以排除和定位網路或系統故障時大有幫助。
1、TCP狀態
瞭解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.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的連線中斷請求，或先前的連線中斷請求的確認 /
如果伺服器出現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狀態遷移路線圖：
這是一個看起來比較複雜的狀態遷移圖，因為它包含了兩個部分—-伺服器的狀態遷移和客戶端的狀態遷移，如果從某一個角度出發來看這個圖，就會清晰許多，這裡面的伺服器和客戶端都不是絕對的，傳送資料的就是客戶端，接受資料的就是伺服器。
客戶端應用程式的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
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建立連線的三次握手過程，以及關閉連線的四次握手過程。
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)，過程如下圖所示。
對應的函式介面：
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開連線:
我們看到 （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連線的終止（四次握手釋放）
由於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元組，這時候連線就可能接收到網路上的延遲報文就可能干擾最新建立的連線。
3、發現系統存在大量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 時間
5、同時開啟
兩個應用程式同時執行主動開啟的情況是可能的，雖然發生的可能性較低。每一端都發送一個SYN,並傳遞給對方，且每一端都使用對端所知的埠作為本地埠。例如：
主機a中一應用程式使用7777作為本地埠，並連線到主機b 8888埠做主動開啟。
主機b中一應用程式使用8888作為本地埠，並連線到主機a 7777埠做主動開啟。
tcp協議在遇到這種情況時，只會開啟一條連線。
這個連線的建立過程需要4次資料交換，而一個典型的連線建立只需要3次交換（即3次握手）
但多數伯克利版的tcp/ip實現並不支援同時開啟。
6、同時關閉
如果應用程式同時傳送FIN，則在傳送後會首先進入FIN_WAIT_1狀態。在收到對端的FIN後，回覆一個ACK，會進入CLOSING狀態。在收到對端的ACK後，進入TIME_WAIT狀態。這種情況稱為同時關閉。
同時關閉也需要有4次報文交換，與典型的關閉相同。
7. TCP的FLAGS說明
在TCP層，有個FLAGS欄位，這個欄位有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.
其中，對於我們日常的分析有用的就是前面的五個欄位。
一、欄位含義：
1、SYN表示建立連線：
步序列編號(Synchronize Sequence Numbers)欄有效。該標誌僅在三次握手建立TCP連線時有效。它提示TCP連線的服務端檢查序列編號，該序列編號為TCP連線初始端(一般是客戶端)的初始序列編號。在這裡，可以把TCP序列編號看作是一個範圍從0到4，294，967，295的32位計數器。通過TCP連線交換的資料中每一個位元組都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個位元組的序列編號。
2、FIN表示關閉連線：
3、ACK表示響應：
確認編號(Acknowledgement Number)欄有效。大多數情況下該標誌位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1，Figure-1)為下一個預期的序列編號，同時提示遠端系統已經成功接收所有資料。
4、PSH表示有DATA資料傳輸：
5、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的連線建立和連線關閉，都是通過請求－響應的模式完成的。
8. TCP通訊中伺服器處理客戶端意外斷開
如果TCP連線被對方正常關閉，也就是說，對方是正確地呼叫了closesocket(s)或者shutdown(s)的話，那麼上面的Recv或Send呼叫就能馬上返回，並且報錯。這是由於close socket(s)或者shutdown(s)有個正常的關閉過程，會告訴對方“TCP連線已經關閉，你不需要再發送或者接受訊息了”。
但是，如果意外斷開，客戶端（3g的移動裝置）並沒有正常關閉socket。雙方並未按照協議上的四次揮手去斷開連線。
那麼這時候正在執行Recv或Send操作的一方就會因為沒有任何連線中斷的通知而一直等待下去，也就是會被長時間卡住。
像這種如果一方已經關閉或異常終止連線，而另一方卻不知道，我們將這樣的TCP連線稱為半開啟的。
解決意外中斷辦法都是利用保活機制。而保活機制分又可以讓底層實現也可自己實現。
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端應該為以下三種情況之一：
-
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.
9. Linux錯誤資訊(errno)列表
經常出現的錯誤：
22：引數錯誤，比如ip地址不合法，沒有目標埠等
101：網路不可達，比如不能ping通
111：連結被拒絕，比如目標關閉連結等
115：當連結設定為非阻塞時，目標沒有及時應答，返回此錯誤，socket可以繼續使用。比如socket連線
原文釋出時間為：2018-09-10
本文作者：真實的歸宿