TIME_WAIT為什么持續(xù)兩個(gè)MSL(報(bào)文段最大生存時(shí)間)
TIME_WAIT 為主動(dòng)關(guān)閉的一方所出現(xiàn)的狀態(tài)，上圖為客戶(hù)端主動(dòng)關(guān)閉，假如客戶(hù)端不維護(hù) TIME_WAIT 為兩個(gè)MSL周期，可能會(huì)出現(xiàn)一下兩個(gè)不正常的情況
- 如果最后一個(gè) ACK 丟失了，Server 會(huì)重新發(fā)送 FIN 信號(hào)，而這時(shí) Client 已經(jīng)處于 CLOSED 狀態(tài)，Client 將會(huì)響應(yīng) RST, 從而導(dǎo)致 Server 非正常關(guān)閉。
- 如果斷開(kāi)連接之后，Client 又重新和 Server 建立新的連接，如果此時(shí)上一次連接的延遲的 ACK 又重新出現(xiàn)，會(huì)干擾新的連接。
當(dāng)然 TIME_WAIT 持續(xù)兩個(gè)MSL 周期，并不能完全解決以上不正常情況的發(fā)生。 但是還是要 “心懷感恩”，畢竟給了你兩個(gè)MSL周期，已經(jīng)足夠 ”仁慈“了。哈哈。
TIME_WAIT的危害
系統(tǒng)分配給進(jìn)程的文件句柄的個(gè)數(shù)是有限制的，一般TIME_WAIT的時(shí)間長(zhǎng)大概是1-4分鐘，尤其像http服務(wù)器這種面向短連接的進(jìn)程，會(huì)產(chǎn)生大量的TIME_WAIT狀態(tài)，一旦文件句柄的數(shù)目到達(dá)上限，新的請(qǐng)求就無(wú)法進(jìn)行處理了，而且大量的TIME_WAIT狀態(tài)占用資源影響性能。
TCP 為什么三次握手
1.為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
比如下面這種情況：
client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來(lái)這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來(lái)數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒(méi)有要求建立連接
2.信道不可靠, 但是通信雙發(fā)需要就某個(gè)問(wèn)題達(dá)成一致. 而要解決這個(gè)問(wèn)題, 無(wú)論你在消息中包含什么信息, 三次通信是理論上的最小值。
net.ipv4.tcp_tw_reuse = 1表示開(kāi)啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_recycle = 1表示開(kāi)啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。
