Как работает WebRTC и зачем нужны STUN и TURN?

WebRTC передаёт аудио, видео и данные напрямую между браузерами, обычно поверх UDP; STUN помогает узнать свой публичный адрес за NAT, а TURN ретранслирует трафик, когда прямой путь невозможен.

Установка соединения

1. Сигнализация не входит в WebRTC: стороны обмениваются SDP offer и answer через ваш сервер, чаще всего по WebSocket.
2. ICE собирает кандидатов: host — локальный адрес, srflx — публичный адрес от STUN, relay — адрес на TURN.
3. Пары кандидатов проверяются, выбирается лучшая рабочая.
4. DTLS-рукопожатие, затем медиа по SRTP и данные по SCTP в DataChannel. Шифрование обязательно.

STUN и TURN

• STUN отвечает на вопрос «с какого IP:порта ты ко мне пришёл» — этого хватает для большинства домашних NAT (UDP hole punching).
• Симметричный NAT, выдающий новый внешний порт на каждое назначение, и строгие корпоративные файрволы ломают hole punching — нужен TURN.
• TURN гонит весь трафик через себя и дорог по полосе, поэтому доступ к нему дают по временным учётным данным.

const ws = new WebSocket("wss://signal.example.com");
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" },
    { urls: "turn:turn.example.com:3478", username: "user", credential: "secret" },
  ],
});
pc.onicecandidate = (e) => { if (e.candidate) ws.send(JSON.stringify(e.candidate)); };

Коротко для собеседования

WebRTC пытается соединить браузеры напрямую, а сигнализацию и серверы STUN/TURN вы поднимаете сами. TURN нужен, когда NAT или файрвол не пропускают прямой путь, и он дорог по трафику; для групповых звонков вместо mesh используют SFU.