|
網(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)行四次握手才能成功斷開連接,如果缺少了其中某個(gè)步驟,將會(huì)使連接處于假死狀態(tài),連接本身占用的資源不會(huì)被釋放。網(wǎng)絡(luò)服務(wù)器程序要同時(shí)管理大量連接,所以很有必要保證無用連接完全斷開,否則大量僵死的連接會(huì)浪費(fèi)許多服務(wù)器資源。在眾多TCP狀態(tài)中,最值得注意的狀態(tài)有兩個(gè):CLOSE_WAIT和TIME_WAIT。 1、LISTENING狀態(tài) FTP服務(wù)啟動(dòng)后首先處于偵聽(LISTENING)狀態(tài)。 2、ESTABLISHED狀態(tài) ESTABLISHED的意思是建立連接。表示兩臺(tái)機(jī)器正在通信。 3、CLOSE_WAIT 對方主動(dòng)關(guān)閉連接或者網(wǎng)絡(luò)異常導(dǎo)致連接中斷,這時(shí)我方的狀態(tài)會(huì)變成CLOSE_WAIT 此時(shí)我方要調(diào)用close()來使得連接正確關(guān)閉 4、TIME_WAIT 我方主動(dòng)調(diào)用close()斷開連接,收到對方確認(rèn)后狀態(tài)變?yōu)門IME_WAIT。TCP協(xié)議規(guī)定TIME_WAIT狀態(tài)會(huì)一直持續(xù)2MSL(即兩倍的分段最大生存期),以此來確保舊的連接狀態(tài)不會(huì)對新連接產(chǎn)生影響。處于TIME_WAIT狀態(tài)的連接占用的資源不會(huì)被內(nèi)核釋放,所以作為服務(wù)器,在可能的情況下,盡量不要主動(dòng)斷開連接,以減少TIME_WAIT狀態(tài)造成的資源浪費(fèi)。 目前有一種避免TIME_WAIT資源浪費(fèi)的方法,就是關(guān)閉socket的LINGER選項(xiàng)。但這種做法是TCP協(xié)議不推薦使用的,在某些情況下這個(gè)操作可能會(huì)帶來錯(cuò)誤。 1. socket的狀態(tài)1.1 狀態(tài)說明| CLOSED | 沒有使用這個(gè)套接字[netstat 無法顯示closed狀態(tài)] | | LISTEN | 套接字正在監(jiān)聽連接[調(diào)用listen后] | | SYN_SENT | 套接字正在試圖主動(dòng)建立連接[發(fā)送SYN后還沒有收到ACK] | | SYN_RECEIVED | 正在處于連接的初始同步狀態(tài)[收到對方的SYN,但還沒收到自己發(fā)過去的SYN的ACK] | | ESTABLISHED | 連接已建立 | | CLOSE_WAIT | 遠(yuǎn)程套接字已經(jīng)關(guān)閉:正在等待關(guān)閉這個(gè)套接字[被動(dòng)關(guān)閉的一方收到FIN] | | FIN_WAIT_1 | 套接字已關(guān)閉,正在關(guān)閉連接[發(fā)送FIN,沒有收到ACK也沒有收到FIN] | | CLOSING | 套接字已關(guān)閉,遠(yuǎn)程套接字正在關(guān)閉,暫時(shí)掛起關(guān)閉確認(rèn)[在FIN_WAIT_1狀態(tài)下收到被動(dòng)方的FIN] | | LAST_ACK | 遠(yuǎn)程套接字已關(guān)閉,正在等待本地套接字的關(guān)閉確認(rèn)[被動(dòng)方在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 | 這個(gè)套接字已經(jīng)關(guān)閉,正在等待遠(yuǎn)程套接字的關(guān)閉傳送[FIN、ACK、FIN、ACK都完畢,這是主動(dòng)方的最后一個(gè)狀態(tài),在過了2MSL時(shí)間后變?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)線拔了的時(shí)候,客戶端發(fā)送SYN過去就會(huì)收不到ACK,因此就會(huì)出現(xiàn)這個(gè)錯(cuò)誤,1分鐘內(nèi)就會(huì)返 回這個(gè)錯(cuò)誤。 errno=111(ECONNREFUSED),當(dāng)服務(wù)器未listen時(shí),就會(huì)報(bào)這個(gè)錯(cuò) 2.2.2 ESTABLISHED不一定真的establish 會(huì)出現(xiàn)這種情況:client為ESTABLISHED狀態(tài)而server為SYN_REVD狀態(tài)。 這是因?yàn)長INUX不像其他操作系統(tǒng)在收到SYN為該連接立馬分配一塊內(nèi)存空間用于存儲(chǔ)相關(guān)的數(shù)據(jù)和結(jié)構(gòu),而是延遲到接收到client的ACK,即三次握手 真正完成后才分配空間,這是為了防范SYN flooding攻擊。 如果是這種情況,那么就會(huì)出現(xiàn)client端未ESTABLISHED狀態(tài),server為SYN_RECV狀態(tài)。 并且server的SYN_RECV狀態(tài)在一定時(shí)間后會(huì)消失,client的established狀態(tài)也會(huì)消失。這是因?yàn)閟erver在SYN_RECV狀態(tài)時(shí),會(huì)像client發(fā)送多次的SYN+ACK(因?yàn)樗詾樽约旱倪@個(gè)包對方?jīng)]收到),發(fā)送的次數(shù)定義在/proc/sys/net/ipv4/tcp_synack_retries中,默認(rèn)為5.在發(fā)送5次之后還沒有收到ACK,就將其回收了,所以用netstat查看就看不到這個(gè)SYN_RECV狀態(tài)了。并且會(huì)像client發(fā)送RST信號(hào)。這就會(huì)導(dǎo)致client的這種半連接最后也會(huì)消失。這個(gè)可以通過tcpdump抓包得到(最好知道src這樣看到的包比較集中)。
|