网页端IM即时通讯技术入门之短轮询长轮询SSEWebSocket

Posted 2022-07-15 wecloud1314

对Web端即时通讯技术熟悉的开发者来说，我们回顾网页端IM的底层通信技术，从短轮询、长轮询，到后来的SSE以及WebSocket，使用门槛越来越低（早期的长轮询Comet这类技术实际属于hack手段，使用门槛并不低），技术手段越来越先进，网页端即时通讯技术的体验也因此越来越好。

之前的这些所谓的网页端即时通讯“老技术”相对于当红的WebSocket，并非毫无用武之地。就拿IM里的扫码登录功能来说，用短轮询技术就非常合适，完全没必要大炮打蚊子上WebSocket。

 

所以，很多时候没必要盲目追求新技术，相对应用场景来说适合的才是最好的。对于即时通讯网的im和消息推送这类即时通讯技术开发者来说，掌握WebSocket固然很重要，但了解短轮询、长轮询等这些所谓的Web端即时通讯“老技术”仍然大有裨益，这也正是整理分享本文的重要原因。

对于IM/消息推送这类即时通讯系统而言，系统的关键就是“实时通信”能力。

从表面意思上来看，“实时通信”指的是：

1）客户端能随时主动发送数据给服务端；2）当客户端关注的内容在发生改变时，服务器能够实时地通知客户端。类比于传统的C/S请求模型，“实时通信”时客户端不需要主观地发送请求去获取自己关心的内容，而是由服务器端进行“推送”。

注意：上面的“推送”二字打了引号，实际上现有的几种技术实现方式中，并不是服务器端真正主动地推送，而是通过一定的手段营造了一种“实时通信”的假象。

就目前现有的几种技术而言，主要有以下几类：

1）客户端轮询：传统意义上的短轮询（Short Polling）；2）服务器端轮询：长轮询（Long Polling）；3）单向服务器推送：Server-Sent Events（SSE）；4）全双工通信：WebSocket。以下正文将针对这几种技术方案，为你一一解惑。

理解短轮询（Short Polling）

短轮询的实现原理：

1）客户端向服务器端发送一个请求，服务器返回数据，然后客户端根据服务器端返回的数据进行处理；2）客户端继续向服务器端发送请求，继续重复以上的步骤，如果不想给服务器端太大的压力，一般情况下会设置一个请求的时间间隔。

使用短轮询的优点：基础不需要额外的开发成本，请求数据，解析数据，作出响应，仅此而已，然后不断重复。

缺点也显而易见：

1）不断的发送和关闭请求，对服务器的压力会比较大，因为本身开启Http连接就是一件比较耗资源的事情；2）轮询的时间间隔不好控制。如果要求的实时性比较高，显然使用短轮询会有明显的短板，如果设置interval的间隔过长，会导致消息延迟，而如果太短，会对服务器产生压力。

长轮询的基本原理：

1）客户端发送一个请求，服务器会hold住这个请求；2）直到监听的内容有改变，才会返回数据，断开连接（或者在一定的时间内，请求还得不到返回，就会因为超时自动断开连接）；3）客户端继续发送请求，重复以上步骤。

长轮询是基于短轮询上的改进版本：主要是减少了客户端发起Http连接的开销，改成了在服务器端主动地去判断所关心的内容是否变化。

所以其实轮询的本质并没有多大变化，变化的点在于：

1）对于内容变化的轮询由客户端改成了服务器端（客户端会在连接中断之后，会再次发送请求，对比短轮询来说，大大减少了发起连接的次数）；2）客户端只会在数据改变时去作相应的改变，对比短轮询来说，并不是全盘接收。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

下面是一个原生不用库的实现（这里只是介绍原理），整体的思路是：如果服务器端支持hold住请求的话，那么在一定的时间内会自轮询，然后期间通过比较key值，判断是否返回新数据。

以下是具体思路：

1）客户端第一次会带一个空的key值，这次会立即返回，获取新内容，服务器端将计算出的contentKey返回给客户端；2）然后客户端发送第二次请求，带上第一次返回的contentKey作为key值，然后进行下一轮的比较；3）如果两次的key值相同，就会hold请求，进行内部轮询，如果期间有新内容或者客户端timeout，就会断开连接；4）重复以上步骤。

基于iframe的长轮询模式

这是长轮询技术的另一个种实现方案。

该方案的具体的原理为：

1）在页面中嵌入一个iframe，地址指向轮询的服务器地址，然后在父页面中放置一个执行函数，比如execute(data)；2）当服务器有内容改变时，会向iframe发送一个脚本<script>parent.execute(JSON.stringify(data))</script>；3）通过发送的脚本，主动执行父页面中的方法，达到推送的效果。

从纯技术的角度讲：上两节介绍的短轮询和长轮询技术，服务器端是无法主动给客户端推送消息的，都是客户端主动去请求服务器端获取最新的数据。

本节要介绍的SSE是一种可以主动从服务端推送消息的技术。

SSE的本质其实就是一个HTTP的长连接，只不过它给客户端发送的不是一次性的数据包，而是一个stream流，格式为text/event-stream。所以客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。

简单来说，SSE就是：

1）SSE 使用 HTTP 协议，现有的服务器软件都支持。WebSocket 是一个独立协议。2）SSE 属于轻量级，使用简单；WebSocket 协议相对复杂。3）SSE 默认支持断线重连，WebSocket 需要自己实现。4）SSE 一般只用来传送文本，二进制数据需要编码后传送，WebSocket 默认支持传送二进制数据。5）SSE 支持自定义发送的消息类型。

WebSocket诞生于2008年，在2011年成为国际标准，现在所有的浏览器都已支持（详见《新手快速入门：WebSocket简明教程》）。它是一种全新的应用层协议，是专门为web客户端和服务端设计的真正的全双工通信协议，可以类比HTTP协议来了解websocket协议。

它们的不同点：

1）HTTP的协议标识符是http，WebSocket的是ws；2）HTTP请求只能由客户端发起，服务器无法主动向客户端推送消息，而WebSocket可以；3）HTTP请求有同源限制，不同源之间通信需要跨域，而WebSocket没有同源限制。它们的相同点：

1）都是应用层的通信协议；2）默认端口一样，都是80或443；3）都可以用于浏览器和服务器间的通信；4）都基于TCP协议。