дороговизны: в интернете много информации по сравнению стоимости ресурсов DPDK и eBPF […] Нам в условиях большого количества VLAN и транзитного способа обработки трафика использовать eBPF было выгоднее
Вы же свое решение описываете, причем тут какие-то статьи из интернетов?
Насчёт скорости разработки: я не знаю с какой конкретно проблемой вы сталкивались, какую задачу решали и почему у вас не получилось. Скорость разработки нас устраивает
Тут в качестве ответа напрашивается только то, что потребности в вашем случае, видимо, самые примитивные. Вот в качестве начала, оптимизатор компилятора (clang) конфликтует с верификатором ядра очень часто - заведенный мной баг https://github.com/iovisor/bcc/issues/5062 до сих пор висит в статусе open (уже 2 года), максимум что там предложили - ассемблерную затычку макросом.
Далее, вот возьмем вполне себе типовую задачу - нужно отслеживать установленные соединения по 5-tuple (conntrack в терминах iptables), причем для разных состояний соединения - это ключевое! - иметь разный таймаут его протухания (скажем 300 секунд для проверенных, 20 секунд для еще нет). Так вот, в eBPF подход “жрите что дают” - есть только LRU-мапы, где вытесняться будет как оно там внутри захочет, а не по административному критерию. В полноценной системе решается довольно просто - в каждой записи имеем поле expire и при его обновлении просто перелинковываем запись в голову связного списка соответствующей секунды, дальше 1 (один) таймер просто ходит по ним и удаляет их. Но в eBPF-мапах никаких связных списков НЕТ. В результате надо либо городить сложные схемы с индексацией одной мапы другой, и всё равно упереться в лимит работы на одном eBPF-таймере, либо встраивать собственный таймер в каждую запись (дорого и по памяти и по шедулингу), либо отдавать чистку протухших в юзерленд - тоже дорого. Когда я в DOSGATE работал, там на каждый чих и чуть что, работа отдавалась из ядра в юзерлендный демон, потому что ну очень больно работать с ЭТИМ, слишком многое нельзя.
Я просто делаю вывод, что в вашей системе, скорее всего не более чем статические ACL по сути (пополнение/чистку мапы из юзерленда мы относим к статическим, это не динамический conntrack).
Под L2 мы имели в виду забивание канала (Amplification), в нашем случае множества каналов. Это то, с чем наша система борется (в числе прочего).
С этим любая система на рынке борется, вот только называется это таки L3 - не по MAC-адресам фильтруете же.
Если хотите узнать подробнее про архитектуру нашей защиты, приглашаем вас продолжить дискуссию на наших будущих митапах и linkmetup. Мероприятия будут ближе к концу года.
Пока что в описании слишком много общих слов без конкретики, это недостаточная реклама для посещения мероприятий.
В этом комменте всё хорошо, кроме слова POSIX - никто его давно не соблюдает, и особенно линуксы (причем намеренно). Да и конкретно по файловой иерархии в нём не особо
Не переживайте, я админил с 2005 до 2012, сначала сеть общаги своего факультета (два фряшных сервера (один роутер) с пачкой свичей на триста рыл), потом суперкомпьютерный кластер, потом в интернет-провайдере, пока не надоело и не пошел по специальности программистом. Видел я на разных юниксах отличия в положенных каталогах, и помню как товарищ по активу сети общажной монтировал на своей слаквари жесткие диски в /mnt на постоянку.
А что, разве FHS предписывает пользователию сидеть только в его каталоге? Нет ровным счетом никаких причин, почему пользователю не иметь свои каталоги вне хомы, это нормально (я себе так делаю, опыт у меня больше 20 лет, и man hier у нас во фре построже этого вашего FHS варьирующегося)
Конечно нет. Они все готовыми протоколами пользуются - HTTP, gRPC… их как раз совсем не много, по пальцам пересчитать.
Создать протокол - это сейчас труд коллективный, это инженерная задача
Я в IETF участвую и вижу как это на самом деле происходит. Как правило, успешные протоколы создаются одним человеком, вся остальная “коллективная” работа по сути сводится к review: “а вот мне бы еще такую фичу”, “вот такой-то use case не учтен”. Хорошо видно по числу авторов на каждом RFC.
Ближе к народу - USB стандарты делает “консорциум” USB Implementers Forum
…и такую херню делают, один из наиболее костыльных стандартов (самое хорошее, что было в USB - почти неубиваемая форма разъема, но со временем потеряли и это). Драйверописатели плюются, погуглить хоть USB quirks.
Это всю атмосферу убьет. К тому же зависимость от внешних сервисов. Я вот всё думаю новый аналог Фидонет сделать, и вот чтоб требование регистрации было только через знакомство с сисопом в оффлайне.
Столько проблем, большинство из которых решается банально настроенным MTA и админом, читабющим почту (для каковых времен, собственно, крон и создавался).
начинал с “наивного” архиватора на ассемблере z80.
Тоже неплохо, совсем не JSON.
ходит такое мнение, что 90% всех тасков в конечном счете сводится к перемещению и трансформации данных в формате json =)
Так собственно про ту сферу, где оно так, речь и шла. Мне, как джуну, в те годы обычно поручали несложные задачи, которые в бэклоге висят, а у старших руки не доходят. И это все-таки были разнообразные задачи, не джейсоны.
Ну что ж, если не искусство, попробуйте создать новый сетевой протокол, который заменил TCP или IPv6. Удачи оставаться в плену зашоренных представлений, тем более подменяя понятия на “типовые проекты” (которые по определению не).
Можете делать по сценарию, а можете приложить творческую жилку и делать искусство. Нет, наличие стандартов вовсе не означает, что всё ограничено и искусство невозможно. Наоборот, точно так же, как в случае с самолётами или ракетами, наличие ограничений в виде законов физики и имеющихся в доступности технологий (стандарты, вообще говоря, тоже подпадают под эту категорию), вынуждает творить так, чтоб эти ограничения обойти. И рождаются шедевры. Так же, как и в случае с сетевыми протоколами или сложными программными комплексами.
Более того, наука совершила такой рывок, что с XX века “творчество и искусство” (незачем разделять эти понятия) стали гораздо более сложными и доступными в большем поле вариаций именно в технических/инженерных областях, нежели в “традиционных” областях искусства/творчества типа художников или музыкантов.
Недостаточное у них пространство измерений, фундаментально меньше нужного для искусство. А вот архитектура уже имеет их, что в строительстве, что в IT. Можно видеть на примере удачных или неудачных протоколов, например. В мире сложных материальных объектов инженерное искусство еще более заметно, например спроектировать самолёт (“некрасивый не полетит”) или ракету.
Язык Go не просто так получил такую популярность. Он не допускает вольностей. И по той же причине многим не нравится Ruby - на нём легко можно написать одноразовый код.
Что забавно, настоящие программисты не любят Go и скорее будут любить Ruby именно поэтому - Go прокрустово ложе для быдлокодеров, искусство на нём не сделаешь.
Вы же свое решение описываете, причем тут какие-то статьи из интернетов?
Тут в качестве ответа напрашивается только то, что потребности в вашем случае, видимо, самые примитивные. Вот в качестве начала, оптимизатор компилятора (clang) конфликтует с верификатором ядра очень часто - заведенный мной баг https://github.com/iovisor/bcc/issues/5062 до сих пор висит в статусе open (уже 2 года), максимум что там предложили - ассемблерную затычку макросом.
Далее, вот возьмем вполне себе типовую задачу - нужно отслеживать установленные соединения по 5-tuple (conntrack в терминах iptables), причем для разных состояний соединения - это ключевое! - иметь разный таймаут его протухания (скажем 300 секунд для проверенных, 20 секунд для еще нет). Так вот, в eBPF подход “жрите что дают” - есть только LRU-мапы, где вытесняться будет как оно там внутри захочет, а не по административному критерию. В полноценной системе решается довольно просто - в каждой записи имеем поле expire и при его обновлении просто перелинковываем запись в голову связного списка соответствующей секунды, дальше 1 (один) таймер просто ходит по ним и удаляет их. Но в eBPF-мапах никаких связных списков НЕТ. В результате надо либо городить сложные схемы с индексацией одной мапы другой, и всё равно упереться в лимит работы на одном eBPF-таймере, либо встраивать собственный таймер в каждую запись (дорого и по памяти и по шедулингу), либо отдавать чистку протухших в юзерленд - тоже дорого. Когда я в DOSGATE работал, там на каждый чих и чуть что, работа отдавалась из ядра в юзерлендный демон, потому что ну очень больно работать с ЭТИМ, слишком многое нельзя.
Я просто делаю вывод, что в вашей системе, скорее всего не более чем статические ACL по сути (пополнение/чистку мапы из юзерленда мы относим к статическим, это не динамический conntrack).
С этим любая система на рынке борется, вот только называется это таки L3 - не по MAC-адресам фильтруете же.
Пока что в описании слишком много общих слов без конкретики, это недостаточная реклама для посещения мероприятий.
В чем заключается дороговизна?
Скорости разработки? Серьезно? Это когда постоянно бороться с верификатором приходится?
Вы путаете L2 и L3, судя по всему. После этого доверие к статье (и к решениям) как-то резко падает.
Аж глаз режет. Серьезно? Кто-то атакующий прям в свитчи втыкается?
Почему взят уродливый и кастрированный eBPF/XDP вместо, например, нормального неограниченного DPDK, опять же тема не раскрыта.
Ну допустим, вот у нас во FreeBSD есть подсистема MAC. И как бы она помогла в данном случае?
В этом комменте всё хорошо, кроме слова POSIX - никто его давно не соблюдает, и особенно линуксы (причем намеренно). Да и конкретно по файловой иерархии в нём не особо
Не переживайте, я админил с 2005 до 2012, сначала сеть общаги своего факультета (два фряшных сервера (один роутер) с пачкой свичей на триста рыл), потом суперкомпьютерный кластер, потом в интернет-провайдере, пока не надоело и не пошел по специальности программистом. Видел я на разных юниксах отличия в положенных каталогах, и помню как товарищ по активу сети общажной монтировал на своей слаквари жесткие диски в /mnt на постоянку.
А что, разве FHS предписывает пользователию сидеть только в его каталоге? Нет ровным счетом никаких причин, почему пользователю не иметь свои каталоги вне хомы, это нормально (я себе так делаю, опыт у меня больше 20 лет, и man hier у нас во фре построже этого вашего FHS варьирующегося)
Однако, такие дурные вещи делает (тащемта вот хоть дичайше костыльный протокол телеги взять, например)
Конечно нет. Они все готовыми протоколами пользуются - HTTP, gRPC… их как раз совсем не много, по пальцам пересчитать.
Я в IETF участвую и вижу как это на самом деле происходит. Как правило, успешные протоколы создаются одним человеком, вся остальная “коллективная” работа по сути сводится к review: “а вот мне бы еще такую фичу”, “вот такой-то use case не учтен”. Хорошо видно по числу авторов на каждом RFC.
…и такую херню делают, один из наиболее костыльных стандартов (самое хорошее, что было в USB - почти неубиваемая форма разъема, но со временем потеряли и это). Драйверописатели плюются, погуглить хоть USB quirks.
Это всю атмосферу убьет. К тому же зависимость от внешних сервисов. Я вот всё думаю новый аналог Фидонет сделать, и вот чтоб требование регистрации было только через знакомство с сисопом в оффлайне.
Да, собственно, как Рамблер-почта в 2011 начала мигрировать с FreeBSD на Ubuntu, так и пошла деградация, реальные проблемы решать перестали.
Столько проблем, большинство из которых решается банально настроенным MTA и админом, читабющим почту (для каковых времен, собственно, крон и создавался).
Тоже неплохо, совсем не JSON.
Так собственно про ту сферу, где оно так, речь и шла. Мне, как джуну, в те годы обычно поручали несложные задачи, которые в бэклоге висят, а у старших руки не доходят. И это все-таки были разнообразные задачи, не джейсоны.
Ну что ж, если не искусство, попробуйте создать новый сетевой протокол, который заменил TCP или IPv6. Удачи оставаться в плену зашоренных представлений, тем более подменяя понятия на “типовые проекты” (которые по определению не).
Можете делать по сценарию, а можете приложить творческую жилку и делать искусство. Нет, наличие стандартов вовсе не означает, что всё ограничено и искусство невозможно. Наоборот, точно так же, как в случае с самолётами или ракетами, наличие ограничений в виде законов физики и имеющихся в доступности технологий (стандарты, вообще говоря, тоже подпадают под эту категорию), вынуждает творить так, чтоб эти ограничения обойти. И рождаются шедевры. Так же, как и в случае с сетевыми протоколами или сложными программными комплексами.
Более того, наука совершила такой рывок, что с XX века “творчество и искусство” (незачем разделять эти понятия) стали гораздо более сложными и доступными в большем поле вариаций именно в технических/инженерных областях, нежели в “традиционных” областях искусства/творчества типа художников или музыкантов.
Недостаточное у них пространство измерений, фундаментально меньше нужного для искусство. А вот архитектура уже имеет их, что в строительстве, что в IT. Можно видеть на примере удачных или неудачных протоколов, например. В мире сложных материальных объектов инженерное искусство еще более заметно, например спроектировать самолёт (“некрасивый не полетит”) или ракету.
Большинство людей слишком тупы, чтобы понимать правильное применение понятия “рессентимент”. Вот так и здесь, очередное навешивание ярлыков.
шутка про мертвых младенцев и воздушные шары
Что забавно, настоящие программисты не любят Go и скорее будут любить Ruby именно поэтому - Go прокрустово ложе для быдлокодеров, искусство на нём не сделаешь.
Искусство - это не про варианты исполнения, а про продумать архитектуру. У токаря или тем более уборщицы такого пространства вариантов нет.