Что такое p2p соединение

Что такое p2p соединение

Работа с отдельными камерами и целыми системами видеонаблюдения через интернет приобрела широкую популярность благодаря ряду аналитических функций и оперативному доступу к устройствам.

Как правило, большинство технологий, которые для этого используются, требуют присвоения камере или видеорегистратору дорогостоящего белого IP адреса, сложной процедуры настройки с использованием сервисов UPnPct и DDNS. Альтернативой этому является применение технологии Р2Р.

Р2Р (peer-to-peer) – пиринговый протокол связи, отличается более эффективным использованием полосы пропускания канала передачи сигнала и высокими показателями отказоустойчивости.

Впервые термин peer-to-peer (Advanced Peer to Peer Networking) – расширенные одноранговые сети, был использован корпорацией IBM в сетях с классической одноуровневой архитектурой и равноправными рабочими станциями. Он применялся в процессе динамической маршрутизации без использования сервера, когда каждый ПК выполнял функцию и клиента, и сервера. Сейчас более свободная версия перевода аббревиатуры звучит как «равный к равному».

Основная область применения – это удаленное видеонаблюдение за различными объектами, например:

  • открытая складская или строительная площадка;
  • магазин или производственное помещение;
  • приусадебный участок или дача.

Камеры видеонаблюдения с Р2Р технологией передачи изображения используются преимущественно в бытовых небольших и средних частных системах видеонаблюдения, выполняя некоторые функции систем безопасности и тревожной сигнализации.

ПРЕИМУЩЕСТВА Р2Р ВИДЕОНАБЛЮДЕНИЯ

Простота настроек сетевого оборудования — основное преимущество Р2Р технологии перед другими способами передачи сигнала. Фактически, не имея глубоких познаний в сетевых протоколах, процедурах подключения и наладки, любой пользователь с начальными навыками работы в сети интернет может самостоятельно организовать удаленное видеонаблюдение.

Нет привязки к статическому IP адресу. Получение и содержание статического IP адреса может оказаться проблемой для рядового пользователя. Большинство провайдеров предоставляют услуги подключения к сети интернет на основании динамически изменяющихся IP адресов из определенного массива.

При каждом входе в сеть этот адрес для пользователя может изменяться, что потребует систематической настройки камер системы видеонаблюдения. Белый статический IP адрес провайдер предоставляет на платной основе и стоит эта услуга недешево.

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

Возможность использования различных устройств для просмотра видео. Для осуществления мониторинга системы видеонаблюдения может использоваться как стационарный ПК или ноутбук, так и мобильные устройства: планшеты, смартфоны.

Доступная стоимость. Цена на камеры видеонаблюдения использующие технологию Р2Р не слишком отличается от стоимости обычных IP камер с сопоставимыми техническими и эксплуатационными параметрами.

Р2Р КАМЕРЫ ВИДЕОНАБЛЮДЕНИЯ

Ниже рассмотрены основные производители Р2Р камер и некоторые их модели.

Falcon Eye – компания производитель оборудования для систем видеонаблюдения и безопасности. Специализируется на беспроводных системах охранных GSM сигнализаций. Имеет официальное представительство в России с 2005 года. вся продукция производителя, которая реализуется в нашей стране, сертифицирована и адаптированы для работы в сложных погодных условиях. Соответствуют международном у стандарту ISO – 90001.

Модельный ряд камер видеонаблюдения Р2Р включает:

  • Falcon Eye FE-MTR 1300;
  • Falcon Eye FE-MTR 300 P2P;
  • Falcon Eye FE-ITR 1300.

Все видеокамеры дают изображение в высоком разрешении 1280х720, могут работать при освещении 0,1 Люкс и имеют интерфейс передачи сигнала Lan и Wi-Fi (Falcon Eye FE-ITR 1300 только Lan). Кроме того они оснащены детектором движения и могут активировать процесс видеозаписи по тревоге.

Запись может осуществляться на видеорегистраторы, в облачный сервис или на карту памяти. Наличие микрофона и динамика превращает камеру в интерактивное устройство для двухсторонних переговоров.

Foscam – компания была основана в 2002 году. Специализируется на выпуске устройств и IP камер для GSM видеонаблюдения. Продукция прошла сертификацию по международному стандарту ISO 9001 и отечественным ГОСТам. Устройства оснащены детектором движения, слотами для карт памяти и интерфейсом RJ 45 (кабельное сетевое подключение витая пара).

Наиболее популярные модели:

  • Foscam FI9821P;
  • Foscam FI9853EP;
  • Foscam FI9803EP.

Zodiac – компания предлагает устройства для бытовых и профессиональных систем видеонаблюдения. Все Р2Р камеры оборудованы системой инфракрасной подсветки, что позволяет производить видеосъемку в темное время суток.

Модели, распространенные на рынке:

  • Zodiac 909W;
  • Zodiac 911;
  • Zodiac 808 выполнена в уличном варианте в корпусе со степенью защиты IP65.

НАСТРОЙКА Р2Р ВИДЕОНАБЛЮДЕНИЯ

Настройка Р2Р видеокамеры занимает не более 5 минут и не требует глубоких знаний протоколов связи или сложных настроек программы. Независимо от используемой камеры или выбранного облачного сервиса алгоритм настройки следующий:

1. С сайта выбранного облачного сервиса скачивается и устанавливается программное обеспечение, совместимое с операционной системой устройства для просмотра.

2. Устанавливается камера, к ней подводится электропитание.

3. Камера подключается к сети интернет посредством локальной проводной сети или через беспроводные средства передачи информации – WiFi, GSM и т. п.

4. На устройстве для просмотра запускается ранее установленное ПО. В специальном поле для поиска набирается ID код. Его можно найти на корпусе камеры или в технической документации. У большинства моделей на корпусе так же размещают QR код, который можно отсканировать смартфоном или планшетом.

5. Для доступа к камере набирается стандартный пароль, который потом нужно обязательно сменить. У каждого производителя или модели он свой, указан на коробке или в паспорте устройства.

Установку системы Р2Р видеонаблюдения можно осуществлять и без использования камер с интегрированной технологией Р2Р. Достаточно в обычной систем видеонаблюдения использовать видеорегистратор с этой функцией. Тогда во время настройки необходимо указывать ID видеорегистратора, и через его интерфейс получить доступ к камерам.

Алгоритм настройки видеорегистратора ничем не отличается от настройки камеры. Примером такого устройства может служить гибридный видеорегистратор SPYMAX RL-2508H Light.

ОБЛАЧНЫЕ СЕРВИСЫ, ПОДДЕРЖИВАЮЩИЕ Р2Р ТЕХНОЛОГИЮ

Облачный Р2Р сервис является совокупностью серверов, которые дают возможность доступа к устройствам, поддерживающим соответствующую функцию. Таких ресурсов существует много. Они делятся на два типа. Сервисы, разработанные компаниями производителями оборудования.

Как правило, поддерживают только работу Р2Р камер компании разработчика. И универсальные сервисы, разработанные сторонними компаниями, которые совместимы с большинством устройств использующих Р2Р.

К примеру, сервисы Proto-X и RVi воспринимают только камеры и видеорегистраторы соответствующих разработчиков. Предустановки для быстрой настройки записывают еще на заводе в процессе производства.

Универсальный облачный Р2Р сервис – Easy4ip совместим с большинством популярных камер.

Для работы с Р2Р камерами необходимо ПО, устанавливаемое на устройстве просмотра:

  • PSS для операционной системы Windows и iOS;
  • iDMSS для мобильных устройств Apple;
  • gDMSS для устройств под управлением ОС Android.

Использование камер с Р2Р технологией дает возможность быстрой установки и настройки эффективной системы видеонаблюдения без привлечения дорогостоящих специалистов. Различные облачные сервисы предоставляют пользователю широкие функциональные возможности, аналогичные тем которые используются в сложных стационарных системах видеонаблюдения.

© 2010-2020 г.г.. Все права защищены.
Материалы, представленные на сайте, имеют ознакомительно-информационный характер и не могут использоваться в качестве руководящих документов

Пару слов о том, что такое P2P и в чем преимущество:
P2P — технология, которая позволяет получить онлайн доступ к устройству через интернет с мобильного или компьютера
P2P работает по уникальному ID коду который есть в устройствах с P2P. При подключении ip камеры или NVR к интернету они связываются с сервером и регистрируются на нем, клиент с мобильным приложением тоже подключается к данному серверу и получает доступ к видео и управлению. Аналогичным способом работает всем известный TeamViewer, когда два ПК связываются между собой через сервер по ID
Преимущество P2P:
Технология P2P не требует проброса портов, не требует настройки DDNS, UPnP, для работы нужен только выход в интернет.
Не имеет значения какой у вас IP адрес "белый", " серый" динамический или статический, WiFi или 3G главное выход в интернет.
У каждого производителя свой P2P сервер и своё приложение для подключения к серверу.
Это говорит о том, что ip камера OMNY не сможет подключиться к P2P серверу Dahua, т.к. не пройдет идентификацию и наоборот.
Аналогичная ситуация с Base и PRO.

Читайте также:  Удаленный рабочий стол windows 7 home basic

Параметры для работы с P2P
1.Самое главное — наличие интернета, ведь как уже сказано выше, камера обращается через интернет к серверу.
2.Безопасность — обязательно смените пароль, не оставляйте admin/admin по умолчанию, ведь тот, кто знает ваш ID сможет смотреть вашу камеру или регистратор без вашего ведома. Существуют и те,кто занимается подбором ID
3.По умолчанию, мобильные приложения используют дополнительный поток для отображения, что в общем то логично, ведь экран смартфона маленький и отображать тяжелый основной поток совершенно не нужно.
Рекомендуемый битрейт для доп.потока это 256-512 Кбит при разрешении CIF,VGA,D1, проверьте ваши настройки потока, т.к зачастую пропускной способности мобильного интернета не хватает, одно дело скачивать что либо, другое непрерывно тянуть поток без задержек и рассыпания картинки. Битрейт напрямую влияет на задержку и отображение картинки.
4.Настройки сети в камере или NVR. Для доступа к P2P не забудьте прописать все параметры, такие как IP адрес, маска подсети, шлюз, и DNS адреса, убедитесь, что с данными параметрами есть выход в интернет. В качестве эксперимента, можете назначить эти параметры вашему компьютеру для проверки. Самый быстрый вариант — установить настройки сети в режим DHCP (при наличии DHCP сервера)
5.Если,на вашем объекте нет интернета, вы не сможете использовать P2P, но можете подключаться локально через Wi-Fi, для этого в мобильном приложении выберите вариант подключения по IP адресу. (не поддерживается приложением Danale)
6.Воспроизведение архива, при подключении через P2P. Как уже было сказано выше, мобильное приложение отображает дополнительный поток, НО! В архив пишется основной поток, который высокого разрешения, это значит, что смартфону потребуется больше усилий и и больше интернет трафика, чтоб выкачивать архив, что может сказываться на долгом отклике, и постоянной подкачке.
Если, вы часто смотрите архив через смартфон, вы можете включить запись дополнительного потока на вашем NVR,а в мобильном приложении выбрать соответствующий параметр — просмотр архива доп.поток, в таком случае, архив просматривать проще и быстрее, но не стоит забывать, что камера которая пишет два потока одновременно, занимает в архиве больше места, соответственно срок хранения уменьшится.
В каких случаях P2P может не работать:

1.Не указаны действующие DNS адреса в сетевых настройках камеры или регистратора. Самая частая ошибка.
Для работы с P2P мы рекомендуем установить сетевые параметры устройства в режим DHCP
2.Низкая скорость интернет соединения, даже если смартфон показывает вам 3G,4G. Попробуйте стабильный Wi-Fi.
3.На сервере могут проводится профработы, обновление и.т.д нужно просто ждать
Не стоит забывать, что сервера находятся заграницей, и возможно, что где-то произошла авария на линии связи.
Как правило, даже самые крупные аварии устраняются максимум за неделю.
Повлиять на скорость проф.работ мы к сожалению не можем.
4.Устройство не поддерживает P2P. Устройства до 2015г не поддерживаются и не будут поддерживаться.
Устройства 2015-2016г поддерживаются частично, в зависимости от текущей версии, уточняйте в технической поддержке.
Некоторые устройства Dahua не поддерживают P2P по задумке производителя, например PTZ камеры, многоквартирные IP домофоны
Это обусловлено безопасностью, многоквартирный домофон не должен иметь выход в интернет а PTZ камеры как правило
ставят на крупные охраняемые объекты, где доступ с мобильного противопоказан.
Обратите внимание, если ваш продукт не поддерживает P2P вы можете подключить его традиционным способом по IP адресу!
5.Несовместимая версия прошивки. Для OMNY прошивки можно найти здесь для Dahua на официальном сайте https://www.dahuasecurity.com/
6.Устройство не проходит идентификацию на P2P сервере. Такое может быть, если серийный номер устройства не соответствует действительности, например выглядит как 8888888888 или отсутствует совсем. В данном случае, обратитесь в техническую поддержку.
7.Неправильное мобильное приложение. Убедитесь, что используете мобильное приложение соответствующее вашему продукту и актуальную его версию.
8.Неверные данные для подключения, перепроверьте логин/пароль, не используйте спец.символы для имени,логина,пароля.

Теперь более подробно об особенностях в подключении каждого из продуктов:

OMNY PRO
IP камеры и видеорегистраторы NVR серии OMNY PRO поддерживают P2P подключение на мобильных платформах iOS и Android.
Устройства после 2016 года поддерживаются в программе NetVideo для Windows, с подключением через P2P.
Для подключения с мобильного, нужно скачать и установить бесплатное приложение EasyLive
(ранее использовался Smartwatchman, MobileLive но они уже не актуальны)
По ссылке есть инструкция на русском языке и другие программы для OMNY
Кратко: Приложением EasyLive сканируйте QR код который находится на WEB странице устройства в превью (снизу значок QR)

QR код содержит в себе идентификатор, в поле логин/пароль введите реальный данные вашего устройства.
Убедитесь, что ваш смартфон и OMNY устройство имеют доступ в интернет, в настройках сети указаны работающие DNS.

OMNY Base
IP камеры серии OMNY Base поддерживают P2P подключение только на мобильных платформах iOS и Android
Для подключения требуется скачать и установить бесплатное приложение Danale
По ссылке есть подробная инструкция (англ.яз) и другие программы для OMNY Base
Кратко: Приложением Danale сканируйте QR код который находится в камере на WEB странице (Система/системная информация)

Dahua IP камеры, NVR, HCVR, Intercom

Устройства Dahua поддерживают P2P подключение как на мобильных платформах, так и на компьютере.
Для подключения на мобильном устройстве требуется скачать и установить приложение DMSS
Есть различные версии приложения, DMSS Lite, DMSS plus, DMSS HD
Рекомендуем ставить DMSS Lite. Платная версия plus практически не отличается, версия HD для планшетов, но и Lite тоже с планшетом работает.
По ссылке есть подробная информация и другие программы для Dahua
Кратко: В первую очередь P2P нужно включить на устройстве. В зависимости от релиза, вкладка может находится в разных местах, но как правило она находится в настройках сети. Для включения кликните Enable. Успешное соединение это статус online или connect success
Приложением DMSS сканируйте QR код.
Для работы на компьютере: Установите программу Smart-PSS на вкладке добавления устройств нужно выбрать тип P2P и вручную ввести серийный номер, который находится в том же месте где QR код.


Для работы с P2P мы рекомендуем установить сетевые параметры устройства в режим DHCP

Добрый день, хабрасообщество! Сегодня я хотел бы рассказать о волшебном и чудесном проекте компании Тензор — удаленном помощнике. Это система удаленного доступа, связывающая миллионы клиентов и операторов в рамках общей клиентской базы СБИС. Удаленный помощник уже сейчас тесно интегрирован с online.sbis.ru. Каждый день мы регистрируем более десяти тысяч подключений и десятки часов сессионного времени в сутки.В этой статье мы расскажем о том, как мы устанавливаем p2p соединения, и что делать, если этого сделать не удается.

Читайте также:  Как установить драйвера на наушники с микрофоном

Опыт — сын ошибок трудных

Систем удаленного доступа существует достаточно много. Это и всевозможные вариации бесплатных VNC, и достаточно мощные и предлагающие широкий набор функционала платные решения.Изначально наша компания использовала адаптацию одного из таких решений — UltraVNC. Это отличная бесплатная система, которая позволяет подключиться к другому ПК, зная его IP. Вариант того, как стоит поступать, если ПК имеет непрямой доступ к сети интерне, уже мелькал на просторах Хабра, и мы не будем затрагивать эту тему. Этого решения будет достаточно только до достижения сравнительно небольшого количества одновременных подключений. Шаг влево, шаг вправо, и начинается головняк с масштабированием, удобством использования, интеграцией в систему и сложностью доработок, которые, конечно, появляются в процессе жизненного цикла ПО, с чем мы и столкнулись.

Итак, было принято решение изобрести свой велосипед создать свою систему управления удаленными рабочими столами, которую можно было бы интегрировать в общую экосистему СБИС. Конечно, самый простой способ связать 2 ПК, который не использует только ленивый — по числовому идентификатору. В нашей реализации мы используем рандомные 6-и знаковые номера без привязки к конкретному клиенту.

Один очень известный человек однажды сказал:

Теория — это когда все известно, но ничего не работает.
Практика — это когда все работает, но никто не знает почему.
Мы же объединяем теорию и практику: ничего не работает…
и никто не знает почему!

В самом начале нашего пути, эта цитата была очень похожа на правду: было понимание каким образом можно «познакомить» друг с другом клиента и оператора. Но на практике все оказалось не совсем тривиально.

Введение в p2p

Для связи 2х устройств мы используем сигнальный сервер — посредник, доступ к которому есть у обеих сторон. Его роль заключается в регистрации и возможности обмена информацией между участниками в режиме реального времени. Через него без лишних хлопот мы производим обмен endpoint’ами (связка IP-адрес и порт, точка доступа) с целью установки соединения.

Этот сигнальный сервер, именуемый у нас remote helper manager(RHM) — пул написанных на nodejs систем, обеспечивающих отказоустойчивую работу всего сервиса. Нууу, точнее, как «отказоустойчивую» … мы на это надеемся :). Подключение к одному из серверов происходит по принципу round-robin. Таким образом клиент и оператор могут быть подключены к разным серверам, и вся механика по их синхронизации и координации полностью снята с десктопного приложения.

Вся работа сводится к обмену служебными пакетами, при помощи которых стороны могут однозначно идентифицировать друг друга и выполнять какие-либо действия относительно синхронно, например, начать процедуру сбора кандидатов на подключение или же начало самой попытки подключения.

Кстати, не поступайте как мы – не стреляйте себе в ногу: если используете 443 TCP порт — используйте TLS, а не чистый трафик. Все больше и больше брандмауэров его блокируют и разрывают соединение, причем, нередко на стороне провайдера.

Самые распространенные в сети интернет протоколы обмена информацией — это UDP и TCP. UDP — быстр и легок, однако лишен нативной возможности гарантировать доставку пакетов и их очередность. TCP лишен этих недостатков, однако чуть более сложен в процессе установки p2p соединения. А с последними тенденциями, как мне кажется, прямое tcp соединение и вовсе может кануть в лету.

Далеко не всегда установка p2p соединения зависит от умения работать с сетевыми протоколами. По большей части эта возможность зависит от конкретных сетевых настроек, чаще: типа NAT(Network address translation) и/или настроек файрвола.

Принято разделять NAT на 4 типа, каждый из которых отличаются правилами трансляции пакетов из внешней сети конечному пользователю:

  • Symmetric NAT
  • Cone/Full Cone NAT
  • Address restricted cone NAT
  • Port restricted cone NAT

Кстати, некоторые продвинутые устройства позволяют выбрать режим прямо из конфигурационной панели, но сейчас не об этом.

В большинстве случаев удается пробиться через NAT, инициировав передачу данных к узлу сети, от которого ожидаешь получить ответ. Для этого необходимо, чтобы удаленная сторона узнала свой внешний endpoint и сообщила его нам. Нам, в свою очередь, необходимо сделать то же самое.

Чтобы узнать свой IP-адрес и порт на внешнем устройстве (для простоты назовем его маршрутизатором), мы используем STUN (Session traversal utilities for NAT) и TURN (Traversal using relay NAT) сервера. STUN – для определения внешних IP: порт(endpoint) на UDP протокола, TURN – для TCP.

Почему так, ведь гораздо проще было бы получить внешний IP с нашего же сигнального сервера?

Здесь имеется как минимум 4 аргумента «за»:

  1. Возможность прозрачного расширения списка серверов (как своих, так и общедоступных) для сбора endpoint’ов, таким образом повысить отказоустойчивость системы.
  2. Взаимодополняемость и широкое распространение протоколов STUN и TURN позволяет уделять минимум внимания на сбор endpoint’ов и ретрансляцию трафика.
  3. STUN и TURN протоколы очень похожи. Разобравшись с архитектурой STUN пакетов, TURN идет уже по «накатанной». А использование TURN дают нам возможность ретрансляции трафика при провале попытки установить прямое подключение.
  4. У нас уже использовался STUN/TURN сервер «coturn» в проекте видеозвонков, а значит можно было «заюзать» их мощности с минимальными вливаниями в «железо».

Coturn — это opensource реализация TURN и STUN сервера. Его использование, как показала практика, совсем не ограничивается WebRTC. На мой взгляд, это достаточно гибкий инструмент, не сильно требовательный. Да, у него нет встроенной возможности горизонтального масштабирования, но все решаемо, например, при помощи сигнального сервера.

Как же строится общение с сервером по STUN/TURN протоколу

Этапы получения endpoint’ов задокументированы в RFC #3489, #5389, #5766 и #6062.
Все сообщения к STUN или TURN протоколу имеют следующий вид:

  1. 12 байта на тип сообщения
  2. 22 байта на его длину (размер всех последующих атрибутов)
  3. 12 байт — для рандомного идентификатора для TURN и 16 байт — для STUN пакетов. Их размер отличается на 4 байта — эти данные зарезервированы для TURN пакета под константный MagicCookie.

В целом служебная информация заключена в первых 20 байтах пакета.
Атрибуты также состоят из:

  1. 2 байта на тип атрибута
  2. 2 байта на его длину
  3. самого значения атрибута

Важно, что общая длина атрибута должна быть кратна 4 байтам. Если, скажем, значение длины атрибута, например 7, то в конце необходимо доукомплектовать: (2 + 2 + 7) % 4 байтами пустых данных.

Как выглядит сбор endpoint’а для UDP протокола:

  1. Коннект к серверу
  2. Отправка пакета, содержащего binding request:
  3. Получение пакета, содержащего binding response:
  4. Парсинг пакета и извлечение mapped-address:
    0x00 0x01 — Тип атрибута, соответствующий MAPPED-ADDRESS
    0x00 0x08 — Совокупная длина атрибута
    0x00 0x01 — Версия протокола, соответствующая IPv4
    0x30 0x39 – Порт, со значением 12345
Читайте также:  Как настроить ноутбук на раздачу wifi

Далее каждый байт соответствует своему октету ipv4 адреса: 123.123.123.123

Сбор endpoint’а для TCP несколько отличается, т.к. получаем мы его по TURN протоколу. Почему именно так? Все объясняется минимизацией количества сокетов, подключенных к TURN-серверу, а значит, потенциально большее количество людей смогут «висеть» на одном сервере ретрансляции трафика.

Для сбора кандидата по TURN протоколу необходимо:

  1. Подключиться к серверу.
  2. Отправить пакет, содержащий allocation request.
  3. При необходимости авторизации на TURN сервере в ответ мы получим allocate failure с 401 ошибкой. В таком случае необходимо будет повторить allocation request с указанием имени пользователя и атрибута Message Integrity, генерируемого на основании самого сообщения, имени пользователя, пароля и атрибута realm, взятого из полученного от сервера ответа.
  4. Далее сервер в случае успешной регистрации присылает allocate success response с атрибутом выделенного порта на TURN-сервере, а также XOR-MAPPED-ADDRESS – тем самым публичным endpoint’ом на TCP протоколе. Для дальнейшей работы с IP каждый октет надо «заксорить» (XOR — операция логического исключения ИЛИ) аналогичным байтом из константного атрибута MagicCookie: 0x21 0x12 0xA4 0x42
  5. В случае дальнейшей работой с этим TURN соединением необходимо каждый раз продлять регистрацию, отправляя refresh request. Сделано это для отбрасывания «мертвых» коннектов.

Итак, мы имеем сервер, через который мы обменялись с удаленной стороной собранными endpoint’ами.

Конечно, это сейчас кажется простым и понятным, но оглядываясь назад, когда смотришь в RFC и понимаешь, что без подсказок wireshark’а дальше дело не сдвинется с мертвой точки — готовишься к погружению в… В общем, вспоминается один бородатый анекдот:

Учись пацан, а то так и будешь ключи подавать…

Как установить соединение?

Самое простое – это организация UDP hole punch’а.
Для этого необходимо искусственно создать правила маршрутизации на своем NAT.

Достаточно просто организовать серию передачи пакетов на удаленный endpoint и дождаться от него ответ. Несколько пакетов необходимы для создания соответствующего правила на NAT’е и избавления от «гонки», кто кому первым доставит соответствующий пакет. Ну и потерю на UDP никто не отменял.

Далее обменялись контрольными фразами и можно считать, что соединение установлено.

Чуть-чуть сложнее – организация TCP hole punch, хотя общая идеология остается точно такой же.

Сложность заключается в том, что только 1 сокет по умолчанию может занимать свой локальный endpoint, а попытка подключения к другому адресу приведет к автоматическому разрыву соединения с первым. Однако существуют опции сокета, это ограничение снимающие: REUSE_ADDRESS и EXCLUSIVEADDRUSE. После взведения первой и сбрасывания второй опции на сокете другие сокеты смогут занимать тот же самый локальный endpoint.

Ну и остается сущий пустяк – забиндиться на локальный endpoint, открытый сокетом при коннекте с TURN’ом, ну и попытаться подключиться к endpoint’у удаленной стороны.

Ну и еще чуть сложнее, но не менее важная для стабильной установки соединения – ретрансляция трафика.

  1. Т.к. регистрация на TURN’е у нас уже имеется, все, что нам необходимо – это добавить в разрешения на TURN’е регистрацию удаленной стороны. Для этого отправляем пакет CreatePermission с указанием удаленной регистрации.
  2. Инициатор соединения отправляет пакет ConnectRequest с указанием «заксоренного» endpoint’а удаленной регистрации и подписывает пакет MessageIntegrity.
  3. Если все хорошо и удаленная сторона отправляла CreatePermission с вашей регистрацией, то инициатору придет connect success response, а клиенту – connection attempt. И в том, и в другом случае во входящем пакете будет присутствовать атрибут connection-id.
  4. Далее за непродолжительный промежуток времени необходимо новым сокетом подключиться к тому же IP и порту TURN сервера, что и первоначальный сокет (в классическом исполнении TURN сервера могут слушать как 3478, так и 443 tcp порты) и отправить пакет ConnectionBind с нового сокета с указанием connection-id, полученного ранее.
  5. Дождаться пакета, содержащего connection bind success response, и вуаля – соединение установлено. При этом да, используется 2 сокета — управляющий, который отвечает за поддержание соединения, и транспортный, с которым можно работать как при прямом соединении – все, что будет отправлено или получено, должно обрабатываться как есть.

По приоритету использования у нас выстроилась такая иерархия: прямое tcp > прямое udp > релей (ретрансляция)

Почему мы унесли прямое udp на второе место?

Что ж, UDP при всей своей легкости и скорости обладает существенным недостатком: отсутствием гарантии доставки и очередности. И если с видеопотоком еще как-то с этим можно было бы смириться (наличие графических артефактов), то вот с передачей файлов тут несколько серьезней.

Для обеспечения гарантии и очередности был реализован механизм, схожий с reliable UDP, который да, потребляет несколько больше ресурсов, но и дает желаемое.
Как же мы вышли из ситуации? Для начала необходимо узнать MTU (maximum transmission unit) – то есть максимально большой размер udp пакета, который может быть отправлен без фрагментирования на проходящих узлах.

Для этого принимаем за максимальный размер пакета 512 байт и выставляем сокету опцию IP_DONTFRAGMENT. Отправляем пакет и ждем его подтверждения. Если в течение фиксированного времени мы получили ответ, то увеличиваем максимальный размер и повторяем итерацию. Если же в конечном итоге подтверждения мы не дождались, то начинаем процедуру уточнения размера MTU: начинаем не существенно понижать максимальный размер блока и ожидаем стабильного подтверждения в течение 10 раз. Не получили подтверждение – снизили MTU и по новой запускаем цикл.
Оптимальный размер MTU найден.

Далее проводим сегментирование: нарезаем весь большой блок на множество маленьких с указанием начального номера сегмента и конечного номера сегмента, характеризующего пакет. После разбиения добавляем сегменты в очередь отправки. Отправка сегмента производится до тех пор, пока удаленная сторона не сообщит нам о том, что получила его. Интервал повторной отправки используем как 1.2*максимальный размер ping’а, полученного при нахождении MTU.
На принимающей стороне смотрим полученный сегмент, добавляем во входящую очередь и пробуем собрать ближайший пакет. Если получилось – чистим очередь и пробуем собрать следующий.

Тут, конечно, самые внимательные из вас, кто «дожил» до этого абзаца, могут смело заметить: а почему не использовать кодек x264 или x265? — и будут частично правы. Честно говоря, мы тоже склонны его заюзать, тогда можно поступиться этим велосипедом на udp. Но как быть, скажем, с передачей бинарных файлов? В этом случае мы опять возвращаемся к необходимости гарантии доставки и очередности пакетов.

В заключение хочется отметить, что с такой организацией подключений мы имеем не более 2-3% несостоявшихся подключений в день, большую часть из которых составляют неверные настройки прокси или файрвола, настроив которые соединение осуществляется без проблем.

Если эта тема вам окажется интересна (а нам она кажется таковой), то в следующих статьях мы расскажем о запуске приложения с наивысшими правами в системе, проблемах, которые из-за этого образуются, и как мы с ними боремся. Об алгоритмах сжатия, виртуальных рабочих столах и многом другом.

Автор: Владислав Яковлев asmsa

Вы можете помочь и перевести немного средств на развитие сайта

Ссылка на основную публикацию
Что лучше ps3 или ps4
PlayStation 4 выпуска 2013 года позиционируется на рынке как флагман нового поколения игровых приставок от Sony. Анонс новинки дал понять,...
Что делать если браузерные игры лагают
Что делать если зависает браузерная игра, не грузится, лагает? Если игра не загружается, зависает, загрузка останавливается на определенном шаге, вы...
Что делать если взорвалось колесо
Вы когда-нибудь видели взрыв шины? Это поистине экстремальное зрелище, особенно если речь идёт о грузовом транспорте. Взрываясь на ходу, куски...
Что лучше амд или нвидиа для игр
Война видеокарт никогда не прекращается. Если вы спросите консольного игрока, он вам подробно расскажет о бесконечном соперничестве между Xbox One...
Adblock detector