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

[romanbiz]

Всем привет, продумываю оптимальный алгоритм использования проблемных прокси у которых случаются обрывы связи или медленная скорость, в том числе мобильных прокси у которых происходит переключение между IP. Если у кого-то есть более интересные решения или дополнения- буду рад советам.

Пока надумал вот что:

1. На некоторых сайтах при работе с такими прокси "ожидание полной загрузки" затягивается до бесконечности. Поэтому надо это отключать
2. Если отключаем "ожидание полной загрузки", то устанавливаем ресурс "сколько спать после открытия сайта", вставляем действие "Спать" со значением этого ресурса после открытия сайта. Таким образом, ждем чтобы сайт подгрузился.
3. Проверки наличия какого-либо элемента, если нашли, то двигаемся дальше, если не нашли, то переходим по метке или по циклу (чтобы считать количество неудачных попыток, например, и выйти из цикла, если прокси нерабочий) к повторной загрузке страницы. Важно помнить, например, при проверке авторизации, надо проверять не только элемент который появляется когда аккаунт авторизован, но и элемент когда аккаунт неавторизован, если обоих элементов нет, то значит сайт плохо загрузился и надо снова его загружать.
4. Отключение картинок, возможно отключение css для облегчения загрузки сайта, возможно отключение ненужных JS
5. Игнорирование ошибок (которые появляются, например, когда сайт не отвечает вообще), в случае ошибки переход по метке или в цикле к повторной загрузке
6. Так как подобные методики ведут к более медленной работе скрипта, возможно, надо создавать в ресурсах переключатель между работой с прокси со стабильным соединением и проблемными, в случае, если со стабильными тоже будет работа. Возможно нужно ставить переключатели не в одном алгоритме, а в скрипте создать две параллельных ветки (фактически, дублирующих друг друга, но с разными алгоритмами загрузки сайта), переключение между которыми осуществляется в самом начале, для удобства и наглядности при доработках (ветку для стабильных прокси не трогаем, а работаем с веткой нестабильных).
7. После энного количества неудачных попыток в цикле загрузить сайт можно подключаться к эталонному сайту bablosoft.com/ip чтобы скрипт четко понял если эталонный сайт не загружается, значит точно нет доступа к интернету.

Буду благодарен за мнения.

[f0cus]

@romanbiz Текст ссылки
Интересны 2 последние строки, не обязательно этот, этих "судей" вагон перед использованием просто проверить. И уже тогда строить алгоритм

[romanbiz]

@tts9 спасибо.
REQUEST_TIME = 1558949711 это скорость загрузки? 1,5 секунды?

[f0cus]

@romanbiz Да?только не 1,5 сек а время старта. Смотрим старт REQUEST_TIME_FLOAT и вторая строка REQUEST_TIME ответ.
На других они могут называться по другому но общий смысл один, так же на них проверяется анонимность. Самый известный http://azenv.net/

[romanbiz]

@tts9 Почитал документацию PHP, немного непонятно.

'REQUEST_TIME'

Временная метка начала запроса. Доступно с PHP 5.1.0.

'REQUEST_TIME_FLOAT'

Временная метка начала запроса с точностью до микросекунд. Доступно с PHP 5.4.0.

Что это и зачем это нужно в данном случае?

[f0cus]

@romanbiz Смотрите вы устанавливаете прокси и запрашиваете через него сервер "судьи", время старта вы знаете (подразумевается), вы получаете ответ от сервера с точным временем. Дальше вы просто смотрите сколько шел запрос. Время указано в миллисекундах. , Float для того что бы точно определить, например ответ будет тысячные секунды. Или сотые, а вам надо отсортировать по времени задержки например не больше 400 мс. Эти серваки для php шников. Нас мало ботостроителей на почти чистом js. Версии вам пофигу) Это кто и какой ответ из них получит. Вы увидите его весь в любом случае даже на запросе

[romanbiz]

@tts9 Вот я получил REQUEST_TIME = 1558949711, что мне с этой цифрой делать дальше? Как и во что перевести? Как вычислить сколько шел запрос в секундах?

[f0cus]

@romanbiz У вас есть модуль дата и время там есть время миллисекунды в дату// Блин, написал целую простыню, но понял лучше так. Постарался максимально по кубикам разнести
0_1558953954102_azvert.xml

[DrPrime]

@romanbiz В настройках бас есть галочка Реконект. Она вроде предназначена для прокси, на которых может быть временный обрыв связи.
Советую потестировать

[romanbiz]

@drprime Нашел, "восстановление соединения", не подскажете каков алгоритм работы у этой настройки? Или лучше у разработчика спросить?

[romanbiz]

@tts9 Спасибо, теперь понял, скрипт писать было необязательно, достаточно было сказать что надо перевести из миллисекунд в дату.

[f0cus]

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

[Qwaros]

не проще ли попросту прописать функцию чека ип внешнего прокси на стороннем сайте и дергать ее по ошибке загрузки страницы?

[FastSpace]

Какой-то ты слишком сложный танец с бубном хочешь замутить. По моим наблюдениям нормальные сайты (топ 500) не любят такие реконекты.
Я под свои задачи эту проблему решил так:
1)Для Gmail мобильные порты по 10 минут беру. Профиль греется рандомное время от 3 до 10 мин. Также все остальные действия стараюсь уместить в 10 минут.
2)Если это прокси с ротацией, то вообще не советую поддерживать такой реконект, там может поменяться страна, а вместе с ним язык, часовой пояс, webrtc и гео. Хотя тут надо тестить как поведет на это твой сайт.

[romanbiz]

@drprime Поступил ответ от разработчика насчет галочки "Восстановление соединения"

Устаревшая настройка только для режима без туннелирования. Игнорируйте ее.

[Snegovik]

This post is deleted!