tgoop.com/hacksnperks/53
Last Update:
В последнее время я много работаю с сетью на уровне ОС. Это связано с моей деятельностью в сфере ИБ. Одним из последних таких проектов была самообучаемая нейросеть для IDS.
Существует известный в узких кругам мем: "У меня локально всё работает". Чтобы избежать подобных моментов крайне необходимо покрывать ваш код юнит тестами. А в случае с ПО, которое активно работает с сетью, в добавок нужно учитывать сетевые аномалии и прочие реальности сурового мира в виде задержек, упирание в количество открытых сокетов и т.п.
Как много людей задумываются о подобных вещах? Что отличает хорошего инженера от не очень хорошего? Перед тем как запустить свой проект в продуктив я озадачился подобными вопросами. И сегодня хочу поделиться с вами с тем, как искусственно добавить задержки в ваш интерфейс.
Допустим у нас интерфейс eth0, который слушает вас софт. Необходимо добавить задержек, чтобы прояснить как себя ведёт сервис. Во многих дистрибутивах есть такая утилита tc — Traffic Control, которая позволяет управлять сетевым интерфейсом.
Давайте попробуем добавить latency, изначально замерив задержку:
m@centos in ~ : ping ya.ru
PING ya.ru (93.158.134.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=1 ttl=58 time=45.2 ms
64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=2 ttl=58 time=44.4 ms
А теперь добавим задержки:
m@centos in ~ : sudo tc qdisc add dev eth0 root netem delay 700ms
И замеряем вновь:
mark@centos in ~ : ping ya.ru
PING ya.ru (93.158.134.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=1 ttl=58 time=745 ms
64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=2 ttl=58 time=744 ms
Как мы видим latency возрос так, будто бы мы используем GRPS для коннекта. Данный финт здорово помогает , если ваше приложение полагается на timeout. С помощью данной фишки можно отловить баги, которые вы бы никогда не обнаружили на своем dev сервере.
Следующим шагом можно лимитировать пропускную способность интерфейса. Это бывает важно, когда необходимо определить, как себе будет вести софт при большом количестве входных данных с малой пропускной способностью.
mark@centos in ~ : sudo tc qdisc add dev eth0 handle 1: root htb default 11
mark@centos in ~ : sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 10kbps
mark@centos in ~ : sudo tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps
Теперь попробуем замерить скорость путем скачивания файла:
mark@centos in ~ : curl -L http://mirror.neolabs.kz/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1611.iso -o centos7_x64.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 680M 0 3291k 0 0 15k 0 7:50:23 0:00:07 7:49:46 10k
Можете замерять и iperf. У меня его не было на тестовой машине.
Помимо выше описанных фич tc поддерживает:
● gact — управление пакетами, своего рода классификатор трафика. Позволяет отбрасывать, переклассифицировать пакеты.
● mirred — зеркалирование трафика на другие интерфейсы
● nat — ну вы поняли
● pedit — изменение пакетов на лету. Данная фишка очень мощное оружие в руках w/b/g-hat'а. Позволяет манипулировать трафиком как заблагорассудится. Использует вкупе с csum
● csum — пересчитывает контрольные суммы пакетов. Раз уж подделал, то соизволь сделать всё по уму.
Покрыть всё в рамках одного перка не представляется возможным. Поэтому вот список ссылок для дальнейшего самостоятельного изучения:
● ArchWiki
● LarTC
● OpenNet
#perks #hacks #trafficcontrol #tc #shaping #throttling #network #КДПВ
BY Hacks & Perks
Share with your friend now:
tgoop.com/hacksnperks/53