Java.io.IOException: Connection reset by peer问题定位

相信不少兄弟都碰到过这类问题。很不幸，今天本人负责的一个系统突然大量出现该类错误，本身系统没有做修改。

一般第一眼看到这类错误基本上就可以确定是本系统作为服务端跟客服端的长链断了并进行了重连，但是是跟那条链路呢？由于报错中一点链路信息都没带，就仅仅抛出了一个异常给问题定位带来了不小困难。经过跟同事的讨论最终的定位方式如下：

（1）首先我们可以确保该问题是由于长链路重置导致，也就是说肯定有一条本来是长链的链路在不断的重置，因此重置链路肯定会导致客户端的端口发生变化，因此，我们首先需要确认所有存在长链的端口，并获取跟该端口所建的长链。

netstat -an |grep port<端口号> | sort > port_time1.txt

（2）获取所有该端口下所有的外部链接，因为链接在不断重置，因此过5分钟（时间可以自己根据时间情况定）后再次执行第（1）步骤的命令并把结果输出到文件

netstat -an |grep port<端口号> | sort > port_time1.txt

（3）比较port_time1.txt 和 port_time2两个文件，找出客户端端口在不断变化的链路的地址。

（4）这样，通过上述三步我们就能获取发生链路重置的的IP地址，但是不幸的是我获取到的地址是一个F5的地址，并不是真实的服务器地址，因此无法确认发生链路重置的具体服务器。

（5）为了进一步确认到底是那台服务器发生链路重置，我们查看了一下这台F5后面的挂的所有服务器，发现有一部分已经跟我的系统建立了链路（注意：此处是F5后面的服务器直接跟我的系统建立链路，我grep获得地址是真实服务器的地址不是F5的地址），但是还有一部也跟我的系统建立了链路，但是我grep时并没有发现这一部分服务器对应的IP，这样我们可以确认这一部分服务并没有直接跟我的系统建立链路而是通过F5跟我建立的链路。

（6）这样就比较奇怪了，为什么同一台F5下面的服务有的是直接跟我的系统建立的链路有的却是通过F5跟我系统建立的链路呢，这个只有一种解释那就是通过F5同我系统建链的这部服务器的路由跟直接跟我建链的服务器的主机路由是不一样的。因此我们分别登陆到两类服务器上查看其主机路由：

netstat -rn

发现果然那部分通过F5跟我系统建链的服务的主机路由直接配置到了F5上而不是通过转换机到我的应用。

（7）这样基本上可以确定原因了，由于那部分服务器是通过F5跟我应用建立的链路，因此这部分服务的“心跳”包能够通过F5透传到我的应用上，但是我应用的“心跳”包却无法通过F5发送到对应的服务，从而导致客户端断链重连。