mishasat Опубликовано 26 февраля, 2010 · Жалоба У знакомого есть пару вайфай линков Хочу подумать насчет оптимизации передачи трафика если и там и там на концах стоят сервера на Линухе Теперь подробней Стоит: сеть-- линух потом вайфай ----- вайфай -- линух -- инет Линухи посоветовал ставить я, что б броадкаст резать и шейпить, но вот возникла идея можно ли как то поднять то ли тунель толи еще что то, что бы сжимать трафик, инскальпулирвоать мелкие пакеты в крупные, что бы более рационально использовать пропускную способность канала. Хотел применить Globax но он не фриваре, нуклеаркет не дает в свободное плаванье Может есть у кого какие наработки? Буду рад подискутировать Спасибо за ранее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 26 февраля, 2010 · Жалоба эээ, Микротик... там есть nstream. вот он и жмет и пакеты мелкие во крупные инкапсулирует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mishasat Опубликовано 26 февраля, 2010 (изменено) · Жалоба эээ, Микротик... там есть nstream. вот он и жмет и пакеты мелкие во крупные инкапсулирует.стоят булеты 2 но дело не в этом есть места где стоят сервера с обоих концов линка, а между ними например VDSL 10мбит, хочется выжать не 10 а более просто стоят 2 линуха как между ними програть оптимально трафик? П.С. интересна теория и практика Изменено 26 февраля, 2010 пользователем mishasat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavelak Опубликовано 26 февраля, 2010 · Жалоба я готового решения не втречал, НО есть стандартный интерфейс tap SOCAT с ним может работать. если мелкие пакеты маркировать через iptables, и роутить через tap на SOCAT то вполне можно решить данную проблему, хоть и через описанные костыли. с другой стороны небольшую программу написать которая будет сама открывать/передавать/закрывать tap интерфейс и склеивать пакеты и по таймеру/размеру их передавать/ принимать ИМХО не большая проблема... хотя.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 26 февраля, 2010 · Жалоба Можно поднять туннель типа пптп, там примитивное сжатие есть или опенвпн. И смотреть на тонкий тюнинг TCP, там вроде были настройки для отложенной отправки пакетов, чтобы их клеить и интервал макс задержки. А если туннель будет по тсп (пптп отпадает, там гре) то по идее и юдп будет клеится инкапсулированное. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 27 февраля, 2010 (изменено) · Жалоба я готового решения не втречал, НО есть стандартный интерфейс 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 Изменено 27 февраля, 2010 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mishasat Опубликовано 27 февраля, 2010 · Жалоба а жать пакет чем? гзипом? а вот насчет сравнения это идея спс стандартизованых вещей для этого нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 февраля, 2010 · Жалоба Жать лучше тем, что лучше сожмёт, из доступного. Выше предлагали делать сравнение перед отправкой, можно несколькими алгоритмами одновременно жать и сравнить кто лучше жмёт, то и слать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavelak Опубликовано 27 февраля, 2010 · Жалоба не нужно ничего сжимать -- это сильно усложняет. а если делать через socat - то достаточно написать небольшую программу которая умеет stdio и функцию таймера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 28 февраля, 2010 (изменено) · Жалоба Ну да. В принципе, если процессора много, то можно жать несколькими алгоритмами. И выбирать оптимальный. В предложеном 16 бит заголовке непотрачено еще 4 бита. можно похерить флаг пожатости и выделить 2-3 бита на флаг алгоритма сжатия. 000 - несжатый пакет. да, и если там IP , то можно применить VJ алгоритм для дополнительного сжатия заголовков ip, хотя не ясно, есть ли в этом смисел. Ибо весь пакет все одно пожмет сжиматель и выкинет оттуда всю избыточность. Хотя, т.к. сжиматель жмет каждый пакет по отдельности, то не выкинет он избыточность заголовков ибо она межпакетная. В принципе, можно жать оптом весь тандем. и при приходе очередного пакета, сжимать этот новый тандем и смотреть, вписался он в 1500 или нет. Можно иметь буфер 4-10 входящих пакетов и какой нибудь эвристикой выбирать из них наиболее плотно пакующиеся в 1500 байт Дело за программером. Я пишу только на PERL... причем очень давно и прочно забыл даже паскаль ))) А так, почти нахаляву может интересный модуль в кернел выйти... прямо какой-то мега оптимизатор вырисовывается. борьба за каждый байт... Хотя, при дешивизне современных процов и копеечности ПЛМ, планировщик линукса давно не тот малыш... Да и вафля усилиями маркетинга идет семимильными шагами... Изменено 28 февраля, 2010 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 2 марта, 2010 · Жалоба И все умерли... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hub00 Опубликовано 2 марта, 2010 · Жалоба sol, не умерли на счет модуля кернелевского на перле. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavelak Опубликовано 2 марта, 2010 · Жалоба посмотрел сегодня на vtun.sf.net -- там практически всё что нужно для решения задачи способом, предложенным мной. модуль ядра писать -- это изврат -- легче заюзать netfilter tproxy, а там как-раз можно и на перле написать быстренько. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 2 марта, 2010 · Жалоба 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% для подобной задачи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavelak Опубликовано 2 марта, 2010 · Жалоба во первых между двумя wifi линками особой скорости всё равно не получить -- к тому-же эту самую инкапсуляцию по условиям задачи нужно делать на linux'овых машинах -- и самая дохлый писюк легко это осилит даже на перле. ansi c программистов насколько я могу ошибаться найти довольно просто везде и всюду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...