使用Websockets代替RESTful HTTP有什么缺陷？ [英] What are the pitfalls of using Websockets in place of RESTful HTTP?

问题描述

我目前正在开发一个需要客户端请求大型作业并将其发送到服务器的项目。然后服务器分割作业，并使用一组url响应客户端对数据进行GET调用和流回。我是项目的greenhorn，我目前使用Spring websockets来提高效率。而不是客户端不断地ping服务器，看看是否有结果准备流回，websocket现在将直接联系客户端hooray！

这将是一个坏的想让websockets从头到尾管理整个过程？

解决方案

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

使用webSockets您有一个有状态）消息传递系统，其中可以以任一方式发送消息，并且发送任何给定的消息比使用RESTful HTTP请求/响应的开销更低。

具有不同强度的非常不同的结构。

连接的webSocket的主要优点是：

1. 双向通信。因此，服务器可以随时通知客户端任何内容。所以，不是轮询一个定期的服务器，以查看是否有新的东西，客户端可以建立一个webSocket，只监听来自服务器的任何消息。从服务器的角度来看，当发生客户感兴趣的事件时，服务器简单地向客户端发送消息。




2. 降低每封邮件的费用。如果您预计在客户端和服务器，那么每个消息的webSocket有一个较低的开销。这是因为TCP连接已经建立，您只需在已经打开的套接字上发送消息。使用HTTP REST请求，您必须首先建立一个TCP客户端和服务器之间来回连接。然后，您发送HTTP请求，接收响应并关闭TCP连接。 HTTP请求将必然包括一些开销，例如与该服务器对齐的所有cookie，即使这些cookie与特定请求不相关。如果客户端和服务器都使用HTTP / 2（最新的HTTP规范），则在这方面允许一些额外的效率，因为单个TCP连接可以用于不仅仅单个请求/响应。如果你绘制了所有的请求/响应，在TCP层只是为了做一个REST REST请求/响应，你会惊讶到多少是相比，只是通过已经建立的webSocket发送消息。

（给定服务器可以提供的客户端数量更多）。



3. 有状态连接。如果不使用Cookie和会话ID，可以直接将状态存储在给定连接的程序中。虽然已经通过无状态连接进行了大量的开发来解决大多数问题，但是有时它只是有状态连接更简单。

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

1. 。很难获得比HTTP更广泛的支持。




2. 兼容更多的服务器环境。

   / strong>有一些服务器环境不允许长时间运行的服务器进程（一些共享主机情况）。这些环境可以支持HTTP请求，但不支持长时间运行的webSocket连接。




3. 对连续连接的TCP套接字的要求为HTTP请求不需要的服务器基础设施增加了一些新的规模要求。所以，这最终是一个权衡空间。如果webSockets的优点不是真正需要或者以显着的方式使用，那么HTTP请求实际上可以更好地扩展。




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




5. 无状态。如果没有无状态的基础设施，您的工作不会变得更加复杂，那么无状态的世界可以使扩展更容易（只需在负载均衡器后面添加更多服务器进程）。

---

因此，为了解决您问问题的方式：

使用websockets代替RESTful HTTP有什么缺陷？

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

   / li>
   

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 any given message is 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 to 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 compare 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 much easier (just add more server processes behind a load balancer).

---

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屋！