故障排查：是什麼 導緻了伺服器端口telnet失敗？

      telnet指令的主要作用是與目标端口進行TCP連接配接（即完成TCP三向交握）。

      當服務端啟動後，但是telnet其監聽的端口，卻失敗了。或者，當服務端運作了一段時間後，突然其監聽的端口telnet不通了。當類似這樣的telnet失敗的情況出現時，都可以按照如下方面進行排查：

       比如，當CPU持續在100%時，就有可能導緻來自用戶端的TCP連接配接請求被丢棄或無暇處理。 

（1）IsMaxConnection：是否達到了最大連接配接數的限制。

（2）IsListening：是否正在監聽端口。如果未授權，或達到了最大連接配接數限制，則将會停止監聽端口。

（3）LastDetectTime：最後一次檢測TCP連接配接隊列（已完成OS底層的三次握手，但尚未被ESFramework提取的TCP連接配接存放于該隊列中）的時間。 

        如果上述兩點都正常，則接下來，需要專業的運維人員或網管人當員參與進來協助排查。

        如果能連接配接成功，至少表明本機的TCP握手請求是能正常地被接收和處理的。 

          netstat是一個非常有用的檢視端口狀态的指令，執行netstat指令後，請注意檢視以下資訊：

（1）目标端口是否處于監聽狀态？

（2）目标端口上是否存在已成功建立的TCP連接配接（ESTABLISHED）？其數量是多少？

（3）是否存在半開連接配接（SYN_RECV）？其數量是多少？

（4）是否存在等待關閉的連接配接（TIME_WAIT）？其數量是多少？

          這裡，最有可能的原因是半開連接配接數達到最大限制，導緻windows系統丢棄後續的TCP連接配接請求。 

         對于一些奇怪現象的跟蹤與分析，資料抓包工具是不可缺少的。

         在伺服器上将抓包工具運作起來，然後在其他的電腦上telnet該伺服器的目标端口，通過抓包工具觀察目标端口上TCP三向交握的過程是否正常：

（1）目标端口是否收到了來自用戶端的SYN請求？

（2）目标端口有回複SYN_ACK給用戶端？

（3）目标端口有收到來自用戶端的第三次握手？

         隻有當TCP三向交握順利完成後，windows底層才會将建立好的TCP連接配接放入隊列中，送出給上層的應用程式。

        在抓包分析的同時，結合伺服器的網絡拓撲接口進行考慮是很有必要的。很可能來自用戶端的三次握手請求被防火牆、路由器、或某些網絡完全監控的相關軟硬體給擋住了。

        此時，需要專業的運維人員或網管人員參與進來，協助排查問題，比如：

（1）在伺服器上執行netstat指令，檢視目标端口的相關狀态資訊。

（2）在伺服器上執行抓包工具，監測目标端口上是否有資料從用戶端過來。

（3）分析伺服器的網絡拓撲結構，并以伺服器為中心，依次向外檢查防火牆、路由器、網絡安全監控等相關軟硬體等的設定，并進行針對性的排查測試。

       經過以上的排查分析，應該都可以找到問題的根源所在，如果還是沒有結果，可以給我留言，我們一起讨論下啊。