telnet命令的主要作用是与目标端口进行TCP连接(即完成TCP三次握手)。
当服务端启动后,但是telnet其监听的端口,却失败了。或者,当服务端运行了一段时间后,突然其监听的端口telnet不通了。当类似这样的telnet失败的情况出现时,都可以按照如下方面进行排查:
比如,当CPU持续在100%时,就有可能导致来自客户端的TCP连接请求被丢弃或无暇处理。
如果服务端是基于ESFramework开发的,则可以通过IRapidServerEngine的Advanced属性的GetPortListenerState方法来获取端口监听器的状态,该方法返回一个PortListenerState对象,其包含3个属性:
(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)分析服务器的网络拓扑结构,并以服务器为中心,依次向外检查防火墙、路由器、网络安全监控等相关软硬件等的设定,并进行针对性的排查测试。
经过以上的排查分析,应该都可以找到问题的根源所在,如果还是没有结果,可以给我留言,我们一起讨论下啊。