Потестил. Насчет тормозов не скажу, т.к. сам думал над этим и ниче не придумал.
Но вот мне что интересно. Почему через баш и через командную строку такие разные результаты, аж в 2 раза, при том что команда для курла вроде та же?
Или лыжи не едут, или я что-то упускаю.
У вас тоже не получилось увидеть тормоза в курле?
Не знаю, может cygwin под виндой медленно работает.
Я попытался максимально повторить в курле запрос браузера, но тспу на курл все равно не реагирует. Я даже урл использовал не только googlevideo.com, а весь длинный со всеми параметрами, Если не получится увидеть в курле тормоза, то и тестировать им тоже не выйдет. Может как-нибудь сделать, чтобы хром притворился курлом и его тоже блочить не будут 
?
Я бы не сказал что ТСПУ не реагирует в моем случае. У меня всё сводится к 2 вариантам: либо курл показывает что всё окей, либо соединение полностью стопорится.
Единственное исключение - это сервера моего провайдера. Они до ТСПУ стоят, и с ними там странная история. Я тут уже много про это писал, но по сути, там проблема не на канале между мной и ими, а между ними и внешней сетью. Через курл это не увидеть, а вот через ytdlp - можно.
Выглядит это так: берешь какой-то супер-непопулярный зарубежный видос, начинаешь его качать. Yt-dlp присасывается к ближайшему серверу (т.е. провайдерскому). Скачка идет как черепаха. Потом останавливаешь на 50%, например. Удаляешь всё что накачалось и начинаешь заново. И - о, чудо! - до 50% скачивается за секунды, а потом опять начинает ползти как черепаха.
То есть отдача уже закэшированного там идет быстро. Но сам сервер не может нормально получить данные извне.
Хз, чем это вызвано. Перегрузка канала? Козни РКН?
Из-за этого мне пришлось в браузере заблочить провайдерские сервера через ublock. Они дикие таймауты при перемотках вызывали.
Вставлять нужно полный URL или только адрес домена? В одном случае у меня статусы 000 идут по всем протоколам, в другом 404.
Всегда 404, 200 вообще не было ни разу
С чего вы решили, что сервер вам должен 200 отправлять? На этом сервере сайта нет. 404 это нормально это тоже ответ сервера, 200 не обязательно. Попробуйте через браузер зайти на корректный урл, например,
https://rr1---sn-n8v7znz7.googlevideo.com
увидите не 200, а ERR_CONNECTION_RESET или Status: 000 в тесте. Т.е. сервер не ответил, а он и не обязан был отвечать.
На запрос
http://rr1---sn-n8v7znz7.googlevideo.com
придет Status: 404
Это зависит от настроек сервера на что он отвечает, а на что нет.
Нужно пробовать. Цель полностью повторить запрос браузера в тесте. У меня не получилось подобрать такие параметры запроса, на которые тспу выдавал бы задержки идентичные браузеру. Вставлять нужно такой минимальный урл, на который поведение сервера будет таким же как и в браузере. Т.е. если в браузере запросы красные, то в тесте Status: 000. Если в браузере висит Pending и запросы приходят, но с задержками по 5-10 секунд, то такие же задержки должны быть в тесте. В скрипте нужно не только полный урл указывать, но и заголовки, пэйлоад конкретно ваши вставлять, может что-то еще, потому, что мы не знаем на что тригернет тспу.
На данный момент курл показывает только ситуации когда сервер совсем ничего не отвечает, а замедление не показывает никак. Видимо нужно открывать Wireshark и более тщательно подделывать запрос браузера в скрипте.
А нельзя в таком случае как-нибудь подвязать chromedriver? Вместо того, чтобы по кускам собирать запрос для курла, может сам браузер проще анализировать/модифицировать?
Как вы в браузере будете замерять задержки пакетов и перебирать несколько тысяч комбинаций различных настроек обхода блокировок?
Я лишь предлагаю мысль для развития идеи) Уж возможно это или нет, я сказать наверняка не могу.
Да никто ничего не должен) Что в браузере 404 - в курсе. На вашем скрине ответ 200 - как вы его получили?
Открыл инкогнито вкладку хром. Дождался пока сервер моего провайдера начнет тормозить в браузере. Скопировал из браузера в скрипт полностью урл, всю длинную строчку с параметрами до конца, не ограничиваясь googlevideo.com, все заголовки. Сейчас тот же запрос выдает Status: 403 вместо 200. Видимо, на сервере есть таймер срока действия параметров. Я же говорю, я пытался полностью повторить запрос браузера.
Насколько я знаю, там дело в параметре n=, который является ключом безопасности. Ютуб расчитывает его на ходу по алгоритму, который находится в base.js. Если ключ неправильный - данные не отдаются. Это их политика борьбы со сторонними ютуб-приложениями, качалками и т.д.
Однако, там вроде есть какая-то дыра, связанная с андроидом (с приложением ютуба?) Поэтому тот же yt-dlp или парсер из PotPlayer, притворяются андроидом, лезут в ютубовский base.js, рассчитывают ключ n= и скачивают видос подставляя найденное значение.
Короче, сложно.
Вы копировали cURL (Bash)? У меня почему-то такой запрос возвращает 411
Я не понимаю что вы спрашиваете. Я копировал всю строчку Request URL из браузера прямо в скрипт.
Кстати, хорошая идея! Можно прям из yt-dlp запрос скопировать, yt-dlp же также тормозит из-за тспу. И прикрутить к нему перебор всех стратегий обхода из блокчека. Будет всего лишь один скрипт, запустил его, и он без всяких подборов параметров сам установил рабочую стратегию обхода.
Но я ничего не рассчитывал, просто скопировал из браузера и мне 200 пришло. Хотя, может, самого видео контента в ответе и не было, я не проверял.
А разве это не сигнализирует, что стратегия рабочая? При блоке что-то в консоли никаких 200 и близко нет
Нет. В браузере полно ответов 200, но они идут с задержкой 5-10 секунд вместо обычных 300 ms.
Вот про это 
А, вы об этом. Да, можно и так. Без разницы как вы урл и заголовки скопируете. Только ипишник свой не палите.
Но думаю надо делать как Ori предложил, через yt-dlp с расчетом ключа, чтобы запрос постоянно работал, а не отваливался со временем.
А я вот думаю, не забанит ютуб в таком случае по ip-нику? Мне и так про бота все время пишет, без кук через yt-dlp качать не дает…
Надо посмотреть как в yt-dlp это сделано и сделать также. Зачем заново изобретать и что-то придумывать?
