loop-uh
baf0091fa3
Some checks failed
Published content check / validate (push) Failing after 17s
git.zapret.moe в России заблокирован по имени, как и wiki.zapret.moe. Ссылки на Forgejo во всех заметках, футерах, wizard.html и главной заменены на git2.zapret.moe (включая закодированные адреса значков shields.io). Какое имя рабочее, теперь решают реестры хоста /etc/zapret-*-domains.conf через zapret-site-names: pre-commit хук vault отклоняет добавленные строки с заблокированным именем, сборка Quartz сама переводит ссылки и baseUrl на рабочие имена. Правило в AGENTS.md переписано под этот механизм. scripts/wiki-stats.py: переходы с любых имён вики и git (wikiN, gitN) больше не считаются внешними сайтами. content-check: проверка зеркал сторонних проектов узнаёт любое имя git. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
148 lines
29 KiB
Markdown
148 lines
29 KiB
Markdown
---
|
||
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] Резервное зеркало
|
||
> Актуальная версия этой страницы — на основной вики: [wiki2.zapret.moe/DPI/ggc-googlevideo-how-it-works](https://wiki2.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://git2.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/ggc-googlevideo-how-it-works.md) · [скачать весь репозиторий одним zip-архивом](https://git2.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).
|