When we design web applications using real-time data, we all need to consider how we will pass the data from the server to the client. The default answer is usually to use "WebSockets", is there a better way than this?

The answer is yes.， Let's compare three different approaches：Long polling（ long wheeling and questioning），WebSockets harmonyServer-Sent Events（ Server sending events， acronymSSE）， Understanding the limitations of their practical use， The answer may surprise you.。

When it comes to passing data from the server to the client, we are limited to two general methods: client pull or server push. When a website in a browser asks the server for data, this is called a client-side pull. Instead, when a server actively pushes updates to your site, it's called a server push.

Today, there are several ways to achieve these functions.

Long/short polling (customer pull)

WebSockets (server push)

The server sends the event (server push).

long wheeling and questioning

The client requests data from the server, which is not available, and waits for a period of time before sending a response.

If something pops up while waiting, the server will send it and close the request;

If there is nothing to send and the maximum wait time is reached, the server sends a response with no data;

In both of these cases, the client opens the next data request;

Each polling request and response is a complete HTTP message with a full set of HTTP headers in the message frame. In the case of our frequent messages being frequent, the headers actually represent a larger percentage of the transmitted data.

After the server responds, it cannot send any more data to the client until the client sends the next request.

While this can be avoided by using persistent HTTP connections that can avoid many polling requests, it is accordingly a cumbersome technique to compute all components to poll in a short time to keep the connection active.

A long polling client (or server) that is underloaded naturally tends to reduce performance at the cost of message latency. When this happens, events pushed to the client will be queued.

long wheeling and questioning Requests need to remain pending， Until the server has something to send to the client。 If the proxy server is idle for a long time， This may cause the connection to close。

A multiplexing situation occurs if a persistent response occurs simultaneously on an HTTP connection.

WEBSOCKETS

WebSockets is an advanced technology that opens interactive communication sessions between a user's browser and a server. Using the API, messages can be sent to the server and receive event-driven responses without having to poll the server for a reply.

Both HTTP and WebSockets are located at the application layer of the OSI model and therefore rely on TCP at layer 4.

In general, WebSockets and proxies suffer from a number of different problems.

Implementing custom multiplexing on the server and client is too complex to make the sockets useful in the specified business case.

When your server is overloaded and you need to create a new instance and terminate the old one according to the software implementation, the action taken by "reconnect" may trigger a large number of refresh chains and new data requests, resulting in system overload and the need to maintain WebSockets on both the server and the client. If the current server is experiencing high load, it is not possible to move the socket connections to other servers and they must be closed and reopened.

This is usually handled by front-end HTTP proxies that cannot be handled by the TCP proxy required by WebSockets and are vulnerable to DOS attacks.

Reinventing the wheel: with WebSockets, you have to deal with many of the issues that you deal with in HTTP yourself.

SSE

The EventSource interface is used to receive events sent by the server. It connects to the server via HTTP and receives events in text/event stream format without closing the connection.

SSE Unique Features.

The connection stream is from the server and is read-only.

They use regular HTTP requests for persistent connections, not special protocols.

If the connection is disconnected, EventSource will trigger an error event and automatically attempt to reconnect. The server can also control the timeout before the client tries to reconnect.

The client can send a unique ID with the message. When a client tries to reconnect after a disconnection, it will send the last known ID. The server can then see how many messages the client has missed n and sends a backlog of missed messages when reconnecting.

SSE is not only a way to provide quick updates, but it's even better when it comes to optimizing for mobile devices. As far as the server-side implementation is concerned, it is not much different from polling, and on the client side it is much simpler than polling, as it requires initial subscription and assignment of event handlers, very similar to the way WebSockets are managed.

Recommended>>
1、WE Reprise Daniel Leithinger 3D touch screen goodbye tablet world
2、Top 10 Docker logging issues
3、6 Android apps infected by master key vulnerability
4、How to set your laptop to automatically disable the touchpad when you plug in a USB mouse
5、How to make a daily data report

已发送

发送中