一、TCP狀態
1、linux查看tcp的狀態命令
2、網絡測試常用命令
1) ping:檢測網絡連接的正常與否,主要是測試延時、抖動、丟包率。
但是很多服務器為了防止攻擊，一般會關閉對ping的響應。所以ping一般作為測試連通性使用。
ping命令后，會接收到對方發送的回饋信息，其中記錄著對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄之前允許通過的最大網段數量。
TTL是IPv4包頭的一個8 bit字段。例如IP包在服務器中發送前設置的TTL是64，你使用ping命令后，得到服務器反饋的信息，其中的TTL為56，說明途中一共經過了8道路由器的轉發，每經過一個路由，TTL減1。
2）traceroute：raceroute 跟蹤數據包到達網絡主機所經過的路由工具
traceroute hostname
3）pathping：是一個路由跟蹤工具，它將 ping 和 tracert 命令的功能與這兩個工具所不提供的其他信息結合起來，綜合了二者的功能
pathping www.baidu.com
4）mtr：以結合ping nslookup tracert 來判斷網絡的相關特性
5) nslookup:用于解析域名，一般用來檢測本機的DNS設置是否配置正確。
狀態分析：
①LISTENING：偵聽來自遠方的TCP端口的連接請求。
首先服務端需要打開一個socket進行監聽，狀態為LISTEN。
有提供某種服務才會處于LISTENING狀態，TCP狀態變化就是某個端口的狀態變化，提供一個服務就打開一個端口。
例如：提供www服務默認開的是80端口，提供ftp服務默認的端口為21，當提供的服務沒有被連接時就處于LISTENING狀態。
FTP服務啟動后首先處于偵聽（LISTENING）狀態。處于偵聽LISTENING狀態時，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經敞開的，但還沒有人進來。
看LISTENING狀態最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關閉不必要的端口是保證安全的一個非常重要的方面，服務端口都對應一個服務（應用程序），停止該服務就關閉了該端口，例如要關閉21端口只要停止IIS服務中的FTP服務即可。關于這方面的知識請參閱其它文章。
如果你不幸中了服務端口的木馬，木馬也開個端口處于LISTENING狀態。
②SYN-SENT：客戶端SYN_SENT狀態：
再發送連接請求后等待匹配的連接請求:客戶端通過應用程序調用connect進行active open.
客戶端tcp發送一個SYN以請求建立一個連接.之后狀態置為SYN_SENT.
The socket is actively attempting to establish a connection. 在發送連接請求后等待匹配的連接請求
當請求連接時客戶端首先要發送同步信號給要訪問的機器，此時狀態為SYN_SENT，如果連接成功了就變為ESTABLISHED，正常情況下SYN_SENT狀態非常短暫。
例如要訪問網站http://www.baidu.com,如果是正常連接的話，用TCPView觀察IEXPLORE.EXE（IE）建立的連接會發現很快從SYN_SENT變為ESTABLISHED，表示連接成功。SYN_SENT狀態快的也許看不到。
如果發現有很多SYN_SENT出現，那一般有這么幾種情況:
③SYN-RECEIVED：服務器端狀態SYN_RCVD
再收到和發送一個連接請求后等待對方對連接請求的確認
當服務器收到客戶端發送的同步信號時，將標志位ACK和SYN置1發送給客戶端，此時服務器端處于SYN_RCVD狀態，如果連接成功了就變為ESTABLISHED，正常情況下SYN_RCVD狀態非常短暫。
如果發現有很多SYN_RCVD狀態，那你的機器有可能被SYN Flood的DoS(拒絕服務攻擊)攻擊了。
SYN Flood的攻擊原理是：
④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狀態。等待遠程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就會出現錯。
三、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)。
連接出現連接不上的問題，一般是網路出現問題或者網卡超負荷或者是連接數已經滿啦。
四、TCP連接的終止（四次握手釋放）
由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。
首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉(half-close)造成的，
五、為什么建立連接協議是三次握手，而關閉連接卻是四次握手
服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；
但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
六、為什么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元組，這時候連接就可能接收到網絡上的延遲報文就可能干擾最新建立的連接。
七、大量TIME_WAIT狀態問題解決
發現系統存在大量TIME_WAIT狀態的連接，可以通過調整內核參數解決：vi /etc/sysctl.conf 加入以下內容：
備注：這種方式不是很好，我之前試過修改內核參數只是一會沒有問題，但是時間長了還是沒有效果，建議采用長連接方式。
八、同時打開
兩個應用程序同時執行主動打開的情況是可能的，雖然發生的可能性較低。每一端都發送一個SYN,并傳遞給對方，且每一端都使用對端所知的端口作為本地端口。例如：
主機a中一應用程序使用7777作為本地端口，并連接到主機b 8888端口做主動打開。
主機b中一應用程序使用8888作為本地端口，并連接到主機a 7777端口做主動打開。
tcp協議在遇到這種情況時，只會打開一條連接。
這個連接的建立過程需要4次數據交換，而一個典型的連接建立只需要3次交換（即3次握手）
但多數tcp/ip實現并不支持同時打開。
九、同時關閉
如果應用程序同時發送FIN，則在發送后會首先進入FIN_WAIT_1狀態。在收到對端的FIN后，回復一個ACK，會進入CLOSING狀態。在收到對端的ACK后，進入TIME_WAIT狀態。這種情況稱為同時關閉。
同時關閉也需要有4次報文交換，與典型的關閉相同。
十、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、自己編寫心跳包程序
2、啟動TCP編程里的keepAlive機制
1）雙方擬定心跳（自實現）
一般由客戶端發送心跳包，服務端并不回應心跳，只是定時輪詢判斷一下與上次的時間間隔是否超時（超時時間自己設定）。服務器并不主動發送是不想增添服務器的通信量，減少壓力。
2）利用KeepAlive
其實keepalive的原理就是TCP內嵌的一個心跳包,
以服務器端為例，如果當前server端檢測到超過一定時間（默認是 7,200,000 milliseconds，也就是2個小時）沒有數據傳輸，那么會向client端發送一個keep-alive packet（該keep-alive packet就是ACK和當前TCP序列號減一的組合），此時client端應該為以下三種情況之一：
