потерто
Алгоритм использования медленных прокси и с обрывами связи в браузере
-
Всем привет, продумываю оптимальный алгоритм использования проблемных прокси у которых случаются обрывы связи или медленная скорость, в том числе мобильных прокси у которых происходит переключение между IP. Если у кого-то есть более интересные решения или дополнения- буду рад советам.
Пока надумал вот что:
- На некоторых сайтах при работе с такими прокси "ожидание полной загрузки" затягивается до бесконечности. Поэтому надо это отключать
- Если отключаем "ожидание полной загрузки", то устанавливаем ресурс "сколько спать после открытия сайта", вставляем действие "Спать" со значением этого ресурса после открытия сайта. Таким образом, ждем чтобы сайт подгрузился.
- Проверки наличия какого-либо элемента, если нашли, то двигаемся дальше, если не нашли, то переходим по метке или по циклу (чтобы считать количество неудачных попыток, например, и выйти из цикла, если прокси нерабочий) к повторной загрузке страницы. Важно помнить, например, при проверке авторизации, надо проверять не только элемент который появляется когда аккаунт авторизован, но и элемент когда аккаунт неавторизован, если обоих элементов нет, то значит сайт плохо загрузился и надо снова его загружать.
- Отключение картинок, возможно отключение css для облегчения загрузки сайта, возможно отключение ненужных JS
- Игнорирование ошибок (которые появляются, например, когда сайт не отвечает вообще), в случае ошибки переход по метке или в цикле к повторной загрузке
- Так как подобные методики ведут к более медленной работе скрипта, возможно, надо создавать в ресурсах переключатель между работой с прокси со стабильным соединением и проблемными, в случае, если со стабильными тоже будет работа. Возможно нужно ставить переключатели не в одном алгоритме, а в скрипте создать две параллельных ветки (фактически, дублирующих друг друга, но с разными алгоритмами загрузки сайта), переключение между которыми осуществляется в самом начале, для удобства и наглядности при доработках (ветку для стабильных прокси не трогаем, а работаем с веткой нестабильных).
- После энного количества неудачных попыток в цикле загрузить сайт можно подключаться к эталонному сайту bablosoft.com/ip чтобы скрипт четко понял если эталонный сайт не загружается, значит точно нет доступа к интернету.
Буду благодарен за мнения.
-
-
-
@romanbiz Да?только не 1,5 сек а время старта. Смотрим старт REQUEST_TIME_FLOAT и вторая строка REQUEST_TIME ответ.
На других они могут называться по другому но общий смысл один, так же на них проверяется анонимность. Самый известный http://azenv.net/ -
@tts9 Почитал документацию PHP, немного непонятно.
'REQUEST_TIME'
Временная метка начала запроса. Доступно с PHP 5.1.0.
'REQUEST_TIME_FLOAT'
Временная метка начала запроса с точностью до микросекунд. Доступно с PHP 5.4.0.
Что это и зачем это нужно в данном случае?
-
@romanbiz Смотрите вы устанавливаете прокси и запрашиваете через него сервер "судьи", время старта вы знаете (подразумевается), вы получаете ответ от сервера с точным временем. Дальше вы просто смотрите сколько шел запрос. Время указано в миллисекундах. , Float для того что бы точно определить, например ответ будет тысячные секунды. Или сотые, а вам надо отсортировать по времени задержки например не больше 400 мс. Эти серваки для php шников. Нас мало ботостроителей на почти чистом js. Версии вам пофигу) Это кто и какой ответ из них получит. Вы увидите его весь в любом случае даже на запросе
-
-
-
-
-
-
Какой-то ты слишком сложный танец с бубном хочешь замутить. По моим наблюдениям нормальные сайты (топ 500) не любят такие реконекты.
Я под свои задачи эту проблему решил так:
1)Для Gmail мобильные порты по 10 минут беру. Профиль греется рандомное время от 3 до 10 мин. Также все остальные действия стараюсь уместить в 10 минут.
2)Если это прокси с ротацией, то вообще не советую поддерживать такой реконект, там может поменяться страна, а вместе с ним язык, часовой пояс, webrtc и гео. Хотя тут надо тестить как поведет на это твой сайт.
