1. 案例

有⼀一天，⼴广告业务⼈人员反馈，部分⼴广告位显示空⽩白，如下图所示。

作为开发，想不明⽩为什么广告位显示空白，⽽且是选择性空白。于是登⼊服务器查看⼴告曝光日志，结果显示所有广告位都有广告。那到底是什么原因导致空⽩⼴告呢？

运维也来帮助找原因。运维领导站在后⾯指挥着运维⼩兵（紧张、压⼒大，⼿还发抖），仔细查了半⼩时，没有发现问题。同时另⼀个有着抓包分析经验的运维人员也过来帮忙，决定进⾏抓包，希望能从抓包文件⾥面捕获到线索。

⼴告业务⼈员⾸先发现⼴告显示有问题，担⼼是⾃己的操作失误导致了问题，所以非常希望能够知道问题的原因。

这三种⼈的状态分析如下图：

最终通过抓包分析，发现问题是由网关网卡 MTU 配置不当导致（“⼴告位空⽩显示的罪魁祸首：MTU不

⼀致”会有介绍）。

当出现 TCP 相关问题的时候，抓包分析对于开发、运维、DBA、测试、前端都很重要。

2. 哪些场景需要抓包分析？

TCP/IP 是互联网应用的基础。我总结出如下场景需要抓包分析：

第⼀种场景是分析程序运⾏机制。开发 Cetus 的过程中，经常需要分析竞争对手产品的特性，这样有助于⾃身产品的不断进化，但竞争对⼿产品（如商业软件数据库中间件 OneProxy）未必是开源的，这个时候抓包分析就显得极其重要。通过抓包分析，我们可以研究 OneProxy 在分布式场景下， SQL 是如何代理给多个后端的，以及 OneProxy 有没有实现流式传输。

第二种场景是挖掘线上潜在问题。例如，开发广告投放系统的时候，利用流量复制⼯具 TCPCopy 复制线上广告流量到测试系统，通过抓包查看⾃己开发的广告投放系统有没有异常的 TCP 状态，如⼤量CLOSE_WAIT 状态（忘记关闭连接导致的连接泄漏）。开发 Cetus 的时候，利用 TCPCopy 复制线上 MySQL 流量到 Cetus 测试系统，查看 Cetus 中间件有没有发送不必要的 SQL 语句给后端，⼀旦发现了，就可以及时纠正问题，达到不断优化 Cetus 的⽬的。

第三种场景是线上出问题了，利用抓包来捕获问题的线索。例如 Cetus 部署到阿⾥云环境，开发遇到了性能慢的问题。通过抓包分析，发现是⽹络抖动导致应⽤程序报大量慢⽇志。

总的来说，抓包分析不仅⽤于帮助解决问题，⽽且也可以⽤于分析软件运⾏的机制，如没有源代码的软件。有⼀种说法：“不会抓包分析，如同医⽣不会使⽤听诊器“。⾯对 TCP 相关问题，如果不会抓包分析，你很难去分析和解决问题。

3. 如何抓包？

抓包的好处是可以保留问题的现场，⽅便后续判断。

那怎么抓包呢？

有了抓包工具，抓包其实很简单。

tcpdump 和 wireshark 是目前最流行的两个抓包⼯具。

3.1. tcpdump 抓包

tcpdump 在 Linux 服务器领域普遍被采用。对于开发/运维/dba/测试来说，tcpdump 抓包主要⽤如下命令就能解决工作中 95%的抓包问题：

tcpdump -i any tcp and port xxx -s yyy -w zzz.pcap -v

参数解释如下：

-i any 从所有网卡设备上抓包

tcp 抓取 TCP 类型的数据包

and “与”的意思

port xxx 捕获端⼝口为 xxx 的应⽤用数据包

-s yyy 设置抓包⼤小为 yyy 大小，⼀般在 60～1500 范围，视情况⽽定

-w zzz.pcap 抓包数据存放到zzz.pcap，pcap 后缀名⽅便wireshark 识别

-v 设置实时显示抓包状况

如果想捕获 web 80 端⼝口的数据包，命令如下：

tcpdump -i any tcp and port 80 -s 1500 -w web.pcap -v

输⼊命令，按回车键就开始抓包，如下图。

这里Got 为 0，代表还没有捕获到任何数据包。

我们执行telnet 访问来试验 tcpdump 的抓包情况。

telnet 命令格式是：telnet ip port

执行telnet 172.17.0.2 80，即访问 172.17.0.2 机器的 80 服务，结果显示 Connection refused，代表连

接请求被拒绝。

这时 tcpdump 实时显示已经捕获到 2 个数据包。

如果要停⽌抓包，按ctrl+c就可以终止抓包过程，这时 tcpdump 命令显示内核捕获到了多少个数据包，tcpdump 抓到了多少个数据包，丢了多少个数据包，通过这些数据可以判断出抓包的情况。

下图给出一个例⼦

• 2 packets captured代表捕获了 2 个数据包

• 2 packets received by filter代表从内核的过滤器⾥面接收到 2 个数据包

• 0 packets dropped by kernel代表没有丢包，一般压⼒不大的场景不会丢包。

抓包的时候需要注意如下事项：

1. 抓包⽂件不不能过大

如果线上压⼒很大，可利利用-c参数限制每一个抓包文件抓取的数据包数量。

2. 设置-s参数⼤小要合理

除⾮特殊情况需要，⼀般设置尽量小。越小，越不容易丢包。

• 分析 TCP/IP 底层协议，⼀般只需-s 60即可

• 分析应用协议短请求，⼀般设置-s 500即可

• 分析应⽤协议⼤请求或者大响应，需设置-s 1500或者更大

• 如果是为了TCPCopy 回放抓包文件，那就设置最⼤-s 65535或者-s 0。

3. 最好抓完整 TCP 交互的数据包

因为连接建⽴的时候会初始化参数，捕获连接建立过程可以更好地分析问题；如果是为了 TCPCopy 回放（只需访问服务器的流量），把port改成dst port以降低抓包文件大小。

4. 复杂问题可能需要在多个地方同时进行抓包

例如，同时在客户端和服务器抓包，确认是否被途中的防⽕墙⼲扰了。

如果需要进一步研究 tcpdump⾼级功能，请参考官⽅文档

3.2. wireshark 抓包

Wireshark 是当今主流的⽹络协议分析软件，不仅可以截获各种⽹络数据包，⽽且能够对数据包进⾏协议分析。

在 windows 环境下我们演示如何利用 wireshark⼯具抓包。

打开 wireshark，点击“捕获”菜单，如下图：

点击"选项"，会显示如下的对话框：

在这里选择需要抓包的接口，如选择"⽆线⽹络连接"；在接⼝的捕获过滤器（类似于 tcpdump 的过滤条件）中，选择tcp port http，即捕获 http 的数据包；点击开始，wireshark 就开始抓包了。

如上图，红⾊⽅框显示正在抓包，如果要停止抓包，点击红⾊方框就能停⽌抓包过程。

虽然原理差不多，个⼈推荐在 Linux 环境下利用 tcpdump 抓包，因为它更加⾼效。

4. Wireshark 抓包分析基础

在进行具体的抓包分析之前，先讲解常用的 wireshark 操作。

4.1. 保存成 pcap 格式

不管是 tcpdump 抓包还是 wireshark 抓包，保存⽂件的后缀名最好为pcap，这样就能被 wireshark⾃动识别为抓包⽂件。例如下图文件都是pcap结尾，⾃动就被 wireshark 识别为 pcap 抓包⽂件。

打开这些 pcap⽂件的时候就会以抓包数据文件的格式来解析，如果格式不符合 pcap 格式，那么打开的时候就会报错。

4.2. 分析 TCP 会话

打开 pcap⽂件后，最常⽤的操作是跟踪某一个 TCP 连接会话，查看 TCP 是如何交互的。在⼤量抓包数据中，不同 TCP 会话往往是不相⼲的，所以只分析有问题的 TCP 会话，对于找出问题的原因是非常有帮助的。

下图展示了如何利用 wireshark 命令跟踪某⼀个 TCP 会话。在某⼀行点击右键，弹出如下菜单栏，再点击追踪流，弹出子菜单，其中就有 TCP 流，点击就可以查看这⼀行对应的 TCP 流。

下图是跟踪第五个会话（从 0 开始算）的情况，可以看出整个 TCP 会话的过程，分别为：

• TCP 建⽴连接

• TCP 连接是通过三次握⼿建立的，也即图中三个数据包组成的，缺一不可。在三次握手过程中，会初始化相关参数，如图中的第一个数据包中的WS = 128，代表客户端的窗口扩大选项window scale为128，⽽第二个数据包中WS = 256，代表服务器端的窗⼝扩大选项window scale为256，这个参数对于判断对方接收窗口⼤小非常关键

• TCP 传输数据

• TCP 传输数据包括传输数据内容的数据包和 ack 确认数据包，⽽ack 确认数据包对于可靠传输⾄关重要

• TCP 连接关闭

• 连接关闭⼀般是四次挥手，图中把第二次和第三次合并了，所以只有三个数据包，这样做的目的是可以提升⽹络传输的效率

具体关闭连接参考深入浅出连接关闭，连接关闭的多样性远远不是四次挥手所能表达的。

4.3. 尽量分析完整的 TCP 会话

上图由于没有捕获到连接建⽴过程，导致没有捕获到初始窗口扩大选项window scale参数⼤小，而 Wireshark 给用户显示的时候，却显示没有错误提示的win=29。不熟悉抓包分析的⽤户，会误以为对方窗口⼤小是29，从而可能导致后续判断失误。

这时查看Window size scaling factor（参考上图最下面的箭头），如果是-1，说明上面的win=29是不靠谱的。

4.4. 利用时间差信息

利用时间差信息，可以充分挖掘很多隐含的信息。

从上图可以看出三次握手过程中，第一次握⼿数据包（第一个数据包）和第二次握手数据包（第二个数据包）相差 0.015473 秒，而第三次握手数据包（第三个数据包）和第二次握⼿数据包（第二个数据包）时间相差只有 54 微秒，时间间隔的倍数=0.015473/0.000054=286 倍左右。

假设是客户端抓包，收到第二次握⼿数据包后，TCP 会很快发送第三次握手数据包，这个时间差一般是非常短的，几十微秒，跟上面符合，因此可以判断出这是客户端抓包。

假设是服务器抓包，从收到第一次握⼿数据包，到发送第二次握⼿数据包，经过了 15 毫秒，这个时间差有点大，⽽发送完第二次握手数据包到接收到客户端的第三次握手数据包，却只花了54 微秒，因此这个假设是不符合经验常识的。

4.5. 常⽤wireshark 过滤条件

利用 wireshark，往往需要找出含有某些信息的数据包，这时过滤功能就显得尤为重要。例如查找是否含有某⼀个特定类型的 SQL 语句，这时该怎么做呢？

⾸先我们需要知道数据包内容是什么协议的数据包，下图是 MySQL 数据包，端⼝是 6001。由于 wireshark 事先不知道 6001 端口的数据包是什么协议的数据包，所以解析的时候是根据默认的 X11 协议去解析数据包，但这是不对的。因此，我们需要去设定数据包的协议。

根据下图提示打开“解码为”对话框

打开了“解码为”对话框，再根据下图提示操作：

点击 Save。设置完成后，6001 端⼝的数据包，将会采⽤MySQL 协议来解析。

下图显示了刚刚被 X11 协议错误解析的数据包在设置 MySQL 协议后，已经被正确解析为 MySQL 协议的数据包内容。

数据包被正确解析后，采⽤MySQL 的过滤条件来过滤 SQL 语句。如下图，采⽤“mysql.query contains

"select"”过滤出含有“select”的三个数据包。值得注意的是，这里的过滤条件只能应用于 MySQL 协议，不同的应用层协议需要使用不同的应⽤层过滤条件。

为分析应⽤层数据内容，tcpdump 抓包的时候，-s参数设置不能过⼩，否则，上述过滤条件就不会起作用，从⽽容易引起误判（例如以为没有此类 SQL 语句）。

利用 TCP 参数，还可以查询 TCP 层指定内容的数据包，⽐如tcp.flags.syn == 1，就能过滤出含有 syn 标志位的数据包，⽽这个 syn 标志位，代表着正在进行三次握手。

tcp.flags.fin == 1可以过滤出含有 fin = 1 标志位的数据包，而 fin 标志位，代表着正在进行连接关闭的操作。

我们还可以利用tcp.port作为过滤条件。例如，下图的tcp.port == 13354，可以过滤出端口 13354 的数据包。

我们不仅可以利用 TCP 信息来过滤数据包，还可以利用 IP 信息来过滤数据包。下图中，ip.host == 10.238.7.6 可以过滤出含有 IP 地址为 10.238.7.6 的数据包。

我们还可以直接选择某些内容作为过滤条件的⽅法，⽐如下图利用 IP 层的total length: 51作为过滤条件，wireshark⾃动转变成ip.len == 51来过滤出 IP 数据包⻓度为 51 的数据包。

4.6. 传说中的三板斧

三板斧的第一个是“时间序列列”查看。当我们想分析整个会话传输的过程时，可以利用“统计”菜单下的“TCP 流图形”的 “时间序列”来查看整个会话过程（参考下图）。

下图展示了TCP 流 239 的传输情况。图中的横坐标是时间，纵坐标为传输的数据量。数据传输集中在几个时间点。因此，在这几个时间点，数据传输量大，接近竖线；⽽其它时间点，数据传输空闲，所以是水平线。此分析图可以帮助我们分析 TCP 会话的整体传输过程。

三板斧另外⼀个值得关注的是分析栏目中的专家信息，具体操作如下图。

通过点击专家信息，可以统计出一些可疑的问题，如下图。

不过这些问题也不能全信，毕竟网络状况复杂。可能你们会感到疑惑：专家信息，为什么不能相信呢？

个⼈人总结原因如下：

• 协议没有更新，解析错误导致的误判

• 抓包过程中丢包导致的误判

• 未抓全整个 TCP 会话导致的误判

• 协议匹配错误导致的误判

• Wireshark 自身程序的误判

5. 抓包分析简单信息推理

5.1. 判断哪一端抓包案例

抓包⼀般可以在如下的地⽅抓包

• 客户端

• 服务器端

• 中途设备

如果是客户端抓包，那么客户端的 TCP 对服务器端的 ack 确认分为两种情况

• 快速 ack 确认，因为只需要经过本机器的 TCP/IP 协议栈，就可以返回，消耗的时间⼀般最多只有⼏十微秒

• TCP ack 延迟确认，这时延迟⼤概是 200 毫秒左右，适合于外⽹应用分析判断

以下图中的 TCP 会话为例。对于矩形框中的两个 TCP 数据包，第一个是服务器的响应数据包，第⼆个是对 response 的 ack 确认数据包。计算出这个时间差为 15 微秒(16.996501-16.996486=0.000015s），这么短的往返时间，只可能是从客户端抓的数据包：因为从网卡接收数据包到 TCP 回复 ack 数据包，再到网卡，一般也就⼏十微秒（除非延迟确认），⽽传递数据包给服务器端，往往至少是⼏百微秒，所以判断的时候更倾向于是从客户端抓的包。

下面是服务器抓包的案例，我们看看服务器端抓包的时间差有什么规律。

上图中 250.217 是服务器器，前⾯是三次握手过程。三次握手过程不涉及应用层，是在 TCP 层完成的，协议处理速度都很快（不会产⽣延迟确认）。当服务器端收到第一次握⼿数据包，仅仅过了了9 微秒，服务器就发送了第二次握⼿数据包（SYN+ACK 数据包）给客户端，而客户端的第三次握手数据包（ACK 数据包）过了 13440 微秒，也即 0.01344 秒才返回。

如果第二次握手与第⼀次握手时间间隔非常短（⼏微秒或几十微秒），可以判断为服务器端抓包。

下图给出在中途设备抓包的⼀个案例：

上图中，第一次握手和第二次握⼿相差 2 毫秒，⽽第⼆次握手和第三次握⼿相差 1 毫秒，不符合客户端或服务器端的时间差规律。因此，数据包可能在中途设备抓取，如路由器或交换机。

5.2. 判断哪一端发生了问题

上图展示了从客户端角度看，服务器端 web 80 端口发来了reset 数据包，客户端本身并没有任何 TCP 会话异常的问题，这样就排除了客户端的问题。因此，我们缩小了问题的范围。

5.3. 判断 TCP 哪个环节出的问题

上图展示了在数据传输过程中发⽣了数据包重传（客户端延迟确认导致服务器误判），这样问题的范围限制在了数据传输⽅面。

6. 抓包分析之 TCP 分析

TCP 分析主要包括如下⽅面：

• TCP 流量控制分析

• TCP 拥塞控制分析

• TCP 性能分析

• TCP 灵异事件分析

这里简要讲述这⽅面的内容，后续专题会讲更加详细的内容。

6.1. TCP 流量控制分析

上图内⽹环境下，客户端访问 MySQL 服务器，请求返回大结果集响应，导致客户端 TCP 来不及接收数据，于是通知服务器端接收窗⼝win=0。当客户端应用接收了数据以后，再次通知服务器端，客户端 TCP 接收窗⼝已经有 1078400 字节的空间，服务器 TCP 于是可以继续发送后续数据。

6.2. TCP 拥塞控制分析

⽹络传输不仅有窗口限制，而且还有网络拥塞算法的限制。

下图展示了拥塞控制算法是如何发挥作用的。

图中序号 264 发送请求到服务器器MySQL 之前，客户端窗口⼤小为 29312 字节，后续 MySQL 发送了若⼲响应数据包，中间还夹杂着客户端的 TCP ack 确认，即使是左边的矩形框中的数据包内容加起来也不足 20k，还没有到 29312 字节，win 窗⼝⼤小已经变为 62080 字节⼤小，不但没有缩小，反而增大了。为什么服务器端 TCP 没有按照窗⼝⼤小传输数据呢？这是因为⽹络拥塞控制算法在发挥作用，限制了传输速度。

当然如果 MySQL 上⾯的 TCP（注意是在内⽹环境），刚开始发送数据激进一点，可以提升 MySQL 的传输数据的速度。

6.3. TCP 性能分析

上图展示了 TCP 传输过程中的性能问题。数据传输主要发生在三个阶段，最初接收窗口较小（见下图）导致窗口满，线条相对比较曲折（见上图），而后 TCP 动态增加了接收窗口⼤小（⻅下图），从此 TCP 接收数据就没有再报窗口满，从上图也可以看出后续线条也⽐较直。

6.5. TCP 灵异问题分析

之前根据时间差信息判断出了抓包是在中途设备进⾏的，⽽且中途设备在收到服务器端请求响应的最后一个数据包（时间为 19：58：42.559118）后， 短时间（20 微秒）就发送了Reset 数据包给服务器端，从而关闭了服务器端的 TCP 连接，⽽客户端连接却还活着。由于客户端不知道服务器端连接已经被关闭，还继续发送 ack 确认数据包给服务器，最终造成了⽤户的困扰。

7. 建⽴TCP 反馈跟应⽤程序的关联

下面通过两个案例讲述 TCP 反馈跟应⽤程序的关联

7.1. 服务不可用与 reset 数据包的关系

下图给出⼀个实际的案例

从⽤户的描述来看，用户怀疑到了防火墙或者云主机上边的安全策略导致了问题。⽤户之所以这样怀疑的原因可能如下

⽤户带给我们如下困惑

解决用户问题，应该采用不能全信的态度，如果描述都准确，大部分场合都会朝着正确的⽅向走，但如果描述不准确或者某一个理解不对，就会往错误的⽅向⾛，这样离解决问题的距离越来越远。

客户端 TCP 接收到 Reset 数据包，会给上层应⽤报 Connection refused，而telnet ip port报Connection refused，意味着远程 ip 地址的端⼝服务不存在，可以去服务器上面利用netstat –nlp查看 IP 地址的端⼝应用是否存在，需要注意的是不能只看端口，还需要看 IP 地址是否匹配。最终发现⽤户只开启了localhost 的监听，意味着只有本地才能访问服务，远程⽆法访问。

我们模拟这样的场景

上述只监听 127.0.0.1 的地址，利用netstat –nlp查看如下

我们开启抓包

远程访问此服务（远程不能利用 127.0.0.1 地址访问，因为这是本地回路地址）

完美复现了用户的问题。

在建⽴连接的时候，建⽴TCP reset 跟应⽤服务不可⽤的关系，对问题解决是非常重要的。

7.2. 连接不关闭与 close_wait 的关系

当连接一直不关闭，TCP 层会提示什么信息给我们呢？

我们可以演示这一场景

利用 MySQL 终端登入 MySQL 服务器，然后⼀直不操作，然后在 MySQL 端将interactive_timeout设置为 30 秒。由于 MySQL 客户端一直不操作，MySQL 就会关闭这个连接，抓包显示如下

客户端 TCP 层对 MySQL 的关闭数据包进⾏了确认，但 TCP 没有去关闭连接，这是因为关闭连接的操作是应用层去做的，这个时候需要等应⽤层的 MySQL 客户端主动去关闭连接。由于一直不操作，在客户端利用netstat命令查看（如下图），这个连接的 TCP 状态变为 CLOSE_WAIT 了。

这意味着客户端没有关闭连接，导致客户端的 TCP 状态为 CLOSE_WAIT 状态。如果很多客户端都没有关闭连接，就会积累很多的 CLOSE_WAIT 状态，从⽽可能会导致系统服务不可用。

CLOSE_WAIT 状态还会引发一系列列诡异的问题，后续专题会详细介绍这⽅面的内容。

8. 分析应用层协议数据

应⽤层数据分析，需要 wireshark 具有解析相应协议的能力，⽽大部分常⽤协议，wireshark 都具备，⽐如我们常用的 HTTP 协议，MySQL 协议等。

下图展示了wireshark 是如何解析 HTTP 协议的，这对于查明 HTTP 协议的问题是很有帮助的，否则如果不能解析，只能查看⼆进制数据去查明问题。

下图展示了 wireshark 解析 MySQL 的场景，MySQL 返回错误（1062）。通过下面信息，wireshark 解析

出了问题的具体原因（重复插⼊）。

我们利用 wireshark，不仅可以去解析了解应用层协议的内容，⽽且还能去分析应用层的诡异问题。

举下⾯一个例子

用户通过 MySQL 客户端去执⾏⼀个带有注释的 SQL（⻅下图），注释的内容要求通过数据库中间件去访问 master 库，意味着这个命令要去 MySQL 主库执⾏，结果用户发现这条 SQL 去了MySQL 从库执⾏了，跟用户的意图不匹配。

用户想不明白问题的原因。由于不懂数据库中间件的代码，也不懂得抓包分析，解决这个问题变得非常困难。

其实只要会抓包分析，用户就会很容易解开这个谜团。

我们复现这一场景，并进行抓包分析

从上图可以看出，发出的 SQL 根本就没有带有注释/*master*/，而这条 SQL 是只读请求，根据读写分离原则，读请求是应该去 MySQL 从库执行，数据库中间件也没有做错，但⽤户感觉是数据库中间件没有按照他的意思去做，所以这里用户怪错了对象。

分析了抓包文件，指向了问题MySQL客户端发送请求为什么没有带上注释呢？，而不是之前用户的问题为什么数据库中间件没有按照我的意思去做？

为什么 MySQL 没有带上注释，网上一搜索，很快就能得到问题的解，这是因为 MySQL 要想带上注释，必须加上-c，help 解释如下：

再举⼀个分析应用层协议的例子：

这个案例是为了研究竞争对手商业产品 OneProxy 的⼯作原理。既然是商业产品，那就拿不到源代码，因此抓包分析就是⼀种⾮常好的分析方法。

我们分析的目的是想查看对于客户端的 SQL 请求，这个商业产品是如何分发给后端多个数据库的。

客户端发送的 SQL 如下：

根据下图的信息，来分析⼀下是如何发送给后端数据库的？

可以看到在 14：00：12.277142 时间，商业软件 OneProxy 接收到了⽤用户的 SQL，在 14：00：12.277280 这个时间 Oneproxy 发送请求给第一个后端数据库；过了 2s 左右，OneProxy 发送给第二个后端数据库；⼜过了3s 左右，发送给第三个后端数据库；最后又过了 2s 左右发送给了第四个后端数据库。从 OneProxy 接收到⽤户 SQL 请求到把请求都发送出去，过了将近 7s，可见这种串⾏⼯作⽅式效率是比较低下的。

OneProxy 对免费用户提供了这样一个服务，当然如果想提升性能，需要去购买商业版本，这种做法其实是一种商业策略。

通过抓包分析，我们了解了商业产品 OneProxy 在免费用户模式下的工作原理，可⻅抓包分析对于分析一个服务器软件的运行机制是⾮常有帮助的。

9. 总结

本节简单讲述了如何抓包分析，掌握了本节的内容可以解决一般 TCP 相关的问题，但对于解决⾼难度问题还是不够的，下一节将讲述数据包是如何穿越各层协议的，这对于提升解决 TCP 相关问题的能力是非常重要的。