AJAX模拟HTTP LongPoll 实现“服务器推”技术.pdfVIP

文档来源： 核心图解： 最近在看 服务器推送技术”，在B/S 结构中，通过某种magic 使得客户端不需要通过轮询即 可以得到服务端的最新信息 （比如股票价格，聊天 室，webQQ、开心网、白社会），这样 可以节省大量的带宽。 传统的轮询技术对服务器的压力很大，并且造成带宽的极大浪费。如果改用aj ax 轮询，可 以降低带宽的负荷（因为服务器返回的不是完整页面），但 对服务器 的压力并不会有明显 的减少。 而推技术（push）可以改善这种情况。但因为HTTP 连接的特性（短暂，必须由客户端发起）， 使得推技术的实现比较困难，常见的做法 通过延长http 连接的寿命，来实现push。 本实现原理： 接下来自然该讨论如何延长 http 连接的寿命，最简单的自然 死循环法，如果使用观察者 模式则可以进一步提高性能。 但 这种做法的缺点在于客户端请求了这个 servlet 后，web 服务器会开启一个线程执行 servlet 的代码，而servlet 由迟迟不肯结束，造成 该线程也无法被释放。于是乎，一个客户 端一个线程，当客户端数量增加时，服务器依然会承受很大的负担。 要从根本上改变这个现象比较复杂，目前的趋势 web 服务器内部入手，用nio （JDK 1.4 提出的j ava.nio 包）改写request/response 的实现，再利用线程池增强服务器的资源利用率， 而解决这个问题，目前支持这一非 J2EE 官方技术的服务器有Glassfish 和Jetty 。目前也 有一些框架/工具可以帮助你实现推功能，比如 pushlets 。不过没有深入研究。还 有就 通 过设置超时来解决。 在客户和服务器之间保持 心跳”信息 —–无事件导致超时处理： 因为服务器为了保持请求 （阻塞请求），必须有一个无限循环，循环的结束条件就 获取到 了返回结果，如果客户端关闭了（客户端浏览器的关闭不会发消息给服务 器），服务器无法 知道客户端已经关了，这个请求没必要处理下去了，最终会造成资源过度浪费。还有服务器 中间可能存在各式各样配置怪异的网关和代理，它们上 面可能有各式各样的超时规则，因 此 Comet 最好设计为定期重连。只要用一个折中的办法，限制超时时间。一般情况下，如 果30 秒没有 何事件发生，服务器 端就应该通知客户端确实没有事件发生，结束掉本次请 求，然后重新开始一次新的请求以便继续等待。这里可以不必设置客户端aj ax 的超时时间， 但进行请求的 时候传递一个超时值给服务器，服务器在处理的时候，如果超时时间到了的 话，还没有客户端需要的结果，这时传递一个超时信息给客户端，客户端接收到了此信 息， 根据情况重新进行aj ax 请求，也就是进入下一个轮询……….当服务器处理信息出现异常情 况，需要发送错误信息通知客户端，同时释放资源、关闭连接。 文档来源： 文档来源： 服务器端事件队列管理以及如何保持可靠的消息队列: 由于aj ax 的LongPoll 拉的方式(不同的客户端拉取的参数可以根据客户端不同而不同)， 服务器端根据客户选择的方式在读取事件队列 （fetchEvents ）时进行不同的处理，会把 heartbeat”与 refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。 拉的同 时也解决了发送目标的返回值。 在这里我们可以想象一个可能发生的情况，服务器端向你发送一个消息，你没有成功接收， 但 服务器端认为发送了就成功了，消息 队列删除了，然后这个消息就 永久丢失掉了。 可能有人会强调TCP 多么可靠，服务器端发送的消息如果在TCP 的层面发生问题了，肯定 会引发Socket 级别的Exception，这个 Exception 冒泡上来，服务器端就能截获， 而得知 发送失败，然后先不删除队首消息。可 别忘了，中间 可能存在代理的，如果代理成功把 消息收回去 了，可是代理发送到客户端这一步失败了，服务器端就不一定会发生异常了。 因此，我们需要制定一种策略，来确保下行消息总能发送到客户端。在这里，我们选择了引 入逐个 ACK 的机制，来确认消息的接收。也就 说，服务器端发送给客 户端的消息带有 一个序号，在客户端收到消息后就将该序号发回给服务器端，已确认它受到了该消息。在下 次请求时就将该序号加1 的值通过sequence 参