2019-12-06 才来一次,,，对于tcp timeout类问题的思路

一两个月以前就发现，位于国外的测试主机经常出现连接失败导致的错误报警，我们的业务涉及国内国外，国外有测试主机A，运行Jenkins任务，由主机B上的脚本轮询主机A上的Jenkins接口来获得测试状态；最近两周仔细观察发现，连接失败多出现在北京时间3-5点和晚上11点-凌晨2点.我通过监控系统也发现非常规律的TIME_OUT（和连接失败相符合），测试主机上的任务是调用美国的业务API，如果出现超时，测试直接会报错。（不行了，越说觉得越明显了，这么明显的原因今天才发现…还是因为别人的失误发现的…）

首先我们看到规律的TCP timeout，但是有TCP timeout 不一定有报警，但是报警一定位于TCP timeout，同时监控看到有大量的TIME_WAIT，1K左右

再来描述下今天发生的事，同事在国内"业务"搞域名切换，要把一个域名解析到另一个IP,突然国内的测试和国外的测试都有大量报警，看国外的是有过时的构建任务失败(红色)，Jenkins URL访问失败。

我非常确认的是过时的任务不会触发警报，所以它构建失败只是幌子，但是看国外业务测试又没有出错，断定是主机B获取结果失败，从而报警。
同时由于另一个同时怀疑TIME_WAIT的问题，但是说由于Jenkins 作为server，由于自己主动断开连接造成的1K多TIME_WAIT，不至于导致自己的服务器程序没端口可用，而导致其他客户端访问而超时，所以TIME_WAIT 排除 ,但是TIME_WAIT对应的主机IP令人生疑，同事查得是北京亚马逊中心的IP，但是从AWS控制台并没有找到这个IP对应的主机信息，于是我百度这个端口，20389
这才点醒了我。测试主机使用的身份认证LDAP服务器是国内的，它出现故障，导致位于主机B上的程序 登录Jenkins超时，但是报出的错是连接Jenkins超时，掩盖了真相。于是登到主机上tcpping，2s等待时一步三跪，国内主机就没这个问题。

我们事后分析
openfalcon的TIME_OUT指的是计时器第一次超时时间，显然由于TCP重试机制，并不是每次第一次超时就会导致失败；这个TIME_OUT当然是向外的请求，既然向外的业务请求没有频繁超时，那么肯定是非业务超时了，但是没有想到主机上除了业务测试谁还会向外发请求。

主机C访问主机S的服务P偶尔出现超时？
范式： 查看主机C程序日志，系统日志和统计，C外发请求是否出现丢包(ride rocket)，S主机在端口s收包是否成问题丢包？端口不够用？，服务P在处理请求(数据流动一定要具体)依赖的网络服务是否正常？

在解决问题时，要列举事实你所看到的现象，可以转述给别人（甚至模糊的转述给别人），看他的提问，给你不一样的切入点。

附加 国内国外:一般，公司可能非主要业务使用同一个系统；
北京时间：网络请求有明显的峰谷特性（一次傍晚时间明显的请求失败）；
直接出现报错：那么TIME_OUT就是非测试请求时发生的；
搞域名切换：新IP对应的服务器上应用程序部署可能有问题，有缺陷；
都有：这两个程序的共同点出了问题 （依赖LDAP）；
并没有找到这个IP对应的主机：那么这个IP是ELB的，但是怎么根据IP找打ELB名称我觉得是个技术活…

20200102
TIME_OUT问题再次出现，不过这次不是测试，而是关键业务主机。openfalcon显示0.3左右的TIME_OUT，已经很明显的影响到测试，估计用户使用也是。描述:测试发送TCP请求，socketTimeout是5s，仔细看Java文档，说的是readTimeout,5s内测试没有收到相应于是返回null，报错，但是从业务日志来看，(看了一个,即使一个也应该是可信的，因为业务没有大量报错),该请求79内ms就处理完并返回了，并且该请求不是和服务器交互的第一个请求，这次是在国外出现的问题，12.25出现问题；还有一次是国内618，初次请求就出错，监控表现为傍晚5点半开始业务主机有TcpDropOnOverflow，就是在建立TCP连接时的半连接队列满了，客户端请求被丢弃，晚上百度半连接队列满是因为业务模块处理不过来，不过我们不论是CPU还是Mem都很低，后面排查出为进程文件打开数限制ulimit -a。

学习在应用层编程中TIMEOUT和传输层重传，计时器等的关系。