Глобальная доставка видео: регионы и резидентность данных

TL;DR

Расстояние – это налог, который вы платите в миллисекундах: свет в волокне ползёт со скоростью около двух третей вакуумной, поэтому зритель, которого обслуживают с другого континента, теряет сотни миллисекунд на одной физике – ещё до того, как сервер хоть что-то сделает, – и эта задержка прямо превращается в медленный старт и ушедшего зрителя. Глобальная стриминговая платформа борется с этим налогом, размещая edge близко к зрителям в каждом значимом регионе и доставляя каждый запрос к сетево-ближайшему edge двумя приёмами маршрутизации – GeoDNS (служба имён отдаёт адрес ближнего сервера) и anycast (один адрес анонсируется из многих мест, а интернет-маршрутизация ведёт каждого зрителя к ближайшему – см. IETF RFC 4786). Сложны не плотные регионы (Сев. Америка, Зап. Европа, развитая Вост. Азия, где PoP густы, а задержка мала), а длинный хвост – большая часть Африки, внутренняя Юж. Америка, Центр. Азия, Тихий океан, – где PoP редки, трафик идёт долгим backhaul по подводным кабелям, а решения локальны: пиринг на IXP, кэши внутри местного ISP (Netflix Open Connect, Google Global Cache, CloudFront Embedded PoPs) и региональный или multi-CDN-набор. И география – это три разные карты, которые основатели постоянно путают: откуда вы отдаёте байты (производительность), где по закону могут жить персональные данные (residency – глава V GDPR, 242-ФЗ РФ, PIPL КНР) и где контент лицензирован для показа (права, гео-блокировка). Спутаете их – выпустите платформу быструю, нелегальную или нарушающую договор со студией.

Почему это важно

Платформа, которая отлично тестируется в Москве или Сан-Франциско, может быть неюзабельной в Лагосе или Лиме, и команда часто узнаёт об этом только из тикетов поддержки, потому что причина невидима из сети головного офиса: зритель просто слишком далеко от ближайшей копии видео. География решает startup time, startup time решает отток, а отток решает, удастся ли запуск на новом рынке, – поэтому «какие регионы мы реально обслуживаем хорошо и как» это продуктовый вопрос, а не технический пустяк. Статья для основателя, продакт-менеджера или стриминг-инженера, который выводит сервис более чем в одну страну и должен понимать механику достаточно, чтобы поставить задачу CDN-вендору, заложить бюджет на действительно трудные регионы и не попасть в юридическую ловушку перемещения данных зрителей туда, куда нельзя. К концу вы сможете объяснить, почему зритель в одной стране получает быстрый старт, а в другой – спиннер, что делать с регионами, в которых тонок любой глобальный CDN, и почему «откуда отдаются байты» – это другой вопрос, чем «где хранятся данные» и «где разрешено показывать».

Краткое напоминание: магазин у дома, теперь по всему миру

Статья опирается на как CDN доставляет видео и механику origin из origin и origin shielding; вот одна мысль, которую нужно держать перед глазами.

Сеть доставки контента – всемирный парк кэширующих серверов, CDN, что держит копии вашего видео рядом со зрителями, – работает как сеть магазинов у дома, снабжаемых с одного центрального склада. Origin – это склад (единственная истинная копия каждого файла); edge-точки CDN, сгруппированные в точки присутствия (PoP – это площадка CDN в городе с её серверами и каналами), это магазины у дома. Когда ближний магазин держит то, что зритель попросил, это попадание в кэш – быстро и дёшево. Весь смысл сети – чтобы зритель покупал в ближнем магазине, а не ехал на склад.

География – это вопрос, который напоминание прячет: насколько близко это «близко», в любой точке Земли? В городе с PoP в нескольких километрах – очень близко. В регионе, где ближайший PoP на другом континенте, – совсем не близко, и этот разрыв, измеряемый в миллисекундах расстояния, и есть тема статьи.

Расстояние – это налог, а единица измерения – миллисекунды

Начнём с физики, потому что это пол под всем остальным и он никуда не девается. Свет в вакууме идёт около 300 000 км/с, но свет в стекле оптического волокна идёт примерно на две трети медленнее – около 200 000 км/с. Инженеры превращают это в правило: один километр волокна добавляет около 5 микросекунд задержки в одну сторону, поэтому round trip (туда и обратно) стоит около 10 микросекунд на километр, или 10 миллисекунд на каждые 1 000 км. Это «правило 5 микросекунд», и его не обойти апгрейдом оборудования – это скорость света в стекле.

И вот что усугубляет: волокно не идёт по прямой. Кабели тянутся вдоль побережий, железнодорожных коридоров и маршрутов подводных кабелей по дну, поэтому реальный путь между двумя городами обычно в 1,5 раза длиннее прямой (по большому кругу) или больше. Значение имеет длина стекла, а не линия на карте.

Проговорим арифметику вслух, потому что весь аргумент – в величине числа. Возьмём зрителя в Сан-Паулу и сервер в Сев. Вирджинии (US-East), «ближний» облачный регион для Америк по умолчанию, если вы ещё не построились в Юж. Америке:

Расстояние по большому кругу, Сан-Паулу → Сев. Вирджиния ≈ 7 600 км
Реальный путь волокна ≈ 1,5× ≈ 11 000 км стекла
Round-trip propagation = 11 000 км × 10 мкс/км = 110 мс
   …это ТОЛЬКО round trip света, до любой работы сервера.

Старт защищённого адаптивного потока — это не один round trip. Плеер должен:
   разрешить DNS → открыть соединение → согласовать TLS
   → взять манифест → взять init-сегмент → взять первый медиа-сегмент
   ≈ 4–6 round trip до первого кадра.

Налог расстояния ≈ 5 round trip × 110 мс ≈ 550 мс чистой задержки
   поверх собственного времени обработки каждого сервера.

Поставьте edge В Сан-Паулу (в нескольких км, < 2 мс round trip):
   те же 5 round trip стоят ≈ 5 × 2 мс = 10 мс.
   Налог расстояния падает с ~550 мс до ~10 мс.

Эти полсекунды – не погрешность округления. Время от нажатия на «play» до первого кадра, startup time (video start time), – один из сильнейших предикторов того, останется зритель или уйдёт; измерение мы разбираем в QoE: startup time и ребуферизация. Новые транспортные протоколы помогают на полях – TLS 1.3 срезает один round trip рукопожатия, а QUIC может начать передачу за ноль round trip, – но они режут число поездок, а не длину каждой. Сократить длину можно лишь короче сделав стекло: положить копию видео в регион. Этот факт и есть причина, почему «глобальная доставка» на самом деле «региональная доставка, везде».

Нажмите, чтобы увеличить

Как запрос находит ближайший edge: GeoDNS и anycast

Если ответ – «поставить edge в регионе», следующий вопрос механический: когда зритель жмёт «play», как его запрос попадает к правильному edge, а не к случайному? Почти всю эту работу делают два приёма, и большинство крупных CDN используют оба вместе.

Первый – GeoDNS (географический DNS). Любое устройство находит сервер, сначала спросив систему доменных имён – адресную книгу интернета, описанную в IETF RFC 1035, что превращает имя вроде video.example.com в числовой IP-адрес. С GeoDNS CDN держит свою адресную книгу и даёт разный ответ в зависимости от того, откуда вопрос как будто пришёл: резолвер, похожий на бразильский, получает адрес PoP Сан-Паулу; похожий на немецкий – Франкфурт. У каждого PoP свой адрес, и служба имён направляет каждого зрителя к ближнему. Слабость – в слове «как будто»: GeoDNS маршрутизирует по географической близости, угаданной по местоположению резолвера, а географически ближайший не всегда сетево-ближайший. Особенность пиринга или загруженный канал могут сделать чуть более дальний PoP реально быстрее, а GeoDNS этого не видит.

Второй – anycast, и он хитрее. Вместо своего адреса на каждый PoP anycast анонсирует один и тот же адрес сразу из многих PoP – Токио, Лондон и Сан-Паулу все объявляют, что они и есть пункт назначения для этого одного IP. Маршрутизация интернета (BGP – протокол, которым сети сообщают друг другу «чтобы дойти до этого адреса, идите так») затем доставляет пакеты каждого зрителя к тому анонсирующему PoP, что топологически ближайший – на наименьшем числе сетевых хопов, – автоматически. IETF описывает эту практику в RFC 4786, «Operation of Anycast Services» (Best Current Practice 126, 2006): сервис делается доступным по одному адресу из многих мест, и маршрутизация выбирает ближайший узел для каждого клиента. Изящество в том, что маршрутизация уже знает форму сети, поэтому anycast обычно находит сетево-ближайший PoP, а не просто географически ближайший, и если PoP выходит из строя, его адрес просто перестаёт анонсироваться, а трафик уходит к следующему ближайшему – failover бесплатно.

Представьте это как два способа отправить человека в ближайший филиал магазина. GeoDNS – это справочник, что печатает свой адрес филиала на листовке для каждого района, но угадывает ваш район по почтовому индексу. Anycast – это один и тот же телефон на всех филиалах, и телефонная сеть соединяет каждого звонящего с ближайшим, кто поднял трубку. На практике CDN их смешивают: anycast – для устойчивой, сетево-осведомлённой маршрутизации, GeoDNS и real-user-измерения сверху – чтобы поправить редкую плохую догадку anycast.

Нажмите, чтобы увеличить

Карта неровная: плотные регионы и длинный хвост

Вот факт, который вендорские карты с их успокаивающим россыпью точек скрывают: покрытие CDN дико неравномерно, и неравномерность следует за населением, деньгами и подводными кабелями, а не за потребностью. На 2026 год крупные CDN публикуют очень разные охваты – Cloudflare заявляет присутствие в 330+ городах, Akamai – 4 100+ точек присутствия и сотни тысяч серверов, встроенных в 1 000+ сетей в 130+ странах, а AWS CloudFront – 600+ точек присутствия в десятках стран (цифры вендорские, 2026, и постоянно меняются). Но эти точки кучкуются. Сев. Америка, Зап. Европа и развитая Вост. Азия густо усеяны PoP и короткими прогонами волокна; большие части Африки, внутренней Юж. Америки, Центр. Азии и тихоокеанских островов тонки, и зритель там часто обслуживается с другого континента по длинному пути подводного кабеля.

Инфраструктурные данные показывают ту же форму. Подводные кабели несут подавляющую долю межконтинентального трафика, а пиринг – объём трафика, которым сети обмениваются напрямую, – в недообслуженных регионах драматически ниже: отраслевые замеры ставят Юж. Америку и Африку в низ таблицы, доля от европейского или североамериканского объёма, потому что там меньше точек обмена трафиком (IXP) – общих площадок, где соединяются местные сети, – и меньше инвестиций в магистрали. Меньше локального обмена – значит больше трафика вынуждено покидать регион в поисках контента, а это длиннее пути и выше задержка. Это и хрупкость: когда в 2024 году у Вост. Африки перерезали подводные кабели, целые страны увидели обвал связности, потому что не было плотной местной сети, на которую можно опереться. Бейдж «глобальный CDN» не делает эти регионы быстрыми; он лишь означает, что у провайдера есть какое-то присутствие где-то.

Это проблема длинного хвоста, и именно здесь глобальная доставка реально трудна. Три тактики её решают, и серьёзные платформы используют их в сочетании.

Первая – локальный обмен трафиком: вывести трафик на региональный IXP, чтобы он дошёл до местных ISP напрямую, а не делал крюк через Европу или США. Локальный пиринг через IXP способен резко срезать задержку, потому что байты вообще не покидают регион; Африканский союз и операторы IXP давно продвигают местные точки обмена именно потому, что локальная маршрутизация часто во много раз быстрее международного крюка, который она заменяет.

Вторая, и самая мощная для популярных каталогов, – встроенный кэш: кэширующий сервер, размещённый внутри собственной сети ISP, максимально близко к зрителю. Так крупнейшие стримеры покоряют длинный хвост. Netflix Open Connect даёт подходящим ISP Open Connect Appliance (OCA) – поставляемое Netflix железо, что стоит на площадке ISP и отдаёт контент Netflix локально; это «directed cache», обслуживающий только те IP-диапазоны, что ISP анонсирует ему по BGP, и Netflix даёт его бесплатно, а ISP даёт питание, место и связность. Google Global Cache (GGC) делает то же для YouTube и Google Play – серверы Google внутри ISP кэшируют контент, популярный у пользователей этого ISP, и держат трафик локальным. CDN теперь предлагают паттерн и как продукт: CloudFront Embedded Points of Presence ставят железо AWS внутри сетей ISP, чтобы срезать last-mile-задержку. Принцип тот же, что у origin shield, но вывернутый наружу: вместо одного shield у origin вы ставите кэш в собственный ISP зрителя, чтобы популярные байты были уже в здании.

Третья – региональный или multi-CDN-набор: там, где ваш глобальный CDN тонок, добавьте CDN, сильный именно в этом регионе (местный специалист часто обходит глобальный бренд на своей территории), и направляйте региональный трафик к нему. Это региональное лицо архитектуры из multi-CDN: архитектура и оркестрация; протокольную механику выбора multi-CDN глубже нас разбирает материал по multi-CDN раздела Video Streaming.

Таблица 1. Пять способов добраться до зрителей и колонка, что важна для длинного хвоста: держит ли тактика байты внутри региона или всё равно делает backhaul через океан? Тактики плотных регионов (anycast, GeoDNS) держат трафик локальным лишь там, где у CDN уже есть PoP; длинному хвосту нужны встроенные кэши, локальный пиринг или региональный CDN.

Три географии, которые путают основатели

Теперь концептуальная ловушка, что приносит самые дорогие ошибки, потому что невидима, пока на неё не укажет регулятор или юрист студии. «География» в стриминге – не одна карта. Это три, управляемые тремя совершенно разными силами, и проектировать их надо порознь.

Первая – география доставки – откуда вы отдаёте байты. Это всё вышеописанное: PoP, регионы, маршрутизация, встроенные кэши. Управляют физика и стоимость, цель – «близко к зрителю». Сегмент видео – это просто байты; отдать его с ближнего edge это решение о производительности.

Вторая – data residency – где по закону разрешено жить персональным данным о зрителях. Управляет закон, а не физика, и цель – «там, где требуют правила». Общий регламент ЕС по защите данных (GDPR, Регламент (ЕС) 2016/679) не запрещает данным покидать ЕС, но его глава V (статьи 44–50) разрешает передачу персональных данных за пределы ЕЭП лишь при особых условиях – чище всего в страну, которую ЕС счёл обеспечивающей «адекватный уровень защиты» (ст. 45), либо при одобренных гарантиях. Другие страны идут дальше, в жёсткую локализацию: Федеральный закон РФ 242-ФЗ требует, чтобы персональные данные граждан РФ хранились на серверах физически в России; PIPL КНР и Закон о кибербезопасности требуют хранения в стране для определённых операторов и формальной оценки до вывоза данных. Более шестидесяти стран сейчас вводят то или иное требование residency или локализации, и их число с 2020 года более чем удвоилось. Важно: само видео обычно не «персональные данные» – но записи просмотров, данные аккаунта, история и профили для таргетинга безусловно да, и именно их неосторожная глобальная архитектура реплицирует не в ту страну. Юридическая сторона этого живёт в конфиденциальность и данные просмотра: VPPA, GDPR, CCPA.

Третья – география прав – где вы лицензированы показывать конкретный тайтл. Управляют контракты на контент, цель – «только там, где купили права». Фильм, лицензированный для Германии, не должен играть во Франции, и платформа обеспечивает это гео-блокировкой. Это снова другая карта, и владеет ею слой лицензирования; мы разбираем её в лицензирование по территориям и гео-блокировка, не здесь.

Почему это так важно: три карты редко совпадают. Вы можете отдавать байты российского зрителя с быстрого edge в стране (доставка), при этом данные его аккаунта тоже должны оставаться в стране (residency, 242-ФЗ), при этом конкретный голливудский тайтл может быть вовсе гео-заблокирован для России (права). Три независимых ограничения, три независимых проекта. Команда, что воспринимает «мы глобальны» как один тумблер, рано или поздно будет отдавать быстрое видео, тихо нарушая закон о данных или договор со студией.

Нажмите, чтобы увеличить

Рабочий план: вывод сервиса в новый регион

Соберём всё в решение, с которым сталкивается реальная команда при экспансии. Скажем, европейский SVOD-сервис запускается в Бразилии и Нигерии. Рассуждение идёт в том же порядке для обоих, а ответы различаются.

Для Бразилии аудитория сосредоточена в нескольких крупных прибрежных мегаполисах, у крупных CDN есть PoP в Сан-Паулу, а подводные кабели до Сев. Америки и Европы неплохи. Доставка: включите региональные PoP, проверьте, что anycast реально приземляет бразильских зрителей на Сан-Паулу (замерьте, не предполагайте), и для популярного каталога изучите встроенные кэши у крупнейших бразильских ISP. Residency: бразильский закон о данных (LGPD) формирует, как обращаться с данными просмотра, поэтому аналитике и хранилищам аккаунтов нужен комплаентный дизайн, хотя доставка проста. Права: подтвердите лицензию на Бразилию для каждого тайтла до того, как он появится в каталоге. Бразилия – «достаточно плотный» регион; большая часть работы это конфигурация и замеры.

Для Нигерии картина труднее, и бюджет это должен отразить. PoP реже, больше трафика зависит от меньшего набора подводных кабелей, и обрыв кабеля может разом ухудшить весь регион (как показали западно- и восточноафриканские аварии 2024 года). Доставка: PoP глобального CDN может быть в соседней стране, а не в самой стране, поэтому реалистичны локальный пиринг на IXP для прямого выхода к нигерийским ISP, встроенный кэш у крупнейших местных ISP и вполне возможно региональный CDN, специализирующийся на африканской доставке, подмешанный через multi-CDN. Устойчивость важнее: при меньшем числе кабельных путей один отказ скорее будет ощутим, поэтому плану доставки нужен региональный fallback. Пол задержки выше бразильского при любом раскладе, поэтому encoding ladder и поведение плеера на старте (см. низкая задержка доставки и доставка живых событий) стоит настраивать под более тяжёлую сеть, а не под офисную.

Два региона, один метод: нанесите аудиторию, выберите тактику доставки, что держит байты ближе всего, проверьте закон о residency для данных, проверьте права для каталога и спланируйте устойчивость под кабельную реальность. Стоимость двух запусков не одинакова, и притворяться, что одинакова – закладывать Нигерию как Бразилию, – это как новый рынок недополучает.

Нажмите, чтобы увеличить

Частые ошибки, что делают регион медленным или нелегальным

Большинство провалов глобальной доставки не экзотичны; это допущение головного офиса, встретившее регион, под который оно не подходит.

Главная ошибка – считать «глобальный CDN» однородным – полагать, что задержка, что вы меряете в офисе, такая же везде, тогда как регионы длинного хвоста обслуживаются с другого континента и чувствуют полсекунды налога расстояния, которых офис не видит. Её родственница – доверять географически ближайшему PoP вместо сетево-ближайшего – опираться на сырую географическую близость GeoDNS, когда особенность пиринга делает «ближний» PoP медленнее, вместо того чтобы мерить real-user-задержку и дать anycast и замерам поправить догадку. Третья – держать один глобальный CDN с тонким регионом и без локального присутствия, так что зрители в регионе делают backhaul через океан без встроенного кэша и пиринга на IXP. Четвёртая, самая опасная, – путать три географии – строить один «международный» тумблер, что отдаёт байты, хранит перс. данные и открывает каталог одинаково везде, тихо нарушая закон о residency (242-ФЗ, PIPL, глава V GDPR) или лицензию в момент пересечения границы. Пятая – игнорировать подводный кабель как единую точку отказа для прибрежного или островного региона, так что один обрыв роняет всю аудиторию, потому что не было регионального fallback. И тихая шестая – разместить origin далеко от нового региона без shield или in-region tier, так что даже зрители у edge платят трансокеанский налог на каждом промахе – отказ, что прямо тянется к origin и origin shielding и проявляется на дашборде наблюдаемости доставки как регион с высоким startup time и низким cache-hit ratio.

Где здесь Фора Софт

Глобализация – это задача масштаба и охвата прежде, чем техническая: вопрос не «есть ли у нас CDN», а «какие регионы мы реально обслуживаем хорошо, во что обходится каждый трудный регион и где разрешено жить данным» – и регионы, что на карте покрытия выглядят запоздалой мыслью, как раз и решают, удастся ли запуск на новом рынке. Фора Софт строит ПО для видеостриминга, OTT/Internet TV, живых событий, e-learning и телемедицины с 2005 года, в 250+ выпущенных проектах для 400+ клиентов, во многом для аудиторий, разбросанных по континентам, и эта работа идёт прямо через этот слой: нанести, где зрители реально, выбрать тактики доставки на регион (маршрутизация anycast и GeoDNS, встроенные кэши в ISP, пиринг на IXP и региональные multi-CDN-наборы) и – не менее важно – держать географию доставки, data residency и права на контент тремя отдельными, осознанно спроектированными картами, а не одним тумблером на удачу. Когда медиакомпании нужна платформа, что быстра в реально трудных регионах и комплаентна в тех, где строгие законы о данных, – эта инженерия региональной доставки и есть то, что мы привносим.

Ключевые выводы

• Расстояние – налог на задержку: ~10 мс round trip на 1 000 км волокна, а старт потока складывает несколько round trip.
• Зритель с другого континента может потерять полсекунды startup time, которые сэкономил бы edge в регионе.
• GeoDNS ведёт по географической догадке; anycast (RFC 4786) анонсирует один адрес и ведёт к сетево-ближайшему PoP.
• Покрытие CDN неровное – густо в Сев. Америке/Европе/Вост. Азии, редко в Африке, внутренней Юж. Америке, Центр. Азии.
• Решение для хвоста локально: пиринг на IXP, встроенные кэши в ISP (Open Connect, GGC, CloudFront Embedded) и региональный/multi-CDN.
• Доставка, data residency (глава V GDPR, 242-ФЗ, PIPL) и права на контент – три разные карты; проектируйте каждую отдельно.

Что почитать дальше

• Multi-CDN: архитектура и оркестрация
• Стоимость CDN: egress, коммиты и 95-й перцентиль
• QoE: startup time и ребуферизация