Привет! Продолжаем цикл статей про тестирование не-REST-бэкенда, в прошлый раз мы говорили о GraphQL, теперь пришло время WebSocket.

Итак, что такое WebSocket?

Википедия сообщает, что это «протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, использующий постоянное соединение».

Что тут важно — что это протокол (со всеми вытекающими последствиями для протокола), который использует постоянное соединение.

Работу по WebSocket в обычной жизни можно представить примерно так.

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

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

ОК, что вам делать в такой ситуации? Как минимум, открыть свою крутую звуконепроницаемую дверь, чтобы услышать звонок курьера в дверь квартиры, и продолжать работать. Когда он придет и позвонит, вы услышите и среагируете.

Собственно, вот так работает WebSocket.

А если бы мы взаимодействовали через REST-HTTP, всё выглядело бы немного иначе.

Вы бы подходили к закрытой звуконепроницаемой двери, открывали ее, убеждались, что курьер не обрывает дверной звонок, возвращались обратно поработать 20 секунд, снова вставали и подходили к двери, слушали, как там дела с курьером, и снова уходили работать на еще одни 20 секунд. И так бегали бы туда-сюда, пока бы не пришел курьер или пока не протоптали бы ламинат.

У меня, кстати, был случай — мне надо было через мобильное приложение срочно обратиться в медицинское учреждение по страховке. Я открыл приложеньку, вошел в чат с оператором, оператор попросил уточнить подробности. Сижу, пишу подробности — и у меня моргает чат, вижу вместо своего сообщения пустое поле. Думаю — ну ладно, бывает, пишу снова. Опять через полминуты то же самое. И в третий раз тоже.

Я в этот момент начинаю выглядеть как-то так.

Но потом вспоминаю, что я в первую очередь инженер, и мне интересно понять «А почему так?». Сижу и думаю — неужели они реально используют HTTP? Подключаю мобилку к компу, смотрю трафик — и правда, оказывается, мобильный клиент раз в 25 секунд шлет HTTP-запрос на сервер и уточняет, есть ли в чате новый ответ от оператора. Если нет, то он зачем-то перерисовывает фронт. Заодно дропая все введенные мною данные. Видимо, ребята не тестировали это. И зря.

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

Как устанавливается это соединение

Процесс работы по Websocket выглядит так. Сперва посылается обычный HTTP-запрос на установку постоянного соединения— это вот когда к вам в дверь постучала жена. Но у запроса должно быть два очень важных технических заголовка.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade

Первый – это connection upgrade. Тут мы говорим серверу, что готовы перенести наши отношения на новый уровень, более постоянный и вообще хороший. Второй — мы указываем, что мы хотим сделать апгрейд на WebSocket.

Если сервер может, он отвечает — хорошо, это будет код ответа 101, и служебные заголовки смены протокола. 

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMl YUkAGmm50PpG2HaGWk=
Sec-WebSocket-Protocol: chat'

Укажет, на какой протокол поменялся, какой сокет будет использоваться и прочую информацию. Это аналог того, что вы открыли дверь и начинаете слушать звонок курьера, продолжая при этом делать свои дела.

После этого между клиентом и сервером устанавливается тип соединения connection, они начинают общаться.

HTTP Connect is upgrading to WS
TYPE: Connection

Если вдруг кто-то там отвалился или закрыл соединение, тип коннекта меняется на дисконнект.

WS connection close
TYPE: Disconnect

И здесь сразу возникает вопрос — а как сервер поймет, что клиент все еще там?

Представьте себе пневмопочту.

Откуда вы знаете, что по ту сторону прямо сейчас еще сидит человек, который сразу принимает ваши посылки? А вдруг он ушел уже, и вы впустую все это шлете.

Вот на этот случай у WebSocket-протокола есть специальный механизм пинг-понгов — он всегда может уточнить, “слышно” ли его и стоит ли продолжать работу. Если вдруг кто-то не ответил, происходит несколько попыток (с увеличивающимся таймаутом), и после этого соединение считается закрытым. У WebSocket для этого есть свои коды ответов, которые все так или иначе завязаны именно на закрытие соединения.

Как с ним работать в Postman

На одном из своих прошлых проектов я как раз тестировал поиск на WebSocket, так что на этом примере и разберемся.

Запустим Google Chrome, откроем консоль разработчика (F12), перейдем на сайт https://www.onetwotrip.com/ru/bus/ и поищем билеты Москва-Тверь на дату в будущем. Дожидаемся окончания загрузки и переходим во вкладку Network

Увидим следующую картину. Как видите, везде коды 200, то есть обычные HTTP-запросы.

Где ловить WebSocket запрос? Он находится на вкладке WS, WebSocket

Тут видно, что протокол SSL-ный, защищенный и есть вся информация.

Есть и вкладка payload — показывает, что мы отправили какие-то данные.

Есть вкладка Messages, где мы видим все сообщения, которыми обменивались клиент и сервер.

Здесь мы сначала сделали connection, потом мы отослали на сервер ОК, и он вернул нам данные в четыре захода

Как это все делать и протестировать в Postman?

Нажимаете в Postman кнопку New, видите WebSocket.

Выбираете его, и у вас появляется такой экран. Тут есть уже месседжи, параметры, хедеры и прочее.

Давайте потестируем.

В адрес вводим wss://www.onetwotrip.com/_bus/ws/run/search?startGeoId=16&endGeoId=100&date=2023-08-10&adults=1&children=0

Если дата в параметре date устарела, меняем на будущую. Postman сам проставит параметры и заголовки, но в Headers все же надо самим добавить еще и Origin — https://www.onetwotrip.com

Нажимаем, как всегда, кнопочку connect, и видим, что все остановилось. Почему?

Смотрим вниз окна и форму Responses, где нас уже ждет ответ.

Раскрываем его

Видим, что сперва был послан сначала обычный HTTPS-запрос на установку Websocket-соединения со всеми служебными заголовками: connection upgrade, WebSocket, все как надо.

Сервер прислал мне в ответ 101, мол, я согласен, давай проапгрейдим наши отношения на WebSocket. Он выдал мне сокет и все остальное, включая куки.

При этом статус нашего соединения connected.

Теперь с ним можно работать, сервер ждет от нас сообщение

Пошлем ему ОК. Для этого во вкладке Messages напишем “ОК” и нажмем кнопку Send.

В ответ увидим несколько ответов от сервера, в рамках которых он отгружал нам данные, и в конце, когда данные закончились, он закрыл соединение. 

Это сигнал для клиента к отключению соединения. Если раскрыть это сообщение, увидим, что мы завершились с кодом 1000 — это нормальное завершение.

Собственно, в этом и заключается вся магия вебсокета. Во-первых, нам нужно установить вебсокет-соединение: посылаем обычный http-запрос (Postman это, кстати, делает автоматически). Далее посылаем данные в том формате, который ждет сервер, и получаем от него информацию в ответ. В конце еще получим какие-то определенные коды, связанные с закрытием коннекта.

Что можно тестировать?

Прежде всего — сам факт установки соединения. Потому что, может быть, сервер откажется соединяться, или он отключен, или умеет только в http.

Обязательно не забудьте проверить security, SSL никто не отменял и установку по WSS тоже нужно проверить.

Далее, как в классическом тестировании backend api, — проверяем формат ответа и сами данные, которые внутри.

Как написано выше, у вебсокета есть свои коды ответов. Тестировать или нет их — зависит от обстоятельств. Если вам это действительно нужно, ведь у вас есть такой функционал завязанный на это, — то вперед! В своей практике я с тестированием кодов ответа почти не сталкивался.

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

С вебсокетом на этом всё. Для тех кто еще с нами — в третьей части поговорим про самое сложное из цикла. Про gRPC.