Вероятно, вы слышали такую фразу: «вам нужно использовать VPN для защиты вашей конфиденциальности». Теперь вы думаете: «Хорошо, но как работает VPN?»

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

Что такое VPN?

Прежде чем мы рассмотрим конкретные протоколы VPN, давайте быстро вспомним, что такое VPN.

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

Когда вы используете VPN, все ваши запросы сначала направляются через частный сервер, принадлежащий провайдеру VPN. Ваш запрос направляется от A до C через B. Вы можете получить доступ ко всем ранее доступным вам данным (и в некоторых случаях - к большему числу). Но на веб-сайте или службе есть только данные провайдера VPN: их IP-адрес и т. д.

Существует много применений для VPN, в том числе защитить ваши данные и личность, избежать репрессивной цензуры и шифровать ваши сообщения.

Что такое VPN-протоколы?

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

Давайте рассмотрим наиболее распространенные протоколы VPN.

1. OpenVPN

OpenVPN - это протокол VPN с открытым исходным кодом. Это означает, что пользователи могут проверять исходный код на наличие уязвимостей или использовать его в других проектах. OpenVPN стал одним из важнейших протоколов VPN. OpenVPN имеет открытый исходный код и является одним из наиболее безопасных протоколов. OpenVPN позволяет пользователям защищать свои данные с использованием, по существу, нерушимого шифрования ключей AES-256 (среди прочих), с 2048-битной аутентификацией RSA и 160-битным алгоритмом SHA1.

Помимо обеспечения надежного шифрования, OpenVPN также доступен практически для каждой платформы: Windows, MacOS, Linux, Android, iOS, маршрутизаторов и многого другого. Даже Windows Phone и Blackberry могут его использовать!

Протокол OpenVPN в прошлом подвергался критике из-за низких скоростей. Однако недавние внедрения привели к некоторому ускорению, и внимание к безопасности и конфиденциальности заслуживает внимания.

2. L2TP / IPSec

Протокол туннеля уровня 2 - очень популярный протокол VPN. L2TP является преемником обесцененного PPTP (более подробно см. Ниже раздел PPTP), разработанный Microsoft и L2F, разработанный Cisco. Однако L2TP фактически не обеспечивает никакого шифрования или конфиденциальности.

Соответственно, службы, использующие L2TP, часто связаны с протоколом IPsec безопасности. После внедрения L2TP / IPSec становится одним из наиболее безопасных подключений VPN. Он использует шифрование AES-256 бит и не имеет известных уязвимостей (хотя IPSec якобы был скомпрометирован NSA).

Тем не менее, в то время как L2TP / IPSec не имеет известных уязвимостей, он имеет некоторые небольшие недостатки. Например, по умолчанию протокол использует UDP на порту 500. Это упрощает определение и блокировку трафика.

3. SSTP

Протокол Secure Socket Tunneling Protocol является еще одним популярным протоколом VPN. SSTP обладает одним заметным преимуществом: он полностью интегрирован с каждой операционной системой Microsoft с момента установки Windows Vista с пакетом обновления 1 (SP1). Это означает, что вы можете использовать SSTP с Winlogon или для повышения безопасности - смарт-чип. Кроме того, многие поставщики VPN имеют специальные встроенные инструкции SSTP для Windows. Их можно найти на веб-сайте поставщика VPN.

SSTP использует 2048-битные SSL / TLS-сертификаты для аутентификации и 256-битные SSL-ключи для шифрования. В целом, SSTP достаточно безопасен.

SSTP является, по сути, проприетарным протоколом Microsoft. Это означает, что никто не может полностью проверить базовый код. Тем не менее, большинство из них по-прежнему считают SSTP безопасным.

Наконец, SSTP имеет встроенную поддержку систем Windows, Linux и BSD. Android, macOS и iOS поддерживают сторонние клиенты.

4. IKEv2

Internet Key Exchange (Интернет обмен ключами) версии 2 - еще один протокол VPN, разработанный Microsoft и Cisco. IKEv2 сам по себе является протоколом туннелирования, обеспечивающим сеанс обмена безопасными ключами. Поэтому (как и его предшественник), IKEv2 часто сопрягается с IPSec для шифрования и аутентификации.

Хотя IKEv2 не так популярен, как другие протоколы VPN, он имеет множество решений для мобильных VPN. Это связано с тем, что он умеет повторно подключаться в моменты временной потери интернет соединения, а также во время сетевого коммутатора (например, от Wi-Fi до мобильных данных).

IKEv2 - это проприетарный протокол с собственной поддержкой устройств Windows, iOS и Blackberry. Для Linux доступны версии с открытым исходным кодом, а поддержка Android доступна через сторонние приложения.

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

5. PPTP

Протокол туннелирования «точка-точка» является одним из старейших протоколов VPN. Он по-прежнему используется в некоторых местах, но большинство служб давно обновлены до более быстрых и безопасных протоколов.

PPTP был введен еще в 1995 году. Он был фактически интегрирован с Windows 95, разработанный для работы с коммутируемыми соединениями. В то время это было чрезвычайно полезно.

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

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

Подведем итог протоколов VPN

Мы рассмотрели пять основных протоколов VPN. Давайте быстро подытожим их плюсы и минусы.

OpenVPN: имеет открытый исходный код, предлагает самое сильное шифрование, подходящее для всех видов деятельности, имеет немного более медленное время соединения.

L2TP / IPSec: широко используемый протокол, хорошие скорости, но он легко блокируется из-за зависимости от одного порта.

SSTP: хорошая безопасность, трудно блокировать и обнаруживать.

IKEv2: быстрый, удобный для мобильных устройств, с несколькими реализациями с открытым исходным кодом (потенциально подрывается АНБ).

PPTP: быстрый, широко поддерживаемый, но полный дыр в области безопасности, используется только для потоковой передачи и основного просмотра веб-страниц.

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

Какой VPN-протокол вы обычно используете? Предлагает ли ваш VPN-провайдер выбор? Расскажите это в комментариях!

Прежде всего определим области применения каналов передачи данных в электроэнергетике и задачи, которые решаются с их помощью. В настоящее время к основным областям применения систем передачи данных можно отнести системы релейной защиты и автоматики (РЗА), диспетчерского и автоматизированного технологического управления электроэнергетическими объектами (АСТУ), а также системы автоматизированного учета энергоресурсов. В рамках этих систем решаются следующие задачи:

Системы АСТУ

1. Передача данных между локальными устройствами телемеханики (ТМ), устройствами РЗА и центральной приемопередающей станцией (ЦППС).
2. Передача данных между объектом и диспетчерским центром.
3. Передача данных между диспетчерскими центрами.

Системы учета

1. Передача данных от приборов учета в устройства сбора и передачи данных (УСПД).
2. Передача данных от УСПД на сервер.

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

В РЗА системы передачи информации могут выполнять следующие функции:

1. Передача дискретных сигналов.
2. Передача данных между устройствами РЗА и ЦППС.

Другим важным каналом передачи, общим как для систем РЗА, так и для систем АСТУ и учета, является канал, по которому осуществляется передача измерений от измерительных трансформаторов тока и напряжения. До последнего времени о внедрении цифровых протоколов связи на данном уровне речь не шла, однако, имея в виду появление протокола для передачи мгновенных значений тока и напряжения МЭК 61850-9-2, на проблемах этого информационного канала также стоит остановиться.

Последовательно рассмотрим каждую из вышеперечисленных функций передачи информации и существующие подходы к их реализации.

Передача измерений от ТТ и ТН

Передача сигналов от измерительных трансформаторов тока (ТТ) и напряжения (ТН) осуществляется по кабелям с медными жилами переменного тока и напряжения соответственно. Для данного способа характерны проблемы, о которых достаточно часто упоминается в литературе :

• большая разветвленность и протяженность медных кабелей, приводящая к необходимости применения большого числа вспомогательного оборудования (испытательных блоков, клеммников и т.д.) и, как следствие, к повышению стоимости систем и сложности монтажа и наладки;
• подверженность измерительных цепей воздействию элек­тромагнитных помех;
• сложность или отсутствие возможности контроля исправности измерительного канала в темпе процесса, сложность поиска места повреждения;
• влияние сопротивления измерительных цепей на точность измерений и необходимость согласования мощности ТТ/ТН с сопротивлением цепей и нагрузкой приемника.

Передача дискретных сигналов между устройствами

Передача дискретных сигналов между устройствами традиционно осуществляется подачей оперативного напряжения посредством замыкания выходного реле одного устройства на дискретный вход другого.

Такой способ передачи информации имеет следующие недостатки :

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

Передача данных между РЗА и ЦППС

Обмен данными между РЗА и ЦППС на объекте осуществляется в цифровом формате. Однако ввиду необходимости интеграции большого количества различных устройств этот способ имеет следующие особенности:

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

Передача данных между ЦППС объекта и диспетчерским центром

Передача данных между объектом и диспетчерским центром также ведется в цифровом формате. Обычно для этих целей используют протоколы МЭК 60870-101/104. Особенности реализации этих систем связи:

• необходимость передачи данных в протоколах диспетчерского управления, как правило, отличающихся от протоколов, применяемых на подстанции;
• передача ограниченного количества информации, что обусловлено необходимостью переназначения всех сигналов с одного протокола на другой, и, как следствие, потеря некоторых данных, передача которых на этапе проектирования не была сочтена целесообразной;
• отсутствие единых наименований сигналов в рамках объекта и в центрах управления сетями (ЦУС), приводящее к сложности наладки и отслеживания ошибок.

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

Рис. 1. Схема организации передачи данных.

Охарактеризуем кратко показанные стандартные протоколы.

Modbus

Modbus – один из наиболее распространенных сетевых протоколов для интеграции устройств РЗА в систему АСТУ, построенный на архитектуре «клиент–сервер». Популярность этого протокола во многом обусловлена его открытостью, поэтому большинство устройств поддерживают этот протокол.

Протокол Modbus может применяться для передачи данных по последовательным линиям связи RS-485, RS-433, RS-232, а также сети TCP/IP (Modbus TCP).

Стандарт Modbus состоит из трех частей, описывающих прикладной уровень протокола, спецификацию канального и физического уровней, а также спецификацию ADU для транспорта через стек TCP/IP.

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

МЭК 60870-5-101/103/104

МЭК 60870-5-101 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ. Он также построен на архитектуре «клиент–сервер» и предназначен для передачи данных по последовательным линиям связи RS-232/485.

Протокол МЭК 60870-5-104 является расширением протокола 101 и регламентирует использование сетевого доступа по протоколу TCP/IP. Стандарты МЭК 60870-5-101/104 не подразумевают наличие семантической модели данных.

Протокол МЭК 60870-5-103 предназначен для обеспечения возможности интеграции в систему управления энергообъекта устройств РЗА. В отличие от стандартов МЭК 60870-5-101/104, он определяет семантику для фиксированного набора данных, формируемых устройствами РЗА. Одним из основных недостатков протокола МЭК 60870-5-103 является относительно невысокая скорость передачи данных.

Протоколы МЭК 60870-5-101/103/104 обеспечивают достаточно высокую функциональность при решении задач телеуправления, телесигнализации и телеизмерений, интеграции данных устройств в системы управления. В отличие от Modbus они позволяют также осуществлять спорадическую передачу данных с устройств.

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

В целом протоколы хорошо подходят для решения описанного выше спектра задач, однако обладают рядом недостатков :

1. Передача данных осуществляется в два этапа: назначение индексированных коммуникационных объектов на прикладные объекты; назначение прикладных объектов на переменные в прикладной базе данных или программе. Таким образом, отсутствует семантическая связь (полностью или частично) между передаваемыми данными и объектами данных прикладных функций.
2. Протоколы не предусматривают возможность передачи сигналов реального времени. При этом под сигналами реального времени понимаются данные, которые должны передаваться в темпе процесса с минимально возможными выдержками времени, к которым относятся, например, команды отключения, передача мгновенных значений токов и напряжений от измерительных трансформаторов. При передаче таких сигналов задержки в канале связи являются критическими. Отметим, что данный пункт не связан с возможностью синхронизации устройств с единым сервером времени, а касается именно вопросов скорости передачи данных между устройствами.

DNP3

В России этот стандарт распространен слабо, однако некоторые устройства автоматизации все же поддерживают его. Долгое время протокол не был стандартизован, но сейчас он утвержден как стандарт IEEE-1815.

DNP3 поддерживает и последовательные линии связи RS-232/485, и сети TCP/IP. Протокол описывает три уровня модели OSI: прикладной, канальный и физический. Его отличительной особенностью является возможность передачи данных как от ведущего устройства к ведомому, так и между ведомыми устройствами. DNP3 также поддерживает спорадическую передачу данных от ведомых устройств.

В основу передачи данных положен, как и в случае с МЭК-101/104, принцип передачи таблицы значений. При этом с целью оптимизации использования коммуникационных ресурсов ведется посылка не всей базы данных, а только ее переменной части.

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

В дано подробное сравнение протоколов, но мы в табл. 1 приведем краткие выдержки применительно к рассмотренным выше протоколам.

Таблица 1. Протоколы передачи данных

Параметр	Протокол
	Modbus	МЭК-101/103/104	DNP3
Линии связи	RS-232/485/422 TCP/IP (Modbus TCP)	RS-232/485/422 TCP/IP (104)	RS-232/485/422 TCP/IP
Архитектура	Клиент – сервер	Клиент – сервер	Клиент – сервер
Принцип передачи данных	Обмен индексированными точками данных
Спорадическая передача данных	Нет	Да	Да
Семантическая модель данных	Нет	Нет Базовая (103)	Да
Передача данных в режиме реального времени	Нет	Нет	Нет

Выводы

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

Большое количество проприетарных протоколов приводит к усложнению процесса интеграции устройств в единую систему:

• Протоколы должны поддерживаться контроллером и ЦППС, что требует реализации поддержки большого количества протоколов в УСО и ЦППС одновременно и ведет к удорожанию оборудования.
• Для интеграции устройств по проприетарным протоколам требуется квалификация наладочного персонала в работе с каждым из них.
• Переназначение сигналов из проприетарных протоколов в общепромышленные и назад часто приводит к потере информации, включая дополнительную информацию (такую как метки времени, метки качества и т.п.).

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

Передача ответственных команд управления (команды отключения выключателей от РЗА, оперативные блокировки и т.п.) и оцифрованных мгновенных значений токов и напряжений невозможна в цифровом формате в силу непригодности существующих протоколов связи для передачи подобного рода информации.

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

Основные положения при создании стандарта МЭК 61850

Работа над стандартом МЭК 61850 началась в 1995 году, причем изначально велась двумя независимыми, параллельно работающими группами : одна из них, образованная UCA , занималась разработкой общих объектных моделей подстанционного оборудования (GOMFSE); вторая, образованная в рамках технического комитета 57 МЭК, занималась созданием стандарта на протокол передачи данных для подстанций.

Позднее, в 1997 году, работы обеих групп были объединены под эгидой рабочей группы 10 ТК 57 МЭК и вошли в основу стандарта МЭК 61850.

В основе стандарта лежат три положения:

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

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

На сегодняшний день МЭК 61850 состоит из 25 различных документов (в том числе разрабатываемых), которые охватывают широкий круг вопросов и делают его гораздо больше, чем просто спецификацией ряда коммуникационных протоколов. Отметим основные особенности стандарта :

• Определяет не только то, как должен производиться обмен информацией, но и то, какой информацией должен производиться обмен. Стандарт описывает абстрактные модели оборудования объекта и выполняемых функций. Информационная модель, лежащая в основе стандарта, представляется в виде классов объектов данных, атрибутов данных, абстрактных сервисов и описания взаимосвязей между ними.
• Определяет процесс проектирования и наладки систем.
• Определяет язык описания конфигурации системы (System Configuration description Language – SCL). Данный язык обеспечивает возможность обмена информацией о конфигурации устройств в стандартизованном формате между программным обеспечением различных фирм-производителей.
• Описывает методики испытаний и приемки оборудования.

Работая с МЭК 61850, необходимо понимать, что стандарт:

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

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

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

Список литературы

1. Баглейбтер О.И. Трансформатор тока в сетях релейной защиты. Противодействие насыщению ТТ апериодической составляющей тока КЗ // Новости ЭлектроТехники. 2008. № 5(53).
2. Schaub P., Haywood J., Ingram D., Kenwrick A., Dusha G. Test and Evaluation of Non Conventional Instrument Transformers and Sampled Value Process Bus on Powerlink’s Transmission Network. SEAPAC 2011. CIGRE Australia Panel B5.
3. Шевцов М. В. Передача дискретных сигналов между УРЗА по цифровым каналам связи // Релейщик. 2009. № 1.
4. Schwarz K. Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC 60870-6-TASE.2 with IEC 61850 (электронный документ: http://bit.ly/NOHn8L).
5. Brunner C., Apostolov A. IEC 61850 Brand New World. PAC World Magazine. Summer 2007.
6. IEC 61850-1: Introduction and Overview.

Сегодня я расскажу о замечательном протоколе вещания RTMFP . В нём реализовано много интересных подходов и бытует очень много предрассудков относительно его возможностей. Хочу подогреть интерес к этой теме и развеять существующие иллюзии. Я не нашёл ничего лучше для вещания в реальном времени, и решил написать этот пост.

Предыстория

Давным-давно в далёкой галактике...
В 2004"ом жила-была Amicima, Inc. в которой были разработана GPL реализация протокола MFP - MFPNet . Потом они выпустили amiciPhone - одного из конкурентов Skype, но из-за проблем позиционирования дела пошли не очень хорошо. В 2007"ом их приобрели Adobe так как им нужен был хороший протокол вещания реального времени.

А что не так с RTMP ?

RTMP не является протоколом вещания реального времени:

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

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

Предрассудки по поводу RTMFP

1. Это проприетарный протокол

   Adobe решила его опубликовать в виде RFC7016 для того, чтобы подогреть внимание общественности, но как-то обошлось. Как ни странно, это не похоже на кривую спецификацию RTMP и больше напоминает MFP.

   Сам по себе протокол модульный: обмен сертификатами, шифрование, синхронизация потоков выполнены в виде отдельного профиля. То, что происходит в Flash"е, остаётся в Flash"e. Для разработчиков сторонних решений, типа Cumulus , Flash оставался чёрным ящиком; как-то тихо и незаметно в апреле 2014-го вышел Adobe"s RTMFP Profile for Flash Communication .

2. Это UDP - значит, нет гарантии доставки

   Достаточно много протоколов реального времени используют UDP, для гарантии доставки добавляют сетевую контрольную сумму и избирательные проверки доставки. Проверяют только то, что обязательно должно прийти, а не всё в подряд. Для аудио/видео контроль доставки пакетов не имеет большего смысла. Размер окна (MTU) обычно максимален и статичен, что повышает вероятность возникновения ситуации проигрывания пустоты с последующим приёмом неактуальных данных при потере пакета.

3. RTMFP нам не нужен - у нас есть WebRTC

   WebRTC это не протокол, это браузерная технология - попытка интегрировать SIP с RTP стэком в браузер. Если скрестить в кучу RTP, SRTP, SCTP, RTCP, ZRTP, RTSP - получится RTMFP. Но в ряде случаев у подобных связок есть избыточность и проблемы с адресацией которых нет в RTMFP.

   У RTMFP есть и проброс через NAT, и контроль размера окна, и метаданные для потоков с контролем избыточности со стороны приложения, и forwarding/redirect сессий, и свой DHT.

   Сколько нужно инкапсулировать RTP-подобных протоколов, чтобы это всё реализовать?.. Думаю, где-то 4-5 штук.

   Текущая реализация протоколов вещания напоминает ситуацию:
   

   «Существует 6 протоколов, но у них всех есть фатальный недостаток, и мы разработаем ещё один...»
   Проходит год.
   «Существует 7 протоколов, и у них всех есть фатальный недостаток...»

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

RTMFP и модель OSI

Итак, давайте рассмотрим, какие уровни модели OSI покрывает RTMFP протокол.

• Физический и канальный

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

• Сетевой и транспортный

  Это IP и UDP multicast.
  Тут и Path MTU discovery и Congestion Control, уже в коробке, для каждого конкретного потока. Есть режим передачи данных с выборочной частотой проверкой доставки - проверяем раз в N пакетов. Все пакеты имеют временные метки для замера задержки при доставке. Встроенная кольцевая хэш-адресация конечных точек типа DHT.

• Уровень представления

  Для Flash это, конечно же, AMF3 и инкапсулированный RTMP, но передавать можно любые другие данные.

Безопасность в RTMFP

• Классический обмен ключами по Диффи-Хелману c статическими и эфемерными ключами.
• Cookies и сертификаты в сессиях, с возможностью цифровой подписи пакетов. Правда, по умолчанию неподписанные пакеты считаются валидными
• Для шифрования используется AES128, но можно использовать любой другой блочный алгоритм.
• HMAC-SHA256 или сетевые контрольные суммы.

Пользовательскую аутентификацию и авторизацию можно реализовать со стороны приложения. Вопрос фильтрации зловреда остаётся открытым.

Где функция-убийца?

Я думаю, все помнят провал трансляции последней презентации нового поп-телефона IPhone 6 Plus?

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

И все его увидят…

Варианты использования

1. Вещание контента в реальном времени

   Собственно, это предназначение самого протокола, и с этой задачей он справляется очень хорошо.
   Его можно использовать не только для передачи аудио/видео, но и как основной транспорт в Flash играх.

2. CDN

   Это Р2Р и для загрузки файла нужно лишь знать его имя, хэш и размер.
   Можно реализовать http2rtmfp шлюз - возможности открываются довольно занимательные.

3. Видео-конференции и чаты

   В пост-сноуденовскую эпоху RTMFP - доступный и защищённый Р2Р транспорт. Также основным преимуществом является возможность продолжить вещание при смене сетевого адреса устройства. WebRTC может отвалится при смене соты в 3G/4G. RTP стэк плохо подходит для вещания в подобной среде.

4. Передача данных реального времени внутри приватных сетей

   Основным преимуществом для данного варианта использования является возможность гибкой политики маршрутизации, минимизации задержек, опциональной проверки доставки пакетов и встроенные средства приоритезации трафика. Всё это можно настроить индивидуально для каждого конкретного приложения.

Как обстоят дела с существующими решениями на базе RTMFP?

Если кратко - дела обстоят очень плохо. На сегодняшний день из открытых реализаций есть разве что Cumulus. Развивается он очень вяло. Основан не на RFC, а на первых реверсах RTMFP Cirrus 1, так что совместимость с текущим Flash Profile Cirrus 2 довольно сомнительна. В нём реализована большая часть полезностей, в том числе организация избыточности в Р2Р и вещание между устройствами. Есть FMS, но он работает как FMS…

Буду рад конструктивным замечаниям.

В комментариях прошу указать аналоги RTMFP, если вам они известны.

Многие из нас слышали о таком термине, как «проприетарный». Им могли называть что угодно. Оборудование, драйверы, программы. Что же это за термин такой, и что он обозначает? Вообще, это слово пришло к нам из английского языка. В общем смысле «проприетарный» - это продукт, имеющий лицензию. А подробнее значение этого термина мы разберем чуть ниже.

Термин «проприетарный». Значение

Слово «проприетарный» происходит от английского слова proprietary, что означает «личное» или «патентованное». Этот термин используется для обозначения чего-либо «несвободного». Будь то ПО или оборудование. Это значит, что к примеру, имеет некую лицензию. Естественно, за то, чтобы пользоваться лицензионным программным обеспечением, придется платить деньги. Причем в некоторых случаях — деньги немалые.

В случае с оборудованием значение слова «проприетарный» несколько меняется. Этим термином обычно обозначаются некоторые уникальные части оборудования, характеризующие определенного производителя. К примеру, у смартфонов компании Apple присутствуют уникальные и патентованные разъемы для зарядки устройства.

Проприетарное программное обеспечение (ПО)

К проприетарному ПО относятся как драйверы для некоторых устройств, так и В случае с драйверами все понятно, - производитель устройства осуществляет поддержку работоспособности всех функций устройства посредством программного обеспечения с закрытым исходным кодом. В принципе, это правильно. Неизвестно каких бед могли натворить наши всякие любители покопаться в компьютерном «железе» и программах, если бы разработчики открыли исходный код. К тому же ПО для оборудования обычно бесплатно. Стоит приобрести ту же видеокарту, и техническая поддержка в виде драйверов будет доступна постоянно до тех пор, пока сохраняется ее актуальность.

С проприетарным программным обеспечением не все так просто. Ярким представителем компаний, использующих проприетарные лицензии, является компания Adobe с ее «вечным» Photoshop. За пользование продукцией Adobe придется платить серьезные деньги. Да и Microsoft недалеко ушли. За использование фирменной ОС Windows 10, к примеру, придется каждый год отчислять солидную сумму. Сейчас это обычная практика среди крупных производителей программного обеспечения.

Плюсы и минусы проприетарного ПО

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

• Постоянная техническая поддержка продукта.
• Более стабильная работа по сравнению со свободным ПО.
• Гарантированное отсутствие вредоносных объектов (вирусов).
• Автоматические обновления ПО.
• Качественное использование всех возможностей оборудования.

Все это были плюсы проприетарного ПО. Теперь перейдем к минусам:

• Солидная сумма оплаты за лицензию.
• Проприетарные протоколы работы устройства.
• Зависимость от разработчика.
• Невозможность изменить исходный код.
• Ограничение на распространение ПО.
• Ограничение на модификацию ПО.

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

Проприетарные драйверы

Проприетарными также бывают и драйверы устройств. В этом случае "проприетарный" означает, что они поставляются от производителя с закрытым исходным кодом. Внесение каких-либо изменений в их структуру невозможно. Обычно такие драйверы актуальны в использующих открытое ПО. Особенно этим грешат свободные «линуксоподобные» системы. Они-то обычно и используют проприетарные драйвера. Ubuntu, к примеру, повально использует и свободные, и «закрытые».

Такие драйверы под Ubuntu отличаются большей стабильностью, чем свободные. Что и неудивительно, ведь в их исходном коде никто не «ковырялся». Но, в отличие от свободных драйверов, пользователям «закрытого» ПО приходится довольно долго ждать свежей обновленной версии. Тут уж приходится выбирать: новизна или стабильность.

Проприетарное оборудование

В случае с оборудованием проприетарный — это не имеющий аналогов. Обычно таким словом обозначают какую-нибудь «фишку» производителя. К примеру, уникальный разъем. Кроме особенной формы, такие разъемы поддерживают и определенные протоколы, к примеру, передачи данных или управления электропитанием.

Проприетарными разъемами для своих девайсов «грешит» компания Apple. У них все подряд патентованное и «закрытое». Если вы вздумаете подключить, к примеру, к iPhone нелицензионное зарядное устройство — ваш девайс может даже сгореть. Такое оборудование обычно производится только с целью содрать с пользователей больше денег. Очевидных плюсов в использовании проприетарных разъемов не наблюдается. На скорость передачи данных или скорость зарядки девайса это никак не влияет.

Заключение

Теперь мы вполне можем понять, что же называют умным словом «проприетарный». Это продукт, который имеет лицензию и конкретного владельца. Использование такого продукта без оплаты невозможно. Кроме того, такие продукты (программное обеспечение и драйверы) имеют закрытый исходный код, и внести изменения в их структуру не получится никакими средствами.

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