Real-Time Backend
STUN и TURN
Zoom, Google Meet и Jitsi работают прямо в браузере без установки плагинов. Как два браузера за разными NAT в разных странах находят друг друга и передают видео без центрального медиасервера?
- **Twilio Video** использует глобальную сеть TURN серверов в 6 регионах - это позволяет 99.9% пользователей установить соединение даже за корпоративными firewall. Стоимость TURN relay включена в $0.004/мин на участника.
- **Jitsi Meet** (open-source, 10M+ активных пользователей) деплоит coturn на тех же серверах, что и SFU. В конфиг-файле 3 строки для STUN, 5 для TURN - и продакшен-сеть готова.
- **Agora.io** держит 200+ Point of Presence по всему миру именно для STUN/TURN discovery с минимальным RTT - это напрямую влияет на время установки соединения (connection time < 500ms в 95% случаев).
- **Discord** использует WebRTC для голоса и видео. При переходе на режим «Go Live» (screen share) задействует TURN для пользователей за Symmetric NAT - ~12% всех пользователей по их внутренней статистике.
NAT Traversal
99% устройств в мире прячутся за NAT - маршрутизатором, который переводит приватные IP (192.168.x.x) в один публичный. Когда два браузера хотят создать прямое P2P соединение, они не знают публичных адресов друг друга и не могут просто «позвонить» напрямую. Это называется проблемой NAT traversal.
WebRTC решает её через ICE (Interactive Connectivity Establishment) - фреймворк, который собирает все возможные пути соединения (candidates): локальные IP, публичные IP через STUN, relay через TURN. Затем оба пира обмениваются кандидатами и перебирают их в порядке приоритета.
По данным Google (2013), ~86% WebRTC соединений устанавливаются через STUN (P2P), ~8% требуют TURN relay. Symmetric NAT - основная причина, почему TURN вообще нужен.
Два пользователя за Symmetric NAT пытаются установить WebRTC соединение. STUN-сервер доступен. Что произойдёт?
STUN
STUN (Session Traversal Utilities for NAT) - протокол обнаружения публичного IP. Браузер отправляет запрос на STUN-сервер, тот отражает публичный IP:Port, с которого пришёл запрос. Браузер узнаёт свой внешний адрес и добавляет его как ICE candidate.
STUN-сервер - статeless, дешёвый в обслуживании. Google, Cloudflare, Twilio дают публичные STUN бесплатно. Трафик через STUN = 0 байт медиа (только discovery). Агора использует 11 STUN серверов в разных регионах для минимального RTT при discovery.
Какую информацию возвращает STUN-сервер клиенту в ответ на Binding Request?
TURN
TURN (Traversal Using Relays around NAT) - протокол relay. Когда P2P невозможен (Symmetric NAT, жёсткий firewall), медиатрафик идёт через TURN-сервер. Клиент аутентифицируется, получает allocation (выделенный UDP порт на сервере), и сервер пересылает пакеты между пирами.
TURN сервер пропускает ВЕСЬ медиатрафик - нагрузка пропорциональна числу участников и битрейту. Twilio Video тратит на TURN relay ~$0.0015 за минуту видеосессии. Agora держит TURN-серверы в 200+ PoP для минимальной задержки relay.
Почему TURN credentials нельзя публиковать в коде фронтенда?
coturn
coturn - самый популярный open-source сервер для STUN и TURN (RFC 5766, RFC 8489). Написан на C, работает на Linux/Mac, держит тысячи concurrent allocations на одном инстансе. Используется как в самостоятельных продакшен-деплоях, так и как backend в Twilio, Xirsys и других WebRTC cloud-провайдерах.
Production-деплой coturn: минимум 2 инстанса за load balancer для HA. Xirsys (WebRTC infrastructure SaaS) строит свою сеть из 5000+ coturn серверов. Для небольших проектов достаточно одного VPS 2CPU/4GB - выдерживает ~500 concurrent видеосессий relay.
TURN заменяет STUN - достаточно настроить только TURN сервер
STUN и TURN решают разные задачи. ICE всегда сначала пробует P2P (через STUN), и только при неудаче падает на TURN relay
TURN намного дороже STUN в обслуживании (пропускает весь трафик). ICE приоритизирует прямые соединения. Если настроить только TURN без STUN, P2P всё равно попытается - TURN candidates имеют низший приоритет в ICE.
Jitsi Meet по умолчанию использует P2P для звонков с 2 участниками и SFU (Jicofo) для групп. Когда всё равно нужен TURN?
Итоги
- **ICE** перебирает кандидатов в порядке приоритета: host → srflx (STUN) → relay (TURN). P2P всегда предпочтительнее relay.
- **STUN** - дешёвый stateless сервис обнаружения публичного IP. Google, Cloudflare дают бесплатно. Не помогает при Symmetric NAT.
- **TURN** - дорогой relay, пропускает весь медиатрафик. Требует аутентификации с временными HMAC credentials. coturn - стандарт де-факто для self-hosted.
- **Symmetric NAT** - главная причина, почему TURN вообще нужен. ~8-14% реальных пользователей попадают в эту категорию.
Связанные темы
STUN/TURN - инфраструктурный слой WebRTC. Выше него работают медиа-протоколы и топологии:
- WebRTC ICE и Signaling — ICE использует STUN/TURN кандидатов для установки соединения; signaling сервер обменивает SDP и кандидатов между пирами
- SFU архитектура — SFU сам является медиасервером, но ICE соединения клиент-SFU также могут требовать TURN
- MCU vs SFU vs Mesh — Выбор топологии влияет на нагрузку TURN: Mesh = N*(N-1)/2 потенциальных TURN соединений, SFU = N
Вопросы для размышления
- В каком сценарии имеет смысл поднять собственный coturn вместо использования Twilio/Xirsys TURN API?
- Как временные HMAC credentials защищают TURN сервер от злоупотреблений при том, что генерируются на frontend?
- Если 86% соединений P2P, а 8% через TURN - как рассчитать необходимую пропускную способность TURN для 10 000 concurrent пользователей видеоконференции?