WebSocket, SSE или polling
Вопрос
Чем отличаются WebSocket, SSE и long polling? Когда что выбрать?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Polling и long polling: обычные HTTP-запросы, просто, но лишние запросы и заголовки
SSE: поток сервер → клиент по HTTP, текст, автореконнект и `Last-Event-ID`
WebSocket: двунаправленный канал после upgrade, текст и бинарь, реконнект и heartbeat вручную
Выбор: уведомления и прогресс → SSE, чат и игры → WebSocket, редкие обновления → polling
Масштабирование долгих соединений: pub/sub между инстансами, таймауты на балансировщике
Что могут спросить следом
- Как авторизовать WebSocket-соединение?
- Что будет с SSE на HTTP/1.1 при многих открытых вкладках?
- Как не потерять сообщения при переподключении?
Разбор
Все три решают задачу доставки событий от сервера. Long polling это обычный запрос, который сервер держит, пока не появится событие, потом клиент сразу шлёт следующий. Работает везде, но каждый раз это новый запрос с заголовками. SSE держит один HTTP-ответ открытым и пишет в него события в формате text/event-stream. Это однонаправленный канал, зато браузер сам переподключается и сообщает Last-Event-ID, а инфраструктура видит обычный HTTP. WebSocket после handshake с 101 превращает соединение в двунаправленный канал фреймов: подходит, когда клиент тоже часто шлёт данные, как в чате или игре. Но реконнект, heartbeat и досылку пропущенного придётся писать самому. Для уведомлений и прогресса я беру SSE, для чата и совместной работы WebSocket, а если обновления раз в минуту, хватит polling. В обоих долгоживущих вариантах при нескольких инстансах нужен pub/sub между ними.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.