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

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

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

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

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

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

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

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

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

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

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

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

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

Я и говорил про тунель через 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, неведомо чего хочет ТС.

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

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

А это не то же самое, что ip2ip в Linux
http://blog.rts-mirea.msk.ru/2012/09/11/туннель-ipip-между-двумя-linux/
?

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

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

Я в курсе возможных проблем с 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 или другом тоннеле если между ними посредник не знаю но спасибо, за идею, буду пробовать.

Понятно. И открытых альтернатив проприетарному варианту от микротик нет? О_о

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не работает агрегация на тоннельных интерфейсах Микротика. Только на физических интерфейсах. Остается свои

О тоннелях в микротике никто и не говорил.