一、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的進行抓包
5)、tcpdump dst port 9000 -w dump9000.pcap 對tcp目標端口為9000的進行抓包保存pcap文件wireshark分析。
6)、tcpdump tcp port 9000 -n -X -s 0 -w tcp.cap 對tcp/http目標端口為9000的進行抓包保存pcap文件wireshark分析。
網絡測試常用命令;
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 http://www.baidu.com
4）mtr：以結合ping nslookup tracert 來判斷網絡的相關特性
5) nslookup:用於解析域名，一般用來檢測本機的DNS設置是否配置正確。
二、TCP建立連接三次握手相關狀態
TCP是一個面向連接的協議，所以在連接雙方發送數據之前，都需要首先建立一條連接。
1、Client連接Server三次握手過程：
當Client端調用socket函數調用時，相當於Client端產生了一個處於Closed狀態的套接字。
( 1) 第一次握手SYN：Client端又調用connect函數調用，系統為Client隨機分配一個端口，連同傳入connect中的參數(Server的IP和端口)，這就形成了一個連接四元組，客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。connect調用讓Client端的socket處於SYN_SENT狀態，等待服務器確認；SYN：同步序列編號(Synchronize Sequence Numbers)。
( 2)第二次握手SYN+ACK： 服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
( 3) 第三次握手ACK：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶器和客務器進入ESTABLISHED狀態，完成三次握手。連接已經可以進行讀寫操作。
一個完整的三次握手也就是： 請求---應答---再次確認。
TCP協議通過三個報文段完成連接的建立，這個過程稱為三次握手(three-way handshake)，過程如下圖所示。
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返回，至此三次握手完畢，連接建立。
我們可以通過wireshark抓包，可以清晰看到查看具體的流程：
第一次握手：syn的seq= 0
第二次握手：服務器收到syn包，必須確認客戶的SYN（ACK=j+1=1）=，同時自己也發送一個SYN包（syn=0）
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)
2、建立連接的具體狀態：
1)、LISTENING：偵聽來自遠方的TCP端口的連接請求.
首先服務端需要打開一個socket進行監聽，狀態為LISTEN。
有提供某種服務才會處於LISTENING狀態，TCP狀態變化就是某個端口的狀態變化，提供一個服務就打開一個端口，例如：提供www服務默認開的是80端口，提供ftp服務默認的端口為21，當提供的服務沒有被連接時就處於LISTENING狀態。FTP服務啟動后首先處於偵聽（LISTENING）狀態。處於偵聽LISTENING狀態時，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經敞開的，但還沒有人進來。
看LISTENING狀態最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關閉不必要的端口是保證安全的一個非常重要的方面，服務端口都對應一個服務（應用程序），停止該服務就關閉了該端口，例如要關閉21端口只要停止IIS服務中的FTP服務即可。關於這方面的知識請參閱其它文章。
如果你不幸中了服務端口的木馬，木馬也開個端口處於LISTENING狀態。
2)、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出現。
3)、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洪水攻擊）
4)、ESTABLISHED：代表一個打開的連接。
ESTABLISHED狀態是表示兩台機器正在傳輸數據，觀察這個狀態最主要的就是看哪個程序正在處於ESTABLISHED狀態。
服務器出現很多ESTABLISHED狀態： netstat -nat |grep 9502或者使用lsof -i:9502可以檢測到。
當客戶端未主動close的時候就斷開連接：即客戶端發送的FIN丟失或未發送:
這時候若客戶端斷開的時候發送了FIN包，則服務端將會處於CLOSE_WAIT狀態；
這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態；
結果客戶端重新連接服務器。
而新連接上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED; 如果客戶端重復的上演這種情況，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。
最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，並顯示ESTABLISHED，但始終無法進入程序代碼。
三、 TCP關閉四次握手的相關狀態
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
1、四次握手關閉連接的過程
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉(half-close)造成的，如圖：
調用過程和對應函數接口：
- 1) 客戶端發送一個FIN: 用來關閉客戶A到服務器B的數據傳送,當client想要關閉它與server之間的連接。client（某個應用進程）首先調用close主動關閉連接，這時TCP發送一個FIN M；client端處於FIN_WAIT1狀態。
- 2) 服務器確認客戶端FIN: 當server端接收到FIN M之后，執行被動關閉。對這個FIN進行確認，返回給client ACK。確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。當server端返回給client ACK后，client處於FIN_WAIT2狀態，server處於CLOSE_WAIT狀態。它的接收也作為文件結束符傳遞給應用進程，因為FIN的接收 意味着應用進程在相應的連接上再也接收不到額外數據；
- 3) 服務器B發送一個FIN關閉與客戶端A的連接: 一段時間之后，當server端檢測到client端的關閉操作(read返回為0)。接收到文件結束符的server端調用close關閉它的socket。這導致server端的TCP也發送一個FIN N；此時server的狀態為LAST_ACK。
- 4) 客戶端A發回ACK報文確認: 當client收到來自server的FIN后 。 client端的套接字處於TIME_WAIT狀態，它會向server端再發送一個ack確認，此時server端收到ack確認后，此套接字處於CLOSED狀態。
這樣每個方向上都有一個FIN和ACK。
2、四次握手關閉連接的具體狀態
1）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。
2）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狀態，而直到應用層來決定關閉這個狀態。
3）CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
被動關閉(passive close)端TCP接到FIN后，就發出ACK以回應FIN請求(它的接收也作為文件結束符傳遞給上層應用程序),並進入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待從本地用戶發來的連接中斷請求 */
4）CLOSING：等待遠程TCP對連接中斷的確認
比較少見./* Both sockets are shut down but we still don't have all our data sent. 等待遠程TCP對連接中斷的確認 */
實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當一方發送FIN報文后，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示一方發送FIN報文后，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢？
有兩種情況可能導致這種狀態：
其一，如果雙方幾乎在同時關閉連接，那么就可能出現雙方同時發送FIN包的情況；
其二，如果ACK包丟失而對方的FIN包很快發出，也會出現FIN先於ACK到達。
4）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。
5）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時間的過去才能進行下一次連接。
6）CLOSED：沒有任何連接狀態
被動關閉端在接受到ACK包后，就進入了closed的狀態。連接結束./* The socket is not being used. 沒有任何連接狀態 */
四、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建立連接的三次握手過程，以及關閉連接的四次握手過程。
五、具體問題
1．為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
2、什么是2MSL
MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯為“報文最大生存時間”，他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。因為tcp報文（segment）是ip數據報（datagram）的數據部分，具體稱謂請參見《數據在網絡各層中的稱呼》一文，而ip頭中有一個TTL域，TTL是time to live的縮寫，中文可以譯為“生存時間”，這個生存時間是由源主機設置初始值但不是存的具體時間，而是存儲了一個ip數據報可以經過的最大路由數，每經過一個處理他的路由器此值就減1，當此值為0則數據報將被丟棄，同時發送ICMP報文通知源主機。RFC 793中規定MSL為2分鍾，實際應用中常用的是30秒，1分鍾和2分鍾等。
2MSL即兩倍的MSL，TCP的TIME_WAIT狀態也稱為2MSL等待狀態，當TCP的一端發起主動關閉，在發出最后一個ACK包后，即第3次握手完成后發送了第四次握手的ACK包后就進入了TIME_WAIT狀態，必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最后一個ACK包對方沒收到，那么對方在超時后將重發第三次握手的FIN包，主動關閉端接到重發的FIN包后可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的端口不能使用，要等到2MSL時間結束才可繼續使用。當連接處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此端口。
這是因為雖然雙方都同意關閉連接了，而且握手的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狀態還需要等2MSL后才能返回到CLOSED狀態？
第一，保證可靠的實現TCP全雙工鏈接的終止：為了保證主動端A發送的最后一個ACK報文能夠到達被動段B，確保被動端能進入CLOSED狀態。
對照上圖，在四次揮手協議中，當B向A發送Fin+Ack后，A就需要向B發送ACK+Seq報文，A這時候就處於TIME_WAIT 狀態，但是這個報文ACK有可能會發送失敗而丟失，因而使處在LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認。B會超時重傳這個FIN+ACK報文段，而A就能在2MSL時間內收到這個重傳的FIN+ACK報文段。如果A在TIME-WAIT狀態不等待一段時間，而是在發送完ACK報文段后就立即釋放連接，就無法收到B重傳的FIN+ACK報文段，因而也不會再發送一次確認報文段。這樣B就無法按照正常的步驟進入CLOSED狀態。
第二，防止已失效的連接請求報文段出現在本連接中。A在發送完ACK報文段后，再經過2MSL時間，就可以使本連接持續的時間所產生的所有報文段都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求的報文段。
假設在A的XXX1端口和B的80端口之間有一個TCP連接。我們關閉這個連接，過一段時間后在相同的IP地址和端口建立另一個連接。后一個鏈接成為前一個的化身。因為它們的IP地址和端口號都相同。TCP必須防止來自某一個連接的老的重復分組在連 接已經終止后再現，從而被誤解成屬於同一鏈接的某一個某一個新的化身。為做到這一點，TCP將不給處於TIME_WAIT狀態的鏈接發起新的化身。既然 TIME_WAIT狀態的持續時間是MSL的2倍，這就足以讓某個方向上的分組最多存活msl秒即被丟棄，另一個方向上的應答最多存活msl秒也被丟棄。 通過實施這個規則，我們就能保證每成功建立一個TCP連接時。來自該鏈接先前化身的重復分組都已經在網絡中消逝了。
4、解決linux發現系統存在大量TIME_WAIT狀態
如果linux發現系統存在大量TIME_WAIT狀態的連接，可以通過調整內核參數解決：vi /etc/sysctl.conf 加入以下內容：
net.ipv4.tcp_max_tw_buckets=5000 #TIME-WAIT Socket 最大數量
#注意：不建議開啟該設置，NAT 模式下可能引起連接 RST
net.ipv4.tcp_tw_reuse = 1 #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 #表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。
然后執行 /sbin/sysctl -p 讓參數生效。
六. 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的連接建立和連接關閉，都是通過請求－響應的模式完成的。
七. 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端應該為以下三種情況之一：
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.
八. 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