--- date: 2026-10-20 tags: - youtube - ggc - googlevideo - ттк - сетевая-диагностика - dpi aliases: - Что такое Google Global Cache - GGC googlevideo как работает - rr1---sn googlevideo что значит - redirector.gvt1.com report_mapping что показывает - Как YouTube выбирает узел googlevideo - Кэш Google у провайдера как проверить - 188.43 GOOGLE-TTK-NET что это description: "Как устроен Google Global Cache и узлы googlevideo.com, как YouTube выбирает узел и что показали прямые замеры четырёх кэшей ТТК с хостинга в Москве." image: DPI/attachments/ggc-googlevideo-how-it-works-header.png link: https://redirector.gvt1.com/report_mapping?di=no --- > [!mirror] Резервное зеркало > Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/ggc-googlevideo-how-it-works](https://wiki.zapret.moe/DPI/ggc-googlevideo-how-it-works) # 🦎 Кэши Google (GGC) у провайдера: как YouTube выбирает узел googlevideo.com и что показали прямые замеры ![[ggc-googlevideo-how-it-works-header.png]] > [!info] О чём заметка > Основа для разбора сбоев вроде [[DPI/ttk-youtube-ggc-october-2026|истории с ТТК в октябре 2026 года]]: что такое кэш Google внутри сети провайдера, как плеер YouTube попадает именно на него, что значит имя `rr1---sn-…`, как это проверить самому и что отвечают такие узлы на прямые подключения со стороны. Раздел с замерами содержит собственные измерения от 20 октября 2026 года. ## TL;DR - Видео YouTube приходит не с `youtube.com`, а с адресов `*.googlevideo.com`. Для популярных роликов Google ставит собственные серверы-кэши прямо в сетях провайдеров: это Google Global Cache (GGC). - Какой узел достанется, решает страница воспроизведения по IP клиента, поэтому прокси или VPN для `*.youtube.com` меняют набор узлов, а правила для `*.googlevideo.com` часто не нужны. - Четыре адреса из блока `GOOGLE-TTK-NET` с хостинга в Москве дали одинаковую картину: TCP-соединение за 2–99 мс, TLS-рукопожатие с сертификатом `*.googlevideo.com` при любом имени в запросе (28 проб из 28), на чужой запрос быстрый ответ HTTP 400; имена узлов из обсуждения превращаются в адреса именно этих блоков. Узлы как серверы живы и не придираются к имени. - Из-за рубежа картина другая: на приветствие с именем `…googlevideo.com`, написанным строчными буквами, те же узлы молчат (и ряд других российских адресов тоже), а HTTP на порту 80 отвечает всегда. Заглавные буквы в имени рукопожатие пропускают. Разрез приветствия не помогает. - Значит, зависание, о котором пишут абоненты, возникает на пути до узла или в передаче данных, а не потому, что узел «мёртв». ## Что такое кэш Google у провайдера Пока абонент смотрит ролик, его данные могут идти из дата-центра Google за границей, а могут из небольшого сервера, который Google поставил в сеть самого провайдера. Второй путь короче и дешевле для обеих сторон: провайдер не гоняет популярный ролик через международные каналы каждый раз, а Google экономит на внешнем трафике. Такой сервер и называется Google Global Cache (*GGC, кэш-сервер Google у оператора*). Он хранит то, что чаще всего смотрят абоненты этого провайдера. Если нужного ролика на нём нет, сервер сам докачивает его у Google и отдаёт абоненту: для абонента это выглядит как короткая задержка перед началом фрагмента. Проще говоря: хорошо работающий кэш быстро отдаёт то, что у него лежит, и быстро докачивает остальное. Когда докачка сломана, популярное по-прежнему идёт быстро, а редкое и новое встаёт. Именно такую картину описывают участники обсуждения ТТК. ## Как читать имя узла Адрес вида `rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com` состоит из трёх частей. Префикс `rr1` отражает номер: у одного кластера несколько узлов (`rr1`, `rr2`, …). Часть `sn-…` служит идентификатором кластера, а последний фрагмент после дефиса, судя по всему, различает отдельные машины. Значение этих кусков Google не публикует. Участники обсуждения по общему фрагменту `uxaxjvh` предполагали, что такие узлы стоят в России, и это остаётся гипотезой. Имя нельзя считать надёжным признаком принадлежности оператору: что за сеть стоит за адресом, надёжнее проверить по базе RIPE. Например, адреса из обсуждения ТТК `188.43.65.140`, `188.43.67.12` и `188.43.61.141` [записаны в RIPE](https://stat.ripe.net/data/whois/data.json?resource=188.43.65.140) как `GOOGLE-TTK-NET` с описанием `GOOGLE-SERVERS` и анонсируются из AS20485 (TransTeleCom). Как узнать владельца любого адреса, разобрано в заметке [[Zapret2/find-domain-owner|Как определить владельца домена или IP]]. ## Как YouTube выбирает узел Самое важное, что стоит понять: выбор делается заранее и не на уровне DNS. По описаниям участников форума ntc.party, браузер при открытии ролика запрашивает у `www.youtube.com` данные для воспроизведения, и в ответе Google перечисляет узлы `googlevideo.com`, подобранные по IP-адресу, с которого пришёл запрос. Телевизоры и мобильные клиенты, по тем же сообщениям, берут список ещё у `redirector.googlevideo.com`, а возможно, и у `manifest.googlevideo.com`. Дальше имя узла превращается в IP обычным DNS-запросом, и плеер идёт к этому адресу. ![[ggc-googlevideo-node-selection.png]] Практическое следствие такое. Если пустить запросы к `*.youtube.com` через прокси или VPN другого региона, плеер получит имена узлов, подобранных для региона прокси, и пойдёт на них напрямую. Поэтому участники обсуждений советуют направлять через другой регион именно `*.youtube.com`, а не `*.googlevideo.com`. Дополнительная деталь: по словам участника, после первого фрагмента плеер может переключиться на ближайший к клиенту кэш, где лежит следующий фрагмент. Независимо подтвердить это не удалось. Увидеть, куда направили именно вас, можно на служебной странице Google: https://redirector.gvt1.com/report_mapping?di=no — по рассказам участников, она показывает кластер, который обслуживает ваш адрес (например, внутри сети ТТК). Второй способ без специальных страниц: открыть вкладку «Сеть» в инструментах разработчика браузера (F12), отфильтровать запросы `videoplayback` и посмотреть «Удалённый IP». ## Что показали прямые замеры 20 октября 2026 года Чтобы отделить поведение самих узлов от поведения сетей абонентов, четыре адреса `GOOGLE-TTK-NET` проверены прямым подключением с хостинга в Москве (AS207957), без прокси и туннелей. Для каждого адреса измерены время установления TCP-соединения, успех TLS-рукопожатия при семи разных именах в запросе и ответ на заведомо чужой запрос (ссылка на ролик, выданная для другого кластера). | Адрес | TCP до порта 443 | TLS при 7 именах | Сертификат | Ответ на чужой запрос | |---|---|---|---|---| | `188.43.61.141` | 2,1 мс | 7 из 7 | `*.googlevideo.com` | HTTP 400 за 7,6 мс | | `188.43.67.12` | 19,0 мс | 7 из 7 | `*.googlevideo.com` | HTTP 400 за 55 мс | | `188.43.65.140` | 41,2 мс | 7 из 7 | `*.googlevideo.com` | HTTP 400 за 121 мс | | `188.43.65.12` | 98,6 мс | 7 из 7 | `*.googlevideo.com` | HTTP 400 за 268 мс | Семь имён: `rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com`, `rr2---sn-ug5onuxaxjvh-p5ge.googlevideo.com`, `r1---sn-aigl6nze.googlevideo.com`, `googlevideo.com`, `www.youtube.com`, `www.google.com` и `ya.ru`. Время ответа HTTP 400 считалось от начала соединения и включает TCP и TLS, поэтому в каждой строке оно лишь немного превышает задержку из предыдущего столбца. ![[ggc-googlevideo-ttk-nodes-rtt.png]] Из таблицы следуют три вывода. Во-первых, все четыре узла живы: они отвечают на соединение, завершают TLS и отвечают на запрос, пусть и отказом, мгновенно. Во-вторых, узлу безразлично имя в запросе: даже `ya.ru` и `www.google.com` получают сертификат `*.googlevideo.com` и успешное рукопожатие, то есть избирательность по имени узлом не создаётся. Это важно для диагностики: если у абонента запрос с именем `googlevideo.com` зависает, а с другим именем проходит (так утверждает тест одного из участников обсуждения), причина лежит на пути между абонентом и узлом, а не в узле. В-третьих, четыре адреса одного блока находятся на разном удалении: 2, 19, 41 и 99 мс от Москвы. Это разные площадки, а не одна машина. Есть деталь, которая пока объяснения не имеет. Автор записей трафика видит до `188.43.65.140` около 5 мс, а с московского хостинга до того же адреса 41 мс. Значит, из региона абонента ближе, чем из Москвы, то есть узел стоит где-то в пределах региона абонента или адрес обслуживают разные машины в зависимости от точки входа. Из публичных данных выбрать между этими вариантами нельзя. Отдельно проверено, как имена узлов из обсуждения превращаются в адреса. Имена разрешены тем же прямым подключением с московского хостинга (DNS-запросы без прокси), и все они ведут в блоки `GOOGLE-TTK-NET`. | Имя узла (без `.googlevideo.com`) | Адрес | Блок в RIPE | |---|---|---| | `rr1---sn-ug5onuxaxjvh-n8v6` | `188.43.61.140` | `188.43.61.0/24` | | `rr2---sn-ug5onuxaxjvh-n8v6` | `188.43.61.141` | `188.43.61.0/24` | | `rr3---sn-ug5onuxaxjvh-n8v6` | `188.43.61.142` | `188.43.61.0/24` | | `rr2---sn-ug5onuxaxjvh-p5ge` | `188.43.65.77` | `188.43.64.0/23` | | `rr3---sn-ug5onuxaxjvh-p5ge` | `188.43.65.78` | `188.43.64.0/23` | | `rr1---sn-ug5onuxaxjvh-v8cz` | `188.43.65.140` | `188.43.64.0/23` | | `rr1---sn-ug5onuxaxjvh-gv8e` | `188.43.67.140` | `188.43.66.0/23` | | `rr6---sn-ug5onuxaxjvh-axql` | `188.43.69.17` | `188.43.68.0/23` | Из таблицы видно три вещи. Во-первых, число в `rrN` — номер внутри кластера, и адреса идут подряд: у кластера `…-n8v6` `rr1`, `rr2`, `rr3` равны `.140`, `.141`, `.142`. Во-вторых, адрес `188.43.65.140` для `rr1---sn-ug5onuxaxjvh-v8cz` совпадает с тем, который абонент увидел в своих инструментах разработчика и на который смотрят записи трафика: ответ DNS из Москвы тот же, что у абонента, то есть имя не зависит от того, откуда спрашивают. В-третьих, четыре из семи блоков `GOOGLE-TTK-NET` (`188.43.61.0/24`, `188.43.64.0/23`, `188.43.66.0/23`, `188.43.68.0/23`) подтверждены именами узлов; для `188.43.87.0/24`, `188.43.126.0/24` и `188.43.127.0/24` реестр тоже называет серверы Google, но имён узлов оттуда в обсуждениях нет, и перебирать чужие адреса, чтобы найти их, нельзя. > [!warning] Чего эти замеры не показывают > Это одна точка наблюдения (хостинг в Москве) и один день. Замеры не показывают, что происходит у абонентов ТТК и как узлы отдают ролики, которых нет в кэше: чтобы получить такое видео с конкретного кэша, нужна ссылка, выданная именно для этого кластера, а YouTube выдаёт её по IP клиента. Поэтому вывод «узел жив и не придирается к имени» относится только к рукопожатию и первому ответу. ## Контрольный замер из-за рубежа: имя `googlevideo.com` строчными буквами теряется Результат из Москвы нельзя читать как «узел всегда отвечает»: тот же узел проверен ещё и из-за границы, с сервера Zapret DNS в Нидерландах (AS41745, настоящие задержки 50–140 мс). Картина другая. - **HTTP на порту 80 отвечает всегда.** Запрос `GET /generate_204` с любым заголовком `Host` (`rr1---sn-….googlevideo.com`, `googlevideo.com`, `www.google.com`, `example.org`, вовсе без `Host`) возвращает `204 No Content` и из Москвы, и из Нидерландов, за доли секунды. - **HTTPS из-за рубежа теряется по имени.** TCP-соединение с узлами `188.43.65.140` и `188.43.61.141` устанавливается, но на приветствие TLS с именем вида `rr1---sn-ug5onuxaxjvh-v8cz.googlevideo.com` ответа нет вовсе (5 секунд). С именами `googlevideo.com` (без имени слева), `www.youtube.com`, `www.google.com`, `ya.ru` и даже `rr1---sn-ug5onuxaxjvh-v8cz.example.com` рукопожатие проходит. Из Москвы проходят все имена. - **Правило зависит от регистра.** Стоит изменить буквы в `googlevideo.com`, и рукопожатие проходит: `…GOOGLEVIDEO.COM`, `…GoogleVideo.com` и даже `…googlevideo.COM` (заглавными только `COM`) прошли, а `RR1---SN-….googlevideo.com` (заглавная только левая часть) и `rr1---sn-….googlevideo.com.` (точка в конце) по-прежнему теряются. Не проходят и другие имена вида `x.googlevideo.com`, `r1.googlevideo.com`, `manifest.googlevideo.com`. Не проходит то, что оканчивается на строчное `.googlevideo.com`; имена `googlevideo.net`, `xgooglevideo.com` и `….googlevideo.com.example.org` не затронуты. - **Разрез приветствия не помогает.** Приветствие, разрезанное на два и три TCP-сегмента (до имени, посреди имени, внутри `googlevideo.com`), теряется так же, как целое. Значит, на пути стоит устройство, которое собирает поток, а не смотрит один пакет. - **Это не свойство узла.** Приветствие с именем `rr1---sn-….googlevideo.com` из Нидерландов молча теряется и на части других российских адресов: у `ya.ru` (`5.255.255.242`) на пяти попытках из пяти, у других адресов `ya.ru`, `mail.ru`, `rt.ru` и `gosuslugi.ru` на отдельных запусках; к зарубежным серверам (`google.com`, `example.org`) оно проходит, а адрес `74.125.110.168` из семейства Google отвечает на любое имя. Есть и российские адреса, к которым это же приветствие проходит (`mail.ru`, `90.156.232.4`). Значит, дело не в кэшах как таковых: узлы ТТК попадают под правило потому, что они российские и называются `googlevideo.com`. - **Запись пакетов на стороне Нидерландов** для потерянного приветствия показывает: рукопожатие TCP проходит, подтверждение первого сегмента (1584 байта) приходит с адреса узла, после этого ничего не отвечают: следующий сегмент в 184 байта остаётся без подтверждения и клиент пересылает его заново. Для приветствия с заглавными буквами ответ приходит сразу. Из записи не видно, кто именно шлёт подтверждение, узел или устройство на пути. ![[ggc-googlevideo-sni-case-matrix.png]] Что из этого следует. Первое: сообщение «кэш недоступен через VPN, а с другого провайдера доступен, и по HTTP всегда доступен» совпадает с замерами для узлов ТТК. Выход VPN за рубежом — зарубежный источник, и его приветствие с именем `…googlevideo.com` в этом направлении теряется, а HTTP на порту 80 проходит. Второе: приём «пустить через VPN только `*.googlevideo.com`» обречён, когда плеер получил от `youtube.com` российские узлы; надёжнее, чтобы и страница воспроизведения, и сами видеоузлы шли через один выход, тогда плеер получает узлы того же региона, что и выход. Третье: правило нечувствительно к разрезу, но чувствительно к регистру, поэтому «простая нарезка» из Zapret в этом направлении не поможет, а смена регистра имени (достаточно заглавных букв в `COM`) в замере помогла. Это не рекомендация и не проверенный обход: клиентская программа должна уметь менять регистр имени в приветствии, а у браузера такой возможности нет. Проверить гипотезу на своём канале можно командами `openssl s_client -connect <адрес>:443 -servername rr1---sn-….googlevideo.com` и такой же командой с `…googlevideo.COM`: если первая молчит, а вторая отвечает, на пути стоит такое же правило. Чего замеры не показывают. Где именно стоит устройство (на границе, в сети ТТК или рядом с узлами), чьё оно и действует ли то же правило внутри сети ТТК для абонентов, неизвестно: замер идёт только от двух точек и только по направлению «из-за рубежа». Часть результатов нестабильна (одно и то же имя то проходит, то теряется): это похоже на несколько путей с разным оборудованием. Адреса кэшей «Ростелекома» в Санкт-Петербурге не проверялись: их адресов нет, а по имени узла их из открытых данных не найти. ## QUIC и откат на TCP Плеер YouTube умеет получать видео двумя способами: по QUIC (протокол HTTP/3 поверх UDP, порт 443) и по обычному TCP с шифрованием TLS. Он сначала пробует QUIC и, если ответа нет в течение нескольких секунд, откатывается на TCP, а затем периодически снова возвращается к QUIC. Для обходов блокировок это важная деталь: стратегия, настроенная только для TCP, не помогает, пока плеер ждёт тайм-аут QUIC. Участник из Республики Коми выяснил, что адресов кэшей ТТК нет в списках Zapret, поэтому его правила для UDP вообще не срабатывали на трафик к ним. О том, как три области Zapret (`YouTube TCP`, `YouTube QUIC`, `GoogleVideo`) делят эту работу, написано в заметке [[Zapret/youtube|YouTube в Zapret]]. ## История GGC в России Правила игры вокруг GGC в России менялись несколько раз, и это объясняет, почему любые сбои с ними принято сначала проверять на старение оборудования. ![[ggc-russia-timeline-2022-2026.png]] Единственное событие, подтверждённое первоисточником, которое удалось открыть: 12 июля 2024 года «Ростелеком» [заявил в сообщении, опубликованном ComNews](https://www.comnews.ru/content/234315/2024-07-15/2024-w29/1007/youtube-ne-pokazalsya-rostelekomu), что из-за «проблем с эксплуатацией серверов GGC и невозможности их расширения» наблюдается серьёзная перегрузка мощностей, в том числе на пиринговых стыках. Остальные события на схеме даны по обзору [Runnin4ik/ggc-russia](https://github.com/Runnin4ik/ggc-russia): автор сам называет цифры расчётными, а события 2025–2026 годов, по его же оговорке, опираются на посты форума. Отсюда общий вывод: версия «оборудование стареет» действительно давно звучит, но для событий конца октября 2026 года её не подтверждает ни одно измерение. ## Источники - [RIPEstat: whois для 188.43.65.140](https://stat.ripe.net/data/whois/data.json?resource=188.43.65.140) — сеть `GOOGLE-TTK-NET`, AS20485 - [ComNews, 15 июля 2024 — «YouTube не показался „Ростелекому“»](https://www.comnews.ru/content/234315/2024-07-15/2024-w29/1007/youtube-ne-pokazalsya-rostelekomu) — заявление «Ростелекома» от 12 июля 2024 - [Обзор Runnin4ik/ggc-russia на GitHub](https://github.com/Runnin4ik/ggc-russia) — компиляция по GGC в России, цифры расчётные - Служебная страница Google, которую участники используют для проверки кластера: https://redirector.gvt1.com/report_mapping?di=no - Форум ntc.party, тема от 17 октября 2026 об отдаче YouTube через разные кэши `googlevideo.com`: прямой ссылки нет, форум недоступен с сервера, который собирает вики - Собственные замеры 20 октября 2026 года с хостинга в Москве (AS207957) и с сервера Zapret DNS в Нидерландах (AS41745): TCP, TLS (разные имена и регистр, разрез приветствия, запись пакетов) и HTTP к узлам блока `GOOGLE-TTK-NET` и к контрольным адресам ## 📚 См. также - [[DPI/ttk-youtube-ggc-october-2026|ТТК и YouTube: кэши Google в сети Транстелекома (с 17 октября 2026)]] — инцидент, для разбора которого написана эта заметка - [[DPI/googlevideo-pcap-analysis-ttk-october-2026|Как читать pcap видеосоединения с узлом googlevideo]] — разбор записей трафика к узлу ТТК - [[Zapret/youtube|YouTube в Zapret]] — три области обхода и вкладка `GoogleVideo` - [[Zapret2/find-domain-owner|Как определить владельца домена или IP]] — как проверять подсеть узла --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/ggc-googlevideo-how-it-works.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).