参考
TCP_TW_RECYCLE
It enables fast recycling of TIME_WAIT sockets. ... Known to cause some issues with hoststated (load balancing and fail over) if enabled, should be used with caution.
TCP_TW_REUSE
This allows reusing sockets in TIME_WAIT state for new connections when it is safe from protocol viewpoint. Default value is 0 (disabled). It is generally a safer alternative to tcp_tw_recycle
Note: The tcp_tw_reuse setting is particularly useful in environments where numerous short connections are open and left in TIME_WAIT state, such as web servers. Reusing the sockets can be very effective in reducing server load.
NOTE:
net.ipv4.tcp_tw_recyclehas been removed from Linux 4.12.
SOURCE: https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux
我看到ubuntu18.04版本是linux 4.15
使用TIME_WAIT导致的错误后果
**
若TIME_WAIT事件设置过短, 会导致错误后果
TIME_WAIT结束过早, 导致之前迷失的第三次握手突然到达, 新连接突然成功
TIME_WAIT结束过早, 若最后的ACK丢失, 却过早结束TIME_WAIT, 导致新连接发起连接请求时, 旧连接还未关闭状态, 拒绝连接
小总结
- 最合适的解决方案是增加更多的四元组数目, 比如, 服务器可用端口, 或服务器IP, 让服务器能容纳足够多的TIME-WAIT状态连接。
- 在我们常见的互联网架构中(NGINX反代跟NGINX，NGINX跟FPM，FPM跟redis、mysql、memcache等), 减少TIME-WAIT状态的TCP连接，最有效的是使用长连接，不要用短连接, 尤其是负载均衡跟web服务器之间. 尤其是链家事件中的PHP连不上redis。
TCP_TW_RECYCLE分析1
在4.12之后的内核已移除tcp_tw_recycle内核参数:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc
TCP_TW_RECYCLE分析2
会快速回收socket
相较于tcp_tw_reuse只在需要时重用TIME_WAIT状态socket, tcp_tw_recycle处理更激进，它会快速回收TIME_WAIT状态的socket。
内核代码中有定时器来调用tcp_time_wait函数来处理TIME_WAIT状态的socket，函数源码如下:
(省略源码)
从代码上可以看到只有当tcp_timestamps和tcp_tw_recycle都开启时，才会快速回收。
回收时间
而根据代码:
const int rto = (icsk->icsk_rto << 2) - (icsk->icsk_rto >> 1);
可以看到回收的超时时间为3.5 * RTO, RTO是由TCP分段中timestamp选项计算得到的，一般场景下这个时间在几百毫秒左右。
可主动跳过TIME_WAIT
从上面的
tcp_time_wait源码也可以看出, 当TIME_WAIT状态的socket数量超过tcp_max_tw_buckets选项指定的数量值时，会直接关闭socket，进入CLOSED状态，内核日志中会报错:
TCP: time wait bucket table overflow
的错误。若把tcp_max_tw_buckets选项设置为0，则可以直接跳过TIME_WAIT状态。
NAT下服务端引发的问题
然而，tcp_tw_recycle选项在NAT环境使用有一些隐患，下面来分析一下。
协议栈收到syn包时会调用到函数tcp_v4_conn_request, 该函数部分源码如下:
(省略linux内核TCP源码)
从代码上我们可以看到，当开启tcp_timestamps和tcp_tw_recycle选项时，60秒内来自同一源IP主机的TCP分段的时间戳必须递增，否则该分段会被直接丢弃。
假如多个客户端从NAT环境访问服务器，服务器端看到的对端IP是一样的，但是TCP分段的时间戳会不一样。当时间戳较大的客户端连接成功后的60秒内，时间戳较小的客户端再次连接服务器，syn包会被服务器直接丢弃，导致连接失败。
tcp_tw_reuse
参考
- tcp_tw_reuse只在连接时起作用
-
被抛弃的tcp_recycle
tcp_tw_reuse设置的是内核变量sysctl_tcp_tw_reuse，而这个变量仅在tcp_twsk_unique函数中使用。而这个函数的调用路径有且仅有一个：tcp_v4_connect->inet_hash_connect->__inet_check_established->twsk_unique->twsk_unique。
// net/ipv4/tcp_ipv4.c
int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp)
{
/* ……省略…… */
if (tcptw->tw_ts_recent_stamp &&
(!twp || (sock_net(sk)->ipv4.sysctl_tcp_tw_reuse &&
get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
/* ……省略…… */
return 1;
}
return 0; }
- 也就是说
tcp_tw_reuse仅在TCP套接字作为客户端，调用connect时起作用。绝大部分的TCP服务器，应该不会有大量主动连接的动作（或许会连接DB等，但一般也是长连接）。因此这个选项对于TCP服务来说，基本上是无用的，完全是没必要打开，甚至可能还会给一些初级的运维工程师带来迷惑和干扰。 - 如果新的时间戳比之前存储的时间戳更大，那么Linux将会从TIME-WAIT状态的存活连接中选取一个，重新分配给新的连接出去的的TCP连接，这种情况下，TIME-WAIT的连接相当于只需要1秒就可以被复用了。
SO_LINGER和SO_REUSEADDR
这两个应该都是setsockopt的参数
https://blog.csdn.net/u012635648/article/details/80279338
SO_LINGER应该是设置TIME_WAIT时间, 超时则发送RST强行关闭-
https://zhuanlan.zhihu.com/p/31329253
后来查了查这个选项对应的linux内核参数是tcp_tw_reuse
SO_REUSEADDR对应tcp_tw_reuse
总结
tcp_tw_reuse和tcp_tw_recycle都需要通信双方开启net.ipv4.tcp_timestamps(默认开启的)
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟
假如是客户端-负载均衡nginx-服务端架构
- 对于服务端:
- tcp_tw_reuse没啥用, 因为是用于发起连接的
- tcp_tw_recycle不要用, 因为在NAT下会有问题
- 对于nginx:
- 以客户端身份连接服务端时, tcp_tw_reuse能回收端口, 可以考虑用, 但最好还是改成长连接.
- tcp_tw_recycle
常用的参数
net.ipv4.ip_local_port_range = 9000 6553 # 默认值范围较小
net.ipv4.tcp_max_tw_buckets = 10000 # 默认值较小，还可适当调小
net.ipv4.tcp_tw_reuse = 1 #
net.ipv4.tcp_fin_timeout = 10 #`
