TCP/IP協議棧
應用層
DNS協議
傳輸層
TCP協議
TCP協議報文結構
- 源埠
- 目的埠
- 序列號
- 確認號
- 頭長度
header length or data offset - 保留欄位
reserved - 狀態欄位
- URG
- ACK
- PSH
- RST
- SYN
- FIN
- 視窗欄位
- 校驗和
- 緊急指標
- 可選欄位
- 資料
TCP協議三次握手
TCP三次握手是一個老生常談的問題。為了方便理解，我們首先來模擬A基地和B基地通訊的問題，核心的問題是A基地和B基地如何確認雙方的傳送和接收能力。
首先，我們要去掉上帝視角、沉浸進去扮演一個角色。我們是A基地，現在我們想和B基地建立通訊，首先我們給B基地發一個“hello”，等待B基地的回覆。這時候B基地在收到我們的資訊之後，回發一個“我收到了你的資訊”。我們A基地收到B基地的回覆“我收到了你的資訊”之後，我們就能知道B基地的接收和傳送能力都沒有問題。但是站在B基地的視角，B基地不知道我們是否收到這條回發訊息，所以此時B基地出於安全考慮就不會發訊息，因為他們無法確定我們A基地是否有接收能力，B基地只能夠知道A基地有傳送能力。所以需要我們再發一次“我們收到了你的回覆”資訊給B基地。B基地在收到我們的回發訊息就能夠確認我們A基地收到了回覆，這樣B基地就能夠知道我們的接收能力也沒有問題。此時才能夠安全通訊。所以我們總結一下，其實TCP三次握手就是為了確定兩者都具有傳送和接收的能力。所以發包總共三次，確認總共兩次。
值得一提的是，TCP連線發起是由客戶端發起的，並不能由服務端發起。
所以我們來分析一下上圖的三次握手，
- 客戶端傳送
SYN包，生成隨機序列號seq = x； - 服務端傳送
SYN, ACK包，生成隨機序列號seq = y，對上一次的確認ack = x + 1； - 客戶端傳送
ACK包，生成上一次確認號ack = y + 1。