Интересно, сколько таких вот мелких заначек для будущих оптимизаций уже заложено разрабами?
Такое не закладывается заранее, особенно в хайлоаде. Места для оптимизаций В ПО всегда есть, потому что нельзя сразу написать сложную программу которая работает без ошибок, оптимизирована и легко расширяется. Сначала пишут чтобы работало (закладывая возможности для расширение), потом исправляют ошибки, профилируют и оптимизируют.
Но суть оригинального сообщение было о том, что банки уже ввели лимиты на переводы по СБП, и что потенциально цифровой рубль может решить эту проблему.
С 15 сентября Тинёк вводит лимит на переводы по СБП - 100к (кажется), дальше комиссия. Причем если вы оплачиваете на кассе или в кафе, то это черпает лимит переводов. Сбер кажется уже ввёл такое же ограничение (не проверял, но слышал от знакомых про то, что появились 1.5% комиссии за СБП).
Поэтому, если цифровой рубль оставят навсегда без комиссий, то это будет аналог нынешнему СБП.
У статьи нет структуры. Возникает вопрос - какую проблему вы решаете? Обход блокировок трафика или скорость работы сервиса при обходе таких блокировок?
Если первое, то тогда интересно иметь входные данные - для каких сервисах проводились тесты, у каких операторов они были заблокированы, затем вы меняете какие-то характеристики поведения вашего сервиса (например задержка, 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 плагинов - очки видят все то, что видите вы.
Такое не закладывается заранее, особенно в хайлоаде. Места для оптимизаций В ПО всегда есть, потому что нельзя сразу написать сложную программу которая работает без ошибок, оптимизирована и легко расширяется. Сначала пишут чтобы работало (закладывая возможности для расширение), потом исправляют ошибки, профилируют и оптимизируют.
Возможно вы правы.
Но суть оригинального сообщение было о том, что банки уже ввели лимиты на переводы по СБП, и что потенциально цифровой рубль может решить эту проблему.
Приложил к предыдущему ответу скриншоты из чата с Тинькофф банком.
С 15 сентября Тинёк вводит лимит на переводы по СБП - 100к (кажется), дальше комиссия. Причем если вы оплачиваете на кассе или в кафе, то это черпает лимит переводов. Сбер кажется уже ввёл такое же ограничение (не проверял, но слышал от знакомых про то, что появились 1.5% комиссии за СБП).
Поэтому, если цифровой рубль оставят навсегда без комиссий, то это будет аналог нынешнему СБП.
У статьи нет структуры. Возникает вопрос - какую проблему вы решаете? Обход блокировок трафика или скорость работы сервиса при обходе таких блокировок?
Если первое, то тогда интересно иметь входные данные - для каких сервисах проводились тесты, у каких операторов они были заблокированы, затем вы меняете какие-то характеристики поведения вашего сервиса (например задержка, 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 плагинов - очки видят все то, что видите вы.