У меня ситуация интересная. Кажется блокируются только некоторые поддомены.
Например с rr10---sn-n8v7znsz.googlevideo.com еле шевелится, а c rr2---sn-045oxu-045k.googlevideo.com грузится на полной скорости. То есть при тормозах достаточно обновлять страницу до попадания на “правильный” сервер.
HTTP/3 выключен, запросы идут исключительно по HTTP/1.1.
| ISP | AS | Location |
|---|---|---|
| JSC Ufanet | AS24955 | Republic of Bashkortostan |
rr2.sn-045oxu-045k.googlevideo.com – гуглокэш в сети вашего провайдера. rr10---sn-n8v7znsz.googlevideo.com – пиринг от гугла. Адреса российских сетей, как они их видят, в белых списках для всех новых блокировок, включая гугловские обновления процентов.
HTTP/1.1
Вы отключили HTTP/2?
Нет. Соседние запросы его используют. Но именно к googlevideo.com исключительно по 1.1 лиса почему-то обращается.
Внезапно, но гугл раздает видео с серверов без поддержки http/2. Этой информации у меня не было.
Настолько лишняя сущность оказалась. Зато пропихивали протокол в стандарты с ускорением.
Преимущество HTTP2 в стандартизированной поддержке pipelining (конвейерная/многопоточная обработка). А нужна ли она для googlevideo.com ещё вопрос.
Для раздачи видео да, для других задач нет. Разве что дедубликацию данных в заголовке можно притянуть(если закрыть глаза на то, что это экономия на спичках в данной задаче)
Ютуб окончательно отвалился ровно в 0:00 по МСК
Спасибо за инструмент! А будет обновление для Keenetic? Пытался сам собрать для него, но нифига не получилось…
В хроме. В файерфоксе работает но с задержками.
Билайн СПБ
Как будто, оно должно собираться для всего, что имеет crosscompilation toolchain и рут доступ. Ну и ядро с netfilter nfqueue + юзерспэйс iptables. Можете открыть issue в гитхабе и покидать туда ошибки компиляции. Возможно, смогу помочь. С поиском тулчейна - тут увы. По первой ссылке получил GitHub - The-BB/Entware-Keenetic: Ultimate repo for embedded devices и вроде как тут его можно собрать.
Протокол заявлялся как улучшение, он не должен был деградировать в уже существующих сценариях. Если отказались от внедрения значит весь продуктивный контроль передачи данных оказался пшиком. Речь про кодирование передачи бинарных данных, когда заранее неизвестен размер, например.
Использую дурение через nfqws --dpi-desync=fake,split2
Тесты с curl подтверждают, что дурение работает и скорость до googlevideo становится полной (разница в среднем 20 раз).
Но ютуб при этом тупит, особенно сильно зарубежные видео - загрузка фрагментов бывает по 5+ сек, а время ответа сервера 1+ сек (фф отмечает такие запросы черепашкой).
Пчелайн мск.
Я так понимаю, это уже не вылечить?
На Firefox работает без VPN и дополнитленых танцев с бубном.
Вы же сообщили совсем недавно, что Ютуб у вас отвалился.
Не знаю связано ли, но пользователи yt-dlp стали жаловаться на исчезновение 251 (opus) формата. Также я заметил (под VPN), что исчез VP9 24X (например, 247 720p, который https), m3u8 кусковой VP9 остался, однако. В браузере при этом всё есть.
Возможно из-за:
Webpage contains broken formats (poToken experiment detected). Ignoring initial player response.
nsig extraction failed: Some formats may be missing.
Разработчики говорят, что в случае неудачи, yt-dlp переключается на iOS форматы.
Может, это и не связано, но имейте в виду, что yt-dlp сейчас малость поломан из-за гугла.
Upd: в yt-dlp починили.
…конкретных сценариев использования(для некоторых сценариев он просто остался “на том же уровне” что имхо не есть деградацией ведь новый протокол должен не быть хуже старого и решать новые технические проблемы с чем HTTP2 справился. Ютуб не взялся его внедрять ибо к 2015 эдак году трудозатраты на изменение были огромны и взамен с учётом их сценария использования кардинальных улучшений нет)
P.S. Продуктивный контроль передачи нужен для конвейера/мультиплексинга и в случае одного потока данных ничего не даст
про yt-dlp
ну там есть --extractor-args
ютуб и так отдает разные форматы разным “клиентам”
Вот эту жуть https://en.wikipedia.org/wiki/HTTP_pipelining допилили/переделали и стандартизировали. Раньше (в HTTP 1.1) в основном только пользователи Opera Presto кайфовали от быстрой загрузки, если не глючило (картинки не путались).
WARNING: [youtube] Android client formats are broken and may yield HTTP Error 403. They will be deprioritized
