linux的TCP超时重传--一次数据断开连接分析

最近生产上发现一个问题，刚开始，应用连接数据库正常，如果长时间没有业务估计半小时以上，再发起业务时，

发现应用重连不上数据库，一直挂在重连那里，如果重启应用又能很快连上数据库（数据库是Oracle)。后来经数

据库专家的同学看了后，发现我们的生产是RAC的，而客户端配置了TAF，导致在发生会话切换的时候，可能原

来的连接没有释放好，影响了重连。把Oracle客户端的TAF关掉，重连的问题解决了。但又出现了一个很奇怪的

现象，就是今天要说的重点问题，如果长时间没业务的时候还是断，而且断了后执行SQL要15分钟左右应用才能

返回，这将导致应用在15分钟内不能服务，应用返回的错误是 ORA-03113: end-of-file on communication channel

从这个错误看，应该是Oracle客户端返回了连接断开的错误，但是为什么要15分钟后才返回这个错误呢？

机器的网络情况如下：

应用主机A ----> FW1(防火墙1) ---->FW2（防火墙2) ----> 数据库主机(OracleDB)

后来经网络专家的同学判断，有可能是防火墙设置了会话超时，如果长时间一个会话上没有数据防火墙就会删除

会话，同时网上也有人遇到类似的情况：

我们做了类似的尝试，放开防火墙的时间限制后，问题没再出现。但是还有几个疑问没有解决：

1.为什么防火墙删除会话后，主机要等15分钟?

2.防火墙删除会话后，会不会通知主机（给主机发RST)?

早上和同事讨论，猜测是由于防火墙删除了会话，但主机并不知道，有数据库操作的时候，由Oracle客户端

发起TCP请求，但由于防火墙找不到会话，丢弃了这些包（目前是不是丢还不清楚），导致了TCP不停地超时

重发。

查看TCP/IP详解第一卷的21章节21.2节，都超时重发有这样的描述：

这里提到9分钟，不过这本书写得比较早，猜测linux有所不一样，不过原理差不了太多，google了一下，

好像找到了15分钟的说法, 参考资料[1]中提到：

TCP_RTO_MIN=(HZ/5)=0.2s
TCP_RTO_MAX=(120*HZ)=120s
linear_backoff_thresh = ilog2(120*5)=ilog2(0x258)=9
timeout：未超过linear_backoff_thresh=9的部分按TCP_RTO_MIN 2的指数倍增长，超过的部分按TCP_RTO_MAX线性增长
tcp_time_stamp：当前时钟时间
例如数据发送阶段，sysctl_tcp_retries2=9，则timeout=1023*TCP_RTO_MIN=204.6s；sysctl_tcp_retries2=11时，timeout=1023*TCP_RTO_MIN+2*TCP_RTO_MAX=448.6s
默认sysctl_tcp_retries2=15，timeout=1023*TCP_RTO_MIN+6*TCP_RTO_MAX=920.6s，约15分钟

是根据RTO及一定的算法算出来的（具体的算法，可以看参考资料[3])

简单说，就是如果系统配置重传次数小于9的话，就是指数增长时间，如果大于9的话，就是最大超时时间。

而linux默认是15，所以刚好是15分钟，查看我们主机的配置，确认是15：

[steven@kfjk2 ~]$ cat /proc/sys/net/ipv4/tcp_retries2
15

现在还有一个问题没弄清楚，就是防火墙删除会话后，是否会通知主机？现在看起来应该是不会的，至少在主机上是没收到

防火墙的RST，由于两个防火墙的两个厂商不一样，也有可能是一个吃掉另外一个的包也说不定。假如删除会话后，在原来

的会话上来有包上来，是重建会话呢？还是直接把包丢弃？还是发RST呢？从目前主机的现象来看，猜测是：

防火墙删除会话后，不会通知主机也就是不会给主机发RST，当有新包上来，找不到连接，但不是S包的时候，直接丢弃，

导致主机用完了重发次数后，自己发RST后给应用报断开连接。

不过。。。以上的东东都是根据现象来猜测的，最有效的办法是捉出tcpdump包来看，但由于是生产不敢乱动，也先这样吧！

仅以此记，为避免以后踩坑，同时开发人员也要关心网络部署，当时我并没有考虑中间有两个防火墙。

【参考资料】

1. linux TCP超时重传
2. 【探讨】linux下的tcp协议栈超时重传机制
3. TCP/IP重传超时--RTO