d4s: (Default)
[personal profile] d4s
только ради сжатия.

WiFi B open + openvpn:

scp * xxx:/var/ftp/pub/people/d4s/mkimage/
centos5.bun 100% 571MB 1.5MB/s 06:21
openmpi.bun.gz 100% 217MB 616.0KB/s 06:00

Date: 2009-11-21 13:36 (UTC)
From: [identity profile] dizel-by.livejournal.com
У openvpn оверхед дикий. К тому же имеет обыкновение периодически падать. Если и делать туннель, то ppp-over-ssh

Date: 2009-11-21 14:00 (UTC)
From: [identity profile] d4s.livejournal.com
> У openvpn оверхед дикий
ну на самом деле не такой уж и дикий. на "узких" линиях - это да. неэффективно.
пробовали tcp ?

> К тому же имеет обыкновение периодически падать
вот этого вообще не понял.
(пользуюсь уже полтора года)

> ppp-over-ssh
ну как вариант - да.

Date: 2009-11-22 07:03 (UTC)
From: [identity profile] angry-elf.livejournal.com
Для ускорения браузера достаточно туннель по ssh до прокси за пределами беларуси. Для общего (но небольшого) ускорения интернета (уменьшения лага) полезен локальный dns-кэш. В смысле, совсем локальный :)
bind на локалхосте - самое то. Важно - не использовать в качестве up-линков днс-ы провайдера, они, обычно, тормозные до немогу, а дёргать напрямую рут-серверы (сейчас меня распнут :-)).

Date: 2009-11-22 09:27 (UTC)
From: [identity profile] pestilentia.livejournal.com
Прошу пояснить про ссх. Толщина канала, выделенная провайдером, вещь afaik независимая от количества ваших туннелей, а вы предлагаете еще ресурсов подубить на заворот трафтунга в туннель.профит сомнителен

Date: 2009-11-22 09:31 (UTC)
From: [identity profile] angry-elf.livejournal.com
Компрессия плюс снижение оверхеда на количестве коннектов. Даже картинки сжимаются (ну, конечно, не сами картинки, а http-хедеры от запросов к ним. Если картинка 200-300 байт, то размер хедеров часто сопоставим с ним, т.е. имеем компрессию).

Date: 2009-11-22 09:32 (UTC)
From: [identity profile] angry-elf.livejournal.com
Ну и плюс общее улучшение латентности из-за отсутствия необходимости создавать кучу коннектов наружу.

Date: 2009-11-22 09:37 (UTC)
From: [identity profile] angry-elf.livejournal.com
Протокол SPDY от гугля собственно всё вышеописанное и должен делать - 1 коннект на сервер + сжатие хедеров.

Date: 2009-11-22 13:12 (UTC)
From: [identity profile] d4s.livejournal.com
когда мы это использовали (на одной фирме ;-) ), замер показал, что при обычном браузинге, за счет компрессии, увеличение скорости составляет в среднем в 2-3 раза.

Date: 2009-11-22 13:15 (UTC)
From: [identity profile] d4s.livejournal.com
кстати, подумалось, что, если не качок, то сейчас дешевле завести vps, чем расширять канал с 256 до 512Kbit. при куче добавочных плюсов

Date: 2009-11-22 16:02 (UTC)
From: [identity profile] pestilentia.livejournal.com
Я и сейчас вне этой самой фирмы временами пользую, но профита по скоростям не ощущаю чота

Date: 2009-11-22 13:10 (UTC)
From: [identity profile] d4s.livejournal.com
да пользовался я таким уж несколько лет назад. речь не о браузере.
у меня в универе стоит wifi в режиме open, через который доступны несколько ресурсов. для полноценного доступа надо еще коннектиться через vpn. так вот только что обратил внимание на разницу при передаче сжатых/несжатых данных, точнее на ее отсутствие.
теперь думаю - может дома завести такую же схему, вместо стандартной wpa2. или просто поверх wpa2 пустить, благо vpn у меня и так работает для доступа из-вне.
вот только боюсь, что ARM@400MHz захлебнется при попытке шифрования и компрессии/декомпрессии широкого канала :-(

Date: 2009-11-22 13:19 (UTC)
From: [identity profile] angry-elf.livejournal.com
Не очень понял, при чём тут arm. Использование любого шифрования сильно тормозит точки доступа, это без вариантов. Т.е. если ты vpn будет прокидывать не до точки доступа, а до нормального сервра, то разницу в скорости да, не увидишь, а отключив wpa2 на точке доступа, да увидишь увеличение скорости.

Date: 2009-11-22 14:31 (UTC)
From: [identity profile] d4s.livejournal.com
у меня на xscale сервер, обслуживающий домашние нужды - файлопомйка, dhcp, bind, openvpn, роутер. загнется бедняга ;-) а ставить что-то более мощное пока нет ни смысла, ни желания.

> ты vpn будет прокидывать не до точки доступа, а до нормального сервра, то разницу в скорости да, не увидишь
увижу. еще как. пример в посте - передача по 802.11B двух файлов - один сжат, другой - нет.
а отключение wpa2 на точке даст только несколько процентов прироста скорости.

Проверил. ступил, как оказалось ;-)
ну действительно! какая, нафиг, компрессия шифрованного с помщью scp трафика ? ;-))) это у меня в .ssh/config на ту машину Compression yes стояло ;-)

после этого посмотрел на передачу по ftp over vpn - компрессия есть, но не такая ощутимая: при передаче того же самого centos5.bun - передача проходит, в среднем, на скорости 750-800Kbps (в пике до 1.1Mbps), при утилизации канала на 550-600KBps. Может и больше выдало бы, но процессор на vpn сервере и так загружен на 100% ;-)

Profile

d4s: (Default)
d4s

October 2016

M T W T F S S
     12
345 6789
10111213141516
17181920212223
24252627282930
31      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2017-10-24 07:23
Powered by Dreamwidth Studios