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

Протокол групповой коммуникации

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

Общая схема групповых протоколов обмена мгновенными сообщениями, показывающая интерфейсы взаимодействующего пользователя (слева) и сетевые интерфейсы приложения (справа), выглядит следующим образом:

Состав группы

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

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

Протокол обмена сообщениями

Для обеспечения точной модели безопасности, мы определяем протокол обмена мгновенными сообщениями в группе как набор алгоритмов:

• $inline$sndс$inline$: Отправляет шифротекст, назначенный центральному серверу.
• $inline$rcv( c )$inline$: Получает зашифрованный текст от центрального сервера и обрабатывает его, вызывая один из алгоритмов доставки и, возможно, алгоритм $inline$snd$inline$.
• $inline$SndM( gr,m )id$inline$: отправка сообщения $inline$m$inline$ в группу $inline$gr$inline$.
• $inline$Add( gr,V )id$inline$: добавление пользователя $inline$V$inline$ в группу $inline$gr$inline$.
• $inline$Leave( gr )id$inline$: выход пользователя $inline$U$inline$ из группы $inline$gr$inline$.
• $inline$Rmv( gr,V )id$inline$: удаление пользователя $inline$V$inline$ из группы $inline$gr$inline$.
• $inline$DelivM( id,gr,V,m )$inline$: Сохраняет $inline$m$inline$ с идентификатором $inline$id$inline$ от отправителя $inline$V$inline$ в группе $inline$gr$inline$ для отображения его пользователю $inline$U$inline$.
• $inline$ModG( id,gr )$inline$: Обновляет группу после удаленного обновления с идентификатором $inline$id$inline$.
• $inline$Ackid$inline$: Подтверждает, что действие с идентификатором $inline$id$inline$ было доставлено и обработано всеми получателями.

Первые два алгоритма обеспечивают доступ приложения к сети (сетевой интерфейс). Тем самым $inline$snd$inline$ отправляет шифротексты, а $inline$rcv$inline$ принимает и обрабатывает шифротексты. Последние семь алгоритмов обрабатывают действия пользователя или доставляют удаленные действия других пользователей в графический интерфейс пользователя.

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

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

Модель угроз

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

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

Сетевой атакующий. Этот злоумышленник имеет полный контроль над каналом связи, может получать доступ и изменять весь незащищенный трафик.

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

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

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

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

Цели безопасности

Безопасность и надежность в динамическом групповом общении можно разделить на три аспекта: 1) конфиденциальность содержания разговоров, 2) целостность разговора и 3) конфиденциальность управления группой.

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

• Сквозная конфиденциальность. Ни одно сообщение $inline$m$inline$ отправленное участником в целевую группу $inline$gr$inline$ посредством $inline$SndM( gr,m )$inline$ не может быть получено злоумышленником.
• Совершенная прямая секретность. При утечке состояния сеанса пользователя U сохраняется конфиденциальность прошлых сообщений $inline$U$inline$ в группе $inline$gr$inline$.

Соответственно, мы определяем одну групповую передачу как последовательность действий, после которой все члены группы выводят шифротексты через $inline$snd$inline$, а все члены группы получают назначенные им шифротексты через $inline$rcv$inline$.

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

• Аутентификация сообщений. Если сообщение $inline$m$inline$ доставлено посредством $inline$DelivM( id,gr,U,m )$inline$, тогда верно то, что это сообщение было отправлено пользователем $inline$U$inline$ посредством вызова $inline$SndM( gr,m )$inline$.
• Отсутствие создания. Если сообщение $inline$m$inline$ было доставлено пользователем в группу посредством $inline$DelivM( id,gr,V,m )$inline$ с отправителем $inline$V$inline$, тогда $inline$V$inline$ должен быть в комнате.

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

• Отсутствие дублирования. Для каждого действия $inline$Actn( gr )id$inline$ инициированного пользователем $inline$U$inline$ для группы результат $inline$Deliv( id,gr )$inline$ должен вызываться только один раз для каждого члена группы.
• Отслеживаемая доставка. Если доставка действия $inline$Actn( gr )id$inline$ пользователя $inline$U$inline$ подтвердилась одним пользователем посредством вызова $inline$Ackid$inline$, тогда соответствующий алгоритм $inline$Deliv( id,gr )$inline$ должен вызваться всеми участниками.

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

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

• Аддитивная закрытость. Если один из участников группы модифицирует набор участников тогда администратор вызывает $inline$Add( gr,V )$inline$, добавляя нового участника в группу.
• Субтрактивная закрытость. Если пользователь один из участников группы модифицирует набор участников тогда администратор вызывает $inline$Rmv( gr,V )$inline$, удаляя участника из группы, или участник $inline$V$inline$ вызывает $inline$Leave( gr )$inline$ для выхода из группы.

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

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

Алгоритмы групповой криптографии

Методы формирования составных ключей на сегодня представляют собой разнообразные расширения фундаментального алгоритма, предложенного Диффи и Хеллманом в 1976. Оригинальный протокол предлагает метод установления общего ключа двумя взаимодействующими сторонами, групповые же его расширения предлагают обобщение данной схемы до случая N взаимодействующих сторон. Как и для оригинального протокола, сложность раскрытия устанавливаемого группового ключа основывается на сложности нахождения дискретного логарифма, поэтому если двусторонний протокол считается защищенным, то же самое можно утверждать для всех его расширений.

Протокол GDH.3 был представлен вместе с протоколами GDH.1 и GDH.2. Это особенно подходит для сред, которые требуют минимальных вычислительных мощностей от каждого члена группы. Протокол развивается в четыре этапа, и здесь я расскажу об оригинальном алгоритме GDH.3 и об аналоге, представленном в материале Design, Analysis and Perfomance Evaluation of Group Key Establishment in Wireless Sensor Networks. Протокол Диффи-Хеллмана для групп с эллиптической кривой позволяет использовать ключи намного меньшего размера, чем обычные криптосистемы на основе дискретного логарифма (160-битный ключ в криптосистеме с эллиптической кривой обеспечивает эквивалентную защиту с 1024-битным ключом в обычной криптосистеме).

GDH.3 на эллиптической кривой

Предположим, что каждый член группы согласился на использование тех же параметров эллиптической кривой. Количество участников $inline$n$inline$ и мы будем обозначать $inline$M_i$inline$ каждого $inline$i$inline$-го участника.

1. На первом этапе каждый член группы $inline$M_i$inline$ генерирует случайное секретное значение $inline$k_i$inline$. Участник $inline$M_1$inline$ выбирает точку $inline$P$inline$ и отправляет $inline$M_2$inline$ точку $inline$Q_1 = k_1P$inline$. Затем $inline$M_2$inline$ отправляет $inline$M_3$inline$ точку $inline$Q_2 = k_1k_2P$inline$ и так далее, пока протокол не достигает члена $inline$M_{n1}$inline$. Обратите внимание, что протокол должен пройти каждого участника только один раз.
2. Член группы $inline$M_{n1}$inline$ вычисляет точку $inline$Q_{n1} = k_1k_2 ... k_{n 1}P$inline$ и отправляет ее всем членам.
3. На третьем этапе каждый член группы $inline$M_i, i [1, n-1]$inline$ вычисляет точку $inline$G_i = k^{i1} Q_{n 1}$inline$ и отправляет его последнему члену группы $inline$M_n$inline$.
4. $inline$M_n$inline$ вычисляет значения $inline$k_nG_i$inline$ и отправляет их соответствующим членам $inline$M_i$inline$

После этих этапов каждый член группы $inline$M_i$inline$ может вычислить ключ группы $inline$Q_n = k_1k_2 ... k_nP$inline$ путем умножения значения $inline$k_nG_i$inline$ на его секретное число $inline$k_i$inline$. Несмотря на его эффективность, недостатком протокола GDH.3 является то, что он не обеспечивает симметричность операции, потому что все участники протокола не выполняют одно и то же количество операций. Если количество участников велико, то усилия $inline$M_n$inline$ могут быть разрушительными для него.

Аналог GDH.3 на эллиптической кривой

Мы придерживаемся распределенного подхода, который не требует обмена сообщениями многие-ко-многим, как в случае второго и третьего этапов протокола GDH.3, и не полагается на какой-либо глобальный порядок устройств. Наш протокол основан на наблюдении, что на первом этапе протокола GDH.3 член группы $inline$M_n$inline$ может вычислить общий ключ группы $inline$Qn$inline$ путем получения точки $inline$Q_{n1}$inline$ из $inline$M_{n1}$inline$ и умножения его на его секретное значение $inline$k_n$inline$. Кроме того, точки $inline$Q_i = k_1k_2 ... k_iP$inline$, которые генерируются каждым членом группы $inline$M_i$inline$ могут быть использованы в качестве своих открытых ключей, в то время как их закрытые ключи являются значениями $inline$k_i$inline$. Используя это наблюдение, наш протокол полностью избегает третий и четвертый этапы протокола GDH.3.

1. На первом этапе каждый член группы $inline$M_i$inline$ генерирует случайное секретное значение $inline$k_i$inline$. Участник $inline$M_1$inline$ выбирает точку $inline$P$inline$ и отправляет $inline$M_2$inline$ точку $inline$Q_1 = k_1P$inline$ который является его открытым ключом и может использоваться $inline$M_2$inline$. Затем $inline$M_2$inline$ отправляет $inline$M_3$inline$ точку $inline$Q_2 = k_1k_2P$inline$ (которая является открытым ключом $inline$M_2$inline$) и так далее пока протокол не достигает члена $inline$M_n$inline$. Точка $inline$Q_n$inline$ является общим секретным ключом и рассчитывается участником $inline$M_n$inline$.
2. Теперь $inline$M_n$inline$ шифрует $inline$Q_n$inline$ с помощью открытого ключа $inline$M_{n-1}$inline$$inline$Q_{n-1}$inline$ и отправляет его в $inline$M_{n-1}$inline$. $inline$M_{n-1}$inline$ может расшифровать сообщение с помощью своего закрытого ключа $inline$k_{n-1}$inline$. Получив секретное значение $inline$Q_n$inline$, шифрует его открытым ключом $inline$M_{n-2}$inline$ и отправляет результат $inline$M_{n-2}$inline$. Такая же операция будет выполнена $inline$M_{n-2}$inline$ и так далее, пока протокол не достигнет члена $inline$M_1$inline$.

В частности, мы используем распределенный алгоритм последовательного обхода, который посещает каждого участника группы для создания общего секретного ключа (начиная с $inline$M_1$inline$ и достигая $inline$M_n$inline$). Это похоже на первую стадию GDH.3, не обязательно требует прямого общения между всеми членами группы и по-прежнему гарантирует что каждый участник посещается только один раз. Когда обход закончен и все участники посещаются, протокол достигает члена $inline$M_n$inline$, который вычисляет точку $inline$Q_n$inline$, что является общим секретным ключом. Наконец, для того, чтобы $inline$M_n$inline$ сообщил общий секретный ключ всем участникам группы, повторяет этот обход, но в обратном порядке. $inline$M_n$inline$ теперь шифрует $inline$Q_n$inline$ открытым ключом $inline$M_{n-1}$inline$$inline$Q_{n-1}$inline$ и отправляет его участнику $inline$M_{n 1}$inline$. $inline$M_{n-1}$inline$ может расшифровать сообщение с помощью своего закрытого ключа $inline$k_{n-1}$inline$, получить секретное значение $inline$Q_n$inline$, зашифровать его открытым ключом $inline$M_{n-2}$inline$ и отправить $inline$M_{n2}$inline$. Это же проделает $inline$M_{n-2}$inline$ и так далее, пока протокол не достигнет члена $inline$M_1$inline$.

Заключение

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

Источники

• Paul Rsler, Christian Mainka, Jrg Schwenk / More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema
• Ioannis Chatzigiannakis, Elisavet Konstantinou, Vasiliki Liagkou, Paul Spirakis / Design, Analysis and Performance Evaluation of Group Key Establishment in Wireless Sensor Networks

Вот небольшое известие, которое вы могли пропустить, восстанавливая свою жизнь после начала кризиса COVID: из-за того, что вирус перемешал всем карты, Google пропустила выпуск Chrome версии 82. Да кого это волнует?, спросите вы. Ну, хотя бы пользователей FTP, или File Transfer Protocol. Во время пандемии Google отложила свои планы по убийству FTP, и теперь, когда буря немного успокоилась, Google недавно объявила о том, что возвращается к мысли об убийстве в Chrome версии 86, которая снова сократит поддержку протокола, и окончательно убьёт его в Chrome 88. (Mozilla объявила о похожих планах на Firefox, утверждая, что дело в безопасности и возрасте поддерживающего протокол кода.) Это один из старейших протоколов, который поддерживает мейнстримный Интернет (в следующем году ему исполнится 50 лет), но эти популярные приложения хотят оставить его в прошлом. Сегодня мы поговорим об истории FTP, сетевого протокола, который продержался дольше, чем почти все остальные.

1971

Именно в этом году родившийся в Индии студент магистратуры MIT Абхай Бхушнан впервые разработал File Transfer Protocol. FTP, появившийся спустя два года после telnet, стал одним из первых примеров работающего пакета приложений для системы, которая в дальнейшем стала известна как ARPANET. Он обогнал электронную почту, Usenet и даже стек TCP/IP. Как и telnet, FTP по-прежнему используется, хоть и ограниченно. Однако в современном Интернете он потерял значимость, в основном из-за проблем с безопасностью, а его место занимают альтернативные протоколы с шифрованием в случае FTP это SFTP, протокол передачи файлов, работающий поверх протокола Secure Shell (SSH), по большей мере заменившего telnet.


FTP настолько стар, что появился раньше электронной почты, а в начале он сам играл роль email-клиента. Наверно, неудивительно, что среди множества программ прикладного уровня, созданных для раннего ARPANET именно FTP выделился и проложил себе дорогу в мир современных технологий.

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

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


Телетайпный терминал эпохи ARPANET.

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

В своём RFC Бхушан пишет:

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

В интервью подкасту Mapping the Journey Бхушан сообщил, что приступил к разработке протокола из-за очевидной потребности в приложениях для зарождающейся системы ARPANET, в том числе из-за потребности в электронной почте и FTP. Эти первые приложения стали фундаментальными строительными блоками современного Интернета и за последующие десятилетия сильно усовершенствовались.

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

Мы спросили: Почему бы не добавить в FTP две команды под названием mail и mail file? Команда mail будет использоваться для обычных текстовых сообщений, а mail file для вложений писем, которые существуют и сегодня, говорит он в интервью.

Разумеется, Бхушан был не единственным, кто принял участие в разработке этого фундаментального раннего протокола, ведь после выпуска из вуза он получил должность в Xerox. Созданный им протокол продолжил своё развитие без него, получив в 1970-х и 1980-х серию обновлений в виде RFC; в том числе примерно в 1980 году появилась его реализация, позволявшая обеспечивать поддержку спецификации TCP/IP.

Хотя со временем появлялись незначительные обновления, чтобы протокол успевал за временем и мог поддерживать новые технологии, версия, которую мы используем сегодня, была выпущена в 1985 году, когда Джон Постел и Джойс К. Рейнольдс разработали RFC 959 обновление предыдущих протоколов, лежащих в основе современного ПО для работы с FTP. (Постел и Рейнольдс, среди прочего, примерно в то же время работали над системой доменных имён (DNS).) Хотя в документе эта версия описывается как предназначенная для исправления незначительных ошибок документации, улучшения объяснения некоторых функций протокола и добавления новых вспомогательных команд, стандартной стала именно она.

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

Во многих смыслах, из-за столь раннего появления в истории Интернета FTP повлиял на структуру множества последующих протоколов. Можно сравнить его с чем-то, что часто менялось и совершенствовалось в течение нескольких десятков лет, допустим, с баскетбольными кроссовками. Да, Converse All-Stars это хорошая обувь, и в нужных условиях с честью она послужит и сегодня, но с гораздо большей вероятностью успеха добьётся какая-нибудь модель от Nike, вероятно, под брендом Air Jordan.

File Transfer Protocol это Converse All-Star Интернета. Он передавал файлы ещё до того, как это стало круто, и по-прежнему сохраняет часть своей притягательности.

Никто не зарабатывал на Интернете. Скорее наоборот, на него тратили кучу денег. Мы смело сражались в этой битве и знали, что у него был потенциал. Но если кто-то скажет вам, что он знал, что будет дальше, то это ложь. Ведь я видел всё сам своими глазами.

Так Алан Эмтедж, создатель Archie, считающегося первым поисковым движком Интернета, рассказывал Internet Hall of Fame почему его изобретение, позволявшее пользователям искать на анонимных FTP-серверах файлы, не сделало его богатым. Если вкратце, то Интернет тогда был некоммерческим, а аспирант и работник техподдержки монреальского Университета Макгилла Эмтедж без разрешения использовал сеть вуза для работы Archie. Но именно так и лучше всего было поступить. Как гласит старая пословица, лучше просить прощения, чем разрешения. (Как и Бхушан, Эмтедж был иммигрантом, он родился и вырос на Барбадосе и приехал в Канаду, став студентом благодаря своим достижениям.)


Скриншот WS_FTP FTP-клиента для Windows, который был довольно популярен в 90-х.

Почему FTP может быть последней связью с нашим прошлым, до сих пор используемым онлайн

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

Крупные технологические компании наподобие Hewlett-Packard, Mozilla, Intel и Logitech десятками лет использовали эти сайты для распространения среди конечных пользователей документации и драйверов. И по большей части эти сайты по-прежнему находятся онлайн, храня контент, который находился там долгие годы.

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


Пример того, как выглядит FTP в современном веб-браузере (ftp.logitech.com).

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

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

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

В том интервью Скотт заметил, что долгая жизнь таких FTP-сайтов на самом деле больше исключение, чем правило.

Невероятно странно, что FTP-сайты накопили инерцию, позволившую им продолжать работать в течение 15-20 лет, сказал он.

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

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

Цитата из статьи 1997 года в Network World; в ней говорится, что FTP, несмотря на свою неуклюжесть, по-прежнему остаётся хорошим вариантом для надомных работников и корпоративных пользователей Интернета. Хотя автор статьи был заинтересованным лицом (Роджер Грин являлся президентом компании Ipswitch, крупного изготовителя программ для FTP), его аргументы, тем не менее, соответствовали духу эпохи. Протокол был отличным способом передачи больших файлов через сети и сохранения их на сервере. Проблема в том, что FTP, несмотря на своё постепенное совершенствование, будет вытеснен гораздо более изощрёнными альтернативами, как протоколами (BitTorrent, SFTP, rsync, git, даже современными вариантами HTTP), так и облачными системами наподобие Dropbox или Amazon Web Services.

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

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


Panics Transmit современный пример FTP-клиента. Множество современных клиентов поддерживает широкий набор протоколов, а не только старый добрый FTP.

Позже я выпустился и FTP-сервер отключился навсегда; к тому же всё равно возникли более эффективные варианты его замены, например, BitTorrent, и более законные, типа Spotify и Tidal.

Так же, как и обмен файлами, сильно эволюционировавший спустя 15 лет, изменились и мы сами. Мы узнали о более эффективных и безопасных способах удалённого управления файлами. В 2004 году многие считали, что лучше всего управлять веб-сервером при помощи FTP. Сегодня, когда сервисы типа Git обеспечивают возможность эффективного контроля версий, такой способ кажется рискованным и неэффективным.

Даже если популярные браузеры в ближайшие месяцы избавятся от поддержки FTP, это не значит, что у нас совершенно исчезнут другие способы работы с этим протоколом. Специализированное ПО, разумеется, по-прежнему будет существовать. Но, что более важно, для замены устаревшего протокола FTP есть веские причины.

В отличие от ситуации с IRC (когда у протокола отобрали популярность коммерческие инструменты) и Gopher (рост которого погубил внезапный переход на коммерческую модель), FTP уходит из веб-браузеров потому, что его возраст подчёркивает отсутствие инфраструктуры безопасности.

Самые распространённые способы его использования, например, для организации публично доступных анонимных FTP-серверов, по сути, потеряли свою популярность. А в своей основной нише он в конечном итоге был заменён более защищёнными и современными версиями, например SFTP.

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

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

---

На правах рекламы

VDS с посуточной оплатой для любых целей это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

Здравствуйте, меня зовут Валентин, и я задолбался. Нет-нет, вы всё ещё на Хабре.

Все технологии телефонии ужасны.
Большинство технологий разработки IETF ужасны. Может, не ужасны-ужасны, как ISO
Когда они смешиваются ну вы в курсе. Или ещё нет? Получается SIP.

Это пост ворчания, техническая суть которого может быть полезна паре сотен человек. Но, to grumble is human.

Начнём с синтаксиса

HTTP заголовок видели все. Ну, большинство. Кто не видел может посмотреть на заголовок почтового письма (email). Принципы взяты оттуда, НО...

Я буду брать примеры из стандартных RFC, чтобы не влияла местная специфика. Типичное сообщение выглядит в таком стиле:

INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
a=sendrecv
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Alice инициирует звонок к Bob (полные адреса указаны в виде user@domain), предлагая аудио в кодеке PCMU (G.711u) и сообщая свои адреса (хост: порт) для сигнализации и для медии.

Пойдём вглубь

Параметры, параметры и параметры

У нас есть address parameters, URI parameters и user parameters. Не то чтобы это был необходимый набор для работы, но если начал, становится трудно остановиться Все три отделяются точками с запятой, ограничения на синтаксис у всех немного разные. Смотрите не перепутайте. Кстати, чем отличается адрес от URI, тоже не каждому сразу получится объяснить. Адрес (определение формально не встречается в спеках, но постоянно используется на практике) это содержимое всяких From/To/Contact/Route (один элемент, где их несколько), URI с параметрами и (возможно) именем Ну поехали:

To: sip:bob@example.com
тут всё просто схема, домен и юзер.

To: sip:bob@example.com;xyz=123
xyz=123 параметр адреса. Но: если URI должен присутствовать сам по себе, как в первой строке запроса:

INVITE sip:bob@example.com;xyz=123
то xyz=123 будет уже параметром URI.

To: <sip:bob@example.com>;xyz=123
To: "Bob" <sip:bob@example.com>;xyz=123
xyz=123 параметр адреса.

To: <sip:bob@example.com;xyz=123>;xyz=456
xyz=123 параметр URI.
xyz=456 параметр адреса.

To: sip:bob;rn=alice@example.com;xyz=987
Так нельзя. Странно, да? Хотя если URI там, где нужен именно URI (в request line), то можно:
INVITE sip:bob;rn=alice@example.com;xyz=987 SIP/2.0

Надо заключить в угловые скобки:

To: <sip:bob;rn=alice@example.com;xyz=987>;xyz=123
rn=alice параметр юзера.
xyz=987 параметр URI.
xyz=123 параметр адреса.

Кстати, во всех допускаются символы за пределами очевидного набора типа [A-Za-z0-9] и ещё некоторого набора неожиданно допущенных, но по-разному. В user и в URI надо квотить недопустимое их кодами через %XX, а в адресе через quoted string, и никак иначе. Поэтому параметр со значением a%\b будет передан:

To: <sip:bob;xyz=a%25%5Cb@example.com;xyz=a%25%5Cb>;xyz="a%\\b"

В спеке на синтаксис, обобщение для параметра URI зовётся other-param, а параметра адреса generic-param. Смотрите не перепутайте, правила для них заметно разные. Кстати, user parameters это другая спека (точнее, произведение двух RFC4694 + RFC3398).

Что может быть значением параметра URI? Что угодно, только надо его единообразно заквотить (через %XX), дальше это набор октетов (UTF-8, если в SIP). Примеры были выше.

Что может быть значением параметра адреса? token, quoted string или host. Кстати, token это не token в смысле грамматического разбора. Это особый token, которого лично зовут token. Но при этом с маленькой буквы, потому что он самый скромный token.

To: <sip:bob@example.com>;xyz=127.0.0.1

127.0.0.1 это host или token? Допустимы оба. Должен ли я считать, что это host?

To: <sip:bob@example.com>;xyz=[fe80::1]
To: <sip:bob@example.com>;xyz="[fe80::1]"

Значения одинаковы. Но в первом случае это host подтипа IPv6reference,
во втором quoted string. Если я прокси и передаю параметр через себя, я должен сохранить, чем он был восстановление по содержимому не поможет.

Кстати, к предыдущему примеру:

To: <sip:bob@example.com>;xyz="127.0.0.1"

это не host и не token. Но если объекту типа address скажут назначить параметр со значением "127.0.0.1" какой тип выбрать? Ах ну да, такая установка уже должна указывать тип...

Вместе с тем, что если это token, то регистр букв не имеет значение, а если quoted-string, то имеет; а если host, то снова не имеет для адекватности одновременно обработки и сохранения исходного значения (про регистр подробнее ниже) я должен хранить:

1) Исходную форму как октетную или unicode строку для точного воспроизведения;
2) Приведённую форму для сравнения;
3) Признак, какого типа был параметр на входе (насколько это вообще восстановимо, не зная по названию параметра, чем он должен быть хотя годится обобщение типа любой host кроме IPv6reference может храниться как token там ещё есть несколько подобных тонкостей).

Но в To допускается только один адрес. А в Contact несколько. Есть некоторые другие поля заголовка, где тоже можно, но пока пусть например будет слонёнок Contact:

Contact: sip:alice@example.com, sip:bob@example.com

Да, можно.

Contact: <sip:alice@example.com>, sip:bob@example.com, <sip:mallory@example.com>

Тоже можно.

Contact: sip:alice,bob@example.com

Нельзя. URL с запятой должен быть заключён в <>. Распарситься не должно: после запятой нет схемы URL.

Contact: sip:alice, bob bob bob <bob@example.com>

Уже можно. Хотя это надо минимум три синяка от граблей, чтобы сразу видеть, что alice уже не юзер, а домен.

Contact: sip:alice,bob@example.com, sip:mallory@example.com

Нельзя. URL с запятой внутри поля заголовка конструкции адрес должен быть заключён в <>.

Contact: <sip:alice,bob@example.com>, sip:mallory@example.com

Уже можно. При этом второй адрес заключать не обязательно.

Хорошо, а это что тогда?

Contact: sip:alice,sip:bob@example.com

Это два адреса в контактах: sip:alice (alice это хост, user отсутствует целиком) и sip:bob@example.com. Но:

Contact: <sip:alice,sip:bob@example.com>

Это один адрес с user=alice,sip и паролем bob. Да-да, запятая в user возможна и её можно не квотить.

Это я ещё не вспоминал, что впереди может быть display-name, а позади адресные параметры:

Contact: sip user <sip:alice>, "The Bob" <sip:bob@example.com>;
foo="The Bob, Almighty and Superb <sip:bob>", <tel:alice;xyz=987>

И снова здравствуйте, меня зовут Валентин. (Здравствуй, Валентин ответил нестройный хор.) Я сделал реализацию разбора SIP регулярными выражениями, и нет, я не стыжусь этого. У меня нет проблем, которые нельзя так решить: в грамматике нет рекурсии (максимум есть списки), и, к счастью, это единственное, что там хорошее. Если бы была рекурсия разбор был бы ужасен-ужасен. А так, он просто ужасен:

>>> len(SipSyntax.re_addr)
2847


Нет, мне не страшно. Потому что эти выражения формируются из отдельных частей:

re_addr = "(?:%s|%s)%s?" % (re_name_addr, re_addr_spec_short, re_gen_params_wsc)

и на каждом этапе я могу проверить качество каждого выражения и соответствие правилам комбинирования. Кстати, некоторые мелочи, которые никогда за почти 20 лет существования продуктового стека не понадобились (типа возможности absoluteURI), тут не реализованы. С ними было бы ещё в полтора раза больше, наверно.

Но почему таки регулярные выражения? спросит отдельный робкий голос. Ответ: а потому что Python.

Я сравниваю один и тот же разбор URI на Python через regexps, Java через regexps и Java через пропуск по классам символов. Сравнение эффективности на одной и той же железке (Ryzen5):

CPython + regexps        - 14K/secPyPy    + regexps        - 130K/secJava    + regexps        - 270K/secJava    + symbol classes - 1800K/secPyPy    + symbol classes - 3K/sec

Всё потому, что в Python движок регулярных выражений написан на C, а обходить его означает выходить на уровень интерпретатора, который страшно медленный. Предкомпилированные (на этапе загрузки модулей парсинга) выражения превращаются в аккуратные таблички в памяти это хуже, чем выхлоп какого-нибудь re2c, но по ним бегает неплохо оптимизированный код матчинга. В Java вроде JIT, но движок регулярных выражений написан на самой Java, и JIT ему не очень помогает, когда логика состоит из сплошных переходов с лукапами по табличкам, которые этим JITом не перерабатываются. На чём-то напрямую компилируемом цифры могут быть ещё вкуснее нет, я не буду впадать в этот флейм. PyPy заметно помогает, но есть порог, за которым кончается и его умение (а цифры говорят, что >90% накладных расходов CPython это работа со структурами Python, а не собственно управление памятью, парсинг и т.п.)

Что такое лукап по классам символов это в таком духе:

        while (pos < limit && (b = source[pos]) >= 0 &&                SipSyntax.userinfo_allowed[b] != 0)        {            ++pos;        }

табличка userinfo_allowed тщательно выверена руками и подкреплена юнит-тестом.

(Меня удивила цифра PyPy, но, может, это я оказался такой криворукий. Но на CPython я даже не пытаюсь это делать страашно. Ладно, может, попробуем, как сады зацветут.)

А ещё есть проблема '#'. По RFC, такое не разрешено:

INVITE sip:123#456@example.com SIP/2.0
From: <sip:123#789@example.com>; tag=from1

но не только лишь все (tm), начиная с Cisco, это игнорируют. Поэтому почти сколько существует наш продукт, почти столько и существует параметр получателя url_hash_safe, который говорит рисовать #, а не %23 (а %23 многие из них не понимают). Но некоторые наоборот, не понимают, если ставить '#'. Поэтому нужна регуляция по конкретному ремотному участнику определять, кому таторы, а кому ляторы. Последний раз я подсказывал техподдержке включить этот параметр прошлой осенью. Наверно, эта проблема будет жить вечно. Ах да, '*' ещё один частый символ в этих последовательностях разрешён явно и проблемы не вызывает. Неаккуратненько-с.

В RFC3261 есть роскошное примечание:

The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.

Спасибо, дорогая партия, за наше счастливое детство. У меня вопрос: а зачем вообще было разрешать вариант без угловых скобок? Ах да, забыл: в Route и Record-Route угловые скобки обязательны. В From, To, Contact нет. Картина Репина.

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

Если упоминается Java, кто-то обязательно спросит почему не ANTLR?

Я пробовал применить ANTLR. Нет, конечно, это можно. Забитый молотком шуруп держится лучше, чем вкрученный отвёрткой гвоздь. В linphone его применяют. Но уже там видны недочёты.

Ему нельзя снаружи управлять контекстом для лексического анализатора, а это критично. Есть несколько разных стартовых контекстов: как минимум: первая строка сообщения, URI, адрес, ряд специфических заголовков со своими правилами (Call-Id, Authorization...)

Можно было бы справиться с semantic rules на месте, но:

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

Часто однозначного решения нет. Начало адреса может присутствовать или схема с ':' (включать ли двоеточие в токен лексера?), или display-name как последовательность token (это не тот токен, это другой токен, который token в грамматике SIP). После схемы в SIP-URI или хост, или username, и различить их можно только по тому, что раньше встретится после него (может, заметно после него) '@', ';', '?' или EOI. Не так предсказал откат назад на другую гипотезу.

Начальных контекстов как минимум: начало адреса (одиночного или множественного поля заголовка типа From, To, Contact, Route, Record-Route...); начало URI (например, в первой строке SIP запроса). Есть ещё несколько специфических контекстов для авторизационных заголовков, например там целые URI могут находиться в кавычках. В результате, получается сплошное дублирование. Грамматики лексеров не могут включать другие грамматики лексеров (почему?) В результате чтобы избежать копипастинга надо генерировать грамматики отдельным макропроцессором. Ну спасибо...

Альтернативно, можно было бы на уровне лексера определить каждый символ, а выше собирать их уже в грамматические конструкции. Исключение даётся только для quoted-string (и то за пределами авторизационных заголовков). Но производительность падает на порядки, реализация на Java становится тормознее реализации на Python+regexps.

Поэтому доступные реализации невозможно читать без ящика водки. Виски не подойдёт: он для добавления положительных эмоций, а не гашения отрицательных. Если бы не требование менять контексты лексера из самого лексера, было бы ещё подъёмно (LL() превратился бы в цивилизованный PEG), но не как сейчас.

Вместо регулярных выражений можно использовать классы символов. И на компилируемом языке это быстрее (ускорение раз в 5 я получаю без оптимизационных ухищрений). Но не на Python: его движок регулярных выражений на C, а поиск по строке будет чудовищно дорог.

В целом, мир грамматики IETF выглядит сущностью, принципиально противоположной тому, что рекламируется, например, в Dragon Book. Возможно, для него нужна своя теория, которая будет заметно отличаться от знаменитых LL(k), LR(k) и прочих. Но я такого не видел.

И ложка мёда:

А знаете, что хорошо по сравнению с RFC822, например? Границы строк чётко определены. Кошмариков типа "\\\r\n", которое неверно разбирали 99% почтовых парсеров, уже нет. Поэтому я могу (и даже обязан) сначала опознать границы строк, по ним полей заголовка, и тогда каждый подавать на разбор уже по своему вкусу (а скорее всего вообще не подавать те, что не нужно).

За 17 лет (1982->1999) IETF кое-чему научился. Жаль, что это так медленно происходит.

Морфология

У нас в каждом сообщении нужно посылать From и To. На INVITE выше приходит ответ, например:

SIP/2.0 100 TryingVia: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9    ;received=192.0.2.101From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76slTo: Bob <sip:bob@biloxi.example.com>Call-ID: 3848276298220188511@atlanta.example.comCSeq: 1 INVITEContact: <sip:bob@client.biloxi.example.com;transport=tcp>Content-Length: 0

Реально они нужны только в одном виде сообщений в начальном для установления диалога (или в отдельной транзакции). Дальше их можно тупо выкидывать, от этого ничего не поменяется: на них ничего не завязывается и никто не парсит, хотя пропускать их запрещено. Матчинг ответов на транзакции происходит по h_Via.branch. Матчинг ответов внутри диалога происходит по тегам диалога. И снова, смотрите не перепутайте. Я сам путаюсь, когда через несколько месяцев не-общения с этим всем возвращаюсь к тематике.

Так зачем же нужны эти From и To? А затем, что там теги.

From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=skfhjskdkfsd


Ах да, я ж забыл упомянуть теги:

У нас есть call-id и есть два тега. Вместе они образуют полный идентификатор диалога (ассоциация между двумя конечными участниками). Сообщение внутри диалога (у него два тега) определяет модификацию установленного звонка, а вне диалога (только один тег) новый звонок. (Я упростил всё, что можно, но для первого описания пойдёт.)

Call-id имеет особые, ни на что остальное в SIP не похожие, правила допуска и сравнения. Он регистрозависим (в отличие от тегов диалога), но об этом ниже. У него свой набор допустимых символов. Call-id неуникален, его совпадение у соседних звонков норма и закономерность (при форкинге диалога, когда на один запрос отвечают несколько удалённых участников). В отличие от, теги диалога уникальны, требуется хотя бы 32 бита случайности при их генерации, больше лучше. На самом деле после генерации тегов call-id вообще не нужен, у него роль мнэээ в рамках стандартных использований по RFC у него роли вообще нет, кроме как путаться под ногами, всё работало бы и без него. А вот для B2BUA, как у нас, call-id начинает выполнять особую функцию связи между звонками на разных сторонах одного B2BUA. Но B2BUA не определён ни одним RFC даже в ранге informational; это такое странное понятие, на которое ссылаются в нескольких RFC, но определено в лучшем случае неформально.

Так почему теги не в отдельных полях заголовка? Вы не найдёте обоснованного ответа на этот вопрос: это уже закон жизни, который тайна веков. Но зато ради них приходится полностью парсить целые From и To, с учётом всех тонкостей по содержанию (см. выше про адресные поля).

Cинтаксис возвращается: регистр букв

По непонятной прихоти call-id регистрозависим, а теги нет. Точнее, так в книге написано (tm), что они регистронезависимы. Реально же:
1) Есть UA (user agents железные или программные телефоны), которые воспринимают посылки в диалоге только если буквы в теге в том же регистре, что они посылают (если это Abc, то и надо прислать им Abc).
2) Есть UA, которые переделывают теги под себя, и если им прислать abc они ответят ABC. Или наоборот, прислали ABC а они отвечают abc.

И с обоими надо работать. Отказывать просто потому, что они нарушают ну в основном нельзя. Потому что всё равно не исправят большинство из них железные, и авторы прошивки просто не поймут, чего от них хотят. Не знаю, зачем производители железных UA нанимают таукитян или сентинельцев? Сложно разобрать, но проверено, что планета у них какая-то другая.

Какой вариант работает в итоге? Тег надо хранить в двух вариантах: приведённый к конкретному регистру для сравнения, и неприведённый для посылки другому участнику. Где-то мы это уже слышали?

И то же оказалось привет, история в Git с transport параметром URI. Потому что мы добрые, и если чужой телефон или SBC настаивает, что должно быть transport=UDP, а не transport=udp, то легче согласиться, чем спорить. Это карма авторов чисто софтового продукта: легче адаптировать софт, чем даже прошивку железного аппарата (а тем более само железо).

Но это были цветочки, основной же вопрос зачем вообще эта регистронезависимость?

Стандартные аргументы в пользу регистронезависимости: облегчение человекочитаемости. Это миф: её путают с человекоозвучиваемостью. Регистр не должен быть важен, например, в имени человека (хотя и тут могут быть тонкости). Но я не знаю, в каком случае с экрана будет читаться что-то в шрифтах, которые не различают регистр. И совсем не понимаю, почему и зачем различие регистра считается важнее, чем 100500 других различий.

Этот тезис можно обсудить в применении, например, к файловым системам отдельно (почему такие FS различают foo.docx, foo.docx , foо.docx и foo.docx (кто увидит разницу?), но не различают foo.docx и Foo.docx?), и что будет в случае (см. Turkey test), но сейчас речь не о них, а о SIP на простом беспроблемном ASCII.

Вы можете написать:

<code>From: <sip:123@foobar>;tag=mamarama</code>

но вы можете также написать:

<code>fRoM      :  <sip:123@foobaR>;TaG=mamaRAMa</code>

Все воспринимающие должны понять это одинаково. Но чего этого стоит? Обратимся к коду одной из самых быстрых реализаций Kamailio, в девичестве Sip Express Router.

/*! \brief macros from parse_hname2.c */#define READ(val) \(*(val + 0) + (*(val + 1) << 8) + (*(val + 2) << 16) + (*(val + 3) << 24))#define LOWER_DWORD(d) ((d) | 0x20202020)...#define _cont_ 0x746e6f63......                                // например возьмём этот кусок                                if ((LOWER_DWORD(READ(c)) == _cont_) &&                                        (LOWER_DWORD(READ(c+4)) == _ent__) &&                                        (LOWER_DWORD(READ(c+8)) == _type_)                                ) {                                        /* Content-Type HF found */

Ну, это хорошо работает на C. (Clang умудрился свернуть READ в просто 32-битное чтение из памяти. GCC этого не сумел. Ну не так страшно.) Уже на Java надо финтить, но хотя бы есть ByteBuffer. На интерпретаторах вроде Python, и на Java на строках, это превращается в чудовищную затрату или времени, или памяти, или обоих сразу.

Но и этот детект помогает только в очень ограниченной роли быстрый поиск по первым четвёркам символов (а ещё есть альтернативные имена полей f вместо from, i вместо call-id; пробелы до и после ':' в неограниченном количестве; и так далее). А как только мы выходим за пределы средств с прямым изменением в буферах привет, копирование.

Продолжение следует

Введение

Цифровая Подстанция это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?

Всем, кому интересно разобраться в этой теме, welcome под кат!

Как данные передаются в сети и зачем управлять multicast-потоками?

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


Что такое Цифровая Подстанция и зачем там нужен multicast?

Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:

• Кто участвует в передаче данных?
• Какие данные передаются в ЛВС?
• Какая типовая архитектура ЛВС?

И уже после этого обсуждать multicast

Что такое Цифровая Подстанция?

Цифровая Подстанция это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.

Соответственно, в цифровом виде здесь передаются все данные:

• Измерения.
• Диагностическая информация.
• Команды управления.

Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО Россети определяет следующее определение и критерии ЦПС:

Определение:
Цифровая подстанция автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.

Критерии:

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

Кто участвует в передаче данных?

В составе Цифровой Подстанции есть следующие системы:

• Системы релейной защиты. Релейная защита это практически сердце Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
  Горизонтальная связь общение терминалов между собой.
  Вертикальная связь общение с сервером АСУ ТП.
  Измерения общение с измерительными устройствами.

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

• Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.

Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже пишите в комментарии. Расскажем про это отдельно ;-)

Какие данные передаются в ЛВС?

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


Структурная схема электроэнергетического объекта в соответствии с МЭК 61850

На структурной схеме изображены шины:

• Мониторинг/Управления.
• Передача сигналов РЗА.
• Передача мгновенных значений напряжений и токов.

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

Через шину Передача сигналов РЗА терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.

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

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

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

С сервера АСУ ТП данные отправляются в диспетчерский пункт.

Какая типовая архитектура ЛВС?

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

На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.

Архитектура Цифровой Подстанции

На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.

Архитектура разбита на три уровня:

• Уровень станции/подстанции.
• Уровень присоединения.
• Уровень процесса.

Уровень станции/подстанции включает в себя АРМы и сервера.

Уровень присоединения включает в себя все технологическое оборудование.

Уровень процесса включает в себя измерительное оборудование.

Также есть две шины для объединения уровней:

• Шина станции/подстанции.
• Шина процесса.

Шина станции/подстанции объединяет в себе функции шины Мониторинг/Управление и шины Передача сигналов РЗА. А шина процесса выполняет функции шины Передача мгновенных значений напряжения и тока.

Особенности передачи Multicast в Цифровой Подстанции

Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры Издатель-Подписчик. Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.

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

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

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

Поэтому данные должны были передаваться:

• Надежно.
• Гарантированно.
• Быстро.

Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).

GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.

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

Переход от связи точка-точка к ЛВС подхода не изменил. Данные по-прежнему необходимо передавать надежно, гарантированно и быстро. Поэтому для GOOSE-сообщений используется несколько непривычный механизм передачи данных. Про него чуть позже.

Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).

SV-потоки это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой частотой дискретизации.

Частота дискретизации частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.


Частота дискретизации 80 выборок в секунду

Состав SV-потоков описан в МЭК61850-9-2 LE.

SV-потоки передаются через шину процесса.

Шина процесса коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).

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

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

Во-первых, они передаются на канальном уровне и имеют свой Ethertype 0x88b8. Это обеспечивает высокую скорость передачи данных.

Теперь необходимо закрыть требования гарантированности и надежности.

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

Поэтому для передачи GOOSE используется архитектура Издатель-Подписчик.

Архитектура Издатель Подписчик

Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом через чуть больший и так далее. В итоге время увеличивается до Т0.

Принцип передачи GOOSE-сообщений

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

SV-потоки также передаются на канальном уровне, имеют свой Ethertype 0x88BA и передаются по модели Издатель Подписчик.

Нюансы multicast-передачи в Цифровой подстанции
Но в энергетическом multicastе есть свои нюансы.

Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для энергетического multicast используются свои группы для рассылки.

В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО ФСК определяет собственные диапазоны multicast-рассылки.

Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Для GOOSE-сообщений: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее терминалы релейной защиты не поддерживают IGMP или PIM. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.

Другими словами вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой никак.

А SV-потоки это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.

Какой тогда выход?

Простой использовать старые проверенные VLAN.

Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.

Поэтому можно выделить простое правило пусконаладки Сеть не работает? Disable IGMP!

Нормативная база

Но может быть все-таки можно как-то организовать ЛВС Цифровой Подстанции на основе multicast? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:

• СТО 34.01-21-004-2019 ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВХ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
• СТО 34.01-6-005-2019 КОММУТАТОР ЭНЕРГООБЪЕКТОВ. Общие технические требования.
• СТО 56947007-29.240.10.302-2020 Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.

Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО ФСК ЕЭС. СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.

Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.

На этом все про multicast

Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.

Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.

СТО 34.01-21-004-2019 говорит о том, что VLANы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.

СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.

Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.

Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020



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

А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.

Заключение

В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.

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

Полезные ссылки:
Обучающий курс Цифровая подстанция от Phoenix Contact.
Решения для ЦПС от Phoenix Contact.