В чем разница между потоковой передачей HTTP и событиями, отправленными сервером?

SSE на самом деле является формой потоковой передачи HTTP. Это просто HTTP-ответ с типом MIME «текст / поток событий», и он отправляет простые текстовые сообщения, оканчивающиеся двойными символами новой строки.

SSE - это не то, что раньше было невозможно сделать, но веб-сайт должен был использовать соединение WebSocket, длинный опрос AJAX, комету, периодический опрос и т. Д., А теперь с SSE API стандартизирован, а реализация очень проста. Видеть:

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

Следует иметь в виду, что SSE не поддерживается в IE, включая Edge и IE Mobile:

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

Таким образом, вы не можете использовать его для более широкой аудитории (пока), если не знаете, какой браузер они используют.

IMHO, события, отправленные сервером HTTP2, имеют более широкие возможности, чем HTTP Streaming.

В однонаправленном потоке данных (Сервер - ›Клиент), где клиентская сторона может быть организована на основе внутренних событий, отправленные сервером события могут быть хорошим выбором.

Например:

# ---------- 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) {
    ...
}

Ограничения событий, отправляемых сервером:

• События SSE используют открытые соединения браузера.
• Существует ограничение на максимальное количество открытых подключений не на уровне вкладки браузера, а на уровне всего браузера.
• На тот момент, когда я пишу, у Chrome и Firefox оно равно 6 (слишком мало). Это ограничение действует на браузер + домен, поэтому вы можете открыть 6 SSE-подключений на всех вкладках к www.example1. com и еще 6 подключений SSE к www.example2.com.

HTTP-поток

Есть много вариантов использования, в которых может быть полезна потоковая передача HTTP. Если нас интересует только поток сообщений от Сервера, это может быть удобно.

Пример сценария:

Допустим, нам нравится передавать клиенту содержимое файла журнала. Либо это может быть огромный файл, либо содержимое файла постоянно обновляется, и мы хотели бы отправить его клиенту (например, хвост журнала). В таком случае поток HTTP (Transfer-Encoding: chunked) может удовлетворить наши потребности.

# ---------- 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();
            });
        }
    });
}

Ограничения ответа Stream:

• В случае потокового ответа (фрагментированного) - HTTP / 2 не поддерживает механизм кодирования фрагментированной передачи HTTP 1.1, поскольку он предоставляет свои собственные, более эффективные механизмы для потоковой передачи данных.