TCP连接TIME-WAIT
2016-11-28 15:45
120 查看
如下是一系列相关linux参数设置:
cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000
cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1024
cat /proc/sys/net/ipv4/tcp_syn_retries 5
cat /proc/sys/net/ipv4/tcp_max_tw_buckets 180000
cat /proc/sys/net/ipv4/tcp_tw_recycle 0
cat /proc/sys/net/ipv4/tcp_tw_reuse 0
设置方法:sysctl -w net.ipv4.tcp_timestamps=1
ip_local_port_range目标服务器支持的tpc端口后范围,可以设置大一点
tcp_max_tw_buckets同时处于TIME-WAIT的tcp最大连接数
tcp_timestamps 是否开启tcp TIME-WAIT时间戳记录,默认开启,1
tcp_tw_recycle是否快速回收,1是开启
通常需要设置
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_recycle=1
这样nginx发起的大量http请求会被快速回收
但是要注意一点,在nat环境下不能设置net.ipv4.tcp_tw_recycle=1,因为时间戳混乱会造成正常请求被切断
在nat模式下(服务器一般会用到dnat,用户一般会用到snat),nat设备(or服务器)会修改目的ip和源ip,以屏蔽内部信息。试想很多用户snat出来,通过dnat访问网站,在dnat这层,时而会产生时间戳错乱的问题,那么基于tcp的时间戳的tcp_tw_recycle,就会出错
tcp会记录每个连接的时间戳,如果后续时间戳比之前记录的时间戳小,就会认为这是错误的连接,拒绝这个连接。如果tcp_tw_recycle开启,那么这种规则就会被激活(那样才能快速回收连接)。所以在lvs使用nat的情况下,用户请求到lvs,LVS会修改地址数据后将请求转发给后端服务器,但不会修改时间戳(因为nat的机制就是只修改源地址和目的地址)。在后端服务器看来,请求的源地址永远都是LVS的地址,并且端口复用,原本不同客户端的请求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,还可以通过下面命令来确认数据包不断被丢弃的现象。就会出现部分用户能连接服务器,部分用户不能连接服务器的情况
相关文章推荐
- 服务器tcp连接timewait过多优化及详细分析
- 修改Linux内核参数,减少TCP连接中的TIME-WAIT
- TCP连接状态分析:SYNC_RECV,CLOSE_WAIT,TIME_WAIT
- 减少tcp连接中的time_wait
- Linux网络tcp连接大量CLOSE_WAIT和TIME_WAIT状态的出现和解决方法
- 通讯系统经验谈【一】TCP连接状态分析:SYNC_RECV,CLOSE_WAIT,TIME_WAIT
- TCP 连接关闭的 TIME_WAIT (2MSL) 状态,及 TCP 连接状态图
- 优化内核参数,减少TCP连接中的TIME_WAIT(经典)
- tcp短连接TIME_WAIT问题解决方法大全(3)——tcp_tw_recycle
- 网络编程(25)—— 详解TCPIP断开连接后的Time-wait状态
- TCP连接状态分析:SYNC_RECV,CLOSE_WAIT,TIME_WAIT
- tcp短连接TIME_WAIT问题解决方法大全(2)——SO_LINGER
- TCP连接的TIME_WAIT过多导致 Tomcat 假死
- 一个解除TCP连接的TIME_WAIT状态限制的简便方法
- TCP连接中TIME_WAIT连接过多
- tcp短连接TIME_WAIT问题解决方法大全(1)——高屋建瓴
- 一个解除TCP连接的TIME_WAIT状态限制的简便方法
- 一个解除TCP连接的TIME_WAIT状态限制的简便方法
- TCP关闭连接(为什么会能Time_wait,Close_wait?)
- TCP关闭连接(为什么会能Time_wait,Close_wait?)