表达式

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

筛选的是 `SYN` 标志位等于 `1`，同时 `ACK` 标志位等于 `0` 的 `TCP` 报文，也就是典型的 `TCP` 连接建立过程中由主动发起连接的一方向对方发送的初始 `SYN` 报文。

因此按照这道选择题的出题意图，应选择 A，所有 `SYN` 包。

不过如果按照非常严格的协议分析语言来说，A 选项里的「所有 `SYN` 包」表达得稍微有一点宽泛。因为 `TCP` 三次握手的第二个报文 `SYN+ACK` 同样设置了 `SYN=1`，但它设置了 `ACK=1`，所以不会被这个表达式匹配。更准确的答案应该写成「所有 `SYN=1` 且 `ACK=0` 的初始连接请求报文」。

这个小细节很适合软考记忆。考试看到

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

脑子里直接翻译成一句话

```text
我要建立连接，但我现在还不是在确认别人
```

这基本就是三次握手中的第一个报文。

理解这条过滤器之前，需要把 `TCP` 首部中的两个标志位拆开看。

`SYN` 是 `Synchronize` 的缩写，与连接建立以及初始序列号同步有关。RFC 9293 对 `SYN` 的定义就是同步序列号。`ACK` 则表示确认字段有效，当 `ACK` 标志被置位时，`Acknowledgment Number` 才承担确认对方数据或者序列号的作用。RFC 9293 也明确列出了 `SYN`、`ACK`、`RST`、`FIN` 等控制位的含义。

而在 `Wireshark` 中，`tcp.flags.syn` 和 `tcp.flags.ack` 都是布尔类型的显示过滤字段。官方 `TCP Display Filter Reference` 中可以直接查到 `tcp.flags.syn` 对应 `Syn`，`tcp.flags.ack` 对应 `Acknowledgment`。

所以看到

```text
tcp.flags.syn==1
```

可以直接理解成

```text
只保留 SYN 标志位打开的 TCP 报文
```

再看到

```text
tcp.flags.ack==0
```

可以理解成

```text
ACK 标志位必须关闭
```

中间的

```text
and
```

不是二选一，而是两个条件必须同时成立。

整个逻辑就成了

```text
SYN 打开
并且
ACK 关闭
```

用二进制思维去看会更加直观。

假设只关注 `SYN` 和 `ACK` 两个标志位，可以得到几种很典型的状态。

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

其中

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

正是本题过滤器要找的状态。

而

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

对应的则通常是三次握手第二步的 `SYN+ACK`。

这也是为什么 B 不能选。

把整个 `TCP` 三次握手放进真实网络通信中就非常清楚了。

我们在浏览器中访问一个传统的基于 `TCP` 的服务时，例如浏览器准备与服务器的 `443` 端口建立连接，在进入 `TLS` 握手和后续 `HTTP` 数据交换之前，底层通常需要先建立 `TCP` 连接。

假设客户端地址为

```text
192.168.1.100
```

服务器地址为

```text
203.0.113.10
```

客户端临时端口为

```text
52000
```

服务器端口为

```text
443
```

三次握手可以抽象成下面这个过程。

```text
客户端                              服务器

192.168.1.100:52000  ----------->  203.0.113.10:443
                     SYN
                     SYN=1
                     ACK=0


192.168.1.100:52000  <-----------  203.0.113.10:443
                     SYN+ACK
                     SYN=1
                     ACK=1


192.168.1.100:52000  ----------->  203.0.113.10:443
                     ACK
                     SYN=0
                     ACK=1
```

现在把题目的过滤表达式放进去。

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

第一步

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

两个条件全部满足，所以显示。

第二步

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

虽然 `SYN` 满足，但 `ACK==0` 不满足，所以被过滤掉。

第三步

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

两个要求都不符合，所以也不会显示。

于是三次握手经过这个过滤器以后，最典型的结果只剩下第一步。

这就是这道题真正考察的东西。

如果只死记 `A`，过几天很容易把 `SYN` 和 `SYN+ACK` 混起来。把它和三次握手的对话关系绑定起来，记忆会稳定得多。

第一次发消息的一方相当于说

```text
我想建立 TCP 连接
```

此时它是在主动提出请求，并不是在确认已经收到对方的连接请求，所以典型状态是

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

服务器收到后回答

```text
我收到了建立连接的请求，我也同意建立连接
```

这里既要同步自己的序列号，又要确认客户端发来的 `SYN`，于是同时存在

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

也就是 `SYN+ACK`。

客户端再确认服务器的响应

```text
收到了，可以开始通信
```

这时不需要再次发送新的 `SYN`，只需要确认，所以是

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

于是一个特别好记的模式就出来了。

```text
第一次    SYN
第二次    SYN+ACK
第三次    ACK
```

进一步转换成标志位就是

```text
第一次    SYN=1 ACK=0
第二次    SYN=1 ACK=1
第三次    SYN=0 ACK=1
```

本题把第一行原封不动地写成了 `Wireshark` 过滤条件。

所以看到

```text
syn==1 and ack==0
```

脑海里不要停留在两个孤立的数字 `1` 和 `0` 上，而应该立刻出现三次握手第一步。

还有一个很适合做题的记忆方法。

把 `SYN` 想成「申请」，把 `ACK` 想成「确认」。

那么

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

就是

```text
申请，但不是确认
```

这正是主动建立连接时发出的第一封申请。

而

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

就是

```text
既申请，又确认
```

服务器既确认客户端的连接请求，又发送自己的序列号同步信息，所以对应 `SYN+ACK`。

至于

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

就只剩下

```text
确认
```

正好对应第三次握手。

回到四个选项，A 和 B 最容易混淆。

A 是所有 `SYN` 包。

按照考试语境，这里实际上指初始 `SYN` 报文，也就是连接建立请求。因为题目明确要求

```text
tcp.flags.syn==1
```

同时

```text
tcp.flags.ack==0
```

所以答案指向 A。

B 是所有 `SYN+ACK` 包。

如果想筛选三次握手中的第二个报文，过滤器应该改成

```text
tcp.flags.syn==1 and tcp.flags.ack==1
```

因为第二个报文同时设置 `SYN` 和 `ACK`。

这里特别容易出现一种机械记忆错误。

看到

```text
tcp.flags.syn==1
```

马上选 A，没有继续看后面的

```text
tcp.flags.ack==0
```

这种做法碰巧在本题也能选对，但理解是不完整的。

因为真正决定「初始 `SYN`」和「`SYN+ACK`」区别的，恰恰就是后半段的 `ACK`。

可以把考试里的两个表达式放在一起记。

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

对应三次握手第一个包。

```text
tcp.flags.syn==1 and tcp.flags.ack==1
```

对应三次握手第二个包。

如果考试稍微变一下，把题目问成

```text
tcp.flags.syn==0 and tcp.flags.ack==1
```

情况就完全不同了。

它会匹配大量普通的 `ACK` 报文，因为一旦 `TCP` 连接进入正常数据传输阶段，大量报文都会设置 `ACK=1`。RFC 9293 规定，在连接建立后，确认信息会广泛存在于正常的 `TCP` 通信中。

再看 C，所有 `TCP` 重传。

这个选项和题目的过滤表达式不是一类东西。

`SYN`、`ACK`、`FIN`、`RST` 都属于 `TCP` 首部中的控制标志，而重传是根据序列号、确认号、时间关系以及前后报文上下文分析出来的通信现象。

`Wireshark` 对重传拥有专门的分析字段，例如

```text
tcp.analysis.retransmission
```

官方的 `TCP Display Filter Reference` 中明确列出了 `tcp.analysis.retransmission`，描述为疑似重传报文。

所以如果题目问

```text
如何筛选 TCP 重传
```

常见显示过滤条件会是

```text
tcp.analysis.retransmission
```

而不是检查 `SYN` 与 `ACK`。

这里还藏着一个网络故障排查里很实用的知识点。

连接建立阶段的 `SYN` 自己也可能发生重传。

例如客户端向服务器发送

```text
SYN
```

但由于防火墙丢包、网络路径故障、服务器没有响应或者中间设备异常，客户端迟迟收不到 `SYN+ACK`，操作系统就可能再次发送 `SYN`。

此时抓包可能看到

```text
SYN
SYN
SYN
```

多个连接请求。

这些报文大概率同样符合

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

所以本题过滤器并不能区分「正常的第一次 `SYN`」和「重传的 `SYN`」。

这点在真实故障分析中特别重要。

假设某个企业系统出现用户反馈，网页一直转圈，应用层日志却没有请求进入。我们在客户端附近抓包，使用

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

发现某个目标地址不断出现客户端发送的 `SYN`。

再进一步观察，没有对应的 `SYN+ACK` 返回。

这种流量形态往往提示问题发生在应用层请求真正建立之前。可能是服务器端口没有监听，也可能是防火墙直接丢弃，或者中间网络路径异常。

如果目标主机明确返回 `RST`，情况又不同，通常说明数据已经到达某个设备，但对应端口不接受这个连接。

这就自然带到了 D，所有 `RST` 包。

`RST` 是 `Reset`，用于重置连接，与 `SYN` 标志不是同一个字段。

在 `Wireshark` 的字段命名中，`RST` 对应的是

```text
tcp.flags.reset
```

因此筛选设置了 `RST` 标志的报文，可以使用类似

```text
tcp.flags.reset==1
```

官方显示过滤字段参考中同样列出了 `tcp.flags.reset`，类型为布尔字段。

所以 D 与题目条件也没有关系。

如果把几个最常考的 `TCP` 标志位放在脑海里形成一张图，会比孤立记忆过滤器好得多。

连接开始时主要关注

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

连接正常传输期间大量出现

```text
ACK
PSH+ACK
```

连接正常关闭时常见

```text
FIN
ACK
FIN
ACK
```

异常或者拒绝连接时经常看到

```text
RST
```

因此 `SYN` 更像建立连接阶段的标志，`FIN` 更像正常结束连接，`RST` 更像强制重置，`ACK` 则贯穿连接建立后的大量通信过程。

软考如果把这些标志位与 `Wireshark` 过滤器结合起来，通常并不是考特别复杂的抓包技巧，而是在检查两个知识点有没有真正连起来。

一个知识点是 `TCP` 状态和标志位。

另一个知识点是 `Wireshark` 显示过滤表达式。

理解了这两个东西，表达式几乎就是英语句子。

```text
tcp.flags.syn==1
```

读成

```text
TCP 的 SYN flag 被设置
```

```text
tcp.flags.ack==0
```

读成

```text
TCP 的 ACK flag 没有被设置
```

```text
and
```

读成

```text
并且
```

连起来就是

```text
TCP 的 SYN 被设置，并且 ACK 没有被设置
```

看到这里，三次握手第一步自然就出来了。

还有一个非常关键的实际操作细节。

题目说「使用 `Wireshark` 捕获时，过滤表达式……」，这种说法在考试材料里比较常见，不过从 `Wireshark` 官方术语来说，这条表达式属于 Display Filter，也就是显示过滤器，不是 Capture Filter，也就是捕获过滤器。

`Wireshark` 官方用户手册明确区分了两套过滤语言。Capture Filter 在真正抓取数据包之前工作，用来决定哪些数据包进入捕获文件，它使用 `libpcap` 过滤语言。Display Filter 则作用于已经捕获的数据，用来决定当前界面显示哪些报文。两者语法不同。

像

```text
tcp.flags.syn==1
```

这种按 `Wireshark` 协议字段名称进行比较的写法，是典型 Display Filter。

官方 `wireshark-filter` 手册甚至直接给出了使用位运算检测 `TCP SYN` 的例子

```text
tcp.flags & 0x02
```

用于判断 `SYN` 位是否被设置。

而真正的 Capture Filter 使用的是 `libpcap` 语法。

所以实际打开 `Wireshark` 做实验时，如果已经开始抓包，可以在上方的显示过滤框输入

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

应用以后，原始抓包文件中的其他数据并没有被删除，只是暂时不显示。

这一点官方文档讲得很明确，Display Filter 只改变显示结果，数据包仍然留在捕获文件里。

这也是 Display Filter 特别适合故障排查的原因。

我们可以先完整抓取一段流量，再不断切换过滤条件。

例如先观察初始连接请求

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

再观察服务器响应

```text
tcp.flags.syn==1 and tcp.flags.ack==1
```

再查看重传

```text
tcp.analysis.retransmission
```

再查看连接重置

```text
tcp.flags.reset==1
```

原始数据始终没有变化，只是观察窗口在变化。

回到考试场景，可以进一步研究出题人为什么要把 `ACK==0` 放在这里。

如果表达式仅仅写成

```text
tcp.flags.syn==1
```

它会匹配所有设置了 `SYN` 标志的报文，其中既包含连接发起方发送的初始 `SYN`，也包含服务器返回的 `SYN+ACK`。

因为 `SYN+ACK` 里面的 `SYN` 当然也是 `1`。

所以

```text
tcp.flags.syn==1
```

不能精确等同于三次握手第一步。

加入

```text
tcp.flags.ack==0
```

以后，第二步 `SYN+ACK` 就被排除了。

这也是这道题最值得记住的地方。

可以形成这样一组长期记忆。

```text
只看 SYN 位
tcp.flags.syn==1
```

范围比较宽，初始 `SYN` 和 `SYN+ACK` 都可能进去。

```text
SYN=1 并且 ACK=0
tcp.flags.syn==1 and tcp.flags.ack==0
```

锁定典型的初始连接请求。

```text
SYN=1 并且 ACK=1
tcp.flags.syn==1 and tcp.flags.ack==1
```

锁定典型的服务器 `SYN+ACK` 响应。

这种记法比背诵某道题的 A、B、C、D 更可靠，因为题目换一种问法仍然可以推出来。

还可以利用 `TCP` 标志位在首部中的二进制位置来加深理解。

传统 `TCP` 标志中，常见控制位包括

```text
URG
ACK
PSH
RST
SYN
FIN
```

其中 `SYN` 对应的位掩码常见为

```text
0x02
```

`ACK` 对应

```text
0x10
```

所以一个纯 `SYN` 报文常见 Flags 数值中包含

```text
0x02
```

而 `SYN+ACK` 同时包含

```text
0x02 + 0x10
```

也就是

```text
0x12
```

这也是抓包分析中经常看到的数字。

因此看到

```text
Flags 0x002
```

可以联想到 `SYN`。

看到

```text
Flags 0x012
```

可以联想到 `SYN+ACK`。

`Wireshark` 提供的

```text
tcp.flags.syn
tcp.flags.ack
```

只是把底层位运算包装成了更容易读懂的协议字段。

站在计算机组成原理的角度看，它仍然是一个位字段判断问题。

一个标志位只有两个基本状态。

```text
0
1
```

`1` 表示相应控制功能被设置，`0` 表示没有设置。

所以

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

并没有什么神秘之处，它其实就是一个布尔表达式。

设

```text
S = SYN
A = ACK
```

题目的条件就是

```text
S = 1
A = 0
```

如果把三次握手三个报文放进真值组合中，就变成

```text
第一个报文
S=1
A=0
匹配

第二个报文
S=1
A=1
不匹配

第三个报文
S=0
A=1
不匹配
```

这已经和编程里的

```text
if (syn == true && ack == false)
```

没有多少区别了。

对于有编程经验的人，完全可以把 `Wireshark` Display Filter 当成一种针对数据包结构执行的查询语言。

数据包相当于对象。

```text
tcp.flags.syn
```

相当于访问对象的一个布尔属性。

```text
tcp.flags.ack
```

是另一个布尔属性。

```text
==1
```

是判断属性为真。

```text
==0
```

是判断属性为假。

```text
and
```

就是逻辑与。

因此这道题其实同时考了协议知识和布尔逻辑。

再把四个答案压缩一次，会发现区分非常直接。

A 对应的是

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

和题目完全一致。

B 所要求的 `SYN+ACK` 应该是

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

与题目中的 `ACK==0` 冲突。

C 所说的重传需要考虑 `tcp.analysis.retransmission` 等分析字段，与 `SYN` 和 `ACK` 的固定组合不是一回事。

D 所说的 `RST` 应该检查

```text
tcp.flags.reset
```

题目完全没有检查这个标志。

因此考试时可以在十秒以内完成判断。

看到

```text
syn==1
```

先想到握手。

再看到

```text
ack==0
```

立刻排除 `SYN+ACK`。

剩下的就是连接发起方的初始 `SYN`。

最终答案记成一句足够牢固的话

```text
SYN 有，ACK 无，握手第一步
```

所以本题选择 A。

如果追求协议层面的精确表述，可以把 A 在脑中自动修正为

```text
所有 SYN=1 且 ACK=0 的 TCP 报文
```

或者

```text
典型的 TCP 初始连接请求 SYN 报文
```

这样既能拿到考试分数，也不会因为选项里的「所有 `SYN` 包」而形成一个不够严谨的概念。

以后碰到类似题，只需要记住三组关系即可。

```text
SYN=1 ACK=0
连接请求
三次握手第 1 步

SYN=1 ACK=1
连接响应
三次握手第 2 步

SYN=0 ACK=1
确认报文
三次握手第 3 步以及大量正常 TCP 通信
```

其中真正最值得背下来的不是选项 A，而是这一条

```text
tcp.flags.syn==1 and tcp.flags.ack==0
```

等价于

```text
SYN 有，ACK 无，正在主动敲门
```

服务器还没有进入这个报文的确认语义，因此 `ACK` 没有置位。等服务器回包时，才会出现 `SYN+ACK`。

这条逻辑一旦建立起来，不管软考把题目改成判断题、选择题、抓包分析题，还是让我们根据过滤表达式判断 `TCP` 握手阶段，都可以从标志位直接推导答案，不需要单独背题。

## 参考资料

Wireshark 官方 User's Guide，官方文档区分了 Capture Filter 与 Display Filter，并介绍了 Display Filter 对协议字段、字段值和逻辑表达式的过滤机制。

Wireshark 官方 Display Filter Reference for TCP，可查询 `tcp.flags.syn`、`tcp.flags.ack`、`tcp.flags.reset`、`tcp.analysis.retransmission` 等字段。

Wireshark 官方 `wireshark-filter` 手册，介绍 Display Filter 语法，并给出了通过 `tcp.flags & 0x02` 判断 `SYN` 位的示例。

Wireshark 官方 Capture Filter 文档，说明真正的 Capture Filter 使用 `libpcap` 过滤语言，与 Display Filter 语法不同。

RFC 9293，Transmission Control Protocol，对 `SYN`、`ACK`、`RST`、`FIN` 等 `TCP` 控制位以及确认号语义进行了规范定义。

筛选的是 SYN 标志位等于 1，同时 ACK 标志位等于 0 的 TCP 报文，也就是典型的 TCP 连接建立过程中由主动发起连接的一方向对方发送的初始 SYN 报文。

一眼看懂 Wireshark 的 SYN 过滤表达式，从 TCP 三次握手记住 tcp.flags.syn==1 and tcp.flags.ack==0

紫薇堂堂主

数据库

TCP过滤表达式tcp.flags.syn==1且tcp.flags.ack==0匹配SYN标志位开启、ACK标志位关闭的报文，对应TCP三次握手的第一个包（初始连接请求）。此表达式排除SYN+ACK（第二次握手）和普通ACK包。理解SYN有ACK无即握手第一步，是掌握Wireshark显示过滤与TCP标志位关联的关键考点。

代码解释

服务器

防火墙

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

TCP过滤表达式tcp.flags.syn==1且tcp.flags.ack==0匹配SYN标志位开启、ACK标志位关闭的报文，对应TCP三次握手的第一个包（初始连接请求）。此表达式排除SYN+ACK（第二次握手）和普通ACK包。理解SYN有ACK无即握手第一步，是掌握Wireshark显示过滤与TCP标志位关联的关键...

一眼看懂 Wireshark 的 SYN 过滤表达式，从 TCP 三次握手记住 tcp.flags.syn==1 and tcp.flags.ack==0-腾讯云开发者社区-腾讯云

一眼看懂 Wireshark 的 SYN 过滤表达式，从 TCP 三次握手记住 tcp.flags.syn==1 and tcp.flags.ack==0

一眼看懂 Wireshark 的 SYN 过滤表达式，从 TCP 三次握手记住 tcp.flags.syn==1 and tcp.flags.ack==0

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐