LINUX.ORG.RU

Прокси для браузера из связки SSH + Putty тормозит

 , , , ,


1

3

Есть несколько прокси настроенных одинаково, до них примерно по ping по 60-80 мс. скорость серверов по тестам НЕ падает ниже 5 Мбит/с в обе стороны. Все сервера используются как прокси для браузера в связке SSH + Putty (туннель через SSH). Один из серверов жутко медленно открывает страницы, от 6-25 сек. Другие сервера открывают по 1-3 сек. На серверах кроме SSH ничего не запущено. Почему могут быть такие тормоза?

настройки что менялись:

- в resolv.conf прописывались DNS сервера Googl'a 8.8.8.8 и самого провайдера VPS. без изменений, все тормозит. Сервера менялись я проверяла.

- в sshd_config прописывались:

X11Forwarding no
UseDNS no
у кого-то от этого стало работать быстрее но у меня нет.

При всем этом просто консоль в Putty работает нормально, быстро открывается и быстро вводятся и получаются ответы на введенные команды.

Из-за чего страницы могут так сильно тормозить, где еще какой параметр поменять чтобы попробовать ускорить открытие страниц в браузере?

Ответ на: комментарий от bodqhrohro_promo

основная страница html загружается первой и довольно быстро, а потом грузятся остальные данные со страницы, картинки, шрифты... и вот они почему то очень долго грузятся, хотя размер у них маленький. иногда бывает что и не дождешься загрузки, приходится жать F5 чтобы обновить страницу. https://postimg.org/image/ef7qusp2j/

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

Может, пакеты теряются? А если параллельно с загрузкой страницы пинговать с сервера что-то часто?
Например ping 8.8.8.8 -i 0.1
Каковы значения mtu?

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

пробовала пинговать, явных проблем с потерей пакетов нет. Теряется 1-2 пакета из 1000. Ответы от DNS Googl'a 3-4 мс. Он буквально тут возле VPS, теряться нечему. для eth0: mtu = 1500 стандартное значение; для lo: mtu = 65536 тоже стандартное значение.

на всех серверах эти значения одинаковые. явных потерь нет, пинги до DNS Googl'a по 4мс. Но на одном из серверов сидит барабашка и тормозит просмотр страниц.

AnastasiaM
() автор топика
Ответ на: комментарий от mandala

по sftp данные на сервер / с сервера хорошо гоняются: скачка с сервера примерно 5 Мбит/с; загрузка на сервер примерно 2 Мбит/с. сейчас скорость немного просела, обычно выше.

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

AnastasiaM
() автор топика
Ответ на: комментарий от mandala

профиль браузера нормальный, там все вылизано и настроено. проблема в том что есть несколько одинаковых серверов, настройка одинаковая, ОС и приложения одинаковые, только разные реселлеры. меняем прокси в браузере и получаем три проски работают как нужно, а четвертый тормозит. До проксей одинаковый пинг и скорость скачки загрузки на них примерно одинаковая. У меня есть предположение что реселлер криворукий и что-то накрутил не так, вопрос могу я это как-то исправить настройками на самом VPS или нет?

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

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

mandala ★★★★★
()
Ответ на: комментарий от mandala

с нуля ОС ставилась 3 раза, притом 3 разных дистрибутива. Тех поддержки нет как таковой решать через нее что-то бесполезно, там сидят блондинки, уже пробовала. Если такой расклад и все так плохо, то просто нужно съехать от этого реселлера и не продлевать VPS, благо есть другие.

AnastasiaM
() автор топика
Ответ на: комментарий от mandala

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

Возможно есть какой-то параметр с виду не относящийся вообще ни к чему и который влияет на работу связки SSH+Putty. Вопрос: что это за параметр который можно подкрутить на VPS или в Putty?

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

просто нужно съехать от этого реселлера и не продлевать VPS, благо есть другие

Скорее всего, именно так.

Как я понял, скорость закачки проверялась между локалхостом и впсом. Но проблема может быть на участке vps — Internet. Я бы ещё этот момент проверил чисто ради спортивного интереса. А если интерес исключительно практический, а не спортивный, то см. п. 1. :-)

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Если проверять участок vps — Internet, т.е. просто скачивать данные с интернета на VPS то на вид все нормально. для теста использовался:

https://github.com/hidden-refuge/bench-sh-2

скорости скачки хорошие, явных тормозов нет, скорости от 26 до 402 Мбит/с. Диск тоже шустро работает.

Location                Provider        Speed
CDN                     Cachefly        23,8MB/s

Atlanta, GA, US         Coloat          2,06MB/s
Dallas, TX, US          Softlayer       3,71MB/s
Seattle, WA, US         Softlayer       4,08MB/s
San Jose, CA, US        Softlayer       2,64MB/s
Washington, DC, US      Softlayer       4,10MB/s

Tokyo, Japan            Linode          6,62MB/s
Singapore               Softlayer       3,35MB/s

Rotterdam, Netherlands  id3.net         26,1MB/s
Haarlem, Netherlands    Leaseweb        40,2MB/s


Disk Speed
----------
I/O (1st run)   : 144 MB/c
I/O (2nd run)   : 551 MB/c
I/O (3rd run)   : 542 MB/c
Average I/O     : 412.333 MB/s

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

Тут сразу по 100 метров грузится с каждого сервера, а на картинке https://postimg.org/image/ef7qusp2j/ сначала всё очень медленно, а потом нормально. Если это на всех сайтах так же, как на приведённом на картинке, то такое ощущение, что вначале оно тормозит, а потом разгоняется. Из-за чего такое может быть — шут знает. Может файрвол на сервере при соединении тупит? Кастану-ка на всякий случай anc.

aureliano15 ★★
()

Есть предположение что там какой-то dpi или сорм стоит - что обрабатывает именно http заголовки и при большом количестве запросов он захлёбывается, а всё что после заголовка уже нагрузки не даёт. Если сервер в россии, то это весьма и весьма вероятно. У меня на vpn маршрутизация так работает, что иногда я вижу заглушки от мтс, а иногда от билайна, причём это в один день и на одном подключении

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Из всего вышесказанного скорее всего реселлер настроил сеть таким образом чтобы ограничить количество новых соединений в единицу времени. Для SSH и для тестов при скачке файлов по 100 Мб это соединение RELATED,ESTABLISHED (это работает без проблем), а когда открываешь html страницу сайта - то там очень много соединений NEW для скачки картинок и прочего контента (и тут начинаются проблемы). Это никак не исправить и не изменить.

Пока вариант решения только один - переехать.

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

А реселлер работает с ЦОД напрямую или через еще одно звено? А то они могут и не знать.

mandala ★★★★★
()
Ответ на: комментарий от AnastasiaM

Проверяем ipref3 (в обе стороны)
1. между клиентом и сервером
2. между клиентом и сервером но в поднятым туннелем
3. между сервером и «сайтом» назначения (в данном случае взять хотя бы любой другой из ваших существующих для туннеля)
4. повторить все от клиента
На основании полученных данных понять где потери.

anc ★★★★★
()
Ответ на: комментарий от anc

как реселлер работает с ЦОД напрямую или через еще одно звено я не знаю, этой информации на сайте нет, но наверное напрямую арендует железо.

используя ipref3 получился такой результат:

- загрузка данных на сервер стабильная без потерь и без проблем, хоть внутри SSH тунеля, хоть на прямую, TCP/UDP все отлично.

- скачивание данных с сервера внутри SSH тунеля без потерь и без проблем. TCP/UDP все отлично.

- скачивание данных с сервера напрямую идут большие потери TCP пакетов (UDP пакеты не теряются). В секунду теряются от 1 до 4 пакетов TCP. Вывод: сервер режет отдаваемые новые пакеты.

Кажется что-то криво настроили или наоборот специально так настроили. Вопрос: если делали это осознано то зачем? Реселлеры - уроды, неделю времени на них убила, думала я криворукая.

Как я понимаю почему возникают тормоза: я беру посылаю запрос к сайту через SSH (доходит нормально) и сервер отправляет с себя запросы к сайту, куча новых запросов для скачивания контента с html станицы. часть запросов теряются, потом по таймауту браузер еще раз отправляет запросы и они доходят, так и получаются отрытия страниц по 20 секунд.

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

скачивание данных с сервера напрямую идут большие потери TCP пакетов

Ну вот и хорошо что найдено на каком участке проблема. Теперь фейсом результатами об тэйбл прова в лицо прову

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от AnastasiaM

Вывод: сервер режет отдаваемые новые пакеты. [skip] Вопрос: если делали это осознано то зачем?

Закон Яровой же.

Как я понимаю почему возникают тормоза: я беру посылаю запрос к сайту через SSH (доходит нормально) и сервер отправляет с себя запросы к сайту, куча новых запросов для скачивания контента с html станицы. часть запросов теряются, потом по таймауту браузер еще раз отправляет запросы

Скорее всего именно так. Но для чистоты эксперимента лучше проверить ещё и участок vps - сайт. Впрочем, практически это может быть полезно только чтобы поскандалить с реселлером и попытаться от него чего-то добиться. А для принятия решения о смене сервиса достаточно простого факта, что тормозит.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

это может быть полезно только чтобы поскандалить с реселлером

Кстати да, забыл еще приписать, для сандала хорошо приложить логи tcpdump. И желательно с нескольких мест. Вида: «Вот отсюда пров1, пров2, провN все работает, вот логи. А вот от вас не работает, вот логи».

А для принятия решения о смене сервиса достаточно простого факта, что тормозит.

И да и нет. С одной стороны да, «переедем и будет счастье». С другой стороны, ну а вдруг не такие уж там ублюдки сидят? Если среагируют оперативно и починят. Имхо сначала стоит попытаться ткнуть носом, а потом посылать на юг.

anc ★★★★★
()
Ответ на: комментарий от anc

VPS зарубежный, пакет Яровой там не действует.

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

AnastasiaM
() автор топика
Ответ на: комментарий от AnastasiaM

VPS зарубежный, пакет Яровой там не действует.

Ну по самой теме мы уж догадались что не здесь :)

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

Значит на юг.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.