TCP 是一種要求資料正確性的傳輸方式,
這表示它需要一些特殊機制,
來確保傳輸的數據不會出錯。
其中就包含了建立連結
與終止連結的縝密運行機制,
也就是三次握手與四次揮手。
建立連線的三次通訊
順序 | 客戶狀態 | 行為 | 伺服器狀態 |
---|---|---|---|
1 | 發起請求 | 傳送 Greeting → | 聆聽/待命中 |
2 | 等候確認 | 收到訊息 | |
3 | 等候確認 | ← 傳送回應表示收到 | 回覆請求 |
4 | 收到回覆 | 等待確認 | |
5 | 確認收到 | 傳送回應表示收到 → | 等候確認 |
5 | 確認收到 | 確認收到 | |
5 | 通訊建立成功 | 通訊建立成功 |
以上三次訊息傳遞後,
就能讓 Client 端和 Server 端,
確認彼此都能收到對方的訊息。
三次握手的用途
想像成兩人在講電話的話就類似於:
A:「喂?有聽到嗎?」
B:「有聽到喔,你那邊聽得到我聲音嗎?」
A:「可以喔。」
對建立可靠的通訊來說,
三次握手是一種非常具體可行的方法。
終止連線的四次揮手
同樣用電話模擬的話如下:
A:「我沒什麼要說的了,要掛囉?」
B:「喔,你要結束通話啦?」
B:「嗯我要跟你說的都說完了,就掛吧。」
A:「那掛囉,BYE。」
其中 Server 方的第二和第三次揮手,
之所以分為兩次進行,
是因為此時 Client 方的連結
處於「半關閉」的狀態,
也就是可以收聽但無法傳輸資料。
所以 Server 會先回覆已收到終止連線的訊息,
表示斷開連線的請求已經受理,
並向上層確認沒有要發給 Client 的資料後,
才對 Client 回覆斷開連線,
這就是第二次和第三次揮手的功能。
為何第四次揮手後需要等待,
大致有以下原因:
是為了避免由於網路延遲等關係,
在關閉連接後,又再度收到前次通話的封包,
此時如果客戶端已經開始進行新的連線,
在新數據傳輸的情況下收到舊數據,
會出現資料錯亂的問題。
所以會等候一段時間,
讓可能沒收到的封包都自然死亡,
如此才能確保新建立的連結沒有問題。
如果 Client 端發送的第四次揮手沒有被收到,
則 Server 端會繼續保持連接狀態,
此時如果 Client 未等候直接發起新連接,
仍處於連線狀態正在等候回覆的 Server 端,
可能會回覆中止連接通知,
並直接關閉本次連接,讓新的連接失敗。