是什么导致了客户端TCP连不上服务器？

　这几年做了很多基于 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）分析服务器的网络拓扑结构，并以服务器为中心，依次向外检查防火墙、路由器、网络安全监控等相关软硬件等的设定，并进行针对性的排查测试。

　　经过以上的排查分析，应该都可以找到问题的根源所在，如果还有疏漏的方面，可以给我留言一起讨论。