【Java面試題】之三次握手和四次揮手
本文內容大部分轉載自:http://blog.csdn.net/whuslei/article/details/6667471/
原文獲得了54萬的閱讀量,說明改文章的質量很高
同時,博主在原文的基礎上也補充了一些內容
建立TCP需要三次握手才能建立,而斷開連線則需要四次握手。整個過程如下圖所示:
先來看看如何建立連線的。
【更新於2017.01.04 】該部分內容配圖有誤,請大家見諒,正確的配圖如下,錯誤配圖也不刪了,大家可以比較下,對比理解效果更好。這麼久才來更新,抱歉!!
錯誤配圖如下:
首先Client端傳送連線請求報文,Server段接受連線後回覆ACK報文,併為這次連線分配資源。Client端接收到ACK報文後也向Server段發生ACK報文,並分配資源,這樣TCP連線就建立了。(注意:第二次客戶端的SYN標誌位為0)
這裡補充一下,為什麼客戶機還要再傳送一次確認呢?
答:這主要是為了防止以失效的連結請求報文段突然又傳送到了服務端,因而產生了錯誤。
所謂“已失效的連線請求報文段”是這樣產生的。
考慮一種情況。客戶端發出連線請求,但因為連線請求丟失而未收到確認。於是客戶端會再重傳一次連線請求。
後來收到了確認,建立了連線。
資料傳輸完畢後,就釋放了連線。客戶端一共傳送了兩個連線請求報文段,其中第一個丟失,第二個到達了服務端。沒有“已失效的連線請求報文段”。
現在假定一種異常情況,即客戶端發出的第一個連線請求報文段並沒有丟失,而是在某些網路節點長時間滯留了,以致延誤到連線釋放以後的某個時間才到達服務端。
本來這是一個早已失效的請求報文段。但服務端收到此失效的連線請求報文段後,就誤以為客戶端又發出了一次連線請求。
於是向A發出確認報文段,同意建立連線。
假定不採用三次握手,那麼只要服務端發出確認,新的連線就建立了。這顯然是不行的。
由於現在客戶端並沒有發出建立連線的請求,因此不會理睬服務端的確認,也不會向服務端傳送資料。
但是服務端卻以為新的傳輸連線已經建立,並一直等待客戶端發來的資料。服務端的許多資源就是這樣白白浪費了
那如何斷開連線呢?簡單的過程如下:
【注意】中斷連線端可以是Client端,也可以是Server端。
假設Client端發起中斷連線請求,也就是傳送FIN報文。Server端接到FIN報文後,意思是說"我Client端沒有資料要發給你了",但是如果你還有資料沒有傳送完成,則不必急著關閉Socket,可以繼續傳送資料。所以你先傳送ACK,"告訴Client端,你的請求我收到了,但是我還沒準備好,請繼續你等我的訊息"。這個時候Client端就進入FIN_WAIT狀態,繼續等待Server端的FIN報文。當Server端確定資料已傳送完成,則向Client端傳送FIN報文,"告訴Client端,好了,我這邊資料發完了,準備好關閉連線了"。Client端收到FIN報文後,"就知道可以關閉連線了,但是他還是不相信網路,怕Server端不知道要關閉,所以傳送ACK後進入TIME_WAIT狀態,如果Server端沒有收到ACK則可以重傳。“,Server端收到ACK後,"就知道可以斷開連線了"。Client端等待了2MSL後依然沒有收到回覆,則證明Server端已正常關閉,那好,我Client端也可以關閉連線了。Ok,TCP連線就這樣關閉了!
整個過程Client端所經歷的狀態如下:
而Server端所經歷的過程如下:轉載請註明:blog.csdn.net/whuslei
【注意】 在TIME_WAIT狀態中,如果TCP client端最後一次傳送的ACK丟失了,它將重新傳送。TIME_WAIT狀態中所需要的時間是依賴於實現方法的。典型的值為30秒、1分鐘和2分鐘。等待之後連線正式關閉,並且所有的資源(包括埠號)都被釋放。
【問題1】為什麼連線的時候是三次握手,關閉的時候卻是四次握手?
答:因為當Server端收到Client端的SYN連線請求報文後,可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來同步的。但是關閉連線時,當Server端收到FIN報文時,很可能並不會立即關閉SOCKET,所以只能先回復一個ACK報文,告訴Client端,"你發的FIN報文我收到了"。只有等到我Server端所有的報文都傳送完了,我才能傳送FIN報文,因此不能一起傳送。故需要四步握手。
【問題2】為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態?
答:雖然按道理,四個報文都傳送完畢,我們可以直接進入CLOSE狀態了,但是我們必須假象網路是不可靠的,有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
相關文章
- TCP三次握手和四次揮手TCP
- 正本清源:TCP協議之三次握手和四次揮手TCP協議
- TCP三次握手和四次揮手理解TCP
- 面試官,不要再問我三次握手和四次揮手面試
- TCP:三次握手和四次揮手,面試無死角答覆TCP面試
- TCP三次握手四次揮手TCP
- TCP三次握手&四次揮手TCP
- TCP 三次握手四次揮手TCP
- 簡述TCP三次握手和四次揮手TCP
- HTTP協議三次握手和四次揮手HTTP協議
- TCP的三次握手,四次揮手及常見面試題詳解TCP面試題
- TCP 三次握手 與 四次揮手TCP
- TCP 、 UDP、三次握手、四次揮手TCPUDP
- TCP三次握手與四次揮手TCP
- TCP的三次握手四次揮手TCP
- 面試官問我TCP三次握手和四次揮手,我真的是面試TCP
- 說說TCP的三次握手和四次揮手TCP
- 圖解TCP的三次握手和四次揮手圖解TCP
- TCP協議的三次握手和四次揮手TCP協議
- TCP 三次握手和四次揮手及其狀態TCP
- TCP的三次握手與四次揮手TCP
- TCP三次握手四次揮手介紹TCP
- TCP三次握手及四次揮手理解TCP
- TCP-三次握手和四次揮手簡單理解TCP
- TCP協議特點和三次握手/四次揮手TCP協議
- 跟著動畫學TCP三次握手和四次揮手動畫TCP
- 看圖理解TCP的三次握手和四次揮手TCP
- 詳解TCP一:三次握手、四次揮手TCP
- tcp三次握手、四次揮手過程解析TCP
- 【網路】TCP協議中三次握手和四次揮手TCP協議
- 談談TCP協議的三次握手和四次揮手TCP協議
- 詼諧的談談TCP三次握手和四次揮手TCP
- 網路協議 - TCP/IP 三次握手和四次揮手協議TCP
- 跟著動畫學習 TCP 三次握手和四次揮手動畫TCP
- TCP連線為什麼三次握手和四次揮手TCP
- 面試必問之 TCP/IP協議的三次握手 四次揮手面試TCP協議
- 關於三次握手和四次揮手,面試官想聽到怎樣的回答?面試
- Wireshark抓包分析TCP“三次握手,四次揮手”TCP