WebRTC расшифровывается как Web Real-Time Communication - сетевая технология, представленная Google в 2011 году для обеспечения передачи аудио, видео и данных в режиме реального времени через Интернет и собственные браузеры.
WebRTC позволяет веб-приложениям создавать одноранговую связь.
Почему разработчики и компании любят Web RTC?
- Бесплатный открытый исходный код
Он обеспечивает браузерам прямую связь между разработчиками и позволяет разработчикам легко упростить это соединение.
- Повышение скорости
Больше не нужно маршрутизировать через сервер, это уменьшает задержку и потребление полосы пропускания.
Прямое общение повышает скорость передачи данных и обмена файлами.
Не нужно стороннее приложение
Не требует дополнительного программного обеспечения, плагинов или постоянного участия сервера (это так, но только в начале)
Легко встраиваться в любые веб-сайты и подключаться к коллегам через Интернет.
- Легко реализовать
Меньше времени и усилий, чтобы реализовать одноранговое (P2P) соединение.
Все функциональные возможности могут быть выполнены через клиентскую часть. Разработчикам просто необходимо скачать WebRTC-совместимый браузер и использовать
- Совместимость
Поддерживаются популярные браузеры: Microsoft Edge, Google Chrome, Mozilla Firefox, Safari, Opera.
Поддерживаются Android, Chrome OS, Firefox OS, BlackBerry 10, iOS, Tizen.
- Обеспечивает безопасное соединение во многих браузерах
Шифрование является обязательным для всех компонентов WebRTC.
Поскольку это не плагин, он работает внутри песочницы браузера, не создавая новый процесс, так что никакие вредоносные программы не могут проникнуть в систему пользователя.
Не нужно следить за обновлениями. Благодаря автоматическому обновлению версии браузера пользователь получает исправление сразу после его появления.
Что происходит во время соединения P2P
Для подключения двух браузеров Web RTC необходимо выполнить пять шагов для настройки P2P-соединения.
1. Обработка сигнала для удаления окружающего шума из аудио или видео.
2. Обработка кодека для сжатия и распаковки аудио или видео.
3. Маршрутизация от одного узла к другому через брандмауэры (NAT) и ретрансляторы для создания интерактивного соединения (ICE)
4. Пользовательские данные шифруются перед передачей через соединения.
5. Управление полосой пропускания для пользователя, что каждый пир должен дать
Передача сигналов
P2P-соединения в браузере устанавливаются сервером для обеспечения согласия всех пиров на сеанс.
Такая информация, как сеансовые ключи, сообщения об ошибках, метаданные мультимедиа, кодеки, пропускная способность и общедоступный IP-адрес и порты, совместно используется одноранговыми узлами для создания соединения.
Сервер сообщает обоим одноранговым узлам, какой формат мультимедиа использовать и что каждый одноранговый узел хочет отправить другому.
Трансляция сетевых адресов (NAT) и ICE
NAT преобразовывает частный IP-адрес, найденный на устройствах, таких как домашний маршрутизатор, в общедоступный IP-адрес. Брандмауэры и NAT замедляют процесс, блокируя определенные протоколы или порты. Решение, которое использует WebRTC, представляет собой фреймворк под названием ICE.
ICE устанавливает P2P-соединение через Интернет, пробуя все соединения параллельно и выбирая наиболее эффективный путь. Существует два типа соединений: STUN & TURN
STUN серверы
Сначала он работает при подключении через сервер STUN (Session Traversal Utilities for NAT), чтобы получить прямую связь через сетевой адрес.
Сервер STUN предоставляет запрашивающему публичный IP-адрес для связи с другими. Его цель - помочь запрашивающей стороне ответить на вопрос: «Какой у меня IP-адрес?»
Как работают серверы STUN
Чтобы установить соединение с другими одноранговыми узлами, конечная точка должна знать свой публичный IP-адрес, чтобы делиться с другими.
Когда конечная точка (Calvin) находится за NAT / Firewall, она может идентифицировать только свой локальный IP-адрес, а другая (Elana) не может подключиться к локальному IP из-за безопасности межсетевого экрана.
Эта конечная точка будет запрашивать помощь у сервера STUN для предоставления своего общедоступного IP-адреса и типа NAT.
Другая конечная точка (Elana) может попытаться установить соединение между ними, используя заданный общедоступный IP-адрес с сервера STUN.
В случае успеха мультимедиа будет передаваться непосредственно на каждую конечную точку без стороннего или другого сервера.
В целях безопасности все серверы STUN будут отброшены и ждут следующего запроса.
Ограничения - Симметричный NAT
Тем не менее, описанная выше ситуация может иногда давать сбой , и номер порта и IP будут изменены.
Эта ситуация называется «симметричным NAT», так как общедоступный IP-адрес сервера STUN не имеет достаточных возможностей для установления здесь соединения, так как порт также нуждается в преобразовании.
Некоторые маршрутизаторы используют Symmetric NAT, который предназначен для добавления другого уровня безопасности к конечной точке или предотвращения подключения посторонних лиц к вашему устройству. Симметричный NAT не только переводит IP-адрес с частного на общедоступный, но и транслирует порты.
Другими словами, маршрутизатор будет принимать подключения только от известных партнеров, к которым ранее подключался пользователь. Следовательно, другое решение сделано, чтобы гарантировать, что соединение между двумя узлами успешно через сервер TURN.
Почему серверы STUN полезны
Как протокол, STUN супер быстрый, легкий и простой. Это позволяет СМИ перемещаться непосредственно друг к другу за короткое время. STUN позволяет ускорить соединение и быстрее получить результат в режиме реального времени.
Сценарий аналогичен, когда пользователь использует локальную сеть для загрузки данных, что быстрее, чем загрузка из Wi-Fi. Что наиболее важно, это позволяет СМИ перемещаться непосредственно между обеими конечными точками. STUN можно использовать публично и бесплатно.
TURN Серверы
Сервер TURN (обход через NAT) действует как сервер ретрансляции, если одноранговое соединение обрывается. В то время как серверы STUN используются для установления соединения, серверы TURN остаются активными в течение всей ассоциации.
Сервер TURN продолжает ретрансляцию мультимедиа между узлами WebRTC. Вот почему термин «реле» используется для определения поворота.
Как работают серверы TURN
Этот сервер ретрансляции используется для ретрансляции трафика в случае сбоя сервера STUN, а также имеет функции STUN.
Сервер TURN является сервером STUN со встроенной возможностью передачи. Более конкретно, TURN используется для передачи потоковой передачи аудио / видео / данных между узлами, а не для передачи данных.
Следуйте инструкциям для серверов STUN
Если произойдет сбой STUN, конечный пользователь создаст соединение с сервером TURN, проинформирует всех партнеров об отправке данных на сервер, который отвечает за передачу данных первому конечному пользователю.
Одна из главных причин, по которой сервер STUN всегда используется первым, заключается в том, что сервер TURN слишком дорогой и использует большую полосу пропускания, если HD-видео транслируется онлайн.
VP9 Видеокодек
Одна из главных особенностей, почему многие люди начинают использовать WebRTC, это для потокового видео. Поскольку живое видео становится все более распространенным и начинает приобретать более высокое качество, требуется более быстрая передача данных или меньший размер пакета для более легкой передачи.
Именно тогда имеет место кодек VP9 для сжатия и распаковки аудио или видео. Это помогает потоковое видео быстрее и нагляднее. Поддерживая VP8, Safari 12.1 может обмениваться видео в реальном времени с другими.
VP9, который является улучшением по сравнению с VP8, представляет собой формат сжатия видео, принадлежащий Google и созданный On2 Technologies.
Основная функция заключается в том, чтобы скрыть потерю пакетов и очистить зашумленные изображения, а также возможности захвата и воспроизведения на нескольких платформах.
С VP9 пользователи могут использовать WebRTC для потоковой передачи видео 720p без потери пакетов или задержки. Он также может поддерживать видеовызов 1080p при той же полосе пропускания и помогает сократить количество плохих соединений и использование данных, чтобы избежать дорогостоящих затрат для пользователей.
API JavaScript
Существует три основных API Javascript, которые обрабатывают захват аудио, видеоконференции и передачу данных:
Использует камеру пользователя и микрофон для захвата и потокового аудио и видео. Использование этого API позволяет получить доступ к таким устройствам ввода, как микрофон и веб-камера.
Когда разработчик интегрирует WebRTC в свой веб-сайт, он может создать ограничения на то, как они хотят передавать аудио и видео. Ограничения, такие как частота кадров, размер видеокадра, разрешение и многое другое.
Этот API был предоставлен как часть HTML 5, тогда как два других API явно предлагаются для WebRTC.
Отправляйте захваченный поток аудио и видео в режиме реального времени через Интернет на другую конечную точку WebRTC. Использование этих API позволяет пользователям передавать аудио и видео, захваченные getUserMedia другим.
Имеет функции для подключения к удаленному узлу, поддержания и мониторинга соединения, а также закрытия соединения после завершения.
Передать произвольные данные. Каждый канал данных связан с RTCPeerConnection.
Встроенная защита (DTLS) и контроль перегрузок.
Безопасность
Один из рисков безопасности в любом приложении связи в реальном времени может возникнуть во время передачи данных. В конце концов, шифрование является обязательной функцией WebRTC и применяется ко всем компонентам.
WebRTC использует два стандартизированных протокола шифрования:
Стандартизированный протокол, встроенный в браузер. Он используется для шифрования потоков данных. Он основан на протоколе транспортного уровня (TLP).
Сохраняет семантику транспорта, поскольку DTLS использует протокол пользовательских данных (UDP).
Это расширение Secure Sockets Layer (SSL); любой протокол SSL может быть использован для защиты данных WebRTC, позволяющих осуществлять сквозное шифрование.
Используется для шифрования медиапотоков.
Это расширение транспортного протокола реального времени (RTP), который не имеет встроенных механизмов безопасности. Добавляет защиту, целостность и аутентификацию сообщений в RTP.
Недостаток: хотя он обеспечивает шифрование пакетов RTP, он не шифрует заголовок.
0 комментариев
Добавить комментарий