У статьи нет структуры. Возникает вопрос - какую проблему вы решаете? Обход блокировок трафика или скорость работы сервиса при обходе таких блокировок?
Если первое, то тогда интересно иметь входные данные - для каких сервисах проводились тесты, у каких операторов они были заблокированы, затем вы меняете какие-то характеристики поведения вашего сервиса (например задержка, CDN флуд) и получаете результаты у какого провайдера сервисы "разбловировались". В статье же перечислены интересные метрики чтобы их покрутить, но совершенно не понятно как они в итоге влияют на классификацию.
Если же вы хотите раскрыть потенциал скорости обходов блокировок с помощью вашего подхода, тогда нужно в самом начале иметь референсные значения других сервисов позволяющих обходить блокировки и в итогах сравнить показатели с вашим решением.
Моё мнение, если вы средняя или крупная компания, то переезд оправдан.
Если вас от 10-30 человек, то лучше выбрать сервис и пользоваться, тем самым делегировав работу по обслуживанию инфраструктуры.
Свой сервер - аренда места в стойке (опционально, если нет своего офиса), бесперебойник, электричество, наличие резервного канала если интернет в офисе отлетает.
Почтовый сервер - спам фильтрация, настройка DKIM, DMARK, SPF, защита от брутфорса, обновление почтового сервера, мониторинг на неподание в черный список.
Можно продолжить далее по списку, но остановлюсь.
P.S.0.: Не говорю что вы сделали неправильно, просто делюсь тем, через что сам прошел и знаю обе стороны. Если у вас есть человек или отдел, который готов заниматься поддержанием инфраструктуры - то прекрасно. Если нет, то поддержание будет отнимать часть ресурсов у вашей команды. Иногда просто хочется чтобы работало =)
P.S.1.: Полностью согласен с тем, что наличие рекламы в почтовых сервисах это просто трешак! В Яндекс зайти нельзя уже - начинает плашки кидать "Купи-купи-купи". Полагаю в Mail.ru такая же история.
Вы просто не представляете масштаб, сложность и уровень ответственности при таких блокировках (масштаб - вся страна).
Это весьма непростая задача для команды опытных инженеров. Терабиты трафика для реал-тайм обработки с необходимостью точечной классификации. Плюсом ко всему трафик мигрирующий между выходными узлами и/или сервером обработки.
Не нужно думать что когда что-то отваливается это в виду некомпетентности людей. Просто это реально очень сложно.
_ в начале имени члена класса весьма удобен - при написании и чтении когда сразу с первого символа названия переменной понимаешь что это не аргумент и не локальная переменная.
Согласен с вопросом проблемности архитектуры нынешних технологий - клиент<->сервер.
Но насколько я понимаю, ваш мессенджер не решает эту проблему. Такж есть сервера вашего мессенджера, которые можно определять и блокировать.
---
На мой взгляд, P2P должен получить новый виток на фоне того, что происходит в мире с технологиями. Причем без каких-то костылей в виде mesh систем и блютузов.
Готовых и подходящих симуляторов ядра сети и пользовательских устройств на рынке мы не нашли, поэтому разрабатываем их самостоятельно.
Где-то читал (уже не помню) что не смотря на то что стандарты мобильной связи имеют спецификации составленные 3GPP, в разных странах работа мобильной сети может немного отличаться. Это правда? И если да, то может это и причина того что готовых симуляторов нет, так как они затачиваются под страну?
И второй вопрос, а что ожидается от симулятора пользовательского устройства? Работа GSM модуля с возможностью проигрывать сценарии?
маршрутизатор направляет запрос DHCP-серверу для получения динамического IP-адреса. Сервер выдаёт адрес и запускает shell-скрипт, ...
То есть у вас свой модифицированный DHCP который дергает shell скрипт после выдачи IP адреса? Который в свою очередь шлет запрос (команду) на активацию политики no-auth (условное название) для конкретного IP адреса, верно?
Я ведь описал механизм (SPID - Statisitcal Protocol Identification). Он основывается не на протоколе, а статистических характеристиках, которые можно рассчитывать как для шифрованного трафика, так и для не шифрованного.
Что до чата, передачи файла, отсылки кружка, и прочего - делаются условно 100 тестов и составляются референсные значения (вилки) для каждой категории.
DPI классифицирует сервис (WhatsApp, Telegram, Viber, ...), затем происходит классификация workflow (аудио/видео вызов, передача файла, чат). Workflow классифицируется только для отдельные сервисов, для которых это требуется и мессенджеры одни из них. Например для какого-нибудь DropBox можно также классифицировать передачу файлов или для YouTube можно классифицировать Video stream.
Классификация workflow не всегда "протокольная" как описано в статье. Какой-нить SIP/RTP/RTCP можно отловить для FaceTime. Для телеграм это не сработает - там свой протокол и для DPI это выглядит как нераспознанный трафик. Но так как основной сервис определен (Telegram), то DPI может сделать предположение о том, что этот поток делает (workflow) на основе статистической информации по потоку: уровень энтропии, битрейт, средний размер пакетов, IAT (inter arrival time) и прочее. Например для аудио вызова характерен высокий битрейт и не очень большой размер пакетов. Для видео вызова также высокий битрейт и большой размер пакетов. Для передачи файлов - бла-бла, и так далее.
Вывод уведомлений в реальном времени (отпадает необходимость постоянно доставать смартфон). Просто удобно.
Вывод каких-то важных оповещений. Например при вождении можно не дёргать глазами на навигатор, а очки будут отображать полосу, скорость, время до точки и так далее.
Вывод дополнительного дисплея при работе за компьютером (монитором) или на крайний случай вывод виджетов.
Встроенный AI помогающий тебе в режиме реального времени. Например пишешь статью или код и не нужно плодить 100500 плагинов - очки видят все то, что видите вы.
Google Glass как отличный пример опередивший время. Очки дополненной реальности для 2013 казались чем-то непонятным, но в наши дни практически каждый осознает как они могут быть применены.
P.S. Apple Vision не в счёт. Это вообще не пойми что. Для маргиналов)
В 2015 (или 2016) закрыли G+ где сохранял ссылки на статьи. Выгруженные данные где-то лежат в архиве, но вот куда их загрузить чтобы они были в «потребном» виде не понятно. Начал использовать Pocket. И вот 2025 и его тоже закрывают и снова выгружать ссылки и снова они будут валяться в архиве на диске.
Два крупных сервиса для агрегации ссылок за 10 лет грохнули)
Предоставьте простые и понятные инструменты для активации лицензии конечным пользователем. Например, внедрите элемент самообслуживания через личный кабинет с возможностью мгновенной покупки, изменения тарифного плана или переноса лицензий между устройствами.
Года 3 назад, видел как в одной из компаний начали улучшать данный процесс. Его назвали User Journey (кажется это какой-то специальный термин). Цель была упростить покупку и продление лицензии для пользователей. Чтобы все было приятно и красиво. Это здравая мысль и это действительно работает, но вот оплату автоматизировать для B2B продукта не так просто в случае, если общая стоимость продукта (или совокупная цена) достаточно большая. Условно карту не привяжешь для оплаты лицензии на сумму >= 10 000 000 рублей в год и все возвращается к ручному/автоматическому генерированию счета на оплату, ожидания перевода, подтверждение его человеком и выдаче лицензионных ключей.
Я правильно понимаю что на данный момент это не больше чем IDE с прикрученным AI плагинами?
Как агенты они не рабоют. То есть, невозможно на данный момент подключить к этим IDE issue tracker, где можно повесить теги “ai” для задач, которые мы можем делегировать искусственному интеллекту и на выходе ожидать готовый MR, с документированными коммитами, новыми тестами, изменениями в доке если требуется и пройденным циклом CI/CD?
У статьи нет структуры. Возникает вопрос - какую проблему вы решаете? Обход блокировок трафика или скорость работы сервиса при обходе таких блокировок?
Если первое, то тогда интересно иметь входные данные - для каких сервисах проводились тесты, у каких операторов они были заблокированы, затем вы меняете какие-то характеристики поведения вашего сервиса (например задержка, CDN флуд) и получаете результаты у какого провайдера сервисы "разбловировались". В статье же перечислены интересные метрики чтобы их покрутить, но совершенно не понятно как они в итоге влияют на классификацию.
Если же вы хотите раскрыть потенциал скорости обходов блокировок с помощью вашего подхода, тогда нужно в самом начале иметь референсные значения других сервисов позволяющих обходить блокировки и в итогах сравнить показатели с вашим решением.
Моё мнение, если вы средняя или крупная компания, то переезд оправдан.
Если вас от 10-30 человек, то лучше выбрать сервис и пользоваться, тем самым делегировав работу по обслуживанию инфраструктуры.
Свой сервер - аренда места в стойке (опционально, если нет своего офиса), бесперебойник, электричество, наличие резервного канала если интернет в офисе отлетает.
Почтовый сервер - спам фильтрация, настройка DKIM, DMARK, SPF, защита от брутфорса, обновление почтового сервера, мониторинг на неподание в черный список.
Можно продолжить далее по списку, но остановлюсь.
P.S.0.: Не говорю что вы сделали неправильно, просто делюсь тем, через что сам прошел и знаю обе стороны. Если у вас есть человек или отдел, который готов заниматься поддержанием инфраструктуры - то прекрасно. Если нет, то поддержание будет отнимать часть ресурсов у вашей команды. Иногда просто хочется чтобы работало =)
P.S.1.: Полностью согласен с тем, что наличие рекламы в почтовых сервисах это просто трешак! В Яндекс зайти нельзя уже - начинает плашки кидать "Купи-купи-купи". Полагаю в Mail.ru такая же история.
Вы просто не представляете масштаб, сложность и уровень ответственности при таких блокировках (масштаб - вся страна).
Это весьма непростая задача для команды опытных инженеров. Терабиты трафика для реал-тайм обработки с необходимостью точечной классификации. Плюсом ко всему трафик мигрирующий между выходными узлами и/или сервером обработки.
Не нужно думать что когда что-то отваливается это в виду некомпетентности людей. Просто это реально очень сложно.
Наконец-то! Давно пора сделать такой фильтр.
Так и есть - это субъективный-объективизм)
Здесь нет правильно или неправильного ответа (пока это не ломает сборку компилятором) и определяется мэинтейнером проекта.
_в начале имени члена класса весьма удобен - при написании и чтении когда сразу с первого символа названия переменной понимаешь что это не аргумент и не локальная переменная.Как вариант решения кейса для многопоточности - атомарный индекс для вершины стека.
Когда приходит запрос на выделение сегмента - первым делом резервируется сегмент через инкремент индекса.
Или альтернативный и самый простой вариант - thread_local пул. Но тогда потребление памяти будет не рациональным.
Согласен с вопросом проблемности архитектуры нынешних технологий - клиент<->сервер.
Но насколько я понимаю, ваш мессенджер не решает эту проблему. Такж есть сервера вашего мессенджера, которые можно определять и блокировать.
---
На мой взгляд, P2P должен получить новый виток на фоне того, что происходит в мире с технологиями. Причем без каких-то костылей в виде mesh систем и блютузов.
Где-то читал (уже не помню) что не смотря на то что стандарты мобильной связи имеют спецификации составленные 3GPP, в разных странах работа мобильной сети может немного отличаться. Это правда? И если да, то может это и причина того что готовых симуляторов нет, так как они затачиваются под страну?
И второй вопрос, а что ожидается от симулятора пользовательского устройства? Работа GSM модуля с возможностью проигрывать сценарии?
Тоже хотел об этом написать, что причина скорее в уже написанных (для мессенджера) библиотеках, зависимостях и технологиях.
Всем вокруг одна сплошная конспирология мерещится.
То есть у вас свой модифицированный DHCP который дергает shell скрипт после выдачи IP адреса? Который в свою очередь шлет запрос (команду) на активацию политики
no-auth(условное название) для конкретного IP адреса, верно?Тоже заметил что файлы стали долго уходить. Возможно передача файлов некорректно классифицируется как видеовызов.
P.S. Всё нормально, бывает=)
Я ведь описал механизм (SPID - Statisitcal Protocol Identification). Он основывается не на протоколе, а статистических характеристиках, которые можно рассчитывать как для шифрованного трафика, так и для не шифрованного.
Что до чата, передачи файла, отсылки кружка, и прочего - делаются условно 100 тестов и составляются референсные значения (вилки) для каждой категории.
DPI классифицирует сервис (WhatsApp, Telegram, Viber, ...), затем происходит классификация workflow (аудио/видео вызов, передача файла, чат). Workflow классифицируется только для отдельные сервисов, для которых это требуется и мессенджеры одни из них. Например для какого-нибудь DropBox можно также классифицировать передачу файлов или для YouTube можно классифицировать Video stream.
Классификация workflow не всегда "протокольная" как описано в статье. Какой-нить SIP/RTP/RTCP можно отловить для FaceTime. Для телеграм это не сработает - там свой протокол и для DPI это выглядит как нераспознанный трафик. Но так как основной сервис определен (Telegram), то DPI может сделать предположение о том, что этот поток делает (workflow) на основе статистической информации по потоку: уровень энтропии, битрейт, средний размер пакетов, IAT (inter arrival time) и прочее. Например для аудио вызова характерен высокий битрейт и не очень большой размер пакетов. Для видео вызова также высокий битрейт и большой размер пакетов. Для передачи файлов - бла-бла, и так далее.
Первое что приходит в голову:
Вывод уведомлений в реальном времени (отпадает необходимость постоянно доставать смартфон). Просто удобно.
Вывод каких-то важных оповещений. Например при вождении можно не дёргать глазами на навигатор, а очки будут отображать полосу, скорость, время до точки и так далее.
Вывод дополнительного дисплея при работе за компьютером (монитором) или на крайний случай вывод виджетов.
Встроенный AI помогающий тебе в режиме реального времени. Например пишешь статью или код и не нужно плодить 100500 плагинов - очки видят все то, что видите вы.
Google Glass как отличный пример опередивший время. Очки дополненной реальности для 2013 казались чем-то непонятным, но в наши дни практически каждый осознает как они могут быть применены.
P.S. Apple Vision не в счёт. Это вообще не пойми что. Для маргиналов)
В 2015 (или 2016) закрыли G+ где сохранял ссылки на статьи. Выгруженные данные где-то лежат в архиве, но вот куда их загрузить чтобы они были в «потребном» виде не понятно. Начал использовать Pocket. И вот 2025 и его тоже закрывают и снова выгружать ссылки и снова они будут валяться в архиве на диске.
Два крупных сервиса для агрегации ссылок за 10 лет грохнули)
Года 3 назад, видел как в одной из компаний начали улучшать данный процесс. Его назвали User Journey (кажется это какой-то специальный термин). Цель была упростить покупку и продление лицензии для пользователей. Чтобы все было приятно и красиво. Это здравая мысль и это действительно работает, но вот оплату автоматизировать для B2B продукта не так просто в случае, если общая стоимость продукта (или совокупная цена) достаточно большая. Условно карту не привяжешь для оплаты лицензии на сумму >= 10 000 000 рублей в год и все возвращается к ручному/автоматическому генерированию счета на оплату, ожидания перевода, подтверждение его человеком и выдаче лицензионных ключей.
Я правильно понимаю что на данный момент это не больше чем IDE с прикрученным AI плагинами?
Как агенты они не рабоют. То есть, невозможно на данный момент подключить к этим IDE issue tracker, где можно повесить теги “ai” для задач, которые мы можем делегировать искусственному интеллекту и на выходе ожидать готовый MR, с документированными коммитами, новыми тестами, изменениями в доке если требуется и пройденным циклом CI/CD?
Когда уже конец?)