一天工作日，你拿着刚买的咖啡来到了办公室，准备开始做计划好的工作，度过本该是平平无奇的一天，直到——一位用户发过来消息说他们有新的机器上线之后，所有的 TCP 连接都自带3.5s左右的延迟！他们的服务在使用新的服务器之后，延迟都上升了 3.5s！
经过他们自己的 debug，他们发现，延迟增加之后，在 TCP 连接建立之后，有3.5s 的时间没有发送数据，之后，网络就正常了！然后我们知道，不光服务器是新的，机架，网络设备，都是新的。这批服务器本不该你来负责，但是这个现象也太怪了！所有人都知道你是公司里的网络专家，如果有有解决不了的网络问题，就会来找你。
你让用户用 iperf 测试一下带宽1，用户测试了一下，结果如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ iperf3 -c 10.0.2.2 -b 10M Connecting to host 10.0.2.2, port 5201 [ 5] local 10.0.1.2 port 45026 connected to 10.0.2.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 3.00-4.00 sec 384 KBytes 3.15 Mbits/sec 24 22.4 KBytes [ 5] 4.00-5.00 sec 5.12 MBytes 43.0 Mbits/sec 0 221 KBytes [ 5] 5.00-6.00 sec 1.75 MBytes 14.7 Mbits/sec 0 328 KBytes [ 5] 6.00-7.00 sec 1.12 MBytes 9.44 Mbits/sec 0 328 KBytes [ 5] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0 328 KBytes [ 5] 8.00-9.00 sec 1.12 MBytes 9.44 Mbits/sec 0 328 KBytes [ 5] 9.00-10.00 sec 1.25 MBytes 10.5 Mbits/sec 0 328 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 27 sender [ 5] 0.00-10.02 sec 12.0 MBytes 10.0 Mbits/sec receiver iperf Done. |
还真是和用户说的一样！
这必须要抓包一下才知道原因了！用户又做了一次 iperf，并且同时执行 tcpdump 进行抓包，过一会儿，就发来了抓包文件。
你看了一会，然后马上就发现了不对劲的地方……
请分析这个抓包文件，找出固定3.5s延迟的问题在哪里。
==抓包破案录==
通过真实故障和抓包文件，学习网络分析与故障排查。
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器？（答案和解析）
- 网工闯了什么祸？（答案和解析，阅读加餐！）
- BPG 连接建立失败问题 （答案和解析）
- 重新认识 TCP 的握手和挥手（答案和解析）
- 3.5 秒初始延迟问题 （答案和解析）
- 网络断断续续…… （答案和解析）
- 延迟增加了多少？（答案和解析）
- 压测的时候 QPS 为什么上不去？（答案和解析）
- TCP 下载速度为什么这么慢？（答案和解析）
- 请求为什么超时了？（答案和解析）
- 0.01% 的概率超时问题 （答案和解析）
- 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
直接丢给gemini，你的提问。作为提示词：
延迟原因定位
这种“阶梯式”的延迟（1s + 2s + …）是典型的 TCP 指数退避 (Exponential Backoff) 机制。
根本原因：
网络丢包：中间网络设备或防火墙丢弃了前几次 SYN 包。
服务端监听队列溢出：服务端的 backlog 队列已满，导致它忽略了新的 SYN 请求。
防火墙/安全策略：某些安全设备可能对高频连接有拦截，或者在特定的“静默期”后才放行流量。
建议解决方案
检查服务端资源：查看服务端（10.x.x.x）的 CPU 负载和网络连接数，确认是否存在 SYN Flood 防护被触发的情况。
检查防火墙日志：排查中间路径上的防火墙或负载均衡器，看是否有针对该端口的丢弃记录。
内核参数优化：如果是 Linux 服务器，可以尝试调小 tcp_syn_retries 或检查 net.core.somaxconn 队列深度。
这个 3.5 秒的延迟并非应用层的处理缓慢，而是典型的网络层/传输层建连重试导致的启动延迟。
mss or mtu吗？
是的
诶，为什么第五个包变小了？我当年MTU设错的时候，TLS连接就卡在那儿完全动不了哇。
如果 MTU 设置错误，而且收不到 ICMP 提示 segment 太大的话 （现实情况一般是收不到的）就会出现 blackhole，默认情况是会一直卡住的。
但是可以通过 sysctl 设置 net.ipv4.tcp_mtu_probing，默认是 0，如果是 1 的话，在出现 blackhole 的时候就会尝试降低 segment 的大小看能不能通。
居然还有这种选项，学习了～
mtu clamping造成的延时吗
不是，不过是和 mtu 有关。