重新分析connection reset by peer, socket write error错误原因

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

上次写《connection reset by peer, socket write error问题排查》已经过去大半年，当时把问题“敷衍”过去了。

但是此后每隔一段时间就会又想起来，baidu、google一番，可能也会再拉周围的人小讨论一下，然后无果而终。淡忘，想起，淡忘，又想起，挥之不去。

这个周末它又在脑海中浮现，这次总算理解了这个问题，答案就在一本买了很久的新书《HTTP权威指南》中。如果懒得看下面的啰嗦，可以去直接看书中的《4.7.4 正常关闭连接》章节。实际上，我也只是为了找答案直接通过目录翻到了这一章，以后再找时间完整看一遍吧。

问题现象

再重新描述一下这个问题的现象和起因。

问题来源于一个http的文件上传接口，接口会先对一些参数签名进行校验，参数签名通过之后才会取出InputStream，将文件数据保存起来。如果参数校验失败或者检查到文件已经存在（参数上会带md5），则直接返回了错误信息。

实际上大多数情况挺正常的，但是偶尔在客户端会出现“connection reset by peer, socket write error”。这个错误通过搜索引擎找了答案，都不能解释遇到的现象，只有尝试着猜测和重现了。经过尝试发现，只有比较“大”的文件在参数校验失败或者属于重复上传的情况才能重现这个错误。

所以猜测应该是当客户端上传大文件时，服务端接收到了http header就拿到了接口参数，可以开始进行校验了，不符合条件时就直接返回了Response，关闭OutputStream的同时也把InputStream给close掉了。

基于此猜测，在服务端改动了一下，返回Response之前，先request.getInputStream().skip(request.getContentLength)。果然。问题不会出现了，虽然接口处理变慢了。

然后，我通过wireshark进行了抓包，实际上也抓到了服务端返回的错误码信息，也就是说服务端在这个情况下，Response已经输出了，而且很可能客户端是收到了的。

这个是令人比较矛盾的地方，并不是服务端数据没有输出啊，为什么客户端接收不到这个响应，而且是直接报了一个奇怪的错误呢？

翻了书之后，才弄清楚了其中的细节，细节是魔鬼啊。

关于连接的关闭

TCP连接是双向的，TCP连接的每一端都有一个输入队列和一个输出队列，用于数据的读或者写。

放入一端输出队列的数据会被传送到另一端的输入队列。

Recv-Q 输入<-------------------------------------------------输出 Send-Q Client ------------------------------------------------------- Server Send-Q 输出------------------------------------------------->输入 Recv-Q

连接的全关闭和半关闭

当应用程序的通过TCP通信时，Client端和Server端都可以关闭输入和输出信道中的某一个，或者两个都关闭。

如果只关闭其中的一个，称之为“半关闭”，如果两个都关闭，称之为“全关闭”。

这两种操作对应java里的Socket有相应的方法，shutdownInput()或者shutdownOutput()是半关闭操作，close()是全关闭操作。

connection reset错误的产生

可以看到不论是对于客户端还是服务端，发送数据（输出信道）总是主动的，而接受数据（输入信道）总是被动的。

当主动发送数据的一方完成数据发送，进行shutdownOutput之后，另一方的接受端在从缓冲区读出所有数据后会收到一条通知，说明数据流结束了，这样接受端就知道连接关闭了。
但是反过来，如果被动接收数据的一方想要停止接收数据，也就是shutdownInput时，它并不知道数据发送方是否还要发送数据；

当接收端直接shutdownInput时，数据发送方却可能还在往缓冲区写数据呢，如果这个时候对方关闭连接的通知还没有到达这边，那么数据依然会被传送到已经shutdownInput另一端，这个时候另一端的操作系统会回复一条“连接被对方重置”的报文过去。

当数据发送方出现这种情况时，大多数操作系统都会作为很严重的错误来处理，会删除掉对端还未读取的所有缓存数据。

所以我们可以看到关于连接关闭存在3种情况(从某一端的角度)：

完全关闭：直接关闭输入和输出
半关闭(Output)：关闭输出，
半关闭(Input)：关闭输入

从上面的分析也可以看到，只有关闭输出是两端各自可以掌握主动权的，也就是相对安全的。

正常关闭

HTTP规范只是建议了在要关闭一条连接时应该正常的关闭传输连接，但是没有说明具体该如何去做。

由于只有输出端是自己可以掌握主动权的，所以要想正常的关闭连接首先是各自关闭自己的输出信道，同时等对方关闭输出信道，这样连接就完全关闭了，这样就不会出现“connecton reset”错误了。

但是，理想是美好的，现实中可能会比较无奈，无法确保双方都按照这个约定来操作。

所以除了做好自己这一方的关闭输出信道外，还需要周期性检查一下输入信道（对应于对方的输出）状态（是否还有数据，是否到了流的末尾），如果经过一定时间对方没有关闭还是需要强制结束以节省时间。

解决问题

问题的原因清楚了。回头看看文件上传接口的场景，就是服务端数据接收的一方在客户端方处于发送数据的时候强制关闭了连接，也就造成了客户端“connection reset”的错误。

那为什么小文件在同样的场景下没问题呢？因为小文件数据量小，在服务端关闭连接时就已经传输完成了。

那怎么解决大文件情况下的问题呢？貌似这个场景下没办法！因为服务端不应该在参数校验不通过的情况下等着客户端的数据流发送完，否则（实际上一开始说的临时解决办法skip真个content-length长度）就可能遇到可能安全问题（如果接口部署在局域网关系倒不大；如果部署在开放的互联网环境下，那就危险了，也就是如果不怀好意的人拿几个超大的文件少量的并发调用接口就可以把宝贵的带宽给占据了）。

既然技术角度无法解决了，只有从业务的角度来解决这个问题了。可以将这个文件上传接口拆分为两个接口，一个上传token生成接口，一个数据上传接口。token生成接口负责参数校验，如果校验成功则返回一个临时token，客户端用拿到的token再去上传数据。这样对于正常的调用方客户端应该不会再有问题，而对于非法的token不接收数据就很合理了。