網(wǎng)上查了一下端口狀態(tài)的資料，我下面總結(jié)了一下，自己學(xué)習(xí)學(xué)習(xí)：

TCP狀態(tài)轉(zhuǎn)移要點(diǎn)
    TCP協(xié)議規(guī)定，對于已經(jīng)建立的連接，網(wǎng)絡(luò)雙方要進(jìn)行四次握手才能成功斷開連接，如果缺少了其中某個步驟，將會使連接處于假死狀態(tài)，連接本身占用的資源不會被釋放。網(wǎng)絡(luò)服務(wù)器程序要同時管理大量連接，所以很有必要保證無用連接完全斷開，否則大量僵死的連接會浪費(fèi)許多服務(wù)器資源。在眾多TCP狀態(tài)中，最值得注意的狀態(tài)有兩個：CLOSE_WAIT和TIME_WAIT。  
 
1、LISTENING狀態(tài)
　　FTP服務(wù)啟動后首先處于偵聽（LISTENING）狀態(tài)。

2、ESTABLISHED狀態(tài)
　　ESTABLISHED的意思是建立連接。表示兩臺機(jī)器正在通信。

3、CLOSE_WAIT

    對方主動關(guān)閉連接或者網(wǎng)絡(luò)異常導(dǎo)致連接中斷，這時我方的狀態(tài)會變成CLOSE_WAIT 此時我方要調(diào)用close()來使得連接正確關(guān)閉

4、TIME_WAIT

    我方主動調(diào)用close()斷開連接，收到對方確認(rèn)后狀態(tài)變?yōu)門IME_WAIT。TCP協(xié)議規(guī)定TIME_WAIT狀態(tài)會一直持續(xù)2MSL(即兩倍的分段最大生存期)，以此來確保舊的連接狀態(tài)不會對新連接產(chǎn)生影響。處于TIME_WAIT狀態(tài)的連接占用的資源不會被內(nèi)核釋放，所以作為服務(wù)器，在可能的情況下，盡量不要主動斷開連接，以減少TIME_WAIT狀態(tài)造成的資源浪費(fèi)。

    目前有一種避免TIME_WAIT資源浪費(fèi)的方法，就是關(guān)閉socket的LINGER選項(xiàng)。但這種做法是TCP協(xié)議不推薦使用的，在某些情況下這個操作可能會帶來錯誤。

1. socket的狀態(tài)

1.1 狀態(tài)說明

CLOSED	沒有使用這個套接字[netstat 無法顯示closed狀態(tài)]
LISTEN	套接字正在監(jiān)聽連接[調(diào)用listen后]
SYN_SENT	套接字正在試圖主動建立連接[發(fā)送SYN后還沒有收到ACK]
SYN_RECEIVED	正在處于連接的初始同步狀態(tài)[收到對方的SYN，但還沒收到自己發(fā)過去的SYN的ACK]
ESTABLISHED	連接已建立
CLOSE_WAIT	遠(yuǎn)程套接字已經(jīng)關(guān)閉：正在等待關(guān)閉這個套接字[被動關(guān)閉的一方收到FIN]
FIN_WAIT_1	套接字已關(guān)閉，正在關(guān)閉連接[發(fā)送FIN，沒有收到ACK也沒有收到FIN]
CLOSING	套接字已關(guān)閉，遠(yuǎn)程套接字正在關(guān)閉，暫時掛起關(guān)閉確認(rèn)[在FIN_WAIT_1狀態(tài)下收到被動方的FIN]
LAST_ACK	遠(yuǎn)程套接字已關(guān)閉，正在等待本地套接字的關(guān)閉確認(rèn)[被動方在CLOSE_WAIT狀態(tài)下發(fā)送FIN]
FIN_WAIT_2	套接字已關(guān)閉，正在等待遠(yuǎn)程套接字關(guān)閉[在FIN_WAIT_1狀態(tài)下收到發(fā)過去FIN對應(yīng)的ACK]
TIME_WAIT	這個套接字已經(jīng)關(guān)閉，正在等待遠(yuǎn)程套接字的關(guān)閉傳送[FIN、ACK、FIN、ACK都完畢，這是主動方的最后一個狀態(tài)，在過了2MSL時間后變?yōu)镃LOSED狀態(tài)]

1.2 狀態(tài)變遷圖

摘自《UNIX 網(wǎng)絡(luò)編程 卷1：套接字聯(lián)網(wǎng)API》 P35

2. TCP的三次握手和四次揮手

2.1 總結(jié)圖

左邊為客戶端的狀態(tài)轉(zhuǎn)變，后邊為服務(wù)器的狀態(tài)轉(zhuǎn)變

2.2 說明

2.2.1   connect返回-1

             errno=110(ETIMEDOUT)，當(dāng)服務(wù)器端網(wǎng)線拔了的時候，客戶端發(fā)送SYN過去就會收不到ACK，因此就會出現(xiàn)這個錯誤，1分鐘內(nèi)就會返  回這個錯誤。

             errno=111(ECONNREFUSED)，當(dāng)服務(wù)器未listen時，就會報(bào)這個錯

2.2.2 ESTABLISHED不一定真的establish

              會出現(xiàn)這種情況：client為ESTABLISHED狀態(tài)而server為SYN_REVD狀態(tài)。

             這是因?yàn)長INUX不像其他操作系統(tǒng)在收到SYN為該連接立馬分配一塊內(nèi)存空間用于存儲相關(guān)的數(shù)據(jù)和結(jié)構(gòu)，而是延遲到接收到client的ACK，即三次握手    真正完成后才分配空間，這是為了防范SYN flooding攻擊。 如果是這種情況，那么就會出現(xiàn)client端未ESTABLISHED狀態(tài)，server為SYN_RECV狀態(tài)。   

             并且server的SYN_RECV狀態(tài)在一定時間后會消失，client的established狀態(tài)也會消失。這是因?yàn)閟erver在SYN_RECV狀態(tài)時，會像client發(fā)送多次的SYN+ACK（因?yàn)樗詾樽约旱倪@個包對方?jīng)]收到），發(fā)送的次數(shù)定義在/proc/sys/net/ipv4/tcp_synack_retries中，默認(rèn)為5.在發(fā)送5次之后還沒有收到ACK，就將其回收了，所以用netstat查看就看不到這個SYN_RECV狀態(tài)了。并且會像client發(fā)送RST信號。這就會導(dǎo)致client的這種半連接最后也會消失。這個可以通過tcpdump抓包得到（最好知道src這樣看到的包比較集中）。