по 10 рублей ipv6 подходят прекрасно
Начните с goodbyedpi.exe --wrong-chksum или goodbyedpi.exe --wrong-seq. Этого должно хватить.
В браузере нужно отключить QUIC (chrome://flags → QUIC)
“проблема” http3 что оно работает только через браузер или curl (wget?) тот же yt-dlp как писали выше вроде не умеет его (не уверен насчет aria2c. и можно ли yt-dlp качать через curl --http3-only)
не говоря о том что QUIC не работает через любые (даже socks5) прокси
при этом многое приходится открывать через прокси как с РКН так и наоборот блокировки РФ
p.s. хотя конркретно с гуглвидео в некоторых случаях оно (http3/quic) помогает. а как забанят ютуб целиком там уже пофик будет на ограничение скорости 
на linux.org.ru как раз обсуждают эту тему и вариант
--downloader curl --downloader-args "curl:--http3-only"
у меня пришлось менять на полный путь к нормальному curl.exe (choco/msys/etc) но работает. хоть и почему то очень медленно
еще пишут про SNI
У современных версий хром и ФФ поддержка ECH включена по умолчанию. Но работает она только если включен DoH. По этому фактически включение DoH приводит к включению и ECH.
У меня кстати работает с параметрами -f 2 -e 2 --wrong-seq --reverse-frag --max-payload или просто -6 я использую сервис вместе --blacklist, спасибо за полезную программу, вот если просто–wrong-seq то одни сайты работают у которых аплинк через транстелеком, а которые через retn ростелеком ошибка PR_END_OF_FILE_ERROR
У меня тоже работает yt-dlp + curl и тоже медленней, чем чистый yt-dlp. Причем, одинаково медленней, что с опцией --http3-only, что с --http1.1. Скорости как у тебя.
Это видимо связано с тем, что curl’у скармливается цельный URL (я посмотрел в логах запуска ps -ef | grep curl) и троттит уже гугл сторонние качалки.
А когда качает сам yt-dlp, он разбивает на фрагменты (просто прозрачно, с какой-то версии стал прятать этот процесс) и фрагменты скачиваются быстро (несмотря даже на время переподключения, но если ping небольшой, то некритично). Так работает YouTube, надо скачивать фрагментами ниже скольки-то МБ, чтобы не замедлял уже гугл.
Кстати, у меня Yota не замедляет YouTube. Правда, у меня сейчас тариф 3 мбит/с, разве что свыше замедляется. А проводной Ростелеком замедляет.
РКН ещё не признал своего участия в деграданстве, рано резать пользователей куриц несущих золотые яйца. ОПСОСы гребут бабло на нарушении сетевой нейтральности, в том числе на видео трафике. Деньги из воздуха. Но если родина прикажет – признают и зарежут. С криком банзай и ударом ноги жаровы яйца стекли в кирзачи.
Зависит в каком формате вы скачивайте видео.
Если в dash тогда пофрагментно, он даже отмечает их при скачивании. А если нет, то файл целиком скачивается.
Оно примерно и так замедляется до 3 мбит/c, поэтому вы скорее всего на таком тарифе просто не замечайте замедления.
ага про yt-dlp
-N, --concurrent-fragments N
Number of fragments of a dash/hlsnative video that should be downloaded concurrently (default is 1)
кстати когда пробовал yt-dlp --force-ipv6 + в опции curl добавил -6
что то не заметил ни разницы ни тем более “ускорения”.
сейчас же на моем провайдере и 1МБ/сек канале качает на всю… так что не проверить что там было не так
про “не замечаете” ну на yt-dlp тогда не проверял. а вот curl + SNI googlevideo даже и близко не был к скорости канала и тому что сейчас показывает
curl -o NUL -k --connect-to ::speedtest.selectel.ru https://test.googlevideo.com/10MB -w %{speed_download}
1 192 809
а было и 100КБ/сек если не меньше. временами вообще до нуля падало. даже был раз когда прервалась закачка 10МБ этих
yt-dlp не поможет нам, как и разбиение на фрагменты.
Скачивает пару мегабайт, а дальше жесткая просадка.
Спасибо! Кстати браузер Arc (chromium), без замедлений, но в Safari режется скорость. (mac os)
yt-dlp сам по себе “странный”
а корпорация зла еще круче. ибо стали резать даже для браузеров скорость в “борьбе” с качалками и всякими youtube-“gui”
как многие выше писали смотри через нормальный браузер (quic+kyber+без прокси) в статистике для админов самого ютуба. причем некоторые говорят что еще и не логинится в гугл/ютуб чтобы обойти часть возможных ограничений и тестов
мне вот провайдер выдал опять/снова ограничение до НУЛЯ после 200КБ даже а не МБ как у многих…
буду сейчас тестить yt-dlp разный (IPv6, curl -6, aria2c)
yt-dlp --force-ipv6 100% of 34.41MiB in 00:00:35 at 981.37KiB/s
yt-dlp --force-ipv6 + curl -6 -http3-only == 190 KB/s
yt-dlp --force-ipv6 + curl -6 (без http3) == те же 190 КБ/сек на HTTP/1.1 206 Partial Content
yt-dlp + aria2c в 10 потоков == [#8e213a 27MiB/34MiB(81%) CN:10 DL:813KiB ETA:8s]
такое очущение что aria2c как и курл скорость режет сам ютуб.
yt-dlp + aria2c в ДВА потока == [#000f93 13MiB/34MiB(37%) CN:2 DL:400KiB ETA:54s]
в ru-board пишут такой вариант еще
yt-dlp --extractor-args "youtube:formats=dashy" -N 4
[download] 67.5% of ~ 36.52MiB at 1.28MiB/s ETA 00:09 (frag 44/67)
если что 1000 КБ/сек это мой канал. 
и 4К он сам по себе не вытягивает.
но chrome без прокси
при этом в https://redirector.googlevideo.com/report_mapping?di=no пишет почему то IPv4
Помогает: на Linux и Windows. Нужно определить стратегию обхода с помощью скрипта blockcheck и добавить googlevideo.com в zapret-hosts-user.txt.
Удалось улучшить скороcть при скачивании из Android приложения.
На мобильном интернете от теле2
45 минутное видео в 1080p 334 мегабайт скачалось за 6:30
Не самый выдающийся результат, но хоть что-то
Как это работает?
Как вы могли заметить при скачивании загружаются первые пару мегабайт, а дальше РКН режет скорость до 50 кб/c и ниже.
Скачивать что-либо становится невозможно.
Делаем иначе – скачиваю видео небольшими кусками по 700000 байт.
Один кусок - один запрос к сети. Если таймаут превышает 3 секунды, то обрываю и начинаю с того же куска опять(исходя из тестов запрос мог уходить и на 20 секунд, поэтому лучше дропнуть раньше). Ну т.е вот такая докачка происходит.
Совсем обрыва не происходит, потому что считываю сколько байт в уже скачанном файле и стартую с того же места.
Выложил на 4PDA свое приложение в apk (надеюсь тут за такое не банят)
Буду рад фидбэку, как скачивается, сообщениям об ошибках и багах.
Пока бета тестирование, но как доведу до ума, то пойдем в рустор.
Сделал еще одну альтернативу обхода замедления ютуба под линукс.
На Ростелекоме работает. Еще люди сообщали, что работает на Ertelecom.
Поддерживает OpenWRT и есть инструкция как его там использовать, плюс я готовлю обновление оптимизации (мультитрединг) под роутеры. Буду рад если поможет, а если нет - открывайте issue, будем разбираться
Такие “сливы” от федеральных сми больше похожи на агитацию, имхо.
Я думаю, в будущем будут просто “ложить” на определённое время, ссылаясь на перегрузку. У меня такое мнение…
Пока ещё охват большой, а альтернативы не очень хорошие.
Огромное спасибо за эти данные! Как раз хотел уйти с “РСТ” на “Игра Сервис” из-за этой истории с замедлением, но теперь видно, что смысла нет.
А у меня както странно замедляится при проверки скачивания через yt-dlp скорость 50 и до 300 мегабит но при добавление googlevideo.com в блоск лист в утилиту goodbyedpi скорость поднимается до 400 мегабит вплоть до 700
доброго времени суток!
скорость режется, очень страдает youtube на android TV из-за этого
вопрос к специалистам:
немного опытов на домашнем компьютере показали
- видео, открытое в браузере (хром, консоль разработчика), идёт с сервера rr6---sn-n8v7kne6.googlevideo.com
- тест через curl подтверждает занижение скорости по этому имени
- IP адрес сервера
Reverse IP results for rr6---sn-n8v7kne6.googlevideo.com (74.125.110.214)
- трассировка показывает, что этому IP соответствует другой DNS
svo07s15-in-f22.1e100.net (74.125.110.214)
- домен *.1e100.net не попадает под урезание скорости
ремарка:
хром при просмотре видео обращается за потоком к *.1e100.net
YouTube Downloader при скачивании открывает поток к *.1e100.net
все исх. соединения отслеживались через ProcessHacker
собственно вопрос к более осведомлённым в этой области коллегам.
на одном ip адресе два (или более) DNS имени, к которым обращается ПО для получения видеопотока
один попадает под ограничение скорости, второй нет
возможно ли на уровне ПО, позволяющее обходить ограничения, подменять одно DNS имя на другое, при условии, что целевое URL видеопотока не отличается кроме как доменным именем https://???.com/*
возможно ли стандартными средствами ОС или ПО, позволяющее обходить блокировку, находить URL с ссылкой на видеопоток формата
https://???.googlevideo.com/*
проверять/генерировать “валидный” URL на тоже видео, но уже в формате
https://???.1e100.net/*
и заставлять ОС или приложение обращаться по этому URL за видеопотоком?
возможно где-то накосячил с терминами и понятиями, сильно прошу не пинать
Кстати, я тоже об этом подумал. Нужно копать эту тему