四次揮手

tcp協議的三次握手是通信雙方建立連接的程序，而四次揮手其實就是通信雙方斷開連接時要經歷的程序，而在通信雙反斷開連接時，無論是客戶端先關閉（呼叫close函式，向服務端發送FIN），還是服務端先關閉（呼叫close函式，向客戶端發送FIN）都要經歷四次握手這個階段，
客戶端：

在這里插入圖片描述

服務端：
在這里插入圖片描述
對于四次揮手，個人覺得和我們平時下班還挺像的，就比如說你和你的老板讓你處理一件作業，快下班了，老板說他快下班了，你的把你處理的作業進度給你的老板說，并詢問自己是否可以下班，當他同意了你才可以下班一樣：
在這里插入圖片描述

四次揮手時客戶端與服務端的狀態轉變

服務端：

狀態	解釋
ESTABLISHED -> CLOSE_WAIT	當客戶端主動關閉連接(呼叫close), 服務器會收到結束報文段, 服務器回傳確認報文段并進入CLOSE_WAIT;
CLOSE_WAIT -> LAST_ACK	進入CLOSE_WAIT后說明服務器準備關閉連接(需要處理完之前的資料); 當服務器真正呼叫close關閉連接時, 會向客戶端發送FIN, 此時服務器進入LAST_ACK狀態, 等待最后一個ACK到來(這個ACK是客戶端確認收到了FIN)
LAST_ACK -> CLOSED	服務器收到了對FIN的ACK, 徹底關閉連接

客戶端：

狀態	解釋
ESTABLISHED -> FIN_WAIT_1	客戶端主動呼叫close時, 向服務器發送結束報文段, 同時進入FIN_WAIT_1;
FIN_WAIT_1 -> FIN_WAIT_2	客戶端收到服務器對結束報文段的確認, 則進入FIN_WAIT_2, 開始等待服務器的結束報文段;
FIN_WAIT_2 -> TIME_WAIT	客戶端收到服務器發來的結束報文段, 進入TIME_WAIT, 并發出LAST_ACK;
TIME_WAIT -> CLOSED	客戶端要等待一個2MSL(Max Segment Life, 報文最大生存時間)的時間, 才會進入CLOSED狀態.

理解為什么TIME_WAIT的時間是2MSL

上面我們看到在斷開連接的一方進入TIME_WAIT后等待了2MSL的時間，那么他為什么要等待2MSL的時間呢，要來解釋清楚這個問題，我i們需要理解
（1）MSL表示的是報文的最大生存時間（在網路中資料包理論上的最大生存時間）
（2）對于斷開連接的一方而言（這里以客戶端為例子），客戶端還是處于TIME_WAIT狀態，并切在等待2MSL的時間；
（3）對于被斷開連接的一方（這里以服務端為例）而言，服務端不清楚FIN報文是否達到客戶端，服務端在發送FIN報文之后，就會開啟超時重傳，
那么現在我們假設主動斷開連接方（客戶端）只等待一個MSL，就將自己的狀態設定成CLOSED狀態，并且回傳的ACK還丟失掉了，那么這個時候客戶端的狀態已經為CLOSED狀態了，而服務端狀態由于還沒有收到ACK，將繼續維持在LASK_ACK狀態，而此時服務端開始重新發送FIN報文，但是由于客戶端已經是CLOSED狀態了，不會再去處理該連接上的資料了，客戶端機器會給服務端發送一個RST報文（連接重置報文），
其實這個現象也可以用上面我們老板和員工的例子來模擬一下的，假如老板最后給員工發送下班的資訊中途因為某種原因丟失了，導致員工一直在等待下班的指令（假設員工只能在收到下班指令后才能下班，除非老板已經下班），時間長了員工由于不知道老板是否已經下班了就會懷疑老板沒有收到剛才的訊息，再次向老板發送作業完成的訊息，此時員工會受到老板已經下班的訊息，要想給他提交資料的話只能等明天上班（建立連接），
而2MSL其實就是丟失ACK的MSL+重傳FIN報文的MSL

如果服務端或者客戶端突然崩潰，會怎樣

在日常生活中可能會出現突然斷電的情況，突然斷電就意味著網路不能正常作業了，行程會崩潰，來不急呼叫close，也就是說我們沒有向對端發送FIN，但是自己已經關閉了，這種情況下會怎樣呢？
保活計時器：在網路協議堆疊的TCP協議當中，設計了一種心跳包，當連接雙方沒有資料往來的時候，超出保活計數器的時間之后，就會給對方發送心跳包（心跳包是TCP協議處理的，并不會交給應用層程式處理）；如果對方沒有收到心跳包，連續發送10次心跳包，如果10次都沒有收到確認回復，則認為對端已經不存在了，關閉連接；如果收到了對方發送的確認包，則認為連接是正常的，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/273271.html

標籤：其他

上一篇：用大白話和面試官扯“八大常用排序演算法的基本思想”

下一篇：SNMP實作交換機的資訊采集——MIB