线上问题分析:The target server failed to respond(目标服务器返回失败)

背景

后台服务通过REST接口调用第三方服务,调用偶尔会发生失败。查看后台日志发现,抛出The target server failed to respond。
该问题只是在特定操作下才会出现,暂时没有任何规律可言。

问题分析

1、到第三方服务器上查看后台日志,发现在相同时间点没有日志输出。查看tomcat的locahost_access访问日志,也没有发现任何日志信息。初步怀疑请求没有达到第三方服务器。
2、怀疑是gateway的问题,但是调用服务是通过ip直连的方式,没有通过gateway中转。排除此种可能。
3、为了验证http请求是否发出,以及是否到达了第三方服务器,使用tcpdump工具,对网络包进行了监控。只监控这两台服务器,脚本为:
tcpdump host A and B -w test.cap
注意,此处生成的是cap文件,方便在windows上用wireshark工具进行分析。
用wireshark分析的结果如下:

从分析结果可以看出,已经与第三方服务器建立了连接,但是第三方服务器没有返回HTTP应答,只有一个TCP响应报文。由此可以排除步骤一的疑点。
但是按顺序分析这几个报文,一开始就建立一个HTTP连接,不太符合TCP连接的规范。理论上,应该是走TCP的三次握手。有一种可能是,使用了连接池的机制,重用了TCP的连接。但是为什么第三方服务器会发送一个重置的TCP报文呢?
4、在我们的服务器上查看连接情况,使用netstat -nltpa,发现有个CLOSE_WAIT状态的连接:

根据TCP的四次挥手理论,此种情况是因为第三方服务器端主动发起了关闭请求,而咱们的服务器还没有对这个请求做处理。
咱们的HTTP协议使用的是1.1版本,因此会默认为Keep-Alive,在请求头中,Connetion确实设置为了Keep-Alive。排除客户端主动关闭的可能。

查看第三方服务器的tomcat配置,发现超时时间是20s。因为在请求处理完后的20s,服务器端就会主动关闭TCP连接。
有了这个线索,我们就掌握了重现的规律:发送一个请求后20s,待客户端连接状态变为CLOSE_WAIT状态,再发送一次请求就出现错误了。

结论

1、客户端使用了HttpClient的连接池机制,因此TCP连接会被重复使用,并且由于默认使用的是HTTP 1.1协议,Keep-Alive会被置上,因此不会主动关闭连接。但是由于第三方服务器配置了20s的超时时间,TCP连接会被关闭,但是此时客户端的TCP连接会被回收到池子里,不会理睬服务器发送过来的关闭请求,因此客户端的连接状态会变成CLOSE_WAIT,而服务器经过一段时间等待后会关闭自身的TCP连接。如果客户端下一次请求正好使用了这个TCP连接,就会出现服务器返回空应答的情况,从而抛出该问题。
2、HTTP协议是基于TCP连接的,如果是重用已有的TCP连接,则TCP三次握手不会发生。抛出该问题,是HTTPClient在解析HTTP头时,发现没有数据。根本原因是因为没有返回HTTP数据包,而是返回了TCP数据包。

总结

1、可以使用HttpClient重试机制,调用第一次失败时,第二次可能就正常了。HTTP 1.1默认使用了持久连接机制,像这种情况不可避免。如果访问频繁的话,该问题不会发生,而且性能会比较高。
2、开启一个线程,定期关闭无效的TCP连接。HttpClientConnectionManager.closeExpiredConnections()、HttpClientConnectionManager.closeIdleConnections()。这个方法没试过。(此方法为官方文档的推荐方法)
3、在请求头里设置"Connection":"close"。弊端是,没有用上连接池的性能。
4、设置HttpClient的连接重用策略。目前的重用策略,对于HTTP 1.1,都是默认为可以重用。

如果服务器使用长连接配置,那不做调整应该也不会碰到该问题。
但是服务器如果设置了keep-alive时间,客户端如果也同样设置,感觉不太灵活。
有没有更好的方法,还需要去研究下HttpClient的实现。




你可能感兴趣的:(java)