что я не так сделал?
Поставьте что он тут пишет в config.cmd
Нельзя сравнивать однопоточный Test-Connection с параллельным запуском сотни курлов.
Почему? Они к разным серверам. Если гугл забанит, то они и через 3 секунды не ответят.
Если вы найдете хоть один мск сервер googlevideo.com или вашего провайдера с пингом более 1 секунды скиньте скриншот, если вы пингуете из РФ конечно.
Я к тому, что скрипт выдает много false-positive, поэтому результат скрипта разный при каждом запуске.
Все так. Просто у вас блокнули gvt1.com видимо. Странне решение
При чём здесь Москва? Если мне нужен доступ до pixiv.net, то вредный совет заменить таймаут на 1 секунду будет выдавать намного больше false-positivenegative, чем больший таймаут.
curl -o NUL -w "time_total:%{time_total}s" https://pixiv.net
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 162 100 162 0 0 122 0 0:00:01 0:00:01 --:--:-- 122
time_total:1.320709s
Тотал тайм в данном случае не нужно, и даже тут нет секунды
Большинство людей сюда пришло обходить замедление ютуба, и в первую очередь разговор об этом. В РФ вы не найдете сервер googlevideo.com с пингом в 1 секунду. Поэтому для обхода замедления ютуба 1 секунды более чем достаточно, все что больше вредит.
У меня больше секунды, и таймаут в 1 секунду даёт ложно-отрицательный результат.
>curl -o NUL -w "time_starttransfer:%{time_starttransfer}s" -m 1 https://pixiv.net
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
curl: (28) Operation timed out after 1002 milliseconds with 0 bytes received
time_starttransfer:0.000000s
>curl -o NUL -w "time_starttransfer:%{time_starttransfer}s" -m 2 https://pixiv.net
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 162 100 162 0 0 149 0 0:00:01 0:00:01 --:--:-- 149
time_starttransfer:1.086396s
Давайте проголосуем, кто сюда пришел обходить pixiv.net, и кто ютуб.
Большинство здесь все таки за ютуб, да и замедление гораздо более сложная проблема чем обычная блокировка. Для таких частных случаев как у вас, думаю, вы и без меня знаете где поставить нужный тайминг.
А в чем проблема самому изменить скрипт на то что тебе нужно?
Я сюда пришел обходить все. И, действительно, в чем проблема изменить скрипт самому?
разница в пинге и отклике сервера может отличаться, например, утром и вечером (когда повышенная нагрузка на сеть)
Я уже все изменил, здесь проблема в другом.
Если применить самую успешную стратегию из чекера в GoodbyeDPI то процентов на 80% проблема загрузки видео ютуба проходит. Поэтому многим может показаться, что проблема решена. Но как только вы захотите убрать проблему с оставшимися периодически подвисающими 20% серверов googlevideo.com, то обнаружите, что сделать это не так просто. Результат чекера при каждом запуске разный. И это не потому, что тспу настройки поменяли. Так получилось из-за того, что сама логика проверки, реализованная сейчас, дает много false-positive.
Чтобы обойти все нужно сначала гарантированно обойти самую сложную часть, т.е. ютуб, а потом добавлять более простые случаи, пытаясь не сломать при этом обход ютуба.
так проблема с
решена?
У меня например по вечерам на некоторое время отваливается рутрекер, хотя, якобы, он и так должен работать. А потом так же сам восстанавливается. По утрам отваливается этот форум (я не про сегодня), а потом сам восстанавливается. Получается, я мог бы это время что-то суетиться, искать обходы, а потом подумать, что героически решил проблему.
В теории, можно было бы запотеть и для каждого домена свою стратегию запилить, но как будто бы не настолько оно мне надо.
Кстати, скрипт ведь тупо по списку аргументы перебирает? Что насчет похранить их в дереве и перебирать по приоритету да с балансировочкой? Пойду думать.
Мне тут приснилось, возможно всего лишь приснилось, что заблокированный от незаблокированного серверы можно отличить трассировкой. К чистому можно успешно трассировать маршрут, а заблокированный начнет дропать пакеты и отвалится по максимальному числу хопов. Я знаю что другой протокол. Всего лишь предположение.
А второе, таймаут для тестирования делать не статическим, а брать Х квантов, где квант равен avg ping. К примеру, пинг 8 мс, тогда таймаут брать условных 100 пингов (800 мс) и регрессивно итерироваться с каким-то шагом пока хендшейк не перестанет успевать.
Какая только дичь не приснится. Пойду досыпать, проснусь скажу взломали и это был не я.
Строка с пингом закомментирована не просто так, а потому что у некоторых людей заблокирован ICMP трафик, на это уже жаловались в данной теме. И в скрипте это черным по белому написано.
Убирать https тоже не вариант. Проверка при инициализации пройден, но потом будут валиться ошибки. Лучше пусть сфейлится сразу.
Тем не менее, спс за инфо, я подумаю что с этим сделать.
Хз почему так, я посмотрю.
У вас версия из шапки? Она старая, я не обвновлял. Попробуйте тестовый билд, из поста выше.
Вы адекватный вообще? Я вам прямым текстом написал, что не планирую менять дефолтную минимальную задержку, привел аргументы. А вы тут развели - какие-то голосования призываете проводить. Я, конечно, понимаю, что наглость - второе счастье, но вы мне не клиент и я вам ничем не обязан. Поумерьте пыл.
Откройте чеклист со списком серверов для проверки, выделите их все и нажмите CTRL+C, CTRL+V. Вуаля - ваши сервера теперь проверяются дважды.
Выбор кол-ва проходов в самом скрипте добавлю когда будет время.
Многие сервера банально не отвечают на пинг.
Короче, я не понимаю как работает doh в курле. Допустим у нас есть команда:
curl -4sSm 2 -w "%{time_namelookup}\n" --doh-url https://freedns.controld.com/uncensored https://ya.ru -o NUL
Она делает запрос к doh, потом к серверу и выводит время dns-lookup. У меня её результат - 1,1 секунды, что странно и много.
Вот вторая команда - то же самое но с включенным параллелизмом, результат идентичен:
curl -4sSm 2 -w "%{time_namelookup}\n" --doh-url https://freedns.controld.com/uncensored --parallel --parallel-immediate --parallel-max 10 https://ya.ru -o NUL
Вот третья команда, где мы делаем не одно обращение, а два. И неожиданно время снижается c 1.1 секунды до ожидаемых 0,1 секунды:
curl -4sSm 2 -w "%{time_namelookup}\n" --doh-url https://freedns.controld.com/uncensored --parallel --parallel-immediate --parallel-max 10 https://ya.ru -o NUL https://ya.ru -o NUL
Можно подумать, что по каким-то причинам doh игнорится для параллельных запросов. Однако если его убрать, то результат уменьшится до 0,002 секунд. То есть doh имеет эффект:
curl -4sSm 2 -w "%{time_namelookup}\n" --parallel --parallel-immediate --parallel-max 5 https://ya.ru -o NUL
Я в растерянности. Хотел прикрутить doh к скрипту, а тут такое…
а зачем вобще дох (тут) нужон? чтобы ECHить? так ето два споловиной сайта понтдерживают ету технололгию, а если ктото пользуется днсами от провайдера то ето ССЗП
ето уже становится похоже на как етот анон описывал 
Но зачем?
сюда как будто бы просится {time_connect}
У меня вот так
curl -4sSm 2 -w “%{time_namelookup}\n” --doh-url https://freedns.controld.com/uncensored https://ya.ru https://ya.ru
1.259895
0.000071
что в принципе как раз логично