[20200312]不要设置net.ipv4.tcp_tw_recycle=1.txt，

[20200312]不要设置net.ipv4.tcp_tw_recycle=1.txt，

[20200312]不要设置net.ipv4.tcp_tw_recycle=1.txt

--//昨天认真看了2篇blog：
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
--//中文翻译：
http://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle/

--//里面提到不要设置net.ipv4.tcp_tw_recycle=1。TIME_WAIT状态问题不是太严重，可以完全不理会它。
--//我仔细阅读，说真的许多一些细节还不是很理解。我开始接触主要是不理解生产系统rac环境为什么这么多state=TIME_WAIT.
--//现在看来自己纯粹是画蛇添足，浪费时间,不过自己感觉还是学到许多东西.

--//现在我大概知道原因,做一些总结：

1.实际上对于正常数据库应用，正常退出应用程序，实际上state=TIME_WAIT发生在客户端，这也是我开始的困惑。服务端不应该这个多
  state=TIME_WAIT。我的问题实际上由此展开^_^.

https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

TCP state diagram

Only the end closing the connection first will reach the TIME-WAIT state. The other end will follow a path which usually
permits to quickly get rid of the connection.
--//只有先关闭连接的结束才会达到TIME-WAIT状态.. 另一端将沿着通常允许快速摆脱连接。

2.我们使用dblink短连接很多，这时服务端实际上变成客户端，导致state=TIME_WAIT多。

3.exadata 出厂设置 net.ipv4.tcp_timestamps = 0，即使我设置net.ipv4.tcp_tw_recycle=1也无效，毫无作用，这也是我在测试中遇
  到的第二个困惑。我想oracle这样做可能有它的道理, 不会使用特殊的方式规避其它dba设置net.ipv4.tcp_tw_recycle=1的问题。

--//exadate 的 /etc/sysctl.conf设置,不知道前面# 12650500 ,oracle内部表示什么?
# 12650500
net.ipv4.tcp_timestamps = 0

--//再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1 解决大量state=TIME_WAIT问题。

4.还有1个原因导致服务端state=TIME_WAIT增多,就是客户端连接RAC数据库使用scan ip,会跳转到vip ip，这样一旦大量用户以这种方式
  登录，就是在服务端产生大量的state=TIME_WAIT连接。

5.还有前台客户端基本都是XP机器。我的测试MS关于tcp_timestamps缺省设置是关闭的，至少在windows 7，windows 2003服务器版下,XP
  我不知道。
 
这样即使服务端设置  net.ipv4.tcp_timestamps = 1 和 net.ipv4.tcp_tw_recycle=1 依旧在服务端生产大量的state=TIME_WAIT.
不过linux机器缺省设置都是net.ipv4.tcp_timestamps = 1。

--//再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1 解决大量state=TIME_WAIT问题。  
--//注：我在这里测试时又犯了一个错误，以为跨网段的机器不能快速回收TIME_WAIT，实际上是我的测试机器windows7的
--//tcp_timestamps缺省设置是关闭的.

6.有一个可行的方法减少大量state=TIME_WAIT连接,就是在一些中间件服务器可以不要使用scan ip连接数据库，采用老的vip ip就可以
  减少这样的情况。改动涉及中间件服务器，影响不大,这是比较可行成本最低的改进方法,仅仅对rac环境有效.

--//话又反活来讲,如果不是rac环境,可能就看不到大量的state=TIME_WAIT状态.

7.如果网络链接通过公网或者NAT转换，肯定不能设置net.ipv4.tcp_tw_recycle=1. 由于我们一些应用通过公网，当我设置
  net.ipv4.tcp_tw_recycle=1
  net.ipv4.tcp_timestamps=1
--//确实有少量的客户端(实际上也就2台)无法连接服务器的情况，甚至内网的机器也出现一台，我不知道为什么。最终还原原来设置
  net.ipv4.tcp_tw_recycle=0
  net.ipv4.tcp_timestamps=0

8.内存 CPU 资源消耗很少。参考链接的测试：https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

9.state=TIME_WAIT对应用影响很小，4元素组成一个连接，oracle 建议内核参数设置net.ipv4.ip_local_port_range = 1024 65000
  支持端口数量达到64000，这样如果不达到每秒60000/60 = 1000 个/连接，基本影响可以忽略。

  我感觉不能达到这个数量，至少我自己没见过。我们数据库高峰也就是200个/每秒连接。

10.TIME_WAIT状态的消失时间在linux下写死的,在net/tcp.h头文件里面的,许多链接提示修改net.ipv4.tcp_fin_timeout是错误的:
--//除非修改头文件内容,重新编译内核!!
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                  * state, about 60 seconds */
#define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN
                                 /* BSD style FIN_WAIT2 deadlock breaker.
                  * It used to be 3min, new value is 60sec,
                  * to combine FIN-WAIT-2 timeout with
                  * TIME-WAIT timer.
                  */

11.windows下可以修改TIME_WAIT状态的消失时间:
--//在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，值
--//就是秒数，最小30秒,不能低于该值.注要重启机器才能生效:
--//timewait.reg
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

12.windows下设置tcp_timestamps:
--//按照https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938205(v=technet.10)?redirectedfrom=MSDN
Tcp1323Opts
--//注:1323 应该是关联RFC 1323文档.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type  Range            Default value
------------------------------------------
REG_DWORD  0 | 1 | 2 | 3    3

Value  Meaning
0 (00) Timestamps and window scaling are disabled.
1 (01) Window scaling is enabled.
2 (10) Timestamps are enabled.
3 (11) Timestamps and window scaling are enabled.

--//按照介绍MS缺省应该是打开tcp_timestamps的。不过我发现在windows 7,windows 2003下不是这样。修改为2或者3.我仅仅测试修改3
--//的情况.
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=hex:03

13.最后简单讲一下测试方法,使用tnsping server_ip count > /dev/null,这样比较简单快捷,这时state=TIME_WAIT出现在服务端,使用
   netstat -ntop 或者ss -nto 观察.

# seq 10000 | xargs -IQ bash -c "ss -tano state time-wait | ts.awk ; sleep 1"
or
# seq 10000 | xargs -IQ bash -c "netstat -nto | grep TIME-WAIT | ts.awk ; sleep 1"

$ cat $(which ts.awk)
# /bin/bash
gawk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0 }'

在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客户端net.ipv4.tcp_timestamps=1的情况下服务端出现TIME_WAIT很快消失.
在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客户端net.ipv4.tcp_timestamps=0的情况下服务端出现TIME_WAIT等60秒消失.
在服务端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=0,                                       服务端出现TIME_WAIT等60秒消失.
在服务端net.ipv4.tcp_tw_recycle=0,net.ipv4.tcp_timestamps=N(N=1,0)                                 服务端出现TIME_WAIT等60秒消失.

--//大家可以自行测试.测试结果就不贴上来了,有点繁琐.
--//从这里也看出如果大量的客户端是windows，没有打开tcp_timestamp,在服务端设置
--//net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1也一样毫无用处.

14.演示一个服务端产生大量TIME_WAIT的例子:
--//还是另外写一篇,不然写的又太长了.

--//最后再次提醒建议不要设置net.ipv4.tcp_tw_recycle=1来解决大量state=TIME_WAIT问题,重要的问题说三遍，国内大量的链接这样
--//做可能会导致一些网络故障非常难查，除非应用都是非常纯的内网环境里面。