LINUX.ORG.RU
ФорумAdmin

Объединение пакетов при туннелировании.


1

2

Имеется технологическое оборудование и сервер которые общаются по протоколу МЭК через IP сокет.

схема вкратце такая

Оборудование <-> роутер <-> спутниковый модем <-> спутник <-> спутниковый модем <-> роутер <-> сервер контроля и управления

http://s5.hostingkartinok.com/uploads/images/2014/01/b7f9856dd558cd758dd7757e...

Особенность протокола в огромном количестве мелких пакетов 90% трафика - пакеты менее 64 байт, 95% - пакеты менее 128 байт.

Пакеты передаются через спутниковый модем, причем спутниковые модемы очень критичны к PPS и при таком количестве пакетов не позволяют использовать всю пропускную способность канала, использование процессора уходит в 100% при использовании 2/3 канала.

Вопрос: Есть ли возможность на уровне роутеров (ПК с Linux) установить тоннель который будет не просто лепить к прилетающему пакету дополнительный заголовок и отправлять дальше, а пытаться впихнуть в один пакет как можно больше данных объединяя десять 128 байтных пакетов в один <1500 уменьшая PPS.

Возможно что то из шифрующих тоннелей типа OpenVPN получают что то подобное как побочный эффект от основной задачи шифрования?

Если транспорт у VPN будет tcp, то ты добьешься чего-то похожего.

Но. Найди и почитай документ в сети с названием что-то вроде «Почему использовать PPP-over-TCP - плохая идея». Документ по-английски, название я примерно перевел. Идея документа спорная, есть масса сторонников и противников. Я сторонник, однако в твоем случае может быть польза и будет, заранее это неизвестно.

И если воспользуешься, то по хорошему, надо будет хорошенько тюнить ТСР-стек на обеих сторонах. Тк спутник, задержки и все такое.

anto215 ★★ ()
Ответ на: комментарий от anto215

ИМХО, ему не tcp-стек нужно будет тюнить, а писать какой-то «агрегатор» tcp-пакетов (патчить netcat), котороый бы пропускал через себя транспортные tcp пакеты тунеля, но стремился делать write() большими порциями. Ядро, в принципе, реализует алгоритм Нагеля, но, вроде как, граница там 50 байт, то есть объединяются в один пакет только совсем короткие последовательности данных и настроить этот алгоритм пресонально на сокет нельзя.

mky ★★★★★ ()
Ответ на: комментарий от mky

Нет. У него, судя по всему, целая контора через такой канал висит, или сам в одиночку создает разнообразный трафик. Алгоритм Нагля работает только в пределах одного tcp-соединения, а у него их куча разных, и все по мелочи, и не только tcp. VPN c tcp транспортом позволит все объединить в одно tcp-соединение и тут уже алгоритм Нагля сработает в полную силу.

Про границу 50 байт не слышал, хотя может быть в конкретных реализациях и да, не уверен. Ну и под одно tcp-соединение можно хоть все ядро потюнить, было бы желание.

И еще, для ТС замечу, если трафик - телефония, с проблемами упомянутыми в статье столкнешься обязательно.

anto215 ★★ ()

На уровне ядра штатными средствами это сделать невозможно. Пиши TCP или UDP или что-там-у-тебя прокси. В качестве бонуса, можно разработать собственный «транспортный» формат, учитывающий особенности протокола.

Можно даже заюзать TUN/TAP подсистему, кстати, не обязательно именно в линуксе. Но это серьезно усложнит софтину.

У данного подхода есть два недостатка. Во-первых, возрастет латентность. Во-вторых, резко возрастет чувствительность к потерям.

Из-за жуткого buffer-bloat (по-определению), возможен жуткий тупняк протокола... И как минимум, тебе нужно сделать какой-то собственный планировщик отправки пакетов, в противном случае эффективность упадет ниже плинтуса.

Короче говоря, работы дофига, слишком сложно, а результатны — неочевидны.

Macil ★★★★★ ()
Ответ на: комментарий от anto215

Я и говорил про тунель через tcp. Но, насколько мне известно, openvpn, хотя по умолчанию и не ставит O_NODELAY на tcp-сокет, всё равно сам пакеты не агрегирует, а на каждый пакет делает write() в сокет. Да и ppp работает аналогично. И у меня сильные сомнения, что алгоритм Нагля поможет ТС.

Посмотрел исходники ядра, про 50 байт я нагнал. Возможно, что я не правильно понял, но в ядре Линукса алгоритм Нагля старается сделать tcp-пакет размером с MSS, но с задержкой не более двух тиков часов. И это не настраивается через /proc, только редактированием ядра. Возможно, что для случая ТС эта задержка (2 мс, ЕМНИП) будет недостаточной, объём трафика не указан. Поэтому я и писал про промежуточный обработчик трафика, который пропустит через себя пакеты от openvpn, внеся настраиваемую задержку.

А вобще, не понятно, как ведёт себя tcp на 100% загруженных спутниковых каналах? Если ТСу удаётся забить 2/3 ширины канала, то, ИМХО это не так уж и плохо и упаковав пакеты в tcp он увеличит объём траифка (заголовки и ack) и, если при этом при 100% канал начнёт терять пакеты или задерживать ack, то пользы от tcp не будет.

P.S. Почитал про МЭК-61850, он как-бы расчитан на локальную сеть с минимальными задержками, на LAN, а не на WAN, неведомо чего хочет ТС.

mky ★★★★★ ()
Ответ на: комментарий от mky

как вариант погуглить исходники/маны openvpn на тему TCP_CORK. впринципе только одна эта штука делает то что нужно.

redixin ★★★★ ()

Ох как я не люблю mikrotik, но у него есть ip-aggregation. Ставите с двух сторон микротики (те же rb450g) и получаете решение, умеет делать в прозрачном бридже. Таким образом ускоряют p2p беспроводные соединения.

nickleiten ★★★ ()
Ответ на: комментарий от selivan

Нет, ipip - это туннель, а в микротике именно агрегация, то есть он собирает пакеты в один фрейм, а потом разбирает, причём даже в режиме бриджа. А туннель (любой) не обязан заниматься агрегацией трафика, у туннеля может быть такая функциональность, но задача другая в туннелях решается. Можно, например, дописать модуль к ipip туннелю для агрегации пакетов, но с этим в job или своими силами.

nickleiten ★★★ ()
Ответ на: комментарий от anto215

Идея документа спорная, есть масса сторонников и противников.

Я в курсе возможных проблем с TCP поверх TCP, не считаю их сильно существенными. Поискал существующие варианты на UDP транспорте, все добавляют оверхед и шлют дальше. никто агрегацией не заморачивается. Было подозрение что шифрованные тоннели так делают, чтобы скрыть истинную длину шифруемых пакетов, опять нет, не заморачиваются, шифруют и отсылают как есть.

VPN c tcp транспортом позволит все объединить в одно tcp-соединение и тут уже алгоритм Нагля сработает в полную силу.

Да там именно такой случай, контора, пару сотен исполнительных контроллеров у каждого минимум четыре tcp-соединения (два основных сервера и два резервных) и каждое TCP соединение генерирует пакеты 64-150 байт, необходимо агрегирование всего этого в один поток с длиной пакета ~1500 байт

На уровне ядра штатными средствами это сделать невозможно. Пиши TCP или UDP или что-там-у-тебя прокси. В качестве бонуса, можно разработать собственный «транспортный» формат, учитывающий особенности протокола.

Это понятно, вариант писать свой транспорт на UDP с отправкой большими кусками первое что пришло в голову, и некогда со счетов не сбрасывалось, вопрос в том, нет ли уже готовых реализаций, ибо изобретать велосипеды не хочется. Насчет латентности можно не волноваться при спутниковой задержке ~700мс дополнительные 1-2 миллисекунды не влияют.

как вариант погуглить исходники/маны openvpn на тему TCP_CORK. впринципе только одна эта штука делает то что нужно.

А вот за это спасибо, не обратил внимания на эту опцию, буду копать.

Ох как я не люблю mikrotik, но у него есть ip-aggregation. Ставите с двух сторон микротики (те же rb450g) и получаете решение, умеет делать в прозрачном бридже. Таким образом ускоряют p2p беспроводные соединения.

Вроде по описанию то что надо, но, возможно я ошибаюсь но ip-aggregation вроде работает только на физических интерфейсах при непосредственном подключении, будет ли оно работать на gre или другом тоннеле если между ними посредник не знаю но спасибо, за идею, буду пробовать.

UncleSam27 ()
Ответ на: комментарий от selivan

Насколько мне известно - таких нет. Я буду делать реализацию, но когда, ещё не знаю. Не хочу ставить микротик где-либо, т.к. проприетарщина, причём нагло стыренная из GPL opensource (linux).

nickleiten ★★★ ()
Ответ на: комментарий от mky

упаковав пакеты в tcp он увеличит объём траифка (заголовки и ack) и, если при этом при 100% канал начнёт терять пакеты или задерживать ack, то пользы от tcp не будет.

Агрегировав пакеты мы немного увеличим объем трафика (заголовки ack ретрансмиты и.т.д. ) но мы в разы уменьшим PPS позволяя полностью утилизировать спутниковый канал. Сейчас об утилизации канала на 100% речь не идет, 2/3 максимум что удается выжать, если удастся загрузить хотя бы на 90%, уже хорошо. А шейпить трафик, не допуская 100% загрузки канала, можно до попадания трафика в тоннель.

P.S. Почитал про МЭК-61850, он как-бы расчитан на локальную сеть с минимальными задержками, на LAN, а не на WAN, неведомо чего хочет ТС.

Спутниковый канал - четвертый и последний резерв на случай отказа всего на свете, работает, но по PPS укладываюсь еле еле, хочу иметь хоть небольшой запас, тем более по ширине канал позволяет. МЭК кстати на спутнике работает довольно сносно, большая задержка влияет не сильно.

UncleSam27 ()
Ответ на: комментарий от UncleSam27

все добавляют оверхед и шлют дальше. никто агрегацией не заморачивается.

Именно так. Причём, видел сообщение от разработчиков openvpn, что у них нет и не будет агрегации пакетов, типа, если нужна, агрегируйте чем-то другим (самописным), а потом этот трафик уже в тунель.

дополнительные 1-2 миллисекунды не влияют.

Я не уверен насчёт 2 мс. 1500 байт за 2 мс — это 6 Мбит/с, у вас такой или большей ширины канал/поток?

Это понятно, вариант писать свой транспорт на UDP с отправкой большими кусками первое что пришло в голову,

Лично я бы так и делал, если нужна только агрегация, через TUN получать пакеты, тупо засовывать в udp пакет ip-пакеты целиком и отправлять. На другой стороне разворачивать. Никакой шифрации, никакого установления соединения (авторизации).

mky ★★★★★ ()
Ответ на: комментарий от mky

Я не уверен насчёт 2 мс. 1500 байт за 2 мс — это 6 Мбит/с, у вас такой или большей ширины канал/поток?

каналы именно 6 мб/с.

видел сообщение от разработчиков openvpn, что у них нет и не будет агрегации пакетов, типа, если нужна, агрегируйте чем-то другим (самописным), а потом этот трафик уже в тунель.

глянул исходники openvpn на предмет использовать TCP_CORK, эммм, похоже действительно писать свое будет в разы проще.

UncleSam27 ()
Ответ на: комментарий от UncleSam27

Грепните по исходникам openvpn строку ″TCP_NODELAY″, будут два места, в одном месте по значению опции tcp-nodelay выставляется внутренний флаг openvpn SF_TCP_NODELAY, в другом месте (socket.c) по этому флагу для сокета выставляется флаг TCP_NODELAY.

Так что грубый патч это просто поправить функцию socket_set_flags(). Можно попробовать пропатчить, убедиться что работает (сравнив счётчики TUN-интерфейса и правила в iptables) и оценить, насколько это помогло с загрузкой канала/модемов.

И если это работает и помогает, то писать своё на базе UDP, чтобы не было overhead'а с шифрацией и затыков из-за TCP.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.