Да, arp'ы в локальной сети, но если кто-то кабелем подключился уже трудно что-то сделать. Если администратор грамотно развел всё по vlan'ам например, то дальше своего канального сегмента злоумышленник не уйдет, но не всегда ответственно подходят к таким настройкам, или не хватает квалификации.
Касательно VPN, вы устанавливаете защищенный VPN туннель до сервера A по порту N, доверенный сертификат в добросовестных VPN клиентах берется из локального хранилища. Далее весь трафик идет на этот сервер в шифрованном виде. Для злоумышленника это выглядит так что атакуемый, сходил до какого сервера, и обменивается с ним данными, но порт скорее всего не 443 и он его проигнорирует. Если же злоумышленник работает на больший диапазон портов, соединение просто не установится т.к. сертификат не будет действительным для VPN клиента.
* Но конечно многое зависит от протокола, их у нас целый зоопарк уже.
Вы правы есть решения, у нас как раз неделя освещения данной темы видимо. Статья описывает чем грозит игнорирование данной темы, и как злоумышленник получает ваши данные. Общие рекомендации которые все трубят не затоагивал чтобы не повторяться.
Снижается нагрузка на CPU серверов для сети с Jumbo Frame. Каждый приходящий пакет на сетевой карте сервера генерирует прерывание, заставляя CPU останавливать текущую работу для его обработки.
В общем случае так, если сетевая карта находится под управлением ОС. Но есть решения построенныена режиме постоянного опроса и DMA, в обход системы прерываний, например с использованием DPDK.
Доброго времени суток. Много есть решений. Обычно используют очереди(или кольцевые буферы), чтобы чаще опрашивать источник, и прокручивать обработку без лага. Ещё хорошей практикой будет декомпозировать узкое место(разбить на несколько узлов), тогда аналогичным образом будем чаще опрашивать источник.
Доброго времени суток. Для простоты представления описаны три структуры, каждой из них сопоставлен пример. Возможно не понял вопроса, уточните пожалуйста.
Доброго времени суток, посыл в том что хочется добиться предсказуемого(прогнозируемого) поведения. Работа с сетью, с диском в подобного рода фреймворках может осуществляться асинхронно, не останавливая потоки обработки. Например, в DPDK + VPP, получение пакетов сетевой карты работает в режиме опроса(пулинга), и мы можем прогнозировать задержки получения пакетов.
Отвечая на ваш вопрос, сборка мусора с моем понимании, остановит рабочий поток произвольно, обойдет граф ресурсов для освобождения, в то время как можно было заниматься обработкой.
Очень интересно почитать про такие мощные инструменты, которые предоставляет современный CMake.
Действительно CMake уже стал негласным стандартом для С++, и лично мне кажется что каждая С++ библиотека, фреймворк в 2023 году уже точно должны иметь CMakeList в своем репозитории.
Спасибо автору, за доступный контент. Предлагаю добавить в список хабов статьи, "Системы сборки*".
Язык С не создавался под ООП парадигму, и подобные конструкции лично на мой взгляд усложняют читаемость кода. Мораль - пишем на С++ если уж очень нужно ООП.
Да, arp'ы в локальной сети, но если кто-то кабелем подключился уже трудно что-то сделать. Если администратор грамотно развел всё по vlan'ам например, то дальше своего канального сегмента злоумышленник не уйдет, но не всегда ответственно подходят к таким настройкам, или не хватает квалификации.
Касательно VPN, вы устанавливаете защищенный VPN туннель до сервера A по порту N, доверенный сертификат в добросовестных VPN клиентах берется из локального хранилища. Далее весь трафик идет на этот сервер в шифрованном виде.
Для злоумышленника это выглядит так что атакуемый, сходил до какого сервера, и обменивается с ним данными, но порт скорее всего не 443 и он его проигнорирует. Если же злоумышленник работает на больший диапазон портов, соединение просто не установится т.к. сертификат не будет действительным для VPN клиента.
* Но конечно многое зависит от протокола, их у нас целый зоопарк уже.
Вы правы есть решения, у нас как раз неделя освещения данной темы видимо. Статья описывает чем грозит игнорирование данной темы, и как злоумышленник получает ваши данные. Общие рекомендации которые все трубят не затоагивал чтобы не повторяться.
Спасибо за статью. Небольшое дополнение.
В общем случае так, если сетевая карта находится под управлением ОС. Но есть решения построенныена режиме постоянного опроса и DMA, в обход системы прерываний, например с использованием DPDK.
Доброго времени суток, вопрос синхронизации потоков из разных источников заслуживает отдельной статьи на самом деле. Спасибо за уточнение.
Доброго времени суток. Много есть решений. Обычно используют очереди(или кольцевые буферы), чтобы чаще опрашивать источник, и прокручивать обработку без лага. Ещё хорошей практикой будет декомпозировать узкое место(разбить на несколько узлов), тогда аналогичным образом будем чаще опрашивать источник.
Спасибо за уточнение, В рамках обработки трафика, например в межсетевых экранах доходит и до 10 в -9.
Ещё можно отключить прерывания на изолированных ядрах. В комбинации с выводом из-под планировщика, получаем почти систему реального времени.
Доброго времени суток. Для простоты представления описаны три структуры, каждой из них сопоставлен пример. Возможно не понял вопроса, уточните пожалуйста.
Доброго времени суток, посыл в том что хочется добиться предсказуемого(прогнозируемого) поведения. Работа с сетью, с диском в подобного рода фреймворках может осуществляться асинхронно, не останавливая потоки обработки. Например, в DPDK + VPP, получение пакетов сетевой карты работает в режиме опроса(пулинга), и мы можем прогнозировать задержки получения пакетов.
Отвечая на ваш вопрос, сборка мусора с моем понимании, остановит рабочий поток произвольно, обойдет граф ресурсов для освобождения, в то время как можно было заниматься обработкой.
Очень интересно почитать про такие мощные инструменты, которые предоставляет современный CMake.
Действительно CMake уже стал негласным стандартом для С++, и лично мне кажется что каждая С++ библиотека, фреймворк в 2023 году уже точно должны иметь CMakeList в своем репозитории.
Спасибо автору, за доступный контент. Предлагаю добавить в список хабов статьи, "Системы сборки*".
Язык С не создавался под ООП парадигму, и подобные конструкции лично на мой взгляд усложняют читаемость кода. Мораль - пишем на С++ если уж очень нужно ООП.