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