|
網上查了一下端口狀態(tài)的資料，我下面總結了一下，自己學習學習： TCP狀態(tài)轉移要點
TCP協議規(guī)定，對于已經建立的連接，網絡雙方要進行四次握手才能成功斷開連接，如果缺少了其中某個步驟，將會使連接處于假死狀態(tài)，連接本身占用的資源不會被釋放。網絡服務器程序要同時管理大量連接，所以很有必要保證無用連接完全斷開，否則大量僵死的連接會浪費許多服務器資源。在眾多TCP狀態(tài)中，最值得注意的狀態(tài)有兩個：CLOSE_WAIT和TIME_WAIT。
1、LISTENING狀態(tài)
FTP服務啟動后首先處于偵聽（LISTENING）狀態(tài)。 2、ESTABLISHED狀態(tài)
ESTABLISHED的意思是建立連接。表示兩臺機器正在通信。 3、CLOSE_WAIT 對方主動關閉連接或者網絡異常導致連接中斷，這時我方的狀態(tài)會變成CLOSE_WAIT 此時我方要調用close()來使得連接正確關閉 4、TIME_WAIT 我方主動調用close()斷開連接，收到對方確認后狀態(tài)變?yōu)門IME_WAIT。TCP協議規(guī)定TIME_WAIT狀態(tài)會一直持續(xù)2MSL(即兩倍的分段最大生存期)，以此來確保舊的連接狀態(tài)不會對新連接產生影響。處于TIME_WAIT狀態(tài)的連接占用的資源不會被內核釋放，所以作為服務器，在可能的情況下，盡量不要主動斷開連接，以減少TIME_WAIT狀態(tài)造成的資源浪費。 目前有一種避免TIME_WAIT資源浪費的方法，就是關閉socket的LINGER選項。但這種做法是TCP協議不推薦使用的，在某些情況下這個操作可能會帶來錯誤。 1. socket的狀態(tài)1.1 狀態(tài)說明| CLOSED | 沒有使用這個套接字[netstat 無法顯示closed狀態(tài)] | | LISTEN | 套接字正在監(jiān)聽連接[調用listen后] | | SYN_SENT | 套接字正在試圖主動建立連接[發(fā)送SYN后還沒有收到ACK] | | SYN_RECEIVED | 正在處于連接的初始同步狀態(tài)[收到對方的SYN，但還沒收到自己發(fā)過去的SYN的ACK] | | ESTABLISHED | 連接已建立 | | CLOSE_WAIT | 遠程套接字已經關閉：正在等待關閉這個套接字[被動關閉的一方收到FIN] | | FIN_WAIT_1 | 套接字已關閉，正在關閉連接[發(fā)送FIN，沒有收到ACK也沒有收到FIN] | | CLOSING | 套接字已關閉，遠程套接字正在關閉，暫時掛起關閉確認[在FIN_WAIT_1狀態(tài)下收到被動方的FIN] | | LAST_ACK | 遠程套接字已關閉，正在等待本地套接字的關閉確認[被動方在CLOSE_WAIT狀態(tài)下發(fā)送FIN] | | FIN_WAIT_2 | 套接字已關閉，正在等待遠程套接字關閉[在FIN_WAIT_1狀態(tài)下收到發(fā)過去FIN對應的ACK] | | TIME_WAIT | 這個套接字已經關閉，正在等待遠程套接字的關閉傳送[FIN、ACK、FIN、ACK都完畢，這是主動方的最后一個狀態(tài)，在過了2MSL時間后變?yōu)镃LOSED狀態(tài)] |
1.2 狀態(tài)變遷圖摘自《UNIX 網絡編程 卷1：套接字聯網API》 P35 
2. TCP的三次握手和四次揮手2.1 總結圖左邊為客戶端的狀態(tài)轉變，后邊為服務器的狀態(tài)轉變 
2.2 說明2.2.1 connect返回-1 errno=110(ETIMEDOUT)，當服務器端網線拔了的時候，客戶端發(fā)送SYN過去就會收不到ACK，因此就會出現這個錯誤，1分鐘內就會返 回這個錯誤。 errno=111(ECONNREFUSED)，當服務器未listen時，就會報這個錯 2.2.2 ESTABLISHED不一定真的establish 會出現這種情況：client為ESTABLISHED狀態(tài)而server為SYN_REVD狀態(tài)。 這是因為LINUX不像其他操作系統在收到SYN為該連接立馬分配一塊內存空間用于存儲相關的數據和結構，而是延遲到接收到client的ACK，即三次握手 真正完成后才分配空間，這是為了防范SYN flooding攻擊。 如果是這種情況，那么就會出現client端未ESTABLISHED狀態(tài)，server為SYN_RECV狀態(tài)。 并且server的SYN_RECV狀態(tài)在一定時間后會消失，client的established狀態(tài)也會消失。這是因為server在SYN_RECV狀態(tài)時，會像client發(fā)送多次的SYN+ACK（因為他以為自己的這個包對方沒收到），發(fā)送的次數定義在/proc/sys/net/ipv4/tcp_synack_retries中，默認為5.在發(fā)送5次之后還沒有收到ACK，就將其回收了，所以用netstat查看就看不到這個SYN_RECV狀態(tài)了。并且會像client發(fā)送RST信號。這就會導致client的這種半連接最后也會消失。這個可以通過tcpdump抓包得到（最好知道src這樣看到的包比較集中）。
|
