为什么要提timewait，因为这是这两个参数的引出，相关博文：
21-ahttpclient 与TIME_WAIT 客户端close与服务端close
21Why httpclient is recommended to go with a connection pool in server-to-server request?
1 http://www.52im.net/thread-513-1-1.html
Again，使用tcp_tw_reuse和tcp_tw_recycle来解决TIME_WAIT的问题是非常非常危险的，（我们在17tcp close端口占用 & setReuseAddress 【本地】有过实践）因为这两个参数违反了TCP协议（RFC 1122）
其实，TIME_WAIT表示的是你主动断连接，所以，这就是所谓的“不作死不会死”。试想，如果让对端断连接，那么这个破问题就是对方的了，呵呵。另外，如果你的服务器是于HTTP服务器，那么设置一个HTTP的KeepAlive有多重要（浏览器会重用一个TCP连接来处理多个HTTP请求），然后让客户端去断链接（你要小心，浏览器可能会非常贪婪，他们不到万不得已不会主动断连接）。
2 两个事故
https://www.cnblogs.com/jdonson/p/4760166.html
lvs接入---> nginx ---> tomcat
这种机制在 客户端-服务器 一对一的时候，没有任何问题，但是当服务器在负载均衡器后面时，由于负载均衡器不会修改
包内部的timestamp值，而互联网上的机器又不可能保持时间的一致性，再加上负载均衡是会重复多次使用同一个tcp端口
向内部服务器发起连接的，就会导致什么情况呢：
负载均衡通过某个端口向内部的某台服务器发起连接，源地址为负载均衡的内部地址——同一ip
假如恰巧先后两次连接源端口相同（负载均衡作为客户端的端口），这台服务器先后收到两个包，第一个包的timestamp被服务器保存着，第二个包又来了，
一对比，发现第二个包的timestamp比第一个还老——客户端时间不一致。服务器基于PAWS，判断第二个包是重复报文，
丢弃之
反映出来的情况就是在服务器上抓包，发现有SYN包，但服务器就是不回ACK包，因为SYN包已经被丢弃了。为了验证这
一结果，可以执行netstat -s | grep timestamp 命令，看输出里面passive connections rejected by timestamp 一项的数字变化。
https://blog.csdn.net/zhuyiquan/article/details/68925707
当开启了tcp_tw_recycle选项后，当连接进入TIME_WAIT状态后，会记录对应远端主机最后到达分节的时间戳。如果同样的主机有新的分节到达，且时间戳小于之前记录的时间戳，即视为无效，相应的数据包会被丢弃
当负载均衡启用NAT模式时，客户端TCP请求到达负载均衡，修改目的地址（IP+端口号）后便转发给后端服务器，而客户端时间戳数据没有变化。对于后端Web Server，请求的源地址是负载均衡，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接，加之不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象，于是后面的数据包就被丢弃了
3
https://www.cnblogs.com/lulu/p/4149312.html
不像Windows 可以修改注册表修改2MSL 的值，linux 需要修改内核宏定义重新编译，tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2状态超时时间.
1. tw_reuse，tw_recycle 必须在客户端和服务端 timestamps 开启时才管用（默认打开）
2. tw_reuse 只对客户端起作用，开启后客户端在1s内回收
3. tw_recycle 对客户端和服务器同时起作用，开启后在 3.5*RTO 内回收，RTO 200ms~ 120s 具体时间视网络状况。
对于客户端
作为客户端因为有端口65535问题，TIME_OUT过多直接影响处理能力，打开tw_reuse 即可解决，不建议同时打开tw_recycle，帮助不大；
业务上也可以设计由服务端主动关闭连接。21-ahttpclient 与TIME_WAIT 客户端close与服务端close 也建议过由服务端close connection
对于服务端
不像客户端有端口限制，处理大量TIME_WAIT Linux已经优化很好了，每个处于TIME_WAIT 状态下连接内存消耗很少
而且也能通过tcp_max_tw_buckets = 262144 配置最大上限，现代机器一般也不缺这点内存。
也就是连接有谁关闭的那一方有time_wait问题，被关那方无此问题。
reuse、recycle 通过timestamp的递增性来区分是否新连接，新连接的timestamp更大，那么保证小的timestamp的 fin 不会fin掉新连接，不用等2MSL。
recycle 对于服务端，同一个src ip，可能会是NAT后很多机器，这些机器timestamp递增性无可保证，服务器会拒绝非递增请求连接。