- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева

VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
да 2 от 3 отличается только числом файлов. Многопоточную закачку одного файла каюсь, не пробовал. Но вроде это не должно иметь значения.
Да и еще. Пробовал закачку неоднократно с разных ресурсов, в т.ч. и через ssh. Результат везде один и тот же. не думаю что ssh от OpenVPN с настройками
proto udp
cipher AES-128-CBC
;comp-lzo да. именно закомментарено.
будет сильно отличаться. Да и пробовал без cipher AES-128-CBC и с comp-lzo результат аналогичный.
Попробуйте изменить настройки именно OpenVPN, а не SSH.
Вводная: Имеем centos 5.2 на XEN с установленным сервером OpenVPN
имеем виндовый комп, на котором установлен OpenVPN клиент.
1) Скачиваем с виндового компа из интернета файл без OpenVPN: Скорость 170кбайт\сек.
2) Скачиваем с виндового компа из интернета файл c OpenVPN: Скорость 50кбайт\сек.
3) Скачиваем с виндового компа из интернета несколько файлов c OpenVPN: Суммарная скорость 170кбайт\сек.
Скачиваем на самом сервере скорость как и положено на хостинге порядка мегабайта.
Проблема: Собственно п.2 и есть проблема. Почему так? Кто виноват и как исправить?
нет.
я забыл сказать.
Я скачивал файл с с сервера на комп. Скорость нормальная те же 170кбит.
Ну и это шло в обход OpenVPN несмотря на то что он был включен. Это так и должно быть, как я понимаю.
Если результаты повторялись на различных файлах, из различных источников, и нет никаких лимитов в конфигах OpenVPN, то можно сделать вывод, что проблема в клиенте.
да, на разных файлах, с разными источниками. Проблема такая уже давно и уже многократно изучена, но решил вот ее победить всеже.
Но что значит, проблема в клиенте? Разве в клиенте можно что-то настроить по поводу полосы канала?
Непонятно это 50 кбайт/c стабильные или рывками?
Ну попробуйте еще mtu на физическом интерфейсе сервера уменьшить. 1200 должно быть достаточно мало.
а как посмотреть рывки, если они есть?
creator123 добавил 28.06.2009 в 17:52
несовсем понял где менять MTU. Настройка есть только для TAP WIN32 адаптера, но там изменение с 1500 на 1200 ничего не дало.
Зато провел еще один эксперимент:
Другой провайдер. 256кбит\сек.
Скорость загрузки того же тестового файла хоть с OpenVPN хоть без него составляет одинаковая. 27-30килобайт\сек. Т.е. канал занимается полностью и все отлично.
Первый провайдер, где все плохо это PPPoE соединение кабель напрямую к компу. А второй это ADSL тоже PPP с роутером в режиме NAT.
Раз вы не знаете как, просто попробуйте уменьшить mtu. Это частая проблема всех видов туннелей.
ну да, вот я на клиенте уменьшил у TAP до 1200. Нет разницы. На сервере уменьшил. Тоже без разницы. На сервере и для eth0 и для tun0
потом еще менял в конфиге openvpn
tun-mtu
и
mssfix
все это в разных комбинациях.
Пофигу. Стабильно 60 килобайт и не выше. А должно быть почти 200
mtu менять на СЕРВЕРЕ или в openvpn. Важно чтобы сервер не посылал слишком большие пакеты когда пытается "разогнаться".
да, я уже понял. менял в openvpn конфиге на сервере еще давно, ну и сейчас менял опять. Да
service openvpn restart делал.
И сейчас и у eth0 и у tun0 менял. и /etc/init.d/network restart делал.
я вот даже вижу
# ip route get 10.8.0.6
10.8.0.6 via 10.8.0.2 dev tun0 src 10.8.0.1
cache mtu 1200 advmss 1160 hoplimit 64
creator123 добавил 28.06.2009 в 18:25
и всеже. То что, при работе через другого провайдера (правда там скорость маленькая всего 256килобит) такой проблемы нет, это не может как-то прояснить ситуацию?
Ну, вероятно, дело не в этом. Вариантов масса.
Попробуйте захватить в файл пакеты одновременно на обоих концах туннеля и поизучать их. Если выложите в формате pcap и не забудете про mtu=1600 при захвате - я даже посмотрю и попытаюсь выдвинуть гипотезы.
К примеру, с провайдеров станется снижать приоритет UDP, чтобы таким образом обрадовать любителей скайпа, торентов и да вообще всего что "не фейсбук".
я ставил proto tcp не помогло.
порт менял с 1194 на разные. сейчас порт 81 используется. Тоже не помогло.
я с радостью выложу хоть в pcap хоть в чем, если скажете как это сделать ;)
ну или сейчас погуглю на тему pcap