Более того, у подавляющего большинства операторов нет даже никаких "историй посещения сайтов". Операторов заставляют ставить отдельно коробку с СОРМ, а управляют этой коробкой и берут оттуда данные совершенно другие люди, не операторы.
Обычно вся статистика которая есть у оператора - это семплированный netflow/ipfix. В нем вообще ничего не видно кроме IP адресов, протоколов и портов. При семплировании 1:500 в эту статистику попадет каждый 500-й пакет, а у крупных операторов бывает sampling rate и 1:10000.
То есть "историю поиска" могут дать только поисковики. Ну да, можно увидеть ее в браузере искавшего, но это какой-то уже странный случай.
После этого момента типы-суммы исчезают из императивного программирования. В императивных языках конца XX века доминировало влияние Pascal и C. В Pascal не было типов-сумм, потому что Вирт считал их менее гибкими, чем не размеченные (untagged) объединения.
В C, возможно, нет типов-сумм, потому что его создатели заимствовали систему типов из языка PL/I от IBM
В C тоже можно сделать tagged unions "на коленке", но нужно следить вручную за тегами. В телекомах это вообще такая классика, используется в куче протоколов и есть даже специальный термин TLV (type-length-value / tag-length-value) https://en.wikipedia.org/wiki/Type–length–value
Линейное чтение больших файлов (большими кусками) - да, будет приблизительно одинаково. Если нужно возиться с одними и теми же данными в небольшой области - mmap-решение может быть проще и быстрее.
Но вообще кеширование есть в "обычных" fread/fwrite из libc, размер буфера можно потюнить, непонятно почему сравнивали только сисколы read/write с mmap().
memory maps в основном упрощают жизнь
Да, но с нюансами. read/write при ошибке чтения/записи возвращают эту ошибку, и обычно программист к этому готов. С mmap в таком же случае приложение может получить SIGBUS и упасть. Программист и пользователи обычно к этому не готовы.
Управлять памятью в случае с mmap тоже сложнее. C read/write вы выделяете буфер и с ним работаете, все более-менее предсказуемо. А если вы сделаете в виртуалке с 8Gb памяти mmap на файл 32Gb и начнете его читать в разных местах, то контролировать память становится довольно проблематично. Все будет делать ОС, и иногда довольно непредсказуемо.
Недавно на гитхабе начали переделывать и сломали статистику по трафику репозиториев. Изменили графики посещений и клонирования (в худшую сторону), перестали показывать сайты с которых перешли и популярный контент.
Referring sites and popular content are temporarily unavailable or may not display accurately. We're actively working to resolve the issue.
Не то чтобы это была какая-то суперважная фича, но иногда интересно было посмотреть.
Судя по
Мы попросим команды отложить разработку функций, чтобы сосредоточиться на переносе GitHub.
Насколько я понимаю, Гарда использует (если использует, конечно) поиск аномалий в сетевом трафике. Они же не могут показывать каждую аномалию человеку для валидации, это было бы странновато. Обычно на аномалии нужно очень быстро реагировать.
А вообще интересно, насколько это реально работает с сетевыми аномалиями, что можно детектировать (атаки? сбои оборудования?) и насколько хорошо это получается.
Нам нужно не только визуализировать, а еще и реагировать на сетевые аномалии, DoS/DDoS, причем чем быстрее, тем лучше. Мы используем скользящие средние для детекции аномалий.
И мы обычно на одной инсталляции показываем статистику по разным сетям или объектам мониторинга разным пользователям (т.е. делаем мультитенантность/мультиарендность).
Абсолютно ничего не имею против Акворадо, даже советую его использовать интересующимся пользователям на реддите, но нужно понимать, что он хранит все фловы. Для кого-то это плюс, для кого-то довольно бессмысленно - для того чтобы раз в неделю грубо посмотреть разбивку трафика по своим сетям, GeoIP или AS нужно иметь хорошее такое хранилище. Плюс он вместе с Кафкой не очень легкий:
Akvorado is performant enough to handle 100 000 flows per second with 64 GB of RAM and 24
Да простят меня Настоящие Хайлоадеры, но мы вместо Кафки используем просто файловую систему - нужная статистика складывается в файликах на диск и отдельным процессом экспортируется в PostgreSQL или ClickHouse.
Ну и предобрабатываем данные внутри коллектора. Наверное это тоже неправильно с точки зрения Настоящей Хайлоад Архитектуры, но позволяет обрабатывать до 700k fps на одном vCPU (когда много объектов мониторинга, то меньше, конечно).
Да, к фидбекам и вообще к комментариям "из интернета" нужно относиться с осторожностью.
Сейчас перепроизводство софта, почти всегда можно найти аналог. Если реальным пользователям что-то не нравится, они как правило молча (и без фидбека!) переходят на другой продукт. В интернете часто пишут вообще далекие от предметной области люди, причем с видом экспертов. А эксперты не пишут, им это не очень интересно. Какой-то странный феномен - личное (или даже оффлайновое) общение с реальными пользователями бывает полезнее и интереснее, чем сообщения от анонимных людей "из интернета".
Иногда вижу еще один вид негативных отзывов - от евангелистов ПРАВИЛЬНЫХ технологий. Программа/библиотека написана не на любимом языке программирования - у евангелиста моментально полыхает: "ха-ха, ну сразу же видно какой это глючный отстой, я пользуюсь штукой написанной на Правильном ЯП и всем советую!!1" (штука делает не то что нужно, но кого это смущает). Не используется любимая технология комментатора - "буэ, что за рукожоп это делал вообще, вот смотрите как нужно делать: <рассказ о продукте, который делает вообще другое>".
Очень странное ощущение, когда о тебе пишет нейросеть.
Да, скриншоты она почему-то не смогла.
Хотя, все эти визуализации выглядят более-менее одинаково. Обычно это time series и опционально отчеты за крупные периоды - столбчатые/круговые диаграммы потребителей трафика, генераторов, AS, гео-распределения и т.п.
Вроде почти у всех можно посмотреть и другие поля, типа распределения трафика по TCP-флагам, TTL, IP протоколам, TCP/UDP портам.
Можно заглянуть в каждый из проектов, там будут картинки. Или загуглить что-то вроде netflow reports и посмотреть картинки. Они у всех приблизительно одинаковые, там сложно придумать что-то оригинальное.
Про xenoeye недавно писал на хабре, там есть и скриншот графаны.
Основные отличия между netflow анализаторами как раз не в визуализации, а в другом - может ли анализатор реагировать на аномалии, как у него реализованы объекты мониторинга (если реализованы вообще), если ли возможность разным группам пользователей показывать разные отчеты и т.д.
На момент релиза tkvdb был одним из редких примеров реализации подобного решения на основе Radix.
Кхем. Radix trees тогда уж.
Key-Value на radix trees в памяти были и тогда, есть и сейчас. tkvdb был (и есть) редкий пример реализации с возможностью хранения деревьев на диске в виде append-only структуры и транзакциями (ну, условными).
Так действительно же диковатое заявление, не чувствуете? Хотя, может вы много с AI общаетесь. Про Оперу, кстати, хороший пример. "Компания Opera переходит на движок Chromium и бросает вызов Google" - нормально звучит?
Точнее, key-value на B-деревьях (B-tree) глубины 1.
Таким БД несколько тысяч лет, все докомпьютерные библиотечные каталоги были построены на похожих принципах, начиная с библиотек глиняных табличек.
Ящики с карточками ("корешками"), индексировались по первым буквам авторов/названий. Как только ящик переполняется, создается новый ящик (узел верхнего уровня) и карточки из одного ящика перераспределяются по двум.
Создатели B-tree естественно знали эту технологию и прямо по ней сделали компьютерный аналог.
Технически особых пределов для мощности атак нет. Все упирается в пропускную способность линков. Как атакующих, так и жертв.
В статье не так уж много подробностей, но скорее всего это была UDP-амплификация со скоростью
585 million data packets per second
Это не так уж и много, одно устройство со 100Gbe линком может генерировать в пике до ~140 миллионов pps. Обычные 10Gbe карты могут генерировать ~14mpps. То есть теоретически для такой атаки достаточно буквально несколько десятков непосредственно атакующих устройств. Они отсылают трафик на взломанные/плохо сконфигурированные хосты, трафик амплифицируется и получаем те самые ужасающие терабиты.
Более того, у подавляющего большинства операторов нет даже никаких "историй посещения сайтов". Операторов заставляют ставить отдельно коробку с СОРМ, а управляют этой коробкой и берут оттуда данные совершенно другие люди, не операторы.
Обычно вся статистика которая есть у оператора - это семплированный netflow/ipfix. В нем вообще ничего не видно кроме IP адресов, протоколов и портов. При семплировании 1:500 в эту статистику попадет каждый 500-й пакет, а у крупных операторов бывает sampling rate и 1:10000.
То есть "историю поиска" могут дать только поисковики. Ну да, можно увидеть ее в браузере искавшего, но это какой-то уже странный случай.
Не специалист по этому всему, но в Pascal же чуть ли не с рождения были variant records? Википедия считает что это и есть tagged unions https://en.wikipedia.org/wiki/Tagged_union#1970s_&_1980s
В C тоже можно сделать tagged unions "на коленке", но нужно следить вручную за тегами. В телекомах это вообще такая классика, используется в куче протоколов и есть даже специальный термин TLV (type-length-value / tag-length-value) https://en.wikipedia.org/wiki/Type–length–value
Линейное чтение больших файлов (большими кусками) - да, будет приблизительно одинаково. Если нужно возиться с одними и теми же данными в небольшой области - mmap-решение может быть проще и быстрее.
Но вообще кеширование есть в "обычных" fread/fwrite из libc, размер буфера можно потюнить, непонятно почему сравнивали только сисколы read/write с mmap().
Да, но с нюансами. read/write при ошибке чтения/записи возвращают эту ошибку, и обычно программист к этому готов. С mmap в таком же случае приложение может получить SIGBUS и упасть. Программист и пользователи обычно к этому не готовы.
Управлять памятью в случае с mmap тоже сложнее. C read/write вы выделяете буфер и с ним работаете, все более-менее предсказуемо. А если вы сделаете в виртуалке с 8Gb памяти mmap на файл 32Gb и начнете его читать в разных местах, то контролировать память становится довольно проблематично. Все будет делать ОС, и иногда довольно непредсказуемо.
Насколько я понимаю, получаем чей-то эмулятор ZX Spectrum, уже написанный. Робот просто заимствует код.
Сможет ли нейронка написать эмулятор для несуществующей архитектуры?
И вообще, сделать то, чего раньше не существовало?
Я видел со стороны несколько попыток заставить LLM написать нетривиальное, все провальные.
Недавно на гитхабе начали переделывать и сломали статистику по трафику репозиториев. Изменили графики посещений и клонирования (в худшую сторону), перестали показывать сайты с которых перешли и популярный контент.
Не то чтобы это была какая-то суперважная фича, но иногда интересно было посмотреть.
Судя по
можно и не дождаться, когда починят.
Насколько я понимаю, Гарда использует (если использует, конечно) поиск аномалий в сетевом трафике. Они же не могут показывать каждую аномалию человеку для валидации, это было бы странновато. Обычно на аномалии нужно очень быстро реагировать.
А вообще интересно, насколько это реально работает с сетевыми аномалиями, что можно детектировать (атаки? сбои оборудования?) и насколько хорошо это получается.
EDIT: не туда ткнул, это был ответ @mvasilev-ai
Да, аллокации/деаллокации на куче влияют на производительность.
У проекта DPDK есть гайд по написанию высокопроизводительного кода. Не для геймдева, конечно, а для обработки сетевого трафика (там требования к производительности и надежности бывают еще жестче): https://doc.dpdk.org/guides-25.07/prog_guide/writing_efficient_code.html
Это гайд для более "традиционных" Intel/ARM, причем многопроцессорных, но, мне кажется, его интересно почитать даже просто для информации.
Самодельную (но тоже опенсорсную) https://github.com/vmxdev/xenoeye/
Нам нужно не только визуализировать, а еще и реагировать на сетевые аномалии, DoS/DDoS, причем чем быстрее, тем лучше. Мы используем скользящие средние для детекции аномалий.
И мы обычно на одной инсталляции показываем статистику по разным сетям или объектам мониторинга разным пользователям (т.е. делаем мультитенантность/мультиарендность).
Недавно писал статью про наш Netflow/IPFIX/sFlow анализатор: https://habr.com/ru/articles/909132/
Абсолютно ничего не имею против Акворадо, даже советую его использовать интересующимся пользователям на реддите, но нужно понимать, что он хранит все фловы. Для кого-то это плюс, для кого-то довольно бессмысленно - для того чтобы раз в неделю грубо посмотреть разбивку трафика по своим сетям, GeoIP или AS нужно иметь хорошее такое хранилище. Плюс он вместе с Кафкой не очень легкий:
Да простят меня Настоящие Хайлоадеры, но мы вместо Кафки используем просто файловую систему - нужная статистика складывается в файликах на диск и отдельным процессом экспортируется в PostgreSQL или ClickHouse.
Ну и предобрабатываем данные внутри коллектора. Наверное это тоже неправильно с точки зрения Настоящей Хайлоад Архитектуры, но позволяет обрабатывать до 700k fps на одном vCPU (когда много объектов мониторинга, то меньше, конечно).
Одно неловкое движение и пальцы рубит винтом меча.
Можно будет узнавать владельцев таких мечей при рукопожатии. Очень удобно.
Да.
Нет. Когда процессоры Intel перешли на 32 бита, регистры общего назначения расширили до 32 бит. AX -> EAX, BX -> EBX и т.д.
BX не объединяли с AX для получения EAX.
Когда переходили на 64 бита, провернули приблизительно такой же трюк. EAX расширили до RAX, EBX до RBX и т.д.
Какое-то мучительное получилось копирование. Иногда такое делают без промежуточного регистра
push cspop dsИз .com файла можно выйти просто инструкцией ret. Вот объяснение как это работает https://devblogs.microsoft.com/oldnewthing/20200309-00/?p=103547
Да, к фидбекам и вообще к комментариям "из интернета" нужно относиться с осторожностью.
Сейчас перепроизводство софта, почти всегда можно найти аналог. Если реальным пользователям что-то не нравится, они как правило молча (и без фидбека!) переходят на другой продукт.
В интернете часто пишут вообще далекие от предметной области люди, причем с видом экспертов. А эксперты не пишут, им это не очень интересно.
Какой-то странный феномен - личное (или даже оффлайновое) общение с реальными пользователями бывает полезнее и интереснее, чем сообщения от анонимных людей "из интернета".
Иногда вижу еще один вид негативных отзывов - от евангелистов ПРАВИЛЬНЫХ технологий.
Программа/библиотека написана не на любимом языке программирования - у евангелиста моментально полыхает: "ха-ха, ну сразу же видно какой это глючный отстой, я пользуюсь штукой написанной на Правильном ЯП и всем советую!!1" (штука делает не то что нужно, но кого это смущает).
Не используется любимая технология комментатора - "буэ, что за рукожоп это делал вообще, вот смотрите как нужно делать: <рассказ о продукте, который делает вообще другое>".
Очень странное ощущение, когда о тебе пишет нейросеть.
Да, скриншоты она почему-то не смогла.
Хотя, все эти визуализации выглядят более-менее одинаково. Обычно это time series и опционально отчеты за крупные периоды - столбчатые/круговые диаграммы потребителей трафика, генераторов, AS, гео-распределения и т.п.
Вроде почти у всех можно посмотреть и другие поля, типа распределения трафика по TCP-флагам, TTL, IP протоколам, TCP/UDP портам.
Можно заглянуть в каждый из проектов, там будут картинки. Или загуглить что-то вроде netflow reports и посмотреть картинки. Они у всех приблизительно одинаковые, там сложно придумать что-то оригинальное.
Про xenoeye недавно писал на хабре, там есть и скриншот графаны.
https://habrastorage.org/r/w1560/getpro/habr/upload_files/419/b9d/ab3/419b9dab3d98780062b1e2e479da8697.png
Основные отличия между netflow анализаторами как раз не в визуализации, а в другом - может ли анализатор реагировать на аномалии, как у него реализованы объекты мониторинга (если реализованы вообще), если ли возможность разным группам пользователей показывать разные отчеты и т.д.
Кхем. Radix trees тогда уж.
Key-Value на radix trees в памяти были и тогда, есть и сейчас. tkvdb был (и есть) редкий пример реализации с возможностью хранения деревьев на диске в виде append-only структуры и транзакциями (ну, условными).
Так действительно же диковатое заявление, не чувствуете?
Хотя, может вы много с AI общаетесь.
Про Оперу, кстати, хороший пример.
"Компания Opera переходит на движок Chromium и бросает вызов Google" - нормально звучит?
Что за дичь я читаю.
Ну, что-то да знает, конечно.
Но, судя по тому, что ТСПУ все-таки умеют обходить, ему бы тоже не мешало почитать книги, не только писать.
Для меня это выглядит приблизительно как "ГАИшник пишет книгу о том, как делать автомобили".
Это тот самый RDP, который делает ТСПУ?
Мне кажется упоминать это - так себе промоушен для книги, не?
Это же key-value, не?
Точнее, key-value на B-деревьях (B-tree) глубины 1.
Таким БД несколько тысяч лет, все докомпьютерные библиотечные каталоги были построены на похожих принципах, начиная с библиотек глиняных табличек.
Ящики с карточками ("корешками"), индексировались по первым буквам авторов/названий. Как только ящик переполняется, создается новый ящик (узел верхнего уровня) и карточки из одного ящика перераспределяются по двум.
Создатели B-tree естественно знали эту технологию и прямо по ней сделали компьютерный аналог.
Классический
goto cleanupна чистом C вроде не так пишут?Обычно он выглядит приблизительно так:
Технически особых пределов для мощности атак нет. Все упирается в пропускную способность линков. Как атакующих, так и жертв.
В статье не так уж много подробностей, но скорее всего это была UDP-амплификация со скоростью
Это не так уж и много, одно устройство со 100Gbe линком может генерировать в пике до ~140 миллионов pps.
Обычные 10Gbe карты могут генерировать ~14mpps.
То есть теоретически для такой атаки достаточно буквально несколько десятков непосредственно атакующих устройств. Они отсылают трафик на взломанные/плохо сконфигурированные хосты, трафик амплифицируется и получаем те самые ужасающие терабиты.