在什么情况下,AJAX长/短轮询优先于HTML5 WebSockets？

Question

在什么情况下,AJAX长/短轮询优先于HTML5 WebSockets？

som*_*dow 298 javascript ajax html5 network-protocols websocket

我正在为朋友建立一个小型聊天应用程序,但不确定如何及时获取信息,而不是手动或基本上强制刷新页面.

目前,我正在使用简单的AJAX实现这一点,但这有一个缺点,即当一个短计时器过去时经常点击服务器.

在研究长/短轮询时,我遇到了HTML5 WebSockets.这似乎很容易实现,但我不确定是否存在一些隐藏的缺点.例如,我认为WebSockets仅受某些浏览器的支持.我应该注意WebSockets还有其他缺点吗？

既然两种技术似乎都做同样的事情,那么在哪种情况下,人们更愿意使用其中一种？更具体地说,HTML5 WebSockets使AJAX长/短轮询过时,还是有令人信服的理由更喜欢AJAX而不是WebSockets？

Answer 1

mok*_*oka 500

WebSockets绝对是未来.

长轮询是一种肮脏的解决方法,可以防止像AJAX那样为每个请求创建连接 - 但是当WebSockets不存在时会创建长轮询.现在由于WebSockets,长时间的轮询正在消失.

WebRTC允许对等通信.

我建议学习WebSockets.

比较:

网上不同的沟通技巧

AJAX - request→ response.创建与服务器的连接,发送带有可选数据的请求标头,从服务器获取响应,以及关闭连接. 在所有主流浏览器中都支持
长轮询 - request→交通wait→交通response.像AJAX一样创建与服务器的连接,但保持keep-alive连接打开一段时间(不长).在连接期间,打开的客户端可以从服务器接收数据.由于超时或数据eof,客户端必须在连接关闭后定期重新连接.在服务器端,它仍被视为HTTP请求,与AJAX相同,除了请求的答案现在或将来某个时间由应用程序逻辑定义. 支持图表(完整) | 维基百科
WebSockets - client↔ server.创建与服务器的TCP连接,并根据需要保持打开状态.服务器或客户端可以轻松关闭连接.客户端经历HTTP兼容的握手过程.如果成功,则服务器和客户端可以随时在两个方向上交换数据.如果应用程序需要以两种方式频繁进行数据交换,则效率很高.WebSockets确实有数据框架,包括屏蔽从客户端发送到服务器的每条消息,因此数据只是加密. 支持图表(非常好) | 维基百科
WebRTC - peer↔ peer.传输以在客户端之间建立通信并且与传输无关,因此它可以使用UDP,TCP甚至更抽象的层.这通常用于大容量数据传输,例如视频/音频流传输,其中可靠性是次要的,并且可以牺牲几帧或质量进展的降低以支持响应时间,并且至少有一些数据传输.双方(同行)可以独立地将数据推送到彼此.虽然它可以完全独立于任何集中式服务器使用,但它仍然需要某种方式来交换endPoints数据,在大多数情况下,开发人员仍然使用集中式服务器来"链接"对等体.这仅需要交换用于建立连接的基本数据,之后不需要集中式服务器. 支持图表(中) | 维基百科
服务器发送的事件 - client← server.客户端建立与服务器的持久和长期连接.只有服务器才能将数据发送到客户端.如果客户端想要将数据发送到服务器,则需要使用其他技术/协议来执行此操作.该协议与HTTP兼容,并且在大多数服务器端平台上易于实现.这是一种优选的协议,用于代替长轮询.支持图表(好,IE除外) | 维基百科

好处:

WebSockets服务器端的主要优点是,它不是HTTP请求(握手后),而是基于消息的正确通信协议.这使您可以实现巨大的性能和架构优势.例如,在node.js中,您可以为不同的套接字连接共享相同的内存,因此它们每个都可以访问共享变量.因此,您不需要将数据库用作中间的交换点(例如使用AJAX或使用PHP之类的语言进行长轮询).您可以将数据存储在RAM中,甚至可以直接在套接字之间重新发布.

安全考虑

人们经常关注WebSockets的安全性.实际情况是它几乎没有什么区别,甚至将WebSockets作为更好的选择.首先,使用AJAX,MITM的可能性更高,因为每个请求都是穿越互联网基础设施的新TCP连接.使用WebSockets,一旦连接它,在它们之间进行拦截就更具挑战性,当数据从客户端传输到服务器时额外强制执行帧屏蔽以及额外压缩,这需要更多的工作来探测数据.所有现代协议都支持:HTTP和HTTPS(加密).

PS

请记住,WebSockets通常具有非常不同的逻辑网络方法,更像是实时游戏,而不像http.

这不是关于它自身的兼容性.最重要的是,它将完全重新思考沟通的方式.由于RESTful API与Request> Response模式一起使用,因此这里的双向通信将毫无意义.因此,尝试使用WebSockets来查询RESTful API - 尝试有点奇怪,并且根本无法看到它的任何好处.如果您需要RESTful API中的数据,但需要实时方式,那么您可以创建WebSockets api来推送可以使用WebSockets等双向通信的数据.你试图比较它们无法比较的角度:) (15认同)
@bagz_man Long Polling是一种"hacky"技术,用于实现技术根据定义不允许的结果,而不是标准替代品.Long Polling存在的原因正是WS没有,Period. (5认同)
长轮询不是一种肮脏的解决方法,它与webSocket不同.这两个用于不同的场景. (4认同)
@moka:Cloudflare的*免费等级*将吸收持续的400 + Gbps攻击.您的钱包可以吸收AWS账单吗？在处理针对您的来源的投诉时,AWS和Cloudflare也有相反的观点.只要我们讨论权衡,这只是要记住的事情.:) (4认同)
嗨@pithhelmet这一切都取决于它自己的服务器端软件(语言/技术).WebSocket是基于TCP的层,有许多方法可以进行TCP流实现.现代Web服务器使用基于事件的体系结构,并且对于线程池非常有效.你正在使用哪种技术？Node.js在幕后使用IO事件,在执行上下文中使用单线程事件,因此效率极高.为每个连接使用线程 - 在RAM(每个线程1mb +)以及CPU方面效率非常低,因为这些线程只是空闲或更糟 - 无限循环检查数据. (2认同)
Web 套接字有许多缺点，例如服务器亲和性、长时间使用服务器资源（1 MB/套接字）、它引入了与无状态 http 相反的状态，并且它带有周期性轮询以进行心跳检查。这就是为什么，在任何可能的情况下：使用短轮询并避免网络套接字。除此之外，对于应用程序来说实时意味着什么？通常这只是一种幻觉，即使我们谈论的是接近实时，与短轮询相比，它对应用程序真正意味着什么？你的回答完全忽略了这一点。 (2认同)

Answer 2

bmm*_*m6o 11

您省略的一项竞争技术是服务器发送事件/事件源. 什么是长轮询,Websockets,服务器发送事件(SSE)和Comet？对所有这些进行了很好的讨论.请记住,其中一些比其他人更容易在服务器端集成.

Answer 3

Bra*_*sen 7

对于聊天应用程序或与服务器不断对话的任何其他应用程序,是WebSockets最佳选择.但是,您只能使用WebSockets支持它们的服务器,因此如果您无法安装所需的库,可能会限制您使用它们的能力.在这种情况下,您需要使用Long Polling以获得类似的功能.

调整一下来解释是的,任何服务器都支持WebSockets.但是,如果您使用托管服务,则可能无法使用它们. (9认同)
每个服务器都支持WebSockets ......您只需要安装node.js或类似的东西. (5认同)

归档时间：	13 年，5 月前
查看次数：	113401 次
最近记录：	6 年，5 月前