TCP 是 TCP/IP 協議族中一個最核心的協議，它向下使用網絡層 IP 協議，向上爲應用層 HTTP、FTP、SMTP、POP3、SSH、Telnet 等協議提供支持。本文給出 TCP 報文格式的詳細說明，介紹網絡數據包傳遞中如何進行地址解析、建立 TCP 連接的三次握手過程以及斷開 TCP 連接的四次揮手過程。

1.  簡介

傳輸控制協議（英語：Transmission Control Protocol，縮寫：TCP）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由國際互聯網工程任務組 (The Internet Engineering Task Force, IETF) 的 RFC793 定義。在簡化的計算機網絡 OSI 模型中，它完成傳輸層所指定的功能。

在 TCP 定義中，有以下 3 點需要特別說明：

(1) 什麼是面向連接？

面向連接是相對於另一個傳輸層協議 UDP(User Datagram Protocol, 用戶數據報協議) 而言的。TCP 在開始傳輸數據前要先經歷三次握手建立連接，並通過連接一對一發送消息，傳輸結束後通過四次揮手斷開連接。

而 UDP 是無連接的，發送方在發送數據之前不需要與接收方建立連接，即刻可以傳輸數據，每個 UDP 數據包都是獨立的，相互之間沒有關聯，因此 UDP 可以一對一、一對多或多對多發送消息。

(2) 什麼是可靠的通信協議？

是否可靠也是相對於 UDP 而言的。TCP 自身有三次握手和超時重傳等機制確保數據的可靠傳輸，發送方在發送數據包後會等待接收方發送確認 (ACK) 消息。如果發送方在一定時間內未收到確認消息，它將假定數據丟失，並重新發送數據。接收方收到重複的數據包時會發送冗餘的 ACK 消息來通知發送方，以避免數據丟失。同時 TCP 還提供流量控制和擁塞控制，以保持網絡的穩定性和性能。因此無論網絡如何變化，只要不是主機宕機等原因都可以保證一個報文可以到達目標主機。

相對於 TCP 的可靠傳輸，UDP 是不可靠的。UDP 數據包的傳輸過程中不提供確認、重傳、流量控制和擁塞控制等機制，因此 UDP 數據包可能丟失、重複、亂序或損壞。

(3) 什麼是面向字節流的？

TCP 是面向字節流的傳輸，雖然應用程序和 TCP 的交互是一次一個數據塊 (大小不等)，但 TCP 把應用程序看成是一連串的無結構的字節流。TCP 有一個緩衝，當應用程序傳送的數據塊太長，TCP 就可以把它劃分短一些再傳送。如果應用程序一次只發送一個字節，TCP 也可以等待積累有足夠多的字節後再構成報文段發送出去。

與面向字節流相對的是 UDP 的面向報文。UDP 對應用層交下來的報文，既不合並也不拆分，而是保留這些報文的邊界，即應用層交給 UDP 多長的報文，UDP 就照樣發送，一次發送一個報文。因此，應用程序必須選擇合適大小的報文。若報文太長，則 IP 層需要分片，降低效率。若太短，會使 IP 報文太小。

2.TCP 報文格式

瞭解報文格式是搞懂一個通信協議的必經之路。TCP 報文由 TCP 首部 (報頭) 和應用數據構成，其中 TCP 首部是 TCP 協議的核心所在，應用數據部分是 TCP 報文的負載，如下圖所示。

以下詳細介紹各字段含義：

• 源端口 (Source Port) 和 目的端口(Destination Port)**：長度各爲 16 位，即 2 個字節，分別指示發送端的應用程序使用的端口號以及接收端的應用程序期望接收的端口號。它們的長度說明爲什麼計算機端口的範圍是 1-65535 (0 不使用，2^16=65536，最大位 65536 不使用)。有了源端口和目標端口，加上 IP 首部裏的源 IP 和目標 IP，就可以唯一確定一個連接。

• 序列號(Sequence Number)：長度爲 32 位，說明序列號的範圍是 [0, 2^32-1]，也就是[0, 4294967295]。當序號增加到 4294967295 後，下一個序號將回到 0 重新開始。在建立連接時由計算機生成的隨機數作爲其初始值(ISN，即 Initial Sequence Number，初始序列號)，通過 SYN 包傳給接收端主機，每發送一次數據，就累加一次該“數據字節數” 的大小。序列號用來解決網絡包亂序問題，實現可靠的數據傳輸和流量控制。

• 確認號(Acknowledgment Number)：長度爲 32 位，只有在 ACK 標誌位被設置時纔有效。它指示期望接收的下一個字節的序列號 (所以該字段一般都是上次接收成功的數據字節序號加 1)，用於確認已經成功接收的數據。在 TCP 連接建立後，確認號的範圍通常是相對於初始序號(ISN) 的相對偏移量。如果 ISN 的初始值爲 X，那麼確認號的範圍就是[X+1, X+1+N-1]，其中 N 表示已經成功接收的字節數。發送端收到這個確認應答以後可以認爲在這個序號以前的數據都已經被正常接收。確認號的範圍是[0, 2^32-1]，也就是[0, 4294967295]。

• 數據偏移(Data Offset)：長度爲 4 位，指示 TCP 報文的 “數據” 起始處距離 TCP 報文起始處的距離有多遠，以 4 字節爲單位計算出的數據段開始地址的偏移值。沒有選項時該值爲 5，即 20 字節；4 位能表示的最大整數是 15，也就說明 TCP 報文裏數據開始的位置距離報文起點是 60 個字節(4*15)。這意味着 TCP 的首部長度是 20-60 個字節。

• 保留(Reserved)：長度爲 3 位，保留供將來使用，目前應設置爲零。

• 控制標誌(Flags)：長度爲 9 位，用於控制和管理 TCP 連接。各控制標誌位說明如下：

• NS(Nonce Sum)：用於支持一種稱爲 ECN-nonce 的 TCP 擴展機制，該機制用於增加擁塞控制的安全性，防止擁塞控制信息被惡意篡改。

• CWR(Congestion Window Reduced)：用於指示發送方減小擁塞窗口 (Congestion Window) 的大小。CWR 標誌位通常與擁塞控制機制一起使用，以應對網絡擁塞的情況。

• ECE(ECN-Echo)：ECE 標誌被設置表示發送方支持顯式擁塞通知 (Explicit Congestion Notification, ECN) 機制，並請求接收方通知其關於網絡擁塞的情況。接收方在收到設置了 ECE 標誌的 TCP 報文段後，如果網絡出現擁塞，則可以在回覆的 TCP 報文段中設置 ECN-Echo 標誌作爲響應。通過使用 ECE 標誌和 ECN-Echo 回覆，TCP 連接的發送方和接收方可以共同協調擁塞控制，以提高網絡的性能和穩定性。

•  URG(Urgent)：指示報文段中包含緊急數據。當 URG=1 時，表明開啓了 urgent mode，通知接收方在處理數據時要特別注意緊急數據的處理。URG 標誌位的設置與緊急指針字段 (Urgent Pointer) 一起使用。

• ACK(Acknowledgment)：指示確認號字段有效。僅當 ACK=1 時確認號字段纔有效，當 ACK=0 時確認號無效。TCP 規定，在連接建立後所有的傳送的報文段都必須把 ACK 置爲 1。

• PSH(Push)：指示接收方應立即將數據推送給應用程序，而不是等待緩衝區填滿。當兩個應用進程進行交互式的通信時，有時一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應。在這種情況下，TCP 就可以使用推送 (push) 操作。這時，發送方 TCP 把 PSH 置爲 1，並立即創建一個報文段發送出去。接收方 TCP 收到 PSH=1 的報文段，就儘快地 (即“推送” 向前)交付接收應用進程。而不用再等到整個緩存都填滿了後再向上交付。

• RST(Reset)：用於復位連接，中斷當前的通信。當 RST=1 時，表示 TCP 連接中出現異常 (如主機崩潰或其他原因) 必須強制斷開連接，然後再重新建立連接進行傳輸。RST 置爲 1 還用來拒絕一個非法的報文段或拒絕打開一個連接。

• SYN(Synchronize)：用於建立連接，發起連接請求。在連接建立時用來同步序號。當 SYN=1 而 ACK=0 時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使 SYN=1 和 ACK=1，因此 SYN 置爲 1 就表示這是一個連接請求或連接接受報文。

• FIN(Finish)：用於關閉連接，請求終止連接。當 FIN=1 時，表示發送方沒有數據要傳輸了，要求釋放連接。

• 窗口大小(Window Size)：長度爲 16 位，指示接收方的接收窗口大小，用於流量控制，最大的窗口大小爲 2^16-1=65535=64k。這是早期的設計，對於現在的網絡應用，可能會不太夠，因此可以在選項里加一個 窗口擴大選項，來傳輸更多的數據。窗口指的是發送本報文段一方的接受窗口 (而不是自己的發送窗口)。窗口值告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方發送的數據量 (以字節爲單位)。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。總之，窗口值作爲接收方讓發送方設置其發送窗口的依據。

• 校驗和(Checksum)：長度爲 16 位，用於檢測 TCP 報文段是否在傳輸過程中發生了錯誤。校驗和計算包括報頭和數據。

• 緊急指針(Urgent Pointer)：長度爲 16 位，只有在 URG 標誌位被設置時纔有效。它指出本報文段中的緊急數據的字節數 (緊急數據結束後就是普通數據)。因此，在緊急指針指出了緊急數據的末尾在報文段中的位置。當所有緊急數據都處理完時，TCP 就告訴應用程序恢復到正常操作。值得注意的是，即使窗口爲 0 時也可以發送緊急數據。

• 選項(Options)：可選字段，長度可變，最長可達 40 個字節。當沒有使用 “選項” 時，TCP 的首部長度是 20 字節。選項字段用於提供額外的功能和控制，每個選項的開始是 1 字節的 kind 字段，說明選項的類型。一些常見的選項舉例如下：

• 最大報文段長度(Maximum Segment Size, MSS)：佔用 4 字節，通常在創建連接而設置 SYN 標誌的數據包中指明這個選項，指明本端所能接收的最大長度的報文段。通常將 MSS 設置爲 (MTU-40) 字節，攜帶 TCP 報文段的 IP 數據報的長度就不會超過 MTU(MTU 最大長度爲 1518 字節，最短爲 64 字節)，從而避免本機發生 IP 分片。只能出現在同步報文段中，否則將被忽略。

• 窗口擴大因子(Window Scale Factor)：佔用 3 字節，取值 0-14。用來把 TCP 的窗口的值左移的位數，使窗口值乘倍。只能出現在同步報文段中，否則將被忽略。這是因爲現在的 TCP 接收數據緩衝區 (接收窗口) 的長度通常大於 65535 字節。

• 時間戳選項(TCP Timestamps Option, TSopt)：佔用 10 字節，其中最主要的字段是時間戳字段 (Timestamp Value field, TSval, 4 字節) 和時間戳回送回答字段 (Timestamp Echo Reply field, TSecr, 4 字節)。時間戳選項允許通信的兩端在 TCP 報文段中包含時間戳值，以便進行一些時間相關的操作和計算。

• 安全摘要選項(TCP Authentication Option, TCP Option)：用於提供數據完整性和身份驗證的功能。該選項用於對 TCP 報文段進行保護，防止數據篡改和未經授權的訪問。

3. 數據包傳遞的地址解析

我們在 “IP 協議詳細解析” 一文中介紹了 IP 報頭中 “源地址” 和 “目的地址”，與本文 TCP 報頭中的 “源端口” 和 “目的端口” 共同確定了數據包傳遞過程中需要的地址，如下圖所示。

類比日常工作中郵寄信件，我們裝在信封裏的信件相當於要傳遞的數據，標準的信件格式是要在信封上寫 “收信人地址” 和 “寄信人地址”，相當於 IP 地址，其中，“收信人地址” 對應數據包裏 IP 報頭中的 “目的 IP 地址”，“寄信人地址” 對應數據包裏 IP 報頭中的 “源 IP 地址”，寫上寄信、收信兩個地址就可以保證信件可以郵寄到目的地了。

但信件郵寄到目的地址後由誰來收？從上面這封信的收件人地址檢索到這個地址是位於上海市浦東新區張江 “A 公司 B 部門” 的，這個部門可能有成百上千人，收件人不明確，即使把信件送到這個地址，也沒辦法投遞到具體的收信人。

因此，郵件信件需要填寫 “收件人姓名”、“收件人地址” 和“寄件人姓名”、“寄件人地址”的組合，才能保證信件能準確投遞到具體的收件人手中。這裏的收信人姓名相當於 TCP 報頭的目的端口，寄信人姓名相當於 TCP 報頭的源端口。

對比傳遞信件，我們來看網絡數據包傳遞過程的例子。位於北京的李四 (電腦 IP 地址: 106.54.28.25) 給上海的張三 (電腦 IP 地址: 114.92.67.193) 通過 QQ(端口: 80) 發送一條消息，如下圖所示：

首先，李四電腦將消息打包成 TCP 數據報後，添加 IP 報頭和以太網報頭形成網絡數據包，發送到計算機網絡中。計算機網絡通過數據包中 IP 報頭的目的 IP 地址 (114.92.67.193) 把該數據包準確傳遞到張三電腦。

張三電腦收到了李四電腦發送過來的數據包後，由於張三電腦上同時運行有多個程序 (例如圖中的 QQ、微信、Foxmail 等)，雖然張三電腦知道這個數據包是傳輸給它的，但是它不知道該把這個數據包中的數據交給哪個程序。

針對這個問題，使用數據包中 TCP 報頭的源端口和目的端口，根據不同的程序使用不同端口號來確定應用程序併發送和接受數據，這樣數據包就能像郵寄信件一樣準確投遞到具體電腦上指定的程序了。例如我們指定張三電腦上 QQ、微信、Foxmail 使用的端口分別是 80、8900 和 110，那麼當收到數據包裏目的端口 80 就是傳輸給 QQ 的。

上述例子還可以引申出數據包結構中的其他字段的作用，例如我們收到信後可以簡單地通過信封是否完整，來檢查該信件是否被別人在傳輸途中拆開並篡改過信件內容。對於網絡數據包，TCP 報頭的 “校驗和”(Checksum) 可以驗證收到數據包數據是否在途被別人拆開修改過。

4.TCP 連接

爲什麼需要建立 TCP 連接？首先，IP 協議是無連接的，IP 並不維護任何關於後續數據報的狀態信息，每個數據報的處理相互獨立。這種無連接的優點是不佔用線路，降低了對網絡線路的要求；此外，IP 協議是不可靠的，不能保證 IP 數據報能成功到達目的地，是一種盡力而爲的傳輸服務，路由器對 IP 報文出現錯誤的處理方式是丟包，併發送 ICMP(Internet Control Message Protocol，互聯網控制協議) 控制消息給源地址。因爲 IP 協議是無連接、不可靠的，因此，需要上層 TCP 來建立連接和差錯重傳，實現面向連接的、可靠的、基於字節流的傳輸層通信協議。

4.1 三次握手過程詳解

由於建立 TCP 連接的過程需要來回 3 次，所以將這個過程形象的叫做三次握手 (Three-Way Handshake)，一旦建立連接，兩臺主機就可以進行全雙工的通信。

下面是三次握手的詳細過程，包括髮送的報文段內容：

(1) 第一次握手

首先客戶端發起連接請求，向服務器發送一個 SYN(同步) 報文段，段中包含了目的端口和本機端口，設置 SYN 標誌位爲 1，即 SYN=1，並設置序號字段 (Sequence Number) 爲一個隨機選擇的 x，即 seq=x，也就是初始序號 (Initial Sequence Number, ISN)，如果是第一個連接，很可能是 0。此時服務器對應的端口要處於監聽狀態，客戶端發起請求後進入 SYN_SENT 狀態，等待服務器的確認。

(2) 第二次握手

服務端收到客戶端發來的 SYN 報文段，對這個 SYN 報文段進行確認。服務器向客戶端發送一個 SYN-ACK 報文段作爲迴應，報文段中的標誌位設置爲 SYN=1 和 ACK=1，表示同時作爲確認和同步；序號字段設置爲服務器的隨機選擇的初始序號 y(服務端的 TCP 段序號)，即 seq=y；確認號字段 (Acknowledgment Number) 設置爲客戶端的初始序號加 1，即 ack=x+1。服務器端將上述所有信息放到一個 TCP 段 (即 SYN+ACK 段) 中，一併發送給客戶端，此時服務器進入 SYN_RECV 狀態。

(3) 第三次握手

客戶端接收到服務端發來的 SYN+ACK 報文段後，要向服務端發送一個 ACK(確認) 報文段，對連接請求的確認進行確認。報文段中的標誌位設置爲 ACK=1，確認號字段設置爲服務器的初始序號加 1，即 ack=y+1，序號字段設置爲客戶端的初始序號加 1，即 seq=x+1。此時客戶端進入 ESTABLISHED(已連接) 狀態，服務端接收到此 TCP 段，也將進入 ESTABLISHED 狀態，也就標誌着三次握手結束，連接成功建立。

三次握手完成之後，TCP 連接就正式建立起來了，雙方可以開始進行數據的可靠傳輸。三次握手的目的是確保雙方的初始序號和確認號的同步，並驗證雙方的可達性。通過這個過程，TCP 可以建立一個可靠的雙向通信通道，在後續的數據傳輸中保證數據的可靠性和順序性。

4.2 四次揮手

四次揮手是 TCP 斷開連接的過程。

(1) 第一次揮手

客戶端數據發送完成，則向服務端發送連接釋放請求的 FIN 報文 (請求連接終止：FIN=1)，主動關閉 TCP 連接。報文中會指定一個序列號 seq=u，並停止再發送數據，但依然能夠接收數據。此時客戶端處於 FIN_WAIT_1 狀態，等待服務端確認。TCP 規定，FIN 報文即使不攜帶數據，也要消耗一個序號。

(2) 第二次揮手

服務端收到 FIN 報文之後，通知相應的高層應用進程，告訴它客戶端向服務端這個方向的連接已經釋放了。此時服務端向客戶端發出連接釋放的應答 ACK 報文，並進入了 CLOSE_WAIT(關閉等待) 狀態。ACK 報文頭包含：ACK=1，ack=u+1，並且帶上自己的序列號 seq=v。這裏 ack=u+1 是第一次揮手的序列值 + 1，表示希望收到從第 u+1 個字節開始的報文段，並且已經成功接收了前 u 個字節。

客戶端收到服務端的確認後，進入 FIN_WAIT_2 狀態，等待服務端發出的連接釋放報文段。

前兩次揮手既讓服務端知道了客戶端想釋放連接，也讓客戶端知道了服務端已瞭解自己想要釋放連接的請求。

(3) 第三次揮手

如果服務端也想斷開連接，就向客戶端發送連接釋放報文。由於在 CLOS_WAIT 狀態，服務端很可能又發送了一些數據，假定此時連接釋放報文的序列號爲 seq=w，ack 也是取第一次揮手的 seq +1，即 ack=u+1，這和第二次揮手時是一樣的。

此時服務端就進入了 LAST_ACK(最後確認) 狀態，等待客戶端的確認，並停止向客戶端發送數據，但服務端仍能夠接收從客戶端傳輸過來的數據。

(4) 第四次揮手

客戶端收到服務器的連接釋放報文後，一樣發送一個 ACK 報文作爲應答 (ack=w+1，seq=u+1)， 此時客戶端處於 TIME_WAIT(時間等待) 狀態，並在這個狀態等待 2MSL(Two Maximum Segment Lifetime, 最大報文生存時間)。

服務端收到從客戶端發出的 TCP 報文之後結束 LAST-ACK 階段，進入 CLOSED 階段。客戶端等待完 2MSL 之後，結束 TIME-WAIT 階段，進入 CLOSED 階段，由此完成四次揮手。

爲什麼客戶端在 TIME_WAIT 階段要等 2MSL？ 主要有以下兩點：

一是爲了保證客戶端發送的最後一個 ACK 報文段能夠到達服務器端，確保服務端能正常進入 CLOSED 狀態。服務端在 1MSL 內沒有收到客戶端發出的 ACK 確認報文，就會再次向客戶端發出 FIN 報文。

二是爲了避免新舊連接混淆。由於網絡滯留，客戶端可能發送了多次請求建立連接的請求，經過時間 2MSL，就可以使本鏈接持續時間內所產生的所有報文段都從網絡中消失，這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Hl63eQ6Jlhwaa7x0wtgSQg