看到这道题时，很容易凭着已经背熟的口诀直接选 `B`。

三次握手嘛，无非就是

```text
SYN
SYN + ACK
ACK
```

于是看到题目里的「第二个报文段」，大脑很自然地跳到第二行，也就是 `SYN=1，ACK=1`。

可这道题偏偏多了几个非常关键的字。

题目写的是

在 TCP 三次握手过程中，客户端发送的第二个报文段包含的标志位是（　　）。

A． `SYN=1，ACK=0`  
B． `SYN=1，ACK=1`  
C． `SYN=0，ACK=1`  
D． `FIN=1，ACK=1`

如果严格按照这句话的语义理解，正确答案应该是

## C．`SYN=0，ACK=1`

原因就在「客户端发送的第二个报文段」这几个字。

这里不是问「三次握手中的第二个报文段」，而是在问「客户端自己发送的第二个报文段」。

TCP 三次握手中，客户端实际上发送两次报文。

```text
客户端          服务器

   SYN
   ------------------>

          SYN + ACK
   <------------------

          ACK
   ------------------>
```

客户端第一次发送

```text
SYN=1
ACK=0
```

服务器发送

```text
SYN=1
ACK=1
```

客户端第二次发送

```text
SYN=0
ACK=1
```

所以，如果我们只统计客户端发出去的 TCP 报文，那么客户端的第一个报文是第一次握手的 `SYN`，客户端的第二个报文则是第三次握手的 `ACK`。

这正是这道题最容易设陷阱的地方。

按照当前 TCP 标准 RFC 9293 给出的基本三次握手过程，主动发起连接的一方先发送 `SYN`，另一方返回 `SYN,ACK`，主动发起方再返回 `ACK`。RFC 中的基本握手示例也是这一顺序。

所以考试时可以把这道题压缩成一句非常好记的话。

## 客一 SYN，服一 SYN+ACK，客二 ACK

把这句话记住，类似选择题基本就不会再错。

这里的「客一」不是第一次握手，而是客户端第一次发送。

「服一」是服务器第一次发送。

「客二」是客户端第二次发送。

于是完整过程变成

```text
客一   SYN
服一   SYN + ACK
客二   ACK
```

题目问「客户端发送的第二个报文段」。

直接寻找「客二」。

答案自然就是

```text
SYN=0
ACK=1
```

也就是 C。

这套记忆法比单纯背

```text
SYN
SYN + ACK
ACK
```

更适合应付软考，因为考试题很喜欢改变观察角度。同样一套 TCP 三次握手，既可以问「第二次握手」，也可以问「服务器发送的报文」，还可以问「客户端第二次发送的报文」，甚至可以问某一时刻客户端处于什么状态。

只背三行标志位，在题目稍微改变措辞以后就容易失误。

把发送者也一起记进去，就稳定得多。

```text
Client 1    SYN
Server 1    SYN + ACK
Client 2    ACK
```

可以进一步压缩成

```text
客 SYN
服 SYN ACK
客 ACK
```

读起来甚至有一点节奏感。

客户端说，我要同步。

服务器说，我收到，同时我也要同步。

客户端说，我收到。

这一轮对话正好对应 TCP 建立连接的三个报文。

理解到这里以后，`SYN` 和 `ACK` 就不再只是两个需要死记的字母。

`SYN` 来自 `Synchronize`，作用和序列号同步有关。

TCP 并不是简单地问一句能不能连接，而是在建立连接时让通信双方交换自己的初始序列号。

假设客户端选择的初始序列号是 `x`。

客户端发出的第一个 TCP 报文可以写成

```text
SYN=1
ACK=0
seq=x
```

客户端表达的意思大致可以理解成

```text
我要建立 TCP 连接
我的初始序列号从 x 开始
```

这个时候为什么 `ACK=0`。

因为客户端还没有收到服务器的连接建立报文，没有什么需要确认。

所以第一步非常容易记。

```text
第一次握手
只有 SYN
```

也就是

```text
SYN=1
ACK=0
```

服务器收到以后，需要完成两件事情。

一件事情是确认客户端刚才的 `SYN`。

另一件事情是把服务器自己的初始序列号告诉客户端。

所以服务器的报文里同时出现 `ACK` 和 `SYN`。

假定服务器自己的初始序列号是 `y`，那么第二次握手大致可以写成

```text
SYN=1
ACK=1
seq=y
ack=x+1
```

这里已经能够看出为什么第二次握手必须同时具有两个标志位。

`ACK=1` 是在确认客户端。

`SYN=1` 是服务器在同步自己的序列号。

因此可以把第二次握手记成一句话。

```text
服务器一边回执，一边报自己的号码
```

「回执」对应 `ACK`。

「报自己的号码」对应 `SYN`。

所以服务器发送

```text
SYN + ACK
```

客户端收到服务器的 `SYN+ACK` 之后，服务器的初始序列号已经知道了，客户端自己的初始序列号也已经发送过了。

此时还有一件事情没有完成。

服务器还不知道客户端究竟有没有收到服务器的 `SYN`。

客户端因此需要再发一个确认。

第三次握手大致就是

```text
SYN=0
ACK=1
seq=x+1
ack=y+1
```

这里已经不再需要新的 `SYN`。

双方的初始序列号已经交换完成。

客户端此时只需要确认服务器发来的 `SYN`，所以形成一个纯粹的确认报文。

```text
ACK
```

对应标志位就是

```text
SYN=0
ACK=1
```

RFC 9293 对基本三次握手给出了非常清楚的示例，其中主动方 A 发出的第一条连接建立报文带 `SYN`，被动方 B 返回 `SYN,ACK`，随后 A 返回一个仅包含 `ACK` 控制位的报文。RFC 同时说明，`SYN` 用于同步序列号，而 `ACK` 标志置位时，确认号字段才具有相应的确认意义。

这里还有一个非常适合考试记忆的规律。

## SYN 是开门动作，ACK 是回执动作

把 TCP 连接想成两台机器互相登记号码。

客户端先登记

```text
SYN
```

服务器既确认客户端的登记，又登记自己的号码

```text
SYN + ACK
```

客户端已经登记过自己的号码了，所以没有必要再登记一次，只需要确认服务器的号码

```text
ACK
```

于是三次握手天然形成

```text
登记

登记 + 回执

回执
```

映射到 TCP 就是

```text
SYN

SYN + ACK

ACK
```

这个结构实际上非常漂亮。

第一条消息只有请求。

第二条消息同时包含对第一条消息的回答以及自己的请求。

第三条消息再回答第二条消息里的请求。

所以三次刚好闭环。

如果服务器第二次握手只返回 `ACK`，客户端只知道服务器收到了自己的 `SYN`，却还没有得到服务器自己的初始序列号。

如果服务器只发送 `SYN` 而没有 `ACK`，客户端又不知道服务器有没有收到最开始的连接请求。

所以第二次握手把两件事情合并起来

```text
确认客户端 SYN
+
发送服务器 SYN
```

于是得到

```text
SYN=1
ACK=1
```

这也是为什么很多人一看到「第二个报文」就条件反射地选 B。

B 本身当然没有错。

它确实对应 TCP 三次握手里的第二个报文。

问题只是题干并没有问「三次握手中的第二个报文」。

它问的是「客户端发送的第二个报文段」。

这两个表达只差几个字，答案却完全不同。

可以把两种题型并排放在脑中。

```text
三次握手的第二个报文

Server -> Client
SYN=1
ACK=1

答案 B
```

而

```text
客户端发送的第二个报文

Client -> Server
SYN=0
ACK=1

答案 C
```

考试时看到「第二」这个字，不要立刻找第二次握手。

先看它修饰的是谁。

如果题目写

```text
三次握手中的第二个报文段
```

答案是

```text
SYN=1
ACK=1
```

也就是 B。

如果题目写

```text
服务器发送的连接确认报文
```

通常还是

```text
SYN=1
ACK=1
```

也就是 B。

如果题目写

```text
客户端发送的第一个报文
```

答案变成

```text
SYN=1
ACK=0
```

也就是 A。

如果题目写

```text
客户端发送的第二个报文
```

答案就是

```text
SYN=0
ACK=1
```

也就是 C。

所以真正需要记住的不是 A、B、C 三个字母，而是三行方向。

```text
Client -> Server    SYN
Server -> Client    SYN + ACK
Client -> Server    ACK
```

方向一旦画出来，绝大多数题甚至不用背。

在真实计算机上抓包时也会看到同样的结构。

例如浏览器第一次和某个新的 Web 服务器建立 TCP 连接，在没有复用现有连接的情况下，应用层的 HTTP 或 TLS 数据出现以前，会先完成 TCP 建连。

用 Wireshark 观察一个典型的新建 TCP 连接，可以看到类似顺序

```text
Client -> Server    SYN
Server -> Client    SYN, ACK
Client -> Server    ACK
```

如果这是 HTTPS 连接，完成这三个 TCP 报文以后，才会进入后面的 TLS 交互，例如看到 `ClientHello`。

所以三次握手并不是教材里人为规定的一串口诀，而是真实操作系统 TCP 协议栈每天都在执行的连接初始化过程。

MDN 对 TCP 握手的概括也采用了 `SYN`、`SYN-ACK`、`ACK` 这三个消息的顺序。

说到这里，还可以顺手解决另一个特别容易混淆的问题。

`ACK` 有两个相关概念。

一个是 TCP 首部中的 `ACK` 标志位。

另一个是确认号 `Acknowledgment Number`。

考试题写

```text
ACK=1
```

通常是在说标志位。

它表达的是确认号字段有效。

而类似

```text
ack=x+1
```

是在讨论确认号的具体数值。

二者不是同一个东西。

例如第二次握手可以表示成

```text
SYN=1
ACK=1
seq=y
ack=x+1
```

这里第一个 `ACK=1` 是控制标志。

后面的 `ack=x+1` 是确认号。

理解这个区别以后，很多 TCP 序列号计算题会清楚很多。

还有一个考试中极其好用的小技巧，可以直接观察选项 D。

```text
FIN=1
ACK=1
```

`FIN` 来自连接终止相关过程。

看到 TCP 三次握手题出现 `FIN`，正常连接建立场景下基本可以直接排除。

可以建立这样的条件反射。

```text
建立连接看 SYN

释放连接看 FIN
```

`SYN` 主要和连接建立阶段联系在一起。

`FIN` 主要和正常连接释放阶段联系在一起。

于是 D 基本属于明显干扰项。

剩下 A、B、C 恰好就是三次握手三个阶段。

```text
A    SYN=1 ACK=0
B    SYN=1 ACK=1
C    SYN=0 ACK=1
```

这其实已经把整道题出题人的设计看透了。

A 是第一次握手。

B 是第二次握手。

C 是第三次握手。

D 是四次挥手相关干扰项。

真正需要判断的只是题干指向哪一步。

本题里的「客户端发送的第二个报文段」对应第三次握手，所以选择 C。

还可以做一个非常强的视觉记忆。

把三次握手写成两个标志位的变化

```text
        SYN   ACK

第 1 次   1     0

第 2 次   1     1

第 3 次   0     1
```

观察这三行，很像一个从 `SYN` 向 `ACK` 交接的过程。

```text
1 0
1 1
0 1
```

也可以念成

```text
一零

一一

零一
```

这里存在一个很漂亮的对称结构。

开始的时候只有 `SYN`。

中间两者都有。

结束的时候只有 `ACK`。

写成图形就是

```text
SYN  █ █ ·
ACK  · █ █
```

`SYN` 从开到关。

`ACK` 从关到开。

所以根本不需要把三个组合割裂地背下来。

只需要记住

```text
SYN   1 -> 1 -> 0
ACK   0 -> 1 -> 1
```

这个规律非常适合选择题。

看到第一次握手

```text
1 0
```

看到第二次握手

```text
1 1
```

看到第三次握手

```text
0 1
```

三组答案自然就出来了。

而本题又多绕了一层。

客户端只参与第 1 次和第 3 次发送。

所以客户端自己的两次发送是

```text
客户端第 1 个报文    1 0

客户端第 2 个报文    0 1
```

于是看到「客户端第二个」以后，根本不用再想服务器。

直接选

```text
0 1
```

也就是

```text
SYN=0
ACK=1
```

还有一种记忆方式特别适合连续做软考选择题时使用。

我们可以记住一句

## 客户端一开一关，服务器中间全开

这里的「开」只是把标志位是否为 `1` 作为视觉记忆，不是 TCP 的正式术语。

客户端第一次

```text
SYN 开
ACK 关
```

得到

```text
1 0
```

服务器位于中间

```text
SYN 开
ACK 开
```

得到

```text
1 1
```

客户端第二次

```text
SYN 关
ACK 开
```

得到

```text
0 1
```

于是完整变化仍然是

```text
10 -> 11 -> 01
```

记成数字甚至比记英文单词更快。

考场看到这类题，可以在草稿纸上写

```text
C -> S    10
S -> C    11
C -> S    01
```

整个三次握手就恢复出来了。

其中 `C` 是 Client，`S` 是 Server。

题目问客户端第二个报文。

沿着两个 `C -> S` 找第二个。

就是

```text
01
```

即 `SYN=0，ACK=1`。

这种方法还有一个好处，它不会因为题目改变表述而失效。

问第一次握手，找第一行。

问第二次握手，找第二行。

问第三次握手，找第三行。

问服务器发送什么，找唯一的 `S -> C`。

问客户端第一次发送什么，找第一个 `C -> S`。

问客户端第二次发送什么，找第二个 `C -> S`。

同一张三行小图可以处理五六种题型。

再回到为什么 `SYN` 会从 `1` 变成 `0`。

很多初学阶段的记忆障碍来自一个误解，以为三次握手既然都是在建立连接，那么三个报文都应该包含 `SYN`。

实际上 `SYN` 并不是连接还没成功的通用标志。

它有更具体的职责，用于序列号同步。

客户端已经在第一个报文里发送自己的 `SYN`。

服务器已经在第二个报文里发送自己的 `SYN`。

到第三个报文时，双方需要同步的初始序列号已经发送完成。

客户端剩下的任务只有确认服务器的 `SYN`。

所以

```text
SYN=0
ACK=1
```

非常合理。

只要记住一句

```text
双方各发一次 SYN
```

很多问题就自动解决了。

客户端的 `SYN` 在第一次握手。

服务器的 `SYN` 在第二次握手。

双方都已经完成 `SYN` 以后，第三次自然只剩 `ACK`。

还可以从报文方向理解。

```text
第 1 次
客户端把自己的信息送过去

第 2 次
服务器确认客户端，同时把自己的信息送回来

第 3 次
客户端确认服务器
```

信息交换形成完整闭环。

所以中间那一步最特殊。

服务器既要确认，又要同步。

它因此拥有

```text
SYN + ACK
```

两端则分别比较简单。

第一步只有

```text
SYN
```

第三步只有

```text
ACK
```

RFC 9293 对三次握手形成原因的描述也体现了这一点，双方都需要发送自己的初始序列号，并收到对方对该序列号的确认。原本可以把服务器的确认以及服务器自己的 `SYN` 看成两个逻辑动作，但它们能够合并到同一个 TCP 报文中，因此形成经典的三消息握手。

对于软考记忆，我更推荐保留下面这三层。

第一层用于秒选。

```text
10 -> 11 -> 01
```

第二层用于防止读错题。

```text
客 -> 服
服 -> 客
客 -> 服
```

把它们组合起来就是

```text
客 -> 服    SYN=1 ACK=0    10

服 -> 客    SYN=1 ACK=1    11

客 -> 服    SYN=0 ACK=1    01
```

第三层用于真正理解。

```text
客户端同步自己的序列号

服务器确认客户端，同时同步自己的序列号

客户端确认服务器
```

只要这三层建立起来，就已经不是在死记 TCP 三次握手，而是在根据通信逻辑推导答案。

考场上最值得警惕的正是题干中的限定词。

「第二次握手」

和

「客户端发送的第二个报文」

完全不是一回事。

前者对应整个通信过程里的第二条消息

```text
Server -> Client
SYN=1
ACK=1
```

答案 B。

后者对应客户端自己发送的第二条消息，也就是整个三次握手里的第三条消息

```text
Client -> Server
SYN=0
ACK=1
```

答案 C。

所以这道题最终可以压缩成一张脑内草图。

```text
           10
Client ----------------> Server

           11
Client <---------------- Server

           01
Client ----------------> Server
```

题目问客户端发送的第二个报文。

客户端向右一共射出两支箭。

第一支是 `10`。

第二支是 `01`。

因此答案锁定

## C．`SYN=0，ACK=1`

最推荐记忆的口诀也可以最终压缩成十二个字。

```text
客一发 SYN
服一发 SYN ACK
客二发 ACK
```

再压缩一点就是

```text
客 SYN，服 SYN ACK，客 ACK
```

配合数字规律

```text
10 -> 11 -> 01
```

基本就够用了。

以后再遇到类似题，看到「客户端第二个」四个字，脑中直接出现

```text
客二 = 第三次握手 = ACK
```

于是

```text
SYN=0
ACK=1
```

答案 C。

还有最后一个很重要的考试判断。如果某个题库把完全相同的题干「客户端发送的第二个报文段」给出的标准答案写成 B，那么就需要警惕题库题干是否存在表述问题。B 对应的是「三次握手中的第二个报文段」，这个报文实际上由服务器发送，而不是客户端发送。按照标准 TCP 三次握手以及 RFC 9293 的基本握手流程，客户端第二次发送的确是第三次握手的纯 `ACK`。

# 参考资料

RFC Editor，Transmission Control Protocol，RFC 9293，当前 TCP 核心规范，其中 Section 3.5 给出了 Basic Three-Way Handshake。[RFC 9293 Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293.html?utm_source=chatgpt.com)

RFC Editor，RFC 9293 信息页，可用于确认该文档作为 TCP 规范的发布信息。[RFC 9293 Information](https://www.rfc-editor.org/info/rfc9293/?utm_source=chatgpt.com)

MDN Web Docs，TCP handshake，对三次握手使用 `SYN`、`SYN-ACK`、`ACK` 的顺序进行了简明说明。[MDN TCP handshake](https://developer.mozilla.org/zh-CN/docs/Glossary/TCP_handshake?utm_source=chatgpt.com)

于是看到题目里的「第二个报文段」，大脑很自然地跳到第二行，也就是 SYN=1，ACK=1。

TCP 三次握手最容易看错的一道题，别把客户端第二个报文段当成第二次握手

紫薇堂堂主

编程语言

TCP三次握手中，客户端发送的第二个报文段是纯ACK确认包，标志位为SYN=0、ACK=1，对应选项C。注意区分“三次握手中的第二个报文”（服务器发送，SYN=1、ACK=1）与“客户端发送的第二个报文”（第三次握手，仅ACK），掌握“客SYN、服SYNACK、客ACK”方向即可快速解题。

代码解释

服务器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

TCP 三次握手最容易看错的一道题，别把客户端第二个报文段当成第二次握手-腾讯云开发者社区-腾讯云

TCP 三次握手最容易看错的一道题，别把客户端第二个报文段当成第二次握手

TCP 三次握手最容易看错的一道题，别把客户端第二个报文段当成第二次握手

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐