- Т е ты хочешь не только инкапсулировать пакеты в тоннель и шифровать, а еще и п,
 Pahanivo пробегал (?), 00:12 , 29-Мрт-24 (1)> Имеется мобильный оператор, крайне не любящий высокий PPS, packet-per-second.
> При этом порядка 90% траффика, который на данный момент роутится через openvpn/udp
> состоит из пакетов 64-128 байт.
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?Т.е. ты хочешь не только инкапсулировать пакеты в тоннель и шифровать, а еще и пересобирать их в цепочки?
Хм, имхо, из-за буферизации получится весьма рандомный джиттер бонусом к прочим доп. задержкам на обработку. Теперь у тебя вместо одного битого пакеты будет целая серия - круть, на забитом канале еще и всплеск повторных передач получить на tcp. Как при этом поведут себя реалтайм протоколы чувствительные к задержкам - думаю и Аллах не знает, но те же ip телефонисты могут тебя кастрировать за это тупым ножом, и будут, кстати, правы (а я так понимаю у тебя что-то реалтаймовское там ходит). Опять же оверхед от тоннеля никто не отменял. > Спустя 10 лет, что-то появилось, или отправят писать свой протокол? Может я что-то не догоняю с пакетной сети - но, имхо, концептуально это бред.
- Можно попробовать переключить openvpn на tcp, и не вклюючать NO_DELAY Но как уж, Аноним (4), 00:58 , 01-Апр-24 (4)
Можно попробовать переключить openvpn на tcp, и не вклюючать NO_DELAY. Но как уже тут писали это приведет к возрасранию джиттера.> Имеется мобильный оператор, крайне не любящий высокий PPS, packet-per-second.
> При этом порядка 90% траффика, который на данный момент роутится через openvpn/udp
> состоит из пакетов 64-128 байт.
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?
> По мотивам темы 10-летней давности https://www.linux.org.ru/forum/admin/10120422
> Спустя 10 лет, что-то появилось, или отправят писать свой протокол? - То есть ты хочешь собрать побольше P_CONTROL_V1, отправить их всей кучей, а пото, ACCA (ok), 22:22 , 01-Апр-24 (5)
То есть ты хочешь собрать побольше P_CONTROL_V1, отправить их всей кучей, а потом получить кучу P_ACK_V1.Ну, так себе идея.
- Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, кот, zyxman (?), 07:57 , 02-Апр-24 (6) +1
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, которая заполняется пакетами и освобождается, либо когда пакет задержан на сколько заказано, либо когда корзина переполнилась. На практике, надо померять распределение траффика, посчитать сколько пакетов в секунду проходит сейчас и поделить на сколько хочется иметь и получится 1/(задержка в секундах). Дальше это уже вопрос настройки VPN, который будет просто отправлять сразу блоком - главное что этими пайпами оно будет получать сразу вот этот блок.
В Линуксе это вобщем тоже можно сделать, но сильно менее удобно. Я экспериментировал с этой штукой, но траффик через диверт вытаскивал в скрипт и там в скрипте делал нужные мне манипуляции, это делается через юсерспейс, поэтому небыстрая штука получилась, но так точно работает, это факт.
В принципе можно переписать на С++, а также там есть ebpf кажется расширение чтобы оно прямо в ядре работало, тогда без проблем любые скорости.
По сложности, это задача на пару дней. Также подобным образом сортировал пакеты по размеру (чтобы маленькие проходили раньше больших). Поначалу экспериментов ничего не вышло, тк просто не увидел вообще никакой сортировки, потому что по учебнику сделал очень маленькую корзину и очень маленькую задержку и оно вообще не задерживало и не сортировало.
Потом проанализировал мой траффик, сколько там был период между пакетами и сделал задержку и размер буфера (корзины) так чтобы за ее время в среднем десяток пакетов накапливалось, и тогда сразу всё поехало как заказал.
- Это уже интересно, спасибо Читаю handbook и мануал по ipwf и не нахожу ничего по, Олег Бартунов (?), 09:58 , 03-Апр-24 (7)
>> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
>> по таймауту?
> Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, которая
> заполняется пакетами и освобождается, либо когда пакет задержан на сколько заказано,
> либо когда корзина переполнилась.Это уже интересно, спасибо!
Читаю handbook и мануал по ipwf и не нахожу ничего похожего на корзину, только delay применяемый для каждого отдельного пакета. Можешь ткнуть конкретно или привести некоторые правила от которых можно оттолкнуться?
А то чувствую себя хлебушком в freebsd, после 15 лет на debian. Я правильно понимаю, что чтоб с обратной стороны не получать отдельные пакеты ответов, то надо с обоих сторон [freebsd>openvp] <канал> [openvpn<freebsd]
- ipfw pipeТам в настройках конкретной трубы можно указать bw bandwidthdelay ms-de, zyxman (?), 02:00 , 04-Апр-24 (8) +1
> Читаю handbook и мануал по ipwf и не нахожу ничего похожего на
> корзину, только delay применяемый для каждого отдельного пакета.ipfw pipe
Там в настройках конкретной трубы можно указать:
bw bandwidth
delay ms-delay
queue {slots | sizeKbytes} я просто назвал корзиной буфер (тут он очередь). > Можешь ткнуть конкретно или привести некоторые правила от которых можно оттолкнуться?
> А то чувствую себя хлебушком в freebsd, после 15 лет на debian. Тут есть небольшая проблема, у меня сгорели все компы где еще был АТА а оно на старом диске. Но по памяти я нашел в интернетах пример (и чуток подправил для лучшей наглядности): sudo ipfw pipe 1 config bw 15KByte/s
# creates a pipe that only allows up to 15KB/s to go through.
# Then:
sudo ipfw add 10 pipe 1 src-port 80
# will attach that pipe to the outgoing traffic on port 80, effectively limiting the outgoing traffic of the web server.
sudo ipfw delete 10
# will remove the pipe from the port. https://gist.github.com/olegokunevych/8146412 > Я правильно понимаю, что чтоб с обратной стороны не получать отдельные пакеты
> ответов, то надо с обоих сторон [freebsd>openvp] <канал> [openvpn<freebsd] Да и нет. Диверт просто очень удобная фича bsd (freebsd, openbsd), оно просто создает сокет по правилу вида, диверт всего что идет в какой-то интерфейс (кроме tcp сокет такой-то, см далее), к нему есть стандартная либа, просто говоришь "подключиться к диверт номер такой-то" и функция будет получать на вход пакеты, которые та самая либа прям на блюдечке с голубой каемочкой, делаешь с ними что хочешь, потом по умолчанию в тот же диверт обратно отправляешь (если не отправишь просто получится drop и всё; если никто не будет слушать диверт, он просто будет всё дропать; и если надо, ты можешь создать свои пакеты и туда инжектировать). Дальше, запускается две пары прог.
На удаленной bsd которая из диверта пакеты например в tcp канал копирует с простейшей инкапсуляцией (ну просто чтобы в потоке отдельные пакеты видеть, там какой-то эскейп символ сделать и его конечно маскировать если будет в пакетах встречаться и обратно демаскировать при инжектировании обратно в стек), на местной bsd прога из канала достает пакеты, обратно декапсулирует и в локальный диверт бросает.
Ну и вторая пара всё то же в обратном направлении делает. Тонкость есть в чем, что если просто этими манипуляциями завернуть пакеты в tcp, он конечно постарается их буферизовать по максимуму, может и мегабайт в одном окне отправлять.
То есть нужно еще таймаут в прогу добавить на нашу задержку (на которую отконфигурили трубу) и по наступлению таймаута делать flush tcp. Вот, tcp делается довольно просто, дальше можно по вкусу добавить например шифрование, я обычно тупо в ssh делаю проброс tcp сокета, оно довольно быстрое, у меня например самба несколько лет через такой канал жила. ebpf идеологически то же, но программить сложнее, но там нет оверхеда на копирование в юсерспейс, поэтому заворачивалку отдельных пакетов в tcp лучше на ebpf сделать (на этапе tcp уже все оверхеды по барабану, оно и так медленное). PS честно, я уже позже про netcat узнал, наверное им тоже можно так диверты пробрасывать, но я советовать не буду, мне проще эту прогу на десяток строк написать чем разбираться.
- Спасибо ещё раз Читаю мануал ipfw и dummynet и складывается понимание, что queue, Олег Бартунов (?), 22:03 , 06-Апр-24 (10)
Спасибо ещё раз.
Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно как некий буффер чтения, при заполненной полосе bw,
при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw, НО не как буффер для накопления перед отправкой,
который опустошается (в канал с учётом bw) при заполнении или по delay.
Или delay здесь не нужен так как он будет просто тормозить все пакеты и не связан с queue?> The queue option sets the maximum amount of excess data (in packets or KBytes) that will be accepted before additional packets are refused. Собственно, как именно это будет интерпретироваться, по сути мне только это и надо,
10.1.1.111 - tun0 в клиенте локальной freebsd, 10.1.1.1 - tun0 - внешнего сервера, тоже на freebsd. ipfw add pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out
ipfw pipe 1 config bw 10Mbit/s queue 4KBytes delay 24ms Если я правильно понял, то "queue 4KBytes delay 24ms" это (4096×8)×(1000÷24) = канал 1.3Мбит/с, что существенно ниже bw 10Mbit/s Ещё вопрос, если это всё таки накопление перед отправкой, то имеет ли смысл сделать queue кратно mtu (mtu*2|4|8), и поиграть с разными mtu в openvpn? PS, канал 1.3Мбит/с - это 21k pps для пакетов по 64 байта или 10k для пакетов 128 байт, либо примерно 910 pps для 1500 Или я где-то ошибаюсь?
- Это КОРЗИНА, которая заполняется пришедшими пакетами со скоростью ограниченной b, zyxman (?), 01:32 , 07-Апр-24 (11)
> Спасибо ещё раз.
> Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно
> как некий буффер чтения, при заполненной полосе bw,
> при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw,
> НО не как буффер для накопления перед отправкой,
> который опустошается (в канал с учётом bw) при заполнении или по delay. Это КОРЗИНА, которая заполняется пришедшими пакетами со скоростью ограниченной bw, то есть если будет приходить больше, будут отбрасываться сразу.
Далее, если суммарный размер пакетов находящихся в корзине с новым больше отконфигуренного размера, или если в корзине максимальное количество пакетов, новый пакет НЕ добавляется а отбрасывается.
Далее, если пакет таки попал в корзину, включается таймер и он там сидит до тех пор пока не закончится delay, как закончится delay отправляется дальше по ipfw и удаляется из корзины (освобождает место в корзине).
Проверка производится не в абстрактные моменты времени, а строго по тикам таймера, который по умолчанию в фре 6 был 50Гц, сейчас не знаю сколько, но на современных машинках можно спокойно ставить 1000Гц, это не очень высокая точность но техника переваривает не напрягаясь. Да, за давностию лет я могу перепутать некоторые нюансы, типа в каком конце находится ограничитель скорости и тп, но логика по-моему точно такая. То есть, если вы сделаете очень маленькие буфера, при очень большой скорости будет маленькая задержка В БУФЕРАХ, но часть пакетов будет отбрасываться; если сделать очень большие буфера, будет задержка большая.
Обычно есть некоторый оптимум задержки и потерь пакетов в таких шейперах, его нужно подбирать экспериментальным путем. >> The queue option sets the maximum amount of excess data (in packets or KBytes) that will be accepted before additional packets are refused.
> Собственно, как именно это будет интерпретироваться, по сути мне только это и
> надо,
> 10.1.1.111 - tun0 в клиенте локальной freebsd, 10.1.1.1 - tun0 - внешнего
> сервера, тоже на freebsd.
> ipfw add pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out ipfw add ДЭСЯТЬ pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out
номер правила забыли, он не назначается автоматом. > ipfw pipe 1 config bw 10Mbit/s queue 4KBytes delay 24ms
> Если я правильно понял, то "queue 4KBytes delay 24ms" это (4096×8)×(1000÷24)
> = канал 1.3Мбит/с, что существенно ниже bw 10Mbit/s Мудрить не стоит. В ядре используются очень простые, даже примитивные алгоритмы, за очень редким исключением, потому что сложные алгоритмы часто дают непредсказуемо большую задержку или используют много памяти. Алгоритмы я выше привел. Разбирайтесь. Если тяжело понять просто думая, это бывает, дело житейское, можно просто на листике ручкой или карандашом нарисовать табличку как оно будет жить - один тик таймера одна строка. > Ещё вопрос, если это всё таки накопление перед отправкой, то имеет ли
> смысл сделать queue кратно mtu (mtu*2|4|8), и поиграть с разными mtu
> в openvpn? Пробовать всегда полезно, только важно строго соблюдать правила техники безопасности (типа, не играть в пятницу после обеда, еще полезно добавить перезагрузку файрволла при потере соединения в некоторое заведомо рабочее состояние - в интернетах гуглится), ну тк несоблюдение неприятно, вы же вероятно не с соседним зданием этот канал делаете, будет неприятно если потеряете контроль над удаленным сервером. > PS, канал 1.3Мбит/с - это 21k pps для пакетов по 64 байта
> или 10k для пакетов 128 байт, либо примерно 910 pps для
> 1500
> Или я где-то ошибаюсь? perl -e 'print "".(1300000/8/64)."\n"'
2539.0625
perl -e 'print "".(1300000/8/1500)."\n"'
108.333333333333 Как говорится в классике - удачной охоты!
- Локальная kvm freebsd, openvpnipfw add 10 pipe 1 udp from 10 11 9 21 to 10 11 9 , Олег Бартунов (?), 14:52 , 07-Апр-24 (12)
Локальная kvm freebsd, openvpn
ipfw add 10 pipe 1 udp from 10.11.9.21 to 10.11.9.1 out
ipfw pipe 1 config bw 2Mbit/s queue 4KBytes # лимит выше 1Мбит (-b 1M), условно, без лимита
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 122 KBytes 999 Kbits/sec 1952
[ 5] 1.00-2.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 2.00-3.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 3.00-4.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 4.00-5.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 5.00-6.00 sec 122 KBytes 1000 Kbits/sec 1953 Хост debian, проверял pps как для vnet30, так и для wlan0
Количество пакетов в секунду одинаковое tx 1 rx 1966 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1955 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1961 / pps on vnet30 tx 1958 rx 2 / pps on wlan0
tx 1961 rx 2 / pps on wlan0
tx 1955 rx 3 / pps on wlan0
tx 1964 rx 2 / pps on wlan0
tx 1954 rx 2 / pps on wlan0 Дополнительно, на хосте смотрел iptraf-ng на этих интерфейсах, и там всё те же пакеты, 58-112-192 байт, с тем же pps С другой стороны, freebsd, openvpn
iperf3 -s [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 107 KBytes 874 Kbits/sec 1.316 ms 0/1708 (0%)
[ 5] 1.00-2.00 sec 122 KBytes 1.00 Mbits/sec 1.040 ms 0/1960 (0%)
[ 5] 2.00-3.00 sec 120 KBytes 981 Kbits/sec 0.660 ms 0/1918 (0%)
[ 5] 3.00-4.00 sec 124 KBytes 1.02 Mbits/sec 0.624 ms 0/1985 (0%)
[ 5] 4.00-5.00 sec 122 KBytes 998 Kbits/sec 0.648 ms 0/1950 (0%)
[ 5] 5.00-6.00 sec 122 KBytes 997 Kbits/sec 0.614 ms 0/1948 (0%)
[ 5] 6.00-7.00 sec 122 KBytes 1.00 Mbits/sec 0.690 ms 0/1954 (0%)
[ 5] 7.00-8.00 sec 124 KBytes 1.02 Mbits/sec 0.642 ms 0/1983 (0%)
[ 5] 8.00-9.00 sec 121 KBytes 991 Kbits/sec 0.835 ms 0/1937 (0%)
[ 5] 9.00-10.00 sec 121 KBytes 994 Kbits/sec 1.394 ms 0/1942 (0%)
[ 5] 10.00-11.00 sec 124 KBytes 1.02 Mbits/sec 0.666 ms 0/1984 (0%)
[ 5] 11.00-12.00 sec 122 KBytes 998 Kbits/sec 0.614 ms 0/1949 (0%)
[ 5] 11.00-12.00 sec 122 KBytes 998 Kbits/sec 0.614 ms 0/1949 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[SUM] 0.0-12.0 sec 31 datagrams received out-of-order
[ 5] 0.00-12.00 sec 1.53 MBytes 1.07 Mbits/sec 0.705 ms 0/25053 (0%) receiver Таким образом, с лимитом (bw 2Mbit/s) выше указанного в iperf (-b 1M) 1952 пакета в секунду проходят без потерь, и без объединения.
Локальная freebsd:
ipfw pipe 1 delete
ipfw pipe 1 config bw 512Kbit/s queue 24KBytes delay 24ms
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64 [ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 122 KBytes 999 Kbits/sec 1952
[ 5] 1.00-2.00 sec 122 KBytes 1000 Kbits/sec 1953
[ 5] 2.00-3.00 sec 122 KBytes 1000 Kbits/sec 1953
С другой стороны, ожидаемо:
[ 5] 17.02-18.00 sec 54.4 KBytes 457 Kbits/sec 2.635 ms 1571/2442 (64%)
[ 5] 18.00-19.00 sec 43.8 KBytes 358 Kbits/sec 1.519 ms 1271/1971 (64%)
[ 5] 19.00-20.00 sec 43.5 KBytes 356 Kbits/sec 2.505 ms 1257/1953 (64%)
[ 5] 19.00-20.00 sec 43.5 KBytes 356 Kbits/sec 2.505 ms 1257/1953 (64%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-20.00 sec 882 KBytes 361 Kbits/sec 2.566 ms 24773/38887 (64%) receiver
Локальный хост:
tx 1 rx 697 / pps on vnet30
tx 1 rx 703 / pps on vnet30
tx 1 rx 703 / pps on vnet30 То есть, я просто получю шейпер.
При разных вариантах очереди, таймаута, полосы, получается шейпер.
Всё работает логично и правильно, и тут не должно быть никаких объединений нескольких мелких пакетов в один mtu. Так у меня изначальный вопрос был, есть ли возможность объединить в канале, например, openvpn мелкие пакеты, снизив внешний pps?
- gt оверквотинг удален Всё логично, это императивный подход, теперь надо в явно, zyxman (?), 20:09 , 07-Апр-24 (13) +1
>[оверквотинг удален]
> ipfw add 10 pipe 1 udp from 10.11.9.21 to 10.11.9.1 out
> ipfw pipe 1 config bw 2Mbit/s queue 4KBytes
> # лимит выше 1Мбит (-b 1M), условно, без лимита
> iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64
> То есть, я просто получю шейпер.
> При разных вариантах очереди, таймаута, полосы, получается шейпер.
> Всё работает логично и правильно, и тут не должно быть никаких объединений
> нескольких мелких пакетов в один mtu.
> Так у меня изначальный вопрос был, есть ли возможность объединить в канале,
> например, openvpn мелкие пакеты, снизив внешний pps?Всё логично, это императивный подход, теперь надо в явном виде завернуть пакеты в диверт сокет и пару программ, одна будет клиент, вторая сервер, одна будет пакеты из диверта отправлять в tcp сокет, а вторая получать со своей стороны и в свой диверт вкладывать.
- PS кстати, простой скрипт на перле, думаю до тысяч 50 пакетов на современной маш, zyxman (?), 20:11 , 07-Апр-24 (14) +1
> Так у меня изначальный вопрос был, есть ли возможность объединить в канале,
> например, openvpn мелкие пакеты, снизив внешний pps?PS кстати, простой скрипт на перле, думаю до тысяч 50 пакетов на современной машинке потянет, ну точно заметно больше 1500.
- вот набор ссылок по теме спрашивайте тут только не надо читать умняк насчет пол, zyxman (?), 20:32 , 07-Апр-24 (15) +1
|
Свернуть нити
Пометить прочитанным
Создать тему
