##【问题描述】

开发反馈有个应用在后端数据库某次计划性重启后经常会出现数据库连接异常问题，通过监控系统的埋点数据，发现应用连接数据库异常有两类表现：   其一：连接超时   131148.00ms Tomcat Connection Pool   其二：连接耗时过长   DAL.getConnectionCost 64018ms

##【问题分析】

通过监控数据汇总，出现此异常问题来自应用群集中的多台WEB服务器，没有规律性，数据库服务器也没有做过系统版本升级及硬件调整，且数据库各主要性能指标正常，负载很低。因此最大可疑是网络通讯上的异常导致，于是通过客户端/服务器端同时抓包进行分析。

分析后，发现数据包中有许多TCP Retransmission

六次重连失败样例： 五次重连失败，第六次连接成功样例：

TCP SYN重传次数与请求端的tcp_syn_retries参数值有关，本案例中应用WEB服务器设置为6（查看命令：sudo sysctl -a | grep tcp_syn_retries），即重试的间隔时间从1s开始每次都翻倍，6次的重试时间间隔为1s, 2s, 4s, 8s,16s,32S总共63s，第6次发出后还要等64s才知道第6次也超时了，所以总共需要 1s + 2s + 4s+ 8s+ 16s + 32s+64S =127S，TCP才会断开连接。

因此上述问题描述中   “连接超时”计算公式为：1s + 2s + 4s+ 8s+ 16s + 32s+64S =127S   “建连耗时”计算公式与实际重试次数有关，以5次重试为例：1s + 2s + 4s+ 8s+ 16s + 32s=63S

查询资料得知TCP Retransmission问题很大可能与tcp_tw_recycle设置有关，在此参数开启后，服务端会对TCP包中timestamp有效性进行校验，数据包中的timestamp理应是顺序递增，如最新的数据包timestamp小于前一个包的timestamp，服务端则认为最新的数据包已过时从而丢弃，此问题常出现在NAT网络，如负载均衡设备后面，因为数据包经过转发，source_ip相同，但是后端不同机器的timestamp不同。

检查数据库服务器配置，发现tcp_tw_recycle功能被开启，同时网卡统计中存在因为时间戳被拒的数据包信息

netstat -s |grep reject 251286 passive connections rejected because of time stamp 795 packets rejects in established connections because of timestamp

关闭tcp_tw_recycle功能后，应用连接数据库恢复正常。本案例中为何数据库服务器重启后应用报错，那是因为参数先前只是做了动态关闭，没有修改配置文件固化，重启后读到旧的配置从而导致应用突然报错。

##【问题重现】 本案例中的应用服务器与后端数据库直连，并不在NAT网络中，那理论上特定机器发送给DB的TCP包中timestamp数值是递增，不会出现乱序丢包问题，但实际抓包中的timestamp是乱序的，忽大忽小，没有规律性。

在不同Kernel版本环境中模拟用户请求，发现在不同内核环境中，timestamp行为有明显差异 Kernel 4.10.13，TSecr（请求方timestamp）随机 Kernel 3.10，TSecr（请求方timestamp）递增

查询资料发现timestamp生成算法在linux kernel 4.10之后进行了调整，加入偏移因子，从而变为随机性。因此如开启了tcp_tw_recycle，即使在非NAT网络环境中也会出现丢包问题，tcp_tw_recycle的弊端更为突显，因此在4.12内核中被移除

##【结论】 tcp_tw_recycle在高版本内核中弊大于利，应保持系统默认设置，关闭参数。

##【参考资料】

https://mp.weixin.qq.com/s/uwykopNnkcRL5JXTVufyBw http://80x86.io/post/linux-kernel-v4.10.1-tcp-timestamps-random-offset-problem