图片出自Sun 科技日2008-2009 2008年11月22日 星期六\使用Comet和Ajax开发网络应用 首先进行简单的描述 第一种情况 polling 可以解释为轮训，类似心跳检测的方式。 只客户端按照一定的时间间隔定期请求服务器，在这个过程中可能没有任何事情发生，此时的操作完全是浪费网络资源。不过这也是最简单、最容易理解的方式。 其存在的缺点也是不言而喻，首先是请求的间隔控制，间隔太久就会失去意义，间隔太短就会额外增加服务器的压力。最最关键的是其无法保证服务器事件的实时性，即你不能保证服务器上事件发生的时候客户端可以及时检测到。 第二种方式 long poll 可以解释为长轮询，即服务端阻断前一次对客户端的回应，在事件发生后将事件内容绑定在回应中返回给客户端，同时回应结束，此时客户端立即发送第二次请求，服务器阻塞回应等待下一次事件发生。 此方法与第一种方法相比已经增色不少，大大降低了网络的利用率，即在没有事件的前提下，理论上没有数据交互，同时也是最最重要的一点是它体现了很强的实时性，即服务器端发生事件后客户端能第一时间收到信息。 第三种stream 没有合适的翻译。 按照现有的技术判断，这已经是终极了。即服务器阻断客户端的回应，和第二种方式相似，重要的是服务器没有关闭回应而是一直保留这这个到客户端的输出流。与第二种相比确实是一个很到的进步。 但是第三种方式是理论上的，实际的应用中不需结合第二种，即超时和连接验证等等。 按照之前我的测试在IE下(IE6)是不能支持第三种情况，所以在IE6下要使用第二种情况，因此在IE下超时判断就和连接判断融合在一起。但是在FireFox下还要单独做超时判断。 搜狗西奈(联想取词的方法有时候很恶心啊)。 在此关于业界支持和具体技术评测请参见Sun 科技日2008-2009\2008年11月22日 星期六\使用Comet和Ajax开发网络应用 中的演讲内容和演讲ppt转换的发行版pdf：4_TD09_Comet_Doris_Beijing.pdf 图片出自Sun 科技日2008-2009 2008年11月22日 星期六\使用Comet和Ajax开发网络应用 首先进行简单的描述 第一种情况 polling 可以解释为轮训，类似心跳检测的方式。 只客户端按照一定的时间间隔定期请求服务器，在这个过程中可能没有任何事情发生，此时的操作完全是浪费网络资源。不过这也是最简单、最容易理解的方式。 其存在的缺点也是不言而喻，首先是请求的间隔控制，间隔太久就会失去意义，间隔太短就会额外增加服务器的压力。最最关键的是其无法保证服务器事件的实时性，即你不能保证服务器上事件发生的时候客户端可以及时检测到。 第二种方式 long poll 可以解释为长轮询，即服务端阻断前一次对客户端的回应，在事件发生后将事件内容绑定在回应中返回给客户端，同时回应结束，此时客户端立即发送第二次请求，服务器阻塞回应等待下一次事件发生。 此方法与第一种方法相比已经增色不少，大大降低了网络的利用率，即在没有事件的前提下，理论上没有数据交互，同时也是最最重要的一点是它体现了很强的实时性，即服务器端发生事件后客户端能第一时间收到信息。 第三种stream 没有合适的翻译。 按照现有的技术判断，这已经是终极了。即服务器阻断客户端的回应，和第二种方式相似，重要的是服务器没有关闭回应而是一直保留这这个到客户端的输出流。与第二种相比确实是一个很到的进步。 但是第三种方式是理论上的，实际的应用中不需结合第二种，即超时和连接验证等等。 按照之前我的测试在IE下(IE6)是不能支持第三种情况，所以在IE6下要使用第二种情况，因此在IE下超时判断就和连接判断融合在一起。但是在FireFox下还要单独做超时判断。 搜狗西奈(联想取词的方法有时候很恶心啊)。 在此关于业界支持和具体技术评测请参见Sun 科技日2008-2009\2008年11月22日 星期六\使用Comet和Ajax开发网络应用 中的演讲内容和演讲ppt转换的发行版pdf：4_TD09_Comet_Doris_Beijing.pdf