故障排查:是什麼 致使了服務器端口telnet失敗?

      telnet命令的主要做用是與目標端口進行TCP鏈接(即完成TCP三次握手)。windows

      當服務端啓動後,可是telnet其監聽的端口,卻失敗了。或者,當服務端運行了一段時間後,忽然其監聽的端口telnet不通了。當相似這樣的telnet失敗的狀況出現時,均可以按照以下方面進行排查:api

1.觀察一下服務端進程的CPU和內存是否有異常。

       好比,當CPU持續在100%時,就有可能致使來自客戶端的TCP鏈接請求被丟棄或無暇處理。 安全

2.端口監聽器是否運行正常?

        若是服務端是基於ESFramework開發的,則能夠經過IRapidServerEngine的Advanced屬性的GetPortListenerState方法來獲取端口監聽器的狀態,該方法返回一個PortListenerState對象,其包含3個屬性:服務器

(1)IsMaxConnection:是否達到了最大鏈接數的限制。網絡

(2)IsListening:是否正在監聽端口。若是未受權,或達到了最大鏈接數限制,則將會中止監聽端口。運維

(3)LastDetectTime:最後一次檢測TCP鏈接隊列(已完成OS底層的三次握手,但還沒有被ESFramework提取的TCP鏈接存放於該隊列中)的時間。 工具

        若是上述兩點都正常,則接下來,須要專業的運維人員或網管人當員參與進來協助排查。測試

3.在當前服務器上執行telnet命令,看可否鏈接成功?

        若是能鏈接成功,至少代表本機的TCP握手請求是能正常地被接收和處理的。 spa

4.在服務器上執行netstat命令

          netstat是一個很是有用的查看端口狀態的命令,執行netstat命令後,請注意查看如下信息:對象

(1)目標端口是否處於監聽狀態?

(2)目標端口上是否存在已成功創建的TCP鏈接(ESTABLISHED)?其數量是多少?

(3)是否存在半開鏈接(SYN_RECV)?其數量是多少?

(4)是否存在等待關閉的鏈接(TIME_WAIT)?其數量是多少?

          這裏,最有可能的緣由是半開鏈接數達到最大限制,致使windows系統丟棄後續的TCP鏈接請求。 

5.TCP三次握手是否正常?

         對於一些奇怪現象的跟蹤與分析,數據抓包工具是不可缺乏的。

         在服務器上將抓包工具運行起來,而後在其餘的電腦上telnet該服務器的目標端口,經過抓包工具觀察目標端口上TCP三次握手的過程是否正常:

(1)目標端口是否收到了來自客戶端的SYN請求?

(2)目標端口有回覆SYN_ACK給客戶端?

(3)目標端口有收到來自客戶端的第三次握手?

         只有當TCP三次握手順利完成後,windows底層纔會將創建好的TCP鏈接放入隊列中,提交給上層的應用程序。

6.服務器網絡拓撲結構、防火牆、路由器、網絡安全監控等相關軟硬件

        在抓包分析的同時,結合服務器的網絡拓撲接口進行考慮是頗有必要的。極可能來自客戶端的三次握手請求被防火牆、路由器、或某些網絡徹底監控的相關軟硬件給擋住了

        此時,須要專業的運維人員或網管人員參與進來,協助排查問題,好比:

(1)在服務器上執行netstat命令,查看目標端口的相關狀態信息。

(2)在服務器上執行抓包工具,監測目標端口上是否有數據從客戶端過來。

(3)分析服務器的網絡拓撲結構,並以服務器爲中心,依次向外檢查防火牆、路由器、網絡安全監控等相關軟硬件等的設定,並進行鍼對性的排查測試。

 

       通過以上的排查分析,應該均可以找到問題的根源所在,若是仍是沒有結果,能夠給我留言,咱們一塊兒討論下啊。

相關文章
相關標籤/搜索