SSE передаёт текстовые события от сервера к клиенту по длительному HTTP-ответу text/event-stream. WebSocket даёт двусторонний обмен сообщениями по установленному соединению. EventSource умеет переподключаться и передавать Last-Event-ID, но восстановление пропущенных данных должен реализовать сервер. Для отправки данных клиентом при SSE используют отдельные запросы.
Чем SSE отличается от WebSocket и как работает Server-Sent Events?
Односторонний поток событий по HTTP и двусторонний WebSocket: формат SSE, переподключение и выбор под задачу.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
SSE подходит, когда основное направление обновлений — от сервера к браузеру: статусы задач, уведомления, поток результатов. Браузер открывает запрос, а сервер постепенно отправляет UTF-8-текст с типом text/event-stream.
Пример одного события:
id: 42
event: progress
data: {"percent":75}
Событие заканчивается пустой строкой. Несколько строк data: объединяются в сообщение; тип события задаётся через event:.
const stream = new EventSource('/events');
stream.addEventListener('progress', (event) => {
const progress = JSON.parse(event.data);
console.log(progress.percent);
});
// Когда поток больше не нужен:
// stream.close();
При восстановимом разрыве EventSource переподключается. id позволяет передать последний идентификатор в Last-Event-ID, однако это не очередь с гарантированной доставкой: серверу нужны хранение истории и обработка повтора. Нативный EventSource не предоставляет произвольные заголовки авторизации; способ авторизации выбирают с учётом этого ограничения, не помещая секреты в URL. См. стандарт Server-sent events.
WebSocket предназначен для двустороннего обмена и поддерживает текстовые и бинарные сообщения. Он удобен там, где клиент и сервер часто посылают данные друг другу. Прикладные подтверждения, восстановление состояния и ограничение очередей всё равно нужно проектировать.
SSE не запрещает браузеру отправлять команды: для этого можно использовать отдельные HTTP-запросы. При эксплуатации потоков важно учитывать буферизацию прокси, таймауты и медленных получателей. Выбор определяется направлением и форматом обмена, а не правилом «одна технология всегда быстрее другой».