помогите идеей трафик между своими серверами

[mishasat]

У знакомого есть пару вайфай линков

 

 

Хочу подумать насчет оптимизации передачи трафика если и там и там на концах стоят сервера на Линухе

Теперь подробней

Стоит:

сеть-- линух потом вайфай ----- вайфай -- линух -- инет

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

Хотел применить Globax но он не фриваре, нуклеаркет не дает в свободное плаванье

Может есть у кого какие наработки?

Буду рад подискутировать

Спасибо за ранее.

[sol]

эээ, Микротик... там есть nstream. вот он и жмет и пакеты мелкие во крупные инкапсулирует.

 

 

[mishasat]

эээ, Микротик... там есть nstream. вот он и жмет и пакеты мелкие во крупные инкапсулирует.

стоят булеты 2

 

но дело не в этом

есть места где стоят сервера с обоих концов линка, а между ними например VDSL 10мбит, хочется выжать не 10 а более

просто стоят 2 линуха как между ними програть оптимально трафик?

П.С. интересна теория и практика

Edited February 26, 2010 by mishasat

[pavelak]

я готового решения не втречал, НО

 

есть стандартный интерфейс tap

 

SOCAT с ним может работать.

 

если мелкие пакеты маркировать через iptables, и роутить через tap на SOCAT то вполне можно решить данную проблему, хоть и через описанные костыли.

 

с другой стороны небольшую программу написать которая будет сама открывать/передавать/закрывать tap интерфейс и склеивать пакеты и по таймеру/размеру их передавать/ принимать ИМХО не большая проблема... хотя....

[Ivan_83]

Можно поднять туннель типа пптп, там примитивное сжатие есть или опенвпн.

И смотреть на тонкий тюнинг TCP, там вроде были настройки для отложенной отправки пакетов, чтобы их клеить и интервал макс задержки.

А если туннель будет по тсп (пптп отпадает, там гре) то по идее и юдп будет клеится инкапсулированное.

[sol]

я готового решения не втречал, НО

 

есть стандартный интерфейс tap

 

SOCAT с ним может работать.

 

если мелкие пакеты маркировать через iptables, и роутить через tap на SOCAT то вполне можно решить данную проблему, хоть и через описанные костыли.

 

с другой стороны небольшую программу написать которая будет сама открывать/передавать/закрывать tap интерфейс и склеивать пакеты и по таймеру/размеру их передавать/ принимать ИМХО не большая проблема... хотя....

Единственное стандартное решение - это nstream который в микротике.

 

второй вариант - это

 

я готового решения не втречал, НО

 

есть стандартный интерфейс tap

 

SOCAT с ним может работать.

 

если мелкие пакеты маркировать через iptables, и роутить через tap на SOCAT то вполне можно решить данную проблему, хоть и через описанные костыли.

 

с другой стороны небольшую программу написать которая будет сама открывать/передавать/закрывать tap интерфейс и склеивать пакеты и по таймеру/размеру их передавать/ принимать ИМХО не большая проблема... хотя.

всякие фокусы с инкапсуляцией чего-то во что-то приведут только к повышению накладных расходов. Ибо маленькие пакеты они не клеят а у больших появляется опасность фрагментации изз-за лишних заголовков. А трафик жать - а если он не жмется? если там сейчас летит рар архив?

 

 

Вобщем, если делать самому, то все выглядит примерно так:

 

1. жмем пакет.

2. сравниваем: больше нежатый пакет чем жатый. если нежатый пакет больше на 1-10 байт, то принимаем нежатый (разумная экономия процессора на передающей стороне)

2а. если размер пакета почти 1500 байт - то шлем сразу, нсли неть - то далее.

3. начинаем формирование тандема пакетов:

3а. заряжаем таймер, к примеру на 40 мсек.

3б. формируем заголовок: на каждый пакет - строчка 16 бит: 11 бит - размер пакета, 1 бит - флаг пожатости, остальные 4 бита - флаги фрагментации последней части тандема.

3в. передаем или по таймеру или по заполнении 1500 байт буфера.

4. тип пакета д.б. не ip а какой нибудь другой.

5. вся "энкапсуляция" должна делаться на 2 уровне, чтобы не влетать в оверхеад на Л3

 

Edited February 27, 2010 by sol

[mishasat]

а жать пакет чем? гзипом?

а вот насчет сравнения это идея спс

стандартизованых вещей для этого нет?

[Ivan_83]

Жать лучше тем, что лучше сожмёт, из доступного.

Выше предлагали делать сравнение перед отправкой, можно несколькими алгоритмами одновременно жать и сравнить кто лучше жмёт, то и слать.

[pavelak]

не нужно ничего сжимать -- это сильно усложняет.

 

а если делать через socat - то достаточно написать небольшую программу которая умеет stdio и функцию таймера

 

 

[sol]

Ну да. В принципе, если процессора много, то можно жать несколькими алгоритмами. И выбирать оптимальный. В предложеном 16 бит заголовке непотрачено еще 4 бита. можно похерить флаг пожатости и выделить 2-3 бита на флаг алгоритма сжатия. 000 - несжатый пакет. да, и если там IP , то можно применить VJ алгоритм для дополнительного сжатия заголовков ip, хотя не ясно, есть ли в этом смисел. Ибо весь пакет все одно пожмет сжиматель и выкинет оттуда всю избыточность. Хотя, т.к. сжиматель жмет каждый пакет по отдельности, то не выкинет он избыточность заголовков ибо она межпакетная.

 

В принципе, можно жать оптом весь тандем. и при приходе очередного пакета, сжимать этот новый тандем и смотреть, вписался он в 1500 или нет. Можно иметь буфер 4-10 входящих пакетов и какой нибудь эвристикой выбирать из них наиболее плотно пакующиеся в 1500 байт

 

Дело за программером. Я пишу только на PERL... причем очень давно и прочно забыл даже паскаль ))) А так, почти нахаляву может интересный модуль в кернел выйти...

 

прямо какой-то мега оптимизатор вырисовывается. борьба за каждый байт... Хотя, при дешивизне современных процов и копеечности ПЛМ, планировщик линукса давно не тот малыш... Да и вафля усилиями маркетинга идет семимильными шагами...

Edited February 28, 2010 by sol

[sol]

И все умерли...

[hub00]

sol, не умерли на счет модуля кернелевского на перле.

[pavelak]

посмотрел сегодня на vtun.sf.net -- там практически всё что нужно для решения задачи способом, предложенным мной.

 

модуль ядра писать -- это изврат -- легче заюзать netfilter tproxy, а там как-раз можно и на перле написать быстренько.

[sol]

1.3 What platforms are supported by TUN/TAP driver ?

Currently driver has been written for 3 Unices:

Linux kernels 2.2.x, 2.4.x

FreeBSD 3.x, 4.x, 5.x

Solaris 2.6, 7.0, 8.0

 

 

Не канает... Потом, на перле оверхеад будет 700% для подобной задачи.

[pavelak]

во первых

 

между двумя wifi линками особой скорости всё равно не получить -- к тому-же эту самую инкапсуляцию по условиям задачи нужно делать на linux'овых машинах -- и самая дохлый писюк легко это осилит даже на перле.

 

ansi c программистов насколько я могу ошибаться найти довольно просто везде и всюду.