82 подписчика

Все способы взаимодействия веб‑клиента с сервером: от HTTP GET до WebSocket и лонг-поллинга

28 августа28 авг

45 мин

Оглавление

1. Обычные HTTP-запросы (классический запрос-ответ)
2. Периодический опрос (Polling)

В веб-разработке браузер (клиент) и сервер постоянно общаются между собой. Как именно браузер получает данные с сервера и отправляет ему запросы? Существует несколько способов такой коммуникации – от самых простых одноразовых запросов до сложных постоянных соединений для мгновенного обмена данными. В этой статье мы подробно разберём все основные методы взаимодействия веб-клиента с сервером, сравним их плюсы и минусы и посмотрим, в каких случаях каждый из них пригодится. Будет технически, но постараемся объяснить по-человечески, с примерами и интересными фактами по пути. Поехали!

1. Обычные HTTP-запросы (классический запрос-ответ)

Самый базовый способ общения браузера и сервера – это стандартные HTTP-запросы. Когда вы вводите URL в адресной строке и нажимаете Enter, браузер отправляет HTTP-запрос (чаще всего метод GET) на сервер, а сервер отвечает содержимым страницы. Каждый такой запрос независим: браузер запрашивает – сервер отвечает, и соединение завершается. Для каждого нового кусочка данных нужен новый запрос.

Пример: при загрузке этой страницы ваш браузер сделал HTTP GET запрос к серверу, и сервер вернул HTML код статьи. Если на странице есть картинки или стили, браузер сделает отдельные HTTP запросы за каждым из этих ресурсов.

Особенности: HTTP-запросы могут быть разных методов – GET, POST, PUT, DELETE и т.д. – но суть одна: клиент инициирует запрос, сервер возвращает ответ. Исторически веб сначала работал только так: каждый клик или обновление страницы = новый запрос, полный перезагруз страницы. Затем появилась технология AJAX, позволившая делать асинхронные запросы из скрипта без полной перезагрузки страницы. Но и AJAX (через XMLHttpRequest или современный fetch) всё так же работает поверх HTTP запросов.

Плюсы обычных запросов:

Простота и стандартизация. Это самый простой и надёжный способ – поддерживается везде. Достаточно написать URL и получить данные. Любой браузер, любой сервер умеет в HTTP.
Разные типы запросов. Мы можем не только получать данные (GET), но и отправлять (POST), обновлять (PUT), удалять (DELETE) – набор методов позволяет выразить разные операции.
Кэширование и инфраструктура. HTTP-протокол поддерживает кеширование, прокси-серверы, сжатие данных – всё это автоматически работает для обычных запросов, улучшая производительность.
Легко отладить. Запрос-ответ легко увидеть в DevTools, воспроизвести через cURL или Postman. Никакой особой конфигурации не нужно.

Минусы:

Нет мгновенного обновления. Сервер не может сам по себе отправить что-то клиенту. Всегда нужно дождаться, пока клиент спросит. Если на сервере произошло событие (например, пришло новое сообщение в чат), он не сообщит браузеру, пока браузер сам не запросит обновления.
Одноразовость. Соединение используется кратковременно. Для каждого нового фрагмента данных нужно снова установить соединение, отправить запрос, дождаться ответа. Накладные расходы на каждый запрос (заголовки, установка TCP-соединения, TLS) могут быть существенными, особенно если делать их часто.
Ограничения задержки. Поскольку новые данные приходят только при запросе, частота обновления ограничена частотой запросов. Если опрашивать сервер редко – данные будут приходить с задержкой. Если слишком часто – будет большая нагрузка (об этом далее в разделе про polling).

Тем не менее, классический HTTP запрос–ответ по сей день лежит в основе веба. Даже более продвинутые методы часто используют HTTP на начальном этапе (например, для установки соединения или получения первой страницы) перед переходом к чему-то более сложному.

Пример (клиентский код): простой GET-запрос с помощью современного Fetch API:

// Отправляем GET запрос и выводим результат в консоль
fetch('https://api.example.com/data')
.then(response => response.json())
.then(data => console.log('Получены данные:', data))
.catch(error => console.error('Ошибка:', error));

В примере выше браузер обращается к URL https://api.example.com/data. Сервер может в ответ вернуть, например, JSON-данные, которые мы получим и выведем. Именно так работают все стандартные AJAX-запросы. А что, если нам нужно не разово получить данные, а узнавать о новых данных постоянно? Можно, конечно, вызывать такой запрос каждые N секунд – это и есть следующий метод.

2. Периодический опрос (Polling)

Polling (поллинг, опрос) – это техника, при которой клиент регулярно опрашивает сервер на предмет новых данных. Проще говоря, браузер раз в Х секунд делает запрос: “Ну что, сервер, есть что-нибудь новенькое?”. Сервер каждый раз отвечает либо свежими данными, либо говорит “пока ничего нет” (например, возвращая пустой ответ или статус вроде 204 No Content). Затем клиент ждёт заданный интервал и снова посылает запрос.

Такой подход начали использовать, когда возникла потребность в автоматическом обновлении информации на странице. Например, ранние социальные сети и форумы хотели показывать новые сообщения без ручного обновления страницы. Самый прямолинейный способ – опрашивать сервер каждые несколько секунд.

Как это выглядит:

Браузер делает запрос на некий эндпойнт, скажем /updates.
Сервер сразу отвечает либо данными (если они есть), либо пустым результатом.
Браузер ждёт пару секунд и снова запрашивает /updates, и так бесконечно, пока страница открыта.

Пример (клиентский код polling): опрашиваем сервер каждые 5 секунд:

setInterval(async () => {
try {
const res = await fetch('/updates');
const data = await res.json();
if (data) {
console.log('Обновление от сервера:', data);
}
} catch (err) {
console.error('Ошибка при опросе:', err);
}
}, 5000);

Здесь каждые 5000 мс (5 секунд) идёт запрос на /updates. Если сервер вернул какие-то данные, мы их обрабатываем (выводим). Если вернул пусто или ошибку – просто ждём следующего раза.

Плюсы polling:

Просто и понятно. Реализовать очень легко: по сути тот же обычный запрос в цикле или с интервалом. Не нужны специальные протоколы или поддержку со стороны сервера, кроме самого эндпойнта, который возвращает данные.
Контроль частоты. Разработчик сам решает, как часто опрашивать. Можно настроить интервал в зависимости от требований: раз в минуту, раз в секунду – как угодно.
Совместимость. Работает в любом браузере и с любым сервером, поддерживающим HTTP. Не важно, старый это IE или современный Chrome – обычные запросы доступны всегда. Для серверов тоже никаких особых условий – даже простейший PHP-скрипт может отвечать на такие запросы.

Минусы polling:

Иneффективность при частом опросе. Если опрашивать очень часто, на сервер летит куча запросов, большинство из которых могут быть впустую (сервер скажет “нет новых данных”). Это впустую тратит трафик и ресурсы сервера. Представьте, что вы каждые 5 секунд дергаете сервер вопросом “ну что, обновления есть?”. Если сотни или тысячи клиентов делают так постоянно, серверу приходится обрабатывать лавину лишнего трафика.
Задержки обновления. Если поставить интервал подольше (чтобы серверу было полегче), то новые данные будут появляться с заметной задержкой. Например, при интервале 30 секунд новое сообщение в чате вы увидите в худшем случае через те самые 30 секунд после отправки – не очень “real-time”. Можно уменьшить интервал, но тогда см. пункт про нагрузку.
Ненужный расход ресурсов клиента. Браузер, да и мобильное устройство пользователя, тоже тратит ресурсы на постоянные запросы (радиомодуль в телефоне не дремлет, батарея садится). Особенно это ощутимо, если открыть, скажем, страницу в нескольких вкладках – каждый будет опрашивать.
Шум и пустые ответы. Большинство запросов возвращают “ничего нового”, но они всё равно несут HTTP-заголовки, устанавливают соединение и т.п. Этот служебный “балласт” может составлять сотни байт на каждый запрос, что при тысячах пользователей превращается в мегабайты трафика в секунду без пользы.

Практический пример: В первых версиях Twitter лента обновлялась методом polling – клиент каждые N секунд проверял, нет ли новых твитов. Если твит появился сразу после последнего запроса, вы его не увидите, пока не сработает следующий цикл. Пользователи шутили, что сидят и нажимают F5 (обновить), только в автоматическом режиме. В итоге Twitter и другие проекты перешли на более эффективные методы, о которых далее.

Polling хорош для простых случаев, когда обновления редкие и не критично мгновенно. Например, если нужно проверять раз в час статус какого-нибудь задания – вполне сгодится. Но для интерактивных сценариев (чат, игры, соцсети) постоянный опрос – слишком громоздко и неуклюже. Тут на помощь приходит небольшой трюк: а давайте не отвечать на запрос сразу, если нет данных? Пускай клиент подождёт открытого, пока что-то не появится. Именно так родился лонг-поллинг.

3. Длинный опрос (Long Polling, «лонг-поллинг»)

Long polling – это улучшенная версия опроса, которая позволяет снизить количество лишних запросов и приблизить обновления к реальному времени. Идея в том, что сервер не отвечает сразу на запрос, если у него пока нет новых данных. Он держит соединение открытым до тех пор, пока не появится что отправить (или пока не истечёт некий таймаут). Как только новые данные готовы, сервер отправляет ответ. Браузер, получив данные, тут же (сразу же) открывает новый запрос и снова ждёт. Получается непрерывный цикл: всегда есть один “висящий” запрос на сервере, готовый немедленно принять свежие данные.

По сути, лонг-поллинг – это "обманка": со стороны браузера код похож на polling (сделал запрос, получил ответ, потом снова запрос), но за счёт ожидания на сервере мы избегаем пустых ответов и лишних повторов. Если данных нет, сервер просто задерживает ответ, вместо того чтобы каждый раз говорить “пусто”.

Как это выглядит шагами:

Клиент посылает запрос (например, GET /notifications).
Сервер не отвечает сразу. Он может поставить этот запрос в ожидание: держит соединение открытым, не завершая ответ.
Допустим, через 10 секунд на сервере появилось новое событие (например, пришло сообщение или обновление). Сервер сразу отправляет ответ с этим событием и закрывает соединение.
Клиент получает ответ (через те же ~10 секунд от момента запроса, практически мгновенно после появления события). Важно: клиент сразу же открывает новый запрос GET /notifications и снова начинает ждать следующего события.
Этот цикл повторяется бесконечно: всегда после получения данных клиент открывает новый “подвешенный” запрос.

Если ничего не происходит, сервер может держать запрос открытым некоторое разумное время (например, 30–60 секунд) и потом всё-таки ответить чем-то вроде “ничего нового” и закрыть. Клиент тут же перезапросит и продолжит ждать. Это сделано, чтобы соединение не висело вечно – могут быть сетевые ограничения, да и обновить контекст полезно.

Интересный факт: Такой подход иногда называют Comet. В середине 2000-х, когда AJAX (асинхронные запросы) стал популярным термином, шутливо прозвали серверные пуш-технологии “Comet” – по названию другого бренда чистящих средств (Ajax – чистящий порошок, Comet – тоже порошок). Под “Comet” объединяли разные способы серверного пуша до появления стандартизированных методов. Лонг-поллинг был одним из основных приёмов «Comet-программирования».

Пример (реализация лонг-поллинга на Node.js):

На сервере (Node.js + Express) можно сделать так:

Здесь идея такая: при GET-запросе на /notifications мы не завершаем запрос, а сохраняем объект res (ответ) в массив pendingResponses. Когда случается какое-то событие (в примере это имитация таймером каждую минуту), функция sendNotification отправляет всем “подвешенным” запросам ответ res.json(...) с данными и очищает список. В реальности вместо setInterval это могла бы быть, например, новая запись в базе или сообщение, пришедшее на сервер – тогда мы вызывали бы sendNotification при настоящем событии. Браузер на своей стороне, получив ответ, должен сразу снова сделать запрос на /notifications, чтобы опять встать в режим ожидания следующего события.

Пример (клиентский код лонг-поллинг):

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

Плюсы long polling:

Минимальная задержка данных. Как только у сервера что-то появилось, он тут же отправит ответ, и клиент сразу узнает о событии. Нет фиксированного интервала ожидания как при обычном polling – если событие произошло через секунду после предыдущего, клиент получит его через секунду, а не будет ждать оставшиеся 29 секунд таймера.
Меньше пустых запросов. В отличии от “тупого” опроса каждую N секунд, при лонг-поллинге запросов значительно меньше. Если событий мало, клиент будет тихо ждать на одном соединении, не спамя сервер. Нет постоянного потока “ну что, ну что?” без толку – запрос висит и ждёт, экономя трафик и ресурсы.
Широкая поддержка. Для лонг-поллинга не нужно ничего, кроме стандартных возможностей: долговременно держать HTTP-соединение и отправлять ответ по готовности. Это работает во всех браузерах (через AJAX) и с любым сервером, который позволяет работать с соединением нестандартно. Даже старые IE могли делать лонг-поллинг через forever iframe или XHR – то есть метод совместим почти со всем, что умеет HTTP.
Относительная простота реализации. Не настолько примитивен как polling, но всё же гораздо проще, чем внедрять новые протоколы. Если у вас уже есть серверный API, вы можете добавить лонг-поллинг эндпойнт без переписывания всего приложения. По сути, нужно научиться держать соединение открытым. В Node.js как мы видим это несложно, а вот, например, в PHP (где каждый запрос живёт недолго) потребуются хитрости или отдельный процесс.

Минусы long polling:

Долгие висящие соединения. Постоянно открытые “висящие” запросы занимают ресурсы сервера. Каждый клиент удерживает одно соединение, пусть и в ожидании. Для сервера с потоковой моделью (например, Node, nginx) это не огромная проблема, но всё же на уровне ОС открытые сокеты, память под каждый запрос – это накладные расходы. В традиционных потоковых серверах (типа Apache+PHP с потоком на запрос) лонг-поллинг мог быстро исчерпать лимит потоков/процессов. В больших масштабах (десятки тысяч одновременных соединений) нужно специально оптимизировать серверную часть.
Сложнее, чем разовые запросы. Код как на сервере, так и на клиенте, усложняется. Нужны механизмы повторного подключения в случае разрыва, тайм-ауты, возможно учёт пропущенных сообщений. Хотя это всё реализуемо, но разработчику нужно быть осторожнее. Фронтенд-код, как видно, рекурсивно вызывает себя – важно не забывать об обработке ошибок, иначе при разрыве вы потеряете связь.
Всё ещё полудуплекс. Несмотря на то, что сервер может отправлять данные инициативно, канал по-прежнему односторонний в рамках данного соединения. Браузер не может через тот же запрос отправить что-то на сервер вне стандартного механизма (он отправил запрос – на этом его “вклад” закончен, дальше говорит сервер). То есть если клиенту тоже нужно часто слать данные серверу (например, отправлять свои события в реальном времени), для этого понадобятся отдельные запросы POST или другой канал. Лонг-поллинг решает только доставку от сервера к клиенту.
Если событий слишком много, эффективность падает. Представьте, что данные на сервере обновляются очень часто, скажем несколько раз в секунду. При лонг-поллинге на каждое событие придётся делать новый запрос (ведь схема: событие -> ответ -> новое соединение). В худшем случае это будет практически непрерывный поток запросов, и накладные расходы могут даже превысить постоянный открытый канал. В таких случаях лучше уже переходить на действительно постоянное соединение (WebSocket).

Где используется: Лонг-поллинг был популярен до появления официальных стандартов для реального времени. Классический пример – чат Facebook в первые годы своего существования. Браузер держал соединение открытым, и как только собеседник печатал вам сообщение, сервер сразу его отправлял через тот самый висящий запрос. Затем браузер мгновенно открывал новый запрос и ждал. Для пользователя это выглядело как мгновенные сообщения, почти как сейчас с WebSocket, хотя под капотом шёл лонг-поллинг. Facebook позже перешёл на более эффективные решения (в вебе – на WebSocket, в мобильных клиентах – вообще на отдельный протокол MQTT). Но лонг-поллинг долго оставался надёжной рабочей лошадкой там, где нельзя было использовать что-то более продвинутое.

Сегодня лонг-поллинг считается скорее резервным, устаревающим методом. Он прост, он выручит, если ничего другого нет (например, нужно поддержать старые системные ограничения), но в новых проектах ему обычно предпочитают следующие технологии – они более эффективны и удобны. Первая из них – это Server-Sent Events.

4. Server-Sent Events (SSE) – серверные события

Server-Sent Events (SSE) – это технология, позволяющая серверу стримить данные в браузер по постоянно открытому соединению. Если лонг-поллинг каждые раз разрывал соединение после события, то SSE работают иначе: клиент открывает соединение и держит его открытым постоянно, а сервер периодически отправляет через него данные по мере появления новых событий. Можно сказать, SSE – это стандартизированная реализация паттерна "сервер пушит обновления", выполненная поверх обычного HTTP.

В HTML5 и современных браузерах для SSE предусмотрен удобный API – объект EventSource. Вы создаёте new EventSource(url) в JavaScript, и браузер сам устанавливает соединение с сервером и начинает слушать события. На стороне сервера достаточно выставить специальные заголовки и периодически писать в поток данные в определённом формате.

Как это работает:

На клиенте: создаётся EventSource с URL, например const source = new EventSource('/stream'). Браузер делает запрос на /stream с заголовком Accept: text/event-stream.
На сервере: получив такой запрос, он отвечает статусом 200 и устанавливает заголовки, например:
Content-Type: text/event-stream
Connection: keep-alive
Cache-Control: no-cacheПосле этого соединение не закрывается. Сервер может сразу отправить какое-то приветственное событие, а может и подождать.
Когда на сервере появляются новые данные, он пишет их в открытый поток в формате SSE: каждая «посылка» начинается с префикса data: перед строкой данных и заканчивается двумя переводами строки. Можно также указывать имя события (event: имя) и идентификатор.
На клиенте EventSource ловит эти сообщения: срабатывает событие message или слушатели на конкретные названия (если указано event: myEvent, то можно source.addEventListener('myEvent', ...)).
Так продолжается, пока соединение открыто. Если соединение рвётся, браузер автоматически пытается переподключиться (EventSource это умеет) через несколько секунд. Причём он отправляет заголовок Last-Event-ID с ID последнего полученного события, так что сервер может при восстановлении соединения понять, что клиент пропустил, и дослать при необходимости.

То есть SSE обеспечивает устойчивый однонаправленный канал от сервера к клиенту с минимальными усилиями со стороны разработчика.

Пример (Node.js + Express, отправка SSE):

app.get('/stream', (req, res) => {
res.set({
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive'
});
res.flushHeaders(); // отправим заголовки сразу

const intervalId = setInterval(() => {
const now = new Date().toLocaleTimeString();
// отправляем событие с текущим временем
res.write(`data: ${now}\n\n`);
}, 5000);

// Если соединение закрыто с клиентской стороны – очистим таймер
req.on('close', () => {
clearInterval(intervalId);
});
});

Этот эндпойнт /stream при подключении клиента начинает каждые 5 секунд отправлять текущее время. Обратите внимание, мы используем res.write для отправки данных без завершения ответа. Двойной перевод строки \n\n означает конец одного события SSE. Мы также слушаем событие req.on('close') – когда клиент отключится (например, пользователь закрыл страницу), очищаем интервал, чтобы не продолжать работу впустую.

Пример (клиентский код SSE):

const source = new EventSource('/stream');
source.onmessage = (event) => {
console.log('Пришли данные:', event.data);
};
source.onerror = (err) => {
console.error('SSE ошибка или соединение закрыто', err);
};

Всего пару строк – и браузер начал получать данные от сервера в реальном времени.

Плюсы SSE:

Простота и стандартность. API EventSource в браузере невероятно прост: не нужно писать свой цикл опроса или управлять повторными соединениями – всё происходит автоматически. Формат данных тоже стандартизирован (стрим с data:) и легко читается.
Эффективность для одной стороны. SSE идеально подходят, когда вам нужно только транслировать данные от сервера к клиенту, и нет необходимости часто отправлять что-то обратно. В отличие от WebSocket, SSE не требуют дополнительных обводных путей – используется обычный HTTP. Они также более эффективны, чем лонг-поллинг, потому что нет постоянных реконнектов – одно соединение живёт долго и передаёт много сообщений.
Автоматический ре-коннект. EventSource по умолчанию переподключается, если связь оборвалась. Вам не нужно городить таймеры как в лонг-поллинге – браузер сам повторит попытку через пару секунд. Можно на сервере даже указать интервал повторного подключения (retry: 10000 в миллисекундах) в потоке данных.
Поддержка Event ID. Как упомянуто, SSE позволяют задать каждому сообщению идентификатор (id: 123). Если соединение прервалось, браузер передаст Last-Event-ID: 123 при новом запросе, и сервер сможет понять, что клиент видел по последнее сообщение №123 и начать с 124-го. Это очень полезно, чтобы не потерять события во время временных обрывов связи.
Широкая совместимость серверной инфраструктуры. Так как SSE – это по сути HTTP, они проходят через прокси и файрволлы, которые могут блокировать нестандартные протоколы. Многие корпоративные прокси, например, не любят WebSocket, а SSE для них выглядит как простой длительный HTTP-ответ – обычно они это пропускают. Нет проблем с нестандартными портами или заголовками (кроме специальных SSE заголовков, которые ничего не ломают).
Broadcast (многим клиентам). Для сервера отправлять одно событие на 1000 SSE подключений зачастую проще, чем через 1000 отдельных WebSocket – опять же, потому что это обычный поток. На самом деле под капотом разница не столь велика, но есть мнение, что для рассылки однонаправленных уведомлений SSE потребляют меньше ресурсов. Например, некоторые биржевые тикеры или новости реализованы через SSE, чтобы пушить обновления всем подключённым клиентам.

Минусы SSE:

Односторонний канал. Главный недостаток очевиден: нельзя отправлять данные от клиента к серверу через это же соединение. SSE – только сервер → клиент. Если приложение требует активных действий пользователя (чат, ввод данных, игра) с низкими задержками, SSE придётся комбинировать с другими способами. Обычно в паре с SSE используют обычные AJAX POST-запросы для отправки пользовательских действий. Это не конец света, но уже не так элегантно, как один WebSocket на всё.
Ограниченная поддержка старых браузеров. SSE поддерживаются всеми современными браузерами (Chrome, Firefox, Safari, Edge, даже мобильные) уже давно. Однако, если вдруг нужно работать с чем-то вроде IE10 и ниже – там EventSource нет. При желании, можно полифиллить (SSE можно эмулировать через скрытый iframe или XHR), но это дополнительная морока. Впрочем, Internet Explorer официально почил, так что для большинства проектов это не проблема.
Только текстовые данные. Формат SSE подразумевает, что данные передаются как текст (UTF-8). Браузер API предоставляет event.data всегда строкой. Если нужно передать бинарные данные (например, изображения или аудио-фрагменты) в чистом виде – SSE не подходит. Конечно, можно закодировать бинарные данные в Base64 и отправить как строку, но это увеличивает размер ~на 30%. WebSocket в этом плане гибче, так как умеет и двоичные фреймы.
Ограничение по соединениям (HTTP/1.1). При большом числе открытых SSE соединений можно столкнуться с лимитами. По спецификации HTTP/1.1 браузер ограничивает количество одновременно открытых соединений к одному домену (обычно 6). Если страница открыта в нескольких вкладках, у вас может быть по SSE-коннекту на вкладку, и этот лимит внезапно достигнется, блокируя новые запросы к тому же домену. В современных условиях HTTP/2 решает эту проблему (у HTTP/2 одно физическое соединение, а внутри можно держать много потоков), но если сервер не поддерживает HTTP/2, на большое количество SSE-трансляций надо обратить внимание. WebSocket, кстати, по сути тоже отдельное соединение и также учитывается в лимит, но обычно WS одно на приложение, а SSE можно по незнанию открыть несколько.
Вредно держать “лишние” соединения. Связано с предыдущим: если вы открыли SSE, но ничего по нему особо не идёт, вы всё равно занимаете канал. Например, разработчики отмечают, что мобильные браузеры могут негативно относиться к множеству фоновых соединений. SSE-соединение хоть и спит, но поддерживается открытым. Тут рецепт – открывать SSE только когда нужно, и закрывать (source.close()) если данные больше не нужны.

Тем не менее, Server-Sent Events – отличный инструмент для многих задач. Примеры применения: биржевые котировки, новостные ленты, live-трансляции комментариев, панели мониторинга (когда сервер шлёт обновления метрик) – в общем, всё, где нужно постоянно передавать обновления от сервера, но при этом взаимодействие идёт в одну сторону. Это более элегантно, чем лонг-поллинг, и намного проще, чем управлять полноценным двунаправленным соединением.

SSE появились примерно одновременно с WebSocket (эpoque HTML5), и хотя они менее на слуху, они по-прежнему используются. В некоторых корпоративных системах SSE предпочитают WebSocket именно из-за простоты интеграции и обхода ограничений прокси. Однако, когда речь заходит о полноценном двустороннем взаимодействии в реальном времени, король, безусловно, – это WebSocket.

5. WebSocket – постоянное двунаправленное соединение

WebSocket – это протокол, позволяющий установить постоянное, двунаправленное соединение между браузером и сервером поверх одного TCP-сокета. После установки WebSocket-соединения клиент и сервер могут отправлять данные друг другу в любой момент, независимо от того, кто инициировал связь. Это настоящая двусторонняя “труба”, подходящая для чатов, онлайн-игр, совместного редактирования – всего, где нужно свободно обмениваться сообщениями в реальном времени.

WebSocket был стандартизирован в 2011 году (RFC 6455) и с тех пор получил широкую поддержку во всех браузерах. Его особенность в том, что он начинается как обычный HTTP-запрос, но с запросом “апгрейда” протокола. Клиент посылает специальный заголовок Upgrade: websocket, а сервер, если поддерживает WebSocket, отвечает подтверждением upgrade. После этого соединение переключается из режима HTTP в режим WebSocket. Теперь это не HTTP-протокол, а свой формат фреймов. Но важно, что всё идёт по тому же порту и TCP-соединению.

Особенности WebSocket:

Использует собственные URL-схемы: ws:// для нешифрованного и wss:// для шифрованного (поверх TLS). Например, ws://example.com/chat.
После установления соединения ни браузер, ни сервер не ожидают каких-либо HTTP-запросов для обмена данными. Они посылают друг другу фреймы – куски данных с небольшим заголовком WebSocket. В браузере это доступно через методы socket.send() и обработчик socket.onmessage.
Сообщения могут быть текстовыми или бинарными. WebSocket API в браузере позволяет отправлять String, Blob или ArrayBuffer – что удобно для передачи, например, файлов или медиа-данных.
Соединение обычно остается открытым, пока какая-то из сторон не решит его закрыть (или пока не случится ошибка сети). Можно держать WebSocket открытым часами и днями.

Пример (Node.js WebSocket сервер с использованием библиотеки ws):

Мы создали WebSocket-сервер на порту 8080. При подключении клиента (connection) регистрируем обработчик message – каждое сообщение от клиента выводим на консоль и отправляем обратно с префиксом “Эхо”. Также логируем закрытие соединения. Сервер сразу шлёт клиенту приветствие при подключении.

Пример (клиентский код WebSocket):

Клиент подключается к нашему серверу, отправляет сообщение “Привет сервер!” при открытии соединения и логирует все приходящие сообщения. В данном примере произойдёт обмен: клиент отправит привет, сервер ответит “Добро пожаловать!” и затем эхо “Привет сервер!”, всё это мы увидим в консоли браузера.

Плюсы WebSocket:

Полноценный двусторонний real-time. Это главный козырь: и сервер, и клиент могут отправлять данные независимо друг от друга. Например, в чате вы отправляете сообщение через socket.send() и тут же получаете новое от собеседника через тот же сокет – никаких дополнительных запросов не нужно. Для многопользовательских игр, совместных приложений, где все участники синхронизируются, WebSocket подходит идеально.
Минимальные накладные расходы после установки. В отличие от HTTP, где каждый запрос содержит заголовки, у WebSocket сообщение содержит всего ~2 байта сервисной информации (для коротких текстов). Нет повторяющихся заголовков, нет многократных рукопожатий. Однажды соединившись, мы шлём только полезные данные и минимальный фрейм-префикс. Это экономит трафик и снижает задержки. WebSocket может отправлять очень часто (десятки раз в секунду) – протокол к этому приспособлен.
Поддержка бинарных данных. Как упомянуто, WebSocket без проблем передаёт бинарные блобы. Это открывает возможности для, например, передачи аудио/видео потоков, файлов, или сжатых двоичных сообщений (например, в форматах Protocol Buffers) для экономии.
Хорошая масштабируемость по нагрузке. Несмотря на то, что WebSocket требует держать соединения, современные серверы и инфраструктура умеют справляться с огромным числом веб-сокетов. Например, одна Node.js процесс может держать десятки тысяч соединений, обмениваясь сообщениями. При правильной архитектуре (используя асинхронность) WebSocket-серверы могут быть очень производительными. Также WebSocket хорошо поддерживается облачными провайдерами, есть отдельные сервисы (Pusher, Ably и т.п.), которые берут на себя масштабирование realtime-сообщений.
Универсальность. WebSocket – не привязан к какому-то конкретному типу данных или сценарию. Любую задачу realtime общения можно на нём построить. Поверх WebSocket люди реализуют протоколы чата, уведомлений, игровых синхронизаций, да хоть свой маленький RDP. Это как “сырой сокет” в распоряжении веб-разработчика, но безопасный и проходящий через веб-инфраструктуру.
Стандарт и поддержка. Все современные браузеры поддерживают WebSocket. Серверные реализации есть для любых языков (Node, Python, Java, Go, C#...). Протокол стабилен и практически де-факто стандарт для интерактивных веб-приложений.

Минусы WebSocket:

Более сложная реализация. Внедрение WebSocket требует и на сервере, и на клиенте дополнительного кода и архитектуры. Для сервера это уже не просто HTTP-роутер, а нечто, что умеет держать много соединений и асинхронно с ними работать (например, Node.js идеально подходит, а вот в классическом PHP без дополнительных инструментов – сложно). При разработке нужно учитывать новые типы событий: открытие соединения, закрытие, приход сообщений, возможно, поддерживать протоколирование сообщений, их порядок, размер. Это заметно сложнее, чем обработать разовый запрос и вернуть ответ.
Проблемы с прокси и сетевыми ограничениями. Хотя WebSocket использует стандартный порт 80/443, некоторые корпоративные прокси и сетевые экраны могут блокировать попытки Upgrade-соединения или закрывать долгоживущие соединения. Иногда требуется специальная настройка прокси, чтобы WS трафик проходил. Если прямой доступ затруднён, разработчики прибегают к фолбэкам – например, есть библиотека Socket.IO, которая автоматически может переключиться на лонг-поллинг, если чистый WS не работает. В целом, в 2025 году сети уже дружелюбнее к WebSocket, но нюансы ещё встречаются.
Поддержание соединения. WebSocket-соединение требует поддерживать “живость”. Если клиент или сервер упадёт, нужно уметь обнаружить это и переподключиться. Есть концепция ping/pong (WebSocket поддерживает специальные контрольные фреймы для проверки связи). Это тоже дополнительная логика. Плюс, есть timeout’ы и ограничения: например, некоторые сетевые узлы рвут соединение, если нет активности X минут, поэтому часто реализуют периодическое “heartbeat” сообщение.
Расход ресурсов на большое количество соединений. Хотя мы отметили, что серверы могут держать очень много WebSocket, всё равно это существенно более нагруженно для сервера, чем обычные короткие запросы. Каждое соединение – это некоторая память, открытый сокет, возможно, задача/поток (в не-асинхронных моделях). При тысячах соединений увеличивается потребление памяти. Также, если очень много сообщений, сервер должен успевать их разбирать и рассылать – это нагружает CPU. В общем, высокая интерактивность требует более тщательного мониторинга производительности и масштабирования. При росте аудитории может понадобиться распределять WebSocket-подключения между несколькими серверами и организовывать между серверами обмен (например, с помощью Redis Pub/Sub, чтобы сообщение от пользователя на сервере A дошло до пользователей, подключённых к серверу B). Это всё решаемо, но требует больше компетенций.
Отсутствие встроенного механизма восстановления state. Если SSE имели Last-Event-ID, то WebSocket протокол этого не предоставляет. Если соединение оборвалось, приложение само должно решить, какие данные успели дойти, а какие потерялись, и как их повторно запросить. Обычно поверх WebSocket строят свою логику подтверждений, идентификаторов сообщений, буферизации. Это часть общей сложности, упомянутой выше.
Безопастность и нагрузки: WebSocket позволяет очень активно общаться, что открывает двери для злоупотреблений – скажем, клиент может начать спамить сервер сообщениями или наоборот. Нужно продумывать лимиты, проверки аутентификации (при обычном запросе каждый запрос можно проверить авторизацию, а WS соединение устанавливается один раз – нужно не забыть проверять токены при соединении и чистить сессию при отзыве прав). Также нельзя полагаться на стандартные CSRF защиты и т.п., так как WS – отдельный механизм.

Несмотря на минусы, WebSocket стал ключевой технологией для всего, что требует интерактивности. Чат-приложения, онлайн-игры, совместные редакторы (Google Docs, Miro доски) – практически наверняка используют под капотом WebSocket (в чистом виде или через библиотеки вроде Socket.IO). Для разработчика наличие WebSocket API в браузере – огромный плюс, позволяющий делать то, что раньше было невозможно без костылей.

Кстати, о библиотеках: ранее упомянутая Socket.IO – это популярная библиотека для JavaScript, которая поверх WebSocket реализует удобный интерфейс (события, комнаты, broadcast) и обеспечивает совместимость: если браузер не поддерживает WS или не может установить, она автоматически использует лонг-поллинг. В современном мире это реже требуется, но несколько лет назад Socket.IO спасала ситуацию на старых браузерах или кривых сетях. Сейчас, когда практически везде WebSocket доступен, проекты могут использовать и “чистый” WebSocket API или более легковесные библиотеки.

Подытоживая про WebSocket: это мощный инструмент для постоянного двунаправленного соединения. Если нужно максимально интерактивное взаимодействие, с минимальными задержками и активной отдачей/приёмом – скорее всего, вам нужен WebSocket.

6. Другие методы и протоколы (WebRTC, HTTP/2 Push, WebTransport, Web Push)

Мы рассмотрели основные подходы, непосредственно встроенные в веб-платформу: HTTP запросы, polling, long polling, SSE, WebSocket. Но на горизонте (и отчасти уже в практике) есть и другие способы обмена данными, которые стоит упомянуть кратко:

HTTP/2 Server Push. Версия HTTP/2 протокола вводила возможность серверу пушить ресурсы без запроса. Например, клиент запрашивает страницу, а сервер сам может отправить впрок связанный CSS или скрипт. Идея в том, чтобы уменьшить задержки на загрузке страницы. Однако для произвольных данных (типа обновлений приложения) HTTP/2 Push не прижился – браузеры ограничивали его, и в HTTP/3 его фактически убрали. Этот механизм не путайте с SSE: push в HTTP/2 – это про заранее отправить страницу ресурсы, а не про динамические события.
WebRTC Data Channels. WebRTC – известная технология для видео/аудио звонков и p2p связи между браузерами. Менее известно, что WebRTC позволяет открыть data channel – канал для передачи произвольных данных между участниками. Он может работать по UDP (ненадёжно, но с минимальной задержкой) или TCP (надёжно). Теоретически, WebRTC data channel можно использовать и для общения клиент-сервер, если сервер тоже поддерживает WebRTC стек. Но это сложно и обычно нецелесообразно. WebRTC в основном для peer-to-peer общения (например, файлообмен между двумя клиентами напрямую, игровые сетевые соединения между игроками без сервера). Для клиент-сервер WebRTC требует всё равно настроить сигнальную коммуникацию (а это обычно делается через тот же WebSocket/SSE). Так что WebRTC упоминаем, но в контексте классического веб-клиент <-> сервер его рассматривать не будем. Это скорее про клиент <-> клиент связь.
WebTransport. Совсем свежая штука, которая, возможно, в будущем дополняет WebSocket. WebTransport – это API для коммуникации поверх протокола HTTP/3 (QUIC). Проще говоря, это возможность открыть между браузером и сервером соединение, которое поддерживает множественные потоки, надёжную и ненадёжную доставку и прочие фишки QUIC/HTTP3. WebTransport ещё в черновиках стандарта (на 2025 год) и поддерживается экспериментально (Chrome, возможно Firefox, но не в Safari точно). Серверных реализаций мало, Node.js пока нативно не умеет WebTransport. Потенциально WebTransport позволит, например, стримить данные с более низкими задержками, отправлять из браузера датаграммы (UDP-подобно) – в тех случаях, где WebSocket избыточен по надежности или наоборот недостаточно быстр. Но пока это на будущее. Для большинства задач WebSocket справляется, а WebTransport – для специфических случаев (игры, AR/VR стримы) и потребуется ещё написать немало кода (API довольно низкоуровневое).
MQTT и другие протоколы поверх WebSocket. Сами по себе MQTT, AMQP, XMPP – это не веб-стандарты, а отдельные протоколы обмена сообщениями, популярные в IoT, мессенджерах и пр. Однако в браузере их можно использовать, если запускать через WebSocket. Например, существует MQTT over WebSocket: клиент (браузер) открывает WebSocket до MQTT-брокера, а дальше говорит на языке MQTT внутри этого сокета. Зачем упоминаем? Это показывает, что WebSocket – базовая труба, поверх которой можно наворотить свои протоколы. XMPP (старый протокол для чат-серверов) тоже можно использовать через websocket с соответствующей библиотекой. Но браузер не может самостоятельно открыть чисто TCP-сокет к произвольному порту – только через WebSocket (или HTTP). Так что эти вещи – экзотика в вебе, но упомянуть стоило: вдруг вы услышите, что “наш фронтенд общается с сервером по MQTT” – знайте, что в реальности это MQTT поверх веб-сокета.
Веб-пуш-уведомления (Web Push API). Сюда же стоит включить способ доставки, который работает даже когда браузер не на сайте: push-уведомления через сервис-воркеры. В современном вебе сайт (с согласия пользователя) может подписаться на push-уведомления через сервис-воркер. Сервер через специальный push-сервис отправляет уведомление, и оно приходит на устройство, показывая уведомление, или пробуждая сервис-воркер в фоне. Это немного выбивается из нашего ряда (так как не прямое общение клиента с вашим сервером — там посредник push-сервис, да и предназначение скорее оповестить пользователя). Но для полноты скажем: вне активной вкладки push-уведомления – практически единственный способ “достучаться” из сервера в браузер. Ни WebSocket, ни SSE не будут работать, если пользователь закрыл страницу. А push – доставит (при условии разрешений).
RPC поверх HTTP/2 (gRPC-Web). Ещё одна технология: gRPC – это фреймворк удалённого вызова процедур, обычно поверх HTTP/2 с бинарным протоколом Protocol Buffers. В браузере напрямую полноценный gRPC не работает, но есть адаптация gRPC-Web, которая общается с специальным прокси на сервере. Это узкоспециализированная вещь, но некоторые веб-приложения её применяют. По сути, это альтернатива REST/AJAX для запросов, но с возможностью стриминга. Например, gRPC поддерживает Server streaming – очень похож на SSE, но внутри HTTP/2. В итоге браузер может получать поток данных от сервера в ответ на один запрос. gRPC-Web не столь распространён, но если слышите, что фронтенд вызывает gRPC сервис, значит, скорее всего, работает эта схема. Однако, строго говоря, gRPC-Web – всё равно обёртка над уже известными механизмами (HTTP/2, возможно webSockets), поэтому отдельным фундаментальным способом взаимодействия не является.

В общем, мир веб-коммуникаций не стоит на месте. Но базовые потребности обычно покрываются комбинацией HTTP-запросов (куда ж без них) и реалтайм канала – будь то SSE или WebSocket, а в перспективе, возможно, WebTransport. А теперь давайте резюмируем и наглядно сравним рассмотренные подходы.

7. Мобильные и настольные приложения: особые случаи взаимодействия

До сих пор мы говорили о коммуникации в браузере. А что если у нас не веб-страница, а мобильное приложение или десктопная программа? Стоит упомянуть несколько моментов про них:

Использование тех же протоколов. Мобильные и десктопные приложения обычно общаются с сервером тоже по HTTP(S) и WebSocket. Практически все перечисленные методы им доступны. Разница в том, что нет ограничений браузера: приложение может открыть произвольный сокет. Например, мобильный клиент может установить прямое TCP-соединение к своему серверу и говорить на каком угодно протоколе (хоть свой бинарный). Веб-браузер так не может – у него в арсенале фактически HTTP, WebSocket, WebRTC. Поэтому нативные приложения более гибки. К примеру, многие мобильные мессенджеры (Telegram, WhatsApp) не используют WebSocket, а работают поверх своего TCP-протокола или MQTT – так эффективнее для них. Но браузерные версии тех же мессенджеров вынуждены или эмулировать через WebSocket, или иметь ограниченный функционал.
Пробуждение и фоновые соединения. На мобильных ОС (Android, iOS) есть важное ограничение: приложения не могут держать постоянное соединение в фоне длительное время. Операционная система, чтобы экономить батарею, через несколько минут после свертывания приложения может закрыть любые сокеты и “заморозить” процессы. Поэтому, даже если мобильное приложение установило WebSocket, уйдя в фон, оно не будет постоянно слушать его. Именно поэтому придуманы push-уведомления на мобильных: они позволяют серверу доставить сигнал на устройство, который ОС покажет пользователю и/или разбудит приложение на короткое время. По сути, мобильные push – аналог веб-push, но встроенный в платформу (Google Firebase Cloud Messaging, Apple APNs). Так вот, для устойчивой доставки данных на телефон, когда приложение не активно, разработчики опираются на push. Например, вы получили новое сообщение в чат – сервер отправляет push, телефон показывает нотификацию "Вам сообщение". Когда вы тапаете, приложение просыпается и уже напрямую по своему протоколу фетчит подробности.
Десктопные приложения (например, игры на PC, или специализированные клиенты) подобных строгих ограничений не имеют – приложение на компьютере может держать соединение открытым сколько угодно. Но и там свои нюансы: напр, firewall пользователя может блокировать нестандартные порты, поэтому почти все делают общение тоже через 443 порт, чтобы не было проблем.
Сокеты и протоколы ОС. На уровне OS вы можете использовать UDP протокол, который браузеру недоступен. Это важно для некоторых приложений – например, онлайн-игры часто предпочитают UDP (меньше задержка, не ждет подтверждений). Браузеру UDP напрямую не светит (WebRTC – единственный обходной путь).
gRPC, Thrift и прочие. Вне браузера популярны разные системы коммуникации, которые не подходят для браузера из-за отсутствия поддержки. Например, клиент на C++ может использовать gRPC поверх HTTP/2 или вообще собственный RPC над TCP – всё, что душе угодно, нет sandbox ограничений.
Старые технологии. На заре мобильных приложений иногда применяли технику, похожую на polling: периодически разбудить приложение фоновым сервисом и опросить сервер. Сейчас это скорее вредно (расход батареи) и платформы ограничивают фоновые пробуждения. Правильный путь – push нотификации для значимых событий.
Локальные соединения. Если говорить про десктоп: иногда клиент и сервер могут бегать на одном компьютере. Например, десктопное приложение запускает локальный сервер и взаимодействует через localhost (такие схемы есть для интеграции с аппаратным обеспечением). В таких случаях можно вообще любую технологию применить, вплоть до shared memory – но это уже за гранью нашей темы.

Итого, нативные приложения более свободны в выборе метода: они тоже делают HTTP API запросы, тоже могут открывать WebSocket для чатов или игр, но помимо этого, у них есть push-уведомления как канал от сервера даже в спящем состоянии, и они могут использовать более эффективные бинарные протоколы, неподдерживаемые браузером. В вебе же мы ограничены тем, что рассмотрели выше.

Стоит упомянуть, что в браузере тоже есть push-уведомления (мы написали про Web Push API), но они требуют разрешения пользователя и работают через сервис-воркер. То есть веб-приложение тоже может получить данные в фоновом режиме, но канал для этого отдельный, с ограничениями (размер payload, отсутствие гарантии мгновенности).

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

8. Сравнение подходов: что выбрать?

Напоследок сведём ключевые различия, плюсы и минусы рассмотренных способов взаимодействия веб-клиента с сервером:

Обычный HTTP запрос (включая AJAX):
Когда использовать: статические страницы, редкие запросы за данными, классические REST API вызовы. Хорош для случаев, где данные нужны по требованию пользователя (нажатие кнопки, загрузка страницы) или периодическое обновление не в реальном времени.
Плюсы: простота, низкая сложность реализации. Один запрос – один ответ. Можно кешировать, повторять, использовать весь экосистемный инструментарий (прокси, CDN, и т.д.). Поддерживается везде.
Минусы: не подходит для мгновенных обновлений от сервера, потому что сервер не может сам начать диалог. Если нужно непрерывное обновление, придётся городить опрос.
Пример: загрузка профиля пользователя по REST API при открытии страницы; отправка формы с данными.
Polling (периодический опрос):
Когда использовать: очень ограниченные случаи, когда обновления редки и не критична небольшая задержка, и при этом не хочется внедрять более сложные решения. Можно как временное решение.
Плюсы: легко сделать из обычных запросов, не требует ничего дополнительного. Управляем частотой опроса.
Минусы: либо задержки (при большом интервале), либо нагрузка (при частом интервале). Много пустых запросов, не масштабируется на большое число клиентов.
Пример: простое веб-приложение, которое раз в минуту опрашивает сервер, готов ли отчёт для скачивания. Или проверка статуса сервера каждые 30 сек (где точность не особо важна).
Long polling (длинный опрос):
Когда использовать: как более эффективную альтернативу polling, если по каким-то причинам не можете использовать WebSocket или SSE. Также как фолбэк для старых окружений. Подходит, когда обновления должны появляться быстро, но двунаправленность не нужна (или низкая частота отправки от клиента).
Плюсы: существенно снижает лишние запросы, быстро доставляет данные. Работает везде, где есть HTTP. Простая логика на фронте (пошёл запрос – жди – получил – сразу новый запрос).
Минусы: держит соединения, усложняет сервер. Не умеет отправлять от клиента (кроме как отдельными запросами). В больших масштабах тяжело (10000 пользователей = 10000 постоянно висящих HTTP запросов). По эффективности уступает SSE/WebSocket, но требует примерно ту же инфраструктуру (async сервер).
Пример: веб-чат в эпоху до WebSocket (Facebook Chat ранних версий, долгие опросы на форумах для “новых сообщений”).
Server-Sent Events (SSE):
Когда использовать: если нужно регулярно отправлять события от сервера к клиенту, а от клиента ответная связь либо не нужна, либо может быть разовой/редкой (не требующей realtime). Отлично для стримов данных, нотификаций, обновления лент, которые идут только в одну сторону.
Плюсы: очень легковесно и удобно для server→client оповещений. Нативная поддержка в браузере (EventSource). Автоматический ре-коннект и отсутствие лишних запросов. Просто внедрить на сервере поверх существующего HTTP. Масштабируется лучше, чем long polling (меньше перезапросов).
Минусы: канал только в одну сторону. Если клиенту нужно активно общаться, придется смешивать с другими методами. Не подходит для бинарных данных без доп. кодирования. Требует чтобы сервер мог долго держать соединение (поддержка HTTP/1.1 keep-alive или HTTP/2).
Пример: сайт биржи, транслирующий котировки акций; панель администратора, где сервер пушит системные метрики; лента комментариев конференции, обновляющаяся в реальном времени в режиме “только чтение”.
WebSocket:
Когда использовать: при активном двустороннем обмене или очень высоких требованиях к интерactivity. Чаты, игровые приложения, мгновенные уведомления с обратной связью, совместное редактирование – все случаи, где пользователь и сервер постоянно обмениваются сообщениями.
Плюсы: полноценный двунаправленный канал, минимальные задержки и оверхед, поддержка как текстовых, так и бинарных данных. После установления соединения – очень эффективен. Подходит для сложных реалтайм-приложений. Позволяет реализовать богатые протоколы поверх себя.
Минусы: более сложен в реализации и поддержке. Требует на сервере держать соединения и уметь с ними работать (не все архитектуры это умеют по умолчанию). Может сталкиваться с сетевыми ограничениями (нужна настройка прокси, TLS termination, etc). Нужно самостоятельно решать задачи повторного подключения, сохранения состояния клиента при реконнекте. Не оправдан для простых случаев, где достаточно одностороннего потока или редких обновлений – то есть избыточен, если задача может решиться SSE или даже лонг-поллингом.
Пример: онлайн-игра в браузере (например, многопользовательская стратегия, где состояние синхронизируется постоянно между игроками), корпоративный мессенджер в виде веб-приложения, приложение для трейдинга с мгновенными обновлениями и передачей ордеров, совместный редактор кода, где каждый символ рассылается всем участникам с минимальной задержкой.
Другие / специализированные:
HTTP/3 + WebTransport: стоит рассматривать, если проект нацелен на использование самых новых технологий и есть необходимость в нестандартных режимах передачи (например, передача данных, где часть может быть ненадёжной ради скорости – игровой поток). Пока (2025 г.) – экспериментальная область. В перспективе может стать мейнстримом, если браузеры и сервера широко внедрят HTTP/3.
WebRTC: если вашему приложению нужно прямое p2p общение между пользователями (например, видеозвонок, или передача файла напрямую) – используйте WebRTC. Но это не совсем “клиент-сервер” модель, а скорее сеть клиентов. Сервер участвует только в установлении связи.
Web Push: отличное решение, чтобы уведомить пользователя о событии, когда он не на сайте. Если ваш сервис хочет, чтобы пользователь получил оповещение (например, “товар обратно в наличии!”) – Web Push это сделает. Однако, это скорее дополняет основные методы: push не предназначен для передачи большого объёма данных или длительного общения – он разбудит приложение, а дальше оно уже, вероятно, соединится по WebSocket или опросит сервер.

Наконец, важный совет по выбору: ориентируйтесь на потребности вашего приложения. Нет смысла тянуть WebSocket, если достаточно раз в день делать запрос по крону. И наоборот, пытаться опросом добиться молниеносного отклика – заведомо тупиковый путь, когда есть готовый инструмент realtime-связи.

Сейчас весьма распространён подход, когда сочетаются разные методы:

Основные данные грузятся запросами (REST API или GraphQL).
Для оповещений и обновлений используется WebSocket или SSE, которые запускаются после загрузки страницы.
Если WebSocket падает или недоступен, можно попытаться переключиться на SSE или лонг-поллинг как резерв.
Для фона и критичных уведомлений (особенно на мобиле) – подключаются push-уведомления.

Такое многоканальное общение – это нормально. Ведь разные задачи имеют разные требования.

В заключение: мы прошли путь от обычного HTTP GET до продвинутых постоянных соединений. Веб-клиент сегодня располагает внушительным арсеналом способов поговорить с сервером. От нас, разработчиков, требуется выбрать нужный инструмент под задачу. Простые вещи решаются простыми средствами, а сложные интерактивные приложения – благо, теперь реализуемы прямо в браузере. Главное – понимать ограничения каждого подхода. Надеюсь, теперь эта картина стала яснее, и фразы вроде “лонг-поллинг vs WebSocket” или “что такое SSE” больше не вызывают недоумения. Успехов в разработке, и пусть ваши клиент-серверные связи будут надёжными и быстрыми!