HTTP server push, also known as HTTP streaming, is a client/server communication method that transmits information from an HTTP Server to a Client asynchronously without needing a client request. Server push architectures are especially useful for mobile and interactive web applications. One or more clients must receive continuous information from the server. This article will discuss WebSocket (server-sent events) and WebSocket (web socket), two technologies that implement HTTP Server Push.
Let me describe the technical differences between these solutions and how they are implemented in web architecture. An example application will show you how to set up an SSE implementation. Next, I’ll show you how to implement WebSockets. I will then compare both technologies and recommend how to use them for different types of web or mobile apps.
This article assumes that you are familiar with the concepts and language of HTTP server push. Both applications were written in Python with CherryPy.
Limits of request-response
The web’s client-server communication has traditionally been a request-response system. This requires the client to request resources from the server (such as a web browser). A client requests help from the server. The server replies by sending the requested resource. The server will send an error message if the requested resource is unavailable or the client does not have permission to access it. A request-response architecture means a server cannot send an unwelcome message to a client.
As web applications became more interactive and powerful, the limitations of the request-response system began to become apparent. Client applications that required frequent updates started to direct more frequent HTTP0_ requests. This polling technique can cause performance problems by overloading the server at peak times. This is inefficient as the client sends many demands and needs an update. Clients can only poll at a particular time, which can slow down client responsiveness.
HTTP server push technology was developed to address performance and other limitations that come with frequent polling. It is much more efficient for interactive web apps like games and screen-sharing services to update clients whenever new data becomes available.
Compare WebSocket to SSE
WebSocket, SSE, and the traditional request-response architecture are alternatives. However, they are not necessarily competing technologies. A WebSocket architecture is a socket that is used for bidirectional full-duplex communication. Instead of waiting for a response from the server, the client listens to the socket and receives updates. Clients can also communicate with the server using the socket, such as sending an ACK message after receiving an update.
SSE is a simplified standard that was developed to extend HTML5. SSE allows the server to send asynchronous messages to the client. However, it does not allow the client to send messages to the server. SSE’s half-duplex communication model works best for applications that only require streaming updates from the server. SSE is more efficient than WebSocket because it can be used over HTTP without additional components.
WebSocket is the best choice for a multipurpose web app that requires extensive communication between client/server. SSE is better suited for applications that stream asynchronous data from the server to the client but don’t require a reply.
Browser support
When comparing HTTP protocol versions, browser support is a critical factor. The browsing data in Table 1 shows that the WebSocket protocol can be used across all modern browsers. This includes mobile browsers. Microsoft Edge and Microsoft IE don’t support SE.
Development effort
Another essential factor to consider is effort when comparing protocols, especially those that are newer, like WebSocket or SSE. “Effort” refers to the number of lines of code or the amount of time you will spend coding your app using the protocol. This is particularly important when projects have strict deadlines or a limited development budget.
SSE is much easier to implement than WebSocket. It can be used with any HTML5 app. The main task is to add an HTTP header to messages from the server to clients. The client will recognize the message as a server-sent event if it has the correct header. SSE is not like WebSocket. It doesn’t require establishing or maintaining a socket link between the client and server.
WebSocket requires you to configure a socket on the server side that listens for client connections. Clients automatically open a socket to the server, wait for messages, and can send them asynchronously. Each application can define its message format and keep-alive strategy.
Develop an SSE Application
SSE is an HTML5 standard that uses only HTTP to send asynchronous messages. SSE is not like WebSocket. You don’t need to create a server socket or open connections on your front end. This eliminates a lot of complexity.
The SSE frontend
EventSource creates an interface to establish an HTTP connection with the server. The event stream format is text data encoded with UTF-8 that the server uses to send client messages. The server keeps the HTTP connection open for the specified message stream until contact is established. This allows the server to send updates. In Listing 1, we’ve created an HTTP connection to receive events related to the /#tabs/user-log-stream URI.
The SSE backend
We create a dispatcher on the backend for the URL /user-log stream. The dispatcher will send an asynchronous message to the front end to establish communication. The SSE client can not send messages to the server.