首先，通过这个抓包文件前几个包可以发现，服务器的网络是没有问题的，因为访问 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 包来提前发现，避免用到的时候才通过超时发现问题。
评论(0)