什么是四次揮手?
1. 主動(dòng)斷開方(客戶端/服務(wù)端)-發(fā)送一個(gè) FIN，用來關(guān)閉主動(dòng)斷開方(客戶端/服務(wù)端)到被動(dòng)斷開方(客戶端/服務(wù)端)的數(shù)據(jù)傳送
2. 被動(dòng)斷開方(客戶端/服務(wù)端)-收到這個(gè) FIN，它發(fā)回一 個(gè) ACK，確認(rèn)序號(hào)為收到的序號(hào)加1 。和 SYN 一樣，一個(gè) FIN 將占用一個(gè)序號(hào)
3. 被動(dòng)斷開方(客戶端/服務(wù)端)-關(guān)閉與主動(dòng)斷開方(客戶端/服務(wù)端)的連接，發(fā)送一個(gè)FIN給主動(dòng)斷開方(客戶端/服務(wù)端)
4. 主動(dòng)斷開方(客戶端/服務(wù)端)-發(fā)回 ACK 報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1
為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手?
1. 建立連接的時(shí)候， 服務(wù)器在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。
2. 關(guān)閉連接時(shí)，服務(wù)器收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了,所以服務(wù)器可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來表示同意現(xiàn)在關(guān)閉連接。因此，服務(wù)器ACK和FIN一般都會(huì)分開發(fā)送，從而導(dǎo)致多了一次。
為什么TCP揮手每兩次中間有一個(gè) FIN-WAIT2等待時(shí)間?
主動(dòng)關(guān)閉的一端調(diào)用完close以后(即發(fā)FIN給被動(dòng)關(guān)閉的一端， 并且收到其對(duì)FIN的確認(rèn)ACK)則進(jìn)入FIN_WAIT_2狀態(tài)。如果這個(gè)時(shí)候因?yàn)榫W(wǎng)絡(luò)突然斷掉、被動(dòng)關(guān)閉的一段宕機(jī)等原因，導(dǎo)致主動(dòng)關(guān)閉的一端不能收到被動(dòng)關(guān)閉的一端發(fā)來的FIN(防止對(duì)端不發(fā)送關(guān)閉連接的FIN包給本端)，這個(gè)時(shí)候就需要FIN_WAIT_2定時(shí)器， 如果在該定時(shí)器超時(shí)的時(shí)候，還是沒收到被動(dòng)關(guān)閉一端發(fā)來的FIN，那么直接釋放這個(gè)鏈接，進(jìn)入CLOSE狀態(tài)。
為什么客戶端最后還要等待2MSL?為什么還有個(gè)TIME-WAIT的時(shí)間等待?
1. 保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文能夠到達(dá)服務(wù)器，因?yàn)檫@個(gè)ACK報(bào)文可能丟失，服務(wù)器已經(jīng)發(fā)送了FIN+ACK報(bào)文，請(qǐng)求斷開，客戶端卻沒有回應(yīng)，于是服務(wù)器又會(huì)重新發(fā)送一次，而客戶端就能在這個(gè)2MSL時(shí)間段內(nèi)收到這個(gè)重傳的報(bào)文，接著給出回應(yīng)報(bào)文，并且會(huì)重啟2MSL計(jì)時(shí)器。
2. 防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個(gè)確認(rèn)報(bào)文后，在這個(gè)2MSL時(shí)間中，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，這樣新的連接中不會(huì)出現(xiàn)舊連接的請(qǐng)求報(bào)文。
3. 2MSL，最大報(bào)文生存時(shí)間，一個(gè)MSL 30 秒，2MSL = 60s
客戶端 TIME-WAIT 狀態(tài)過多會(huì)產(chǎn)生什么后果?怎樣處理?
1. 作為服務(wù)器，短時(shí)間內(nèi)關(guān)閉了大量的Client連接，就會(huì)造成服務(wù)器上出現(xiàn)大量的TIME_WAIT連接，占據(jù)大量的tuple /tApl/ ，嚴(yán)重消耗著服務(wù)器的資源，此時(shí)部分客戶端就會(huì)顯示連接不上
2. 作為客戶端，短時(shí)間內(nèi)大量的短連接，會(huì)大量消耗的Client機(jī)器的端口，畢竟端口只有65535個(gè)，端口被耗盡了，后續(xù)就無法在發(fā)起新的連接了
3. 在高并發(fā)短連接的TCP服務(wù)器上，當(dāng)服務(wù)器處理完請(qǐng)求后立刻主動(dòng)正常關(guān)閉連接。這個(gè)場景下會(huì)出現(xiàn)大量socket處于TIME_WAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時(shí)部分客戶端就會(huì)顯示連接不上
高并發(fā)可以讓服務(wù)器在短時(shí)間范圍內(nèi)同時(shí)占用大量端口，而端口有個(gè)0~65535的范圍，并不是很多，刨除系統(tǒng)和其他服務(wù)要用的，剩下的就更少了短連接表示“業(yè)務(wù)處理+傳輸數(shù)據(jù)的時(shí)間 遠(yuǎn)遠(yuǎn)小于 TIMEWAIT超時(shí)的時(shí)間”的連接
4. 解決方法：
用負(fù)載均衡來抗這些高并發(fā)的短請(qǐng)求; 服務(wù)器可以設(shè)置 SO_REUSEADDR 套接字選項(xiàng)來避免 TIME_WAIT狀態(tài)，TIME_WAIT 狀態(tài)可以通過優(yōu)化服務(wù)器參數(shù)得到解決，因?yàn)榘l(fā)生TIME_WAIT的情況是服務(wù)器自己可控的，要么就是對(duì)方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯(cuò)誤導(dǎo)致的強(qiáng)制關(guān)閉，發(fā)送 RST 包越過TIMEWAIT狀態(tài)，直接進(jìn)入CLOSED狀態(tài)
服務(wù)器出現(xiàn)了大量 CLOSE_WAIT 狀態(tài)如何解決?
大量 CLOSE_WAIT 表示程序出現(xiàn)了問題，對(duì)方的 socket 已經(jīng)關(guān)閉連接，而我方忙于讀或?qū)憶]有及時(shí)關(guān)閉連接，需要檢查代碼，特別是釋放資源的代碼，或者是處理請(qǐng)求的線程配置。
服務(wù)端會(huì)有一個(gè)TIME_WAIT狀態(tài)嗎?如果是服務(wù)端主動(dòng)斷開連接呢?
1. 發(fā)起鏈接的主動(dòng)方基本都是客戶端，但是斷開連接的主動(dòng)方服務(wù)器和客戶端都可以充當(dāng)，也就是說，只要是主動(dòng)斷開連接的，就會(huì)有 TIME_WAIT狀態(tài)
2. 四次揮手是指斷開一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開。在socket編程中，這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā)
3. 由于TCP連接時(shí)全雙工的，因此，每個(gè)方向的數(shù)據(jù)傳輸通道都必須要單獨(dú)進(jìn)行關(guān)閉
京公網(wǎng)安備 11010802030320號(hào)