前言：这个系列（以及我的博客）好久不更新了，原因有两个，一个是我在学习用双拼打字，手跟不上脑子，写的东西读起来不顺畅，不过现在已经复健了。双拼确实能极大地减少按键次数，在 AI 的时代，每个人需要和 AI 对话，那么怎么赶上时代的潮流，从芸芸众人脱颖而出呢？我的建议是：练习打字，打字打得快，和 AI 沟通效率高，做 AI 时代的佼佼者；第二个原因是我最近在思考人生的意义。上次录制博客 laike9m 提到了存在主义危机，第一次知道这个词，我觉得我就是陷入了存在主义危机。苦苦思索人生的意义，没有思考出什么结果。看了一些书，看的是莫言，刘震云，看了一本漫画，《我以为这辈子完蛋了- [美]艾莉·布罗什》，让我思考了很多。但是依然没有结论。人生没有思考明白，问题先来了。
有一天，我们在上线新的设备，上线之后，用户反馈他们的服务出现了网络超时的错误。超时的概率大概在 0.01%，并且出现的时间和我们上线新的设备的时间完全一致。我们把新上线的设备隔离（不再处理线上流量）用户的服务没有再出现错误了。
我们对新设备的性能非常有信心，不应该比原来的设备转发速度还低。这中间一定是有什么问题。
拓扑图简化如下：
其中，用户的 Client 和 Server 侧之间的网络是无法连通的，我们的网络设备会把用户的 Ethernet 包封装到 UDP 里面发送（overlay，原理就和 VPN 一样），这个设备提供了封装，转发的服务。但是用户的 Client 和 Server 感受不到中间这个 tunnel 的存在，Client 和 Server 之间的 IP 地址是可以直接 ping 通的，TCP 也是可以连通的，全靠我们的设备在中间做了转发。
我们做了一些常规检查没有发现问题，然后重新上线新的设备，要求用户在 Server 端进行抓包。得到文件如下。在一般的问题分析中，我们一般只看 packet 的 header 就够了，不需要看 application 层的 TCP payload，所以在抓包的时候我们会截断 TCP 的 payload，这样，在下载抓包文件和交流的时候，更方便一些，并不影响问题的分析。
请据此分析，造成小概率超时的问题在哪里。
如果没有头绪，请看下面的提示。
在找不到问题的时候，我们会对比正常情况下的表现，通过正常和异常的情况的不同来寻找线索。以下是原有环境的抓包文件，没有超时的请求。
对比两个抓包问题，请分析问题的根因。
==抓包破案录==
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器？（答案和解析）
- 网工闯了什么祸？（答案和解析，阅读加餐！）
- 重新认识 TCP 的握手和挥手（答案和解析）
- 3.5 秒初始延迟问题 （答案和解析）
- 网络断断续续…… （答案和解析）
- 延迟增加了多少？（答案和解析）
- 压测的时候 QPS 为什么上不去？（答案和解析）
- TCP 下载速度为什么这么慢？（答案和解析）
- 请求为什么超时了？（答案和解析）
- 0.01% 的概率超时问题 （答案和解析）
- 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。