记一次linux 服务器丢包故障排查

  开发联调过程中，使用到了测试环境。测试环境部署在单独的服务器上，由单独的域名访问。但相同的代码和环境，生产环境的服务能够正常访问，而测试环境api经常出现访问超时，一直处在pending状态，而在服务端无论是nginx还是应用层的log都难觅踪影。

  有意思的是，这个现象只有在使用公司网络访问测试域名才会出现。并且复现并没有规律，与具体服务api无关，往往是出现连续几个请求pending，一段时间后恢复。同一时间用云服务进行压测，并没有出现不可用。

  因此，一开始我就一口咬定是公司网络的问题，加上公司的网络环境确实很差劲。但同一个时间，公司的网络访问其他域名的服务一直正常,狠狠的打了脸。首先还是考虑是服务本身的问题，排查了负载情况，重新部署，分离了多个测试服务。但依旧没有丝毫改善。

  推翻了错误的假设后，一时间没有什么思路，决定首先复现这个问题。在本地通过公司网络和ECS不断压测，有大概5%的请求复现了这个问题。而服务器确实没有接收到请求，可以断定不是应用层的问题。

  首先怀疑是DNS的问题，用ping和traceroute测试后否定这个假设。下一步通过httpstat工具分析请求的每步耗时。终于有蛛丝马迹，tcp连接建立的时间高达67000ms。问题就出在tcp连接上。

  接下来通过tcpdump在服务端进行定位，但由于请求很多，并没有找到有用的信息，又陷入了僵局。在网上看了大量的资料，幸运地看到了一篇文章，https://www.sdnlab.com/17530.html。</