Компрессоры трафика

[Картуччо]

Кто-нибудь применяет в практике ?

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

Существует ли какой-нибудь опенсорс на эту тему ?

[Savaoff]

к апачу был mod_gzip ;)

[Картуччо]

Да не, какой апач. Грубо говоря, это туннель с архиватором на обоих концах. Трафик должен проходить прозрачно как просто через маршрутизатор.

Раньше подобное делалось на сериальных и фрейм релейных линках, на цисках по крайней мере,

но профит был не слишком велик.

[s.lobanov]

openvpn умеет компрессию, применял, но только чисто поржать. Через ssh-тунель можно делать компрессию(openssh), очень хорошо помогает, когда выбрасываешь иксы через ssh на тормозном канале(например, adsl), т.е. как раз Ваш случай, когда приложение не умеет нормально утилизировать полосу

[Картуччо]

Надо чтобы решение справлялось с большими объемами трафика и полосой мегабит 500.

[s.lobanov]

ipsec можно попробовать, он тоже умеет компрессию и при этом не userspace

[SmokerMan]

vtun умеет жать.

[taf_321]

Ощутимая задержка это SAT?

 

http://www.memotec.com/

 

Сразу нужно сказать, игрушки не из дешевых. Но учитывая цены частот на спутниках, не лишено смысла.

[Картуччо]

Нет, ощутимая задержка это, скажем, 50 миллисекунд и приложение, которое не может разогнаться при в целом достаточной канальной полосе.

[Картуччо]

Вспомнилось как несколько лет назад видел буклеты по цискиному решению Cisco Wide Area Application Engine (WAE) Appliances.

 

И вот такое ещё есть: http://www.riverbed.com/us/

[Hawk128]

Поддерживаю vtun. Весьма многое может, в том числе и прозрачный канал со сжатием.

[nuclearcat]

vtun, openvpn, циска и прочее - имеют определенный недостаток, к примеру концептуально у них не может быть высокой степени сжатия.

Насчет того, применяет ли кто, ну я применяю, но тут думаю всем понятно, что и где :))) Аналоги есть, но практически все достойныее продались, и продаются с решениями под ключ (e.g. Tellitec/tellinet продался newtec).

Целесообразность и эффективность сильно зависит от сферы применения.

[Картуччо]

А почему у vtun не может быть высокой степени сжатия ? Алгоритмы слабые или в том смысле, что ЦПУ ляжет ?

[SmokerMan]

А почему у vtun не может быть высокой степени сжатия ? Алгоритмы слабые или в том смысле, что ЦПУ ляжет ?

Там вроде как LZH обычный. Ну и смотря что сжимать.

[nuclearcat]

А почему у vtun не может быть высокой степени сжатия ? Алгоритмы слабые или в том смысле, что ЦПУ ляжет ?

Алгоритм, причем не сжатия, а концепция работы программы вообще. Там он приятное дополнение, а не основная фича.

[Ivan_83]

Можно нарисовать ноду во фре, типа ng_zip но как будет при большой нагрузке - хз.

[Sonne]

Нет, ощутимая задержка это, скажем, 50 миллисекунд и приложение, которое не может разогнаться при в целом достаточной канальной полосе.

 

 

Вы должны точно понимать как именно работает приложение и почему оно не может разогнаться.

Потому как компрессия и акселерация задержки это совершенно разные вещи.

[Savaoff]

А почему у vtun не может быть высокой степени сжатия ? Алгоритмы слабые или в том смысле, что ЦПУ ляжет ?

Там вроде как LZH обычный. Ну и смотря что сжимать.

 

vtun opensource, можно и допилить компрессию самому, если очень хочется. Сдеать, как bzip2. Другое дело, что тот же трафик торрента, в основе своей фильмы, бесполезно сжимать, разве что на лету перепаковывать в другой видео-кодек;-)

[dignity]

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

[Картуччо]

Репликация БД или что-то вроде того. По идее тут можно пренебречь увеличением задержки в пользу хорошей степени сжатия.

[SergeiK]

Помимо сжатия надо еще задержку уменьшать. А то у вас TCP не разгонится.

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

Решали как-то проблему, так на 200 секундах задержки сервер почему-то выше 16К окно не увеличивал, да еще предлагал переговоры по этому вопросу клиенту после каждой пачки пакетов. Итого скорость 4 кбайта/сек. Реальная скорость канала была мегабиты.

 

Так вот оптимизаторы умеют перехватывать TCP, собственно трафик пересылать между собой перепакованным и по своим протоколам.

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

[telematic]

http://www.divinetworks.com/

[nnm]

http://www.juniper.net/us/en/products-services/application-acceleration/wxc-series/

[edo]

Репликация БД или что-то вроде того. По идее тут можно пренебречь увеличением задержки в пользу хорошей степени сжатия.

в одну tcp-сессию?

 

и вот что Вы упёрлись - что tcp-стек не утилизирует полную скорость канала или не хватает скорости канала?

 

а может быть клиент/сервер просто не могут выдать больше?

или использутся синхронный протокол, который чувствителен к задержкам?

 

Существует ли какой-нибудь опенсорс на эту тему ?

вбил в гугль "tcp-proxy with compression", среди результатов было

http://wanproxy.org

 

не оно?

[Ilya Evseev]

http://www.trafficsqueezer.org/ - не оно?

 

http://wiki.mikrotik.com/wiki/Manual:IP/Packing