Что такое WebSocket и в каких сценариях его использовать

Что проверяют

Знаете ли вы, чем постоянное соединение отличается от цепочки HTTP-запросов, и когда оно оправдано. В Python вопрос почти всегда продолжается практикой: как это живёт под ASGI-сервером и что ломается при нескольких воркерах.

Как отвечать

WebSocket это протокол поверх TCP с двусторонним обменом по одному соединению. Начинается он обычным HTTP-запросом с заголовком Upgrade, сервер отвечает кодом 101, после чего стороны шлют кадры в любом направлении без нового рукопожатия. Поверх TLS это схема wss.

@app.websocket("/ws")
async def feed(ws: WebSocket):
    await ws.accept()
    while True:
        msg = await ws.receive_text()
        await ws.send_text(msg)

Когда брать: живая лента котировок, чат, совместное редактирование, прогресс долгой задачи. Когда не брать: редкие односторонние уведомления, тут проще Server-Sent Events или обычный опрос, а загрузка файлов и кеширование остаются за HTTP.

Дальше про эксплуатацию, это и отличает ответ практика. Соединение держит состояние, поэтому воркеры перестают быть равноправными и для рассылки между процессами нужен общий брокер, обычно Redis. Балансировщик настраивают на липкие сессии и длинный таймаут простоя. Авторизацию передают билетом в параметре или подпротоколом, потому что браузерный API не даёт задать заголовок. Стек: FastAPI, Starlette или Django Channels под uvicorn, библиотека websockets для клиента и простого сервера.

Где спотыкаются

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

Пишут echo-обработчик и считают задачу решённой. В рабочем коде нужны ping и таймаут чтения, иначе повисшие соединения копятся, нужен лимит размера сообщения и обработка WebSocketDisconnect, иначе исключения засыпают логи.

Забывают, что обрыв неизбежен. Клиент обязан переподключаться с растущей паузой, а сервер уметь отдать пропущенное: нумерация сообщений или запрос состояния после восстановления связи. Без этого пользователь видит устаревшие данные и не знает об этом.