概述

最近處理了一個拖了我差不多一個月的問題，因為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)

總結

以上是生活随笔為你收集整理的telnet服务器显示本机,记一次困扰了我一个月的服务器telnet故障是如何解决的？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。