WebSocket простыми словами: когда нужен real-time

Короткий ответ

WebSocket — это способ держать постоянное соединение между браузером и сервером, чтобы они могли обмениваться сообщениями в обе стороны без перезагрузки страницы и без постоянных повторных HTTP-запросов

Если говорить совсем по-человечески: обычный HTTP похож на переписку письмами "спросил — получил ответ — соединение закончилось". WebSocket похож на открытый звонок: соединение уже есть, обе стороны могут говорить, когда появилось новое событие

WebSocket нужен там, где пользователь должен видеть изменения почти сразу:

• чат;
• онлайн-статус;
• уведомления;
• живые заявки;
• совместное редактирование;
• игровые события;
• панели мониторинга;
• стриминговые инструменты;
• обновление цен, ставок, заказов или статусов.

Почему люди ищут websocket что это

По статистике видно, что запрос широкий: websocket, websocket что это, websocket это, websocket как работает, что такое websocket для чайников. Значит, человек еще не обязательно хочет код. Он хочет понять, почему обычного запроса к API уже не хватает

Задача этого урока — дать понятную картину, чтобы дальше было легче перейти к практике на Node.js, Python, FastAPI или Nginx

Как работает обычный HTTP

Обычный сценарий:

1. Браузер отправляет запрос.
2. Сервер отвечает.
3. Запрос завершен.

Пример:

const response = await fetch('/api/orders');
const orders = await response.json();

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

Можно делать polling:

setInterval(async () => {
  const response = await fetch('/api/orders');
  const orders = await response.json();
  renderOrders(orders);
}, 5000);

Это работает, но у подхода есть минусы:

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

Как работает WebSocket

С WebSocket браузер сначала устанавливает соединение:

const socket = new WebSocket('ws://localhost:3000');

Когда соединение открыто, клиент и сервер могут отправлять сообщения друг другу

socket.addEventListener('open', () => {
  socket.send('Привет, сервер');
});

socket.addEventListener('message', (event) => {
  console.log('Сообщение от сервера:', event.data);
});

Сервер тоже может отправить сообщение сам, не дожидаясь нового HTTP-запроса. Это главное отличие для практики

Что означает ws:// и wss://

Для WebSocket используют два протокола:

• ws:// — обычное незашифрованное соединение;
• wss:// — защищенное соединение поверх TLS, аналог HTTPS.

Локально на компьютере часто используют:

ws://localhost:3000

На настоящем сайте с HTTPS обычно нужен:

wss://example.com/socket

Если страница открыта по HTTPS, а вы пытаетесь подключиться к ws://, браузер может заблокировать соединение как mixed content. Для продакшена почти всегда нужен wss://

Где WebSocket действительно нужен

Чат

Пользователь отправил сообщение, остальные участники должны увидеть его сразу

Уведомления

Например, в админке появилась новая заявка, заказ сменил статус, платеж прошел

Live-dashboard

Счетчики, метрики, мониторинг серверов, очередь задач, состояние роботов или устройств

Совместная работа

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

Игровые и интерактивные события

Где задержка и двусторонний обмен важнее, чем простой запрос-ответ

Где WebSocket не нужен

WebSocket не стоит добавлять "на всякий случай"

Он не нужен, если:

• данные обновляются редко;
• пользователь сам нажимает кнопку "обновить";
• достаточно обычного REST API;
• нужно просто отправить форму;
• страница статичная;
• событие может прийти с задержкой в десятки секунд.

Для многих задач хватит обычного HTTP, polling или Server-Sent Events. Хороший разработчик не тащит real-time туда, где он только усложнит жизнь

WebSocket, polling и SSE

Простое сравнение:

Подход	Когда подходит	Минус
HTTP request	Получить данные по действию пользователя	Сервер не может сам отправить обновление
Polling	Простые периодические обновления	Лишние запросы и задержка
SSE	Сервер отправляет события клиенту	Обычно односторонний поток
WebSocket	Двусторонний real-time	Нужно держать соединения и думать о масштабировании

Если вам нужны только уведомления от сервера к браузеру, иногда SSE проще. Если клиент и сервер оба активно отправляют события, WebSocket подходит лучше

Мини-сцена из реального проекта

Допустим, я делаю маленькую CRM для своих заявок. На сайте есть форма, а в админке открыта страница "Новые лиды". Без WebSocket админка может каждые 10 секунд спрашивать сервер:

"Есть новые заявки?"

С WebSocket сервер сам говорит:

"Появилась новая заявка, вот данные."

Для пользователя это ощущается как живая система: заявка появилась сразу, без перезагрузки и без кнопки

Жизненный цикл соединения

В браузере обычно работают с четырьмя событиями:

const socket = new WebSocket('ws://localhost:3000');

socket.addEventListener('open', () => {
  console.log('Соединение открыто');
});

socket.addEventListener('message', (event) => {
  console.log('Получено:', event.data);
});

socket.addEventListener('close', () => {
  console.log('Соединение закрыто');
});

socket.addEventListener('error', () => {
  console.log('Ошибка WebSocket');
});

Для первого понимания этого достаточно:

• open — можно отправлять сообщения;
• message — пришли данные;
• close — соединение закрыто;
• error — что-то пошло не так.

Важные ограничения

WebSocket не заменяет авторизацию

Если API закрыт, WebSocket тоже должен проверять пользователя. Нельзя думать: "Раз это socket, значит туда никто не доберется"

WebSocket не отменяет хранение данных

Сообщение можно отправить мгновенно, но если оно важно, его нужно сохранить в базе

WebSocket нужно масштабировать

Когда серверов несколько, нужно понимать, как рассылать события между ними. Часто подключают Redis pub/sub, очереди или отдельный real-time слой

WebSocket не любит случайные прокси-настройки

На локальном компьютере все может работать, а на сервере ломаться из-за Nginx, HTTPS, таймаутов или заголовков Upgrade

Частые ошибки новичка

Путать WebSocket с REST API

REST хорош для обычных операций: получить список, создать запись, обновить профиль. WebSocket хорош для событий, которые должны прилетать в реальном времени

Открывать много соединений без необходимости

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

Не обрабатывать закрытие соединения

Интернет пропадает, вкладка засыпает, сервер перезапускается. Клиент должен понимать, что соединение может закрыться

Использовать ws:// на HTTPS-странице

На продакшене почти всегда нужен wss://

Ответы на эти вопросы могут быть для вас полезными

WebSocket — это отдельный язык?

Нет. Это протокол и браузерный API. Клиент можно писать на JavaScript, сервер — на Node.js, Python, Go, Java, C# и других языках

Чем WebSocket отличается от HTTP?

HTTP обычно работает как запрос-ответ. WebSocket после установки соединения позволяет обеим сторонам отправлять сообщения в любой момент

Когда лучше не использовать WebSocket?

Если данные обновляются редко или достаточно обычного запроса к API. WebSocket добавляет сложность: соединения, авторизация, reconnect, прокси, масштабирование

Что такое wss://?

Это защищенный WebSocket, аналог HTTPS для WebSocket-соединений. На сайтах с HTTPS обычно нужен именно wss://

Можно ли проверить WebSocket без своего клиента?

Да. Есть online-инструменты, Postman, браузерная консоль и CLI-клиенты. Но для закрытых систем с токенами лучше проверять осторожно и не вставлять секреты в случайные сайты

Что почитать дальше по WebSockets

Если вы собираете тему по шагам, рядом лучше открыть:

• WebSocket на JavaScript и Node.js: мини-чат в браузере — сразу увидеть протокол в мини-чате на JavaScript и Node.js.
• WebSocket на Python: быстрый пример клиента и сервера — собрать такой же принцип на Python-клиенте и сервере.
• WebSocket test online: как проверить соединение — проверить соединение без полноценного приложения.
• Nginx и WebSocket proxy: почему локально работает, а на сервере нет — понять, почему на сервере WebSocket часто ломается из-за proxy.