TCP 協議深度解析

從字面上來看，很多人會認為 TCP/IP 是 TCP、IP 這兩種協議，實際上TCP/IP 協議族指的是在 IP 協議通信過程中用到的協議的統稱

前言

可以看到協議的分層從上往下依次是

• Ethernet II：網絡接口層以太網幀頭部信息
• Internet Protocol Version 4：互聯網層 IP 包頭部信息
• Transmission Control Protocol：傳輸層的數據段頭部信息，此處是 TCP 協議
• Hypertext Transfer Protocol：應用層 HTTP 的信息

網絡分層

應用層(Application Layer)

應用層的本質是規定了應用程序之間如何相互傳遞報文， 以 HTTP 協議為例，它規定了:

• 報文的類型，是請求報文還是響應報文
• 報文的語法，報文分為幾段，各段是什么含義、用什么分隔，每個部分的每個字段什么什么含義
• 進程應該以什么樣的時序發送報文和處理響應報文

HTTP 客戶端和 HTTP 服務端的首要工作就是根據 HTTP 協議的標準組裝和解析 HTTP 數據包，每個 HTTP 報文格式由三部分組成：

• 起始行（start line），起始行根據是請求報文還是響應報文分為「請求行」和「響應行」。這個例子中起始行是GET / HTTP/1.1，表示這是一個 GET 請求，請求的 URL 為/，協議版本為HTTP 1.1，起始行最后會有一個空行CRLF（rn)與下面的首部分隔開
• 首部（header），首部采用形如key:value的方式，比如常見的User-Agent、ETag、Content-Length都屬于 HTTP 首部，每個首部直接也是用空行分隔
• 可選的實體（entity），實體是 HTTP 真正要傳輸的內容，比如下載一個圖片文件，傳輸的一段 HTML等

以本例的請求報文格式為例:

除了我們熟知的 HTTP 協議，還有下面這些非常常用的應用層協議

• 域名解析協議 DNS
• 收發郵件 SMTP 和 POP3 協議
• 時鐘同步協議 NTP
• 網絡文件共享協議 NFS

傳輸層（Transport Layer）

傳輸層的作用是為兩臺主機之間的「應用進程」提供端到端的邏輯通信，相隔幾千公里的兩臺主機的進程就好像在直接通信一樣。

雖然是叫傳輸層，但是并不是將數據包從一臺主機傳送到另一臺，而是對傳輸行為進行控制，這本小冊介紹的主要內容 TCP 協議就被稱為傳輸控制協議（Transmission Control Protocol），為下面兩層協議提供數據包的重傳、流量控制、擁塞控制等。

假設你正在電腦上用微信跟女朋友聊天，用 QQ 跟技術大佬們討論技術細節，當電腦收到一個數據包時，它怎么知道這是一條微信的聊天內容，還是一條 QQ 的消息呢？

這就是端口號的作用。傳輸層用端口號來標識不同的應用程序，主機收到數據包以后根據目標端口號將數據包傳遞給對應的應用程序進行處理。比如這個例子中，目標端口號為 80，百度的服務器就根據這個目標端口號將請求交給監聽 80 端口的應用程序（可能是 Nginx 等負載均衡器）處理。

網絡互連層（Internet Layer）

網絡互連層提供了主機到主機的通信，將傳輸層產生的的數據包封裝成分組數據包發送到目標主機，并提供路由選擇的能力。

IP 協議是網絡層的主要協議，TCP 和 UDP 都是用 IP 協議作為網絡層協議。這一層的主要作用是給包加上源地址和目標地址，將數據包傳送到目標地址。

IP 協議是一個無連接的協議，也不具備重發機制，這也是 TCP 協議復雜的原因之一就是基于了這樣一個「不靠譜」的協議。

網絡訪問層（Network Access Layer）

網絡訪問層也有說法叫做網絡接口層，以太網、Wifi、藍牙工作在這一層，網絡訪問層提供了主機連接到物理網絡需要的硬件和相關的協議。這一層我們不做重點討論。

分層的好處是什么呢？

分層的本質是通過分離關注點而讓復雜問題簡單化，通過分層可以做到：

• 各層獨立：限制了依賴關系的范圍，各層之間使用標準化的接口，各層不需要知道上下層是如何工作的，增加或者修改一個應用層協議不會影響傳輸層協議
• 靈活性更好：比如路由器不需要應用層和傳輸層，分層以后路由器就可以只用加載更少的幾個協議層
• 易于測試和維護：提高了可測試性，可以獨立的測試特定層，某一層有了更好的實現可以整體替換掉
• 能促進標準化：每一層職責清楚，方便進行標準化

TCP概述-可靠的、面向連接的、基于字節流、全雙工的協議

TCP 是面向連接的協議

面向連接（connection-oriented）：面向連接的協議要求正式發送數據之前需要通過「握手」建立一個邏輯連接，結束通信時也是通過有序的四次揮手來斷開連接。

無連接（connectionless）：無連接的協議則不需要

三次握手

通過三次握手協商好雙方后續通信的起始序列號、窗口縮放大小等信息。

TCP 協議是可靠的

IP 是一種無連接、不可靠的協議：它盡最大可能將數據報從發送者傳輸給接收者，但并不保證包到達的順序會與它們被傳輸的順序一致，也不保證包是否重復，甚至都不保證包是否會達到接收者。不保證有序、去重、完整。

TCP 要想在 IP 基礎上構建可靠的傳輸層協議，必須有一個復雜的機制來保障可靠性。主要有下面幾個方面：

• 對每個包提供校驗和
• 包的序列號解決了接收數據的亂序、重復問題
• 超時重傳
• 流量控制、擁塞控制

校驗和（checksum） 每個 TCP 包首部中都有兩字節用來表示校驗和，防止在傳輸過程中有損壞。如果收到一個校驗和有差錯的報文，TCP 不會發送任何確認直接丟棄它，等待發送端重傳。

包的序列號保證了接收數據的亂序和重復問題假設我們往 TCP 套接字里寫 3000 字節的數據導致 TCP發送了 3 個數據包，每個數據包大小為 1000 字節：第一個包序列號為[1~1001)，第二個包序列號為 [10012001)，第三個包序號為[20013001)

假如因為網絡的原因導致第二個、第三個包先到接收端，第一個包最后才到，接收端也不會因為他們到達的順序不一致把包弄錯，TCP 會根據他們的序號進行重新的排列然后把結果傳遞給上層應用程序。

如果 TCP 接收到重復的數據，可能的原因是超時重傳了兩次但這個包并沒有丟失，接收端會收到兩次同樣的數據，它能夠根據包序號丟棄重復的數據。

超時重傳 TCP 發送數據后會啟動一個定時器，等待對端確認收到這個數據包。如果在指定的時間內沒有收到 ACK 確認，就會重傳數據包，然后等待更長時間，如果還沒有收到就再重傳，在多次重傳仍然失敗以后，TCP 會放棄這個包。后面我們講到超時重傳模塊的時候會詳細介紹這部分內容。

TCP 是面向字節流的協議

TCP 是一種字節流（byte-stream）協議，流的含義是沒有固定的報文邊界。

假設你調用 2 次 write 函數往 socket 里依次寫 500 字節、800 字節。write 函數只是把字節拷貝到內核緩沖區，最終會以多少條報文發送出去是不確定的，如下圖所示

上面出現的情況取決于諸多因素：路徑最大傳輸單元 MTU、發送窗口大小、擁塞窗口大小等。

當接收方從 TCP 套接字讀數據時，它是沒法得知對方每次寫入的字節是多少的。接收端可能分2 次每次 650 字節讀取，也有可能先分三次，一次 100 字節，一次 200 字節，一次 1000 字節進行讀取。

TCP 是全雙工的協議

在 TCP 中發送端和接收端可以是客戶端/服務端，也可以是服務器/客戶端，通信的雙方在任意時刻既可以是接收數據也可以是發送數據，每個方向的數據流都獨立管理序列號、滑動窗口大小、MSS 等信息。

在 TCP 中發送端和接收端可以是客戶端/服務端，也可以是服務器/客戶端，通信的雙方在任意時刻既可以是接收數據也可以是發送數據，每個方向的數據流都獨立管理序列號、滑動窗口大小、MSS 等信息。

小結與思考

TCP 是一個可靠的（reliable）、面向連接的（connection-oriented）、基于字節流（byte-stream）、全雙工（full-duplex）的協議。發送端在發送數據以后啟動一個定時器，如果超時沒有收到對端確認會進行重傳，接收端利用序列號對收到的包進行排序、丟棄重復數據，TCP 還提供了流量控制、擁塞控制等機制保證了穩定性。

TCP提供了一種字節流服務，而收發雙方都不保持記錄的邊界，應用程序應該如何提供他們自己的記錄標識呢？

packetdrill-google協議棧測試神器-TODO

以 centos7 為例

1. 首先從 github 上 clone 最新的源碼 github.com/google/pack…
2. 進入源碼目錄cd gtests/net/packetdrill
3. 安裝 bison和 flex 庫：sudo yum install -y bison flex
4. 為避免 offload 機制對包大小的影響，修改 netdev.c 注釋掉 set_device_offload_flags 函數所有內容
5. 執行 ./configure
6. 修改 Makefile，去掉第一行的末尾的 -static
7. 執行 make 命令編譯
8. 確認編譯無誤地生成了 packetdrill 可執行文件

詳解

tcp基石-剖析首部字段

這篇文章來講講 TCP 報文首部相關的概念，這些頭部是支撐 TCP 復雜功能的基石。完整的 TCP 頭部如下圖所示：

我們用一次訪問百度網頁抓包的例子來開始。

源端口號、目標端口號

在第一個包的詳情中，首先看到的高亮部分的源端口號（Src Port）和目標端口號（Dst Port)，這個例子中本地源端口號為 61024，百度目標端口號是 80。

TCP 報文頭部里沒有源 ip 和目標 ip 地址，只有源端口號和目標端口號。

這也是初學 wireshark 抓包時很多人會有的一個疑問：過濾 ip 地址為 172.19.214.24 包的條件為什么不是 “tcp.addr == 172.19.214.24”，而是 “ip.addr == 172.19.214.24”

TCP 的報文里是沒有源 ip 和目標 ip 的，因為那是 IP 層協議的事情，TCP 層只有源端口和目標端口。

源 IP、源端口、目標 IP、目標端口構成了 TCP 連接的「四元組」。一個四元組可以唯一標識一個連接。

序列號（Sequence number）

TCP 是面向字節流的協議，通過 TCP 傳輸的字節流的每個字節都分配了序列號，序列號（Sequence number）指的是本報文段第一個字節的序列號。

序列號加上報文的長度，就可以確定傳輸的是哪一段數據。序列號是一個 32 位的無符號整數，達到 2^32-1 后循環到 0。

在 SYN 報文中，序列號用于交換彼此的初始序列號，在其它報文中，序列號用于保證包的順序。

因為網絡層（IP 層）不保證包的順序，TCP 協議利用序列號來解決網絡包亂序、重復的問題，以保證數據包以正確的順序組裝傳遞給上層應用。

如果發送方發送的是四個報文序列號分別是1、2、3、4，但到達接收方的順序是 2、4、3、1，接收方就可以通過序列號的大小順序組裝出原始的數據。

初始序列號（Initial Sequence Number, ISN）

在建立連接之初，通信雙方都會各自選擇一個序列號，稱之為初始序列號。在建立連接時，通信雙方通過 SYN 報文交換彼此的 ISN，如下圖所示:

初始建立連接的過程中 SYN 報文交換過程如下圖所示:

其中第 2 步和第 3 步可以合并一起，這就是三次握手的過程:

初始序列號是如何生成的

可以看到初始序列號的計算函數 secure_tcp_sequence_number() 的邏輯是通過源地址、目標地址、源端口、目標端口和隨機因子通過 MD5 進行進行計算。如果僅有這幾個因子，對于四元組相同的請求，計算出的初始序列號總是相同，這必然有很大的安全風險，所以函數的最后將計算出的序列號通過 seq_scale 函數再次計算。

seq_scale 函數加入了時間因子，對于四元組相同的連接，序列號也不會重復了。

序列號回繞了怎么處理

序列號是一個 32 位的無符號整數，從前面介紹的初始序列號計算算法可以知道，ISN 并不是從 0 開始，所以同一個連接的序列號是有可能溢出回繞（sequence wraparound）的。TCP 的很多校驗比如丟包、亂序判斷都是通過比較包的序號來實現的，我們來看看 linux 內核是如何處理的，代碼如下所示。

其中 __u32 表示無符號的 32 位整數，__s32 表示有符號的 32 位整數。為什么 seq1 - seq2 轉為有符號的 32 位整數就可以判斷 seq1 和 seq2 的大小了呢？

以 seq1 為 0xFFFFFFFF、seq2 為 0x02（回繞）為例，它們相減的結果如下。

seq1 - seq2 = 0xFFFFFFFF - 0x02 = 0xFFFFFFFD

0xFFFFFFFD 最高位為 1，表示為負數，實際值為 -(0x00000002 + 1) = -3，這樣即使 seq2 回繞了，也可以知道 seq1

確認號

TCP 使用確認號（Acknowledgment number, ACK）來告知對方下一個期望接收的序列號，小于此確認號的所有字節都已經收到。

關于確認號有幾個注意點：

• 不是所有的包都需要確認的
• 不是收到了數據包就立馬需要確認的，可以延遲一會再確認
• ACK 包本身不需要被確認，否則就會無窮無盡死循環了
• 確認號永遠是表示小于此確認號的字節都已經收到

TCP Flags

TCP 有很多種標記，有些用來發起連接同步初始序列號，有些用來確認數據包，還有些用來結束連接。TCP 定義了一個 8 位的字段用來表示 flags，大部分都只用到了后 6 個，如下圖所示

下面這個是 wireshark 第一個 SYN 包的 flags 截圖

我們通常所說的 SYN、ACK、FIN、RST 其實只是把 flags 對應的 bit 位置為 1 而已，這些標記可以組合使用，比如 SYN+ACK，FIN+ACK 等

• SYN（Synchronize）：用于發起連接數據包同步雙方的初始序列號
• ACK（Acknowledge）：確認數據包
• RST（Reset）：這個標記用來強制斷開連接，通常是之前建立的連接已經不在了、包不合法、或者實在無能為力處理
• FIN（Finish）：通知對方我發完了所有數據，準備斷開連接，后面我不會再發數據包給你了。
• PSH（Push）：告知對方這些數據包收到以后應該馬上交給上層應用，不能緩存起來

窗口大小

可以看到用于表示窗口大小的"Window Size" 只有 16 位，可能 TCP 協議設計者們認為 16 位的窗口大小已經夠用了，也就是最大窗口大小是 65535 字節（64KB）。就像網傳蓋茨曾經說過：“640K內存對于任何人來說都足夠了”一樣。

自己挖的坑當然要自己填，因此TCP 協議引入了「TCP 窗口縮放」選項 作為窗口縮放的比例因子，比例因子值的范圍是 0 ~ 14，其中最小值 0 表示不縮放，最大值 14。比例因子可以將窗口擴大到原來的 2 的 n 次方，比如窗口大小縮放前為 1050，縮放因子為 7，則真正的窗口大小為 1050 * 128 = 134400，如下圖所示

可選項

可選項的格式入下所示

以 MSS 為例，kind=2，length=4，value=1460

常用的選項有以下幾個：

• MSS：最大段大小選項，是 TCP 允許的從對方接收的最大報文段
• SACK：選擇確認選項
• Window Scale：窗口縮放選項

網絡數據包大小-MUT與MSS

前面的文章中介紹過一個應用層的數據包會經過傳輸層、網絡層的層層包裝，交給網絡接口層傳輸。假設上層的應用調用 write 等函數往 socket 寫入了 10KB 的數據，TCP 會如何處理呢？是直接加上 TCP 頭直接交給網絡層嗎？這篇文章我們來講講這相關的知識

MUT

數據鏈路層傳輸的幀大小是有限制的，不能把一個太大的包直接塞給鏈路層，這個限制被稱為「最大傳輸單元（Maximum Transmission Unit, MTU）」

下圖是以太網的幀格式，以太網的幀最小的幀是 64 字節，除去 14 字節頭部和 4 字節 CRC 字段，有效荷載最小為 46 字節。最大的幀是 1518 字節，除去 14 字節頭部和 4 字節 CRC，有效荷載最大為 1500，這個值就是以太網的 MTU。因此如果傳輸 100KB 的數據，至少需要 （100 * 1024 / 1500) = 69 個以太網幀。

不同的數據鏈路層的 MTU 是不同的。通過netstat -i 可以查看網卡的 mtu，比如在 我的 centos 機器上可以看到

IP分段

IPv4 數據報的最大大小為 65535 字節，這已經遠遠超過了以太網的 MTU，而且有些網絡還會開啟巨幀（Jumbo Frame）能達到 9000 字節。當一個 IP 數據包大于 MTU 時，IP 會把數據報文進行切割為多個小的片段(小于 MTU），使得這些小的報文可以通過鏈路層進行傳輸。

IP 頭部中有一個表示分片偏移量的字段，用來表示該分段在原始數據報文中的位置，如下圖所示

前面我們提到 IP 協議不會對丟包進行重傳，那么 IP 分段中有分片丟失、損壞的話，會發生什么呢？這種情況下，目標主機將沒有辦法將分段的數據包重組為一個完整的數據包，依賴于傳輸層是否進行重傳。

利用 IP 包分片的策略，有一種對應的網絡攻擊方式IP fragment attack，就是一直傳More fragments = 1的包，導致接收方一直緩存分片，從而可能導致接收方內存耗盡。

因為有 MTU 的存在，TCP 每次發包的大小也限制了，這就是下面要介紹的 MSS。

MSS

TCP 為了避免被發送方分片，會主動把數據分割成小段再交給網絡層，最大的分段大小稱之為 MSS（Max Segment Size）。

MSS = MTU - IP header頭大小 - TCP 頭大小

這樣一個 MSS 的數據恰好能裝進一個 MTU 而不用分片。在以太網中 TCP 的 MSS = 1500（MTU） - 20（IP 頭大?。?- 20（TCP 頭大?。? 1460。

為什么有時候抓包看到的單個數據包大于 MTU

這就要說到 TSO（TCP Segment Offload）特性了，TSO 特性是指由網卡代替 CPU 實現 packet 的分段和合并，節省系統資源，因此 TCP 可以抓到超過 MTU 的包，但是不是真正傳輸的單個包會超過鏈路的 MTU。