comet

阅读目录(Content) ①轮询 ②长轮询（comet） ③长链接（SSE） ④WebSocket 四种web即时通信技术比较 　Web端即时通讯技术：即时通讯技术简单的说就是实现这样一种功能：服务器端可以即时地将数据的更新或变化反应到客户端，例如消息即时推送等功能都是通过这种技术实现的。但是在Web中，由于浏览器的限制，实现即时通讯需要借助一些方法。这种限制出现的主要原因是，一般的Web通信都是浏览器先发送请求到服务器，服务器再进行响应完成数据的现实更新。 　　实现Web端即时通讯的方法：实现即时通讯主要有四种方式，它们分别是轮询、长轮询(comet)、长连接(SSE)、WebSocket。它们大体可以分为两类，一种是在HTTP基础上实现的，包括短轮询、comet和SSE；另一种不是在HTTP基础上实现是，即WebSocket。下面分别介绍一下这四种轮询方式，以及它们各自的优缺点。 ①轮询 　　短轮询的基本思路就是浏览器每隔一段时间向浏览器发送http请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。 　　这种方式的优点是比较简单，易于理解，实现起来也没有什么技术难点。缺点是显而易见的

我正在创建到HTTP服务器的一些挂起的连接（comet，反向ajax等）。 一切正常，但我看到浏览器仅允许同时暂停到给定域的两个连接。 因此，如果用户在浏览器的Tab1中查看我的网站，然后又尝试在Tab2中加载该网站，则他们已经用完了两个允许访问我的网站的连接。 我想我可以做一些通配符域的事情，在这里我的HTTP服务器可以将网站的任何地址解析为： *.example.com/webapp -> 192.0.2.1 (the actual ip of my server) 所以： a.example.com/webapp b.example.com/webapp c.example.com/webapp 所有这些都仍然指向（ www.example.com/webapp ），但是浏览器认为它们是不同的域，因此我没有遇到2个连接限制。 这是真的？ 即使 是 这样-在所有域中，每个浏览器的活动连接数是否有限制？ 说我使用上述方案-例如Firefox是否在任何给定时间仅允许24个并行连接？ 就像是： 1) a.example.com/webapp 2) www.download.example/hugefile.zip 3) b.example.com/webapp 4) c.example.com/webapp ... 24) x.example.com/webapp 25) //

前言 通常情况下，无论是web浏览器还是移动app，我们与服务器之间的交互都是主动的，客户端向服务器端发出请求，然后服务器端返回数据给客户端，客户端浏览器再将信息呈现，客户端与服务端对应的模式是: 客户端请求--服务端响应，这种机制对于信息变化不是特别频繁的应用尚可，但对于实时要求高、海量并发的应用来说显得捉襟见肘，尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是 Web 应用经常面临的问题，比如金融证券的实时信息，Web 导航应用中的地理位置获取，社交网络的实时消息推送，新闻的订阅,天气的提醒等。这些情况下，需要服务器主动推送消息给客户端。 那么在这样的模式下,会有几个问题需要我们思考下: 1.应用服务器如何确定每一个应用所在的设备 2.服务器端是如何将消息推送到客户端的，客户端又不像服务器有一个固定的地址 带着这些疑问我们来研究一下目前有哪些技术可以解决该问题： 一、Ajax轮询 所谓的Ajax轮询，其实就是定时的通过Ajax查询服务端，客户端按规定时间定时像服务端发送ajax请求，服务器接到请求后马上返回响应信息并关闭连接。 这种技术方式实现起来非常简单，但是这种方式会有非常严重的问题，就是需要不断的向服务器发送消息询问，这种方式会对服务器造成极大的性能浪费。 还有一个类似的轮询是使用JSONP跨域请求的方式轮询，在实现起来有差别，但基本原理都是相同的

前言 通常情况下，无论是web浏览器还是移动app，我们与服务器之间的交互都是主动的，客户端向服务器端发出请求，然后服务器端返回数据给客户端，客户端浏览器再将信息呈现，客户端与服务端对应的模式是: 客户端请求--服务端响应，这种机制对于信息变化不是特别频繁的应用尚可，但对于实时要求高、海量并发的应用来说显得捉襟见肘，尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是 Web 应用经常面临的问题，比如金融证券的实时信息，Web 导航应用中的地理位置获取，社交网络的实时消息推送，新闻的订阅,天气的提醒等。这些情况下，需要服务器主动推送消息给客户端。 那么在这样的模式下,会有几个问题需要我们思考下: 1.应用服务器如何确定每一个应用所在的设备 2.服务器端是如何将消息推送到客户端的，客户端又不像服务器有一个固定的地址 带着这些疑问我们来研究一下目前有哪些技术可以解决该问题： 一、Ajax轮询 所谓的Ajax轮询，其实就是定时的通过Ajax查询服务端，客户端按规定时间定时像服务端发送ajax请求，服务器接到请求后马上返回响应信息并关闭连接。 这种技术方式实现起来非常简单，但是这种方式会有非常严重的问题，就是需要不断的向服务器发送消息询问，这种方式会对服务器造成极大的性能浪费。 还有一个类似的轮询是使用JSONP跨域请求的方式轮询，在实现起来有差别，但基本原理都是相同的

前言 通常情况下，无论是web浏览器还是移动app，我们与服务器之间的交互都是主动的，客户端向服务器端发出请求，然后服务器端返回数据给客户端，客户端浏览器再将信息呈现，客户端与服务端对应的模式是: 客户端请求--服务端响应，这种机制对于信息变化不是特别频繁的应用尚可，但对于实时要求高、海量并发的应用来说显得捉襟见肘，尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是 Web 应用经常面临的问题，比如金融证券的实时信息，Web 导航应用中的地理位置获取，社交网络的实时消息推送，新闻的订阅,天气的提醒等。这些情况下，需要服务器主动推送消息给客户端。 那么在这样的模式下,会有几个问题需要我们思考下: 1.应用服务器如何确定每一个应用所在的设备 2.服务器端是如何将消息推送到客户端的，客户端又不像服务器有一个固定的地址 带着这些疑问我们来研究一下目前有哪些技术可以解决该问题： 一、Ajax轮询 所谓的Ajax轮询，其实就是定时的通过Ajax查询服务端，客户端按规定时间定时像服务端发送ajax请求，服务器接到请求后马上返回响应信息并关闭连接。 这种技术方式实现起来非常简单，但是这种方式会有非常严重的问题，就是需要不断的向服务器发送消息询问，这种方式会对服务器造成极大的性能浪费。 还有一个类似的轮询是使用JSONP跨域请求的方式轮询，在实现起来有差别，但基本原理都是相同的

转自：http://www.cnblogs.com/study-everyday/p/6140498.html 通常情况下,打开网页或app去查询或者刷新时，客户端向服务器发出请求然后返回数据,客户端与服务端对应的模式是: 客户端请求--服务端响应, 而在有些情况下,服务端会主动推送一些信息到客户端,例如:新闻的订阅,天气的提醒等等,那么在这样的模式下,会有些问题值得思考: 1.应用服务器如何确定每一个应用所在的设备 2.服务端把消息推到哪，客户端又不像服务器有一个固定的地址 服务端主动推送到客户端是怎么一个过程? 结合一个实际问题分析下: 问题提出: 外卖app, 商家在商家后台需要实时的获取到有没有新订单，有的话是几个；这个需求类似与日常中使用QQ或者微信时的新信息提醒一样，只要有新信息就需要提醒 最近工作中遇到一个场景，商家在商家后台需要实时的获取到有没有新订单，有的话是几个；这个需求类似与日常中使用QQ或者微信时的新信息提醒一样，只要有新信息就需要提醒；商家基本在PC上使用，各式浏览器都有:如 IE系列（7.0，8.0，9.0及以上），chrome内核，firefox等；功能所属的部署在Tomcat 6.0上，如果技术需要可以部署到 Tomcat 7.0上; 我们先做做技术调研，这种浏览器与服务器实时通信的方式有哪些方式。 AJAX轮询 这是我们最自然想到的。

通常情况下，打开网页或app去查询或者刷新时，客户端向服务器发出请求然后返回数据,客户端与服务端对应的模式是: 客户端请求--服务端响应, 而在有些情况下,服务端会主动推送一些信息到客户端,例如:新闻的订阅,天气的提醒等等,那么在这样的模式下,会有些问题值得思考: 1）应用服务器如何确定每一个应用所在的设备？ 2）服务端把消息推到哪，客户端又不像服务器有一个固定的地址？ 3）服务端主动推送到客户端是怎么一个过程? 假设一个场景，商家在商家后台需要实时的获取到有没有新订单，有的话是几个；这个需求类似与日常中使用QQ或者微信时的新信息提醒一样，只要有新信息就需要提醒；商家基本在PC上使用，各式浏览器都有：如 IE系列（7.0，8.0，9.0及以上），chrome内核，firefox等；功能所属的部署在Tomcat 6.0上，如果技术需要可以部署到 Tomcat 7.0上。 这种浏览器与服务器实时通信的方式有哪些方式。 1、AJAX轮询 这是我们最自然想到的。 采用 常规AJAX轮询 的方式，每10s或者30s轮询一次，既可以判断出有有多少个新订单进入，且这种时间间隔对于消息提醒也是可以接受的。这种技术方式实现起来非常简单，目前的机器都是可以机器的，前端浏览器也都支持。 但是这种方式会有非常严重的问题，就是需要不断的向服务器发送消息询问，如果有1w个商家打开了浏览器，采用10s轮询的方式

问： 难道只能设置定时器每隔一秒通过 Ajax 向后台请求数据来实现吗？ 答： 1、 nodejs的 http://socket.io 支持上述 李宏训 所说的三种方式，另外还支持 Flash Socket、隐藏IFrame、JSONP Polling等方式。http://Socket.io提供前端和服务器端的配套机制，并兼容各种浏览器，它的前端js模块会判断浏览器的能力，自适应选择最合适的Comet方式。 2、 我知道有三种方式： 1，ajax短连接：客户端每隔一秒钟发一次请求，服务器收到请求后会立刻返回结果，不管有没有新数据。 2，ajax长连接：客户端发送一次请求，服务器端收到请求后查询有没有新数据，如果没有新数据就阻塞这个请求，直到有新数据或者超时为止。客户端每次收到请求返回结果后立刻再发一次请求。comet貌似就是这个原理。 3，WebSocket：这就不是一个HTTP协议了，而是一个tcp协议，而且Socket这个玩意顾名思义就是一个流了，可以双向操作。缺点是有些浏览器不支持。 对比延迟： 假设网络延迟是m毫秒，那么ajax短连接的延迟在m到1000毫秒之间，另外两种基本只有m毫秒的延迟。 对比资源占用： 应该是1>2>3。但是1和2的比较要看情况，如果两次请求间隔时间很长的话应该是2>1>3。 3、 用comet,其实也是ajax 了。 只是前端发送一个请求后