В чем разница WebSocket и HTTP запроса

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

Понимаете ли вы модель взаимодействия каждого протокола и умеете ли вывести из неё, что и как тестировать. Следом почти всегда спрашивают, как вы смотрите WebSocket-трафик и какие негативные сценарии проверяете.

Как отвечать

Суть различий:

• модель: HTTP это запрос и ответ, инициатор всегда клиент. WebSocket это двунаправленный канал: после установки соединения сообщения шлют обе стороны в любой момент;
• соединение: в HTTP/1.1 соединение по умолчанию живёт после ответа (keep-alive), HTTP/2 гоняет много запросов через одно. Но каждый запрос несёт заголовки, куки, токен. У WebSocket заголовки только в рукопожатии, дальше идут лёгкие фреймы;
• рукопожатие: WebSocket начинается как HTTP-запрос с Upgrade: websocket и Sec-WebSocket-Key, сервер отвечает 101 Switching Protocols. Схемы ws:// и wss://, стандарт RFC 6455;
• формат: в HTTP у каждого ответа есть код. Сообщения WebSocket без статусов: текстовые и бинарные фреймы, служебные ping и pong, закрытие с кодом (1000 означает нормальное закрытие).

Инструменты: в DevTools вкладка Network, фильтр WS, вкладка Messages с сообщениями в обе стороны. Для ручных проверок Postman, консольные wscat или websocat, для нагрузки JMeter с плагином или k6.

Сценарии, специфичные для WebSocket:

• обрыв сети: переподключение, не теряются и не дублируются ли сообщения;
• простой: прокси вроде nginx по умолчанию рвёт соединение после 60 секунд тишины, если нет ping;
• авторизация: истечение токена посреди сессии;
• порядок и объём: очерёдность сообщений, слишком большие и невалидные сообщения.

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

Говорят, что HTTP закрывает соединение после каждого запроса. Так было в HTTP/1.0 без keep-alive, современный веб устроен иначе.

Считают WebSocket протоколом, не связанным с HTTP, и не знают про рукопожатие и код 101.

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