System design base long polling, WebSocket, Server send Events (SSEs) protocol

💨 Author: Laker, because he likes LOL god Faker and is a fan of NBA Lakers 🏀 (Laker) (mainly a fan of Lao James). His surname is Li, so he takes the pen name laker ❤️. Laker ❤️ likes to share his problems and solutions in his work, as well as some reading notes and experiences. 🌰 I created a wechat public account [Java Factory Interviewer] for communication and sharing with everyone 🏰 personal wechat [Lakernote], with the author’s note under the code: CV way.

The article directories

• • What is the difference between long polling, WebSocket and server sending events?
  • Ajax polling protocol
  • HTTP long polling protocol
  • Web sockets agreement
  • Server sends Event protocols (SSEs)
  • conclusion
  • • SSEs Protocol analysis
    • The client DEMO
    • The service side DEMO

What is the difference between long polling, WebSocket and server sending events?

Long polling, WebSocket, and server sending events are popular communication protocols between clients and servers such as Web browsers and Web servers. First, let’s look at standard HTTP Web requests. The following is a sequence of events for a regular HTTP request:

1. The client opens the connection and requests data from the server.
2. The server calculates the response.
3. The server sends the response back to the client based on the opened request.

Ajax polling protocol

HTTP long polling protocol

This is a variation of the traditional polling technique, which allows the server to push information to the client as data becomes available. With long-polling, the client can request information from the server as normal Polling, but the server may not respond immediately. That’s why this technique is sometimes called a “pending request.”

• If the server does not have any data available to the client, the server holds the request and waits until some data is available, rather than sending an empty response.
• Once the data is available, the complete response is sent to the client. The client then immediately rerequests the information from the server so that the server almost always has an available wait request that the server can use to respond to events.

The basic lifecycle of an application that uses HTTP long-polling is as follows:

1. The client makes the initial request using regular HTTP and then waits for the response.
2. The server delays its response until updates are available or a timeout occurs.
3. When an update is available, the server sends the complete response to the client.
4. Clients typically send a new long poll request as soon as they receive the response, or after a pause in the allowed wait time.
5. Each long poll request has a timeout. After a connection is closed due to a timeout, the client must reconnect periodically.

Web sockets agreement

Server sends Event protocols (SSEs)

Under the SSEs, clients establish persistent, long-term connections to servers. The server uses this connection to send data to the client. If the client wants to send data to the server, another technology/protocol needs to be used.

1. The client requests data from the server using regular HTTP.
2. The requested web page opens a connection to the server.
3. As soon as new information becomes available, the server sends the data to the client.

SSEs are best when we need live traffic from the server to the client, or when the server is generating data in a loop and will send multiple events to the client.

conclusion

SSEs Protocol analysis

The other methods are already familiar, except for the SSEs protocol, so what are SSEs?

SSE, server-sent Events, also known as EventSource, is a server-side event pushing technology that has been written into THE HTML 5 standard. It allows a one-way channel to be established between the client and the Server so that the Server can continuously push event messages to the client in one direction. SSE is suitable for scenarios where data does not need to be sent from the client, but is updated by certain server operations, such as stock quotes, shared facility updates, friend status updates, etc.

The general process has been introduced above. To put it simply, SSE means that the browser sends an HTTP request to the server, and then the server continuously pushes “message” to the browser in one direction. The format of the message is simple: “information” is prefixed with “data:” and then ended with “\n\n”.

SSE is similar to WebSocket in that it is used to establish a communication channel between the browser and the server.

The comparison is as follows:

The client DEMO

<script type="text/javascript">

    if(!!!!!window.EventSource) {

        var source = new EventSource('push');

        // Open the connection
        source.addEventListener('open'.function (evt) {
            // console.info(" Connection is already open ");
        }, false);


        // Receive the message
        source.addEventListener('message'.function (evt) {
            console.info(evt.data);
        });

        // Error message, and close notification
        source.addEventListener('error'.function (evt) {
            // console.info(evt);
        }, false);

    } else {
        alert("Browsers do not support SSE")
    }

</script>
Copy the code

The service side DEMO

First declare to the client that the event stream is followed by data of type TEXT /event-stream, and then you can send messages to the client multiple times. The event stream is a simple text stream that supports only utF-8 encoding. Each message is delimited by an empty line.

@RestController
public class SSEsController {
     // Send data to the browser
    @RequestMapping(value = "/push", produces = "text/event-stream")
    public String push(a) throws InterruptedException { String msg = ... ;// Fixed format
        return "data:" + msg + "\n\n"; }}Copy the code

SpringBoot uses SseEmitter to support SSE, without the cumbersome code above, interested in baidu

Most of this article is a translation of foreign articles:

• Grokking the System Design Interview by Design Gurus
• www.html5rocks.com/en/tutorial…
• Blog.csdn.net/beng_shakal…