1、TCP狀態(tài)linux查看tcp的狀態(tài)命令：1）、netstat -nat? 查看TCP各個(gè)狀態(tài)的數(shù)量2）、lsof? -i:port? 可以檢測(cè)到打開(kāi)套接字的狀況3)、? sar -n SOCK 查看tcp創(chuàng)建的連接數(shù)4)、tcpdump -iany tcp port 9000 對(duì)tcp端口為9000的進(jìn)行抓包LISTENING：偵聽(tīng)來(lái)自遠(yuǎn)方的TCP端口的連接請(qǐng)求.? ? ? ? ? ? ? ? ? 首先服務(wù)端需要打開(kāi)一個(gè)socket進(jìn)行監(jiān)聽(tīng)，狀態(tài)為L(zhǎng)ISTEN。? ? 有提供某種服務(wù)才會(huì)處于LISTENING狀態(tài)，TCP狀態(tài)變化就是某個(gè)端口的狀態(tài)變化，提供一個(gè)服務(wù)就打開(kāi)一個(gè)端口，例如：提供www服務(wù)默認(rèn)開(kāi)的是80端口，提供ftp服務(wù)默認(rèn)的端口為21，當(dāng)提供的服務(wù)沒(méi)有被連接時(shí)就處于LISTENING狀態(tài)。FTP服務(wù)啟動(dòng)后首先處于偵聽(tīng)（LISTENING）狀態(tài)。處于偵聽(tīng)LISTENING狀態(tài)時(shí)，該端口是開(kāi)放的，等待連接，但還沒(méi)有被連接。就像你房子的門(mén)已經(jīng)敞開(kāi)的，但還沒(méi)有人進(jìn)來(lái)。? ? 看LISTENING狀態(tài)最主要的是看本機(jī)開(kāi)了哪些端口，這些端口都是哪個(gè)程序開(kāi)的，關(guān)閉不必要的端口是保證安全的一個(gè)非常重要的方面，服務(wù)端口都對(duì)應(yīng)一個(gè)服務(wù)（應(yīng)用程序），停止該服務(wù)就關(guān)閉了該端口，例如要關(guān)閉21端口只要停止IIS服務(wù)中的FTP服務(wù)即可。關(guān)于這方面的知識(shí)請(qǐng)參閱其它文章。? ? 如果你不幸中了服務(wù)端口的木馬，木馬也開(kāi)個(gè)端口處于LISTENING狀態(tài)。SYN-SENT：客戶(hù)端SYN_SENT狀態(tài)：? ? ? ? 再發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求:客戶(hù)端通過(guò)應(yīng)用程序調(diào)用connect進(jìn)行active open.于是客戶(hù)端tcp發(fā)送一個(gè)SYN以請(qǐng)求建立一個(gè)連接.之后狀態(tài)置為SYN_SENT. /*The socket is actively attempting to establish a connection. 在發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求 */? ? 當(dāng)請(qǐng)求連接時(shí)客戶(hù)端首先要發(fā)送同步信號(hào)給要訪(fǎng)問(wèn)的機(jī)器，此時(shí)狀態(tài)為SYN_SENT，如果連接成功了就變?yōu)镋STABLISHED，正常情況下SYN_SENT狀態(tài)非常短暫。例如要訪(fǎng)問(wèn)網(wǎng)站http://www.baidu.com,如果是正常連接的話(huà)，用TCPView觀察IEXPLORE.EXE（IE）建立的連接會(huì)發(fā)現(xiàn)很快從SYN_SENT變?yōu)镋STABLISHED，表示連接成功。SYN_SENT狀態(tài)快的也許看不到。? ? 如果發(fā)現(xiàn)有很多SYN_SENT出現(xiàn)，那一般有這么幾種情況，一是你要訪(fǎng)問(wèn)的網(wǎng)站不存在或線(xiàn)路不好，二是用掃描軟件掃描一個(gè)網(wǎng)段的機(jī)器，也會(huì)出出現(xiàn)很多SYN_SENT，另外就是可能中了病毒了，例如中了"沖擊波"，病毒發(fā)作時(shí)會(huì)掃描其它機(jī)器，這樣會(huì)有很多SYN_SENT出現(xiàn)。SYN-RECEIVED：服務(wù)器端狀態(tài)SYN_RCVD? ? ? ? ? 再收到和發(fā)送一個(gè)連接請(qǐng)求后等待對(duì)方對(duì)連接請(qǐng)求的確認(rèn)? 當(dāng)服務(wù)器收到客戶(hù)端發(fā)送的同步信號(hào)時(shí)，將標(biāo)志位ACK和SYN置1發(fā)送給客戶(hù)端，此時(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連接請(qǐng)求（握手的第一步），但是這個(gè)地址是偽造的，如攻擊軟件隨機(jī)偽造了51.133.163.104、65.158.99.152等等地址。服務(wù)器在收到連接請(qǐng)求時(shí)將標(biāo)志位ACK和SYN置1發(fā)送給客戶(hù)端（握手的第二步），但是這些客戶(hù)端的IP地址都是偽造的，服務(wù)器根本找不到客戶(hù)機(jī)，也就是說(shuō)握手的第三步不可能完成。? ? 這種情況下服務(wù)器端一般會(huì)重試（再次發(fā)送SYN+ACK給客戶(hù)端）并等待一段時(shí)間后丟棄這個(gè)未完成的連接，這段時(shí)間的長(zhǎng)度我們稱(chēng)為SYN Timeout，一般來(lái)說(shuō)這個(gè)時(shí)間是分鐘的數(shù)量級(jí)（大約為30秒-2分鐘）；一個(gè)用戶(hù)出現(xiàn)異常導(dǎo)致服務(wù)器的一個(gè)線(xiàn)程等待1分鐘并不是什么很大的問(wèn)題，但如果有一個(gè)惡意的攻擊者大量模擬這種情況，服務(wù)器端將為了維護(hù)一個(gè)非常大的半連接列表而消耗非常多的資源----數(shù)以萬(wàn)計(jì)的半連接，即使是簡(jiǎn)單的保存并遍歷也會(huì)消耗非常多的CPU時(shí)間和內(nèi)存，何況還要不斷對(duì)這個(gè)列表中的IP進(jìn)行SYN+ACK的重試。此時(shí)從正?？蛻?hù)的角度看來(lái)，服務(wù)器失去響應(yīng)，這種情況我們稱(chēng)做：服務(wù)器端受到了SYN Flood攻擊（SYN洪水攻擊）ESTABLISHED：代表一個(gè)打開(kāi)的連接。? ? ESTABLISHED狀態(tài)是表示兩臺(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可以檢測(cè)到。? ? ? 當(dāng)客戶(hù)端未主動(dòng)close的時(shí)候就斷開(kāi)連接：即客戶(hù)端發(fā)送的FIN丟失或未發(fā)送。? ? ? ? 這時(shí)候若客戶(hù)端斷開(kāi)的時(shí)候發(fā)送了FIN包，則服務(wù)端將會(huì)處于CLOSE_WAIT狀態(tài)；? ? ? ? 這時(shí)候若客戶(hù)端斷開(kāi)的時(shí)候未發(fā)送FIN包，則服務(wù)端處還是顯示ESTABLISHED狀態(tài)；? ? ? ? ? 結(jié)果客戶(hù)端重新連接服務(wù)器。? ? ? ? ? 而新連接上來(lái)的客戶(hù)端（也就是剛才斷掉的重新連上來(lái)了）在服務(wù)端肯定是ESTABLISHED; 如果客戶(hù)端重復(fù)的上演這種情況，那么服務(wù)端將會(huì)出現(xiàn)大量的假的ESTABLISHED連接和CLOSE_WAIT連接。? ? ? ? 最終結(jié)果就是新的其他客戶(hù)端無(wú)法連接上來(lái)，但是利用netstat還是能看到一條連接已經(jīng)建立，并顯示ESTABLISHED，但始終無(wú)法進(jìn)入程序代碼。FIN-WAIT-1：等待遠(yuǎn)程TCP連接中斷請(qǐng)求，或先前的連接中斷請(qǐng)求的確認(rèn)? ? ? 主動(dòng)關(guān)閉(active close)端應(yīng)用程序調(diào)用close，于是其TCP發(fā)出FIN請(qǐng)求主動(dòng)關(guān)閉連接，之后進(jìn)入FIN_WAIT1狀態(tài)./* The socket is closed, and the connection is shutting down. 等待遠(yuǎn)程TCP的連接中斷請(qǐng)求，或先前的連接中斷請(qǐng)求的確認(rèn) */? ? ? 如果服務(wù)器出現(xiàn)shutdown再重啟，使用netstat -nat查看，就會(huì)看到很多FIN-WAIT-1的狀態(tài)。就是因?yàn)榉?wù)器當(dāng)前有很多客戶(hù)端連接，直接關(guān)閉服務(wù)器后，無(wú)法接收到客戶(hù)端的ACK。FIN-WAIT-2：從遠(yuǎn)程TCP等待連接中斷請(qǐng)求? ? ? 主動(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等待連接中斷請(qǐng)求 */? ? ? ? 這就是著名的半關(guān)閉的狀態(tài)了，這是在關(guān)閉連接時(shí)，客戶(hù)端和服務(wù)器兩次握手之后的狀態(tài)。在這個(gè)狀態(tài)下，應(yīng)用程序還有接受數(shù)據(jù)的能力，但是已經(jīng)無(wú)法發(fā)送數(shù)據(jù)，但是也有一種可能是，客戶(hù)端一直處于FIN_WAIT_2狀態(tài)，而服務(wù)器則一直處于WAIT_CLOSE狀態(tài)，而直到應(yīng)用層來(lái)決定關(guān)閉這個(gè)狀態(tài)。CLOSE-WAIT：等待從本地用戶(hù)發(fā)來(lái)的連接中斷請(qǐng)求? ? ? ? 被動(dòng)關(guān)閉(passive close)端TCP接到FIN后，就發(fā)出ACK以回應(yīng)FIN請(qǐng)求(它的接收也作為文件結(jié)束符傳遞給上層應(yīng)用程序),并進(jìn)入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待從本地用戶(hù)發(fā)來(lái)的連接中斷請(qǐng)求 */? ? ? CLOSING：等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn)比較少見(jiàn)./* Both sockets are shut down but we still don't have all our data sent. 等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn) */LAST-ACK：等待原來(lái)的發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn)被動(dòng)關(guān)閉端一段時(shí)間后，接收到文件結(jié)束符的應(yīng)用程序?qū)⒄{(diào)用CLOSE關(guān)閉連接。這導(dǎo)致它的TCP也發(fā)送一個(gè) FIN,等待對(duì)方的ACK.就進(jìn)入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原來(lái)發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn) */使用并發(fā)壓力測(cè)試的時(shí)候，突然斷開(kāi)壓力測(cè)試客戶(hù)端，服務(wù)器會(huì)看到很多LAST-ACK。TIME-WAIT：等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請(qǐng)求的確認(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接收到連接中斷請(qǐng)求的確認(rèn) */? ? ? ? ? ? TIME_WAIT等待狀態(tài)，這個(gè)狀態(tài)又叫做2MSL狀態(tài)，說(shuō)的是在TIME_WAIT2發(fā)送了最后一個(gè)ACK數(shù)據(jù)報(bào)以后，要進(jìn)入TIME_WAIT狀態(tài)，這個(gè)狀態(tài)是防止最后一次握手的數(shù)據(jù)報(bào)沒(méi)有傳送到對(duì)方那里而準(zhǔn)備的（注意這不是四次握手，這是第四次握手的保險(xiǎn)狀態(tài)）。這個(gè)狀態(tài)在很大程度上保證了雙方都可以正常結(jié)束，但是，問(wèn)題也來(lái)了。由于插口的2MSL狀態(tài)（插口是IP和端口對(duì)的意思，socket），使得應(yīng)用程序在2MSL時(shí)間內(nèi)是無(wú)法再次使用同一個(gè)插口的，對(duì)于客戶(hù)程序還好一些，但是對(duì)于服務(wù)程序，例如httpd，它總是要使用同一個(gè)端口來(lái)進(jìn)行服務(wù)，而在2MSL時(shí)間內(nèi)，啟動(dòng)httpd就會(huì)出現(xiàn)錯(cuò)誤（插口被使用）。為了避免這個(gè)錯(cuò)誤，服務(wù)器給出了一個(gè)平靜時(shí)間的概念，這是說(shuō)在2MSL時(shí)間內(nèi)，雖然可以重新啟動(dòng)服務(wù)器，但是這個(gè)服務(wù)器還是要平靜的等待2MSL時(shí)間的過(guò)去才能進(jìn)行下一次連接。? ? ? ? ? ? ? ? ? 詳情請(qǐng)看：TIME_WAIT引起Cannot assign requested address報(bào)錯(cuò)CLOSED：沒(méi)有任何連接狀態(tài)被動(dòng)關(guān)閉端在接受到ACK包后，就進(jìn)入了closed的狀態(tài)。連接結(jié)束./* The socket is not being used. 沒(méi)有任何連接狀態(tài) */? ? ? ? 2、TCP狀態(tài)遷移路線(xiàn)圖client/server兩條路線(xiàn)講述TCP狀態(tài)遷移路線(xiàn)圖：? ? ? ? 這是一個(gè)看起來(lái)比較復(fù)雜的狀態(tài)遷移圖，因?yàn)樗藘蓚€(gè)部分---服務(wù)器的狀態(tài)遷移和客戶(hù)端的狀態(tài)遷移，如果從某一個(gè)角度出發(fā)來(lái)看這個(gè)圖，就會(huì)清晰許多，這里面的服務(wù)器和客戶(hù)端都不是絕對(duì)的，發(fā)送數(shù)據(jù)的就是客戶(hù)端，接受數(shù)據(jù)的就是服務(wù)器。 客戶(hù)端應(yīng)用程序的狀態(tài)遷移圖? ? ? ? 客戶(hù)端的狀態(tài)可以用如下的流程來(lái)表示：? ? ? ? CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED? ? ? ? 以上流程是在程序正常的情況下應(yīng)該有的流程，從書(shū)中的圖中可以看到，在建立連接時(shí)，當(dāng)客戶(hù)端收到SYN報(bào)文的ACK以后，客戶(hù)端就打開(kāi)了數(shù)據(jù)交互地連接。而結(jié)束連接則通常是客戶(hù)端主動(dòng)結(jié)束的，客戶(hù)端結(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)可以用如下的流程來(lái)表示：? ? ? ? CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED? ? ? ? 在建立連接的時(shí)候，服務(wù)器端是在第三次握手之后才進(jìn)入數(shù)據(jù)交互狀態(tài)，而關(guān)閉連接則是在關(guān)閉連接的第二次握手以后（注意不是第四次）。而關(guān)閉以后還要等待客戶(hù)端給出最后的ACK包才能進(jìn)入初始的狀態(tài)。 其他狀態(tài)遷移還有一些其他的狀態(tài)遷移，這些狀態(tài)遷移針對(duì)服務(wù)器和客戶(hù)端兩方面的總結(jié)如下LISTEN->SYN_SENT，對(duì)于這個(gè)解釋就很簡(jiǎn)單了，服務(wù)器有時(shí)候也要打開(kāi)連接的嘛。SYN_SENT->SYN收到，服務(wù)器和客戶(hù)端在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)入ESTABLISHEDSYN_SENT->CLOSED，在發(fā)送超時(shí)的情況下，會(huì)返回到CLOSED狀態(tài)。SYN_收到->LISTEN，如果受到RST包，會(huì)返回到LISTEN狀態(tài)。SYN_收到->FIN_WAIT_1，這個(gè)遷移是說(shuō)，可以不用到ESTABLISHED狀態(tài)，而可以直接跳轉(zhuǎn)到FIN_WAIT_1狀態(tài)并等待關(guān)閉。? 怎樣牢牢地將這張圖刻在腦中呢？那么你就一定要對(duì)這張圖的每一個(gè)狀態(tài)，及轉(zhuǎn)換的過(guò)程有深刻的認(rèn)識(shí)，不能只停留在一知半解之中。下面對(duì)這張圖的11種狀態(tài)詳細(xì)解析一下，以便加強(qiáng)記憶！不過(guò)在這之前，先回顧一下TCP建立連接的三次握手過(guò)程，以及關(guān)閉連接的四次握手過(guò)程。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è)連接四元組，客戶(hù)端發(fā)送一個(gè)帶SYN標(biāo)志的TCP報(bào)文到服務(wù)器。這是三次握手過(guò)程中的報(bào)文1。connect調(diào)用讓Client端的socket處于SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)；SYN：同步序列編號(hào)(Synchronize Sequence Numbers)。? ? ? ( 2)第二次握手： 服務(wù)器收到syn包，必須確認(rèn)客戶(hù)的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；? ? ? ( 3)? 第三次握手：客戶(hù)端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶(hù)器和客務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。連接已經(jīng)可以進(jìn)行讀寫(xiě)操作。一個(gè)完整的三次握手也就是： 請(qǐng)求---應(yīng)答---再次確認(rèn)。TCP協(xié)議通過(guò)三個(gè)報(bào)文段完成連接的建立，這個(gè)過(guò)程稱(chēng)為三次握手(three-way handshake)，過(guò)程如下圖所示。對(duì)應(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)聽(tīng)套接字? ? ? Server端調(diào)用bind操作，將監(jiān)聽(tīng)套接字與指定的地址和端口關(guān)聯(lián)，然后又調(diào)用listen函數(shù)，系統(tǒng)會(huì)為其分配未完成隊(duì)列和完成隊(duì)列，此時(shí)的監(jiān)聽(tīng)套接字可以接受Client的連接，監(jiān)聽(tīng)套接字狀態(tài)處于LISTEN狀態(tài)。? ? 當(dāng)Server端調(diào)用accept操作時(shí)，會(huì)從完成隊(duì)列中取出一個(gè)已經(jīng)完成的client連接，同時(shí)在server這段會(huì)產(chǎn)生一個(gè)會(huì)話(huà)套接字，用于和client端套接字的通信，這個(gè)會(huì)話(huà)套接字的狀態(tài)是ESTABLISH。從圖中可以看出，當(dāng)客戶(hù)端調(diào)用connect時(shí)，觸發(fā)了連接請(qǐng)求，向服務(wù)器發(fā)送了SYN J包，這時(shí)connect進(jìn)入阻塞狀態(tài)；服務(wù)器監(jiān)聽(tīng)到連接請(qǐng)求，即收到SYN J包，調(diào)用accept函數(shù)接收請(qǐng)求向客戶(hù)端發(fā)送SYN K ，ACK J+1，這時(shí)accept進(jìn)入阻塞狀態(tài)；客戶(hù)端收到服務(wù)器的SYN K ，ACK J+1之后，這時(shí)connect返回，并對(duì)SYN K進(jìn)行確認(rèn)；服務(wù)器收到ACK K+1時(shí)，accept返回，至此三次握手完畢，連接建立。我們可以通過(guò)網(wǎng)絡(luò)抓包的查看具體的流程：比如我們服務(wù)器開(kāi)啟9502的端口。使用tcpdump來(lái)抓包： tcpdump -iany tcp port 9502然后我們使用telnet 127.0.0.1 9502開(kāi)連接.:telnet 127.0.0.1 950214: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 714:13:01.415432 IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 014: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 1814: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客戶(hù)端IP localhost.39870 (客戶(hù)端的端口一般是自動(dòng)分配的) 向服務(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包，必須確認(rèn)客戶(hù)的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包SYN（ack=j+1）=ack 2927179379? ? 服務(wù)器主機(jī)SYN包（syn=seq 1721825043）第三次握手：14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,客戶(hù)端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)客戶(hù)端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)后，可以進(jìn)行通信數(shù)據(jù)交互。此時(shí)和accept接口沒(méi)有關(guān)系，即使沒(méi)有accepte，也進(jìn)行3次握手完成。連接出現(xiàn)連接不上的問(wèn)題，一般是網(wǎng)路出現(xiàn)問(wèn)題或者網(wǎng)卡超負(fù)荷或者是連接數(shù)已經(jīng)滿(mǎn)啦。紫色背景的部分：IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7客戶(hù)端向服務(wù)器發(fā)送長(zhǎng)度為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ù)器向客戶(hù)確認(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í)向客戶(hù)端寫(xiě)入數(shù)據(jù)。 IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0客戶(hù)端向服務(wù)器確認(rèn)已經(jīng)收到數(shù)據(jù)這個(gè)就是tcp可靠的連接，每次通信都需要對(duì)方來(lái)確認(rèn)。4. TCP連接的終止（四次握手釋放）　 　由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(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)過(guò)四次握手，這是由TCP的半關(guān)閉(half-close)造成的，如圖：（1）客戶(hù)端A發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶(hù)A到服務(wù)器B的數(shù)據(jù)傳送（報(bào)文段4）。（2）服務(wù)器B收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。（3）服務(wù)器B關(guān)閉與客戶(hù)端A的連接，發(fā)送一個(gè)FIN給客戶(hù)端A（報(bào)文段6）。（4）客戶(hù)端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）。對(duì)應(yīng)函數(shù)接口如圖：調(diào)用過(guò)程如下：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)閉。對(duì)這個(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端檢測(cè)到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)為L(zhǎng)AST_ACK。4)? 當(dāng)client收到來(lái)自server的FIN后 。 client端的套接字處于TIME_WAIT狀態(tài)，它會(huì)向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)文的建連請(qǐng)求后，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個(gè)報(bào)文里來(lái)發(fā)送。但關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文通知時(shí)，它僅僅表示對(duì)方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對(duì)方了，所以你可以未必會(huì)馬上會(huì)關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對(duì)方之后，再發(fā)送FIN報(bào)文給對(duì)方來(lái)表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開(kāi)發(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)閉端會(huì)重發(fā)FIN，因此主動(dòng)關(guān)閉端需要維持狀態(tài)信息，以允許它重新發(fā)送最終的ACK。另一方面，但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的，你無(wú)法保證你最后發(fā)送的ACK報(bào)文會(huì)一定被對(duì)方收到，因此對(duì)方處于LAST_ACK狀態(tài)下的SOCKET可能會(huì)因?yàn)槌瑫r(shí)未收到ACK報(bào)文，而重發(fā)FIN報(bào)文，所以這個(gè)TIME_WAIT狀態(tài)的作用就是用來(lái)重發(fā)可能丟失的ACK報(bào)文。TCP在2MSL等待期間，定義這個(gè)連接(4元組)不能再使用，任何遲到的報(bào)文都會(huì)丟棄。設(shè)想如果沒(méi)有2MSL的限制，恰好新到的連接正好滿(mǎn)足原先的4元組，這時(shí)候連接就可能接收到網(wǎng)絡(luò)上的延遲報(bào)文就可能干擾最新建立的連接。5、同時(shí)打開(kāi)? ? ? ? 兩個(gè)應(yīng)用程序同時(shí)執(zhí)行主動(dòng)打開(kāi)的情況是可能的，雖然發(fā)生的可能性較低。每一端都發(fā)送一個(gè)SYN,并傳遞給對(duì)方，且每一端都使用對(duì)端所知的端口作為本地端口。例如：主機(jī)a中一應(yīng)用程序使用7777作為本地端口，并連接到主機(jī)b 8888端口做主動(dòng)打開(kāi)。主機(jī)b中一應(yīng)用程序使用8888作為本地端口，并連接到主機(jī)a 7777端口做主動(dòng)打開(kāi)。tcp協(xié)議在遇到這種情況時(shí)，只會(huì)打開(kāi)一條連接。這個(gè)連接的建立過(guò)程需要4次數(shù)據(jù)交換，而一個(gè)典型的連接建立只需要3次交換（即3次握手）但多數(shù)伯克利版的tcp/ip實(shí)現(xiàn)并不支持同時(shí)打開(kāi)。6、同時(shí)關(guān)閉如果應(yīng)用程序同時(shí)發(fā)送FIN，則在發(fā)送后會(huì)首先進(jìn)入FIN_WAIT_1狀態(tài)。在收到對(duì)端的FIN后，回復(fù)一個(gè)ACK，會(huì)進(jìn)入CLOSING狀態(tài)。在收到對(duì)端的ACK后，進(jìn)入TIME_WAIT狀態(tài)。這種情況稱(chēng)為同時(shí)關(guān)閉。同時(shí)關(guān)閉也需要有4次報(bào)文交換，與典型的關(guān)閉相同。 7. TCP通信中服務(wù)器處理客戶(hù)端意外斷開(kāi)引用地址：http://blog.csdn.net/kkkkkxiaofei/article/details/12966407? ? ? 如果TCP連接被對(duì)方正常關(guān)閉，也就是說(shuō)，對(duì)方是正確地調(diào)用了closesocket(s)或者shutdown(s)的話(huà)，那么上面的Recv或Send調(diào)用就能馬上返回，并且報(bào)錯(cuò)。這是由于close socket(s)或者shutdown(s)有個(gè)正常的關(guān)閉過(guò)程，會(huì)告訴對(duì)方“TCP連接已經(jīng)關(guān)閉，你不需要再發(fā)送或者接受消息了”。但是，如果意外斷開(kāi)，客戶(hù)端（3g的移動(dòng)設(shè)備）并沒(méi)有正常關(guān)閉socket。雙方并未按照協(xié)議上的四次揮手去斷開(kāi)連接。那么這時(shí)候正在執(zhí)行Recv或Send操作的一方就會(huì)因?yàn)闆](méi)有任何連接中斷的通知而一直等待下去，也就是會(huì)被長(zhǎng)時(shí)間卡住。? ? ? ? ? ? ? 像這種如果一方已經(jīng)關(guān)閉或異常終止連接，而另一方卻不知道，我們將這樣的TCP連接稱(chēng)為半打開(kāi)的。? ? ? 解決意外中斷辦法都是利用?；顧C(jī)制。而?；顧C(jī)制分又可以讓底層實(shí)現(xiàn)也可自己實(shí)現(xiàn)。? ? 1、自己編寫(xiě)心跳包程序? ? 簡(jiǎn)單的說(shuō)也就是在自己的程序中加入一條線(xiàn)程，定時(shí)向?qū)Χ税l(fā)送數(shù)據(jù)包，查看是否有ACK，如果有則連接正常，沒(méi)有的話(huà)則連接斷開(kāi)? ? 2、啟動(dòng)TCP編程里的keepAlive機(jī)制一、雙方擬定心跳（自實(shí)現(xiàn)）? ? 一般由客戶(hù)端發(fā)送心跳包，服務(wù)端并不回應(yīng)心跳，只是定時(shí)輪詢(xún)判斷一下與上次的時(shí)間間隔是否超時(shí)（超時(shí)時(shí)間自己設(shè)定）。服務(wù)器并不主動(dòng)發(fā)送是不想增添服務(wù)器的通信量，減少壓力。但這會(huì)出現(xiàn)三種情況：情況1.? ? ? 客戶(hù)端由于某種網(wǎng)絡(luò)延遲等原因很久后才發(fā)送心跳（它并沒(méi)有斷），這時(shí)服務(wù)器若利用自身設(shè)定的超時(shí)判斷其已經(jīng)斷開(kāi)，而后去關(guān)閉socket。若客戶(hù)端有重連機(jī)制，則客戶(hù)端會(huì)重新連接。若不確定這種方式是否關(guān)閉了原本正常的客戶(hù)端，則在ShutDown的時(shí)候一定要選擇send,表示關(guān)閉發(fā)送通道，服務(wù)器還可以接收一下，萬(wàn)一客戶(hù)端正在發(fā)送比較重要的數(shù)據(jù)呢，是不？情況2.? ? ? 客戶(hù)端很久沒(méi)傳心跳，確實(shí)是自身斷掉了。在其重啟之前，服務(wù)端已經(jīng)判斷出其超時(shí)，并主動(dòng)close，則四次揮手成功交互。情況3.? ? ? 客戶(hù)端很久沒(méi)傳心跳，確實(shí)是自身斷掉了。在其重啟之前，服務(wù)端的輪詢(xún)還未判斷出其超時(shí)，在未主動(dòng)close的時(shí)候該客戶(hù)端已經(jīng)重新連接。? ? ? 這時(shí)候若客戶(hù)端斷開(kāi)的時(shí)候發(fā)送了FIN包，則服務(wù)端將會(huì)處于CLOSE_WAIT狀態(tài)；? ? ? 這時(shí)候若客戶(hù)端斷開(kāi)的時(shí)候未發(fā)送FIN包，則服務(wù)端處還是顯示ESTABLISHED狀態(tài)；? ? ? 而新連接上來(lái)的客戶(hù)端（也就是剛才斷掉的重新連上來(lái)了）在服務(wù)端肯定是ESTABLISHED;這時(shí)候就有個(gè)問(wèn)題，若利用輪詢(xún)還未檢測(cè)出上條舊連接已經(jīng)超時(shí)（這很正常，timer總有個(gè)間隔吧），而在這時(shí)，客戶(hù)端又重復(fù)的上演情況3，那么服務(wù)端將會(huì)出現(xiàn)大量的假的ESTABLISHED連接和CLOSE_WAIT連接。? ? ? ? 最終結(jié)果就是新的其他客戶(hù)端無(wú)法連接上來(lái)，但是利用netstat還是能看到一條連接已經(jīng)建立，并顯示ESTABLISHED，但始終無(wú)法進(jìn)入程序代碼。個(gè)人最初感覺(jué)導(dǎo)致這種情況是因?yàn)榧俚腅STABLISHED連接和CLOSE_WAIT連接會(huì)占用較大的系統(tǒng)資源，程序無(wú)法再次創(chuàng)建連接（因?yàn)槊看挝野l(fā)現(xiàn)這個(gè)問(wèn)題的時(shí)候我只連了10個(gè)左右客戶(hù)端卻已經(jīng)有40多條無(wú)效連接）。而最近幾天測(cè)試卻發(fā)現(xiàn)有一次程序內(nèi)只連接了2，3個(gè)設(shè)備，但是有8條左右的虛連接，此時(shí)已經(jīng)連接不了新客戶(hù)端了。這時(shí)候我就覺(jué)得我想錯(cuò)了，不可能這幾條連接就占用了大量連接把，如果說(shuō)幾十條還有可能。但是能肯定的是，這個(gè)問(wèn)題的產(chǎn)生絕對(duì)是設(shè)備在不停的重啟，而服務(wù)器這邊又是簡(jiǎn)單的輪詢(xún)，并不能及時(shí)處理，暫時(shí)還未能解決。二、利用KeepAlive? ? ? ? ? 其實(shí)keepalive的原理就是TCP內(nèi)嵌的一個(gè)心跳包,? ? ? ? 以服務(wù)器端為例，如果當(dāng)前server端檢測(cè)到超過(guò)一定時(shí)間（默認(rèn)是 7,200,000 milliseconds，也就是2個(gè)小時(shí)）沒(méi)有數(shù)據(jù)傳輸，那么會(huì)向client端發(fā)送一個(gè)keep-alive packet（該keep-alive packet就是ACK和當(dāng)前TCP序列號(hào)減一的組合），此時(shí)client端應(yīng)該為以下三種情況之一：? ? ? ? 1. client端仍然存在，網(wǎng)絡(luò)連接狀況良好。此時(shí)client端會(huì)返回一個(gè)ACK。server端接收到ACK后重置計(jì)時(shí)器（復(fù)位存活定時(shí)器），在2小時(shí)后再發(fā)送探測(cè)。如果2小時(shí)內(nèi)連接上有數(shù)據(jù)傳輸，那么在該時(shí)間基礎(chǔ)上向后推延2個(gè)小時(shí)。? ? ? ? 2. 客戶(hù)端異常關(guān)閉，或是網(wǎng)絡(luò)斷開(kāi)。在這兩種情況下，client端都不會(huì)響應(yīng)。服務(wù)器沒(méi)有收到對(duì)其發(fā)出探測(cè)的響應(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. 客戶(hù)端曾經(jīng)崩潰，但已經(jīng)重啟。這種情況下，服務(wù)器將會(huì)收到對(duì)其存活探測(cè)的響應(yīng)，但該響應(yīng)是一個(gè)復(fù)位，從而引起服務(wù)器對(duì)連接的終止。? ? ? 對(duì)于應(yīng)用程序來(lái)說(shuō)，2小時(shí)的空閑時(shí)間太長(zhǎng)。因此，我們需要手工開(kāi)啟Keepalive功能并設(shè)置合理的Keepalive參數(shù)。全局設(shè)置可更改/etc/sysctl.conf,加上:net.ipv4.tcp_keepalive_intvl = 20net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_keepalive_time = 60在程序中設(shè)置如下:[cpp] view plain copy print?在CODE上查看代碼片派生到我的代碼片#include#include#include#include#includeint keepAlive = 1; // 開(kāi)啟keepalive屬性

int keepIdle = 60; // 如該連接在60秒內(nèi)沒(méi)有任何數(shù)據(jù)往來(lái),則進(jìn)行探測(cè)

int keepInterval = 5; // 探測(cè)時(shí)發(fā)包的時(shí)間間隔為5 秒

int keepCount = 3; // 探測(cè)嘗試的次數(shù).如果第1次探測(cè)包就收到響應(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檢測(cè)到對(duì)端socket不再可用時(shí)(不能發(fā)出探測(cè)包,或探測(cè)包沒(méi)有收到ACK的響應(yīng)包),select會(huì)返回socket可讀,并且在recv時(shí)返回-1,同時(shí)置上errno為ETIMEDOUT.

8. Linux錯(cuò)誤信息(errno)列表

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

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

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

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

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

附錄：Linux的錯(cuò)誤碼表（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

操作正在進(jìn)行中。一個(gè)阻塞的操作正在執(zhí)行。

_ 114 EALREADY__? Operation already in progress

_ 113 EHOSTUNREACH? No route to host

_ 112 EHOSTDOWN__ Host is down

_ 111 ECONNREFUSED? Connection refused

1、拒絕連接。一般發(fā)生在連接建立時(shí)。

拔服務(wù)器端網(wǎng)線(xiàn)測(cè)試，客戶(hù)端設(shè)置keep alive時(shí)，recv較快返回0， 先收到ECONNREFUSED (Connection refused)錯(cuò)誤碼，其后都是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

在一個(gè)沒(méi)有建立連接的socket上，進(jìn)行read，write操作會(huì)返回這個(gè)錯(cuò)誤。出錯(cuò)的原因是socket沒(méi)有標(biāo)識(shí)地址。Setsoc也可能會(huì)出錯(cuò)。

還有一種情況就是收到對(duì)方發(fā)送過(guò)來(lái)的RST包,系統(tǒng)已經(jīng)確認(rèn)連接被斷開(kāi)了。

_ 106 EISCONN___ Transport endpoint is already connected

一般是socket客戶(hù)端已經(jīng)連接了，但是調(diào)用connect，會(huì)引起這個(gè)錯(cuò)誤。

_ 105 ENOBUFS___ No buffer space available

_ 104 ECONNRESET_? Connection reset by peer

連接被遠(yuǎn)程主機(jī)關(guān)閉。有以下幾種原因：遠(yuǎn)程主機(jī)停止服務(wù)，重新啟動(dòng);當(dāng)在執(zhí)行某些操作時(shí)遇到失敗，因?yàn)樵O(shè)置了“keep alive”選項(xiàng)，連接被關(guān)閉，一般與ENETRESET一起出現(xiàn)。

1、在客戶(hù)端服務(wù)器程序中，客戶(hù)端異常退出，并沒(méi)有回收關(guān)閉相關(guān)的資源，服務(wù)器端會(huì)先收到ECONNRESET錯(cuò)誤，然后收到EPIPE錯(cuò)誤。

2、連接被遠(yuǎn)程主機(jī)關(guān)閉。有以下幾種原因：遠(yuǎn)程主機(jī)停止服務(wù)，重新啟動(dòng);當(dāng)在執(zhí)行某些操作時(shí)遇到失敗，因?yàn)樵O(shè)置了“keep alive”選項(xiàng)，連接被關(guān)閉，一般與ENETRESET一起出現(xiàn)。

3、遠(yuǎn)程端執(zhí)行了一個(gè)“hard”或者“abortive”的關(guān)閉。應(yīng)用程序應(yīng)該關(guān)閉socket，因?yàn)樗辉倏捎?。?dāng)執(zhí)行在一個(gè)UDP socket上時(shí)，這個(gè)錯(cuò)誤表明前一個(gè)send操作返回一個(gè)ICMP“port unreachable”信息。

4、如果client關(guān)閉連接,server端的select并不出錯(cuò)(不返回-1,使用select對(duì)唯一一個(gè)socket進(jìn)行non- blocking檢測(cè)),但是寫(xiě)該socket就會(huì)出錯(cuò),用的是send.錯(cuò)誤號(hào):ECONNRESET.讀(recv)socket并沒(méi)有返回錯(cuò)誤。

5、該錯(cuò)誤被描述為“connection reset by peer”，即“對(duì)方復(fù)位連接”，這種情況一般發(fā)生在服務(wù)進(jìn)程較客戶(hù)進(jìn)程提前終止。當(dāng)服務(wù)進(jìn)程終止時(shí)會(huì)向客戶(hù) TCP 發(fā)送 FIN 分節(jié)，客戶(hù) TCP 回應(yīng) ACK，服務(wù) TCP 將轉(zhuǎn)入 FIN_WAIT2 狀態(tài)。此時(shí)如果客戶(hù)進(jìn)程沒(méi)有處理該 FIN （如阻塞在其它調(diào)用上而沒(méi)有關(guān)閉 Socket 時(shí)），則客戶(hù) TCP 將處于 CLOSE_WAIT 狀態(tài)。當(dāng)客戶(hù)進(jìn)程再次向 FIN_WAIT2 狀態(tài)的服務(wù) TCP 發(fā)送數(shù)據(jù)時(shí)，則服務(wù) TCP 將立刻響應(yīng) RST。一般來(lái)說(shuō)，這種情況還可以會(huì)引發(fā)另外的應(yīng)用程序異常，客戶(hù)進(jìn)程在發(fā)送完數(shù)據(jù)后，往往會(huì)等待從網(wǎng)絡(luò)IO接收數(shù)據(jù)，很典型的如 read 或 readline 調(diào)用，此時(shí)由于執(zhí)行時(shí)序的原因，如果該調(diào)用發(fā)生在 RST 分節(jié)收到前執(zhí)行的話(huà)，那么結(jié)果是客戶(hù)進(jìn)程會(huì)得到一個(gè)非預(yù)期的 EOF 錯(cuò)誤。此時(shí)一般會(huì)輸出“server terminated prematurely”－“服務(wù)器過(guò)早終止”錯(cuò)誤。

_ 103 ECONNABORTED? Software caused connection abort

1、軟件導(dǎo)致的連接取消。一個(gè)已經(jīng)建立的連接被host方的軟件取消，原因可能是數(shù)據(jù)傳輸超時(shí)或者是協(xié)議錯(cuò)誤。

2、該錯(cuò)誤被描述為“software caused connection abort”，即“軟件引起的連接中止”。原因在于當(dāng)服務(wù)和客戶(hù)進(jìn)程在完成用于 TCP 連接的“三次握手”后，客戶(hù) TCP 卻發(fā)送了一個(gè) RST （復(fù)位）分節(jié)，在服務(wù)進(jìn)程看來(lái)，就在該連接已由 TCP 排隊(duì)，等著服務(wù)進(jìn)程調(diào)用 accept 的時(shí)候 RST 卻到達(dá)了。POSIX 規(guī)定此時(shí)的 errno 值必須 ECONNABORTED。源自 Berkeley 的實(shí)現(xiàn)完全在內(nèi)核中處理中止的連接，服務(wù)進(jìn)程將永遠(yuǎn)不知道該中止的發(fā)生。服務(wù)器進(jìn)程一般可以忽略該錯(cuò)誤，直接再次調(diào)用accept。

當(dāng)TCP協(xié)議接收到RST數(shù)據(jù)段，表示連接出現(xiàn)了某種錯(cuò)誤，函數(shù)read將以錯(cuò)誤返回，錯(cuò)誤類(lèi)型為ECONNERESET。并且以后所有在這個(gè)套接字上的讀操作均返回錯(cuò)誤。錯(cuò)誤返回時(shí)返回值小于0。

_ 102 ENETRESET__ Network dropped connection on reset

網(wǎng)絡(luò)重置時(shí)丟失連接。

由于設(shè)置了"keep-alive"選項(xiàng)，探測(cè)到一個(gè)錯(cuò)誤，連接被中斷。在一個(gè)已經(jīng)失敗的連接上試圖使用setsockopt操作，也會(huì)返回這個(gè)錯(cuò)誤。

_ 101 ENETUNREACH_ Network is unreachable

網(wǎng)絡(luò)不可達(dá)。Socket試圖操作一個(gè)不可達(dá)的網(wǎng)絡(luò)。這意味著local的軟件知道沒(méi)有路由到達(dá)遠(yuǎn)程的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類(lèi)型不支持。指定的socket類(lèi)型在其address family中不支持。如可選選中選項(xiàng)SOCK_RAW，但實(shí)現(xiàn)并不支持SOCK_RAW sockets。

_? 93 EPROTONOSUPPORT Protocol not supported

不支持的協(xié)議。系統(tǒng)中沒(méi)有安裝標(biāo)識(shí)的協(xié)議，或者是沒(méi)有實(shí)現(xiàn)。如函數(shù)需要SOCK_DGRAM socket，但是標(biāo)識(shí)了stream protocol.。

_? 92 ENOPROTOOPT_ Protocol not available

該錯(cuò)誤不是一個(gè) Socket 連接相關(guān)的錯(cuò)誤。errno 給出該值可能由于，通過(guò) getsockopt 系統(tǒng)調(diào)用來(lái)獲得一個(gè)套接字的當(dāng)前選項(xiàng)狀態(tài)時(shí)，如果發(fā)現(xiàn)了系統(tǒng)不支持的選項(xiàng)參數(shù)就會(huì)引發(fā)該錯(cuò)誤。

_? 91 EPROTOTYPE_? Protocol wrong type for socket

協(xié)議類(lèi)型錯(cuò)誤。標(biāo)識(shí)了協(xié)議的Socket函數(shù)在不支持的socket上進(jìn)行操作。如ARPA Internet

UDP協(xié)議不能被標(biāo)識(shí)為SOCK_STREAM socket類(lèi)型。

_? 90 EMSGSIZE__ +Message too long

消息體太長(zhǎng)。

發(fā)送到socket上的一個(gè)數(shù)據(jù)包大小比內(nèi)部的消息緩沖區(qū)大，或者超過(guò)別的網(wǎng)絡(luò)限制，或是用來(lái)接收數(shù)據(jù)包的緩沖區(qū)比數(shù)據(jù)包本身小。

_? 89 EDESTADDRREQ? Destination address required

需要提供目的地址。

在一個(gè)socket上的操作需要提供地址。如往一個(gè)ADDR_ANY 地址上進(jìn)行sendto操作會(huì)返回這個(gè)錯(cuò)誤。

_? 88 ENOTSOCK__? Socket operation on non-socket

在非socket上執(zhí)行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

接收端關(guān)閉(緩沖中沒(méi)有多余的數(shù)據(jù)),但是發(fā)送端還在write:

1、Socket 關(guān)閉，但是socket號(hào)并沒(méi)有置-1。繼續(xù)在此socket上進(jìn)行send和recv，就會(huì)返回這種錯(cuò)誤。這個(gè)錯(cuò)誤會(huì)引發(fā)SIGPIPE信號(hào)，系統(tǒng)會(huì)將產(chǎn)生此EPIPE錯(cuò)誤的進(jìn)程殺死。所以，一般在網(wǎng)絡(luò)程序中，首先屏蔽此消息，以免發(fā)生不及時(shí)設(shè)置socket進(jìn)程被殺死的情況。

2、write(..) on a socket that has been closed at the other end will cause a SIGPIPE.

3、錯(cuò)誤被描述為“broken pipe”，即“管道破裂”，這種情況一般發(fā)生在客戶(hù)進(jìn)程不理會(huì)（或未及時(shí)處理）Socket 錯(cuò)誤，繼續(xù)向服務(wù) TCP 寫(xiě)入更多數(shù)據(jù)時(shí)，內(nèi)核將向客戶(hù)進(jìn)程發(fā)送 SIGPIPE 信號(hào)，該信號(hào)默認(rèn)會(huì)使進(jìn)程終止（此時(shí)該前臺(tái)進(jìn)程未進(jìn)行 core dump）。結(jié)合上邊的 ECONNRESET 錯(cuò)誤可知，向一個(gè) FIN_WAIT2 狀態(tài)的服務(wù) TCP（已 ACK 響應(yīng) FIN 分節(jié)）寫(xiě)入數(shù)據(jù)不成問(wèn)題，但是寫(xiě)一個(gè)已接收了 RST 的 Socket 則是一個(gè)錯(cuò)誤。

_? 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

打開(kāi)了太多的socket。對(duì)進(jìn)程或者線(xiàn)程而言，每種實(shí)現(xiàn)方法都有一個(gè)最大的可用socket數(shù)目處理，或者是全局的，或者是局部的。

_? 23 ENFILE___ +Too many open files in system

_? 22 EINVAL___ +Invalid argument

無(wú)效參數(shù)。提供的參數(shù)非法。有時(shí)也會(huì)與socket的當(dāng)前狀態(tài)相關(guān)，如一個(gè)socket并沒(méi)有進(jìn)入listening狀態(tài)，此時(shí)調(diào)用accept，就會(huì)產(chǎn)生EINVAL錯(cuò)誤。

_? 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地址錯(cuò)誤

_? 13 EACCES___ +Permission denied

_? 12 ENOMEM___ +Cannot allocate memory

_? 11 EAGAIN___ +Resource temporarily unavailable

在讀數(shù)據(jù)的時(shí)候,沒(méi)有數(shù)據(jù)在底層緩沖的時(shí)候會(huì)遇到,一般的處理是循環(huán)進(jìn)行讀操作,異步模式還會(huì)等待讀事件的發(fā)生再讀

1、Send返回值小于要發(fā)送的數(shù)據(jù)數(shù)目，會(huì)返回EAGAIN和EINTR。

2、recv 返回值小于請(qǐng)求的長(zhǎng)度時(shí)說(shuō)明緩沖區(qū)已經(jīng)沒(méi)有可讀數(shù)據(jù)，但再讀不一定會(huì)觸發(fā)EAGAIN，有可能返回0表示TCP連接已被關(guān)閉。

3、當(dāng)socket是非阻塞時(shí),如返回此錯(cuò)誤,表示寫(xiě)緩沖隊(duì)列已滿(mǎn),可以做延時(shí)后再重試.

4、在Linux進(jìn)行非阻塞的socket接收數(shù)據(jù)時(shí)經(jīng)常出現(xiàn)Resource temporarily unavailable，errno代碼為11(EAGAIN)，表明在非阻塞模式下調(diào)用了阻塞操作，在該操作沒(méi)有完成就返回這個(gè)錯(cuò)誤，這個(gè)錯(cuò)誤不會(huì)破壞socket的同步，不用管它，下次循環(huán)接著recv就可以。對(duì)非阻塞socket而言，EAGAIN不是一種錯(cuò)誤。

_? 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

阻塞的操作被取消阻塞的調(diào)用打斷。如設(shè)置了發(fā)送接收超時(shí)，就會(huì)遇到這種錯(cuò)誤。

只能針對(duì)阻塞模式的socket。讀，寫(xiě)阻塞的socket時(shí)，-1返回，錯(cuò)誤號(hào)為INTR。另外，如果出現(xiàn)EINTR即errno為4，錯(cuò)誤描述Interrupted system call，操作也應(yīng)該繼續(xù)。如果recv的返回值為0，那表明連接已經(jīng)斷開(kāi)，接收操作也應(yīng)該結(jié)束。

__ 3 ESRCH___? +No such process

__ 2 ENOENT___ +No such file or directory

__ 1 EPERM___? +Operation not permitted