1、TCP報文格式

2、TCP連線建立時三次握手的過程

圖示

1. 文字說明

   1. 第一次握手：建立連線時，客戶端傳送syn包(seq=x)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；

   2. 第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（seq=y），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

   3. 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=y+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。

   4. 完成三次握手，客戶端與伺服器開始傳送資料，在上述過程中，還有一些重要的概念：

2. TCP的弱點

   1. TCP 連線的資源消耗，其中包括：資料包資訊、條件狀態、序列號等

   2. 通過故意不完成建立連線所需要的三次握手過程，造成連線一方的資源耗盡

   3. 序列號的可預測性，目標主機應答連線請求時返回的SYN/ACK 的序列號是可預測的

   4. TCP 會話劫持和SYN FLOOD（同步洪流）就是根據TCP的這個弱點出現的一種網路攻擊方式

• TCP三次握手過程中用到的一些資料結構和引數

  • 未連線佇列：在 三次握手協議中，伺服器維護一個未連線佇列，該佇列為每個客戶端的SYN包（syn=j）開設一個條目，該條目表明伺服器已收到SYN 包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連線在伺服器處於Syn_RECV狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器 進入ESTABLISHED狀態。

  • Backlog引數：表示未連線佇列的最大容納數目。

  • SYN-ACK 重傳次數：伺服器傳送完SYN－ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連線資訊從半連線佇列中刪除。注意，每次重傳等待的時間不一定相同。

  • 半連線存活時間：是指半連線佇列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時我們也稱半連線存活時間為Timeout時間、SYN_RECV存活時間。　　

  • SYN（同步標誌）：該標誌置上的時候，同 步序列編號(Synchronize Sequence Numbers)欄有效。該標誌僅在三次握手建立TCP連線時有效。它提示TCP連線的服務端檢查序列編號，該序列編號為TCP連線初始端(一般是客戶 端)的初始序列編號。在這裡，可以把TCP序列編號看作是一個範圍從0到4，294，967，295的32位計數器。通過TCP連線交換的資料中每一個字 節都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個位元組的序列編號。　

  • ACK（確認標誌）：該標誌置上的時候，確認編號(Acknowledgement Number)欄有效。大多數情況下該標誌位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1，Figure-1)為下一個預期的序列編號，同時提示遠端系統已經成功接收所有資料。　　

  • RST（復位標誌）：該標誌置上的時候，用於復位相應的TCP連線。　　

  • URG（緊急標誌）：該標誌置上的時候，表示緊急(The urgent pointer) 標誌有效。

  • PSH（推標誌）：該標誌置位時，接收端不將該資料進行佇列處理，而是儘可能快將資料轉由應用處理。在處理 telnet 或 rlogin 等互動模式的連線時，該標誌總是置位的。　　

  • FIN（結束標誌）：帶有該標誌置位的資料包用來結束一個TCP回話，但對應埠仍處於開放狀態，準備接收後續資料。

• TCP三次握手的一些中間狀態

• SYN_SENT：客戶端傳送syn資料包向伺服器端申請建立TCP連線，此時客戶端的狀態為SYN_SENT

• SYN_RCVD：接收方收到請求，給發起方傳送一個設定了SYN與ACK標誌位的TCP資料包做為應答，另外設定一個比客戶機發送來的ISN大1個單位的ISN值，這常被稱為SYN_ACK資料包或SYN_ACK報文這時連線的狀態稱做SYN_RCVD

• ESTABLISHED：發起方然後傳送一個帶有ACK應答和增1後的ISN標誌來確認SYN_ACK至此，完成了三次握手，此時的連線狀態為連結成功: ESTABLISHED

3、連線終止協議（四次揮手）

關閉過程

• 由於TCP連線是全雙工的， 因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

• TCP客戶端傳送一個FIN，用來關閉客戶到伺服器的資料傳送（報文段4）。

• 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。

• 伺服器關閉客戶端的連線，傳送一個FIN給客戶端（報文段6）。

• 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。

關閉過程中出現的幾個狀態

• CLOSED: 這個沒什麼好說的了，表示初始狀態。

• LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連線了。

• SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三次握手會話過程中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

• SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連線時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN報文。

• ESTABLISHED：這個容易理解了，表示連線已經建立了。

• FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬 上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。

• FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。

• TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。

• CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什 麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時傳送FIN報 文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。

• CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對 方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。

• LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。
  最後有2個問題的回答，我自己分析後的結論（不一定保證100%正確）

為什麼建立連線協議是三次握手，而關閉連線卻是四次握手呢？

• 這是因為服務端的 LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發 送。但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關 閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ACK報文和FIN報文 多數情況下都是分開發送的。