WebSocket: как не завалить реальное время

WebSocket — это не просто "двусторонний протокол". Это решение, которое меняет логику работы приложений, когда нужно передавать данные между клиентом и сервером не по запросу, а по событию. Но если не учесть детали, можно получить систему, которая будет тормозить, падать или съедать кучу ресурсов. Давайте разберёмся, как это работает на самом деле, а не в учебниках.

Проблема: почему HTTP не тянет

Представьте чат. Пользователь отправляет сообщение — сервер его получает, сохраняет и отправляет всем остальным. В HTTP это выглядит так:

  1. Клиент отправляет POST-запрос на /send-message.
  2. Сервер обрабатывает запрос, сохраняет сообщение в БД.
  3. Сервер отправляет ответ (например, 200 OK).
  4. Клиент получает ответ и сам запрашивает обновления через /get-messages?since=last_id.

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

  • Задержка от 1 до 10 секунд между обновлениями (в зависимости от настройки).
  • Лишние HTTP-заголовки, сетевой трафик, нагрузка на сервер.
  • Если клиент отключился, он может пропустить сообщения.

WebSocket решает эту проблему, открывая постоянное соединение, где сервер может сам отправлять данные клиенту, как только они появятся.

Как это работает на самом деле

WebSocket — это протокол, который работает поверх TCP. Он позволяет:

  • Открывать одно соединение на длительный срок.
  • Отправлять данные в любом направлении (клиент → сервер или сервер → клиент).
  • Минимизировать накладные расходы (нет HTTP-заголовков на каждое сообщение).

Но есть подводные камни:

  1. Соединения не вечные — они могут падать из-за тайм-аутов, прокси, брандмауэров или плохой сети.
  2. Сервер должен поддерживать состояние — если у вас 10 000 активных соединений, это нагрузка на память и CPU.
  3. Масштабирование — не тривиальная задача — нужно думать о балансировщиках, шардинге, репликации.

Практика: как развернуть WebSocket в продакшене

1. Выбор инструментов

Не все серверы поддерживают WebSocket "из коробки". Вот что работает на практике:

  • Node.js — ws или Socket.IO (если нужна совместимость с браузерами и fallback на polling).

    const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    console.log(`Received: ${message}`);
    // Отправляем обратно всем клиентам
    wss.clients.forEach(client => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(`Echo: ${message}`);
      }
    });
  });
});

  • Python — websockets или FastAPI с websockets.

    import asyncio
import websockets

async def handle_connection(websocket, path):
    async for message in websocket:
        print(f"Received: {message}")
        await websocket.send(f"Echo: {message}")

start_server = websockets.serve(handle_connection, "localhost", 8765)
asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

  • Go — стандартная библиотека net/http с HandleFunc для WebSocket.

    package main

import (
    "log"
    "net/http"
)

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
    ws, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println(err)
        return
    }
    for {
        msg := <-ws.ReadMessage()
        log.Printf("Received: %s", msg)
        ws.WriteMessage(1, msg) // Отправляем обратно
    }
}

func main() {
    http.HandleFunc("/ws", handleWebSocket)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

2. Конфигурация Nginx (если нужен терминатор)

Если WebSocket проходит через Nginx, нужно правильно настроить проксирование:

location /ws {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Важно: Без Upgrade и Connection "upgrade" WebSocket не заработает.

Типичные ошибки и как их избежать

  1. Не закрываем соединения

    • Проблема: Клиенты остаются подключёнными годами, съедая память.
    • Решение: Устанавливайте тайм-ауты и закрывайте неактивные соединения.
    wss.on('connection', (ws) => {
  ws.isAlive = true;
  ws.on('pong', () => { ws.isAlive = true; });
  setInterval(() => {
    if (!ws.isAlive) return ws.terminate();
    ws.isAlive = false;
    ws.ping();
  }, 30000); // Тайм-аут 30 секунд
});

  2. Не думаем о масштабировании

    • Проблема: Один сервер не потянет 10 000 соединений.
    • Решение: Используйте балансировку (например, Redis Pub/Sub для синхронизации сообщений между серверами).

  3. Игнорируем падения соединений

    • Проблема: Клиент отключился, сервер не знает.
    • Решение: Реализуйте механизм реконнекта на клиенте.
    let socket;
function connect() {
  socket = new WebSocket("ws://localhost:8080");
  socket.onclose = () => setTimeout(connect, 1000); // Переподключаемся каждую секунду
}
connect();

  4. Отправляем большие пакеты

    • Проблема: WebSocket не оптимизирован для больших данных (например, видео).
    • Решение: Используйте бинарные протоколы (например, Protocol Buffers) или разбивайте данные на chunks.

  5. Не защищаем WebSocket от DDoS

    • Проблема: Злоумышленник может залить сервер тысячами соединений.
    • Решение: Лимите количество соединений от одного IP (например, через Nginx или Cloudflare).

Пример: реальный чат на WebSocket

Допустим, у нас есть чат с комнатами. Вот как это может выглядеть:

Сервер (Node.js)

const WebSocket = require('ws');
const rooms = new Map(); // { roomId: Set<WebSocket> }

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    const { roomId, text } = JSON.parse(message);
    if (!rooms.has(roomId)) rooms.set(roomId, new Set());
    rooms.get(roomId).add(ws);

    // Отправляем всем в комнате
    rooms.get(roomId).forEach(client => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify({ text, from: "server" }));
      }
    });
  });
});

Клиент (JavaScript)

const socket = new WebSocket('ws://localhost:8080');
socket.onopen = () => {
  socket.send(JSON.stringify({ roomId: "general", text: "Привет!" }));
};
socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log(`Новое сообщение: ${data.text}`);
};

Проблемы в этом примере:

  • Нет обработки ошибок (например, если JSON.parse упадет).
  • Нет проверки на дублирующиеся сообщения.
  • Нет аутентификации (любой может присоединиться к комнате).

Вывод: когда WebSocket — правильное решение, а когда нет

WebSocket — это инструмент для реального времени, но он не панацея.

✅ Используйте WebSocket, если:

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

❌ Не используйте WebSocket, если:

  • Вам нужна простота — REST API проще в отладке и масштабировании.
  • Ваши данные большие (например, видеостриминг лучше через HLS или WebRTC).
  • У вас мало ресурсов — поддержка тысяч соединений требует мощного сервера.

Практический совет:

Начните с прототипа на Socket.IO (он автоматически падает на polling, если WebSocket недоступен). Когда понятно, что именно вам нужно, переходите на чистый WebSocket и оптимизируйте.

Если вы уже используете WebSocket в продакшене — расскажите в комментариях, с какими проблемами столкнулись и как их решили. А если только планируете — учтите, что это не просто "открыл соединение и забыл". Это система, за которой нужно следить.