我們通過了解TCP各個狀態，可以排除和定位網絡或系統故障時大有幫助。（總結網絡上的內容）
1、TCP狀態
但是很多服務器為了防止攻擊，一般會關閉對ping的響應。所以ping一般作為測試連通性使用。ping命令后，會接收到對方發送的回饋信息，其中記錄着對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄之前允許通過的最大網段數量。TTL是IPv4包頭的一個8 bit字段。例如IP包在服務器中發送前設置的TTL是64，你使用ping命令后，得到服務器反饋的信息，其中的TTL為56，說明途中一共經過了8道路由器的轉發，每經過一個路由，TTL減1。
看LISTENING狀態最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關閉不必要的端口是保證安全的一個非常重要的方面，服務端口都對應一個服務（應用程序），停止該服務就關閉了該端口，例如要關閉21端口只要停止IIS服務中的FTP服務即可。關於這方面的知識請參閱其它文章。
如果你不幸中了服務端口的木馬，木馬也開個端口處於LISTENING狀態。
SYN-SENT：客戶端SYN_SENT狀態：
當請求連接時客戶端首先要發送同步信號給要訪問的機器，此時狀態為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
如果發現有很多SYN_RCVD狀態，那你的機器有可能被SYN Flood的DoS(拒絕服務攻擊)攻擊了。
ESTABLISHED：代表一個打開的連接。
這時候若客戶端斷開的時候發送了FIN包，則服務端將會處於CLOSE_WAIT狀態；
這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態；
結果客戶端重新連接服務器。
而新連接上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED; 如果客戶端重復的上演這種情況，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。
最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，並顯示ESTABLISHED，但始終無法進入程序代碼。
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
FIN-WAIT-2：從遠程TCP等待連接中斷請求
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
CLOSING：等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED：沒有任何連接狀態
2、TCP狀態遷移路線圖
client/server兩條路線講述TCP狀態遷移路線圖：
3、TCP連接建立三次握手
當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狀態，完成三次握手。連接已經可以進行讀寫操作。
一個完整的三次握手也就是： 請求---應答---再次確認。
2)Server
當Server端調用socket函數調用時，相當於Server端產生了一個處於Closed狀態的監聽套接字
Server端調用bind操作，將監聽套接字與指定的地址和端口關聯，然后又調用listen函數，系統會為其分配未完成隊列和完成隊列，此時的監聽套接字可以接受Client的連接，監聽套接字狀態處於LISTEN狀態。
當Server端調用accept操作時，會從完成隊列中取出一個已經完成的client連接，同時在server這段會產生一個會話套接字，用於和client端套接字的通信，這個會話套接字的狀態是ESTABLISH。
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
4. TCP連接的終止（四次握手釋放）
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（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通信中服務器處理客戶端意外斷開
引用地址：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連接稱為半打開的。
解決意外中斷辦法都是利用保活機制。而保活機制分又可以讓底層實現也可自己實現。
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
在程序中設置如下:
-
-
-
-
-
-
-
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 space available
_ 104 ECONNRESET_ Connection reset by peer
連接被遠程主機關閉。有以下幾種原因：遠程主機停止服務，重新啟動;當在執行某些操作時遇到失敗，因為設置了“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”，即“對方復位連接”，這種情況一般發生在服務進程較客戶進程提前終止。
主動關閉調用過程如下：
服務器端主動關閉：
1）當服務器的服務因為某種原因，進程提前終止時會向客戶 TCP 發送 FIN 分節，服務器端處於FIN_WAIT1狀態。
2）客戶TCP回應ACK后，服務TCP將轉入FIN_WAIT2狀態。
3）此時如果客戶進程沒有處理該 FIN （如阻塞在其它調用上而沒有關閉 Socket 時），則客戶TCP將處於CLOSE_WAIT狀態。
4）當客戶進程再次向 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