请求为什么超时了？答案和解析

首先，通过这个抓包文件前几个包可以发现，服务器的网络是没有问题的，因为访问 DNS 或者 ubuntu apt 源都是通的。

这个问题有两个要点。第一点是，抓包文件并不是仅仅包含出问题的请求本身，还包含很多与问题无关的流量。不过现实的情况也往往如此，我们要在很多抓包和分析的时候过滤掉和问题无关的流量。

有一个非常好用的过滤方法，就是直接用 TCP 的 payload 内容进行过滤。比如，我们已经知道请求的目标是 example.com 了，那么 Host: example.com 必然会存在于 TCP 的 body 中，所以可以用以下的过滤条件：

tcp.payload contains "example.com"

（在之前的写的 网络抓包的技巧 中也介绍过，我们可以发送带有标记的请求，tcp.payload contains "xxx" 也是过滤出来这种标记请求的好方法）

用这个过滤条件可以得到以下的几个包，这就是我们要分析的请求了。

可以看到，我们发送给 exmaple.com 80 端口的包从来就没有得到过确认，于是一直在增大请求间隔并不断重试。

另一个奇怪的地方是，这个 TCP 请求没有 SYN 包被过滤出来，直接就开始发送 payload 了。这说明这个连接是在我们抓包之前就已经建立好的，所以我们没有看到连接建立的过程。

我们这个抓包文件的第一个包的时间是 37分52秒，而 HTTP 请求的第一个包时间是 39分28秒，间隔了 156 秒。这意味着这个 TCP 连接是至少在 156秒之前建立的，并且在建立之后，至少在 156秒 的时间内，没有发送过任何内容。

那么这个连接很可能因为 inactive 太久而被中间的网络设备丢弃了。如何定义 inactive？简单来说就是这个 TCP 连接上没有在一段时间内没有传输任何内容。

为什么网络设备会丢弃不活跃的 TCP 连接呢？因为机房的程序访问到公网要经过 NAT，防火墙等网络设备（其实和家用宽带是一样的，只不过家用路由器本质上是一个路由器+NAT+防火墙），而防火墙或 NAT 设备的内存只能保存有限的连接数，因为连接的保持需要内存，内存是有限的。它们普遍采用的策略是保留最近用到的连接，丢弃最旧没有有消息的连接。即使内存没有用完，一般在配置上也会设置一个连接最长的 inactive 时间，尤其是防火墙设备。

那么如何解决这个问题呢？首先如果不用长连接肯定就没问题了，每次需要发送 HTTP 请求的时候，都重新建立 TCP 连接。但这样成本就高了，TCP 连接不复用会浪费硬件资源，延迟也会升高。所以更好的方法是使用 Keepalive，即还是复用长连接，但是需要把长连接保持住。Keepalive 的原理，其实就是定时在 TCP 连接上发送 len=0 的包，即不包含 payload，类似于 duplicate ACK。发送空包不会对对端造成任何干扰，但是这些数据包会刷新中间的网络设备，避免连接失效。退一步讲，即使连接失效了，也可以通过 Keepalive 包来提前发现，避免用到的时候才通过超时发现问题。

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

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

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

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

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 国际 协议。

---