我們通過了解TCP各個狀態，可以排除和定位網絡或系統故障時大有幫助。（總結網絡上的內容）
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的進行抓包
首先服務端需要打開一個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開連接.:
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可靠的連接，每次通信都需要對方來確認。
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元組，這時候連接就可能接收到網絡上的延遲報文就可能干擾最新建立的連接。
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通信中服務器處理客戶端意外斷開
引用地址：http://blog.csdn.net/kkkkkxiaofei/article/details/12966407
如果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.
8. Linux錯誤信息(errno)列表
經常出現的錯誤：
22：參數錯誤，比如ip地址不合法，沒有目標端口等
101：網絡不可達，比如不能ping通
111：鏈接被拒絕，比如目標關閉鏈接等
115：當鏈接設置為非阻塞時，目標沒有及時應答，返回此錯誤，socket可以繼續使用。比如socket連接
附錄：Linux的錯誤碼表（errno table)
_ 124 EMEDIUMTYPE_ Wrong medium type _ 123 ENOMEDIUM__ No medium found _ 122 EDQUOT___ Disk quota exceeded _ 121 EREMOTEIO__ Remote I/O error _ 120 EISNAM___ Is a named type file _ 119 ENAVAIL___ No XENIX semaphores available _ 118 ENOTNAM___ Not a XENIX named type file _ 117 EUCLEAN___ Structure needs cleaning _ 116 ESTALE___ Stale NFS file handle _ 115 EINPROGRESS +Operation now in progress
操作正在進行中。一個阻塞的操作正在執行。
_ 114 EALREADY__ Operation already in progress _ 113 EHOSTUNREACH No route to host _ 112 EHOSTDOWN__ Host is down _ 111 ECONNREFUSED Connection refused
1、拒絕連接。一般發生在連接建立時。
拔服務器端網線測試，客戶端設置keep alive時，recv較快返回0， 先收到ECONNREFUSED (Connection refused)錯誤碼，其后都是ETIMEOUT。
2、an error returned from connect(), so it can only occur in a client (if a client is defined as the party that initiates the connection
_ 110 ETIMEDOUT_ +Connection timed out _ 109 ETOOMANYREFS Too many references: cannot splice _ 108 ESHUTDOWN__ Cannot send after transport endpoint shutdown _ 107 ENOTCONN__ Transport endpoint is not connected
在一個沒有建立連接的socket上，進行read，write操作會返回這個錯誤。出錯的原因是socket沒有標識地址。Setsoc也可能會出錯。
還有一種情況就是收到對方發送過來的RST包,系統已經確認連接被斷開了。
_ 106 EISCONN___ Transport endpoint is already connected
一般是socket客戶端已經連接了，但是調用connect，會引起這個錯誤。
_ 105 ENOBUFS___ No buffer sp_ 104 ECONNRESET_ Connection reset by peerace available
連接被遠程主機關閉。有以下幾種原因：遠程主機停止服務，重新啟動;當在執行某些操作時遇到失敗，因為設置了“keep alive”選項，連接被關閉，一般與ENETRESET一起出現。
1、在客戶端服務器程序中，客戶端異常退出，并沒有回收關閉相關的資源，服務器端會先收到ECONNRESET錯誤，然后收到EPIPE錯誤。
2、連接被遠程主機關閉。有以下幾種原因：遠程主機停止服務，重新啟動;當在執行某些操作時遇到失敗，因為設置了“keep alive”選項，連接被關閉，一般與ENETRESET一起出現。
3、遠程端執行了一個“hard”或者“abortive”的關閉。應用程序應該關閉socket，因為它不再可用。當執行在一個UDP socket上時，這個錯誤表明前一個send操作返回一個ICMP“port unreachable”信息。
4、如果client關閉連接,server端的select并不出錯(不返回-1,使用select對唯一一個socket進行non- blocking檢測),但是寫該socket就會出錯,用的是send.錯誤號:ECONNRESET.讀(recv)socket并沒有返回錯誤。
5、該錯誤被描述為“connection reset by peer”，即“對方復位連接”，這種情況一般發生在服務進程較客戶進程提前終止。當服務進程終止時會向客戶 TCP 發送 FIN 分節，客戶 TCP 回應 ACK，服務 TCP 將轉入 FIN_WAIT2 狀態。此時如果客戶進程沒有處理該 FIN （如阻塞在其它調用上而沒有關閉 Socket 時），則客戶 TCP 將處于 CLOSE_WAIT 狀態。當客戶進程再次向 FIN_WAIT2 狀態的服務 TCP 發送數據時，則服務 TCP 將立刻響應 RST。一般來說，這種情況還可以會引發另外的應用程序異常，客戶進程在發送完數據后，往往會等待從網絡IO接收數據，很典型的如 read 或 readline 調用，此時由于執行時序的原因，如果該調用發生在 RST 分節收到前執行的話，那么結果是客戶進程會得到一個非預期的 EOF 錯誤。此時一般會輸出“server terminated prematurely”－“服務器過早終止”錯誤。
_ 103 ECONNABORTED Software caused connection abort
1、軟件導致的連接取消。一個已經建立的連接被host方的軟件取消，原因可能是數據傳輸超時或者是協議錯誤。
2、該錯誤被描述為“software caused connection abort”，即“軟件引起的連接中止”。原因在于當服務和客戶進程在完成用于 TCP 連接的“三次握手”后，客戶 TCP 卻發送了一個 RST （復位）分節，在服務進程看來，就在該連接已由 TCP 排隊，等著服務進程調用 accept 的時候 RST 卻到達了。POSIX 規定此時的 errno 值必須 ECONNABORTED。源自 Berkeley 的實現完全在內核中處理中止的連接，服務進程將永遠不知道該中止的發生。服務器進程一般可以忽略該錯誤，直接再次調用accept。
當TCP協議接收到RST數據段，表示連接出現了某種錯誤，函數read將以錯誤返回，錯誤類型為ECONNERESET。并且以后所有在這個套接字上的讀操作均返回錯誤。錯誤返回時返回值小于0。
_ 102 ENETRESET__ Network dropped connection on reset
網絡重置時丟失連接。
由于設置了"keep-alive"選項，探測到一個錯誤，連接被中斷。在一個已經失敗的連接上試圖使用setsockopt操作，也會返回這個錯誤。
_ 101 ENETUNREACH_ Network is unreachable
網絡不可達。Socket試圖操作一個不可達的網絡。這意味著local的軟件知道沒有路由到達遠程的host。
_ 100 ENETDOWN__ Network is down_ 99 EADDRNOTAVAIL Cannot assign requested address_ 98 EADDRINUSE_ Address already in use_ 97 EAFNOSUPPORT Address family not supported by protocol_ 96 EPFNOSUPPORT Protocol family not supported_ 95 EOPNOTSUPP_ Operation not supported_ 94 ESOCKTNOSUPPORT Socket type not supported
Socket類型不支持。指定的socket類型在其address family中不支持。如可選選中選項SOCK_RAW，但實現并不支持SOCK_RAW sockets。
_ 93 EPROTONOSUPPORT Protocol not supported
不支持的協議。系統中沒有安裝標識的協議，或者是沒有實現。如函數需要SOCK_DGRAM socket，但是標識了stream protocol.。
_ 92 ENOPROTOOPT_ Protocol not available
該錯誤不是一個 Socket 連接相關的錯誤。errno 給出該值可能由于，通過 getsockopt 系統調用來獲得一個套接字的當前選項狀態時，如果發現了系統不支持的選項參數就會引發該錯誤。
_ 91 EPROTOTYPE_ Protocol wrong type for socket
協議類型錯誤。標識了協議的Socket函數在不支持的socket上進行操作。如ARPA Internet
UDP協議不能被標識為SOCK_STREAM socket類型。
_ 90 EMSGSIZE__ +Message too long
消息體太長。
發送到socket上的一個數據包大小比內部的消息緩沖區大，或者超過別的網絡限制，或是用來接收數據包的緩沖區比數據包本身小。
_ 89 EDESTADDRREQ Destination address required
需要提供目的地址。
在一個socket上的操作需要提供地址。如往一個ADDR_ANY 地址上進行sendto操作會返回這個錯誤。
_ 88 ENOTSOCK__ Socket operation on non-socket 在非socket上執行socket操作。 _ 87 EUSERS___ Too many users _ 86 ESTRPIPE__ Streams pipe error _ 85 ERESTART__ Interrupted system call should be restarted _ 84 EILSEQ___ Invalid or incomplete multibyte or wide character _ 83 ELIBEXEC__ Cannot exec a shared library directly _ 82 ELIBMAX___ Attempting to link in too many shared libraries _ 81 ELIBSCN___ .lib section in a.out corrupted _ 80 ELIBBAD___ Accessing a corrupted shared library _ 79 ELIBACC___ Can not access a needed shared library _ 78 EREMCHG___ Remote address changed _ 77 EBADFD___ File descriptor in bad state _ 76 ENOTUNIQ__ Name not unique on network _ 75 EOVERFLOW__ Value too large for defined data type _ 74 EBADMSG__ +Bad message _ 73 EDOTDOT___ RFS specific error _ 72 EMULTIHOP__ Multihop attempted _ 71 EPROTO___ Protocol error _ 70 ECOMM____ Communication error on send _ 69 ESRMNT___ Srmount error _ 68 EADV____ Advertise error _ 67 ENOLINK___ Link has been severed _ 66 EREMOTE___ Object is remote _ 65 ENOPKG___ Package not installed _ 64 ENONET___ Machine is not on the network _ 63 ENOSR____ Out of streams resources _ 62 ETIME____ Timer expired _ 61 ENODATA___ No data available _ 60 ENOSTR___ Device not a stream _ 59 EBFONT___ Bad font file format _ 57 EBADSLT___ Invalid slot _ 56 EBADRQC___ Invalid request code _ 55 ENOANO___ No anode _ 54 EXFULL___ Exchange full _ 53 EBADR____ Invalid request descriptor _ 52 EBADE____ Invalid exchange _ 51 EL2HLT___ Level 2 halted _ 50 ENOCSI___ No CSI structure available _ 49 EUNATCH___ Protocol driver not attached _ 48 ELNRNG___ Link number out of range _ 47 EL3RST___ Level 3 reset _ 46 EL3HLT___ Level 3 halted _ 45 EL2NSYNC__ Level 2 not synchronized _ 44 ECHRNG___ Channel number out of range _ 43 EIDRM____ Identifier removed _ 42 ENOMSG___ No message of desired type _ 40 ELOOP____ Too many levels of symbolic links _ 39 ENOTEMPTY_ +Directory not empty _ 38 ENOSYS___ +Function not implemented _ 37 ENOLCK___ +No locks available _ 36 ENAMETOOLONG +File name too long _ 35 EDEADLK__ +Resource deadlock avoided _ 34 ERANGE___ +Numerical result out of range _ 33 EDOM____ +Numerical argument out of domain _ 32 EPIPE___ +Broken pipe
接收端關閉(緩沖中沒有多余的數據),但是發送端還在write:
1、Socket 關閉，但是socket號并沒有置-1。繼續在此socket上進行send和recv，就會返回這種錯誤。這個錯誤會引發SIGPIPE信號，系統會將產生此EPIPE錯誤的進程殺死。所以，一般在網絡程序中，首先屏蔽此消息，以免發生不及時設置socket進程被殺死的情況。
2、write(..) on a socket that has been closed at the other end will cause a SIGPIPE.
3、錯誤被描述為“broken pipe”，即“管道破裂”，這種情況一般發生在客戶進程不理會（或未及時處理）Socket 錯誤，繼續向服務 TCP 寫入更多數據時，內核將向客戶進程發送 SIGPIPE 信號，該信號默認會使進程終止（此時該前臺進程未進行 core dump）。結合上邊的 ECONNRESET 錯誤可知，向一個 FIN_WAIT2 狀態的服務 TCP（已 ACK 響應 FIN 分節）寫入數據不成問題，但是寫一個已接收了 RST 的 Socket 則是一個錯誤。
_ 31 EMLINK___ +Too many links _ 30 EROFS___ +Read-only file system _ 29 ESPIPE___ +Illegal seek _ 28 ENOSPC___ +No space left on device _ 27 EFBIG___ +File too large _ 26 ETXTBSY___ Text file busy _ 25 ENOTTY___ +Inappropriate ioctl for device _ 24 EMFILE___ +Too many open files
打開了太多的socket。對進程或者線程而言，每種實現方法都有一個最大的可用socket數目處理，或者是全局的，或者是局部的。
_ 23 ENFILE___ +Too many open files in system _ 22 EINVAL___ +Invalid argument
無效參數。提供的參數非法。有時也會與socket的當前狀態相關，如一個socket并沒有進入listening狀態，此時調用accept，就會產生EINVAL錯誤。
_ 21 EISDIR___ +Is a directory _ 20 ENOTDIR__ +Not a directory _ 19 ENODEV___ +No such device _ 18 EXDEV___ +Invalid cross-device link _ 17 EEXIST___ +File exists _ 16 EBUSY___ +Device or resource busy _ 15 ENOTBLK___ Block device required _ 14 EFAULT___ +Bad address 地址錯誤 _ 13 EACCES___ +Permission denied _ 12 ENOMEM___ +Cannot allocate memory _ 11 EAGAIN___ +Resource temporarily unavailable
在讀數據的時候,沒有數據在底層緩沖的時候會遇到,一般的處理是循環進行讀操作,異步模式還會等待讀事件的發生再讀
1、Send返回值小于要發送的數據數目，會返回EAGAIN和EINTR。
2、recv 返回值小于請求的長度時說明緩沖區已經沒有可讀數據，但再讀不一定會觸發EAGAIN，有可能返回0表示TCP連接已被關閉。
3、當socket是非阻塞時,如返回此錯誤,表示寫緩沖隊列已滿,可以做延時后再重試.
4、在Linux進行非阻塞的socket接收數據時經常出現Resource temporarily unavailable，errno代碼為11(EAGAIN)，表明在非阻塞模式下調用了阻塞操作，在該操作沒有完成就返回這個錯誤，這個錯誤不會破壞socket的同步，不用管它，下次循環接著recv就可以。對非阻塞socket而言，EAGAIN不是一種錯誤。
_ 10 ECHILD___ +No child processes __ 9 EBADF___ +Bad file descriptor __ 8 ENOEXEC__ +Exec format error __ 7 E2BIG___ +Argument list too long __ 6 ENXIO___ +No such device or address __ 5 EIO____ +Input/output error __ 4 EINTR___ +Interrupted system call
阻塞的操作被取消阻塞的調用打斷。如設置了發送接收超時，就會遇到這種錯誤。
只能針對阻塞模式的socket。讀，寫阻塞的socket時，-1返回，錯誤號為INTR。另外，如果出現EINTR即errno為4，錯誤描述Interrupted system call，操作也應該繼續。如果recv的返回值為0，那表明連接已經斷開，接收操作也應該結束。
__ 3 ESRCH___ +No such process __ 2 ENOENT___ +No such file or directory __ 1 EPERM___ +Operation not permitted
轉自：http://blog.csdn.net/hguisu/article/details/38700899
原創文章，作者：s19930811，如若轉載，請注明出處：http://www.www58058.com/2499
