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

Что диаграмма запросов в браузерных инструментах разработчика кажет?

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

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

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

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

А данные по sftp/scp (лучше много файлов в директории) как гоняются?

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

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

Профиль браузера чистый надо еще попробовать. Или уже?

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

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

Не знаю, может ли putty дать проблему, у меня linux и *bsd, но его я бы тоже посмотрел.

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

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

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

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

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

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

Если проверять участок 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значит на юг.