标签：应该 问题 开发测试 一个 tin out log eset image
问题：某业务系统在运行一段时间后，某个API一定概率偶现Connection reset现象。
问题定位：
首先想到的是要本地复现出这个问题，但一直复现不出来。
8、但考虑服务端有设置60s的超时时间，不会出现那么大概率的问题
9、可以通过在返回header头中加入timeout时间，强制给客户端设置一个长连接超时时间。如
10、去掉默认策略。（因为特殊原因不能让客户端改）仍然不能解决问题。
11、修改测试任务发送的时间，发现sleep时间在30S内不会出现该问题，sleep时间在30-60s会50%概率出现。
12、查询所有链路上的（客户端、lvs、nginx）的相关系统参数超时配置，修改均无效。
13、在设置为32S sleep的场景抓包分析。客户端抓包如下，发现在32S用同一个连接去发送数据后，服务端返回了一个RST（重置连接）信号。但对比服务端nginx日志，并未发现收到该包。怀疑问题出现在LVS
14、LVS上抓包，发现是LVS上回复了RST重置连接的包。检查LVS配置
15、发现有个如下设置：
ipvsadm --set 30 6 60
看说明，应该不会影响功能。在抓包的结果中也发现，客户端会重新换个连接，重新发一次请求。
16、思考良久，在测试代码中加入了catch，发现catch后就不会进行重新选取连接重试。导致BUG。
17、查看LVS官方文档，发现三个参数和baidu搜出来的结果不一致。该参数会使TCP连接超时。
18、修改参数为set 60 6 60，（加上参数的目的是为了方式长连接 的四层tcp耗尽攻击）。问题解决。
至此，问题定位完成。要保证lvs的tcp连接超时时间和nignx的keepaliveded超时时间一致才会出现该问题。
参考：http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html
https://dongliboyqq.iteye.com/blog/2409122
记一次httpclient Connection reset问题定位
标签：应该 问题 开发测试 一个 tin out log eset image
原文地址：https://www.cnblogs.com/wuweidong/p/11028609.html
