局域网下的客户端调用服务接口超时的问题总结

一、准备知识
1、HTTP Keep-Alive
在Http早期，每个http请求都要求打开一个tcp socket连接，并且使用一次之后就断开这个tcp连接
使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数。
当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

2、客户端okHttp的连接复用
Okhttp中连接复用正是建立在HTTP Keep-alive基础之上实现的，默认为5分钟，支持5个socket连接并发，也就是五分钟内客户端如果和已连接的服务器通信不需要重新三次握手连接（三次握手确保了服务端和客户端都具备可靠的通信能力，但握手过程耗时）。

3、客户端okHttp请求超时

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)  // 连接超时
    .writeTimeout(10, TimeUnit.SECONDS)    // Socket写超时
    .readTimeout(30, TimeUnit.SECONDS)     // Socket读超时
    .build();

注意：在2.5.0版本之后，读、写、连接超时的默认值是10s。

4、wireshark抓包分析tcp流

tcp.stream eq  99
ip.src==10.159.63.237 or ip.dst==10.159.63.237
ip contains "api/v1/users/10235"

5、网络设备的相关参数
TCP连接的超时时间
HTTP连接的超时时间

下面贴出我们在用设备的参数默认值

image.png

二、超时现象描述
用户在平板上使用应用的时候，不定期提示超时报错，再重试一次就正常了。
这种报错比较频繁，操作的应用和功能也不固定，已经很大程度地影响了用户体验。

为了很好地理解下文，这里简单描述下局域网的网络拓扑图。

三、网络拓扑图

image.png

四、分析超时的规律
超时慢，第一反应是可能局域网的网络慢导致接口访问超时。
1、跑测试脚本，看接口的超时率、丢包、连通稳定性等
主要使用了ping 和 curl 两个命令。
###########################################################
访问并没有超时很严重

2、在笔记本电脑上执行ab压测，看响应时间和吞吐量等指标
###########################################################
上面两步均正常，超时率也在可接受的范围。无论是在有线还是无线，平板还是笔记本还是说小型服务器上执行测试脚本，再结合网络硬件设备性能偏上，带宽也百兆，始终都无法定位出是网络慢导致的接口访问超时。

3、在平板上开发测试工具，curl真实接口，有请求和有响应数据量的，模拟响应大小10Kb，请求数据随便造一些。
###########################################################
结果仍然是正常的。

4、我们去kibana分析日志报错，看是否有规律可循。
###########################################################
错误超时情况比较分散，没有集中在某个区域，也没有集中在某个用户，更没有集中在某些接口。
唯一总结的一个结论是：使用得多，超时数量就越多。但是晚上很少人使用的时候，也会报很多超时错误。
按照我们以往对网络的指标要求经验，继续分析网络设备参数方面。

5、更换平板，排除是平板硬件导致的超时报错。
###########################################################
换了新平板，超时接口数还是没下降。

6、观察除了超时错误，是否存在应用使用的卡顿问题，也就是慢接口是否也随之增多。
###########################################################
除了偶尔报超时，使用很顺畅。

7、排除网络设备的参数设置的影响，初步去掉上网行为管理中间设备。
更改网络拓扑图如下：

移除上网行为管理设备.png

###########################################################
超时错误并没有什么变化。

8、由于超时错误频繁出现，所以我们一边操作应用，一边使用wireshark抓包记录下来。
观察tcp流的超时到底是超在哪个环节，超时有什么规律。
###########################################################

image.png

http连接在126秒后复用的时候，出现超时。再多观察几个，均是如此。
这里需要串联开篇讲的几个知识点。规律就是连接在空闲后120秒，极大概率出现超时。

9、客户端采用okHttp模拟连接复用、连接不复用的对比测试
###########################################################
连接不复用的时候，超时比例大大降低

10、使用siege模拟分别delay 120秒，delay 180秒
//先请求一次，延迟120秒后再请求一次。
siege -d 120 -r 2 -c 1 -v http://bgp.test.com

//先请求一次，延迟180秒后再请求一次。
siege -d 180 -r 2 -c 1 -v http://bgp.test.com
###########################################################
超时现象容易复现，超过120秒，接口就大概率超时。

五、解决超时的办法
超时规律找到了，并且很容易复现，解决方案也自然容易。
1、把客户端okHttp的keep-alive的默认5分钟调整为100秒。

2、更改华为路由器的HTTP连接的超时时间，由120秒延长至300秒以上（大于okHttp的keep-alive的默认5分钟）。