为了解决TIME_WAIT问题的参数优化
提到TIME_WAIT就不得不提MSL:即Maximum Segment Lifetime,最大报文生存时间,和TTL相似,TTL是IP头中的,是一个设置的初始值,每过一个网络节点-1,0的时候数据报被丢弃。2MSL是为了解决发起连接关闭方回复最后一个fin 的ack,为避免对方ack 收不到、重发的或还在中间路由上的fin 把新连接给干掉了
- tw_reuse,tw_recycle 必须在客户端和服务端timestamps 开启时才管用(默认打开)
- tw_reuse 只对客户端起作用,开启后客户端在1s内回收
- tw_recycle 对客户端和服务器同时起作用
对于客户端
- 作为客户端因为有端口65535问题,TIME_OUT过多直接影响处理能力,打开tw_reuse 即可解决,不建议同时打开tw_recycle,帮助不大。
- tw_reuse 帮助客户端1s完成连接回收,基本可实现单机6w/s请求,需要再高就增加IP数量吧。
- 如果内网压测场景,且客户端不需要接收连接,同时tw_recycle 会有一点点好处。
- 业务上也可以设计由服务端主动关闭连接
对于服务端
- 打开tw_reuse无效
- 线上环境 tw_recycle 不要打开 因为一般的服务器、客户端都在NAT之后公网服务打开就可能造成部分连接失败,内网的话到时可以视情况打开;像我所在公司对外服务都放在负载后面,负载会把timestamp 都给清空,好吧,就算你打开也不起作用。
- 服务器TIME_WAIT 高怎么办
不像客户端有端口限制,处理大量TIME_WAIT Linux已经优化很好了,每个处于TIME_WAIT 状态下连接内存消耗很少,而且也能通过tcp_max_tw_buckets =100000 解决(这个值根据TIME_WAIT数量定),现代机器一般也不缺这点内存。
#客户端
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse=1 #系统默认0。当服务器当为客户端时有效(如反向代理访问后端),开启后客户端在1s内回收
net.ipv4.tcp_tw_recycle=0 #系统默认0。可关闭,但要调大tcp_max_tw_buckets,使用内存来支撑
#服务器端
net.ipv4.tcp_timestamps = 1 #系统默认1。会在tcp包头部记录时间戳。
net.ipv4.tcp_tw_recycle=0 #系统默认0。可关闭,但要调大tcp_max_tw_buckets,使用内存来支撑
net.ipv4.tcp_max_tw_buckets=655350