Daily MaverickLAW AND DISORDER: Slain Joburg attorney represented PA councillor linked to disputed gang claimsInquirerNegros Occidental to honor 2 national artists, top taxpayersThe Jerusalem PostBasketball: Micic puts up 31 points in Tel Aviv derby victoryZDF heuteEntdecken Sie das ZDF-NachrichtenstudioColliderThe 9 Most Atmospheric Fantasy Books of All TimeDeadlineMidterm Elections: What Stood Out In Media Coverage Of Democrats’ Rout Of Trump & RepublicansANSA SportChampions: Politano critica i compagni, 'la faccia ce la mettiamo sempre noi italiani'NU.nlWHO staat gebruik van twee nieuwe ebolavaccins toe in zwaar getroffen CongoBillboardWith God on Their Side: Bob Dylan & Pope Leo XIV Commune at the VaticanESPNMen's conference power rankings: Can the Big Ten win again?ynetהפוסט של ואנס צריך להדליק נורה אדומה בירושלים. וגם האנטי-ישראלים בסנאטFootball ItaliaFabregas: ‘A wonderful night for Como, but must stay humble’ after 9-1 victory
The Daily Newsstand · Free, Always
Wednesday, November 4, 2026

Slyber Inspector — Тестируем WebRTC приложения на лету

Translate

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

Во время работы над Slyber TURN Server я понял то что одного этого решения недостаточно чтобы закрыть боль разработчиков при тестирование WebRTC приложений я создал Slyber Inspector. Это инструмент с веб интерфейсом для тестирования WebRTC приложений прямо из браузера. Это экономит очень много времени и нервов так как для тестов не нужно создавать отдельные клиентские скрипты, а настраивать их тот еще квест. Ниже я подробно разберу методику тестирования WebRTC соединений в Slyber Inspector.

Slyber Inspector - веб интерфес для тестирование WebRTC приложений

Slyber Inspector - веб интерфес для тестирование WebRTC приложений

Проверить TURN или SFU сервер привычными утилитами вроде Postman не выйдет. Когда просто открываешь две вкладки приложения на своем ноутбуке, браузеры связываются напрямую по локальной сети. С этим обычно не возникает проблем, и разработчик думает, что все работает отлично. Но на практике около 20 процентов пользователей сидят за NAT или файрволами через которые невозможно пробиться напрямую, поэтому нам обязательно нужно тестировать внешний сервер посредник, через который мы будем гнать трафик. Если же через такой сервер нужно прогнать двадцать одновременных видеозвонков или сэмулировать переключение сети на ходу, приходится тратить время на написание отдельных клиентских скриптов.

Что именно нужно проверять в WebRTC приложениях

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

1. Доступность портов и передача трафика строго через сервер (relay). Обычно браузеры в одной сети связываются напрямую в обход сервера. При тестировании нужно принудительно отключить прямую связь и убедиться, что звонок идет именно через наш сервер по протоколам UDP, TCP или защищенному TLS.

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

3. Качество картинки и звука. Нужно своими глазами и ушами убедиться, что видео не зависает, звук не прерывается, а участники звонка видят и слышат именно друг друга без путаницы каналов.

4. Смена интернета без обрыва звонка. Когда человек во время разговора выходит из дома, его телефон переключается с домашнего Wi Fi на мобильный интернет 4G. Нужно проверить, что сервер на ходу выдает участникам новую пару портов и разговор продолжается без разрыва.

5. Мгновенное отключение участника. Если сервер работает в связке с базой Redis и мы удаляем из нее ключ конкретного пользователя прямо во время разговора, сервер должен сразу оборвать его сессию.

6. Работа под нагрузкой. Важно запустить сразу несколько десятков параллельных видеозвонков и посмотреть, какую скорость выдает сервер, не теряются ли пакеты по дороге и насколько быстро доходит сигнал от одного собеседника к другому на вашем тарифе хостинга.

Два уровня проверки от консоли до браузера

В экосистеме Slyber тестирование разделено на два этапа. Первый этап выполняется прямо в терминале сервера через утилиты doctor и bench, встроенные в сам бинарник Slyber TURN Server.

Команда slyber_turn doctor проверяет конфигурацию узла, защиту HTTP API, сверяет внешний IP адрес через публичные STUN серверы и делает пробную аллокацию порта. Команда slyber_turn bench поднимает пул потоков и гоняет между ними UDP пакеты по бинарному протоколу SLYB с метками времени в наносекундах, считая пропускную способность, потери и джиттер по RFC 3550.

Консольные утилиты быстро проверяют сетевое ядро ОС и настройки сокетов, но для проверки полного браузерного стека WebRTC с кодеками, шифрованием и сигналингом используется Slyber Inspector.

На главном экране Slyber Inspector доступно переключение между тремя модулями экосистемы.

  • Модуль Slyber TURN Server отвечает за проверку релейных кандидатов, тестирование пропускной способности видеопотоков, переключение маршрутов на лету и управление ключами в Redis.

  • Модуль Slyber SFU Server служит для тестирования маршрутизации видеоконференций, переключения слоев Simulcast и проверки каскадных комнат.

  • Модуль Slyber Signaling Server проверяет скорость обмена SDP сообщениями, задержки доставки событий и состояние комнат при конкурентной нагрузке.

Вся работа интерфейса происходит внутри одного сервера. Веб интерфейс обращается к внутреннему бэкенду инспектора для проверки конкретного сервера и подготовки ключей. При запуске тестовой пары встроенный сигнальный узел по WebSocket связывает два независимых объекта RTCPeerConnection прямо внутри одной открытой вкладки браузера. Оба пира захватывают разные видеоролики и звуковые дорожки из локального пула и гонят их друг другу строго через внешний сервер, а сборщик телеметрии каждую секунду выводит битрейт, объем переданных данных и задержку для каждого направления.

Установка Slyber Inspector в Docker

Для демонстрации развернем Slyber TURN Server и Slyber Inspector на самой простой виртуальной машине Ubuntu c одноядерным процессором.

Сначала скачиваем образ TURN сервера, генерируем случайный секретный ключ, запускаем контейнер с пулом портов от 50000 до 50100 и сразу вызываем проверку doctor.

Заморачиваться особо не требуется достаточно ввести команду ниже все установится автоматически.

docker pull ghcr.io/slyber-app/slyber-turn-server:latest
docker rm -f slyber_turn 2>/dev/null || true

GEN_SECRET=$(head -c 16 /dev/urandom | od -An -tx1 | tr -d ' \n') && \

docker run -d \
  --name slyber_turn \
  --restart unless-stopped \
  -p 3478:3478/udp \
  -p 3478:3478/tcp \
  -p 8080:8080/tcp \
  -p 50000-50100:50000-50100/udp \
  -e PUBLIC_IP="auto" \
  -e REALM="turn.local" \
  -e AUTH_MODE="secret" \
  -e TURN_SECRET="${GEN_SECRET}" \
  -e RELAY_MIN_PORT=50000 \
  -e RELAY_MAX_PORT=50100 \
  ghcr.io/slyber-app/slyber-turn-server:latest && \
  sleep 1 && \
  docker exec slyber_turn slyber_turn doctor && \
  HOST_IP=$([ -n "${SSH_CONNECTION:-}" ] && curl -fsSL4 --max-time 2 ifconfig.me 2>/dev/null || echo 127.0.0.1) && \
  echo "  TURN / STUN URI : turn:${HOST_IP}:3478 (UDP/TCP)" && \
  echo "  HTTP API URL    : http://${HOST_IP}:8080" && \
  echo "  Realm           : turn.local" && \
  echo "  Auth Mode       : secret (TURN_SECRET=${GEN_SECRET})" && \
  echo "  Test Creds API  : curl -s \"http://${HOST_IP}:8080/api/turn-credentials?user_id=dev\" && echo" && \
  echo "  Run Benchmark   : docker exec slyber_turn slyber_turn bench -clients 20 -duration 5s" && \
  echo "  Live Logs       : docker logs -f slyber_turn" && \
  echo "--------------------------------------------------"

После запуска в консоль выводится сводка с внешним IP адресом сервера, портом 3478 и сгенерированным ключом TURN_SECRET.

Второй командой поднимаем контейнер Slyber Inspector.

docker pull ghcr.io/slyber-app/slyber-inspector:latest
docker rm -f slyber_test 2>/dev/null || true

PORT=8095; while (ss -ltn 2>/dev/null || lsof -iTCP -sTCP:LISTEN -P -n 2>/dev/null) | grep -q ":${PORT}\b"; do PORT=$((PORT+1)); done; \

docker run -d \
  --name slyber_test \
  --restart unless-stopped \
  -p "${PORT}:8095" \
  -e LISTEN_ADDR="0.0.0.0:8095" \
  ghcr.io/slyber-app/slyber-inspector:latest && \
  HOST_IP=$([ -n "${SSH_CONNECTION:-}" ] && curl -fsSL4 --max-time 2 ifconfig.me 2>/dev/null || echo 127.0.0.1) && \
  echo "==> Open Slyber Inspector: http://${HOST_IP}:${PORT}"

Скрипт находит свободный порт начиная с 8095, запускает контейнер и выводит ссылку на веб интерфейс.

Настройка параметров тестирования в Slyber Inspector

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

Правый верхний угол интерфейса Slyber Inspector

Правый верхний угол интерфейса Slyber Inspector

  • Active pairs показывает количество карточек пар пиров, созданных в текущей сессии.

  • Relay sessions считает активные релейные соединения, прошедшие согласование кандидатов. Каждая пара дает две релейные сессии.

  • Total throughput выводит суммарный входящий битрейт всех активных звонков в килобитах или мегабитах в секунду.

  • Relayed traffic считает общий объем медиаданных в мегабайтах, прошедший через TURN сервер с момента запуска пар.

Все введенные настройки и загруженные видеоролики сохраняются в локальном хранилище браузера. Кнопка Reset saved state в шапке позволяет полностью сбросить настройки и очистить базу видео роликов.

В левой панели Turn server configuration настраивается подключение к тестируемому узлу.

Левая панель интерфейса в разделе Slyber Turn Server

Левая панель интерфейса в разделе Slyber Turn Server

  • Поле Turn server address принимает хост и порт целевого сервера (по умолчанию 127.0.0.1:3478). Сюда вписываем внешний IP нашей виртуалки.

  • Поле Realm domain задает домен авторизации на сервере (turn.local).

  • Список Transport protocol переключает транспорт между UDP, TCP, TLS и смешанным режимом.

  • В поле Ice transport policy по умолчанию выставлен режим relay only. Он принудительно отключает прямые P2P соединения и гарантирует, что весь трафик идет только через TURN сервер.

  • Поле Credential ttl задает время жизни временных ключей в секундах (по умолчанию 3600).

Переключатель Authentication mode меняет режим проверки учетных данных между secret и redis.

В режиме secret открывается панель со статическим ключом. В поле Shared secret key вставляется переменная TURN_SECRET из терминала. В списке Credential provisioning выбирается способ генерации временного пароля HMAC SHA1. Инспектор может вычислять его сам локально по общему ключу или запрашивать по HTTP у эндпоинта самого TURN сервера /api/turn-credentials, адрес которого указан в поле Turn http api url.

При выборе режима redis открывается форма подключения к базе Redis с полями адреса Redis address or url, имени пользователя Redis acl username, пароля Redis password и индекса базы Redis db index. При создании каждой новой пары в этом режиме Slyber Inspector автоматически генерирует уникальные логины вида p3_u1_da37e6 и p3_u2_da37e6, считает для них MD5 хеш по стандарту RFC 5389 и сам записывает ключи в базу Redis с указанным TTL.

Кнопка Verify server connection в правом верхнем углу панели отправляет тестовый пакет STUN Binding на указанный адрес, проверяет доступность хранилища ключей и выводит время отклика сервера в миллисекундах.

Генерация медиапотоков и запуск пар

Правая панель Media pool & pair generator отвечает за источники видео и запуск нагрузочных пар.

Через кнопку Upload video files можно загрузить свои видеоролики с диска, которые сохранятся во встроенную базу браузера IndexedDB. Если нужно провести тест быстро без локальных файлов, кнопка Add 4 demo streams сразу создает четыре синтетических потока с анимированной Canvas графикой и звуковыми генераторами тона от 220 до 520 Гц. Кнопка Clear pool очищает пул видеороликов.

В поле Pairs to spawn указывается количество пар для одновременного запуска от 1 до 50. По нажатию Spawn pairs для каждой пары алгоритм случайно выбирает два разных ролика из пула, чтобы пиры передавали друг другу разные потоки. Рядом расположены кнопки быстрого добавления еще одной пары +1 pair, отключения звука во всех плеерах Mute all и остановки всех активных звонков Terminate all.

Инспекция активных соединений и стресс тесты во время звонка

Каждая запущенная пара отображается внизу в виде отдельной карточки с двумя симметричными окнами участников Peer 1 слева и Peer 2 справа.

Внутри карточки собрана вся телеметрия конкретного звонка.

Симуляция общения двух юзеров

Симуляция общения двух юзеров

  • Цветной индикатор рядом с номером пары показывает состояние сессии. Желтый цвет горит при выделении портов или перезапуске сессии, зеленый при активной передаче видео и звука, красный при обрыве связи.

  • На зеленой плашке в правом верхнем углу каждого пира выводится реальный внешний IP адрес TURN сервера и выделенный этому участнику релейный UDP порт, например relay 89.111.175.67:50012 у первого пира и relay 89.111.175.67:50013 у второго.

  • Над плеерами в строке Sending to peer указано имя отправляемого файла, а в строке Receiving on screen from peer выводится имя принимаемого потока для визуальной сверки каналов.

  • Справа над плеером каждую секунду обновляются текущий битрейт потока в килобитах в секунду, объем полученных данных в мегабайтах и круговая задержка пакета RTT в миллисекундах.

Под плеерами каждого участника находятся кнопки для проверки поведения соединения на ходу.

  • Кнопка Unmute peer audio / Mute peer audio включает или отключает прослушивание входящей звуковой дорожки выбранного пира через Web Audio API.

  • Кнопка Ice restart запускает пересогласование кандидатов вызовом pc.createOffer({ iceRestart: true }) без обрыва звонка. Индикатор карточки на момент переключения становится желтым, сервер выделяет новую пару релейных UDP портов, номера на зеленых плашках обновляются, а видео продолжает идти по новому маршруту.

  • Кнопка Revoke redis key отображается при тестировании в режиме redis. Одним кликом она удаляет ключ конкретного участника из базы Redis, позволяя сразу проверить реакцию сервера и клиента на отзыв доступа.

  • Кнопка Remove pair закрывает оба WebRTC соединения, останавливает захват потоков, закрывает сигнальные сокеты и удаляет карточку пары.

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

Более детальная документация собрана тут: https://slyber.com/ru/docs/slyber-inspector

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

View the original on Хабр →

KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.