什么是四次揮手?

　　1. 主動斷開方(客戶端/服務(wù)端)-發(fā)送一個 FIN，用來關(guān)閉主動斷開方(客戶端/服務(wù)端)到被動斷開方(客戶端/服務(wù)端)的數(shù)據(jù)傳送

　　2. 被動斷開方(客戶端/服務(wù)端)-收到這個 FIN，它發(fā)回一 個 ACK，確認(rèn)序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將占用一個序號

　　3. 被動斷開方(客戶端/服務(wù)端)-關(guān)閉與主動斷開方(客戶端/服務(wù)端)的連接，發(fā)送一個FIN給主動斷開方(客戶端/服務(wù)端)

　　4. 主動斷開方(客戶端/服務(wù)端)-發(fā)回 ACK 報文確認(rèn)，并將確認(rèn)序號設(shè)置為收到序號加1

　　為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手?

　　1. 建立連接的時候， 服務(wù)器在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端。

　　2. 關(guān)閉連接時，服務(wù)器收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對方了,所以服務(wù)器可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接。因此，服務(wù)器ACK和FIN一般都會分開發(fā)送，從而導(dǎo)致多了一次。

　　為什么TCP揮手每兩次中間有一個 FIN-WAIT2等待時間?

　　主動關(guān)閉的一端調(diào)用完close以后(即發(fā)FIN給被動關(guān)閉的一端， 并且收到其對FIN的確認(rèn)ACK)則進(jìn)入FIN_WAIT_2狀態(tài)。如果這個時候因?yàn)榫W(wǎng)絡(luò)突然斷掉、被動關(guān)閉的一段宕機(jī)等原因，導(dǎo)致主動關(guān)閉的一端不能收到被動關(guān)閉的一端發(fā)來的FIN(防止對端不發(fā)送關(guān)閉連接的FIN包給本端)，這個時候就需要FIN_WAIT_2定時器， 如果在該定時器超時的時候，還是沒收到被動關(guān)閉一端發(fā)來的FIN，那么直接釋放這個鏈接，進(jìn)入CLOSE狀態(tài)。

　　為什么客戶端最后還要等待2MSL?為什么還有個TIME-WAIT的時間等待?

　　1. 保證客戶端發(fā)送的最后一個ACK報文能夠到達(dá)服務(wù)器，因?yàn)檫@個ACK報文可能丟失，服務(wù)器已經(jīng)發(fā)送了FIN+ACK報文，請求斷開，客戶端卻沒有回應(yīng)，于是服務(wù)器又會重新發(fā)送一次，而客戶端就能在這個2MSL時間段內(nèi)收到這個重傳的報文，接著給出回應(yīng)報文，并且會重啟2MSL計時器。

　　2. 防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失，這樣新的連接中不會出現(xiàn)舊連接的請求報文。

　　3. 2MSL，最大報文生存時間，一個MSL 30 秒，2MSL = 60s

　　客戶端 TIME-WAIT 狀態(tài)過多會產(chǎn)生什么后果?怎樣處理?

　　1. 作為服務(wù)器，短時間內(nèi)關(guān)閉了大量的Client連接，就會造成服務(wù)器上出現(xiàn)大量的TIME_WAIT連接，占據(jù)大量的tuple /tApl/ ，嚴(yán)重消耗著服務(wù)器的資源，此時部分客戶端就會顯示連接不上

　　2. 作為客戶端，短時間內(nèi)大量的短連接，會大量消耗的Client機(jī)器的端口，畢竟端口只有65535個，端口被耗盡了，后續(xù)就無法在發(fā)起新的連接了

　　3. 在高并發(fā)短連接的TCP服務(wù)器上，當(dāng)服務(wù)器處理完請求后立刻主動正常關(guān)閉連接。這個場景下會出現(xiàn)大量socket處于TIME_WAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時部分客戶端就會顯示連接不上

　　高并發(fā)可以讓服務(wù)器在短時間范圍內(nèi)同時占用大量端口，而端口有個0~65535的范圍，并不是很多，刨除系統(tǒng)和其他服務(wù)要用的，剩下的就更少了短連接表示“業(yè)務(wù)處理+傳輸數(shù)據(jù)的時間 遠(yuǎn)遠(yuǎn)小于 TIMEWAIT超時的時間”的連接

　　4. 解決方法：

　　用負(fù)載均衡來抗這些高并發(fā)的短請求; 服務(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ù)器自己可控的，要么就是對方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯誤導(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)了問題，對方的 socket 已經(jīng)關(guān)閉連接，而我方忙于讀或?qū)憶]有及時關(guān)閉連接，需要檢查代碼，特別是釋放資源的代碼，或者是處理請求的線程配置。

　　服務(wù)端會有一個TIME_WAIT狀態(tài)嗎?如果是服務(wù)端主動斷開連接呢?

　　1. 發(fā)起鏈接的主動方基本都是客戶端，但是斷開連接的主動方服務(wù)器和客戶端都可以充當(dāng)，也就是說，只要是主動斷開連接的，就會有 TIME_WAIT狀態(tài)

　　2. 四次揮手是指斷開一個TCP連接時，需要客戶端和服務(wù)端總共發(fā)送4個包以確認(rèn)連接的斷開。在socket編程中，這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā)

　　3. 由于TCP連接時全雙工的，因此，每個方向的數(shù)據(jù)傳輸通道都必須要單獨(dú)進(jìn)行關(guān)閉