Почему в Firefox происходит медленная загрузка через socks proxy?

Недавно столкнулся с проблемой и хотел бы попросить у сообщества помощи.

Предыстория: в связи с последними законами(блокировки сайтов) решил настроить себе беспроблемный серфинг. VPN мне не очень подходит, поэтому выбрал туннель через SSH. Но почти тут же столкнулся с проблемой при работе в firefox: медленная прогрузка страниц. Понятно, что через прокси загрузка будет медленнее, но в данном случае она была аномально медленной. Причем проблема именно с фф, у хрома и ie с этим все нормально. Гуглил, увеличивал лимиты коннектов в about:config, но все тщетно.

Несколько дней назад решил разобраться, почему же у фф проблема с socks прокси. Для экспериментов написал socks proxy server v5. Сервер работает на той же машине, а значит задержки между прокси и браузером минимальны. Результаты примерно такие: хром грузит страницу напрямую или через прокси примерно на одно и то же время. А с фф проблема подтвердилась, скорость загрузки через прокси снижается в среднем на 30-50% и падает, если одновременно грузить несколько вкладок.

Основная разница между фф и хромом: количество коннектов. Например берем тяжелую страницу с графикой, общий вес ресурсов 25мб(все значения примерны), для полной загрузки нужно около 300 http запросов. Для загрузки хрому нужно 90 tcp коннектов, а фф 320. Кол-во коннектов в фф можно снизить где-то до 250, если отключить dns lookup через проксю, но скорости это не даст. Получается, что хром через один коннект грузит гораздо больше данных.

Отсуда возникает два вопроса:
Почему firefox через socks proxy медленнее работает, чем хром?
Почему у этих браузеров такая разница в количестве коннектов?
Заранее спасибо за помощь.

Немного техданных:
ОС Windows 8.1.
Firefox & Chrome последней версии.
Socks proxy server написан на C#, использован класс System.Net.Sockets.Socket.
  • Вопрос задан
  • 8013 просмотров
Пригласить эксперта
Ответы на вопрос 1
@mayorovp
"использован класс System.Net.Sockets.Socket" - понятие сильно растяжимое. Для сервера на базе select что 90, что 320 tcp-соединений - ерунда, а вот для "обычного" многопоточного сервера само создание 320 потоков может вызывать подтормаживания. А уж если брать при этом потоки из пула - так стандартного пула на 20 потоков не хватит никому.

Так что тут возникает два основных вопроса - какая технология создания сервера использовалась вами, и какая технология использовалась автором туннеля через ssh?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы