tcp斷開四次握手

2021-05-22 13:32:52 字數 1200 閱讀 9244

1 a: 獨奏大哥我給你發蒼井空經典合集都發完了(fin)

2 b: 恩..都收到了..(ack)

3 b: 那今天就到這嘍,下次要有好的記得分享哦..(fin)

4 a: 恩.好的...(ack)

這就是tcp四次握手斷開的過程.那可能有人會有疑問.在tcp連線握手時為何 ack是和syn一起傳送.這裡ack卻沒有何fin一起傳送呢.

原因是因為tcp是全雙工模式.接收到fin時意味將沒有資料再發來..但是還是可以繼續傳送資料..

下面我們來把這幅圖幾個狀態說明下

listen : 監聽狀態.

syn_sent : 已傳送syn同步會變為這個狀態.等待服務端的syn和ack確認.

syn_recv: 當收到客戶端的syn時變為此狀態.這時將傳送syn及這個報文的ack(合併syn+ack)

establishen: 雙方連線建立

fin_wait_1: 當準備關閉連線時,將進入這個狀態並傳送fin.確認後會變為fin_wait_2

fin_wait_2: 實際這個狀態就是在客戶端傳送fin並得到確認後等待服務端的fin報文

close_wait: 當被動關閉方收到fin時會遷移到這個狀態.如果此時應用層所有資料都已傳送完畢則.遷移到last_ack並傳送fin給客戶端,並等待客戶端的最後確認,如果在一定時間內沒有收到最後的ack確認則服務端會重新傳送fin.直到傳送超時.直接關閉連線.

last_ack :服務端傳送fin後等待客戶端的最後確認.收到確認後則雙方資料流均關閉可以關閉了此連線了

time_wait: 當客戶端吧收到被動關閉方的fin後意味只要傳送最後一ack就可以最終關閉連線.那為何傳送ack後不直接關閉連線而是保持在time_wait呢.按上面說的如果客戶端傳送的最後乙個ack由於網路原因沒有到達服務端.服務端會重新傳送fin.time_wait就是為了接受服務端重新傳送的fin,並重發丟失的ack報文..這個狀態持續時間會有2msl,msl就是乙個報文在被丟棄前網路上的最長時間..tcpip協議卷上說 msl會有兩分鐘....具體的可能跟實現不同.我就不知道了..沒測試過嘍..o(∩_∩)o~

closed: 連線關閉

還有個closeing狀態是在同時關閉時,當客戶端傳送fin後進入fin_wait_1等待服務端的ack.這時接受的卻不是ack,而是服務端傳送的fin,這種情況一般是當雙發同時傳送fin.會進入closing狀態.隨機收到各自的ack後雙發都會進入time_wait狀態

TCP四次握手斷開連線

建立連線非常重要,它是資料正確傳輸的前提 斷開連線同樣重要,它讓計算機釋放不再使用的資源。如果連線不能正常斷開,不僅會造成資料傳輸錯誤,還會導致套接字不能關閉,持續占用資源,如果併發量高,伺服器壓力堪憂。建立連線需要三次握手,斷開連線需要四次握手,可以形象的比喻為下面的對話 下圖演示了客戶端主動斷開...

tcp 三次握手連線,四次握手斷開

tcp握手協議 在tcp ip協議中,tcp協議提供可靠的連線服務,採用三次握手建立乙個連線.第一次握手 建立連線時,客戶端傳送syn包 syn j 到伺服器,並進入syn send狀態,等待伺服器確認 syn 同步序列編號 synchronize sequence numbers 第二次握手 伺服...

TCP斷開連線的四次握手流程

1.客戶端向服務端傳送乙個fin包m,然後進入fin wait狀態。m為請求序號 正確理解為 fin 1,seq m 2.服務端接收到fin包,傳送乙個ack應答,ack 1,ack m 1給客戶端,然後服務端進入close wait狀態 3.服務端向客戶傳送乙個fin包n,然後進入lask ack...