ECONNABORTED，Socket 常见连接错误之一，原因分析 + 解决办法

当服务和客户进程在完成用于 TCP 连接的“三次握手”后，客户 TCP 发送了一个 RST （复位）

文章共1,706字 · 阅读需要大约6分钟

一键AI生成摘要，助你高效阅读

问答

Java Punk

31997人浏览 · 2021-01-20 00:41:53

Java Punk · 2021-01-20 00:41:53 发布

原创博文，欢迎转载，转载时请务必附上博文链接，感谢您的尊重。

前言

通过本篇，你将简单了解到 Socket 连接错误—— ECONNABORTED 【产生的原因】，还有【避免的方法】，结论直接见最后的【总结】。

近期手里的功能已全部安排测试，信心满满的坐等上线了，突然测试小姐姐反馈：合同查看接口，偶发性的查不出数据，同时页面提示“服务异常请稍后重试”。

该功能点的前后端交互流程：前端axios请求服务端接口，服务端将合同的PDF格式文件转换成Base64字节码，返回给前端，前端渲染显示。

真的是第一次遇到这样的问题，起初毫无头绪，明白以后豁然开朗，瞬间泪目...

正文

小编是做后端的，每天都在写Bug，找Bug方法早已烂熟于心，待我一套组合拳下来确定不是后端问题，开始找前端大神讨论，被一句“绝对不是前端的问题”怼了回来。

啪啪打脸，菜鸟在大神面前果然不堪一击，咱啥也不敢说，只能一边揉脸一边客气的请求大神“配合我查一下可能的问题”。

接下来，原因被一连串的揪了出来，希望这个思路对你有帮助。

1. 根据提示，定位问题

先定位错误提示“服务异常请稍后重试”的位置，后端是不可能后端的，这辈子都不可能是后端，最终还是在前端的底包中找到了这句提示（没在功能代码里，所以大佬最初肯定了不是前端问题，把我怼了回来，o(╥﹏╥)o ！！）。

代码逻辑是这样的：当响应发生异常（即：error），error.response 信息为空，但error.code = ECONNABORTED 时，弹框提示“服务异常请稍后重试”。

那么，什么时候 error.code = ECONNABORTED 了？

2. Socket 常见连接错误

翻阅众多资料，我们发现了 error.code = ECONNABORTED 是Socket 常见连接错误之一，Socket 常见连接错误有：

ECONNABORTED：“software caused connection abort”，即“软件引起的连接中止”
ECONNRESET：“connection reset by peer”，即“对方复位连接”
ETIMEDOUT：“connect time out”，即“连接超时”
EPIPE：“broken pipe”，即“管道破裂”

其中，对 ECONNABORTED 的原因解释是：

当服务和客户进程在完成用于 TCP 连接的“三次握手”后，客户 TCP 发送了一个 RST （复位）。在服务进程看来，就在该连接已由 TCP 排队等着服务进程调用 accept 的时候， RST 却到达了。POSIX 规定此时的 error.code 值必须是 ECONNABORTED。源自 Berkeley 的实现完全在内核中处理中止的连接，服务进程将永远不知道该中止的发生。服务器进程一般可以忽略该错误，直接再次调用accept。

又绕到TCP/IP协议的“三次握手和四次挥手”上来了，很多小伙伴都知道这个概念却不知道应用场景，现在它来了。

3. 解决办法

既然说到“服务器进程一般可以忽略该错误...”，那么我们就在前端解决问题。我们的突破口，是：客户 TCP 什么情况下会向服务发送了 RST （复位）？

小编找来了大佬对这个问题的深入研究结果：

当代码调用客户端P2P网络连接后，立刻执行了Client Socket 连接，此时网络切换还没有稳定，客户端设备网络IP地址还没有完全切换成功，所有导致了Socket连接失败。最终将Socket连接放到网络成功监听之后执行，100%成功。

简单点，就是网络问题造成的连接异常，导致客户向服务发送了RST（复位）。针对网络问题，我们做了以下的事情：

首先，因为是偶发，出现几率并不大，且它和用户当前网络速度直接相关，所以，如果你的APP没有庞大的客户群，这个问题可以暂时忽略；
由于我的问题只在pdf文件渲染处爆发，为了保证渲染的可靠性，我们降低了 pdf.js 的版本（只拷贝需要用到的文件，没必要全都要），由 v2.6.347 → v2.0.943（见下图）；
为了保证交互的可靠性，在main.js中设置延长全局的请求次数，请求的间隙，增加了 axios 请求的“连接超时”时间；
必要时可以在 error 中做重新请求处理（我们没有这样做）。