Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the difference between HTTP streaming and server sent events?

My understanding is that HTTP streaming involves the client sending an HTTP request and then response to the request being sent over time allowing the server to essentially push to the client. In what I have read it seems that SSEs operates along the same principle but, is more formalized. Is that close to a correct understanding?

I saw these questions but they didn't really answer my question directly.

HTTP: what are the relations between pipelining, keep-alive and Server Sent Events? What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?

I also looked at this https://www.html5rocks.com/en/tutorials/eventsource/basics/#disqus_thread tutorial for setting up SSEs and it seems like how I would imagine HTTP streaming is set up.

like image 778
Bren Avatar asked Mar 02 '17 15:03

Bren


People also ask

Is SSE over HTTP?

Since SSE is based on the HTTP protocol, scaling can be achieved with means such as load-balancing. However, you'd need to ensure some sort of shared resource behind the servers so they're all kept in sync with new event updates.

What is meant by server-sent events?

A server-sent event is when a web page automatically gets updates from a server. This was also possible before, but the web page would have to ask if any updates were available. With server-sent events, the updates come automatically.

What is HTTP data streaming?

HTTP Streaming is a push-style data transfer technique that allows a web server to continuously send data to a client over a single HTTP connection that remains open indefinitely.

Where are server-sent events used?

They are commonly used to send message updates or continuous data streams to a browser client and designed to enhance native, cross-browser streaming through a JavaScript API called EventSource, through which a client requests a particular URL in order to receive an event stream.


2 Answers

SSE is in fact a form of HTTP streaming. It is just an HTTP response with MIME type of "text/event-stream" and it sends plain text messages terminated with double newlines.

SSE is not something that was impossible to do before, but the website had to use WebSocket connection, AJAX long polling, comet, periodical polling etc. and now with SSE the API is standardized and the implementation is very simple. See:

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

One of the things to keep in mind is that SSE is not supported on IE including Edge and IE Mobile:

  • http://caniuse.com/#feat=eventsource

So you cannot really use it for wider audience (yet), unless you know what browser they use.

like image 109
rsp Avatar answered Sep 29 '22 23:09

rsp


IMHO, HTTP2 Server sent events has rich features than HTTP Streaming.

In a unidirectional data flow (Server -> Client) where client side could be orchestrated based on backend events, server sent events could be a good choice.

For example:

# ---------- client side -----------

const eventSource = new EventSource("//your-api/workflow/state");

eventSource.addEventListener("queued", function(event) {
    ...
}
eventSource.addEventListener("started", function(event) {
    ...
}
eventSource.addEventListener("failed", function(event) {
    ...
}
eventSource.addEventListener("success", function(event) {
    ...
}

Limitations of Server sent events:

  • SSE events consume browser open connections.
  • There is a limit on number of max open connections not at browser tab level but whole browser level
  • The time I am writing, Chrome & Firefox has it as 6 (too low). This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com.

HTTP Streaming

There are many use cases where HTTP streaming could be useful. If we are only interested in a stream of message from Server, this could be handy.

Example scenario :

Let's say we like to stream a log file content to client. Either it could be a huge file or the file content keeps updating and we like to send it to client (like a log tail). In such case, HTTP stream (Transfer-Encoding: chunked) could satisfy our needs.

# ---------- client side -----------
const streamRequest = (url) => {
    fetch(url).then(function (response) {
        let reader = response.body.getReader();
        let decoder = new TextDecoder();
        return readData();
        function readData() {
            return reader.read().then(function ({value, done}) {
                console.log(value)
                if (value) {
                    let newData = decoder.decode(value, {stream: !done});
                    console.log(newData);    
                }
                if (done) {
                    console.log('end of stream');
                    return;
                }
                return readData();
            });
        }
    });
}

Limitations of Stream response:

  • In case of stream response (chunked) - HTTP/2 doesn't support HTTP 1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming.
like image 20
Sairam Krish Avatar answered Sep 30 '22 00:09

Sairam Krish