iT邦幫忙

2021 iThome 鐵人賽

DAY 26
1
自我挑戰組

前端補給站,每天一個知識點系列 第 26

Day25【Web】TCP 連線與斷線:三次握手、四次揮手

  • 分享至 

  • xImage
  •  

TCP 是一種要求資料正確性的傳輸方式,
這表示它需要一些特殊機制,
來確保傳輸的數據不會出錯。

其中就包含了建立連結
與終止連結的縝密運行機制,
也就是三次握手四次揮手


三次握手(Three-way Handshake)

建立連線的三次通訊

順序 客戶狀態 行為 伺服器狀態
1 發起請求 傳送 Greeting → 聆聽/待命中
2 等候確認 收到訊息
3 等候確認 ← 傳送回應表示收到 回覆請求
4 收到回覆 等待確認
5 確認收到 傳送回應表示收到 → 等候確認
5 確認收到 確認收到
5 通訊建立成功 通訊建立成功

以上三次訊息傳遞後,
就能讓 Client 端和 Server 端,
確認彼此都能收到對方的訊息。

三次握手的用途
想像成兩人在講電話的話就類似於:

A:「喂?有聽到嗎?」
B:「有聽到喔,你那邊聽得到我聲音嗎?」
A:「可以喔。」

對建立可靠的通訊來說,
三次握手是一種非常具體可行的方法。


四次揮手(Four-Way Wavehand)

終止連線的四次揮手

同樣用電話模擬的話如下:

A:「我沒什麼要說的了,要掛囉?」
B:「喔,你要結束通話啦?」
B:「嗯我要跟你說的都說完了,就掛吧。」
A:「那掛囉,BYE。」

其中 Server 方的第二和第三次揮手,
之所以分為兩次進行,
是因為此時 Client 方的連結
處於「半關閉」的狀態,
也就是可以收聽但無法傳輸資料。

所以 Server 會先回覆已收到終止連線的訊息,
表示斷開連線的請求已經受理,
並向上層確認沒有要發給 Client 的資料後,
才對 Client 回覆斷開連線,
這就是第二次和第三次揮手的功能。


第四次揮手後的等待

為何第四次揮手後需要等待,
大致有以下原因:

避免收到舊資料

是為了避免由於網路延遲等關係,
在關閉連接後,又再度收到前次通話的封包,
此時如果客戶端已經開始進行新的連線,
在新數據傳輸的情況下收到舊數據,
會出現資料錯亂的問題。
所以會等候一段時間,
讓可能沒收到的封包都自然死亡,
如此才能確保新建立的連結沒有問題。

確保連接正確關閉

如果 Client 端發送的第四次揮手沒有被收到,
則 Server 端會繼續保持連接狀態,
此時如果 Client 未等候直接發起新連接,
仍處於連線狀態正在等候回覆的 Server 端,
可能會回覆中止連接通知,
並直接關閉本次連接,讓新的連接失敗。


參考資料


上一篇
Day24【Web】網路傳輸協定:TCP 與 UDP
下一篇
Day26【Web】TCP 安全協定:SSL/TLS
系列文
前端補給站,每天一個知識點30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言