Замедление YouTube с технической стороны – Waujito (Хабр)

Привет, Афтершок! Согласно FAQ задача нашего ресурса – предоставлять, по возможности, качественную "первичную" информацию – иными словами, предоставлять правду.

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

Да, так как в данном случае происходит замедление, а не блокировка ресурса, использование средств обхода данного замедления вполне легально.

Слово пользователю Vadim Vetrov @Waujito

---

Привет, Хабр!

В последнее время замечаю огромное количество информации по поводу замедления Великого, но очень мало где видел конкретику о том, как именно это работает. Одно лишь отчаяние "мы все умрём".

Сразу скажу, что буду говорить обо всём, что известно на данный момент. Понятно, что с этим разбирался далеко не один я: огромное спасибо обывателям ntc party форума за проделанный ресёрч.

Так вот, начнём сначала, с злополучного GGC. Официальное заявление было, что кэш сервера устарели и долго не обновлялись, но у многих возникло такое скептическое чувство: "до этого работали, а тут в один момент всё поломалось". К тому же есть статья на википедии, которая утверждает, что разговоры про эти GGC шли еще с 2018 года. Да и если это были они, у нас бы плохо работала львиная доля гугл сервисов, включая Google Drive, Google PlayMarket, Google Images. А оно работает прекрасно, как и прежде.

Дальше рассмотрим идею, что это вообще гугл тестирует ограничение загрузчиков типа yt-dlp, потому что, в первую очередь, проблемы коснулись именно их. Идея на самом деле интересная, потому что действительно на современных протоколах (QUIC) всё хорошо работает, а проблемы есть только на старом добром TCP (сейчас ходят слухи, что и QUIC начали ограничивать, и, вроде как, я могу это подтвердить). Эту и предыдущую идеи мы опровергнем далее.

Как только я начал разбираться с этой проблемой и открыл Wireshark, меня ждали логи, состоящие наполовину из красных полос. Я не стал особо думать над тем, как именно замедляется ютуб со стороны TCP, но сразу стало понятно, что замедление искусственное, потому что если бы это были GGC, они бы либо не работали вообще, либо просто скорость была маленькая, а тут тонны потерянных пакетов. А еще забавно, что с QUIC, который автоматом работает в хроме такого вообще не происходило и скорость была в норме. Я начал искать и вспомнил про один очень крутой форум по обходу всяких подобных приколов с цензурой интернета, ntc party. Там я нашёл, как именно замедляется ютуб и контрпример, подтверждающий на 100%, что это проделки большого брата.

Но перед тем, как назвать способ замедления, давайте подумаем, а как они могут вообще определить, что я смотрю ютуб просто видя raw ip пакеты. Пойдём с самого низкого уровня, который может их заинтересовать, IP. Что тут есть? IP адрес. И это очень мощный инструмент, правда если их не тысячи, и если на них работает только один сервис, googlevideo. В случае огромной инфраструктуры гугла их банально сложно получить, я уже не говорю про то, что если на одном айпишнике работают, скажем гуглвидео и гугл плеймаркет, а ведь вероятность такая есть, это же GGC как никак. Тогда обрубая одно, обрубим и другое. Что делать? Посмотрим выше. На TCP мало чего интересного, поднимаемся еще выше. А дальше TLS. И это всё? Почти... Да, современные протоколы сделаны так, чтобы шифровать всё, что можно. Но есть только одно исключение. В спецификации TLS есть такая вещь, как SNI. Она передаётся серверу и говорит ему, к какому именно сайту мы хотим подключиться и, следовательно, какой именно сертификат нам давать. Что-то типа Host в HTTP, но для TLS. Так вот, этот самый SNI спокойно себе передаётся в незашифрованном виде. Было много спецификаций, предлагающих его зашифровать, но мэйнстримом оно не стало. К тому же, провайдеры блокировали такие подключения, чтобы не мешали следить за юзерами.

Так вот, SNI лежит в незашифрованном виде в Client Hello, и, обнаружив его, мы можем коннмарком пометить соединение и выкидывать рандомные пакеты.

Я знаю, что вы ждёте пруфов, господа, и вот они:

curl --connect-to ::speedtest.selectel.ru https://manifest.googlevideo.com/100MB -k -o/dev/null

Что мы видим в этом curl запросе? У curl'a есть возможность подключаться к серверу с его именем, но вместо резолвинга DNS поставить какой-нибудь свой айпи. При этом вся информация более высокого уровня будет передаваться, как будто мы используем именно это имя. Такое поведение заставляет curl подменять тот самый SNI (ну еще и Host, но это нас не особенно интересует). -k флаг используется, чтобы отключить проверку сертификатов (она провалится, потому что speedtest.selectel.ru будет нам давать свой сертификат, но никак не желаемый от гуглвидео). И если запустить это запрос, то мы получим весёлую скорость в 120 килобайт на начале, и дальше она пойдёт на спад. Даже до нуля может дойти. А теперь замените любую букву в googlevideo на другую и скорость прыгнет до нормальной скорости интернета. Всё стало на свои места.

Примечание RarogCmex: На картинке результат выполнения вышеуказанной команды. Строка выше показывает, как оно должно быть в норме (я использую ipv6 шлюз), нижняя показывает замедление (на ipv4). Провайдер Уфанет. Обратите внимание на столбец Time Left

Как с этим бороться?

Конечно, способы борьбы существуют. Для этого будем думать в сторону манглинга (изменения) пакетов. Но если мы просто заменим googlevideo.com на yandex.ru, получим ошибку сертификатов. И не факт что браузер вообще позволит отключить эту проверку для гуглвидео и нормально будет с этим жить. Так что же делать?

Вспомнить про то, что ТСПУ - это всё-таки очень высоконагруженная штука, которая вряд ли будет запоминать, что и когда мы там отправляли в сеть, и, соответственно, если мы просто разобьем наш запрос на два в середине SNI, то О Чудо! Всё начинает работать. В моём случае не понадобились даже фейковые Client Hello или задержка между пакетами (но вроде как ему всё-таки нужен обратный порядок пакетов: сначала идёт хвост, потом голова).

Как разбивать? Есть два варианта: фрагментами IP и на уровне сегментации TCP. У меня лично фрагментация IP сначала работала на половину, а потом и вообще отвалилась. Возможно, провайдеру не понравилось. Идём выше, к TCP. И тут у них всё очень приятно работает. Даже несмотря на то, что я, казалось бы, из одного пакета сделал два, поменял размеры двух пакетов, я не нарушил никаких правил TCP соединения: Ack по количеству доставленных байт - вещь.

Готовые средства обхода. Ну и самое вкусненькое. Я лично написал своё решение под линукс, которое направлено только на ютуб. Также для Windows существует GoodbyeDPI от ValdikSS, под линукс еще есть zapret. Существует ByeDPI, который работает как прокси (Windows/Linux). Также есть версия ByeDPI под андройд, работает как "фейковый впн". Советую прочитать подробный комментарий от ValdikSS о том, как использовать эти средства. Если есть желание погрузиться глубже в эту тему, вот тут можно посмотреть подробнее: https://ntc.party/t/замедление-youtube-в-россии/8055/ and https://ntc.party/t/обсуждение-замедление-youtube-в-россии/8074/
RarogCmex: Более простая инструкция

---

Примечательные комментарии с Хабра:

slinkinone

Было много спецификаций, предлагающих его (SNI) зашифровать, но мэйнстримом оно не стало.

На мой взгляд, многие шифрованные штуки не вошли в постоянный обиход (IPv6, Encrypted SNI, DNS over TLS), по причине того, что это не выгодно с точки зрения бизнеса. Если убрать сигнатуры по которым можно определять сервис, то мобильные операторы не смогут разделать трафик, предлагать разные тарифы, "качественно" делать балансировку. Интернет принадлежит тем, кто его обслуживает.

Интернет провайдеры и мобильные операторы - это бизнес, который должен во-первых соблюдать законы государства, где он работает, а во-вторых, иметь возможность "гибко завлекать пользователей" и предоставлять конкурентноспособный уровень сервиса. Если убрать маркеры для классификации сервисов, то такой бизнес столкнется с большими трудностями. Есть ощущение что это работает плюс-минус одинаково во всех странах.

---

Примечательные комментарии с ntc.party:

1

kotletussy 19 дн

В пользу того, что замедление готовилось заранее, говорит в краткие сроки осуществлённая блокировка всех публичных инстансов Invidious - приватного фронтенда для YouTube, который может проксировать через себя трафик googlevideo.com 60

Piped, у которого такой функции нет, не тронули.