概述

最近處理了一個(gè)拖了我差不多一個(gè)月的問題，因?yàn)閣in不是很擅長，所以這里記錄下大概的解決過程。

異常現(xiàn)象

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

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

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

1、考慮防火墻

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

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

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

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

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

沒有什么有效信息。

下面開始有進(jìn)展了。

4、漏洞?

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

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

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

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

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

鏈接：https://pan.baidu.com/s/1IzoeO3f8b82TaM65OjnHkw 
提取碼：wy5t 
復(fù)制這段內(nèi)容后打開百度網(wǎng)盤手機(jī)App，操作更方便哦

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

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

5.1、默認(rèn)的動(dòng)態(tài)端口范圍：

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

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

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

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

好吧，問題臨時(shí)解決。

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

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

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

在Windows開始菜單中，單擊“運(yùn)行”，在“運(yùn)行”對(duì)話框中，輸入“regedit”后按“Enter”打開注冊(cè)表編輯器。

在“注冊(cè)表編輯器”中打開“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters”路徑。

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

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

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

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

netstat -ano >> c:cmd.txt

因?yàn)檩敵鲇悬c(diǎn)多，所以拿到外面來具體分析。

內(nèi)容如下：

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

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

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

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

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

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

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

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

passive agent通信的過程如下：

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

注意：

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

到這里問題基本解決了，不過還得后面繼續(xù)觀察，所以先記錄到這里了。后面會(huì)分享更多devops和DBA方面的內(nèi)容，感興趣的朋友可以關(guān)注下~