Jump to content
Калькуляторы

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

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

 

 

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

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

Стоит:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
эээ, Микротик... там есть nstream. вот он и жмет и пакеты мелкие во крупные инкапсулирует.
стоят булеты 2

 

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

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

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

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

Edited by mishasat

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
я готового решения не втречал, НО

 

есть стандартный интерфейс 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 by sol

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Edited by sol

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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% для подобной задачи.

Share this post


Link to post
Share on other sites

во первых

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this