跟 AI 学 Linux:为什么 TCP 建立连接需要三次握手?

1. 议题

为什么 TCP 建立连接需要三次握手，而不是两次？

谢希仁教授的《计算机网络》给出了答案：防止已失效的连接请求报文突然传送到服务端，产生错误。

这句话太抽象。读了分析，也难以把握要点。

让我们请 AI 老师来讲解。本文邀请了「ChatGPT 网页版」和「Claude Code + GLM-4.7」。由于 AI 老师"废话"较多，对话已作删减。

2. 对话

2.1 问

《计算机网络》在讲解 TCP 建立连接时，这样描述第三次 ACK 的作用："这主要是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。"

我不理解。什么是"失效的连接请求"？能否举个具体的例子？这种"失效的连接请求"在实际网络中是如何产生的？

2.2 答

这是一个非常经典、也很容易被教材一句话带偏的问题。我们一步一步把“已失效的连接请求报文段”讲清楚，用具体可发生的真实网络场景来解释为什么 TCP 三次握手一定要有最后那一次 ACK。

一个非常具体、可发生的例子（重点）

我们用时间线来看一个真实可能发生的场景。

场景背景

• • 客户端：C
• • 服务器：S
• • 网络：发生了严重拥塞（比如跨国链路、无线网络）

【Step 1】客户端第一次发起连接（但网络很差）

时间 T1C → S : SYN(seq = 100)

但这个 SYN：

• • 在网络中被严重延迟
• • 或者在某个路由器里排队很久

【Step 2】客户端等不及，认为连接失败

时间 T2客户端一直没等到 SYN-ACK→ 认为这次连接失败→ 放弃这次连接（这次 SYN 对客户端来说“失效”了）

⚠️ 注意：客户端此时已经不再认为这个 SYN 有意义了

【Step 3】客户端重新发起一次“新的连接”

时间 T3C → S : SYN(seq = 300)

这次网络正常：

S → C : SYN-ACK(seq = 500, ack = 301)C → S : ACK

✅ 连接成功建立

【Step 4】⚠️ 问题出现了：旧 SYN 终于到了！

时间 T4（很晚）网络中那个“卡住的旧 SYN(seq=100)”终于到达了服务器

如果 TCP 只有“两次握手”，会发生什么？

假设 TCP 只有两次握手（SYN → SYN-ACK），服务器会这样想：

“哦，有客户端要连我！”

于是：

S → C : SYN-ACK(ack = 101)

但是：

• • 客户端 根本不认识这个 SYN
• • 这个连接客户端早就放弃了

❌ 结果：

• • 服务器误以为连接已建立
• • 分配了缓冲区、控制块、连接资源
• • 客户端却完全不理

👉 服务器白白浪费资源，形成“半连接”或“幽灵连接”

这在大规模环境下就是 SYN Flood / 资源耗尽的根源之一

第三次 ACK 是如何“拦截”这种失效请求的？

现在看 三次握手的关键作用：

1️⃣ C → S : SYN(seq = x)2️⃣ S → C : SYN-ACK(ack = x+1)3️⃣ C → S : ACK(ack = y+1)

对“失效 SYN”的处理

当服务器收到那个迟到的旧 SYN：

1. 1. 服务器回 SYN-ACK
2. 2. 客户端不会回 ACK
• • 因为它根本没发过这个 SYN
3. 3. 服务器：

   等不到第三次 ACK→ 认为连接不成立→ 释放资源

✅ 失效连接请求被自动丢弃

2.3 思考

按照 AI 老师的表述，“失效 SYN”如果不经过客户端 ACK 确认，服务端直接分配资源建好连接，这样会白白浪费资源。

我理解了第三次握手 ACK 想要规避的异常情况，但是我感觉这个机制要生效，seq 序号起了很大作用，所以继续追问。

2.4 问

第三次 ACK 的重要作用我理解了。seq 在其中起到了关键作用。请详细阐述 seq 在 TCP 建立中的机制，交互流程请用清晰的流程图阐释。

2.5 答

你这个直觉非常非常对 👍可以直接给结论：

TCP 三次握手的“灵魂”不是 ACK，而是 seq + ack 这一套“编号确认机制”。

先给你一句“总纲式理解”

在 TCP 建立连接阶段：seq 的核心作用不是“计数”，而是“身份确认 + 历史隔离”。

它解决了三件事：

1. 1. 确认对方是否真的收到了我的报文
2. 2. 区分“新连接”和“旧连接的残留报文”
3. 3. 为后续可靠数据传输建立统一的序号空间

TCP 三次握手 seq 机制流程图（重点）

客户端 C                                     服务器 S────────────────────────────────────────────────────────【初始状态】C: 随机生成 ISN_c = 1000S: 随机生成 ISN_s = 7000① 第一次握手（SYN）────────────────────────────────────────────────────────C → S : SYN        seq = 1000含义：- “我要建立连接”- “我这边的数据序号从 1000 开始”② 第二次握手（SYN + ACK）────────────────────────────────────────────────────────S → C : SYN + ACK        seq = 7000        ack = 1001含义：- “我收到了你从 1000 开始的 SYN”- “下次请你从 1001 开始发”- “我这边的数据序号从 7000 开始”③ 第三次握手（ACK）────────────────────────────────────────────────────────C → S : ACK        seq = 1001        ack = 7001含义：- “我确认你从 7000 开始的 SYN”- “你下次请从 7001 开始发”- “我们双方序号空间对齐了”【连接建立完成】────────────────────────────────────────────────────────双方状态：ESTABLISHED

为什么 seq 能防止“失效连接请求”？（关键推理）

场景：旧 SYN 延迟到达

假设网络中出现了一个迟到的旧 SYN：

旧 SYN: seq = 200

服务器收到后：

S → C : SYN-ACK        ack = 201

但客户端此时的状态是：

• • 当前连接的发送序号已经是：

  seq = 5000+

客户端会怎么判断？

客户端发现：

ack = 201 ❌

这意味着：

“服务器在确认一个我当前根本不存在的序号空间”

于是客户端直接：

• • 丢弃该报文
• • 不会发送第三次 ACK

👉 连接自然失败

2.6 思考

我懂了。

三次握手的本质：双方互相确认序号空间。第二次握手，服务端确认客户端序号空间。第三次握手，客户端确认服务端序号空间。

那么初始序列号（ISN）的安全性很关键啊。

在请教 ISN 的实现之前，先让 AI 生成几个实验验证一下。毕竟“ChatGPT 也可能会犯错，请核查重要信息。”

3. 实验

3.1 观察三次握手流程

使用 nc 启动服务：

$ nc -l 8083

开启 tcpdump 抓包：

$ sudo tcpdump -i lo -nn 'tcp port 8083' -S

nc 连接服务：

$ nc 127.0.0.1 8083

观察 tcpdump 输出：

13:08:38.673901 IP 127.0.0.1.16054 > 127.0.0.1.8083: Flags [S], seq 3076632314, win 43690, options [mss 65495,sackOK,TS val 602203118 ecr 0,nop,wscale 10], length 013:08:38.673908 IP 127.0.0.1.8083 > 127.0.0.1.16054: Flags [S.], seq 1418142432, ack 3076632315, win 43690, options [mss 65495,sackOK,TS val 602203118 ecr 602203118,nop,wscale 10], length 013:08:38.673913 IP 127.0.0.1.16054 > 127.0.0.1.8083: Flags [.], ack 1418142433, win 43, options [nop,nop,TS val 602203118 ecr 602203118], length 0

三次握手流程：

1. 1. 第一个包 [S] SYN，客户端的 ISN = 3076632314
2. 2. 第二个包 [S.] SYN+ACK，服务器的 ISN = 1418142432，确认号 ack 3076632315（客户端 ISN + 1）
3. 3. 第三个包 [.] ACK，确认号 ack 1418142433（服务器 ISN + 1）

观察：

• • 双方的 ISN 都是随机的大数
• • 每次握手，虽然 length 为 0，但序列号都会 +1

3.2 模拟丢弃第三次握手 ACK

先看上一个实验中正常建连的状态：

$ ss -ant | awk 'NR==1 || /:8083/'State     Recv-Q Send-Q Local Address:Port     Peer Address:PortLISTEN    0      1            0.0.0.0:8083          0.0.0.0:*ESTAB     0      0          127.0.0.1:54506       127.0.0.1:8083ESTAB     0      0          127.0.0.1:8083        127.0.0.1:54506

输出的最后一行，表示服务端处于 ESTAB 状态。

然后我们用 iptables 模拟丢掉客户端的 ACK，再重复上述实验，观察一下状态。

$ sudo iptables -A OUTPUT -p tcp --tcp-flags ACK ACK -d 127.0.0.1 --dport 8083 -j DROP

$ ss -ant | awk 'NR==1 || /:8083/'State     Recv-Q Send-Q Local Address:Port    Peer Address:PortLISTEN    0      1            0.0.0.0:8083         0.0.0.0:*SYN-RECV  0      0          127.0.0.1:8083       127.0.0.1:29530ESTAB     0      0          127.0.0.1:29530      127.0.0.1:8083

此时客户端视角是 ESTAB 状态，服务端是 SYN-RECV 状态。

观察：

• • 三次握手是原子性的。服务端收到 SYN 后进入 SYN-RECV 状态，只有收到 ACK 才进入 ESTAB 状态。
• • 服务端处于 SYN-RECV 状态时，应该在半连接队列。重传 SYN+ACK 超时后自动释放。

最后别忘了把 iptables 规则移除。

3.3 模拟"滞留 SYN"场景

#!/bin/bash# simulate_delayed_syn.sh# 添加网络延迟（针对本地环回）sudo tc qdisc add dev lo root handle 1: netem delay 1000ms 500ms# 1000ms 基础延迟 ± 500ms 抖动# 启动服务器echo "Starting server on port 8080..."nc -l 8080 &SERVER_PID=$!sleep 1# 客户端发起连接（会超时重传）echo "Client connecting..."timeout 3 nc localhost 8080 &CLIENT_PID=$!# 观察连接状态watch -n 0.5 'ss -ant | grep 8080'# 清理trap "sudo tc qdisc del dev lo root; kill $SERVER_PID $CLIENT_PID 2>/dev/null; exit" INTwait

笔者用 tc 模拟 SYN 延迟。执行脚本的同时进行 tcpdump：

23:51:00.250756 IP 127.0.0.1.50952 > 127.0.0.1.8080: Flags [S], seq 3597230085, win 43690, options [mss 65495,sackOK,TS val 640743358 ecr 0,nop,wscale 10], length 023:51:01.568861 IP 127.0.0.1.8080 > 127.0.0.1.50952: Flags [S.], seq 3188625949, ack 3597230086, win 43690, options [mss 65495,sackOK,TS val 640744695 ecr 640743358,nop,wscale 10], length 023:51:02.083846 IP 127.0.0.1.8080 > 127.0.0.1.50952: Flags [S.], seq 3188625949, ack 3597230086, win 43690, options [mss 65495,sackOK,TS val 640745741 ecr 640743358,nop,wscale 10], length 023:51:02.878941 IP 127.0.0.1.50952 > 127.0.0.1.8080: Flags [.], ack 3188625950, win 43, options [nop,nop,TS val 640746013 ecr 640744695], length 023:51:02.909311 IP 127.0.0.1.50952 > 127.0.0.1.8080: Flags [.], ack 3188625950, win 43, options [nop,nop,TS val 640746528 ecr 640744695], length 0

执行多次，日志多种多样。总的来说观察到一个现象：

• • 三次握手阶段的包重传，只要是“四元组 + ISN”一致，两端都会重发正常的包。

4. 内核实现

经过以上实验，在理解三次握手机制的同时，对 Linux 的实现也进行了一些猜测。

带着这些疑问，再请教一下 AI 老师。

4.1 任务

请梳理 @net/ 目录下关于 TCP 三次握手建立连接的源码，生成报告。

需要讲清楚：

1. 1. 客户端和服务端的状态变化
2. 2. ISN 的计算机制
3. 3. 服务端 SYN-RECV 状态，半连接队列的超时释放机制
4. 4. 包重传机制以及收到重传包后的行为
5. 5. Linux 提供的可配置参数
6. 6. 你认为的要点

4.2 报告

Linux Kernel Version: 5.15.198目标目录:net/ipv4/, include/net/, net/core/

完整的报告在 01_TCP_HANDSHAKE_REPORT.md^[1] ，这里仅摘要关键点。

客户端状态转换流程

主要函数:tcp_v4_connect() in net/ipv4/tcp_ipv4.c:209

┌─────────────┐     connect()     ┌─────────────┐│  TCP_CLOSE  │ ────────────────> │ TCP_SYN_SENT│└─────────────┘                   └─────────────┘                                           │                                           │ 接收 SYN-ACK                                           │ 发送 ACK                                           ▼                                    ┌───────────────┐                                    │TCP_ESTABLISHED│                                    └───────────────┘

状态转换代码位置:

步骤 1: CLOSE → SYN_SENT

• • 位置:net/ipv4/tcp_ipv4.c:285

tcp_set_state(sk, TCP_SYN_SENT);

步骤 2: SYN_SENT → ESTABLISHED

• • 位置:net/ipv4/tcp_input.c:6115

void tcp_finish_connect(struct sock *sk, struct sk_buff *skb){    // ...    tcp_set_state(sk, TCP_ESTABLISHED);}

服务端状态转换流程

主要函数:

• • tcp_v4_conn_request() - 处理 SYN (net/ipv4/tcp_ipv4.c:1534)
• • tcp_v4_syn_recv_sock() - 处理 ACK (net/ipv4/tcp_ipv4.c:1554)

┌─────────────┐     listen()      ┌─────────────┐│  TCP_CLOSE  │ ────────────────> │ TCP_LISTEN  │└─────────────┘                   └─────────────┘                                           │                                           │ 接收 SYN                                           │ 创建 request_sock                                           ▼                                    ┌─────────────────┐                                    │TCP_NEW_SYN_RECV │                                    │   (半连接状态)    │                                    └─────────────────┘                                           │                                           │ 接收 ACK                                           │ 创建完整 socket                                           ▼                                    ┌───────────────┐                                    │TCP_ESTABLISHED│                                    └───────────────┘

状态转换代码位置:

步骤 1: CLOSE → LISTEN

• • 由用户空间 listen() 系统调用触发
• • 内核函数: inet_listen()

步骤 2: LISTEN → NEW_SYN_RECV

• • 位置:net/ipv4/tcp_input.c:7074

if (!inet_csk_reqsk_queue_hash_add(sk, req, req->timeout)) {    // 添加到 ehash，状态变为 TCP_NEW_SYN_RECV}

步骤 3: NEW_SYN_RECV → ESTABLISHED

• • 位置:net/ipv4/tcp_input.c:6603

tcp_set_state(sk, TCP_ESTABLISHED);sk->sk_state_change(sk);

ISN (初始序列号) 计算机制

主函数:secure_tcp_seq() in net/core/secure_seq.c:135

u32 secure_tcp_seq(__be32 saddr, __be32 daddr,                   __be16 sport, __be16 dport){    u32 hash;    net_secret_init();    hash = siphash_3u32((__force u32)saddr,                        (__force u32)daddr,                        (__force u32)sport << 16 | (__force u32)dport,                        &net_secret);    return seq_scale(hash);}

步骤 1: SipHash 计算

• • 输入: 四元组 (源IP、目的IP、源端口、目的端口)
• • 密钥:net_secret (启动时随机生成)
• • 输出: 64位哈希值

步骤 2: 时钟缩放函数:seq_scale() in net/core/secure_seq.c:38

static u32 seq_scale(u32 seq){    return seq + (ktime_get_real_ns() >> 6);}

• • 时钟分辨率: 64 纳秒 (>> 6 = 除以 64)
• • 目的: 防止序列号回绕攻击

半连接队列 (Syn Queue)

关键结构:request_sock - 表示半开连接

核心函数:

SYN 处理流程

位置:net/ipv4/tcp_input.c:6948-7102

┌─────────────────────────────────────────────────────────────────┐│  SYN 到达                                                        │└─────────────────────────────────────────────────────────────────┘                          │                          ▼┌─────────────────────────────────────────────────────────────────┐│  tcp_v4_conn_request()                                          ││  ┌─────────────────────────────────────────────────────────┐    ││  │ 1. 检查 syncookies 和队列是否满                            │    ││  │    if (inet_csk_reqsk_queue_is_full(sk))                │    ││  │        want_cookie = tcp_syn_flood_action(...)          │    ││  └─────────────────────────────────────────────────────────┘    │└─────────────────────────────────────────────────────────────────┘                          │                          ▼┌─────────────────────────────────────────────────────────────────┐│  分配 request_sock                                               ││  req = inet_reqsk_alloc(rsk_ops, sk, !want_cookie);             │└─────────────────────────────────────────────────────────────────┘                          │                          ▼┌─────────────────────────────────────────────────────────────────┐│  计算 ISN                                                        ││  isn = af_ops->init_seq(skb);  // tcp_v4_init_seq               ││  tcp_rsk(req)->snt_isn = isn;                                   │└─────────────────────────────────────────────────────────────────┘                          │                          ▼┌─────────────────────────────────────────────────────────────────┐│  添加到 ehash 并启动定时器                                         ││  inet_csk_reqsk_queue_hash_add(sk, req, req->timeout);          ││  // req->timeout = tcp_timeout_init() = 1 秒                    │└─────────────────────────────────────────────────────────────────┘                          │                          ▼┌─────────────────────────────────────────────────────────────────┐│  发送 SYN-ACK                                                    ││  af_ops->send_synack(sk, dst, &fl, req, &foc, ...);             │└─────────────────────────────────────────────────────────────────┘

超时机制详解

超时处理函数:reqsk_timer_handler() in net/ipv4/inet_connection_sock.c:828

超时计算公式 (inet_connection_sock.h:288):

static inline unsigned long reqsk_timeout(struct request_sock *req,                                          unsigned long max_timeout){    u64 timeout = (u64)req->timeout << req->num_timeout;    return (unsigned long)min_t(u64, timeout, max_timeout);}

参数说明:

• • req->timeout: 初始超时 (TCP_TIMEOUT_INIT = 1 秒)
• • req->num_timeout: 已发生超时次数
• • max_timeout: 最大超时 (TCP_RTO_MAX = 120 秒)
• • 算法: 每次超时后，超时时间翻倍 (指数退避)

重传时间表示例:

老化连接修剪

位置:net/ipv4/inet_connection_sock.c:883-894

当队列长度 > 50% 满时，优先保护新连接:

if ((qlen << 1) > max(8U, READ_ONCE(sk_listener->sk_max_ack_backlog))) {    int young = reqsk_queue_len_young(queue) << 1;    while (max_syn_ack_retries > 2) {        if (qlen < young)            break;        max_syn_ack_retries--;  // 减少老连接的重试次数        young <<= 1;    }}

5. 总结

与 AI 老师讨论之后，笔者对 TCP 三次握手有了更深入的理解。

三次握手的核心价值：通过双向序号空间确认机制，有效防止网络中失效连接请求导致的资源浪费问题。这三次往返看似简单，却巧妙解决了分布式系统中不可靠网络通信的难题。

但是，三次握手机制在每次建立连接时都需要一个完整的 RTT（往返时间）。在高延迟网络场景下，这可能会影响用户体验。

问题又来了：我们能否在保证 TCP 建连安全性的前提下，优化这个建立过程？

Linux 给出的答案：TCP Fast Open（TFO）。

下一篇，笔者将与 AI 老师讨论 TFO 的设计思想和实现机制。

1. https://gitee.com/shichaoyuan/learn-linux-with-ai↩︎