comet的实质

实际上comet也不能完全算作长连接，只是比一般的连接长一点。

当然这是推荐作法，太长的连接是不合适的，无论从通过性还是安全性，还是性能角度来讲，都是不好的。

不象以前的CGI聊天室，总是用长连接来实现不断更新的。现代的comet比较适合的做法是一段一段的长连接。

这象什么呢？很象光的传播。光是不连续的，一段一段的量子所构成，所以有波粒两象性。

扯远了。

比较好的做法是:

发起一个ajax request
-> service 收到，处理（这个处理可能是订阅了message，也可能是轮询，反正是要得到更新数据，必须有一个timeout，一般是30s）
-> 数据有了更新，或者是timeout，返回到ajax
->ajax接收到，处理（如果是timeout则说明没更新数据，有数据就显示或其他处理）
->停一下（ms级），再发起一个ajax request
然后就重复...再重复再重复

comet就这样来了。

每次有一个较长的连接（30s），一旦数据来了，立刻返回（在service里）。既保证了实时性，又减少了轮询的无效request，也避免了长连接的各种问题。

轮询必然设定一个较短的时间（1-2s），不断地发起request，这样产生了大量的无效request。

长连接限制了server的连接能力，也有安全性和通过性的问题。

不过最好的是根据业务来精确地调整timeout时间和休息时间，有点智能吧。