首页 > 试题广场 >

有哪些常见的服务端推送的通信解决方案?它们的优劣分别是什么?

[问答题]
有哪些常见的服务端推送的通信解决方案?它们的优劣分别是什么?
1.http2协议支持服务器主动向推送,比如浏览器请求一个页面时,服务器会将html中静态资源如图片和css、js等随带主动返回给浏览器而不必等到浏览器解析html时再次请求,劣势就是http2协议普及的不够好吧,尚需升级;
2.websocket是H5新增API,操作简单,一反传统http请求-应答机制,服务器浏览器真正全双工平等通信,劣势就是首先也要通过http协议通信进行“握手”,服务器浏览器双方都得支持协议升级。
3.ajax轮询是最先的解决方案,实现简单,兼容性好但会占用带宽,服务器挂起请求,浪费资源。
发表于 2020-08-06 21:15:31 回复(0)
1.Ajax轮询,利用XHR,通过setInterval定时向后端发送请求
优点:实现简单
缺点:数据同步不及时,增加后端处理压力

2. Ajax长轮询,在Ajax轮询的基础上做的改进,在后端数据没有更新时不再返回空响应,而且后端一直保持连接,直到后端有数据变化,则响应请求并且关闭连接,前端收到数据后,再次向后端发起请求,并处理刚刚收到的数据
优点:通信及时,服务端资源消耗低
缺点:请求交替时消息会延迟

3. websocket,允许服务端主动向客户端发送数据,浏览器和服务器只需要完成一次握手就可以创建持久性的连接,并进行双向数据传输
优点:通信及时,采用双工的通信模式
缺点:服务端资源消耗高
编辑于 2020-08-08 09:01:16 回复(0)
1.基于轮询:
优点:开发简单,客户端实现即可,不需要服务端配合
缺点:大多数情况下无用请求,占用服务端资源
实现方式:客户端每隔一段时间调用接口,无论有没有数据,接口立即返回.
使用场景:不想折腾的开发者,消息及时性要求没那么高,服务器资源资源足。
2.基于长轮询
优点:消息及时,命中率高,消耗服务端资源少
缺点:服务端和客户端需要同时改造,消息会有部分延迟(发生在请求交替之时)
实现方式:客户端在上次请求返回后,在发送下次请求,服务端当有数据或者超时后返回,没有数据时hang住链接(超时时间需要综合考虑服务器性能和及时性做出平衡,有代理的话需要考虑代理对于链接的超时机制)。
使用场景:扫码登录,微信网页端获取消息等。
3.长链接
优点:通信及时,通信模式采用双工,类似于打电话
缺点:服务端和客户端需要同时改造,当链接过多时,消耗服务端资源比较大。
实现方式:客户端和服务端建立长链接,基于http1.1 ,keepalive ,websocket,comet,iframe等,基于socket的需要维持心跳
使用场景:实时性要求很高,银行系统,股票系统等
————————————————
版权声明:本文为CSDN博主「yinjiangQAQ」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/yinjiangQAQ/article/details/103941272
发表于 2020-02-18 13:17:29 回复(0)
一、Ajax轮询
优点:开发简单,不需要服务端配合
缺点:无用请求过多,占用服务器资源
实现方式:客户端每隔一段时间调用接口,不管有没有数据,接口立即返回
使用场景:不想折腾的开发者,对消息的即时性要求没那么高,服务器资源充足
二、Ajax长轮询
优点:消息及时,命中率高,消耗服务器资源少
缺点:服务器和客户端需要同时改造,消息会有部分延时(发生在请求交替时)
实现方式:客户端在上次请求返回后,再发送下次请求,服务端当有数据或者超时后返回,没有数据时hang住链接。
使用场景:扫码登录,微信网页端获取消息等。
三、长连接
优点:通信及时,通信模式采用双工,类似于打电话
缺点:服务端和客户端需要同时改造,当链接过多时,消耗服务器资源比较大。
实现方式:客户端和服务端建立长连接:基于http1.1,keepalive,websocket,comet,iframe等,基于socket需要维持心跳
使用场景:实时性要求很高,银行系统,股票系统等

发表于 2020-09-05 12:08:24 回复(0)