Перейти к содержимому
Калькуляторы

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

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

 

 

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

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

Стоит:

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

Изменено пользователем mishasat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Изменено пользователем sol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Изменено пользователем sol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

во первых

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.