现象
个别用户在盘中的时候与行情网关断开连接，导致用户页面白屏，收不到任何行情数据，需要等到90秒超时后发起重建连接才能恢复。场景无法复现，每天断网的用户是随机的。
问题的调查与分析
1，首先对于服务端来说，网络断开的方式有3种：
- 收到客户端的FIN包，主动断开
- 因为网络抖动收到RST包，主动断开
- 超时时间内（90秒）没收到客户端的任何请求，包括心跳包，服务端超时断开
2，所以接下来就是要确定客户端是以哪种形式断开的。我们首先分析服务端错误日志，发现有不少READ_TIMEOUT的报错，不过只是有超时报错其实说明不了什么，我们又对每个机房的READ_TIMEOUT数量进行了统计，发现有两个机房的READ_TIMEOUT错误数量明显高于其它机房，所以现在我们将排查目标锁定在了这两个机房。
3，然后我们调出了这两个机房用户在线人数监控图，发现监控图周期性的垂直下降，对比正常的机房，在线人数是一个平滑曲线，所以可以看出确实有用户周期性掉线。
4，因为网络通讯是客户端，服务端，信息技术部（负责自建机房和网络安全）三方协作的事情，以上分析也只是我们服务端视角得出的结论，他方并不一定认可，并且后续的调查也需要其它部门的配合，所以我先去找了客户端的架构师交流。跟前端架构师沟通得知，这个问题其实在三年前就已经有了，但是没能推进到最后，并且客户没有继续投诉这个问题就搁置了。最近也是因为收到多个用户投诉，这个问题才被继续提上日程。
5，分析这个问题其实有两个维度，一个是这个问题本身，定位问题，解决问题；另一个是用户体验的维度，其实之所以用户投诉，就是因为每次断开之后，要经过90秒才会断线重连，这个时间完全足够用户切出去，登陆别家APP，发现网络正常，再切回来了，用户体验很差。
我： 为什么我们的超时时间这么长？
前端：这是好几年前定下的，当时的网络条件没有现在这么好，高延迟很常见，权衡之下我们把超时时间 定为30秒，3次超时断线重连。
我： 那我们现在可以把超时时间缩短到什么程度，如果能缩短到用户感知不明显的程度，最好10秒以 内，那也是个可行的方案。
前端：这不可能，用户进入电梯，或者地铁什么的，断网时间超过10秒很正常，因为我们是长连接，频繁 重连也会降低用户体验。
6，经过沟通，我们放弃了缩短重连时间的方案，还是回到问题本身，接下来我们要确定客户端的请求是否正常发出，客户有没有误操作，在客户端和数仓的协助下，我们调出用户的行为日志，进行分析，发现在服务端没有收到任何请求的这段时间，客户端的请求确实发出来了，而且用户也是按照正常流程在操作，而且断线之后也有进行正常的断线重连操作。
7，基于上述分析，我们初步确定请求包是在客户端到服务端的中间环节丢了，客户端到服务端的中间环节有两个，客户端到我们机房的互联网链路和机房入口到服务器的内网链路。我们首先排查机房内部链路是否正常，因为如果是互联网链路出现问题也不是我们后端能解决的了，超出了我们的职能边界。但是自建机房是由信息技术部负责的，这算是我们的上级部门，而且办公地点也不在同一个区域，没法直接申请他们配合调查，需要部门大领导发正式邮件申请协同调查。并且信息技术部一向比较强势，本着谁提出谁举证的原则，如果我们没有确凿的证据，很可能一句话就给我们堵回来了（我们一样的配置，别的机房都正常，为啥你这个不正常？）。
8，基于以上原因，我们决定继续收集证据，因为之前的分析都是基于客户端和服务端日志，日志有出错的可能不能作为最终证据，所以我们决定在服务端业务网关入口抓包，再结合日志报错信息佐证。下图是一个超时的IP分析，可以看到15：00：04之后就没有再收到过客户端请求，后续的都是些失败重传。现在可以确定客户端的请求确实是没有到达服务端。
9，证据到手，我就开始写调查报告，发给领导，领导确认没问题之后，就开始给信息技术部发邮件，两天后收到答复开始派人配合我们调查。我们首先要确实客户端的请求有没有到达服务器，我要求在机房最外层入口抓包，最开始以为最外层是F5，就开始在F5上面抓包，结果发现还是没收到客户端请求，当时觉得有点懵，如果请求没到机房的话，按我们的推论就是互联网链路上的问题，这就不是我们能解决的了。期间我们也查了很多网络相关的资料，还资讯了几个大学教授，还是没能得到什么有用信息。结果，信息技术部说F5外面还有一层DDOS设备，晕。但是DDOS设备有规则限制，一次只能抓3W条，还没法设置筛选条件。我们试了一下，3W条请求持续时间还不到1秒钟，我们的超时时间是90秒，根本分析不出来。
10，就在要卡在最后一步的时候，我想着能不能短时间关闭DDOS设备，控制变量法，如果掉线的现象消失，不是也能证明吗？然后我就冒着巨大的风险，写申请，几经周折终于批下来了，我们找了一个并发小一点的机房，在下午15：00收盘之后，开始测试。果不其然，关闭之后，用户连接数图像上之前每次都会出现的垂直下跌点，变成了圆滑曲线。系统正常了。
11，之后的问题就不需要我们参加了，信息技术部最后查出来，问题是那两个机房DDOS设备的算法有问题。
总结：这次的问题排查最大的收获是首先对排查问题的流程要有清晰的思路，知道每一步的意义，其次学会了一些跨部门协作的经验，最后在你认为没办法的时候，可能再坚持多一点点就摸到成功了。
近期评论