Xpoint
   [напомнить пароль]

Максимальное сжатие трафика (для GPRS)

Метки: [без меток]
2004-07-03 00:42:27 [обр] Дмитрий Котеров(0/912)[досье]

Потихоньку начинаю использовать GPRS, и вот, возникла идея, как платить поменьше. (-: Но, прежде чем писать программу, хотелось бы узнать, может, что-то такое уже написано и с успехом применяется. По сему и пишу сюда.

Пусть есть стационарный сервер (на котором все неограничено и можно запускать демонов) и мобильный комп с GPRS.

Идея следующая: все исходящие соединения с ПК пропускать через один-единственный туннель (это делает socks-клиент, Permeo Security Driver, например). Однако не генерировать для каждого исходящего коннекта отдельные socks-коннекты, а, наоборот, впихивать все в рамки одного-единственного соединения-туннеля. Соответственно, и жать по bzip2 всю совокупность, а не в пределах отдельных соединений. По идее, так должен получиться значительный выигрыш (например, 2 последовательных HTTP-запроса сжимаются в совокупности лучше, чем по отдельности, это очевидно).

Все системы, которые я видел (в том числе SSH-туннель с включенным сжатием) грешат постоянными реконнектами при генерации нового исходящего подключения. А коннект - это операция, ресурсоемкая по трафику (тройное рукопожатие - как минимум 3 пакета, и все, что из этого следует).

спустя 1 час 42 минуты [обр] Дмитрий Котеров(0/912)[досье]
Кстати, забыл добавить. Zebedee:
http://www.winton.org.uk/zebedee/manual.html
грешит тем же самым - он открывает новый туннель при каждом исходящем соединении. И, более того, он (судя по документации) очень неоптимально использует bzip2.
спустя 22 часа [обр] Юрий Цитович(0/17)[досье]
А в сторону OpenVPN не смотрели? тоже тунелирование со сжатием, но как он жмет,по потокам или все, сказать не могу
спустя 33 минуты [обр] Дмитрий Котеров(0/912)[досье]
С VPN, честно говоря, не хотелось бы связываться, потому что он не работает, например, через маскарадинг. В принципе, вот прямо сейчас я сделал так: использую socks-сервер, а для сжатия пропусаю трафик через zebedee-туннель. Но проблема с лишними коннектами и, как следствие, неэффективным сжатием остается.
спустя 10 часов [обр] Юрий Цитович(0/17)[досье]
вот цитата с одного из сайтов продающих доступ через OpenVPN
: Как работает OpenVPN
Есть ряд преимуществ у это сервиса. Он базируется на SSL, поддерживает LZO и адаптивная компрессию, работает по UDP протоколу, что позволяет вам экономить свой трафик за счет его сжатия и уменьшения исходящей составляющей. Также данный сервис может работать через прокси. OpenVPN - работает практически везде, если по каким причинам у Вас не работает стандартный VPN (например: Вы используете GPRS или у Вас ограниченный доступ в интернет), то данный сервис для Вас.
спустя 6 часов [обр] Дмитрий Котеров(0/912)[досье]
Ага! Понятно. Я просто подумал, что OpenVPN и VPN - это одно и то же. Спасибо, попробую посмотреть.
спустя 43 минуты [обр] Роман Цандер aka JustVoice(0/102)[досье]
Дмитрий Котеров[досье], поделитесь, пожалуйста, в этой ветке, когда законченное решение откристаллизуется.
(я вот тоже временами на GPRS, - командировки, - и подконтрольный сервер имеется...)
спустя 17 часов [обр] Владимир Палант(4/4445)[досье]
Дмитрий Котеров[досье]
VPN - это общее название, обычно подразумевающее IPSec или PPTP. IPSec вам, конечно же, ни к чему, а вот PPTP как раз то, что надо (и маскарадинг ему не помеха). OpenVPN, судя по всему, зачем-то реализует функциональность, аналогичную PPTP, через SSL/TLS. Что ж, может на то есть причины (возможно то, что разные реализации PPTP не обязательно совместимы). Вроде бы он тем не менее позволяет отключить шифрование, а то оно израсходует больше трафика, чем сэкономится сжатием.
спустя 1 день 9 часов [обр] Дмитрий Котеров(0/912)[досье]
Ну, шифрование-то вряд ли должно увеличивать объем данных - шифруется же все уже после сжатия, а не до (иначе смысла сжимать нет вообще, не сожмется). В общем, как буду в Москве, посмотрю.
спустя 4 дня [обр] Дмитрий Котеров(0/912)[досье]

http://poptop.sourceforge.net/dox/source-howto.html

5.27 Q: I don't seem to have packet compression when I use the Linux pptpd. Why?
   A: You are correct. There is no compression. Nobody has bothered to write
code to support MPPC (which does the compression).

Получается, poptop (http://www.poptop.org)? PPTP-сервер для linux, не поддерживает компрессию?

Вообще, кстати, PPTP было бы, наверное, предпочтительным решением (там на сайте у них написано, что это стандартная для Windows технология, так что подключаться должно быть легко). Но только если там нет компрессии, никому это не надо. (-:

OpenVPN еще не щупал пока, планирую заняться.

спустя 1 минуту [обр] Дмитрий Котеров(0/912)[досье]

P.S.
Windows-драйвер от OpenVPN устанавливает виртуальный сетевой адаптер в Device manager и Сетевые соединения! Хороший знак, есть шанс, что все заработает, как надо.

Все, поехал на дачу.

спустя 11 часов [обр] Дмитрий Котеров(0/912)[досье]

Значит, докладываю по OpenVPN. Работает (но только надо ставить самую последнюю версию, 2.0 beta N, а то в старых возможностей маловато). Даже умеет роутинг настраивать.

Вначале создается секретный ключ (см. документацию) и копируется на обе машины. Затем на клиенте делается конфиг:

remote ваш-сервер 5000
ifconfig 10.3.0.10 255.255.255.0
dev tap
secret key.txt
comp-lzo
verb 4
mute 10

route-gateway 10.3.0.1
redirect-gateway 
dhcp-option DNS какой-нибудь-DNS-сервер

На сервере делается конфиг:

dev tap
ifconfig 10.3.0.1 255.255.255.0
secret key.txt
comp-lzo
verb 4
mute 10

Также на сервере же настраивается маскарадинг для переброса всех пакетов с девайса tap0 (см. ifconfig при запущенном openvpn-сервере) на eth0 (интернетовский интерфейс):

iptables -t nat -A POSTROUTING -o eth0 -s 10.3.0.0/16 -j MASQUERADE

В общем, как видите, все довольно сложно, но ничего не поделать.

Теперь насчет сжатия трафика. Видимо, он жмет каждый пакет отдельно, потому что общая степень сжатия довольно хреновая. Например, файл из 200000 букв "a" (200К), разбитый на строки по 100 штук в каждой, при передаче по FTP через openvpn сожрал примерно 35К трафика (к примеру, `gzip a.txt` дает a.gz размером в 728 байт). Плохо, что и говорить. К счасть, OpenVPN умеет пускать туннель не только по UDP, но также и по TCP, так что никто не мешает вставить между клиентом и сервером еще один туннельчик, который будет жать трафик самостоятельно. Думаю, стоит сделать так: если recv даст много данных за короткое время, жать их bzip2, а если мало - то gzip-ом.

И еще интересный вопрос. Насколько я понимаю, openvpn передает в теле данных не только исходные данные, но также и все заголовки всех-всех пакетов? То есть, он эмулирует сетевое соединение на самом низком уровне? Если это так, то накладные расходы должны быть очень велики - фактически, тело каждого пакета "оборачивается" заголовками дважды.

спустя 9 дней [обр] 30-ый(3/584)[досье]

Внимательно прочел нитку и никак не могу понять. Как чисто теоретически вы хотите сжимать данные не пакетами, а целиком. Ведь к тому мометну, как на инерфейс попали первые 100 букв "а", их уже надо отправлять, а не ждать остальных. Причем сам интерфейс понятия не имеет, будут ли дальше еще "а"... или может быть "б"...

Чтобы жать целиков явно необходим какой-то буфер, где бы эти "а" накапливались, например по тысячи штук. Написание же подобного буфера могу предположить крайне непростая задача и вряд ли ее кто-нибудь решил. Уж очень много у подобного буфера должно получится разных настроек, которые бы пришлось перенастраивать для каждого типа подключения. В частности это явно перестанет работать там где нужны постоянные "heart beats", т.е., например, в online-игре.

спустя 6 минут [обр] Владимир Палант(4/4445)[досье]
30-ый[досье]
Думаю, что Дмитрий Котеров хотел бы сжимать данные на уровне TCP-соединений - там этот буфер есть. Вот только реализовать такое сжатие все равно очень непросто...
спустя 2 дня 11 часов [обр] Дмитрий Котеров(0/912)[досье]
Ведь к тому мометну, как на инерфейс попали первые 100 букв "а", их уже надо отправлять, а не ждать остальных.
А почему бы и не подождать, скажем, 0.2 с? Если в течение этого времени ничего больше не придет, тогда отправлять, а если придет - ну так отлично!
спустя 18 часов [обр] 30-ый(3/584)[досье]
Теоретически да. Но есть сотни задач, где 0.2 секунды будут слишком большим временем, а есть еще сотни, где 0.2 будут слишком маленьким временем. Т.е. задача получается довольно специализированная и непростая...
спустя 5 часов [обр] Дмитрий Шер aka sherd(0/84)[досье]

и мы имеем:

VPN работает по UDP
встроенную буфферизацию, причем на уровне одного соединения, имеет TCP, но не UDP
Буфферизацию на уровне множества соединений не имеет никто.
PPTP понятия не имеет о том, что у него есть соединения (если я правильно представляю его место в модели OSI)

задача не решается стандартным способом - включиться, как hook поверх соединения.

остается только делать SOCKS с буферизацией, или искать, если такой уже есть. Но для сжатия на уровне всех соединений придется поступаться чем-нибудь

спустя 6 часов [обр] Дмитрий Котеров(0/912)[досье]
eсть сотни задач, где 0.2 секунды будут слишком большим временем,

Вы, видать, никогда не пользовались GPRS-ом того же MTS и не знаете, что там задержки порядка секунд при передаче. Так что - таких задач не бывает. (-:

Дмитрий Шер aka sherd[досье]
OpenVPN вроде и по TCP ходить может. Ну, даже если и не может (хотя я в документации вроде видел), то Zebedee это дело исправит: он умеет заворачивать UDP в TCP.

Socks не подходит, потому что создает отдельные соединения для каждого коннекта.

Меня больше беспокоит, что OpenVPN должна, по идее, сильно раздувать трафик - ведь она "оборачивает" уже практически физические пакеты, а там куча разных служебных заголовков понакручено, которые в реальности ну совершенно не нужны.

спустя 5 дней [обр] Владимир Палант(4/4445)[досье]
Дмитрий Шер aka sherd[досье]
PPTP работает через TCP (может быть есть и возможность использовать UDP, но стандартный режим точно TCP).
спустя 9 часов [обр] 30-ый(3/584)[досье]
По крайней мере микрософтовский PPTP работает по Generic Routing Encapsulation (GRE). По TCP он вроде только служебную информацию передает. Трафик же идет про GRE.
спустя 6 дней [обр] Дмитрий Шер aka sherd(0/84)[досье]

Дмитрий Котеров[досье]нет-нет-нет
OpenVPN работает поверх TCP/IP, все же; и вот именно служебная информация выше заворачиватся (а в ней всего-то, http-headers, или, вообще, заголовки протоколов более высокого уровня).
самое плохое в этих шифрованиях то, что энтропия полученных пакетов (которые затем уже выпускаются в Сеть) близка к нулю, то есть они несжимаемы. вот так вот.

так что архивация несовместима с шифрованием; а я не знаю, работает ли эта самая OpenVPN без шифрования. по-моему, нет, потому что бессмысленно и противоречит самой идее )

30-ый[досье]
GRE - это разве транспортный протокол? насколько я помню, эт логический протокол связывания различных модулей различных уровней связи в цепочку, по которой и передаются пакеты?

спустя 4 часа 59 минут [обр] 30-ый(3/584)[досье]
На сколько я понимаю - да. У этого протокола есть свой номер, как у TCP или UDP. Думаю подробности можно уточнить в любой серьезной книжке по защите сетей. Причем вроде в Win2000 с появлением IPSec в эту схему добавилось еще пара протоколов транспортного уровня.
спустя 1 день 3 часа [обр] Дмитрий Котеров(0/912)[досье]
архивация несовместима с шифрованием
Простите, но, по моему скромному мнению Вы ерунду сказали. Шифровать же можно (и нужно) уже после архивации, а не до нее. Соответственно, никакой несовместимости нет.
спустя 4 года 7 месяцев [обр] slonix[досье]
Не просче ли воспользоваться готовым решением. К примеру Web2zip - http://web2zip.com.
спустя 1 час [обр] Алексей Севрюков(0/1280)[досье]
slonix[досье] а 5 лет назад это решение существовало? )
Powered by POEM™ Engine Copyright © 2002-2005