Как работают вебсокеты
Что проверяют
Тестировщика спрашивают не про определение, а про проверяемость: где посмотреть кадры, что ломать, какие дефекты специфичны именно для постоянного соединения.
Как отвечать
- Протокол RFC 6455 поверх одного TCP-соединения. Начинается обычным HTTP-запросом GET с заголовками
Upgrade: websocket,Connection: UpgradeиSec-WebSocket-Key, сервер отвечает кодом 101 Switching Protocols и заголовкомSec-WebSocket-Accept. Дальше HTTP-семантики нет: ни методов, ни статусов, только кадры. - Кадры бывают текстовые, бинарные и управляющие (ping, pong, close), кадры от клиента всегда маскируются. Схемы
ws://иwss://, порты 80 и 443. - Обе стороны шлют сообщения в любой момент, ответ на конкретный запрос протокол не гарантирует: соответствие обеспечивает прикладной формат, обычно идентификатор в JSON.
- Инструменты: вкладка Network, фильтр WS, список Messages с направлением и временем кадров. Для ручных сценариев wscat или Postman, для нагрузки k6 или Artillery.
- Что ломать: обрыв сети и переподключение (дубли сообщений, восстановление подписок, порядок), таймаут прокси на простое (нужны ping и pong), лимит соединений на пользователя, поведение при протухшем токене.
- Безопасность: правило одного источника к вебсокетам не применяется, а куки браузер шлёт. Сервер обязан проверять
Originи токен, иначе возможен перехват соединения с чужого сайта.
Где спотыкаются
Говорят про слабую поддержку старыми браузерами. Она есть везде с 2011 года, реальные преграды другие: корпоративные прокси и балансировщики, которые режут длинные соединения.
Проверяют только счастливый путь в стабильной сети. Основная масса дефектов живёт в переподключении и в состоянии клиента после него.
Путают вебсокеты с SSE. SSE это односторонний поток поверх HTTP со встроенным переподключением, у вебсокета связь двусторонняя, а переподключение пишут руками.
Забывают про горизонтальное масштабирование: без общей шины сообщение получают только клиенты того инстанса, где оно родилось. На одном сервере баг не воспроизводится.