长轮询与WebSockets的优缺点(长轮询和WebSockets哪个更好)

Web应用程序最初设计为客户端-服务器架构。客户端向指定的服务器发出 HTTP/HTTPS 请求,请求或修改信息。例如,一个基本的网络应用程序将遵循类似的流程。

  • 客户端向服务器请求数据
  • 负载平衡器将请求路由到相应的服务器
  • 服务器向相应的数据库查询某些数据
  • 数据库将查询到的数据返回给服务器
  • 服务器处理数据并将数据发送回客户端

简单的 HTTP 请求是接收服务器信息的最常见方式。但是,如果您想在数据添加到数据库或发送到服务器后立即获取数据呢?对于设计为客户端-服务器架构的基本网络应用程序,您必须一遍又一遍地重复这一过程,以检查是否有新信息添加到数据库中。这个过程被称为轮询,有时也称为短轮询。这种方法的缺点是,由于服务器没有收到任何新信息,所以大部分时间都不会返回数据。让我们来解决这个问题,并讨论一下长轮询和 Websockets 的优缺点。

概述: 长轮询与 WebSockets

长轮询

长轮询是一种客户端向服务器发送 API 请求的方法,但客户端不会立即收到服务器的响应,而是需要保持 HTTP 连接。保持 HTTP 连接可使服务器在数据可用或达到超时阈值时稍后回复。收到响应后,客户端会立即发送后续请求。

客户端只需向服务器发送一次请求即可获得最新信息,而无需像轮询那样反复发送大量请求直到服务器收到新信息。收到数据后,客户端可以发起新的请求,并根据需要不断重复这一过程。

长轮询的流程如下:

  • 客户端向服务器发出 HTTP 请求,请求获取某些数据
  • 服务器不会立即回应所请求的信息,而是等待新信息的出现
  • 当新数据可用时,服务器响应新信息
  • 客户端收到该数据后立即向服务器发送另一个请求,重新启动该过程
长轮询与WebSockets的优缺点(长轮询和WebSockets哪个更好)

WebSockets

WebSockets 是一种建立在设备 TCP/IP 协议栈之上的现代技术。WebSockets 与 HTTP 协议的唯一关系是,HTTP 服务器通过握手来建立连接。它是一种双向、全双工的协议,是有状态的,这意味着客户端和服务器之间的连接将持续到任何一方决定终止为止。

与仅为半双工解决方案的长轮询不同,在从服务器接收到最新信息后,该过程无需重复。WebSocket 技术允许我们在返回新信息后保持连接,并执行双向更新。客户端可以向服务器发送信息,并在同一请求中监听进一步的信息。

WebSocket 连接流程如下所示:

  • 客户端通过发送包含升级标头的请求启动 WebSocket,将通信协议切换为 WebSocket 协议。
  • 如果服务器能建立连接并同意客户端的条件,则向客户端发送一个确认 WebSocket 握手请求的响应。
  • 一旦客户端收到成功的 WebSocket 连接,客户端和服务器就可以开始双向发送数据,从而实现实时通信。
  • 服务器或客户端决定终止连接。
长轮询与WebSockets的优缺点(长轮询和WebSockets哪个更好)

何时选择长轮询?

关于何时使用长轮询协议或 WebSocket 协议存在争议。两者都有各自的优点和局限性,通常用于不同的目的。在本节中,我们将讨论长轮询和 WebSockets 的主要优点。

长轮询与 WebSockets 的优点

兼容性: 长轮询是一种更古老的技术,更多地被用作一种技术,因此它比 WebSockets 更兼容。它建立在 XMLHttpRequest 的基础上,与更广泛的网络浏览器和网络配置保持一致。

网络:在当今的技术条件下,人们会不断切换网络,从 4G 到 LTE 再到 WiFi。必须对 WebSockets 进行配置,以适应网络连接的变化。这种配置是因为连接必须与服务器重新建立,而且在客户端选择关闭连接后无法恢复。对于长轮询,这不是一个问题,因为在预定时间(通常为 20 秒)后,客户端将尝试发送另一个请求,自动重新建立与服务器的连接,而无需像 WebSockets 那样在错误状态下进行处理。

选择长轮询而非 WebSockets 的用例

长轮询和 WebSockets 通常用于需要实时更新的情况。例如应用内聊天、实时定价、地理跟踪和物联网。

在低频实时更新的使用案例中,长轮询比 WebSockets 更有优势。这是因为长轮询是一种需要重新建立连接的半实时解决方案。此外,如上所述,如果用户所处的环境带宽较低或网络提供商不稳定,长轮询的架构可以重新建立连接,而不会带来额外的麻烦。不过,长轮询是一种较老的实时更新技术。因此,它不如 WebSockets 先进和灵活,但对传统系统的支持更多。

何时选择 WebSockets?

WebSockets 的优点

减少资源占用: WebSockets 在客户端和服务器之间保持持久连接,减少了为每次实时更新建立新连接的开销。持续连接减少了客户端和服务器端在网络带宽、内存和 CPU 方面的资源占用,从而实现实时通信。

提高可扩展性: 由于 WebSockets 的性质以及客户端和服务器之间的双向通信,服务器可以实时向客户端推送更新,从而减少发送请求的数量。长时间轮询必须在客户端每次需要新信息时重新建立连接。随着用户群的扩大,这会给单个服务器带来很大压力。

高级功能: WebSockets 提供全双工通信通道,可实现实时数据传输和低延迟。长轮询有时被认为只是一种半实时解决方案,对于高流量场景或需要实时更新的用例来说并不理想。先进的功能可为最终用户带来更流畅的体验,因为他们将收到更多应用程序的无缝更新。

选择 WebSockets 而非长轮询的用例

WebSockets 更适合需要高频更新的应用程序。例如聊天应用程序或实时数据馈送。持久连接可实现高效传输,为最终用户带来更无缝的体验。多人游戏和协作工具通常也使用 WebSockets。双向双向通信允许服务器向客户端发出信号,这有利于接收来自其他客户端的实时更新。例如,服务器可以向客户端发出信号,告诉它根据其他玩家的操作更新他们的位置。

就扩展而言,或当用户群开始扩展时,切换到 WebSocket 协议是最理想的选择。如果客户端使用长时间轮询技术,单个服务器的压力就会变得过大。每 20 秒发送一次请求的利用率很低,会导致服务器随着时间的推移而变慢,增加每次请求的延迟。

如何参与长轮询与 WebSockets 的对话

WebSockets 和长轮询的确为创建实时应用程序提供了有价值的解决方案。但是,在构建这些用例时,还需要考虑许多其他因素。就当今的技术而言,没有什么比从一个客户端向另一个客户端发送消息或数据更简单的了。在开发人员试图创建的实时系统之上,几乎总是存在所需的功能。例如,在应用内聊天中,您可以查看用户在线时的存在更新(信号)、脏话过滤,甚至阅读/发送消息。

除了添加特定功能外,底层基础设施还存在一些问题,例如处理可扩展性的复杂性。在使用 Socket.io 等特定技术创建 WebSocket 时,开发人员仍需在负载平衡器后面动态生成世界各地的服务器,以管理每个服务器的使用率。规模越大,这些问题就越复杂。这种情况下选择专业的第三方解决方案也是一个很好的方式,这样不用您就不必担心选择合适的替代方案或实施实时解决方案的底层复杂性。

本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/im/39216.html

(0)

相关推荐

发表回复

登录后才能评论