WebRTC и P2P звонки: почему голос не проходит через сервер

Как работает традиционная VoIP

В большинстве корпоративных мессенджеров — Zoom, Teams, Google Meet — звонки работают через медиасерверы провайдера. Схема выглядит так:

Алиса ──────► Медиасервер ──────► Боб
              (Zoom/Teams/etc)

  Ваш голос → сервер → голос Боба
  Голос Боба → сервер → к вам

Медиасервер принимает, обрабатывает и пересылает аудио/видео потоки. Это означает несколько вещей: провайдер технически имеет доступ к вашим звонкам, задержка выше (трафик делает дополнительный прыжок), а нагрузка на серверы провайдера растёт с каждым участником.

Для групповых звонков такая архитектура вынуждена — нельзя установить P2P-соединение между 50 участниками. Но для разговора двух человек это излишне.

Что такое WebRTC

WebRTC (Web Real-Time Communication) — открытый стандарт для прямой передачи аудио, видео и данных между браузерами без промежуточных серверов. Разработан Google, стандартизован W3C и IETF, поддерживается во всех современных браузерах.

Алиса ─────────────────────────► Боб
         (прямое соединение)

  Ваш голос → напрямую к Бобу
  Никаких серверов между вами

WebRTC включает несколько компонентов:

• RTCPeerConnection — управление P2P-соединением, кодеки, пропускная способность
• MediaStream — захват микрофона и камеры
• RTCDataChannel — передача произвольных данных по P2P

Важно: WebRTC шифрует все медиапотоки с помощью DTLS + SRTP — это обязательная часть стандарта. Незашифрованный WebRTC-звонок невозможен.

ICE, STUN и TURN: как устанавливается соединение

Главная проблема P2P — NAT (Network Address Translation). За большинством домашних и корпоративных роутеров устройства скрыты за общим IP-адресом. Напрямую подключиться к устройству за NAT невозможно без помощи.

Для решения этой проблемы WebRTC использует механизм ICE (Interactive Connectivity Establishment).

STUN-сервер

STUN (Session Traversal Utilities for NAT) — лёгкий сервер, который помогает устройству узнать свой внешний IP-адрес и тип NAT. Трафик звонка через STUN не проходит — он только помогает установить, как связаться.

Алиса → STUN: "какой у меня внешний IP?"
STUN → Алиса: "93.184.216.34:49152"

Боб → STUN: "какой у меня внешний IP?"
STUN → Боб: "198.51.100.42:52341"

Алиса ←→ Боб: прямое P2P соединение

TURN-сервер (запасной вариант)

Если NAT слишком строгий и прямое P2P установить не получается, используется TURN (Traversal Using Relays around NAT). TURN-сервер ретранслирует трафик, но при этом зашифрованный через DTLS — сервер не может его расшифровать.

Почему P2P безопаснее

При P2P-звонке через WebRTC:

• Нет доступа провайдера — голос и видео передаются напрямую, зашифрованными. Даже если сервер скомпрометирован, записей звонков там нет
• DTLS handshake — каждое соединение использует уникальный ключ, согласованный напрямую между участниками
• SRTP шифрование — медиа зашифровано стандартом Secure RTP на всём пути
• Нет централизованного хранилища записей — записать звонок без ведома участников технически сложнее

Сравните с традиционной VoIP: провайдер теоретически может записывать и анализировать все звонки через свои медиасерверы. Для корпоративных переговоров, где обсуждается коммерческая тайна, это серьёзный риск.

Нагрузка на сервер и качество связи

P2P даёт конкретные технические преимущества помимо безопасности.

Нагрузка на сервер

При классической архитектуре каждый звонок нагружает медиасервер: нужно принять, декодировать, перекодировать и отправить аудио/видео. При P2P сервер не участвует в передаче медиа — только помог установить соединение через STUN.

// Классическая VoIP: 100 одновременных звонков
server_bandwidth = 100 × 2 × (audio + video) ≈ 100+ Мбит/с

// WebRTC P2P: 100 одновременных звонков
server_bandwidth ≈ 0 (STUN трафик — несколько байт)

Задержка

Прямое соединение на 1–2 прыжка короче маршрута через медиасервер. Практически это означает меньшую задержку (latency) и лучшее качество голоса при одинаковом интернет-канале.

Как это реализовано в SecureChat

SecureChat использует WebRTC для всех личных звонков — голосовых и видео. Серверная часть участвует только в трёх случаях:

• Сигналинг — обмен SDP-описаниями для установки соединения (несколько килобайт)
• STUN — определение внешнего адреса (несколько пакетов)
• TURN relay — только если P2P невозможен из-за NAT (трафик зашифрован)

Для групповых звонков (3+ участника) используется архитектура SFU (Selective Forwarding Unit) — минимальный сервер маршрутизации, который не декодирует медиапотоки, а лишь перенаправляет зашифрованные пакеты нужным участникам.