这是 网络断断续续 一文的答案。

答案是，在同一个子网内，同一个 IP 地址分配到了 2 个不同的设备上。

对于这种时而正常时而异常的「幽灵问题」，在没有思路的时候，可以通过对比的方法来寻找线索。

有的时候 TCP 能够连通，有的时候无法连通。那么正常的 TCP SYN 包和异常的 TCP 包之间肯定是有什么字段是不一样的。当然，也有可能 SYN 包一模一样，问题出在了其他的网络设备上或者 TCP 的另一端。但是既然题目出给读者了，那么问题的根源肯定是隐藏在抓包文件里面。

通过对比来寻找答案

正常的 TCP 连接可以完成 TCP 的握手和挥手。

异常的 TCP 连接，发出去的 SYN 直接收到了 RST。

通过对比可以发现，两个 SYN 包的 Dst MAC 是不一样的。

通过推理得出答案

如果不通过对比的方法，顺藤摸瓜，可以用下面的思路。

首先，Src IP 和 Dst IP 分别是 10.210.151.187 和 10.210.151.90，很大概率是属于同一个 /24 子网的 IP，不过要想确认的话需要看下服务器的 IP 地址是如何配置的，子网掩码是不是 /24，这点我们从给出的信息无从得知。

假设确实是属于同一个子网，那么 TCP SYN 包不经过网关，直接发给目的地址，二层的 Dst MAC 地址应该是目的 IP 的 MAC 地址。

假设不属于同一个子网，那么 TCP SYN 包经过网关，TCP SYN 包的目的地址应该是路由器的 MAC 地址。

无论是那种情况，正常情况下发送给同一个 Dst IP 的目的 MAC 应该是唯一且稳定的。通过 Conversation 统计可以看出，通讯的 IP 对只有一对，但是 MAC 的确有 2 对，这是不对的。

原因分析

造成这种现象的原因是，IP 分配重复了，在同一个子网内，同一个 IP 地址 10.210.151.90 被分配给了多个机器。

发送 TCP 包之前，需要知道对应的 Dst IP 地址的 Dst MAC 地址，怎么知道呢？Src 机器会在整个子网内广播 ARP 询问，持有这个 IP 的机器会回复 ARP。现在子网内有两个相同的机器是相同的 IP 地址。这两台机器的 IP 地址一样，MAC 地址不一样。如果我们现在 arping 10.210.151.90 ，会得到如下的回复：

$ arping -c 3 10.210.151.90
ARPING 10.210.151.90
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=0 time=944.055 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=1 time=997.915 usec
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=2 time=13.799 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=3 time=109.388 usec
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=4 time=6.670 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=5 time=48.983 usec

--- 10.210.151.90 statistics ---
3 packets transmitted, 6 packets received,   0% unanswered (3 extra)
rtt min/avg/max/std-dev = 0.007/0.353/0.998/0.438 ms

可以看到，我们发出去 3 个询问，却收到 6 个回复。说明每一个询问得到了 2 个答案。（其实，在诊断和验证这个问题的过程中，最快的方式就是用 arping 来测试一下，而不是抓包来分析。但是这里我们主要讨论抓包技术，所以拿来当作一个分析的案例。）

那么 Src 收到两个 ARP 应答，会以哪一个为准呢？答案是以先收到的为准。

$ ip nei show
10.210.151.90 dev h2-eth0 lladdr 5a:65:98:0c:82:02 REACHABLE

但是 ARP 请求广播出去，这两个 ARP 应答哪一个先到是无法确定的，有的时候 5a:65:98:0c:82:02 先到，有的时候 c2:10:70:f2:ae:ab 先到，所以发送给 10.210.151.90 的包，有的时候发给了 MAC 地址为 5a:65:98:0c:82:02 的机器，有的时候发送给了 MAC 地址为 c2:10:70:f2:ae:ab 的机器。

补充一点，在实际的问题排查过程中，我们的 TCP 连接测试失败，最好的排查方法就是去对端进行抓包，看一下对端的机器是否收到了 SYN 包。以及在实际的现象中，客户端收到了 Connection refused ，通常意味着收到了 RST 报文（可能来自真实对端，也可能来自其他设备）。我们在对端抓包的过程中会发现即没有收到 SYN，也没有发出 RST，这说明包到别的地方去了。进而，我们可以发现字网内还有一个「李鬼」的问题。

那么，为什么 ping 的测试完全正常呢？

因为 ICMP 是无连接协议，，ping 的 ICMP 协议回复，是由 Kernel 负责的，所以无论 ICMP 包发送到哪一个机器上，由于它们都设置了这个 IP 地址，所以都可以做出回复。其实抓包中的回复是来自不同的机器，只不过 ping 不知道，只要是收到了回复，就认为一切正常。

最后一个问题，为什么会有 IP 重复的问题呢？

DHCP 可以用来动态分配 IP 地址给设备，但是一般只用于客户端，比如办公网、家用网络中的终端设备，这些设备一般作为连接的发起方，不需要 listen 一个固定的 IP 地址，IP 地址的动态变化对它们影响不大。但是在 IDC 的网络中，每一个服务器的软件都需要固定的 IP 地址，一般不用 DHCP 来动态分配，而是用中心化的 IPAM 系统¹追踪 IP 地址的分配情况。如果里面记录的地址不正确，比如，一个地址已经在使用中了，但是并没有在 IPAM 记录，就造成 IP 地址重复的问题。

1. https://en.wikipedia.org/wiki/IP_address_management ︎

==抓包破案录==

这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。

如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！

如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。

没有链接的目录还没有写完，敬请期待……

1. 序章
2. 抓包技术以及技巧
3. 理解网络的分层模型
4. 数据是如何路由的
5. 网络问题排查的思路和技巧
6. 不可以用路由器？（答案和解析）
7. 网工闯了什么祸？（答案和解析，阅读加餐！）
8. 重新认识 TCP 的握手和挥手（答案和解析）
9. 3.5 秒初始延迟问题 （答案和解析）
10. 网络断断续续…… （答案和解析）
11. 延迟增加了多少？（答案和解析）
12. 压测的时候 QPS 为什么上不去？（答案和解析）
13. TCP 下载速度为什么这么慢？（答案和解析）
14. 请求为什么超时了？（答案和解析）
15. 0.01% 的概率超时问题 （答案和解析）
16. 后记：学习网络的一点经验分享

与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。

在和朋友一起吃饭的时候，A 提了一个有意思的问题：怎样可以把一个机房内的路由设备从互联网「隐藏」呢？

「隐藏就是没有人可以知道这个设备的 IP 地址，这还不简单，只要禁用 ICMP 就可以了」， B说。

A 说，这样是可以。很多安全团队在实施起来也确实是这么做的，但是这样并不好：机房内所有的 IP 都无法 ping 通了。这样会增加 debug 的难度，得不偿失呀！

C 说，那就依然转发 ICMP 包，但是如果是 TTL=1 的包，就不要回复 ICMP Time Exceeded 了。

B 说，人家要的是「隐藏」，要是像你说的这么做，别人还是知道中间有一个设备的存在，没有完全符合要求。

事实是这样的。假设一个简单的物理拓扑是 A -> B -> C，B 不回复 ICMP Time Exceeded，那么 traceroute 看起来就是 A ? C，可以猜测得到中间有一个路由器，但是已经禁止回复 ICMP Time Exceeded。看起来像下面这样。

C 说，traceroute 的原理是发送 TTL=1, 2, 3, … 的包，不断让路由器回复 ICMP Time Exceeded 信息，来得到每一跳的 IP 地址。要想完全隐藏，只需要：

• 自己不回复 ICMP Time Exceeded；
• 让下一跳回复，仿佛下一跳就在自己的位置；

这样就可以完全隐藏了。要达到这个目的，只需要：

• 对于 TTL=1 的包，不是丢弃，而是转发给下一跳，并且 TTL 依然保持为 1，即可。A ---[TTL=1]---> B ---[TTL=1]---> C， 对于客户端的 traceroute，看起来就像：A → C。

这样（理论上）好像确实可行了。三人对这个结论满意了。

后来我把这个讨论记录在了博客上（你现在正在阅读的一个），一位读者马上就发现了问题：可是这样 C 会出现两次吧！

确实是这样，假设在 A -> B -> C 的链路中：

• TTL = 1 从 A 进入的时候，A 会在 ICMP 中回复自己的 IP；
• TTL = 2 从 A 进入的时候，B 会直接转发给 C，C 会在 ICMP 中回复自己的 IP；
• TTL = 3 从 A 进入的时候，B 会 TTL -1 转发给 C，C 会在 ICMP 中回复自己的 IP；

这样 C 就出现了 2 次！

看来，B 必须完全不减 TTL，直接转发，才能隐藏自己。不过这样就有出现环路²的风险了。

1. 使用 mtr 检查网络问题，以及注意事项 ︎
2. 网络中的环路和防环技术 ︎

虽然这个系列的文章都是聚焦于如何通过分析网络抓包文件，结合网络知识，来解决实际的问题的，但是分析之前的步骤——抓包，也是同样重要！很显然，如果不会抓包，那么网络分析去分析什么呢？

抓得一手好包也是很厉害的！笔者遇到过很多次情况，虽然我们无法直接定位根因，但是同事能够精准地捕获到问题的现象，把问题描述给相关的网络专家，传给他们抓包文件，专家一看到准确的抓包文件，就可以很快解决问题了！

可惜的是，抓包的技巧无法像网络分析那样可以通过文章来出谜题，来让读者小试牛刀。所以，这篇文章就来写一下一些常用的抓包方式和技巧，希望能补齐这一块内容。

Tcpdump

tcpdump 命令是我们最常用的抓包工具了¹。

tcpdump -i eth0 icmp and host 1.1.1.1

这个命令就可以抓取到所有通过 eth0 去 ping 1.1.1.1 这个地址的包。

-i eth0 的意思是抓取指定的 interface，如果不指定，tcpdump 会默认选择一个。但是推荐每次都指定好这个参数，这样就没有不确定性了。如果使用 -i any 就可以抓取所有常规端口（文档的原文是 all regular network interfaces），但是什么属于「常规端口」就取决于操作系统的实现了。所以，建议也是如果要抓取多个 interface 来分析的话，就多开几个 tcpdump 进程，这样更加稳定一些。

这个参数非常有用，比如，在定位 ARP 问题的时候，我们需要确定每一个物理接口收发 ARP 的情况，就可以开多个进程分别 dump 每一个 interface 的网络；在定位 Linux 网络栈不通的情况时²，比如有 macvlan，vlan，veth 等复杂的 driver，可以用 tcpdump 对每一个接口 dump，看下包丢在哪里。

icmp and host 1.1.1.1 这个就是包过滤的表达式了，icmp 表示只抓取 icmp 协议，host 1.1.1.1 表示只抓取 src ip 或者 dst ip 是 1.1.1.1 的包。这种包过滤表达式其实是 pcap-filter(7)³ 提供的，所以要想看语法是怎么定义的，看 pcap-filter 的文档就可以了。pcap-filter 支持的语法很灵活，能做的事情很多，基本上想抓什么样的包都可以写出来。但是我们没有必要把所有的语法都记住，因为常用的抓包都是比较简单的。可以找一个 tcpdump exmaple⁴ 看一下，基本就够用了。其次，我们一般不会直接从 tcpdump 就分析出来问题原因，所以这个语法最重要的作用是把我们想要的包抓到，然后为了抓包性能更高，抓包文件更小，我们想要对抓包定义的更精确一些。其实，多抓一些包也没有什么问题，如果不确定怎么过滤出来 TCP SYN+ACK 的包，那不妨就把所有的 SYN 包全抓到，然后再用 Wireshark 这种工具来分析吧。最后，我们现在有 AI 了，用 AI 来写 pcap-filter 也是一个不错的方法，因为这种语法难写，但是很容易验证正确性。

Tcpdump 一些常用的其他参数如下：

• -n 不解析主机名和端口号，保留原始的数字
• -v, -vv, -vvv v 越多表示输出的信息越详细
• -c 5 表示抓到 5 个包之后就退出
• -e 显示二层的 link layer header，这样就可以看到 MAC 地址了
• -Q 可以指定抓包方向，可以选的有 in, out, inout
• -A 可以展示包的内容，tcpdump 默认是只根据不同的协议展示 header 信息的。在线上排查问题的时候，我们往往需要通过特殊请求的关键字来定位到单个请求的情况进行排查，这样 -A 展示出来包的内容就格外有用。

这里分享一个特殊的技巧，就是发标记请求来定位问题。比如 A 通过 B 代理发请求给 C，现在网络不通，我们要定位 B 收到了请求没有，才知道是 B 的问题还是 C 的问题。但是 B 本身就有很多线上流量，怎么知道 A 发送的请求到达 B 了没有呢？我们可以在 B 进行 tcpdump：tcpdump -i eth0 tcp | grep asdf123 -A 10，然后我们从 A 发送一个请求：curl http://host-C.com/asdf123。asdf123 就是我们在请求里面放上的标记，如果 B 能够正常转发，我们就可以 match 到这个请求。当然了，这种技巧只适用于 HTTP 这种明文协议。

Wireshark 离线分析

有些问题很难直接在 tcpdump 的终端分析出来问题，比如涉及 sequence number 分析的，重传分析之类的，我们需要人工对比 seq number，真是一项费眼睛的工作！所以如上所说，我们也经常在机器上用 tcpudmp 抓包保存成 .pcap 文件，下载到本地用 Wireshark 分析。Wireshark 就可以自动根据 sequence number 告诉我们重传等信息了！

具体的操作方式是，用 tcpdump -i eth0 -w file.pcap icmp 来进行抓包，-w file.pcap 表示把抓包文件保存为 file.pcap，抓包结束后，就可以把这个文件用 rsync 或者 scp 下载到本地，用 Wireshark 打开了。

.pcap 文件是一种标准的二进制抓包文件⁵，很多抓包分析工具都支持这种格式的解析，比如 tcpdump, wireshark, scapy 等等，如果想写代码进行更加定制化的分析，也可以用已有的库⁶解析，就如同用 json 库来解析 json 文件一样。

使用 -w 写入文件的时候有一个小问题，就是 tcpdump 原本的到终端的输出没有了。有两种方式可以解决，第一种是用 tcpdump 自带的 --print 功能：

tcpdump -i eth0 -w file.pcap --print

--print 会让 tcpdump 把内容输出到屏幕，即使当前使用了 -w 参数。

第二种就是用 tee，在写入文件的同时，也写入到 stdout。

tcpdump -i eth0 -U -w - | tee test.pcap | tcpdump -r -

其中，第一个 tcpdump 把抓包文件写入到 stdout（-w stdout，注意其中的 -U 表示按照 packet buffer，即来一个 packet 就输出一个到 stdout，而不是等 buffer 满了才进行输出），然后 tee 这里做了分流，把 stdin（tcpdump 的 stdout）同时输出到文件和 stdout。由于这里的 stdout 是 tcdpump 输出的二进制抓包内容，所以我们需要再用 tcpdump 解析这个二进制内容，-r - 表示从 stdin 读入。

还有一个技巧是 -s 参数，默认情况下 tcpdump 会保存所有抓到的内容，但是在分析某些问题的时候，尤其是 TCP 性能问题，我们其实不需要 TCP 传输的 payload 内容，只看 TCP 包的 header（序列号部分）就知道传输的速度了，所以可以用 -s 40 来只抓取前 40 个 bytes，有了 IP header 和 TCP header，就足够分析了。（如果担心有 TCP option 的存在，可以用 -s 54）

其他的一些经验

知道包是从哪里抓到的，很重要。在排查问题的时候，拿到抓包文件，应该第一时间确认抓包的位置。否则，就可能连自己看到的问题是现象还是根因都分不清楚。建议在复杂的结构中画一个拓扑图来对照分析，在定位 Linux 网络栈的问题时，如果接口拓扑非常复杂，也建议画一个拓扑图来分析。

可以从网络的多端抓包对照分析。发送端的抓包不一定等于接受端，尤其分析 TCP 问题的时候。可以同时在发送端和接收端进行抓包，然后对照分析。

在使用 tcpdump 的时候，要尤其注意，我们抓到的包已经经过了网卡驱动的处理，网卡驱动经常会帮 CPU 做一些 offload 的工作，比如把可能因网卡的 GRO/LRO 等特性，导致多个小包在抓包时被合并为一个较大的数据包，或者网卡帮助卸载了 vlan tag 等，我们用 tcpdump 抓到的包不一定是真正在网络上传输的包⁷。要格外注意。

注意抓包不要抓重。比如有人很喜欢用 tcpdump -i any ... 抓全部的包回来慢慢分析。然后下载下来抓包文件就吓坏了——重传率高达 50%！

在 Linux 中的网卡配置有 slave 和 master 的时候很容易发生这种情况，比如有 bonding 配置⁸，-i any 会从 slave 抓包包，从 master 又抓到一次，然后在 Wireshark 看来，所有的包都被重传了。实际是同一个包先后经过 slave 和 master 而已。

抓包的时候最好把相关 host 的 ICMP 协议包也一起抓了。因为 ICMP 是重要的 control message，TCP 在传输的时候，不光有 TCP 协议，可能还会用 ICMP 协议来传递一些信息。比如 PMTUD⁹，以及之前遇到过的这个问题¹⁰，都是涉及到 ICMP 包。如果只按照 TCP 协议来抓包，那这个重要的信息就错过了。

SPAN 交换机抓包和RSPAN 远程抓包

除了我们熟悉的 Linux 抓包，其实网络设备上也可以抓包的。我们一般叫它「端口镜像」技术，故名思义，原理就是把网络设备的一个端口的流量全部复制到另一个端口，而另一个端口连接的就是我们的抓包程序。

1. 文档的主页：https://www.tcpdump.org/manpages/tcpdump.1.html ︎
2. Keepalived 脑裂问题排查 ︎
3. pcap-filter 文档在这里：https://www.tcpdump.org/manpages/pcap-filter.7.html ︎
4. 比如这一个：https://danielmiessler.com/blog/tcpdump ︎
5. IETF 的文件规范定义：https://www.ietf.org/archive/id/draft-gharris-opsawg-pcap-01.html ︎
6. Python 可以使用 scapy (https://scapy.readthedocs.io/en/latest/usage.html#reading-pcap-files)读取 pcap 文件，golang 可以使用这个库进行解析：https://pkg.go.dev/github.com/google/gopacket/pcap ︎
7. 参考 有关 MTU 和 MSS 的一切 一文中，「道理我都懂，但是我的抓的包怎么大？？」 ︎
8. 数据中心网络高可用技术之从服务器到交换机：active-backup ︎
9. 真实世界中的 PMTUD ︎
10. 由 ICMP Redirect 消息引起的丢包问题排查 ︎

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。

如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！

没有链接的目录还没有写完，敬请期待……

1. 序章
2. 抓包技术以及技巧
3. 理解网络的分层模型
4. 数据是如何路由的
5. 网络问题排查的思路和技巧
6. 不可以用路由器？
7. 网工闯了什么祸？
8. 网络中的环路和防环技术
9. 延迟增加了多少？
10. TCP 延迟分析
11. 压测的时候 QPS 为什么上不去？
12. 压测的时候 QPS 为什么上不去？答案和解析
13. 重新认识 TCP 的握手和挥手
14. 重新认识 TCP 的握手和挥手：答案和解析
15. TCP 下载速度为什么这么慢？
16. TCP 长肥管道性能分析
17. 请求为什么超时了？
18. 请求为什么超时了？答案和解析
19. 后记：学习网络的一点经验分享

与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。