软硬件资源相同的情况下,各自在什么场合下使用?
长轮询是指上次说的“服务器推”技术吧,我觉得这个很不错啊,对于客户端来说无所谓,对服务端来说可以支持比socket高很多的人数,没用过缺点不清楚,可能会有http请求超时之类的各种情况要处理吧
长连接 目前就是google 的comet 使用http 负载量大了以后很难处理
现在有出现了 Server-Sent Events html5的浏览器增加一个事件.
然后就是socket, 常规的就是用flash里面的xmlsocket类 来达到访问socket服务器的目的.
现在html5又增加了 websocket
只有socket才是真正的主动推送. 其他都是前端轮询+后端轮询. 结合nodejs 的socket.io 做实时推送的很多. 但为了兼容主流的浏览器很多框架都是多种技术根据浏览器不同融合使用.
WebSockets vs Server-Sent Events vs Long-pollinghttp://dsheiko.com/weblog/websockets-vs-sse-vs-long-pollinghttp://www.oschina.net/question/82993_63312
不知道提问者是想知道长连接还有短连接的区别,还是轮询与通知的区别。问题有点歧义,我在长连接的基础上也可以实现长轮询。
我就当问题是长连接和短连接吧。我在大家的基础上补充一个很重要的一个特性。因为短连接轮询,每次都需要重新解析域名,然后连到HTTP服务器,所以如果你打算热扩展,那选短连接轮询再好不过了。
武侠的游戏服可以不停服增加或者减少服务器,就是因为跟后面的业务HTTP服务器用的是短连接。当发现负载很重的时候,可以在玩家毫无感知的情况下,增加若干台服务器。如果用长连接,这个过程无法做到很平滑。另外如果是有一台机器挂掉了,也可以快速的切到备用机器上面,长连接似乎不那么好做。
即使tcp长连接的情况下,也要定时的发心跳包的。
看你需要什么样的应用了。若是BS模式的是采用轮询,若是CS模式的应用就采用长连接。手机App应该就需要考虑网络情况而决定那种模式更适合。
要看你的应用,若交互的数据量并不大,采用UDP的方式,因为TCP方式即时没有数据交互,也会有定时保活、测试信道拥塞等机制。若客户端很多,可以采用多播的方式,不用每个都建立 UDP 连接。而且可以采用服务器定时多播通知的方式,省掉诸多客户端轮询。可以参考@对于一个具有几百万粉丝的用户,数据如何实时投递到所有用户?
若数据量很大,且要求稳定传送(出错率很小),采用TCP长连接。
长连接的好处是可以用tcp的机制实现一个有状态的过程,但是维护该连接需要资源,而轮询的好处是灵活性,一般的大用户低流量都采用轮询的方式。有一种 socket 叫 T/TCP,特性介于 tcp 和 udp 之间,是个很好的选择,见 T/TCP
在网上查了一下资料,发现轮询和长轮询还有不同的定义:
轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。优点:后端程序编写比较容易。缺点:请求中有大半是无用,浪费带宽和服务器资源。实例:适于小型应用。长轮询:客户端向服务器发送Ajax请求,服务器接到请求后hold住连接,直到有新消息才返回响应信息并关闭连接,客户端处理完响应信息后再向服务器发送新的请求。优点:在无消息的情况下不会频繁的请求。缺点:服务器hold连接会消耗资源。实例:WebQQ、Hi网页版、Facebook IM。
另外,对于长连接和socket连接也有区分:
长连接:在页面里嵌入一个隐蔵iframe,将这个隐蔵iframe的src属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。优点:消息即时到达,不发无用请求。缺点:服务器维护一个长连接会增加开销。实例:Gmail聊天Flash Socket:在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信,JavaScript在收到服务器端传送的信息后控制页面的显示。优点:实现真正的即时通信,而不是伪即时。缺点:客户端必须安装Flash插件;非HTTP协议,无法自动穿越防火墙。实例:网络互动游戏。
以上是四种请求方式的介绍和优缺点比较。
看过这方面的一些技术介绍, 借鉴了下各位大虾的实践经验总结,抛砖引玉吧。
长轮循是客户端发起的,间隔一定的时间向服务器请求事件,AJAX前端实现方式。优点:就是不需要保持和服务器一直联系, 资源占用会少一些缺点:可能会产生比较多的请求, 或请求失败造成的数据混乱。
长连接服务器和客户端会保持一个长久的联系。优点:数据更新即时性好,体验流畅。缺点:对服务器的资源会有一个占用,所以相对占用资源比较大,另外HTTP长连接有时效性,不是可靠连接。
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
暂无简介
文章 0 评论 0
接受
发布评论
评论(9)
长轮询是指上次说的“服务器推”技术吧,我觉得这个很不错啊,对于客户端来说无所谓,对服务端来说可以支持比socket高很多的人数,没用过缺点不清楚,可能会有http请求超时之类的各种情况要处理吧
长连接 目前就是google 的comet 使用http 负载量大了以后很难处理
现在有出现了 Server-Sent Events html5的浏览器增加一个事件.
然后就是socket, 常规的就是用flash里面的xmlsocket类 来达到访问socket服务器的目的.
现在html5又增加了 websocket
只有socket才是真正的主动推送. 其他都是前端轮询+后端轮询. 结合nodejs 的socket.io 做实时推送的很多. 但为了兼容主流的浏览器很多框架都是多种技术根据浏览器不同融合使用.
WebSockets vs Server-Sent Events vs Long-polling
http://dsheiko.com/weblog/websockets-vs-sse-vs-long-polling
http://www.oschina.net/question/82993_63312
不知道提问者是想知道长连接还有短连接的区别,还是轮询与通知的区别。问题有点歧义,我在长连接的基础上也可以实现长轮询。
我就当问题是长连接和短连接吧。
我在大家的基础上补充一个很重要的一个特性。因为短连接轮询,每次都需要重新解析域名,然后连到HTTP服务器,所以如果你打算热扩展,那选短连接轮询再好不过了。
武侠的游戏服可以不停服增加或者减少服务器,就是因为跟后面的业务HTTP服务器用的是短连接。当发现负载很重的时候,可以在玩家毫无感知的情况下,增加若干台服务器。如果用长连接,这个过程无法做到很平滑。另外如果是有一台机器挂掉了,也可以快速的切到备用机器上面,长连接似乎不那么好做。
即使tcp长连接的情况下,也要定时的发心跳包的。
看你需要什么样的应用了。若是BS模式的是采用轮询,若是CS模式的应用就采用长连接。手机App应该就需要考虑网络情况而决定那种模式更适合。
要看你的应用,若交互的数据量并不大,采用UDP的方式,因为TCP方式即时没有数据交互,也会有定时保活、测试信道拥塞等机制。若客户端很多,可以采用多播的方式,不用每个都建立 UDP 连接。而且可以采用服务器定时多播通知的方式,省掉诸多客户端轮询。可以参考@对于一个具有几百万粉丝的用户,数据如何实时投递到所有用户?
若数据量很大,且要求稳定传送(出错率很小),采用TCP长连接。
长连接的好处是可以用tcp的机制实现一个有状态的过程,但是维护该连接需要资源,而轮询的好处是灵活性,一般的大用户低流量都采用轮询的方式。有一种 socket 叫 T/TCP,特性介于 tcp 和 udp 之间,是个很好的选择,见 T/TCP
在网上查了一下资料,发现轮询和长轮询还有不同的定义:
轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。
优点:后端程序编写比较容易。
缺点:请求中有大半是无用,浪费带宽和服务器资源。
实例:适于小型应用。
长轮询:客户端向服务器发送Ajax请求,服务器接到请求后hold住连接,直到有新消息才返回响应信息并关闭连接,客户端处理完响应信息后再向服务器发送新的请求。
优点:在无消息的情况下不会频繁的请求。
缺点:服务器hold连接会消耗资源。
实例:WebQQ、Hi网页版、Facebook IM。
另外,对于长连接和socket连接也有区分:
长连接:在页面里嵌入一个隐蔵iframe,将这个隐蔵iframe的src属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。
优点:消息即时到达,不发无用请求。
缺点:服务器维护一个长连接会增加开销。
实例:Gmail聊天
Flash Socket:在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信,JavaScript在收到服务器端传送的信息后控制页面的显示。
优点:实现真正的即时通信,而不是伪即时。
缺点:客户端必须安装Flash插件;非HTTP协议,无法自动穿越防火墙。
实例:网络互动游戏。
以上是四种请求方式的介绍和优缺点比较。
看过这方面的一些技术介绍, 借鉴了下各位大虾的实践经验总结,抛砖引玉吧。
长轮循是客户端发起的,间隔一定的时间向服务器请求事件,AJAX前端实现方式。
优点:就是不需要保持和服务器一直联系, 资源占用会少一些
缺点:可能会产生比较多的请求, 或请求失败造成的数据混乱。
长连接服务器和客户端会保持一个长久的联系。
优点:数据更新即时性好,体验流畅。
缺点:对服务器的资源会有一个占用,所以相对占用资源比较大,另外HTTP长连接有时效性,不是可靠连接。