wordpress主题商店搜索引擎优化方法总结

一、现象

okhttp调用某个服务，如果第二次访问间隔上一次访问时间超过60s，返回错误："unexpected end of stream"。

二、最终定位原因：

空闲连接如果超过60秒，服务端会主动关闭连接。此时客户端恰巧访问了这个异常的连接，服务端返回RST错误连接标志位。

问题一：这个现象只要超过60秒就会复现吗？

  答：不会，这个现象只会在TCP释放连接的四次挥手过程中出现。如果四次挥手结束了，客户端不会访问已关闭的连接。通过wireshark抓包，在测试环境，TCP四次挥手中的第一个FIN和第二个FIN间隔会有15毫秒到40毫秒不等。因此，碰到的概率不高，出现的机会不多。

   问题二：为什么TCP释放过程中，客户端还可以使用该连接?

  答：TCP连接是全双工的，服务端发完FIN，此时只是关闭了从服务到客户端的通道，客户端到服务端的通道依然是正常的。

   问题三：为什么客户端在失败后没有重试？

   答：项目组没有配置重试。

三、解决方案

1、okHttp增加守护线程，定时进行应用层心跳做探活。

2、调大服务端的关闭空闲长连接时间；

3、缩短客户端长连接的空闲清理时间，至少要小于服务端保持时间，且不可设置成一致，设置一致依然会出现问题。

四、具体排查过程

第一步：

思路：排查Server端日志，发现没有打出日志，首先推断出请求至少没走到Servlet应用层；

结论与解决措施：查询Web服务器Tomcat源码，查看长连接超时时间；

第二步：

思路：通过源码发现keepAliveTimeout（默认等于connectionTimeout）时间为60秒，此时已经和现象相符了，随后在开发测试环境测试改动该值。

结论与解决措施：在开发测试环境调小该值，然后使用netstat观察服务端的TCP连接状态，发现到了我们设置的时间，Established状态的TCP连接就会变成TIME_WAIT。

server: tomcat: keep-alive-timeout: 20s

第三步：

思路：上面知道了60秒会主动关闭，现在就要在本地复现一下，看看能否复现出问题，是不是每次都会出现问题。

结论与解决措施：客户端每隔60.008秒定时向客户端发送一个请求，并用wireshatk抓包，很快就复现出问题。

下面展示了在进行TCP挥手过程中，客户端（ip是75）访问服务端(ip是149)，服务端返回一个RST。

如果超过61秒访问，现象不会出现，因为TCP连接已经完全关闭了，会重新建立连接，如下图，重新进行三次握手：

结论与解决措施：首先看客户端，客户端会在空闲一段时间，关闭某些空闲连接，项目组客户端设置了5分钟，时间过长，导致客户端一直没有检测。 不过客户端不会发心跳检测，只会定时关闭空闲连接。

然后，我让项目组查询生产服务端的keepalive时间，发现是7200s。

sysctl -a|grep keepalive_time net.ipv4.tcp_keepalive_time=7200 //TCP探活间隔2小时

第五步：

思路：在开发测试环境测试服务端的TCP连接，我们把开始测试环境改成空间连接30秒开始检测。

结论与解决措施：发现该配置不起作用。