tcp断线重连(tcp断线重连 如何避免程序阻塞)

理想状态下，一个 TCP 连接可以被长期保持。然而，在实际应用中，客户端或服务器端上维持的一个看似正常的 TCP 连接可能已经断连。TCP 连接主要受到两个方面的影响而导致断连：网络中间节点和客户端 / 服务器节点参与通信的两方节点？ 在实际网络应用中，两个主机之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等。因此，两个主机之间 TCP连接的保持同样会受到中间节点的影响，尤其是会受到防火墙（软件或硬件防火墙）的限制。防火墙是一种装置，有多种不同的实现方式（软件实现、硬件设备实现或是软硬件相结合实现），它需要依据一系列规则对进出的信息流进行扫描，并允许安全（符合规则）的信息交互、阻止不安全（违反规则）的信息交互。防火墙的工作特性决定了要维护一个网络连接就需要耗费较多的资源，并且企业防火墙常常位于企业网络的出入口，长时间维护非活跃的 TCP连接必将导致网络性能的下降。因此，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 TCP 连接断连。类似的，如果中间节点异常导致来自客户端关闭连接的请求无法传递到服务器端，也将导致服务器端的相应连接发生断连。

断开重连，还是需要重新建立tcp三次握手，建立连接。
最好设置端口重用。要不你会吃亏的。
这个不需要处理啊，你服务器如果跑数据的话，那就是丢了呗

简单来说,TCPReceiveWindow是在TCP连接两端都有的缓冲区,用于暂时保存到来的数据.在这个缓冲区中的数据会被发送到应用程序中,为新到来的数据腾出空间.如果这个缓冲满了,那么数据的接收方会警告发送方在缓冲去清空之前已经不能在收取的数据了.这其中涉及到一些细节,但那都是很基本的东西.一般,设备会在TCPHeader信息中通知对方当前它的TCPWindows的大小.

1、弱网络下的断线重连 玩家在游戏过程中，所处的网络环境是复杂多变的，可能是wifi的网络不稳定，或处在3G甚至2G的环境下等。在这些情况下，网络游戏会由于网络或包量等原因而出现延迟，拉拽，甚至掉线等问题。对于这些问题，一方面要对程序的包量和通信进行优化，从根本上减缓网络压力。另一方面，在出现网络异常的时候，保证玩家能重新连接到服务器并继续游戏，并且体验良好。网络的“弱”主要体现在延迟和丢包率大两方面，而这两方面都会影响游戏的体验。我们在市区低速移动的网络情况下（丢包率10%， 平均延迟890ms）测试，并对此情况下进行分析优化，达到了玩家能够顺利游戏的体验。由断线或网络异常性质决定，基本上都是首先由客户端感知，因此断线重连的机制主要是由客户端来进行发起。下面我主要从客户端方向就断线重连触发的条件，如何重连，以及重连后的后续处理三个方面来阐述，最后简略分析一下对我们游戏客户端容易掉线的一些思考。2、判断重连条件在弱网络条件下，我们根据网络状况的不同，有两种情况触发断线重连。网络条件异常在弱网络情况下，网络会显式的抛出一些异常，大部分情况下是NetworkException，少部分情况是Timeout（当然还有连接关闭等等其他异常，就不一一赘述）。在这种显式抛出异常的情况下，就说明网络已经无法顺利的和服务器进行连接，在这些消息类型中，对于客户端断网或网络波动导致的原因，客户端这边就会触发断线重连流程。心跳包触发以及触发时间的确定上一种情况的触发条件是客户端手机本身断网或网络发生异常的情况的触发，但实际情况中，还有可能发生客户端网络并未断开，也并没有异常抛出，但是却出现客户端和服务器无法正常进行收发消息的情况。这种情况一方面原因是中间链路的连接异常，另一方面也会由于延迟过高或丢包导致的TCP重发造成的延迟过大，影响到服务器和客户端之间正常的收发消息。市区低速移动的网络的模拟测试中，我们收集到的最大心跳包延迟是10s左右，也就是说，在此“弱”网络情况下，网络延迟峰值大概有10s以上。因此，我们对心跳包在一定时间内如果没有收到返回包的情况下也认为是一种掉线情况，会触发断线重连处理，目前在大厅设置的触发时间是30s，战斗中触发的时间是20s。游戏切出有一种情况是由于客户端切出游戏，或者中间接到电话等导致游戏暂停等情况，在一定时间后服务器会主动断开和客户端的连接，客户端也需要主动触发重连。 3、断线重连的大致流程图
可以开通信息电话都不影响网络的服务，自己手机上就可以设置的，这样就算你在打游戏时候来了电话也不会断网断开游戏链接的。
可以了解无线网路，就不会造成这种现象了，用流量来电话就更倒霉了，彻底中断网络

TCP本身没有自动重连的机制的，你可以通过设置心跳规律，客户端如果超过多久时间没有收到服务器的心跳数据包，就自动重新连接