客户老是反应调用我们接口超时，但通过监控来看系统并没有什么异常，所以接口调用超时时到底发生了什么呢？让我们通过本文来一探究竟。

服务端程序（一个简单的REST接口，直接睡眠个10s，模拟响应时间长）：

客户端程序（通过HttpClient调用REST接口，配置socketTimeout参数，将超时时间设置为2s）：

启动服务端，然后客户端发起调用。

客户端在2s后发生超时，调用终止：

服务端接口打印日志：

由上述日志可以看出，客户端调用在超过2s后还没有获得响应时，便会抛出Read timed out异常，结束调用，但是服务端针对本次调用还是会完整的处理完，不会因为客户端的调用终止而终止处理。

所以这期间到底发生了什么？服务端请求处理完成后还能响应给客户端吗？

重复上述步骤，模拟客户端调用超时，进行抓包。

抓取的数据包如下：

根据抓包得出整个处理流程如下： 1、TCP三次握手； 2、客户端发起请求； 3、2s后，客户端请求超时，发送FIN包关闭连接； 4、服务端响应FIN包，返回ACK； 5、10s后，服务端处理完请求，返回响应； 6、客户端响应RST重置连接。

可以看到，即使客户端已经返回响应超时异常了，服务端还是会正常处理请求并在完成后响应，并且这个请求状态还是200（这也是服务端监控并没有发现响应异常的原因），但是在返回响应给客户端时，客户端会响应RST包重置该连接，也就是该响应最终并没有成功返回给客户端。

所以说，HTTP请求超时是客户端调用方的概念，服务端在处理请求的过程中不会因为处理时间过长而中断响应，反而是会一直等待请求处理完成然后返回客户端。

至此，接口请求超时的整个处理流程应该比较清楚了。

但还有一个问题，客户端是怎么触发超时提前抛出异常返回的呢？

首先看超时配置：

可以看到上述设置了超时时间参数socketTimeout，通过跟代码，该参数实际是设置了Socket连接的soTimeout参数：

继续看Socket#setSoTimeout方法，通过注释该参数的意思应该比较清楚了——如果超过设置的超时时间读操作还没有返回（即没有接收到响应数据），则会抛出SocketTimeoutException异常。

所以客户端的请求超时实际上是通过设置Socket#soTimeout参数来实现的，即超过指定时间还未读到响应数据，则抛出异常。

HTTP请求超时是客户端调用方的概念。

服务端在处理请求的过程中不会因为处理时间过长而中断响应，反而是会一直等待请求处理完成然后返回客户端。

客户端在调用超时后，会发送FIN包中断连接，所以即使服务端处理完请求后，也无法正确返回给客户端。

客户端的请求超时实际上是通过设置Socket#soTimeout参数来实现的。

知道了这么多，那么到底该如何解决客户端调用超时的问题呢？客户端调用超时的根本原因还是服务端响应过慢，解决方法得从提升服务端性能，减少响应时间入手。如果服务端涉及到第三方调用，还需要将同步调用异步化，通过牺牲一致性来提升性能。

希望今天的内容对大家有所帮助，更多精彩文章欢迎关注微信公众号：WU双。