概述

最近處理了一個拖了我差不多一個月的問題，因為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_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters」路徑。

在「編輯」菜單中，選擇「新建 > 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_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Tcpip\\Parameters]添加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方面的內容，感興趣的朋友可以關注下~

如果你覺得這篇文章對你有幫助, 請小小打賞下.