一、系统环境
操作系统： Centos 6.4 64bit
zabbix-agent 版本： Zabbix agent v2.2.7 (revision 50148) (24 October 2014)
二、出现的问题
zabbix-agent机器上，发现TIME_WAIT过多
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59237 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59783 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59643 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59509 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59221 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59329 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59361 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59730 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59255 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59300 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59344 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59400 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59326 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59209 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59288 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59282 TIME_WAIT
tcp 0 0 xxx.xx.161.183:10050 xxx.xx.161.174:59418 TIME_WAIT
[root@ns_xxx.xx.161.183 ~]$ netstat -an |grep -i time|grep 10050|grep -v 5432|wc -l
89
三、为什么会出现这么多TIME_WAIT
下表说明了zabbix是如何通信的， 它会教给你基本的tcp协议的知识。如果你看不懂这个表的内容，我建议你可以读下<TCP/IP 详解1>！
表格中的state是TCP连接在agent和server不同阶段时的状态。我们假设每个阶段，agent和server都会得到正确的状态！
如果你用tcpdump捕获通信数据，你可以转储到文件，下载桌面，然后通过Wireshark 来查看！
passive agent通信的过程如下：
| Number | Connection state agent | Connection state server | Direction | TCP flags | Purpose of TCP segment |
|---|---|---|---|---|---|
| 1 | LISTEN | SYN_SENT | Agent<-Server | SYN | 初始化TCP连接，第一次tcp握手 |
| 2 | SYN_RECVD | SYN_SENT | Agent->Server | SYN, ACK | 接受连接 |
| 3 | SYN_RECVD | ESTABLISHED | Agent<-Server | ACK | 连接已经建立 |
| 4 | ESTABLISHED | ESTABLISHED | Agent<-Server | PSH, ACK | zabbix server发送item key 给agent |
| 5 | ESTABLISHED | ESTABLISHED | Agent->Server | ACK | Agent 确认收到 |
| 6 | ESTABLISHED | ESTABLISHED | Agent->Server | PSH, ACK | agent发送对应item key的数据 |
| 7 | FIN_WAIT_1 | ESTABLISHED | Agent->Server | FIN, PSH, ACK | 当没有其它数据要发送的时候， agent 关闭连接 |
| 8 | FIN_WAIT_1 | CLOSE_WAIT | Agent<-Server | ACK | |
| 9 | FIN_WAIT_2 | LAST_ACK | Agent<-Server | FIN, ACK | |
| 10 | TIME_WAIT | LAST_ACK | Agent->Server | ACK | 连接已经完全关闭 |
| 11 | CLOSED | CLOSED | - | - | 最终，两边的状态都为CLOSED |
- 1: tcp连接是通过socket通信的，每个socket都是为唯一的，address:port--address:port
- 2: 第二行的SYN/ACK如果没有发送，那么第一步的SYN会重新发送。在缺省的timeout设置中，如果丢了这个SYN/ACK过程，连接将会被重置(RST),并且这个获取数据的过程将会失败！
- 3: 当前的连接是全双工的工作模式
- 4: PUSH标志表明当前正在传送数据！
- 7: 没有其它事要做，关闭连接。在接下来的关闭过程中，agent会保留TIME_WAIT状态！请去看下TCP连接的3次握手，和TCP关闭的4次挥手过程。 这里并不是正确的连接关闭过程。
- 8: 带有FIN标志的数据报会被立刻确认，然后zabbix server 立刻知道这个连接已经关闭。
- 9: zabbix server确认连接关闭的时候，它也会立刻发送一个带FIN的数据包
- 10: 立刻确认第九步的FIN，到此为止，这个连接就关闭了！
- 11：passive zabbix agent的连接过程，并没有第十一步的数据报！当第十步中，server端确认连接关闭，并转变状态为closed之后， agent会把TIME_WAIT挂起两分钟。 这意味着这个连接在两分钟内是不可重用的。
注意：
使用TCP协议，是为了在不可靠的网络环境中创建可靠的连接！
zabbix并不支持UDP和长连接的方式(persistent connection)
四、解决方式
设置TIME_WAIT的重用
linux服务器，配置内核参数中的 net.ipv4.tcp_tw_recycle
/etc/sysctl.conf 添加下面的3行，然后执行sysctl -p
[root@ns_xxx.xx..161.182 ~]$ tail -4 /etc/sysctl.conf
# tcp连接保持时间为1800秒
net.ipv4.tcp_keepalive_time = 1800
# 回收TIME_WAIT占用的连接
net.ipv4.tcp_tw_recycle = 1
[root@ns_xxx.xx..161.182 ~]$ sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 17179869184
kernel.shmall = 4194304
kernel.shmmni = 4096
fs.file-max = 655350
kernel.sem = 250 32000 128 1024
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_tw_recycle = 1
[root@ns_xxx.xx..161.182 ~]$ netstat -an |grep -i time|grep 10050|grep -v 5432|wc -l
0
# 现在TIME_WAIT为0个，原先有89个
注意：
关于tcp_tw_recycle:
如果是tcp_tw_recycle被打开了话，会假设对端开启了tcp_timestamps，然后会去比较时间戳，如果时间戳变大了，就可以重用。但是，如果对端是一个NAT网络的话（如：一个公司只用一个IP出公网）或是对端的IP被另一台重用了，这个事就复杂了。建链接的SYN可能就被直接丢掉了（你可能会看到connection time out的错误
参考：