/ws/echo — эхо, базовый замер RTT
Сервер возвращает сообщение один-в-один. Клиент вкладывает свою метку времени и считает round-trip сам — это самая простая проверка «сколько держит канал».
/ws/chat — комнаты и broadcast
Сообщение в комнату рассылается всем её участникам. Это самый показательный сценарий: нагрузка на сервер растёт как N × M (отправители × получатели), а в отчёте видно и время ack, и e2e-задержку доставки.
/ws/ticker — серверный поток (push)
Клиент только подписывается, дальше сервер сам шлёт котировки с заданным интервалом. Проверяет способность инструмента держать десятки тысяч «молчащих» подписчиков и считать входящий трафик.
/ws/rpc — запрос/ответ с корреляцией и авторизацией
Токен берётся HTTP-запросом POST /api/login, затем передаётся в WebSocket через auth.login. Это ключевой демо-кейс: корреляция между протоколами — сценарий, который умеет не каждый инструмент.
HTTP-сценарий: login → каталог → заказ
Классический веб-сценарий с динамическими данными: токен и productId из ответов надо корреляционно подставлять в следующие запросы.
| Шаг | Метод | Эндпоинт | Что корреляционно тянем |
|---|---|---|---|
| 1 | POST | /api/login | token, sessionId |
| 2 | GET | /api/products?page=1 | items[].id |
| 3 | GET | /api/products/:id | price |
| 4 | POST | /api/orders | orderId (Bearer из шага 1) |
| 5 | GET | /api/orders/:orderId | проверка status |
Передача файлов: POST /api/upload → GET /api/files/:fileId
Принимает multipart/form-data (поле file плюс обычные текстовые поля) и сырое тело запроса. В ответе — динамический fileId, который нужно корреляционно подставить в скачивание. Ответ содержит sha256, поэтому целостность проверяется ассертом.