我目前正在开发一个项目，需要客户端请求一个大作业并将其发送到服务器。然后，服务器划分作业并以一组 url 进行响应，以便客户端进行 GET 调用并流回数据。我是该项目的新手，目前正在使用 Spring websockets 来提高效率。 Websocket 现在将直接联系客户端，而不是客户端不断地 ping 服务器以查看是否有准备好返回的结果！
让 websocket 管理端到端的整个过程是不是一个坏主意？我将 STOMP 与 Spring websockets 结合使用，放弃 REST 还会出现重大问题吗？
使用 RESTful HTTP，您将拥有无状态请求/响应系统客户端发送请求，服务器返回响应。
有了 webSockets，你就有了有状态（或潜在有状态）消息传递系统，消息可以以任何方式发送与 RESTful HTTP 请求/响应相比，发送消息的开销更低。
两者是截然不同的结构，具有不同的优势。
连接的 webSocket 的主要优点是：
-
双向通讯。因此，服务器可以随时通知客户端任何事情。因此，客户端可以建立一个 webSocket 并仅侦听来自服务器的任何消息，而不是定期轮询服务器以查看是否有新内容。从服务器的角度来看，当客户端感兴趣的事件发生时，服务器只需向客户端发送一条消息。服务器无法使用纯 HTTP 来执行此操作。
-
每条消息的开销更低。如果您预计客户端和服务器之间有大量流量，那么使用 webSocket 时每条消息的开销会较低。这是因为 TCP 连接已经建立，您只需在已经打开的套接字上发送消息即可。对于 HTTP REST 请求，您必须首先建立一个 TCP 连接，该连接在客户端和服务器之间来回多次。然后，您发送 HTTP 请求、接收响应并关闭 TCP 连接。 HTTP 请求必然包括一些开销，例如与该服务器对齐的所有 cookie，即使这些与特定请求无关。如果客户端和服务器都使用 HTTP/2（最新的 HTTP 规范），则可以在这方面实现一些额外的效率，因为单个 TCP 连接可用于多个请求/响应。如果您只是为了发出 https REST 请求/响应而绘制了 TCP 级别上发生的所有请求/响应，那么与仅通过已建立的 webSocket 发送消息相比，您会惊讶地发现发生了多少事情。
-
在某些情况下规模更大。由于每条消息的开销较低，并且无需客户端轮询来查找是否有新内容，因此可以提高可扩展性（给定服务器可以服务的客户端数量更多）。 webSocket 可扩展性也有缺点（见下文）。
-
有状态连接。无需借助 cookie 和会话 ID，您可以直接将给定连接的状态存储在程序中。虽然很多开发都是使用无状态连接来解决大多数问题，但有时使用有状态连接会更简单。
RESTful HTTP 请求/响应的主要优点是：
-
普遍支持。很难得到比 HTTP 更普遍的支持。虽然 webSocket 现在享有相对较好的支持，但在某些情况下仍无法定期提供 webSocket 支持。
-
兼容更多服务器环境。有些服务器环境不允许长时间运行服务器进程（某些共享托管情况）。这些环境可以支持 HTTP 请求，但不能支持长时间运行的 webSocket 连接。
-
在某些情况下规模更大。webSocket 对持续连接的 TCP 套接字的要求为服务器基础设施增加了一些 HTTP 请求不需要的新规模要求。因此，这最终成为一个权衡空间。如果 webSocket 的优势并不真正需要或未得到广泛使用，那么 HTTP 请求实际上可能会扩展得更好。这绝对取决于具体的使用情况。
-
对于一次性请求/响应，单个 HTTP 请求比建立 webSocket、使用它然后关闭它更高效。这是因为打开 webSocket 是从 HTTP 请求/响应开始的，然后在双方都同意升级到 webSocket 连接后，才能发送实际的 webSocket 消息。
-
无国籍。如果您的工作没有因拥有无状态基础设施而变得更加复杂，那么无状态世界可以使扩展或故障转移变得更加容易（只需在负载均衡器后面添加或删除服务器进程）。
-
自动可缓存。通过正确的服务器设置，浏览器或代理可以缓存 http 响应。对于通过 webSocket 发送的请求，没有这样的内置机制。
因此，为了解决您提出问题的方式：
使用 websocket 代替 RESTful HTTP 有哪些陷阱？
-
在大规模（数十万个客户端）下，您可能必须执行一些特殊的服务器工作才能支持大量同时连接的 webSocket。
-
所有可能的客户端或工具集都不支持 webSocket 或通过它们发出的请求，其级别与支持 HTTP 请求的级别相同。
-
一些较便宜的服务器环境不支持支持 webSocket 所需的长时间运行的服务器进程。
如果您的应用程序将进度通知返回给客户端很重要，您可以使用长时间运行的 http 连接并持续发送进度，也可以使用 webSocket。 webSocket 可能更容易。如果您确实只需要在该特定活动的相对较短的持续时间内使用 webSocket，那么您可能会发现最好的整体权衡是仅在您需要将数据推送到客户端的时间段内使用 webSocket，并且然后使用 http 请求进行正常的请求/响应活动。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
