為什么 TFO 可以將 TCP 降低到 0 次握手？

作者：蠻荊 2024-10-14 16:40:59

因為 TCP 協(xié)議棧不同版本間存在差異，所以本文的前提是 TCP 三次握手時不傳輸數(shù)據(jù)，也就是傳統(tǒng)的 TCP 三次握手。

一、概述

在之前的文章為什么 TCP 建立連接需要三次握手中，關(guān)于下面 3 個問題給出了簡單的回答:

第一次握手時可以攜帶應(yīng)用數(shù)據(jù)嗎？
第二次握手時可以攜帶應(yīng)用數(shù)據(jù)嗎？
第三次握手時可以攜帶應(yīng)用數(shù)據(jù)嗎？

簡單來說，傳統(tǒng)的 TCP 建立連接時需要三次握手，而且這三次握手只發(fā)送簡單的 SYN 和 ACK 報文。

從網(wǎng)絡(luò)帶寬的資源利用的角度來看，傳輸層的 TCP 頭部 + 網(wǎng)絡(luò)層的 IP 頭部，最少有 40 個字節(jié)，為了發(fā)送幾個字節(jié)的報文數(shù)據(jù)包，而額外組裝了 40 個字節(jié)的頭部，這有點類似前面講 TCP 滑動窗口時，所謂的 “糊涂窗口綜合癥”。

從應(yīng)用優(yōu)化的角度來看，因為要等到 TCP 經(jīng)過三次握手建立連接之后才能發(fā)送應(yīng)用層數(shù)據(jù)，所以會造成應(yīng)用程序首次發(fā)送數(shù)據(jù)時存在一定的延遲，尤其是短連接、移動設(shè)備等場景中，這種副作用會加劇。

那么這種問題如何解決呢？使用 TFO 解決方案。

?? PS: 因為 TCP 協(xié)議棧不同版本間存在差異，所以本文的前提是 TCP 三次握手時不傳輸數(shù)據(jù)，也就是傳統(tǒng)的 TCP 三次握手，事實上，很多云計算服務(wù)商提供的 Linux 發(fā)行版本都對網(wǎng)絡(luò)協(xié)議棧進(jìn)行了優(yōu)化，會在 TCP 第三次握手時直接發(fā)送數(shù)據(jù)，讀者自己抓包驗證時，可能會和本文結(jié)果存在一定差異。

二、TFO

TCP Fast Open (TFO) 是在傳統(tǒng)的三次握手基礎(chǔ)上進(jìn)行優(yōu)化，允許在握手過程中發(fā)送數(shù)據(jù)，從而減少首次發(fā)送數(shù)據(jù)的延遲，提升網(wǎng)絡(luò)應(yīng)用性能。

1.實現(xiàn)原理：

TFO 的核心原理是在發(fā)送方和接收方通信中，引入 1 個 Cookie 機制，這樣使發(fā)送方在后續(xù)重連接收方時，能夠簡化 TCP 三次握手。

顧名思義，TFO Cookie 中的 Cookie 和 Web 應(yīng)用層中的 Cookie 機制一樣，第一次訪問時，需要登錄驗證，然后由服務(wù)端驗證后，后續(xù)訪問中可以直接攜帶，無需再次登錄。

(1) 首次連接

當(dāng)發(fā)送方第一次和接收方建立 TCP 連接時，發(fā)送 1 個 SYN 報文
接收方返回 SYN-ACK 報文的同時，附帶一個隨機生成的名為 TFO Cookie 的標(biāo)識符給發(fā)送方
發(fā)送方收到 SYN-ACK 報文后，保存 TFO Cookie，發(fā)送 ACK 報文給接收方，完成三次握手，開始傳輸數(shù)據(jù)

(2) 后續(xù)連接

當(dāng)發(fā)送方再次連接同一個接收方時，可以在 SYN 報文中攜帶上次保存的 TFO Cookie，同時在 SYN 報文中附帶應(yīng)用層數(shù)據(jù) (也就是第一次握手時就直接發(fā)送數(shù)據(jù))
接收方驗證發(fā)送方的 TFO Cookie 后，將數(shù)據(jù)發(fā)送給應(yīng)用層處理，并返回 SYN-ACK 報文 (同時也可以發(fā)送數(shù)據(jù))
發(fā)送方收到 SYN-ACK 報文后，發(fā)送 ACK 報文給接收方，完成三次握手

2.優(yōu)點

通過 TFO，發(fā)送方在發(fā)送 SYN 報文時就可以直接攜帶數(shù)據(jù)，接收方可以在第一次握手時直接處理數(shù)據(jù)，并且在第二次握手時直接發(fā)送數(shù)據(jù)，最終:

發(fā)送方第一次發(fā)送數(shù)據(jù)，減少了 1.5 個 RTT 延遲
接收方第一次發(fā)送數(shù)據(jù)，減少了 1 個 RTT 延遲

發(fā)送方第一次發(fā)送數(shù)據(jù)，減少了 1.5 個 RTT 延遲

接收方第一次發(fā)送數(shù)據(jù)，減少了 1 個 RTT 延遲

3.局限性

(1) 兼容性

需要通信雙方都支持 TFO, 如果其中一方不支持，連接自動回退到傳統(tǒng)的 TCP 連接建立過程，此外，通信鏈路中的轉(zhuǎn)發(fā)設(shè)備 (NAT, 防火墻) 也會執(zhí)行這個兼容性機制。

(2) 安全性

雖然 TFO 的 Cookie 是由接收方生成并發(fā)送給發(fā)送方的，并且每個 Cookie 都與發(fā)送方關(guān)聯(lián)，但是增加了接收方的安全攻擊面，可能引發(fā)諸如 “TCP SYN Flood” 放大攻擊等安全風(fēng)險。

如果攻擊者從被入侵主機獲取到有效的 TFO Cookie，進(jìn)而偽造了大量的攜帶數(shù)據(jù)報文，那么接收方就需要大量的內(nèi)存來臨時存儲應(yīng)用數(shù)據(jù)，最終導(dǎo)致內(nèi)存耗盡。

(3) 部署環(huán)境要求

對內(nèi)核版本有要求，且需要修改內(nèi)核參數(shù)。

(4) 應(yīng)用數(shù)據(jù)過大

如果發(fā)送方第一次要發(fā)送的數(shù)據(jù)大于 TCP 的 MSS, 依然需要拆包進(jìn)行多次發(fā)送，當(dāng)應(yīng)用數(shù)據(jù)過大時，TCP Fast Open 帶來的優(yōu)勢 (RTT 減少) 幾乎可以忽略。

三、模擬環(huán)境

TFO 需要發(fā)送方和接收方同時支持，如果任意一方不支持 TFO，連接會自動回退到傳統(tǒng)的三次握手方式。

為了演示效果，筆者使用了 2 個 Linux 服務(wù)器作為通信發(fā)送方和接收方，對應(yīng)的發(fā)行版本和內(nèi)核版本參數(shù)如下。

1.TFO 對 Linux 內(nèi)核版本要求: >= 3.7。

# 發(fā)送方

## 發(fā)行版本 (WSL2 環(huán)境)
$ cat /etc/os-release 

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian

## 內(nèi)核版本
$ uname -r

5.10.0-21-amd64

# 接收方

## 發(fā)行版本
$ cat /etc/os-release

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"

## 內(nèi)核版本
$ uname -r

3.10.0-1160.53.1.el7.x86_64

2.內(nèi)核參數(shù)調(diào)整

TFO 啟用需要修改默認(rèn)內(nèi)核參數(shù):

0：關(guān)閉 TFO
1：啟用發(fā)送方模式 TFO
2：啟用接收方模式 TFO
3：同時啟用發(fā)送方和接收方模式 TFO

# 發(fā)送方啟用 TFO
$ echo 1 | sudo tee /proc/sys/net/ipv4/tcp_fastopen

# 接收方啟用 TFO
# 寫入 3 表示既啟用發(fā)送方 TFO 也啟用接收方 TFO
$ echo 3 | sudo tee /proc/sys/net/ipv4/tcp_fastopen

作為模擬實驗，筆者只是臨時修改了參數(shù)，可以采用如下步驟進(jìn)行配置永久生效:

(1) 編輯 /etc/sysctl.conf 文件，添加配置項

net.ipv4.tcp_fastopen=3

(2) 運行 sysctl -p 命令生效，重啟之后仍然有效

四、程序代碼

如果讀者使用主機的 curl 版本較高，可以直接使用如下方式直接開啟 TFO 機制方式訪問:

$ curl --tcp-fastopen http://example.com

# 可以使用如下方式確認(rèn) curl 版本是否支持 TFO
$ curl -V | grep -i TFO

因為筆者所使用的服務(wù)器中的 curl 版本較低，所以這里編寫 Python 腳本代碼，核心代碼其實就是 2 個套接字的參數(shù)的設(shè)置而已。

1.接收方 (服務(wù)端) 代碼

將接收方作為服務(wù)端程序的方式來實現(xiàn)，綁定/監(jiān)聽指定端口，然后接收來自發(fā)送方 (客戶端) 的 TCP 連接。

# service.py

import socket

def listen():
    # 初始化服務(wù)端監(jiān)聽對象
    listener = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    # 參數(shù) 32 表示 TCP 協(xié)議棧
    # 未完成的 Fast Open 隊列長度
    listener.setsockopt(socket.SOL_TCP, socket.TCP_FASTOPEN, 32)

    # 監(jiān)聽 12345 端口號
    # 為了模擬，所以不用主流端口號了 :-)
    listener.bind(('0.0.0.0', 12345))
    # 最大連接數(shù)設(shè)置為 1024
    listener.listen(1024)

    print("Server is listening on port 12345...")

    # 輪詢接收新的 TCP 連接
    while True:
        conn, addr = listener.accept()
        print(f"Accepted connection from {addr}")
        print(f"Received data: {conn.recv(1024)}")

        conn.send(b"Hello, Client")
        conn.close()

        print(f"Closed connection with {addr}")


if __name__ == "__main__":
    try:
        # 啟動監(jiān)聽
        listen()
    except KeyboardInterrupt:
        # 捕獲 Ctrl + C 終止程序
        print("Server shutting down...")

2.發(fā)送方 (客戶端) 代碼

# client.py

import socket

# 初始化客戶端監(jiān)聽對象
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 參數(shù) 32 表示 TCP 協(xié)議棧
# 未完成的 Fast Open 隊列長度
sock.setsockopt(socket.SOL_TCP, socket.TCP_FASTOPEN, 32)

# 向服務(wù)端發(fā)送數(shù)據(jù)時
# 設(shè)置 Fast Open 選項
sock.sendto(b"Hello, Server", socket.MSG_FASTOPEN, ("104.21.71.166", 12345))

print(f"Received data: {conn.recv(1024)}")

sock.close()

五、運行程序?qū)嶒?/h3>
程序核心代碼 (總共 2 行) 準(zhǔn)備就緒，接下來開始運行程序，驗證 TCP Fast Open 過程。
服務(wù)端公網(wǎng) IP: 104.21.71.166

1. 啟動服務(wù)端程序，并確認(rèn)監(jiān)聽狀態(tài)

# 在 1 個終端啟動服務(wù)端程序

$ python3 server.py

# 在另外 1 個終端查看程序監(jiān)聽狀態(tài)是否正常

$ netstat -ant | grep 12345 | grep LISTEN

tcp        0      0 0.0.0.0:12345            0.0.0.0:*               LISTEN

2. 客戶端開始抓包

打開 WireShark, 監(jiān)聽對應(yīng)的網(wǎng)卡設(shè)備。

3. 運行客戶端程序

# 為了驗證效果，這里可以連續(xù)運行幾次
# 每次運行間隔 3 - 5 秒即可
$ python3 client.py

# 輸出省略
...

4. 查看客戶端 TCP 連接狀態(tài)

netstat -ant | grep 12345 | grep TIME_WAIT

# 輸出如下
# 連續(xù)運行了多少次 client.py 
# 就會產(chǎn)生多少 TIME_WAIT 狀態(tài)的 TCP 連接
# 10.0.0.53 為客戶端的內(nèi)網(wǎng) IP 地址


tcp        0      0 10.0.0.53:38084         104.21.71.166:12345       TIME_WAIT  
tcp        0      0 10.0.0.53:37530         104.21.71.166:12345       TIME_WAIT  
tcp        0      0 10.0.0.53:37528         104.21.71.166:12345       TIME_WAIT  
tcp        0      0 10.0.0.53:38076         104.21.71.166:12345       TIME_WAIT  
tcp        0      0 10.0.0.53:38078         104.21.71.166:12345       TIME_WAIT  

...

一切運行正常，接下來就可以去看 WireShark 的抓包結(jié)果了。