使用 Websockets 代替 RESTful HTTP 有哪些陷阱? [英] What are the pitfalls of using Websockets in place of RESTful HTTP?

问题描述

我目前正在处理一个项目，该项目需要客户端请求一个大作业并将其发送到服务器.然后服务器将作业划分并以一组 url 响应，以便客户端进行 GET 调用并将数据流回.我是该项目的新手，目前正在使用 Spring websockets 来提高效率.与客户端不断地 ping 服务器以查看它是否有准备回传的结果不同，websocket 现在将直接联系客户端万岁！

让 websockets 从头到尾管理整个过程是不是一个坏主意?我正在将 STOMP 与 Spring websockets 一起使用，放弃 REST 还会有重大问题吗?

解决方案

使用 RESTful HTTP，您拥有一个无状态请求/响应系统，客户端发送请求，服务器返回响应.

使用 webSockets，您将拥有一个有状态(或可能有状态)的消息传递系统，其中消息可以以任何一种方式发送，并且发送消息的开销比使用 RESTful HTTP 请求/响应低.>

两者是完全不同的结构，具有不同的优势.

连接的 webSocket 的主要优点是:

1. 双向通信.因此，服务器可以随时通知客户端任何事情.因此，与定期轮询服务器以查看是否有新内容不同，客户端可以建立一个 webSocket 并监听来自服务器的任何消息.从服务器的角度来看，当客户端感兴趣的事件发生时，服务器只需向客户端发送一条消息.服务器无法使用纯 HTTP 执行此操作.

2. 每条消息的开销较低.如果您预计客户端和服务器之间会有大量流量，那么使用 webSocket 会降低每条消息的开销.这是因为 TCP 连接已经建立，您只需在已经打开的套接字上发送消息.对于 HTTP REST 请求，您必须首先建立一个 TCP 连接，该连接在客户端和服务器之间来回多次.然后，您发送 HTTP 请求，接收响应并关闭 TCP 连接.HTTP 请求必然包含一些开销，例如与该服务器对齐的所有 cookie，即使这些 cookie 与特定请求无关.如果客户端和服务器都使用 HTTP/2(最新的 HTTP 规范)，则它在这方面允许一些额外的效率，因为单个 TCP 连接可以用于多个请求/响应.如果您将 TCP 级别上发生的所有请求/响应绘制成图表，只是为了发出 https REST 请求/响应，那么与仅通过已建立的 webSocket 发送消息相比，您会惊讶地发现发生了多少.

3. 在某些情况下可扩展性更高.由于每条消息的开销较低且无需客户端轮询来确定是否有新内容，这可以提高可扩展性(给定服务器的客户端数量更多)可以服务).webSocket 可扩展性也有缺点(见下文).

4. 有状态连接.无需借助 cookie 和会话 ID，您可以直接在程序中存储给定连接的状态.虽然已经使用无状态连接进行了大量开发以解决大多数问题，但有时使用有状态连接会更简单.

RESTful HTTP 请求/响应的主要优点是:

1. 普遍支持.很难获得比 HTTP 更普遍的支持.虽然 webSockets 现在得到了相对较好的支持，但仍有一些情况下 webSocket 支持不定期可用.

2. 与更多服务器环境兼容.有些服务器环境不允许长时间运行服务器进程(某些共享主机情况).这些环境可以支持 HTTP 请求，但不能支持长时间运行的 webSocket 连接.

3. 在某些情况下规模更大. webSocket 对持续连接的 TCP 套接字的要求向 HTTP 请求不需要的服务器基础结构增加了一些新的规模要求.所以，这最终成为一个权衡空间.如果 webSockets 的优势不是真正需要或以重要方式使用，那么 HTTP 请求实际上可能会更好地扩展.这绝对取决于具体的使用情况.

4. 对于一次性请求/响应，单个 HTTP 请求比建立 webSocket、使用它然后关闭它更有效.这是因为打开一个 webSocket 是从一个 HTTP 请求/响应开始的，然后在双方同意升级到一个 webSocket 连接之后，就可以发送实际的 webSocket 消息了.

5. 无状态.如果您的工作没有因拥有无状态基础设施而变得更加复杂，那么无状态世界可以使扩展或故障转移变得更加容易(只需在后面添加或删除服务器进程)负载均衡器).

6. 自动缓存.通过正确的服务器设置，浏览器或代理可以缓存 http 响应.对于通过 webSockets 发送的请求，没有这种内置机制.

---

所以，为了解决您提出问题的方式:

<块引用>

使用 websockets 代替 RESTful HTTP 有哪些陷阱?

1. 大规模(数十万个客户端)，您可能需要做一些特殊的服务器工作，以支持大量同时连接的 webSocket.

2. 所有可能的客户端或工具集都不支持 webSockets 或通过它们发出的请求与支持 HTTP 请求的级别相同.

3. 一些较便宜的服务器环境不支持支持 webSockets 所需的长时间运行的服务器进程.

如果将进度通知返回给客户端对您的应用程序很重要，您可以使用长时间运行的 http 连接并继续发送进度，或者您可以使用 webSocket.webSocket 可能更容易.如果你真的只在这个特定活动的相对较短的时间内需要 webSocket，那么你可能会发现最好的整体权衡集是仅在需要将数据推送到客户端的时间段内使用 webSocket 并且然后使用 http 请求进行正常的请求/响应活动.

I am currently working on a project that requires the client requesting a big job and sending it to the server. Then the server divides up the job and responds with an array of urls for the client to make a GET call on and stream back the data. I am the greenhorn on the project and I am currently using Spring websockets to improve efficiency. Instead of the clients constantly pinging the server to see if it has results ready to stream back, the websocket will now just directly contact the client hooray!

Would it be a bad idea to have websockets manage the whole process from end to end? I am using STOMP with Spring websockets, will there still be major issues with ditching REST?

解决方案

With RESTful HTTP you have a stateless request/response system where the client sends request and server returns the response.

With webSockets you have a stateful (or potentially stateful) message passing system where messages can be sent either way and sending a message has a lower overhead than with a RESTful HTTP request/response.

The two are fairly different structures with different strengths.

The primary advantages of a connected webSocket are:

1. Two way communication. So, the server can notify the client of anything at any time. So, instead of polling a server on some regular interval to see if there is something new, a client can establish a webSocket and just listen for any messages coming from the server. From the server's point of view, when an event of interest for a client occurs, the server simply sends a message to the client. The server cannot do this with plain HTTP.

2. Lower overhead per message. If you anticipate a lot of traffic flowing between client and server, then there's a lower overhead per message with a webSocket. This is because the TCP connection is already established and you just have to send a message on an already open socket. With an HTTP REST request, you have to first establish a TCP connection which is several back and forths between client and server. Then, you send HTTP request, receive the response and close the TCP connection. The HTTP request will necessarily include some overhead such as all cookies that are aligned with that server even if those are not relevant to the particular request. HTTP/2 (newest HTTP spec) allows for some additional efficiency in this regard if it is being used by both client and server because a single TCP connection can be used for more than just a single request/response. If you charted all the requests/responses going on at the TCP level just to make an https REST request/response, you'd be surpised how much is going on compared to just sending a message over an already established webSocket.

3. Higher Scale in some circumstances. With lower overhead per message and no client polling to find out if something is new, this can lead to added scalability (higher number of clients a given server can serve). There are downsides to the webSocket scalability too (see below).

4. Stateful connections. Without resorting to cookies and session IDs, you can directly store state in your program for a given connection. While a lot of development has been done with stateless connections to solve most problems, sometimes it's just simpler with stateful connections.

The primary advantages of a RESTful HTTP request/response are:

1. Universal support. It's hard to get more universally supported than HTTP. While webSockets enjoy relatively good support now, there are still some circumstances where webSocket support isn't regularly available.

2. Compatible with more server environments. There are server environments that don't allow long running server processes (some shared hosting situations). These environments can support HTTP request, but can't support long running webSocket connections.

3. Higher Scale in some circumstances. The webSocket requirement for a continuously connected TCP socket adds some new scale requirements to the server infrastructure that HTTP requests don't demand. So, this ends up being a tradeoff space. If the advantages of webSockets aren't really needed or being used in a significant way, then HTTP requests might actually scale better. It definitely depends upon the specific usage profile.

4. For a one-off request/response, a single HTTP request is more efficient than establishing a webSocket, using it and then closing it. This is because opening a webSocket starts with an HTTP request/response and then after both sides have agreed to upgrade to a webSocket connection, the actual webSocket message can be sent.

5. Stateless. If your job is not made more complicated by having a stateless infrastruture, then a stateless world can make scaling or fail-over much easier (just add or remove server processes behind a load balancer).

6. Automatically Cacheable. With the right server settings, http responses can be cached by browser or by proxies. There is no such built-in mechanism for requests sent via webSockets.

---

So, to address the way you asked the question:

What are the pitfalls of using websockets in place of RESTful HTTP?

1. At large scale (hundreds of thousands of clients), you may have to do some special server work in order to support large numbers of simultaneously connected webSockets.

2. All possible clients or toolsets don't support webSockets or requests made over them to the same level they support HTTP requests.

3. Some of the less expensive server environments don't support the long running server processes required to support webSockets.

If it's important to your application to get progress notifications back to the client, you could either use a long running http connection with continuing progress being sent down or you can use a webSocket. The webSocket is likely easier. If you really only need the webSocket for the relatively short duration of this particular activity, then you may find the best overall set of tradeoffs comes by using a webSocket only for the duration of time when you need the ability to push data to the client and then using http requests for the normal request/response activities.

这篇关于使用 Websockets 代替 RESTful HTTP 有哪些陷阱?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！