WebRTC — одна из самых мощных новых веб-технологий, появившихся за последние 6 лет. Обещание простое, одноранговые видео/аудио/данные. Может ли это быть правдой, что больше не нужно платить за серверы и поддерживать их? Не совсем. Как только соединение установлено, WebRTC открывает волшебное будущее, в котором наши пользователи могут напрямую передавать данные между своими устройствами, не нагружая наши серверы.

Однако для установления соединения нам все равно понадобятся серверы. Первая часть установления соединения WebRTC называется сигнализацией. Сигнализация может обрабатываться любым способом, который пожелает разработчик, но в нашей реализации для империо мы уже планировали использовать веб-сокеты в качестве запасного механизма для браузеров, не поддерживающих WebRTC (к сожалению, Safari и, следовательно, iDevices пока не поддерживает поддерживают WebRTC, поэтому мы не можем полагаться только на него) и поэтому мы обрабатываем сигнализацию через WebSockets. Мы создаем уникальную комнату для нашего соединения, и как только второй пользователь присоединился к сокетному соединению, мы знаем, что у нас есть средство передачи данных соединения между устройствами.

После того, как вы установили механизм сигнализации, пришло время создать RTCPeerConnection. Даже если вам удалось избежать использования серверов в реализации сигнализации, теперь вы должны полагаться на них. Конструктор RTCPeerConnection принимает объект конфигурации, который указывает ему, какие серверы STUN и TURN использовать при попытке согласования P2P-соединения.

пример:

const configuration = {
iceServers: [{ url: ‘stun:stun.l.google.com:19302’ }],
};

Примечание: это общедоступный сервер от Google для тестирования и не подходит для производства.

STUN означает прохождение сеанса протокола пользовательских дейтаграмм [UDP] через трансляторы сетевых адресов [NAT] и позволяет устанавливать соединения, когда пользователи находятся за разными брандмауэрами. Поскольку устройства часто будут подключаться из разных локальных сетей, сервер STUN взаимодействует с NAT по общедоступному IP-адресу устройства и определяет, через какой порт каждое устройство доступно в локальной сети. Серверы TURN, расшифровывающиеся как Traversal Using Relays around NAT, обеспечивают резервный механизм для передачи данных, когда соединение P2P невозможно. Поскольку серверы TURN могут иметь более значительный трафик, они не являются общедоступными, но многие провайдеры предлагают очень недорогие серверы TURN и включают бесплатные серверы STUN.

Как только этот список возможных вариантов подключения создается на сервере STUN, этот список отправляется на потенциальные подключающиеся устройства, и они будут пытаться подключиться к каждому кандидату до тех пор, пока либо не будет установлено успешное P2P-соединение, либо они не вернутся к серверу TURN. Предполагая, что одноранговое соединение установлено, вы можете инициировать медиапоток с аудио/видео или каналом данных.

Поздравляем, теперь вы повышаете удобство работы с вашими пользователями с дополнительным преимуществом использования меньшего количества серверных ресурсов.