webSocket入门_【SamDeng】技术分析.pptVIP

服务器推送技术 主讲人：邓效尧 邮箱：samtribiani@163.com Polling Comet Websocket ...... “服务器推送技术的背景 Polling 实现方式 Comet实现方式(Long Polling,Stream) Websocket 实现方式 1 2 3 4 Polling 实现方式 “服务器推送技术的背景 “服务器推送技术的背景 传统的 Web 应用的信息交互过程通常是客户端通过浏览器发出一个请求，服务器端接收和审核完请求后进行处理并返回结果给客户端，然后客户端浏览器将信息呈现出来 可以看出来，所有的这些请求，只能是客户端主动发送请求，服务端才能返回信息 “服务器推送技术的背景 这种机制对于信息变化不是特别频繁的应用尚能相安无事，但是对于那些实时要求比较高的应用来说 譬如： 监控系统：后台硬件热插拔、LED、温度、电压发生变化； 即时通信系统：在线聊天室，在线游戏； 即时报价系统：在线证劵； 都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求. 在 WebSocket 规范出来之前，开发人员想实现这些实时的 Web 应用，不得不采用一些折衷的方案. 其中最常用的就是轮询 (Polling) 和 Comet 技术,还有Flash技术. Long Polling Polling Polling 这是最早的一种实现实时web应用的方案；原理比较简单易懂，就是客户端以一定的时间间隔向服务器发送请求，以频繁请求的方式来保持客户端和服务器端的数据同步。 缺点：当客户端以固定频率向服务器端发送请求时，服务器端的数据可能并没有更新，这样会带来很多无谓的请求，浪费带宽，效率低下。 Streaming Long Polling Long Polling Long Polling是对Polling的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者时间过期，通过这种机制来减少无效的客户端和服务器间的交互 当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提高。 Streaming Streaming Streaming 流技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。 这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。 总结 综合这几种方案，除了基于flash的方案外,您会发现这些目前我们所使用的所谓的实时技术并不是真正的实时技术，它们只是在用 Ajax 方式来模拟实时的效果，在每次客户端和服务器端交互的时候都是一次 HTTP 的请求和应答的过程，而每一次的 HTTP 请求和应答都带有完整的 HTTP 头信息，这就增加了每次传输的数据量，而且这些方案中客户端和服务器端的编程实现都比较复杂，在实际的应用中，为了模拟比较真实的实时效果，开发人员往往需要构造两个 HTTP 连接来模拟客户端和服务器之间的双向通讯，一个连接用来处理客户端到服务器端的数据传输，一个连接用来处理服务器端到客户端的数据传输，这不可避免地增加了编程实现的复杂度，也增加了服务器端的负载，制约了应用系统的扩展性。这些解决方案都存在一个共同的问题：它们带有 HTTP 的开销，导致它们不适用于低延迟应用。可以想象一下浏览器中的多人第一人称射击游戏，或者其他任何带有即时要素的在线游戏。在流量较大情况下，以上两种方式都需要较大的性能开销。因为每次请求及应答都需要带上完整的Http头，明显增加了每次传输的数据量。实现上也相对复杂。 End Websocket Websocket 流技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。 这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。