這幾年做了很多基于 GGTalk開源即時通訊系統 的定制開發專案，經常會碰到如下兩個問題，分享出來，應該對大家會有所幫助：
（1）定制開發完成后，在給客戶部署GGTalk即時通訊服務端到正式的服務器上時，經常出現GGTalk客戶端連不上服務器的情況，
（2）部署好的GGTalk在運行的程序中，突然出現新的客戶端連不上登錄不了，
這些時候，使用telnet命令測驗，通常會發現telnet失敗了，
telnet命令的主要作用是與目標埠進行TCP連接（即完成TCP三次握手），
當服務端啟動后，但是telnet其監聽的埠，卻失敗了，或者，當服務端運行了一段時間后，突然其監聽的埠telnet不通了，當類似這樣的telnet失敗的情況出現時，都可以按照如下方面進行排查：
1.觀察一下服務端行程的CPU和記憶體是否有例外，
比如，當CPU持續在100%時，就有可能導致來自客戶端的TCP連接請求被丟棄或無暇處理，
2.埠監聽器是否運行正常？
GGTalk 服務端可以通過IRapidServerEngine的Advanced屬性的GetPortListenerState方法來獲取埠監聽器的狀態，該方法回傳一個PortListenerState物件，其包含3個屬性：
（1）IsMaxConnection：是否達到了最大連接數的限制，
（2）IsListening：是否正在監聽埠，如果未授權，或達到了最大連接數限制，則將會停止監聽埠，
（3）LastDetectTime：最后一次檢測TCP連接佇列（已完成OS底層的三次握手，但尚未被ESFramework提取的TCP連接存放于該佇列中）的時間，
如果上述兩點都正常，則接下來，需要專業的運維人員或網管人當員參與進來協助排查，
3.在當前服務器上執行telnet命令，看能否連接成功？
如果能連接成功，至少表明本機的TCP握手請求是能正常地被接收和處理的，
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）分析服務器的網路拓撲結構，并以服務器為中心，依次向外檢查防火墻、路由器、網路安全監控等相關軟硬體等的設定，并進行針對性的排查測驗，
經過以上的排查分析，應該都可以找到問題的根源所在，如果還有疏漏的方面，可以給我留言一起討論，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/487817.html
標籤：.NET技术