概述

最近處理了一個拖了我差不多一個月的問題，因為win不是很擅長，所以這里記錄下大概的解決過程。

異常現(xiàn)象

服務(wù)器 telnet其他服務(wù)器端口和本機端口都無法telnet通，且無法訪問網(wǎng)頁，但可以正常ping通服務(wù)器，更奇怪的是每次只需要重啟服務(wù)器就可以解決

說明：其他服務(wù)器端口都是正常的，也不存在防火墻問題

無法訪問百度或者自己的網(wǎng)頁。

1、考慮防火墻

這里確認是已經(jīng)關(guān)閉防火墻了。

2、考慮是網(wǎng)卡問題

禁用網(wǎng)卡，然后重開網(wǎng)卡，但是還是不行，這里要注意如果禁用網(wǎng)卡就不能遠程服務(wù)器了（忽略過一次）...

不要問我怎么禁網(wǎng)卡...

3、檢查操作系統(tǒng)日志

沒有什么有效信息。

下面開始有進展了。

4、漏洞?

微軟上看到有提示相關(guān)漏洞，當Windows2008R2系統(tǒng)運行時間超過497天，TCP/IP的網(wǎng)絡(luò)資源（端口）就不會再自動釋放，在運行一段時間后，本機的網(wǎng)絡(luò)資源就會被全部用光。這樣就會造成系統(tǒng)中任何需要網(wǎng)絡(luò)資源的組件都無法正常工作。

官網(wǎng)提示解決辦法為打一個SP1的補丁，和一個修補程序。

下載補丁windows6.1-KB976932-X64.exe(sp1補丁)和442685_intl_x64_zip.exe

SP1的補丁可以去官網(wǎng)下載http://www.microsoft.com/zh-cn/download/details.aspx?id=5842442685_intl_x64_zip.exe官網(wǎng)下載

這兩個補丁我已共享在我的百度網(wǎng)盤

補充說明：打了補丁后重啟服務(wù)器觀察了幾天還是有這種情況。

5、調(diào)整動態(tài)端口范圍

5.1、默認的動態(tài)端口范圍：

在Windows vista和windows server 2008以前的系統(tǒng)中動態(tài)的客戶端端口范圍是1025到5000；在Windows vista和windows server 2008中，為了遵守IANA的推薦，把范圍擴展成49152到65535。在Windows vista和windows server 2008的環(huán)境中，可以用如下命令查看這些配置：

netsh int ipv4 show dynamicport tcpnetsh int ipv4 show dynamicport udpnetsh int ipv6 show dynamicport tcpnetsh int ipv6 show dynamicport udp

5.2、重新配置

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

netsh int set dynamic start=number num=range

修改如下：

如上所示，可以為每種傳輸層協(xié)議及每個版本的IP協(xié)議進行單獨的設(shè)置，start的最小值是1025，num指的是范圍，最小值是255。

5.3、測試服務(wù)器是否能正常telnet和訪問

好吧，問題臨時解決。

可以看到百度也可以訪問了。

6、調(diào)整TCP連接快速回收時間

操作系統(tǒng)默認TIME_WAIT的TCP連接回收時間是4分鐘，TCP默認動態(tài)端口范圍為開始端口49152，結(jié)束端口65535。這樣會使回收TCP過慢導(dǎo)致系統(tǒng)吞吐量下降，甚至出現(xiàn)502訪問失敗問題。

在Windows開始菜單中，單擊“運行”，在“運行”對話框中，輸入“regedit”后按“Enter”打開注冊表編輯器。

在“注冊表編輯器”中打開“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters”路徑。

在“編輯”菜單中，選擇“新建 > DWORD （32-位）值”，輸入名稱“TcpTimedWaitDelay”。

右鍵單擊TcpTimedWaitDelay，選擇“修改”。

在“編輯 DWORD（32位）值”對話框的“基數(shù)”區(qū)域中，選擇十進制值為“30”，并“確定”。（將4分鐘修改為2分鐘）

7、監(jiān)控網(wǎng)絡(luò)連接使用情況

netstat -ano >> c:\cmd.txt

因為輸出有點多，所以拿到外面來具體分析。

內(nèi)容如下：

可以看到88這臺服務(wù)器（zabbix）有很多time_wait的連接

說明：time_wait狀態(tài)的tcp連接：

1.這是一種處于連接完全關(guān)閉狀態(tài)前的狀態(tài)；

2.通常要等上4分鐘（windows server）的時間才能完全關(guān)閉；

3.這種狀態(tài)下的tcp連接占用句柄與端口等資源，服務(wù)器也要為維護這些連接狀態(tài)消耗資源；

4.winserver解決這種time_wait的tcp連接只有讓服務(wù)器能夠快速回收和重用那些TIME_WAIT的資源：修改注冊表[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]添加dword值TcpTimedWaitDelay=30（30也為微軟建議值；默認為2分鐘）和MaxUserPort：65534(可選值5000 - 65534)；

8、zabbix為什么會出現(xiàn)這么多TIME_WAIT？

表格中的state是TCP連接在agent和server不同階段時的狀態(tài)。我們假設(shè)每個階段，agent和server都會得到正確的狀態(tài)！

passive agent通信的過程如下：

• 1: tcp連接是通過socket通信的，每個socket都是為唯一的，address:port--address:port
• 2: 第二行的SYN/ACK如果沒有發(fā)送，那么第一步的SYN會重新發(fā)送。在缺省的timeout設(shè)置中，如果丟了這個SYN/ACK過程，連接將會被重置(RST),并且這個獲取數(shù)據(jù)的過程將會失??！
• 3: 當前的連接是全雙工的工作模式
• 4: PUSH標志表明當前正在傳送數(shù)據(jù)！
• 7: 沒有其它事要做，關(guān)閉連接。在接下來的關(guān)閉過程中，agent會保留TIME_WAIT狀態(tài)！請去看下TCP連接的3次握手，和TCP關(guān)閉的4次揮手過程。 這里并不是正確的連接關(guān)閉過程。
• 8: 帶有FIN標志的數(shù)據(jù)報會被立刻確認，然后zabbix server 立刻知道這個連接已經(jīng)關(guān)閉。
• 9: zabbix server確認連接關(guān)閉的時候，它也會立刻發(fā)送一個帶FIN的數(shù)據(jù)包
• 10: 立刻確認第九步的FIN，到此為止，這個連接就關(guān)閉了！
• 11：passive zabbix agent的連接過程，并沒有第十一步的數(shù)據(jù)報！當?shù)谑街?，server端確認連接關(guān)閉，并轉(zhuǎn)變狀態(tài)為closed之后， agent會把TIME_WAIT掛起兩分鐘。 這意味著這個連接在兩分鐘內(nèi)是不可重用的。

注意：

使用TCP協(xié)議，是為了在不可靠的網(wǎng)絡(luò)環(huán)境中創(chuàng)建可靠的連接！zabbix并不支持UDP和長連接的方式(persistent connection)