CH395作为TCP客户端，电脑作为TCP服务端，第一次连接时很快就能连接上只需1秒。

TCP客户端与TCP服务端进行数据发输2，3次后，在电脑TCP服务端断开TCP连接后，电脑TCP服务端再开监听，CH395客户端再去连接，这时需要时间很长2分钟左右 。

如果CH395不回送通讯数据，在电脑TCP服务端断开TCP连接后，电脑TCP服务端再开监听，CH395客户端再去连接也可以很快连接上。

如果再次连接时将TCP通讯的端口号换一个新的，也可以快速连接上。

请问各位有没有遇到上述现象，是什么原因造成的？能不能解决？

您好，这是服务端的一种连接/防连接机制，当服务器进程关闭，想立刻再复用原来的ip和端口需要等待2MSL时间，MSL是数据包最大存活时间。因为TCP四次挥手最后一步TIME_WAIT需要等待应答，如果等不到需要重连。

有的服务器会有REUSE可选项或者默认功能，可以让服务器进程立刻复用服务器端口。

谢谢TECH48！那要解决连接连接慢的问题，只能从TCP服务端下手师是不是？

我还有一个疑问，我用的网格调试助手NetAssist.exe在两电脑之间，一个为服务端，一个为客户端进行TCP通讯，不管怎么断开都能很快连接上。这么看又不是电脑调试助手的问题。能不能通过配置CH395解决这个问题？如何配置？

您好，可以更改395的socket本地端口，会直接连上对方的服务端。

我用CH579也存在这个问题，经过抓包发现是网络库程序在断开连接的时候少发了一个数据包所致。

按照规范，TCP断开连接时要进行四次挥手，而沁恒网络库在处理断开连接时，只有三次挥手过程，少一个ACK包。也就是说，服务器发出了断开连接请求后，客户端没有返回ACK，导致服务器一直等待，直到过去很长时间超时以后，服务器才会放弃等待，确认断开。在此期间，因为服务器端认为原来的连接还未彻底断开，因此同一个端口号不能再次使用。

后经多次查证和实验，断开连接的三次挥手也不能算是bug，在不同场合很常见的，有的也能工作的很好。

可能取决于服务端的应用程序编写特点。某些服务端程序比较死板，三次挥手不认，必须死等直到超时。有的服务端程序就可以接受三次挥手。

网络调试助手Net*****就是要求比较严格的那类，还有****的一个网络调试助手，断开连接后都不能再次连接。

换一个其它网络调试助手就可以了。

(补充说明：暂时收回上面那段文字，之前测试的时候确实是那个样子，今天发完这个贴我又测试了一下，结果完全没有问题了，同样的电脑和网络调试助手，同样的板子。搞不明白了。抓包还是三次挥手，也可以断开连接马上重连了。难道是和windows或防火墙有什么关系？)

谢谢health和TECH48回答!  

我测试时，发现如果CH395做为客户端只接收不发送，电脑服务端断开后再监听，CH395去连接很快就能连接上。

如果CH395发送了数据，断开再去连接就会很慢。

如果CH395发送了数据，过2分种断开再去连接就很快连接上。

一般情况不会频繁开断。只要周期大于2分钟就不会出现连接 花长时间的情况。

正常情况下TCP服务端断开会使CH395产生超时中断，建议在超时中断里加上关闭、打开、连接的三个socket操作。如下图：

你好TECH48，你说“电脑端的TCP服务端断开会做为客户端的CH395产生超时中断”，经我测试并没有发现CH395产生超时中断，只产生了一个断开中断。

断开后，电脑服务端再开监听，客户端CH395这时去连接，CH395会产生连接超时中断，在这个超时中断中加上关闭，打开，连接的三个SOCKET操作，我也测试了没有效果，  一样要不断去连接2分钟后才能连接成功。 

您好，建议最好还是每次连接的时候更改本地端口的设置。

我之前用的时候也是这样，但是不知为何，现在一切正常了。

你把电脑的防火墙全关了，再试试，看看和这方面有没有关系。