记一次排查arex_exporter read time_out

记一次排查TCP read time_out

现象：ares是我们公司自己开发的一个服务，生产ares—exporter每天不定时报报错，报错信息如下

java.net.SocketTimeoutException: Read timed out

排查思路：在测试环境重现，两边抓包，判断是ares发包问题，还是网络问题，还是exporter读取的问题

ares方面错误的TCP流

ares方面正确的TCP流

export方面正确的TCP流

exporter方面错误的TCP流

在分析TCP流前，先复习一下TCP的三次握手和四次挥手

注：seq:"sequance"序列号；ack:"acknowledge"确认号；SYN:"synchronize"请求同步标志；；ACK:“acknowledge"确认标志”**；**FIN："Finally"结束标志。

**TCP连接建立过程：**首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

**TCP连接断开过程：**假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，“告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，“就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。”，Server端收到ACK后，“就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

为什么要三次握手？

在只有两次"握手"的情形下，假设Client想跟Server建立连接，但是却因为中途连接请求的数据报丢失了，故Client端不得不重新发送一遍；这个时候Server端仅收到一个连接请求，因此可以正常的建立连接。但是，有时候Client端重新发送请求不是因为数据报丢失了，而是有可能数据传输过程因为网络并发量很大在某结点被阻塞了，这种情形下Server端将先后收到2次请求，并持续等待两个Client请求向他发送数据…问题就在这里，Cient端实际上只有一次请求，而Server端却有2个响应，极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待，因而造成极大的资源浪费！所以，"三次握手"很有必要！

为什么要四次挥手？

试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，并等待Server的回复。但事情还没有完，虽然你自身不往Server发送数据了，但是因为你们之前已经建立好平等的连接了，所以此时他也有主动权向你发送数据；故Server端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证双方的一个合约的完整执行！

可以看到，正确的和错误的TCP流完全都符合这个过程。也不存在高网络延迟

出问题的地方在哪！

注意看ares返回fin包的时间，在发完数据包之后足足一秒多。

正常TCP流ares发送完数据包，应该马上就发送fin包。延迟发包的结果就是exporter不知道你已经发完了数据，一直在等待你发完数据再读取，exporter设置的读取超时时间是1秒，当最后一次收到ares发送数据开始计时，直到读完数据。但是socket里面的逻辑会一直等到你发fin包，才会一次性完整的读取数据。

所以当ares发送完数据包返回fin包的时间，迟了超过一秒后，exporter就会报read timeout

后经排查ares，发现它发送TCP和磁盘操作使用的是一个线程，当它向磁盘中持久化数据时，发送tcp包就会被堵住，就会出现发送fin包延迟的情况。

盘操作使用的是一个线程，当它向磁盘中持久化数据时，发送tcp包就会被堵住，就会出现发送fin包延迟的情况。

暂时性解决问题的办法是调整延时时间为3秒，后续看是否有优化代码的方法。