На количество переселяемых подов есть ограничение сверху, поскольку, по закону распределения максимумов случайных величин, выселение 10 подов может сходиться довольно долго. А ещё ситуация на кластере постоянно меняется, и чем дольше мы исполняем план, тем более вероятно, что он уже потерял актуальность. Также в функционал ЦЛП с небольшим весом включено кол-во переселяемых подов - так что, при прочих равных, дефрагментатор предпочитает переселять поменьше.
По поводу динамической аллокации - в YP в базовом виде реализованы механизмы вертикального и горизонтального масштабирования (в частности, мы умеем по ночам передавать мощности из определённых сервисов в батч), но там ещё есть достаточно улучшений, которыми мы активно занимаемся. В текущих условиях это довольно приоритетная задача :)
Мне тоже в целом нравится идея управлять домом через бота, но такой очевидный вектор атаки доставляет мне беспокойство. Можно добавить к командам цифровые подписи, но очень вряд ли удастся при этом сохранить интерфейс с красивыми кнопочками (не без мороки, по крайней мере).
Интересно, спасибо. Но вас не волнует проблема информационной безопасности? А именно, вы управляете домом через бота в Телеграме, а значит, владельцы Телеграма могут отправить вашему боту команду от вашего лица. Конечно, пока это история про Неуловимого Джо (который никому не нужен), да и вряд ли можно нанести большой вред (разве что лишних киловатт накрутить на счётчик), но, как параноик на почве ИБ, я бы крепко задумался.
Большое спасибо, вроде программирую на Питоне чуть не каждый день, а вот тема с async/await прошла мимо меня. Для увлекательных путешествий по DOMу кроме XPath могу посоветовать Beautiful Soup — чисто Питоновская библиотека для парсинга HTML (родные Питоновские библиотеки лично мне больше по душе, но дело вкуса). Также рекомендую, дабы не особо наглеть, добавлять задержку хотя бы 0.1 сек между запросами и все-таки не распараллеливать — на Метакритике сработало, а вот на более серьезных ресурсах обязательно нарветесь на капчу после 10 запросов.
У меня несколько недель 24/7 парсятся свежие Яндекс.Новости. Никто не банил, регистрации не надо, никакого реакта, каптча обходится таймаутом побольше. Что я делаю не так?
Ну так если мы делаем классификацию трафика «на месте», то точно такие же данные и после применения машинного обучения будут храниться. А вот если здесь и сейчас у нас нет DPI, но есть вероятность, что проанализировать трафик потребуется, то для nDPI придётся хранить по 64 пакета каждого потока. В случае применения машинного обучения, хранить надо только 256 байт на поток.
Я и не замахивался на решение всех задач DPI (в начале статьи сказано — «одной из главных задач»).
Данная статья — это «proof of concept», что такое вообще возможно — определить прикладной протокол, не видя полезной нагрузки. Трафик поэтому рассматривается нешифрованный. Для работы с шифрованным трафиком метод придётся изменять, не спорю.
Кстати, такой метод классификации трафика уже применяется в DPI
Конечно, но в открытом доступе информации о таких технологиях я не нашёл. Данная статья — моё собсвенное исследование на тему.
Кроме всего выше перечисленного, это ещё и способ работать с шифрованным трафиком. Анализировать контент не получится, но вот понять хотя бы, что это за прикладной протокол — вполне.
В перспективе также можно придумать способ решать задачи, не решаемые при помощи DPI. Например, определять вредоносный трафик по таким вот характеристикам, не привязываясь к прикладному протоколу.
Да, естественная. Использовал вполне традиционно — алгоритму для обучения даётся матрица Х «объект-признак» и вектор Y меток класса. В нашем случае объект — поток транспортного уровня, признаки — те самые 32 статистические метрики потока.
Спасибо, про эффективность я сгоряча. Переместил акценты во введении.
вы точность кросс-валидацией проверяли?
Конечно, результаты примерно такие же (в посте я привёл лучшие результаты среди подвыборок).
Ну и тренировать на данных, которые получены только от одного компьютера — неправильно.
Строго говоря, компьютеров было два и доступ в Интернет они получали по-разному (один даже через 3G + Wi-Fi), но я понимаю, что репрезентативность здесь низкая. Собирал там, где была возможность. Если можете посоветовать, где можно достать дампы трафика побольше и с разных точек, буду благодарен.
Если какое-то одно приложение передаёт заметно больше данных, чем все остальные, его теоретически можно будет выявить даже сквозь VPN. Если высокая активность у нескольких приложений, способ «в лоб» скорее всего не сработает, но всё равно можно попытаться что-то придумать и сделать какие-то выводы. К примеру, трафик HTTP имеет свойство передаваться всплесками, и если провести кластеризацию передаваемых пакетов во времени и скормить классификатору выявленные кластеры, вполне вероятно, что HTTP будет определён. Более равномерный трафик тоже можно как-нибудь вычленить как принадлежащий конкретному приложению — тут широкое поле для исследований.
На количество переселяемых подов есть ограничение сверху, поскольку, по закону распределения максимумов случайных величин, выселение 10 подов может сходиться довольно долго. А ещё ситуация на кластере постоянно меняется, и чем дольше мы исполняем план, тем более вероятно, что он уже потерял актуальность. Также в функционал ЦЛП с небольшим весом включено кол-во переселяемых подов - так что, при прочих равных, дефрагментатор предпочитает переселять поменьше.
По поводу динамической аллокации - в YP в базовом виде реализованы механизмы вертикального и горизонтального масштабирования (в частности, мы умеем по ночам передавать мощности из определённых сервисов в батч), но там ещё есть достаточно улучшений, которыми мы активно занимаемся. В текущих условиях это довольно приоритетная задача :)
Мне тоже в целом нравится идея управлять домом через бота, но такой очевидный вектор атаки доставляет мне беспокойство. Можно добавить к командам цифровые подписи, но очень вряд ли удастся при этом сохранить интерфейс с красивыми кнопочками (не без мороки, по крайней мере).
А какие данные надо хранить для nDPI на один поток?
Данная статья — это «proof of concept», что такое вообще возможно — определить прикладной протокол, не видя полезной нагрузки. Трафик поэтому рассматривается нешифрованный. Для работы с шифрованным трафиком метод придётся изменять, не спорю.
Конечно, но в открытом доступе информации о таких технологиях я не нашёл. Данная статья — моё собсвенное исследование на тему.
В перспективе также можно придумать способ решать задачи, не решаемые при помощи DPI. Например, определять вредоносный трафик по таким вот характеристикам, не привязываясь к прикладному протоколу.
Можете рассказать поподробнее про блокировки без DPI? Например, сайтов по спискам Роскомнадзора.
Конечно, результаты примерно такие же (в посте я привёл лучшие результаты среди подвыборок).
Строго говоря, компьютеров было два и доступ в Интернет они получали по-разному (один даже через 3G + Wi-Fi), но я понимаю, что репрезентативность здесь низкая. Собирал там, где была возможность. Если можете посоветовать, где можно достать дампы трафика побольше и с разных точек, буду благодарен.