Table of Contents

概述

最近处理了一个拖了我差不多一个月的问题，因为win不是很擅长，所以这里记录下大概的解决过程。

异常现象

服务器 telnet其他服务器端口和本机端口都无法telnet通，且无法访问网页，但可以正常ping通服务器，更奇怪的是每次只需要重启服务器就可以解决

说明：其他服务器端口都是正常的，也不存在防火墙问题

无法访问百度或者自己的网页。

1、考虑防火墙

这里确认是已经关闭防火墙了。

2、考虑是网卡问题

禁用网卡，然后重开网卡，但是还是不行，这里要注意如果禁用网卡就不能远程服务器了（忽略过一次）…

不要问我怎么禁网卡…

3、检查操作系统日志

没有什么有效信息。

下面开始有进展了。

4、漏洞?

微软上看到有提示相关漏洞，当Windows2008R2系统运行时间超过497天，TCP/IP的网络资源（端口）就不会再自动释放，在运行一段时间后，本机的网络资源就会被全部用光。这样就会造成系统中任何需要网络资源的组件都无法正常工作。

官网提示解决办法为打一个SP1的补丁，和一个修补程序。

下载补丁
windows6.1-KB976932-X64.exe(sp1补丁)和442685_intl_x64_zip.exe

SP1的补丁可以去官网下载
http://www.microsoft.com/zh-cn/download/details.aspx?id=5842442685_intl_x64_zip.exe官网下载

这两个补丁我已共享在我的百度网盘

链接：https://pan.baidu.com/s/1IzoeO3f8b82TaM65OjnHkw 
提取码：wy5t 
复制这段内容后打开百度网盘手机App，操作更方便哦

补充说明：打了补丁后重启服务器观察了几天还是有这种情况。

5、调整动态端口范围

5.1、默认的动态端口范围：

在Windows vista和windows server 2008以前的系统中动态的客户端端口范围是1025到5000；在Windows vista和windows server 2008中，为了遵守IANA的推荐，把范围扩展成49152到65535。在Windows vista和windows server 2008的环境中，可以用如下命令查看这些配置：

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

5.2、重新配置

使用如下命令可以重新配置：

netsh int set dynamic start=number num=range

修改如下：

netsh int ipv4 set dynamicport tcp start=1025 num=60000
netsh int ipv4 set dynamicport udp start=1025 num=60000
netsh int ipv6 set dynamicport tcp start=1025 num=60000
netsh int ipv6 set dynamicport udp start=1025 num=60000

如上所示，可以为每种传输层协议及每个版本的IP协议进行单独的设置，start的最小值是1025，num指的是范围，最小值是255。

5.3、测试服务器是否能正常telnet和访问

好吧，问题临时解决。

可以看到百度也可以访问了。

6、调整TCP连接快速回收时间

操作系统默认TIME_WAIT的TCP连接回收时间是4分钟，TCP默认动态端口范围为开始端口49152，结束端口65535。这样会使回收TCP过慢导致系统吞吐量下降，甚至出现502访问失败问题。

在Windows开始菜单中，单击“运行”，在“运行”对话框中，输入“regedit”后按“Enter”打开注册表编辑器。

在“注册表编辑器”中打开“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters”路径。

在“编辑”菜单中，选择“新建 > DWORD （32-位）值”，输入名称“TcpTimedWaitDelay”。

右键单击TcpTimedWaitDelay，选择“修改”。

在“编辑 DWORD（32位）值”对话框的“基数”区域中，选择十进制值为“30”，并“确定”。（将4分钟修改为2分钟）

7、监控网络连接使用情况

netstat -ano >> c:cmd.txt

因为输出有点多，所以拿到外面来具体分析。

内容如下：

可以看到88这台服务器（zabbix）有很多time_wait的连接

说明：time_wait状态的tcp连接：

1.这是一种处于连接完全关闭状态前的状态；

2.通常要等上4分钟（windows server）的时间才能完全关闭；

3.这种状态下的tcp连接占用句柄与端口等资源，服务器也要为维护这些连接状态消耗资源；

4.winserver解决这种time_wait的tcp连接只有让服务器能够快速回收和重用那些TIME_WAIT的资源：修改注册表[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTcpipParameters]添加dword值TcpTimedWaitDelay=30（30也为微软建议值；默认为2分钟）和MaxUserPort：65534(可选值5000 – 65534)；

8、zabbix为什么会出现这么多TIME_WAIT？

表格中的state是TCP连接在agent和server不同阶段时的状态。我们假设每个阶段，agent和server都会得到正确的状态！

passive agent通信的过程如下：

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)

到这里问题基本解决了，不过还得后面继续观察，所以先记录到这里了。后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~