Термин
STUN
Session Traversal Utilities for NAT (RFC 8489, февраль 2020). Маленький протокол, через который клиент узнаёт свой публичный IP и порт за NAT – первый шаг установления WebRTC-соединения.
STUN – это lookup-сервис, через который WebRTC выясняет, как клиента видит большой интернет. Клиент шлёт маленький UDP-пакет STUN-серверу (публичный дефолт – `stun.l.google.com:19302`), сервер отвечает IP и портом, с которых увидел запрос. Это сообщает клиенту, во что NAT переписал источник, и клиент рекламирует этот адрес peer-у как ICE-кандидата.
STUN не передаёт медиа – он только обнаруживает адреса. Он дешёв, stateless и идёт по UDP/3478 или UDP/5349 для STUN over TLS. Любое WebRTC-приложение нуждается минимум в одном STUN-сервере, доступном обоим peer-ам; стандартная практика – настроить два-три в `iceServers`. Публичные STUN-серверы (Google, Cloudflare, Twilio) бесплатны и держат миллиарды запросов в сутки.
STUN работает с cone-NAT-ами, но проваливается на symmetric: симметричный NAT назначает разный внешний порт каждому назначению, и публичный IP, который STUN сообщил, валиден только для STUN-сервера. Если отправить пакет peer-у из того же сокета, маппинг будет другим. В этот момент включается TURN – медиа-релей, до которого обе стороны достают обычным клиент-инициированным соединением.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.