Wireshark TS | AWS 服务雪崩效应

前言

雪崩效应，技术上的“雪崩效应”理论，我简单理解是一个调用或是依赖不能提供服务，有可能产生雪崩效应，最后造成整个服务不可使用。可能也像是说连锁反应、蝴蝶效应，都是一个小因素的变化，继而连续发酵产生些不可预知的事情，最终产生意想不到的结果。

本文从网络数据包分析的角度，分析一个服务调用问题的实际案例。

问题描述

某日研发中心反馈资讯业务同步任务失败，发生了很多次，因为是跨数据中心访问 AWS 云，涉及到专线，怀疑可能是网络问题，上报至网络运维。之后和相关业务同事沟通，确认了几点以下故障信息。

问题拓扑

问题现象

1. 客户端 netstat 显示与数据库端正常连接 Established 状态，但数据库端并无相关连接，同时防火墙上也无相关连接；
2. 同步任务失败偶发，持续几分钟后即停止，应用日志上显示没有结束，且没有报错日志；
3. 此同步任务还有另外一个特点就是带宽比较低，每秒同步几百条；而其他的同步任务都能上万，一两兆的带宽。

问题分析

客户端连接问题

分析的第一步首先是确认连接问题，客户端显示有 Established 状态连接，但数据库端和防火墙上并没有连接。初听下来确实感觉诡异，本着怀疑一切的心态要求各端一一再次确认，反馈的结果仍是一样。之后要求系统负责人在客户端通过 tcpdump 抓包验证，并没有捕获到相关数据包。

那么问题究竟是什么情况呢？

1. 假设应用有心跳保活机制 或者 系统开启了 TCP keepalive 选项

这种情况下，在端到端无数据传输后的一段空闲时间后，理论上通过保活机制会维持这个长连接在。但是因为考虑数据库端和防火墙上并没有相关连接的情况下，可能是会话空闲时间在防火墙上相对较小，首先防火墙先超时了会话连接删除，紧接着数据库端后超时会话连接删除，而客户端侧由于应用设计的问题，并没有超时退出，所以连接一直存在，而 tcpdump 抓包没有抓到，可能是检活包的间隔时间较长，而抓包时间较短的原因。

2. 假设应用没有心跳保活机制 或者 系统没有开启 TCP keepalive 选项

这种情况下，在端到端无数据传输后的一段空闲时间后，根据防火墙的机制，肯定是空闲会话超时之后连接删除，之后数据库端后也因为会话超时连接删除。而客户端侧由于应用设计的问题，并没有超时退出，所以连接一直存在，而 tcpdump 抓包正常来说确实是无法抓到相关数据包。

在无法深入应用和系统的情况下，我觉得第二种假设更像是真实场景。

进一步搜索相关文档，考证了下客户端 Established 状态超时问题，长时间无法释放连接的原因和以下值有关，为 432000 秒，也就是 5 天。也确实和应用同步任务在上一天下午开始后停止，而在第二天仍能在客户端上 netstat 看到 Established 状态连接的现象一致。

[root@server ~]# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
432000 

流量回溯分析

考虑到客户端涉及应用和系统多方，无法很方便的配合抓包，遂和相关方同步了问题任务的具体发生和停止时间，在网络侧通过科来流量回溯分析设备，调取了发生问题时候 AWS 公有云专线上的数据包进行线下分析。

正常连接

正常情况下的连接，以 TCP 三次握手建连开始，IRTT 约 27ms，通过 Oracle TNS 协议进行交互，基本以 Request 和 Response 结对出现，传输过程中也会出现标准 MTU 1500 大小的数据包正常发送接收。

同步任务，正常数据传输交互完成后，以 TCP 四次挥手结束连接。

异常连接

在业务故障时点，回溯分析流量时发现了该异常连接，分析过程如下

1. 如何判断并找到异常连接

首先在回溯流量时，就依据应用日志的时间，缩小了数据包范围，其次该连接并不完整，传输持续了整整 8 分多钟后发生了停顿，且传输速率仅为 588 kBps，符合应用反馈的现象。

$ capinfos -ae test.pcapng
File name:           test.pcapng
Packet size limit:   inferred: 66 bytes - 1514 bytes (range)
First packet time:   2022-02-10 17:30:23.143816404
Last packet time:    2022-02-10 17:39:16.974296358


$ capinfos -y test.pcapng
File name:           test.pcapng
Packet size limit:   inferred: 66 bytes - 1514 bytes (range)
Data byte rate:      588 kBps

上述所说的连接不完整，意思是仅有正常的 TCP 三次握手和数据传输阶段的数据包，并没有结束连接的 TCP 四次挥手数据包。

在 No.291010 数据包之后，即没有任何数据包交互，再次通过流量回溯设备拉长时间范围，仍没有看到任何数据包，再次验证了应用没有心跳保活机制或者系统没有开启 TCP keepalive 选项的问题。

另最重要的一点，由于应用客户端在第二天 netstat 仍有连接信息，通过反馈得知源端口就是 51346 ，即找到了符合应用问题的实际异常连接。

2. 连接有什么样的异常

首先通过 Expert Information 快速浏览跟踪文件中的异常信息，有大量的疑似重传、快速重传和重传的信息，初步感觉像是有丢包问题。

展开重传信息，方向基本发生在数据库端至客户端的传输方向上。

Tcptrace 图中，展现大量重传现象。

3. 连接为什么异常

进入最重要的一步，定位故障原因。再次通过科来流量回溯分析设备，梳理专线带宽使用情况，在该故障时间范围内并无使用满的情况，且无突发流量尖峰，说明专线带宽是没有问题的。

展开跟踪文件异常信息位置，首先就会发现有很多 DUP ACK 现象。

No.886、No.899、No.901 … ACK 数据包不断 ACK num 803437，而在专线捕获点上是能看到 No.881 从数据库端发给客户端 Seq num 803437 的数据包的，这个问题说明 No.881 数据包在数据中心内部发生了丢包，客户端并没有收到，甚至说在 No.881 之后的部分数据包也有可能没有收到。

继续向下进到重传位置

在 TCP Dup ACK 884#43 发生了 43 次之后，触发了数据库端的快速重传， No.1091 重传了 Seq 803437 的数据包，紧接着一连串的重传数据包，从 Seq num 来说在跟踪文件的上面都已经看到过一次了，可能说明在数据中心内部发生了多个分段丢包情况。

纳尼？小带宽的专线没丢包，数据中心内部丢包？？？网络快速排查数据中心内部客户端访问数据库端所经过的路径，发现并没有网络线路流量满的情况，虚惊一场。那么数据中心内部丢包问题只有指向客户端了，在进一步详细和系统负责人沟通后，反馈说在客户端做了 iptables 限速 … 原因是之前应用任务同步时曾经把专线带宽打满过一次，所以在客户端上做了限速，好吧，信息不同步问题。

在上图中实际上还有一个很关键的问题，No.1091 之后的重传数据包基本把 Seq 803437 丢包之后的数据包都传了一遍，这意味着什么？没有 SACK 的情况。回溯一下 TCP 三次握手，确实在数据库端不支持 SACK。这样的问题就导致传输效率低，重发了很多原来不应该重新传输的段。


异常形成了规律，不断大量丢包 – 重传 – 恢复 – 丢包 – 重传，最后数据库端发生了卡顿，未再重传数据，至此交互发生停止。

小结

综上所述，问题实际导致的原因是由于客户端做了 iptables 限速 ，在数据库端传输数据达到一定速率后产生了丢包，又由于数据库端没开启 SACK 选项的情况下，造成了重传数据包过多，传输效率进一步降低，反复后数据库端陷入了沉寂，反映在业务上就是同步任务停止。之后又由于应用和系统上没开启检活机制，防火墙空闲会话超时删除连接，紧接着数据库端空闲会话超时删除连接，最后应用客户端无连接退出机制，从而一直保持建立连接状态。

可以优化的几点：

1. 网络专线升级带宽，客户端解除 iptables 限速；
2. 数据库端开启 TCP SACK 选项；
3. 开启心跳检活机制或 TCP keepalive；
4. 优化应用代码，超时退出。

问题总结

雪崩时没有一片雪花是无辜的。

---

感谢阅读，更多技术文章可关注个人公众号：Echo Reply ，谢谢。