Connection reset具体的解决方案有如下几种：1、出错了重试；2、客户端和服务器统一使用TCP长连接；3、客户端和服务器统一使用TCP短连接。
首先是出错了重试：这种方案可以简单防止“Connection reset”错误，然后如果服务不是“幂等”的则不能使用该方法；比如提交订单操作就不是幂等的，如果使用重试则可能造成重复提单。然后是客户端和服务器统一使用TCP长连接：客户端使用TCP长连接很容易配置（直接设置HttpClient就好），而服务器配置长连接就比较麻烦了，就拿tomcat来说，需要设置tomcat的maxKeepAliveRequests、connectionTimeout等参数。另外如果使用了nginx进行反向代理或负载均衡，此时也需要配置nginx以支持长连接（nginx默认是对客户端使用长连接，对服务器使用短连接）。
使用长连接可以避免每次建立TCP连接的三次握手而节约一定的时间，但是我这边由于是内网，客户端和服务器的3次握手很快，大约只需1ms。ping一下大约0.93ms（一次往返）；三次握手也是一次往返（第三次握手不用返回）。根据80/20原理，1ms可以忽略不计；又考虑到长连接的扩展性不如短连接好、修改nginx和tomcat的配置代价很大（所有后台服务都需要修改）；所以这里并没有使用长连接。最后的解决方案是客户端和服务器统一使用TCP短连接：我这边正是这么干的，而使用短连接既不用改nginx配置，也不用改tomcat配置，只需在使用HttpClient时使用http1.0协议并增加http请求的header信息（Connection: Close），源码如下：
httpGet.setProtocolVersion(HttpVersion.HTTP_1_0);
httpGet.addHeader(HTTP.CONN_DIRECTIVE, HTTP.CONN_CLOSE);
最后再补充几句，虽然对于每次请求TCP长连接只能节约大约1ms的时间，但是具体是使用长连接还是短连接还是要衡量下，比如你的服务每天的pv是1亿，那么使用长连接节约的总时间为：1亿*1ms=10^8*1ms=10^5*1s=27.78h
神奇的是，亿万级pv的服务使用长连接一天内节约的总时间为27.78小时（竟然大于一天），所以使用长连接还是短连接大家需要根据自己的服务访问量、扩展性等因素衡量下。但是一定要注意：服务器和客户端的连接一定要保持一致，要么都是长连接，要么都是短连接。
扩展资料：
引起connection reset该异常的原因有两个：1，如果一端的Socket被关闭（或主动关闭，或因为异常退出而 引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect reset by peer)。
2，一端退出，但退出时并未关闭该连接，另一端如果在从连接中读数据则抛出该异常（Connection reset）。简单的说就是在连接断开后的读和写操作引起的。
还有一种比较常见的错误“Connection reset by peer”，该错误和“Connection reset”是有区别的：服务器返回了“RST”时，如果此时客户端正在从Socket套接字的输出流中读数据则会提示Connection reset”；服务器返回了“RST”时，如果此时客户端正在往Socket套接字的输入流中写数据则会提示“Connection reset by peer”。
