Несостыковочка с "замедлением ютуба"⁠⁠

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

то, что ты через 3 буквы или прокси можешь достучаться – это как раз доказывает, что проблема не в тупой блокировке ip-адресов гугла (иначе бы и впн не помог), а в политиках маршрутизации или qos для прямых подключений из определенных asn. гуглу может быть выгоднее обслуживать трафик через транзитных операторов или впн-провайдеров, чем напрямую из сетей, которые они считают "проблемными" или "неприоритетными". а твой "бесплатный премиум" – это вообще из другой оперы, не путай маркетинговые подачки с архитектурой cdn.

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

"эксперимент" с фейковым sni на свой сервер – это забавная лабораторка, доказывающая наличие dpi у провайдера (капитан очевидность на связи). но делать из этого вывод, что именно и только это является причиной деградации ютуба по всей стране, игнорируя всю сложность глобальной инфраструктуры гугла – это, мягко говоря, наивно. хватит уже искать виноватых под фонарем, где светлее.

Но ты же понимаешь, что твой curl запрос с флагом --connect-to не телепортируется квантовой запутанностью прямо на твой loopback или на сетевой интерфейс твоего test.server? Он проходит через всю инфраструктуру твоего локального провайдера и, возможно, несколько транзитных операторов, прежде чем достигнуть точки назначения (которую ты искусственно задал как IP твоего сервера). И вот на этом пути, особенно на оборудовании провайдера "последней мили", как раз и могут быть установлены те самые DPI/TSPU комплексы.

Этим системам глубоко фиолетово, какой у тебя там server_name в конфиге бэкенда и как ты его обрабатываешь. Они оперируют на более низком уровне сетевого стека и анализируют транзитный трафик. TLS ClientHello, содержащий SNI, передается в открытом виде до установления зашифрованного туннеля. Соответственно, промежуточное оборудование вполне способно проинспектировать это поле и применить некие политики, основанные на его значении.

Твой собственный эксперимент, как ни парадоксально, как раз и демонстрирует наличие некоего промежуточного узла (вне твоего test.server), который триггерится на конкретное значение SNI (manifest.googlevideo.com) и инициирует некую аномалию в обработке TCP-сессии. Это может быть не банальный TCP Reset, а, например, селективный дроп пакетов (packet loss) или внесение значительной задержки (latency injection) именно для сессий с "неугодным" SNI, что в итоге и приводит к Operation timed out на клиентской стороне (в данном случае, curl). Тот факт, что запросы с другим SNI (фейковым или с опечаткой) к тому же самому IP-адресу (--connect-to) проходят без проблем, как раз и указывает на фильтрацию, основанную именно на значении SNI, применяемую где-то по пути следования пакетов.

Но вот тут главный вопрос, который ты игнорируешь: является ли этот механизм, который ты так изящно продемонстрировал в синтетическом тесте с подменой SNI на свой сервер, единственной и основной причиной наблюдаемой деградации производительности реального YouTube и YouTube Music для миллионов пользователей? Не слишком ли смелая экстраполяция с частного, искусственно созданного случая на глобальную проблему?

Или же мы все-таки имеем дело с комплексной ситуацией, где на стороне Google работают свои, не менее изощренные механизмы шейпинга и управления трафиком? Например, их эдж-ноды или глобальные балансировщики нагрузки (GSLB) могут применять дифференцированные QoS-политики, основываясь на комбинации факторов: геолокации клиентского IP (принадлежность к российским ASN), типа запрашиваемого ресурса (различая запросы к manifest.googlevideo.com и к самим видео-чанкам на *.googlevideo.com), текущей нагрузки на конкретный PoP (Point of Presence) или даже на основании каких-то внутренних эвристик, выявляющих "нежелательные" паттерны потребления трафика из определенных сетей? Не исключено, что таймаут, который ты наблюдаешь, является следствием именно такой политики со стороны Google, когда их фронтенды, получив запрос к manifest.googlevideo.com из "проблемного" региона, просто помещают его в низкоприоритетную очередь обработки или применяют агрессивный rate-limiting, приводящий к фактическому неответу в течение заданного таймаута.

Может, всё-таки не стоит редуцировать комплексную инфраструктурную проблему до уровня "grep SNI && throttle"?

гугл кидает юзеров из рф, а виноват... ркн, который типа из сочувствия тормозит сервисы? это даже не конспирология, это какой-то новый уровень шизы

и ты на основании этого цирка с конями (--connect-to ::test.server и фейковый сни) делаешь вывод про ркн? ты там у себя локально что-то напердолил, твой сервер, увидев незнакомый manifest.googlevideo.com в tls хендшейке, встал раком и ушел в таймаут (может, конфиг такой, может, модуль какой кривой, может, фаервол), а ты уже глобальные выводы про тспу строчишь?

ты бы еще пинганул 127.0.0.1, и если бы пакет потерялся, обвинил бы рептилоидов.

гугловские фронтенды, балансеры, или что там у них накручено перед manifest.googlevideo.com. видишь таймаут на скрине? operation timed out after 300601 milliseconds. это тебе не connection refused или reset by peer. это значит, что твой курл достучался до сервера, возможно даже tls хендшейк начал, а потом сервер просто забил на него и не отвечал пять минут, пока курл сам не отвалился.

почему он так делает? да хрен его знает. может, у них там хитрый qos, который для определенных хостнеймов (типа manifest) и определенных клиентских ip (привет, домашние сети рф) включает режим "подожди у моря погоды".

думаешь, эти коробки с мигалками у провайдера тупо grep manifest.googlevideo.com в clienthello делают и сразу дропают? так примитивно даже для них было бы.

если бы тупо по сни резали, был бы какой-нибудь connection reset, а не вот это вот жалкое пятиминутное ожидание у моря погоды с таймаутом. пакеты что ли теряются по дороге строго после того, как тспу увидела знакомые буковки в tls хендшейке?

ты сам же кинул скрин, где конкретный хостнейм отваливается по таймауту, а другой хостнейм, резолвящийся в тот же ip (через --connect-to), прекрасно работает на полной скорости. если бы резали тупо по ip или даже по пулу ip гугла, так валилось бы всё. а тут ювелирная работа прям по конкретному имени хоста, да еще и не баном, а именно таймаутом

Но ты ж сам пишешь: "внятного объяснения тому, что происходит на скрине". Так вот именно! ТСПУ на последней миле – это хорошо, но как оно объяснит, почему у тебя curl отваливается по таймауту именно на manifest.googlevideo.com, а какой-то левый файл (test.server/file) или даже опечатка в домене (manifest.goooooooglevideo.com) грузятся со свистом под 30+ мегабит? 🤔

Если бы ТСПУ тупо резал скорость до гугловых серверов, то, наверное, все запросы к ним были бы медленными или отваливались, нет? А тут какая-то избирательность прям по конкретному хосту.

Легко. Только вот незадача... Как тогда объяснить прикол, что если запустить виртуалку где-нибудь в Яндекс.Облаке или у другого российского крупного хостера, то внезапно Ютубчик и Музыка там летают как ни в чем не бывало? Те же самые сервера Гугла, тот же самый manifest.googlevideo.com (если он там используется), но скорость – мое почтение!

Может все-таки "корпорация добра" сама рулит краником? Может, Гугл просто решил, что холопам на домашних интернетах хватит и 144p, а вот бизнес-сегменту и жирным хостерам надо нормальный QoS обеспечивать, чтобы контракты не потерять? Типа, один трафик для плебса, другой – для господ?