Короткое определение

Session Traversal Utilities for NAT (RFC 8489, февраль 2020). Небольшой протокол, с помощью которого клиент определяет свой публичный IP-адрес и порт за NAT – первый шаг при установлении соединения WebRTC.

STUN – это сервис обнаружения, с помощью которого WebRTC определяет, как клиент виден в глобальной сети. Клиент отправляет небольшой UDP-пакет на STUN-сервер (по умолчанию используется публичный – `stun.l.google.com:19302`), а сервер возвращает IP-адрес и порт, с которых пришёл запрос. Это позволяет клиенту узнать, как NAT изменил исходный адрес, и использовать этот адрес как ICE-кандидата при обмене данными с пиринговым узлом.

STUN не передаёт медиа – он лишь обнаруживает адреса. Протокол лёгкий, stateless и работает по UDP/3478 или UDP/5349 для STUN over TLS. Любое WebRTC-приложение требует хотя бы одного STUN-сервера, доступного обоим пиринговым узлам; стандартная практика – настроить два-три таких сервера в `iceServers`. Публичные STUN-серверы (Google, Cloudflare, Twilio) бесплатны и обрабатывают миллиарды запросов в сутки.

STUN работает с cone-NAT, но не справляется с symmetric-NAT: симметричный NAT назначает разный внешний порт для каждого адреса назначения, и публичный IP, полученный от STUN, действителен только для самого STUN-сервера. Если отправить пакет другому участнику через тот же сокет, маппинг будет уже другим. В этом случае включается TURN – медиарелей, до которого обе стороны могут подключиться обычным клиентским соединением.

Считаете параметры для своего продукта?

Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.