我正在为朋友构建一个小型聊天应用程序,但不确定如何及时获取信息,而这不像强制刷新页面那样手动或基本。
目前,我正在使用简单的AJAX来实现此功能,但是这样做的缺点是,在经过短计时器后会定期命中服务器。
在研究长/短轮询时,我遇到了HTML5WebSockets。这似乎很容易实现,但是我不确定是否存在一些隐藏的缺点。例如,我认为WebSockets仅受某些浏览器支持。我应该知道WebSockets还有其他缺点吗?
既然两种技术似乎都做同样的事情,那么在哪种情况下,一个人会优先使用一个?更具体地说,HTML5 WebSockets是否已使AJAX长/短轮询无效,还是有充分的理由偏爱AJAX而不是WebSockets?
WebSockets绝对是未来。
长轮询是一种肮脏的解决方法,可以防止像AJAX一样为每个请求创建连接- 但是长轮询是在WebSocket不存在时创建的。现在由于WebSockets的原因,长时间的轮询将消失。
WebRTC允许对等通信。
网络上不同的通信技术
AJAX - request→ response。创建与服务器的连接,发送带有可选数据的请求标头,从服务器获取响应,然后关闭连接。 所有主要浏览器均支持。
request
response
长轮询 - request→交通wait→交通response。与AJAX一样,创建与服务器的连接,但保持打开状态的连接保持一段时间(虽然时间不长)。在连接期间,开放客户端可以从服务器接收数据。由于超时或数据丢失,客户端必须在连接关闭后定期重新连接。在服务器端,它仍被视为HTTP请求,与AJAX一样,只是请求的答案将在应用程序逻辑定义的现在或将来的某个时间发生。 支持图(完整) | 维基百科
wait
WebSockets - client↔ server。创建与服务器的TCP连接,并根据需要保持打开状态。服务器或客户端可以轻松关闭连接。客户端经历与HTTP兼容的握手过程。如果成功,则服务器和客户端可以随时在两个方向上交换数据。如果应用程序需要两种方式都进行频繁的数据交换,则效率很高。WebSockets确实具有数据框架,其中包括对从客户端发送到服务器的每条消息的屏蔽,因此仅对数据进行加密。 支持图(非常好) | 维基百科
client
server
WebRTC - peer↔ peer。传输在客户端之间建立通信,并且与传输无关,因此它可以使用UDP,TCP或更抽象的层。这通常用于大量数据传输,例如视频/音频流,其中可靠性是次要的,可以牺牲几帧或降低质量进度,以利于响应时间和至少一些数据传输。双方(对等方)可以相互独立地推送数据。尽管它可以完全独立于任何集中式服务器使用,但仍需要某种交换端点数据的方法,在大多数情况下,开发人员仍使用集中式服务器“链接”对等节点。仅在交换用于建立连接的基本数据时才需要此操作,此后不需要中央服务器。 支持图(中) | 维基百科
peer
服务器发送的事件 - client← server。客户端建立与服务器的持久和长期连接。只有服务器可以将数据发送到客户端。如果客户端要向服务器发送数据,则需要使用另一种技术/协议。该协议是HTTP兼容的,并且在大多数服务器端平台中都易于实现。这是代替长轮询使用的首选协议。支持图(除IE以外,其他都不错) |维基百科
WebSockets 服务器端的主要优点是,它不是HTTP请求(握手后),而是基于消息的正确通信协议。这 使您可以获得巨大的性能和体系结构优势 。例如,在node.js中,您可以为不同的套接字连接共享相同的内存,因此它们可以访问共享变量。因此,您不需要在中间使用数据库作为交换点(例如使用AJAX或使用PHP之类的LongPolling)。您可以将数据存储在RAM中,甚至可以立即在套接字之间重新发布。
人们经常担心WebSocket的安全性。现实情况是,它几乎没有什么不同,甚至使WebSockets成为更好的选择。首先,使用AJAX,MITM的可能性更高,因为每个请求都是一个遍历Internet基础结构的新TCP连接。使用WebSockets,一旦连接起来,在两者之间进行拦截就变得更具挑战性,另外,当数据从客户端流传输到服务器时,还需要强制执行帧屏蔽以及额外的压缩,这需要更多的精力来探查数据。 所有现代协议都支持:HTTP和HTTPS(加密)。
请记住,WebSocket通常具有非常不同的网络逻辑方法 ,更像是实时游戏一直都在使用,而不像http。