作者简介：大厂一线资深开发。从crud开发到资深开发，再到研究员兼技术经理。《资深开发讲技术》从一线实战中总结有故事，有背景的案例，希望带给大家一系列技术盛宴。

背景：

在实际工作中，我推崇每周一次，线上环境日志巡检。通过巡检，主动发现系统存在的问题，及时优化。目前我们团队进行了超过一年时间，巡检记录超过50次，主动发现不少系统的问题，系统可靠性得到极大提升。我今天想和大家聊聊巡检中经常遇到的 http异常。

线上异常case：

case1:异常日志中出现read timeout。

case2:异常日志中出现 connection reset。

case3:异常日志中出现 connection reset by peer。

case4:异常日志中出现 connection timeout。

case5:异常日志中出现 connection refused。

首先需要指出的是，我并不是单纯的理论派。作为长期一线开发，工作中更需要，能快速分析，快速定位，快速响应。而不是遇到问题后，翻找资料，埋头苦思。在一线开发的时候，我更像一位快速响应，快速实战的实战派。所以接下来的分析，尽量直接给结论，如果读者觉得深度不够，可以继续学习相关资料。

case1:异常日志中出现read timeout。

这类异常，在线上比较容易出现。但是往往，这类异常，追查起来，几乎都能发现系统需要优化的点。例如read timeout设置不是合理。如果设置时间，已经比较长了（比如6秒）。但是还有特殊case出现超时，那么建议，服务提供方和使用方，一起联合排查下。

case2:异常日志中出现 connection reset。

这类异常需要各位重视，一般发生在服务器端重启过程中。所谓连接，简单理解就是服务器端和客户端约定好IP和端口，并预留一部分资源。

但是如果事先建立好的连接，服务器端单方面非正常关闭连接的话（比如重启，故障），客户端是并不知情。那么已断开的连接继续read,就会发生connection reset异常。

我们的线上服务使用的rpc框架，rpc框架一般都会池化连接，比如200个。那么服务端出现异常，此时如果连接没有主动自愈的话，此异常就会出现。

需要注意的是如果线上大量出现connection reset，而且持续时间较长，那么请紧急联系下提供方，服务提供方大概率出问题了。

case3:异常日志中出现 connection reset by peer。

case3和case2原理是一样的，connection reset，发生在客户端主动读异常的连接。connection reset by peer发生在，客户端主动的写数据，到异常的连接。

case4:异常日志中出现 connection timeout。

这类问题较为综合，不能片面的得出结论。有虚机的网络异常，触发连接超时；有服务内存出现问题，影响了客户端正常工作，引发的connection timeout；也有客户端缺陷，对网络偶发的异常，兼容性做的不好。我在实际工作中，都有遇到。具体case，需要具体分析。

case5:异常日志中出现 connection refused。

这个异常我见的比较少，一般发生在，负载过高，nginx层拒绝；配置出现问题。基本上出现此异常，需要开发排查下具体原因。

http是互联网开发最基本的工具，但是很大一部分同学理解不到位，使用不到位。我在实际工作中，问过不少同学。绝大数同学不知道http返回的异常的含义。我希望通过这篇文章，大家能有所收获。