但为了提升IM等前述应用领域情景下的最新消息即刻性和安全性，我们须要消除WebSocket及其下层倚赖的TCP相连对于繁杂网络情况下的复杂性，即刻通讯的开发人员们通常都须要为其结构设计两套完整的相连保活、验活以及丫蕊网重连方案。
不是很崩盘？因此，怎样在繁杂网络情景下，更即刻加速地交互网络变动，并加速恢复WebSocket的易用性，就变得至关重要。
*写作对象：责任编辑适宜有过IM下层网络前述开发经验，或者对下层网络实现有纤枝介绍的开发人员写作如果对下层网络介绍鲜少，提议埃唐佩县责任编辑，直接写作网络责任编辑结尾第三章部分的基础后再回头来看*文本评测：责任编辑文本没有矮小上，但比较蔬果，便携性较低，文本也很浅显，提议可详细写作。
该文虽讲的是WebSocket，但思想能延展应用领域到如前所述TCP协定的同行业控制技术中责任编辑已并行发布于“即刻通讯控制技术圈”社会公众
局限于字数，责任编辑不会思量WebSocket控制用例，如有兴趣请系统学习：《初学者加速进阶：WebSocket易懂讲义》《WebSocket简述（一）：初步认识WebSocket控制技术》《WebSocket简述（二）：控制技术基本原理、标识符模拟和应用领域事例》《WebSocket简述（三）：深入WebSocket串行技术细节》《WebSocket简述（四）：螳臂当车HTTP与WebSocket的亲密关系(上篇)》《WebSocket简述（五）：螳臂当车HTTP与WebSocket的亲密关系(第一卷)》《WebSocket简述（六）：螳臂当车WebSocket与Socket的亲密关系》3、加速介绍WebSocket
Websocket问世于2008年，在2011年成为标准，现在所有的应用领域程序都已支持（参见《初学者加速进阶：WebSocket易懂讲义》）它是一种崭新的网络层协定，是专门为web应用领域程序和服务器端结构设计的真正的串行串行，能等效HTTP协定来介绍websocket协定。
（图片提及自《WebSocket简述（四）：螳臂当车HTTP与WebSocket的亲密关系(上篇)》）它的不同之处：1）HTTP的协定URL是http，WebSocket的是ws；2）HTTP允诺只能由应用领域程序发动，服务器无法主动向应用领域程序发送最新消息，而WebSocket能；3）HTTP允诺有相混管制，不相混之间通讯须要布吕马，而WebSocket没有相混管制。
它的不同之处：1）都是网络层的串行；2）预设路由器一样，都是80或443；3）都能用于应用领域程序和服务器间的通讯；4）都如前所述TCP协定。二者和TCP的亲密关系图：
（图片提及自《初学者加速进阶：WebSocket易懂讲义》）有关Http和WebSocket的亲密关系，能详读：《WebSocket简述（四）：螳臂当车HTTP与WebSocket的亲密关系(上篇)》《WebSocket简述（五）：螳臂当车HTTP与WebSocket的亲密关系(第一卷)》有关WebSocket和Socket的亲密关系，能详读：《WebSocket简述（六）：螳臂当车WebSocket与Socket的亲密关系》.
4、WebSocket重连过程拆解首先考虑一个问题，何时须要重连？最容易想到的是WebSocket相连断了，为了接下来能收发最新消息，我们须要再发动一次相连但在很多情景下，即便WebSocket相连没有断开，前述上也不可用了。
比如以下情景：1）设备切换网络；2）链路中间路由崩盘（常识是一条socket相连对应的网络通路上，会存在很多路由设备）；3）链路的前端出口不可用（比如家庭WiFi中，网络相连正常，但前述运营商的宽带已经欠费被停机）；4）服务器负载持续过高无法响应等。
这些情景下的WebSocket都没有断开，但对上层来说，都没办法正常的收发数据了因此在重连前，我们须要一种机制来交互相连是否可用、服务是否可用，而且要能加速交互，以便能够加速从不可用状态中恢复一旦交互到了相连不可用，那便能弃旧图新了，弃用并断开旧相连，然后发动一次新相连。
其次：是加速发动新相连此快非彼快，这里的快并非是立即发动相连，立即发动相连会对服务器带来不可预估的影响重连时通常会采用一些退避算法，延迟一段时间后再发动重连但怎样在重连间隔和性能消耗间做出权衡？怎样在“恰当的时间点”加速发动相连？。
带着这些疑问，我们来细看下这三个过程：
5、加速重连关键1：加速交互何时须要重连5.1情景须要重连的情景能细分为三种：1）相连明确断开了；2）相连没断但是不可用了；3）相连对端的服务不可用了对于第一种情景：这很简单，相连直接断开了，肯定须要重连了。
对于后二者：无论是相连不可用，还是服务不可用，对上层应用领域的影响都是不能再收发即刻最新消息了5.2心跳包主动探测网络易用性所以从上面这个角度出发，交互何时须要重连的一种简单粗暴的方法就是通过心跳包超时：发送一个心跳包，如果超过特定的时间后还没有收到服务器回包，则认为服务不可用，如下图中左侧的方案（这种方法最直接）。
那如果想要加速交互呢，就只能多发心跳包，加快心跳频率但是心跳太快对移动端流量、电量的消耗又会太多，所以使用这种方法没办法做到加速交互，能作为检测相连和服务可用的兜底机制5.3被动监听网络状态改变如果要检测相连不可用，除了用心跳检测，还能通过判断网络状态来实现，因为断网、切换wifi、切换网络是导致相连不可用的最直接原因，所以在网络状态由offline变为online时，大多数情况下须要重连下，但也不一定，因为webscoket下层是如前所述TCP的，TCP相连不能敏锐的交互到网络层的网络变化，所以有时候即便网络断开了一小会，对WebSocket相连是不会有影响的，网络恢复后，仍然能够正常地进行通讯。
因此在网络由断开到相连上时，立即判断下相连是否可用，能通过发一个心跳包判断，如果能够正常收到服务器的心跳回包，则说明相连仍是可用的，如果等待超时后仍没有收到心跳回包，则须要重连，如上图中的右侧这种方法的优点是速度快，在网络恢复后能够第一时间交互相连是否可用，不可用的话能加速执行恢复，但它只能覆盖网络层网络变化导致WebSocket不可用的情况。
5.4小结综上所述：1）定时发送心跳包检测的方案贵在稳定，能够覆盖所有情景，但速度不即刻（心跳间隔是固定的）；2）判断网络状态的方案速度快，无需等待心跳间隔，较为灵敏，但覆盖情景较为局限因此，我们能结合两种方案：。
1）定时以不太快的频率发送心跳包，比如40s/次、60s/次等，具体能根据应用领域情景来定；2）然后在网络状态由offline变为online时立即发送一次心跳，检测当前相连是否可用，不可用的话立即进行恢复处理。
这样在大多数情况下，上层的应用领域通讯都能较快从不可用状态中恢复，对于少部分情景，有定时心跳作为兜底，在一个心跳周期内也能够恢复6、加速重连关键2：加速断开旧相连通常情况下，在发动下一次相连前，如果旧相连还存在的话，应该先把旧相连断开。
这样做的目的：1）一来能释放应用领域程序和服务器的资源；2）二来能避免之后误从旧相连收发数据我们知道WebSocket下层是如前所述TCP协定传输数据的，相连两端分别是服务器和应用领域程序，而TCP的TIMEWAIT状态是由服务器端维持的，因此在大多数正常情况下，应该由服务器发动断开下层TCP相连，而不是应用领域程序。
也就是说：1）要断开WebSocket相连时，如果是服务器收到指示要断开WebSocket，那它应该立即发动断开TCP相连；2）如果是应用领域程序收到指示要断开WebSocket，那它应该发信号给服务器，然后等待下层TCP相连被服务器断开或直至超时。
那如果应用领域程序想要断开旧的WebSocket，能分为WebSocket相连可用和不可用两种情况来讨论具体如下：1）当旧相连可用时，应用领域程序能直接给服务器发送断开信号，然后服务器发动断开相连即可；2）当旧相连不可用时，比如应用领域程序切换了wifi，应用领域程序发送了断开信号，但是服务器收不到，应用领域程序只能迟迟等待，直至超时才能被允许断开。
超时断开的过程相对来说是比较久的，那有没有办法能快点断开？上层应用领域无法改变只能由服务器发动断开相连这种协定层面的规则，所以只能从应用领域逻辑入手，比如在上层通过业务逻辑保证旧相连完全失效，模拟相连断开，然后在发动新相连，恢复通讯。
这种方法相当于尝试断开旧相连不行时，直接弃之，然后就能加速进入下一流程，所以在使用时一定要确保在业务逻辑上旧相连已完全失效比如：1）保证丢掉从旧相连收到所有数据；2）旧相连不能阻碍新相连的建立3）旧相连超时断开后不能影响新相连和上层业务逻辑等等。
7、加速重连关键3：加速发动新相连有IM开发经验的同学应该有所介绍，遇到因网络原因导致的重连时，是万万不能立即发动一次新相连的，否则当出现网络抖动时，所有的设备都会立即同时向服务器发动相连，这无异于黑客通过发动大量允诺消耗网络带宽引起的拒绝服务攻击，这对服务器来说简直是灾难（即：服务器端雪崩效应）。
所以在重连时通常采用一些退避算法，延迟一段时间再发动重连，如下图中左侧的流程。
如果要加速连上呢？最直接的做法就是缩短重试间隔，重试间隔越短，在网络恢复后就能越快的恢复通讯但是太频繁的重试对性能、带宽、电量的消耗就比较严重怎样在这之间做一个较好的权衡呢？1）一种比较合理的方式是随着重试次数增多，逐渐增大重试间隔；2）另一方面监听网络变化，在网络状态由offline变为online这种比较可能重连上的时刻，适当地减小重连间隔。
上述第2）种方案，如上图中的右侧所示，随重试次数的增多，重连间隔也会变大这两种方式配合使用，更为合理除此之外，还能结合业务逻辑，根据成功重连上的可能性适当的调整间隔，如网络未相连时或应用领域在后台时重连间隔能调大一些，网络正常的状态下能适当调小一些等等，加快重连上的速度。
8、责任编辑小结最后总结一下责任编辑将WebSocket断网重连逻辑细分为三个步骤：1）确定何时须要重连；2）断开旧相连；3）发动新相连然后分别分析了在WebSocket的不同状态下、不同的网络状态下，怎样加速完成这个三个步骤。
使之尽可能快地重连上。
[4] WebSocket简述（五）：螳臂当车HTTP与WebSocket的亲密关系(第一卷)[5] WebSocket简述（六）：螳臂当车WebSocket与Socket的亲密关系第三章：更多Web端即刻通讯资料
《初学者进阶贴：史上最全Web端即刻通讯控制技术基本原理简述》《Web端即刻通讯控制技术盘点：短轮询、Comet、Websocket、SSE》《SSE控制技术简述：一种崭新的HTML5服务器发送事件控制技术》《Comet控制技术简述：如前所述HTTP长相连的Web端实时通讯控制技术》《socket.io实现最新消息发送的一点课堂教学及思路》《LinkedIn的Web端即刻通讯课堂教学：实现单机几十万条长相连》《Web端即刻通讯控制技术的发展与WebSocket、Socket.io的控制技术课堂教学》《Web端即刻通讯安全：跨站点WebSocket劫持漏洞简述(含示例标识符)》《开源框架Pomelo课堂教学：搭建Web端高性能分布式IM聊天服务器》《使用WebSocket和SSE控制技术实现Web端最新消息发送》《简述Web端通讯方式的演进：从Ajax、JSONP 到 SSE、Websoc
（责任编辑并行发布于：http://www.52im.net/thread-3098-1-1.html）
