Comet----众里寻你千百度

       Comet，基于HTTP长连接的的服务器端推技术。就想当年Ajax横空出世一样，同样的老调新弹，同样的振奋人心。BS的架构，CS的实时体验，效率，代宽。这些问题都有了解决的可能。 

        前几天，拜读了一篇关于网络软件架构的博士论文。其中关于REST的阐述非常精辟。现在回想起来，以前对ASP.NET架构的依赖过于严重了。对于HTTP协议的应用也过于单调。很多值得扩展的地方都没有注意。Comet+REST的解决方案理论上可以解决BS实时监控中的大部分问题。

        首先，在AJAX解决方案中的长轮训方式是一种效率比较差的方案。最好以长连接的Keep-Live取而代之，HTTP/1.1默认就是长连接的TCP。只不过因为是无状态的---既服务器端不保存任何东西，所需的所有资源都必须包含在客户端的请求中。从而导致每一次交互对带宽的占用比较大，从而导致性能的低下。其实HTTP协议本身对维护长连接做得很好，这也是对静态网页而言。由于PHP，JSP，ASP.NET等动态语言的出现。对Respnse信息体的动态修改以及本身的com组件的过滤，使得所有的操作和数据返回都一次性完成，并不需要更多的利用HTTP协议中的长连接，也根本就不需要心跳。但对于实时监控程序来说，重要只是实时性和性能。所以对长连接的维护---心跳检测和传输数据的筛选就非常重要。关于心跳检测，我同意老外们的大致做法，客户端定时通过HTTP协议中的HEAD方法向服务器发送请求。由于服务器对HEAD的响应只有消息头，而没有消息体。所以对代宽的占用要小很多。同时服务端对响应的消息头进行扩展，根据监控的数据的变化在响应消息头中添加相应的指令---也就是告诉客户端去从不同的url地址获取数据。客户端对指令进行解析。从而根据不同的指令获取相应的数据利用DOM在客户端注入。由于对于监控程序来说所有客户端接受的数据都是一样，所以利用服务端缓存技术把每个有效的客户请求结果以对象的方式存储在服务端，从而节省了相同请求的逻辑处理时间。由于交互的只是变化的数据，所以传输的性能应该可以保证。

         现在还有一个问题，就是AJAX长时间频繁请求的性能问题。主要是对于客户端而言，设想用临时页面来完成请求交互。一定时间段后临时页面关闭，打开一个新的临时文件。但是有个疑问就是对容错的处理。怎样保证临时页面出错时及时恢复。

         只是理论上的解决方案，不过感觉没有技术盲点，希望听取大家的意见。