上班的时候，突然被测试和产品加入了一个讨论组，说有个问题需要我排查下，一头雾水，于是开始进行了解和排查。
- 故障现象
客服人员使用该系统的沟通（拨打IP电话）功能的时候，弹出的沟通窗口会卡顿，并且关闭当前弹窗，返回首页也会卡顿，卡顿时间1分钟左右。
-
排查流程
1，系统排查
根据现场IT同事反馈异常出现比较集中到时段，进行系统状态查看A，pinpoint查看用于GC和响应正常；
B，nginx日志中没有大量超时异常请求（ELK日志中没请求超时情况）；
C，不存在大量请求在同一台服务器情况，造成单台服务器负载过高情况；
第一次排查：系统正常。2，网络排查
A，发生异常时，IT 现场进行ping 正常，访问其他网站正常；访问公司其他网站正常；
B，发生异常时，traceroute正常；
C，IT 统计办公区网络设备连接数，并未发现异常(担心网络终端网络连接数被耗尽)；
3，浏览器debug
A，异常情况下, it使用浏览器debug，进行请求分析，并未发现异常；
B， 拿到测试账号，登陆后台亲自进行debug,没有发现耗时长的资源请求；
4，再次收集问题
通过上面到排查，排出了应用，网络问题，开始怀疑用户客户端问题。
A，it通过资源管理监控，异常情况时，用户电脑资源并未有明显波动；
5，IP电话问题
同IT排查过程，收集到一个奇怪到现象：拨打IP电话和挂断IP电话打时候会出现卡顿现象。
A，该现象每次毕现；于此同时IP电话打不通和中途断线情况；
B，让it咨询IP电话服务商，确认IP电话是否会对网络有影响；
由于涉及到外部协调排查IP电话，比较费时，同时使用IP电话系统的另外一个系统没有出现卡顿现象（虽然IP电话使用数量上少很多），可以确定IP电话和这个关联性不太高，属于巧合。
6，wireshark 抓包
A，通过之前分析，服务是OK，由于没法办法追踪到具体用户请求，所有不方便排查用户请求是否到达服务器；
B，故障属于随机发生和离现场较远，没法现场待命随时进行浏览器debug分析；
C，traceroute 排除了网络层的问题，浏览器debug基本排出应用层问题；
由于拨打电话毕现，因此让IT同事找个用户电脑进行安装抓包软件，并让他进行电话拨打，对这个时间段对抓包结果进行分析。-
抓包分析
根据it抓包结果，发现有大量对虚假重传
搜索 “tcp spurious retransmission”，网上给出以下可能出现的原因：
'''
tcp虚假重传
指实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种：
（1）对于部分移动网络，当网络发生切换时会导致网络延时突增
（2）当网络的可用带宽突然变小时，网络rtt会出现突增的情况，这会导致虚假超时重传
（3）网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。
'''
但是都没有关于该问题的解决方法。- 尝试方案
搜索 tcp timestamp
文章http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
提及到故障现象和我们遇到类似，于是修改内核参数tcp_tw_recycle=0，并观察（周日修改）
- 故障复现
周日修改后，周一天告知it注意观察；到下班时候，确认一天内没有用户反馈卡顿现象；
为了验证该问题，确认不是由于其他操作（更新，网络改善）解决该问题，于是周一晚上把该参数调整回去；周二上午上班到10:30 收到5-6个卡顿到问题，于是修改回参数，到下班未收到类似反馈。
- 问题原因
服务端通过timestamp的递增性来区分是否新连接，新连接的timestamp更大，那么小的timestamp的fin 就不会fin掉新连接；对于服务端，同一个src ip，可NAT后很多机器，这些机器timestamp递增性无可保证，服务器会拒绝非递增请求连接。
- 解决方案
net.ipv4.tcp_tw_recycle = 0 (所有直接对外提供服务到服务器开进行关闭）