сеть доставки контента что это
Что такое CDN и как это работает?
Цифры и факты (вместо введения)
О том, что в Интернете с каждым годом становится все больше «тяжелого» контента.
А также о том, что в современном мире огромную роль играет скорость работы веб-сайтов и сервисов. Если скорость слишком мала ― это чревато потерей аудитории, а во многих случаях ― ещё и прибыли. Один из надёжных способов решения этой проблемы ― использование сетей доставки контента (Content Delivery Networks, CDN).
Selectel предлагает услугу CDN с 2014 года, и мы подробно изучили техническую сторону вопроса. В этой статье поговорим об устройстве и особенностях работы современных CDN.
Основные термины
Прежде чем начать предметный разговор об особенностях CDN, определимся с основной терминологией.
CDN (Content Delivery Network) — это географически распределённая сетевая инфраструктура, обеспечивающая быструю доставку контента пользователям веб-сервисов и сайтов. Входящие в состав CDN cерверы географически располагаются таким образом, чтобы сделать время ответа для пользователей сайта/сервиса минимальным.
Ориджин (origin) — сервер, на котором хранятся исходные файлы или данные, раздаваемые через CDN.
PoP (point of presence, точка присутствия) — кэширующий сервер в составе CDN, расположенный в определенной географической локации. Для обозначения таких серверов также используется термин edge.
Динамический контент ― контент, генерируемый на сервере в момент получения запроса (либо изменяемый пользователем, либо загружаемый из базы данных).
Статический контент ― контент, хранимый на сервере в неизменяемом виде (например, бинарные файлы, аудио- и видеофайлы, JS и CSS).
Немного истории и теории
Резкий рост Интернета в середине 1990-х привел к ситуации, что серверы стали с трудом выдерживать нагрузку. С серверами того времени (которые по техническим характеристикам иногда были слабее не самого производительного современного ноутбука) приходилось идти на разные ухищрения: погуглите, например, «иерархическое кэширование» и information superhighway ― сейчас эти словосочетания используются разве что в статьях по истории интернет-технологий. Чтобы понять, как развивались технологии раздачи контента, сделаем небольшое теоретическое отступление.
Обратим внимание: раздача статического и динамического контента связаны с разными типами нагрузки на сервер. В случае с динамическим контентом, генерация которого связана с обращениями к базе данных, важны быстродействие процессора и объём оперативной памяти.
Для раздачи статического контента, который в большинстве случаев оказывается очень «тяжелым» и который нужно загрузить очень быстро, важна в первую очередь скорость сети. Смысл технических решений для ускорения раздачи статики заключается в следующем: обеспечить горизонтальное масштабирование без сложных двусторонних синхронизаций с основным сервером.
Для снижения нагрузки владельцы веб-сервисов ещё в конце 1990-х годов начали раздавать статику и динамику с разных серверов. Крупные веб-проекты с огромной аудиторией, разбросанной по всему миру, начали размещать серверы со статикой в разных географических точках.
Тогда же, в конце 1990-х, стали появляться компании, у которых организация раздачи статики стала одним из основных направлений бизнеса. В 1998 году студент Массачусетского технологического института Дэниэл Левин и преподаватель математики Томсон Лейтон основали компанию Akamai. Ныне она является одним из крупнейших (если не самым крупным) CDN-провайдером в мире.
Уже в 2004 году CDN использовали более 3000 компаний; общий объем расходов на доставку контента составлял до 20 миллионов долларов в месяц.
Количество CDN во всём мире постоянно растет: соответствующие услуги предоставляют как крупные международные компании (например, Akamai, Amazon, Cloudflare), так и многочисленные региональные провайдеры (подробные обзоры).
CDN используется не только для раздачи статики в строгом смысле слова: распределение контента по многочисленным серверам в разных точках планеты помогает обеспечивать доступность в периоды пиковых нагрузок.
В течение последних 10-12 лет широкое распространение в Интернете получил еще один тип контента ― стриминговый (многочисленные сервисы потокового аудио и видео, которые в наши дни имеют огромную популярность и миллионную, если не миллиардную, аудиторию). Раздача сегодня является еще одним распространенным сценарием использования CDN.
Рассмотрим принципы работы и особенности использования CDN более подробно.
Как работает CDN
Представим себе веб-сервис, которым пользуются люди на всей территории России. Основные серверы расположены в Санкт-Петербурге, а пользователи находятся в самых разных географических точках: скажем, в Краснодаре (2 604,2 км от Петербурга), Новосибирске (3 826,1 км), Иркутске (5 661, 7 км) или Владивостоке (9 602, 4 км). Чем дальше пользователь находится от оригинального сервера, тем больше время «оригинального» ответа. На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли дожидаться полной загрузки простой веб-страницы полновесные 5, а то и все 10, минут.
При использовании CDN всё происходит по-другому: пользователь из Владивостока переадресуется к географически ближайшему кэширующему серверу в составе CDN, благодаря чему доставка статического контента происходит гораздо быстрее.
Для ускорения раздачи динамики при использовании CDN используются другие механизмы: CDN-провайдер за счет своей сети сокращает сетевой маршрут.
Ещё один интересный сценарий использования CDN ― так называемый live-streaming: пользователи Интернета со всего мира могут в браузере (а иногда и в специальном приложении) смотреть или слушать трансляцию с мест событий. Устроено это так: один или несколько ориджин-серверов принимают c видеокамеры транслируемый поток, который сразу же ретранслируется на точки присутствия. Ориджин-серверы при этом контент клиентам не раздают. В состав стриминговых CDN входят также балансировщики нагрузки, перенаправляющие запросы к наименее загруженным на текущий момент edge-серверам.
Как организована раздача контента?
Как правило, для настройки раздачи статического контента через CDN необходимо выполнить следующие шаги:
Шаг 1: Вынести статику сайта на отдельный домен, например, static.example.com — это будет origin.
Шаг 2: Для работы через CDN создать домен вида cdn.example.com.
Шаг 3: Подключить CDN у провайдера. Для подключения владельцу веб-сервиса необходимо сообщить провайдеру следующее:
домен, с которого он будет забирать статику — static.example.com;
домен, с которого будет идти раздача — cdn.example.com.
Шаг 4: У своего DNS-регистратора настроить CNAME запись с cdn.example.com на домен CDN-провайдера, который CDN провайдер выделяет при подключении.
Например, в CDN Selectel такой домен имеет вид 85e77c09-bc03-43bf-b8f3-9492ae33390f.selcdn.net, где 85e72c09-bc03-43bf-b8f3-9492ae33390f генерируется автоматически.
Шаг 5: На своем сайте изменить домен для статики, которую планируется раздавать через CDN, на cdn.example.com.
Пользователь набирает в строке браузера адрес www.example.com, с которого он получает HTML-страницу. При этом весь статический контент, например, графические изображения, подгружается из CDN (с адреса cdn.example.com).
Статический контент, предназначенный для раздачи, часто помещается в объектные хранилища (об этом мы писали еще шесть лет назад). Существует множество плагинов и расширений для популярных CMS (WordPress, Joomla, Drupal, 1C Битрикс и других), с помощью которых можно настроить интеграцию с облачными сервисами хранения и раздачу статики через CDN.
Веб-сервис после подключения CDN будет работать на том же оригинальном сервере. Кэшированные части сайта будут загружены на серверы CDN-сети. Система находит для пользователя ближайший сервер и максимально быстро загружает статику сайта с него.
Обратим внимание на один важный момент: серверы, входящие в состав CDN, не являются подобием файловых серверов, на которые контент размещается для последующего скачивания. CDN используются не для хранения контента, а для кэширования на основе конкретных алгоритмов.
Как CDN понимает, где находится ближайший кэширующий сервер?
Как правило, для подгрузки контента из CDN используются две популярные технологии: GeoDNS и AnyCast.
С помощью GeoDNS можно привязать к одному доменному имени несколько IP-адресов. В зависимости от географического положения (определяется по IP-адресу, с которого пришел запрос) пользователь перенаправляется на ближайший сервер. Об особенностях работы GeoDNS можно почитать в этой статье (на английском языке).
При использовании технологии Anycast адреса общие, но маршрутизация происходит на «свои» серверы в пределах региона. При обращении к адресу www.example.com пользователь переадресуется на ближайшую точку присутствия. Провайдер пользователя получает несколько анонсов от разных сетей, в которых есть точка присутствия, и маршрутизатор провайдера выбирает из них самый близкий. Ответ аналогичным образом возвращается по наиболее короткому маршруту.
Как кэшируется контент?
Самой распространенной является схема по первому обращению: максимальное количество времени на загрузку затрачивает пользователь, обратившийся к оригинальному серверу первым. Все последующие пользователи будут получать данные, кэшированные на ближайшей к ним точке присутствия.
Здесь очень важна география: например, после обращения пользователя из Рио-де-Жанейро данные будут закэшированы на сервере, находящемся на территории Бразилии, что не решит проблемы со скоростью доступа для пользователей из Парижа или Лондона.
Для преодоления ограничений, накладываемых этой схемой, используются технологии регионального извлечения: соседние серверы, входящие в состав CDN, забирают контент друг у друга, а не обращаются к оригинальному серверу.
В большинстве CDN пользователь, отправивший запрос на получение статического контента, переадресуется к ближайшей точке присутствия и получает кэшированную версию этого контента с неё. Если ближайшая точка присутствия не сможет найти файлы, начнётся поиск по соседним точкам присутствия, откуда и будет перенаправлен ответ пользователю. В CDN Akamai эта процедура называется tiered distribution (на русский можно перевести как «многоуровневая раздача»).
Для чего используются CDN?
Чаще всего CDN используется для уменьшения времени отклика кэшированного контента, что, как мы уже упоминали выше, уменьшает отток посетителей из-за медленной загрузки ресурса и тем самым сокращает возможные финансовые потери. Также CDN помогает снизить риск потери доступа к контенту из-за падения основного сервера. Контент будет доступен всё время, пока вы восстанавливаете работоспособность основного сервера.
Использование CDN существенно снижает нагрузку на основной сервер, что помогает решить проблему пиковых нагрузок. Современная CDN способна переживать очень большие нагрузки. В конце 2018 года компания Akamai заявила о рекордном объеме передаваемого через CDN трафика: 72 Тб/c.
В наше время CDN активно используются также для раздачи стримингового контента.
О чем важно помнить при работе с CDN?
Как и любая технология, CDN обладает рядом особенностей.
Самая первая проблема, с которой могут столкнуться использующие CDN веб-сервисы ― это задержки кэширования. Вполне вероятна следующая ситуация: на основном сервере файл был изменён, а вот на кэширующих серверах он всё ещё будет лежать в неизмененном виде. Это особенно важно, когда через CDN распространяется часто обновляемый контент (фотографии с места событий, новые версии ПО и так далее)
Чтобы обеспечить доставку «свежего» контента в современных CDN имеется функция очистки кэша, то есть удаление контента из пула кэширования. Кроме того, владельцы сайтов и сервисов могут сами управлять настройками, используя заголовки-валидаторы (см. наши рекомендации на эту тему в опубликованной ранее статье).
Еще одна сложность связана с блокировками: если по той или иной причине будут заблокированы сервисы, являющиеся вашими «соседями» по IP CDN-провайдера, вместе с вами может оказаться заблокированным и ваш сайт. Но и это проблема решаема: по запросу CDN-провайдеры могут изменить ваш IP-адрес.
Кому нужны CDN?
CDN нужны в первую очередь проектам с большой аудиторией в разных регионах или странах. Здесь всё ясно: снижение задержек, быстрая раздача контента и повышение уровня удобства, и, как следствие, больше довольных пользователей.
CDN может пригодиться также разработчикам мобильных приложений: по статистике, пользователи часто отказываются продолжать работу с приложением из-за проблем со скоростью. В последнее время появились специальные технические решения, ориентированные на раздачу контента на мобильные устройства. Они так и называются ― Mobile CDNs. Соответствующие услуги предлагают многие крупные CDN-провайдеры ― например, Akamai или Amazon.
Нужны CDN и проектам, ориентированным на распространение игрового, мультимедийного контента и стриминг (об этом уже было сказано выше).
На что обратить внимание при выборе CDN-провайдера (вместо заключения)
Число пользователей вашего веб-сервиса растет, аудитория расширяется, и вы задумываетесь о подключении CDN для оптимизации и ускорения раздачи статики и снижения нагрузки на основные серверы.
На что нужно обратить внимание при выборе CDN-провайдера?
Во-первых, на количество точек присутствия. Это особенно актуально для проектов с обширной международной аудиторией. Нелишним будет узнать информацию о точках присутствия в наиболее интересных для вас регионах и сопоставить их с потенциальной аудиторией сайта.
Во-вторых, это наличие стыков с операторами связи. Это тоже немаловажный фактор, от которого зависит скорость и эффективность работы CDN. Например, у CDN-провайдера с точками присутствия в 100 городах, но небольшим количеством стыков задержка может быть больше, чем у провайдера, у которого точки присутствия расположены в 5 городах, но стыков с операторами связи гораздо больше.
К сожалению, такую информацию в большинстве случаев CDN-провайдеры не публикуют, поэтому проверить всё можно только тестированием.
В-третьих, на наличие дополнительных услуг и функций. Многие CDN-провайдеры предоставляют такие услуги, как анализ статистики потребления, управление политиками кэширования, управление HTTP-заголовками, предзагрузка очень «тяжёлого» (от 200 МБ и более контента), полная и выборочная очистка кэша.
Кроме того, при выборе CDN-провайдера нужно проверить, поддерживает ли он необходимые вам технологии и протоколы (HTTP/2, IPv6, сертификаты SSL и другие).
Что такое CDN, и как это вообще работает
Сайт Texas Internet Consulting. Жив с 1987 года, страница — 7 Килобайт.
Помните время, когда главная больше 90 Килобайт считалась расточительством? С тех пор Интернет стал жирным. И понадобились инструменты, чтобы правильно раздавать трафик сразу с нескольких узлов. Например, во время очередного обновления Fortnite CDN от Akamai сумел переварить трафик мощностью в 106 Терабит в секунду. Давайте пробежимся по основным принципам этой технологии и потенциальным проблемам.
И о том, почему Minecraft в Казани тормозит, если не развернуть сервер в черте города.
Вот современный сайт, который соблюдает разумные рамки: 1,7 Мегабайта.
Пример относительно тяжёлого сайта с видеоконтентом и анимацией: 39,5 Мегабайта радости и шевеления.
Сейчас, когда 100 Мегабит домашнего Интернета воспринимаются вполне привычно, всё меньше дизайнеров заморачивается с кропотливым сжатием каждого изображения и экономии на мелочах. Ситуации, когда кто-то умный положил на главную картинку в PNG весом в 30 Мегабайт, бывают чаще, чем хотелось бы.
Исторические данные взяты здесь.
А если посмотреть на статистику, то тенденция к росту объёмов становится ещё более очевидной. Например, за 10 лет размеры средней страницы, рассчитанной на мобильные устройства, выросли в семь раз (с 233 до 1 864 Килобайт).
Проблема ширины канала
У вас есть много иллюстраций и видео, которые надо доставить клиенту. Передать однократно несколько Мегабайт не очень трудно: современные каналы связи позволяют делать это за секунды. Всё становится гораздо хуже, когда к вам на сайт одновременно заходят вначале несколько десятков, а потом — тысяч посетителей.
Давайте считать. Допустим, у вас один-единственный сервер и у вас типичная страница весом в 1,8 Мегабайта. Клиенты приходят к вам впервые и с «холодным» кэшем, то есть в браузере нет ранее загруженных материалов с вашего ресурса.
Чтобы отдать за приемлемые три секунды страницу, нам потребуется ширина канала в 4,8 Мегабита на одного посетителя. Если их придет 100, то это уже 480 Мегабит. А если вдруг потребуется отдать тем же людям небольшой видеофайл размером 10 Мегабайт, то нам потребуется канал в 2,7 Гигабита.
Таким образом, у вас появляется два основных типа контента: динамический и статический.
Статический контент, как следует из названия, не изменяется или меняется крайне редко. Например, это логотип веб-сайта. Или залитые образы с дистрибутивами ПО.
Динамический контент отличается тем, что он генерируется сервером «на лету». Обычно это происходит в момент самого запроса. Например, при клике на кнопку формируется плей-лист, уникальный для конкретного пользователя.
Именно для решения проблемы кэширования статического контента и были созданы CDN. Но, как мы увидим дальше, и с динамическим контентом CDN тоже могут помочь.
Почему не взлетел чистый multicast?
Схема работы multicast.
Мультикаст очень хорош. В отличие от юникаста он позволяет исходному серверу бросить в сторону клиентов только один пакет, который будет ретранслирован строго тем, кто его ожидает. В отличие от броадкаста не будет слать пакеты всем кому надо и не надо, засоряя Сеть мусором.
Одна проблема — поддержка оборудованием. Для того чтобы гарантировать, что multicast-пакет доедет до каждого клиента, нам нужно убедиться, что каждый промежуточный узел правильно сконфигурирован и готов доставить его дальше. В противном случае пакет «угаснет» где-то по дороге на тупом маршрутизаторе, а клиент не дождётся своей вечерней трансляции на YouTube. Именно поэтому вместо более продвинутого мультикаста взлетела географически распределённая сеть CDN, которая работает на более простом unicast.
Вторая проблема — 4K и грядущий 8K. Провайдеры уже нервно вздрагивают от объёмов трафика, а будет только хуже. В варианте чистого мультикаста вы не можете регулировать качество вещания. В случае того же Google Global Cache в качестве CDN вы можете отдавать локальным клиентам картинку в адаптивном битрейте. GGC закэшировал некоторый кусок видео и кормит своих клиентов в 4K. В этот момент у одного из клиентов возникают проблемы из-за перегрузки локальной сети. GGC автоматически снизит битрейт с учётом изменившейся ширины канала клиента и продолжит раздавать ролик.
Тем не менее технология очень привлекательна для IPTV, поэтому некоторые компании предлагают такие интересные решения, как nanoCDN Multicast ABR. Концепция строится на добавлении в сеть провайдера дополнительного узла-транскастера, который преобразует unicast от источника видео за пределами сети в multicast до конечного потребителя.
Мир без CDN
Итак, мы определились с тем, что нам потребуется очень много ресурсов для того, чтобы обслуживать всех посетителей из единой точки. Давайте попробуем представить, как выглядел бы современный веб без CDN. Каждая компания строит себе один огромный дата-центр и собирает все ресурсы в одной-единственной точке мира.
Централизованная раздача контента и распределённая схема через CDN.
Небольшие веб-ресурсы
Почти не пострадают. Даже сейчас есть множество местечковых форумов, посвящённых узкой тематике разведения, ну, например, алтайских перепелов. Там почти никогда не бывает огромного наплыва посетителей, почти нет тяжёлого контента. Они как жили в начале нулевых, так и продолжают в 2020 году, принося ценность своему небольшому сообществу.
Видеохостинг
Забудьте. Никакого YouTube, Vimeo и других ресурсов без CDN не будет (важно: торрент-сеть, по сути, тоже можно считать подвидом CDN в такой ситуации, но работающей по совершенно иным принципам).
Без CDN можете смело возвращаться в начало нулевых, когда видео было доступно по прямым ссылкам и его нужно было качать. Никакого стриминга, FlashGet и прочих хардкорных менеджеров загрузки. Причём речи о скачивании в реальном времени даже и близко не было бы. Уже сейчас, если верить статистике, один только YouTube генерирует 37 % всего мобильного трафика в мире. Это миллиард часов видео в сутки. Без географического распределения нагрузки подобные сервисы просто не родились бы.
Именно поэтому тот же Google предлагает установку в дата-центры крупных провайдеров своего оборудования, которое обеспечивает так называемый GGC — Google Global Cache. Когда вы тычете в популярный ролик на YouTube, то данные тащатся не из дата-центра в Калифорнии, а из ближайшего крупного узла связи вашего провайдера. Если ролик малопопулярен, то трафик уже прилетит из-за пределов внутренней сети провайдера, но будет закэширован.
Раньше провайдеры существенно экономили на трафике тем, что делали кэши и локальные файлшары. Тогда первый скачавший новую песню «Металлики» пользователь давал возможность провайдеру не платить за магистральный трафик для ещё 50 возжелавших, но выставить счёт пользователям как за обычный трафик. Можно сказать, что это был ещё один подвид CDN. Отсюда же растут уши идеи с retracker.local. В 2010 году nag.ru предложил оригинальную идею организации локальных ретрекеров под этим адресом у всех провайдеров для облегчения поиска локальных пиров и снижения внешнего трафика. Идею поддержал rutracker.org, начав добавлять этот адрес в дополнение к своим ретрекерам.
Мессенджеры
Выживут, но без всяких модных стикеров, трансляции геопозиции и прочих радостей. А ещё вы, скорее всего, можете забыть про пуши со стороны Google Services. То есть в Сети вы будете только тогда, когда запущено приложение, что означает непрерывное потребление батарейки. Можете вспоминать про ностальгические времена ICQ и Jabber. Он со своей федеративной системой был не так плох, кстати. Кое-где его до сих пор используют.
Магазины
Остались бы исключительно в формате странички локального мясного магазина с картой проезда и телефоном. А ещё придётся вспомнить старые добрые бумажные распечатки прайсов в магазинах компьютерных комплектующих. Amazon и Aliexpress просто не смогли бы существовать. У них и сейчас со всеми современными технологиями запредельные пиковые нагрузки в моменты распродаж, которые требуют сложнейшей балансировки и непростой облачной архитектуры. Тем не менее в парадигме «один дата-центр на магазин» можно было бы устраивать распродажи. Просто они шли бы медленнее. В случае отказоустойчивости в виде двух площадок часть проблем резервирования решилась бы, но каждый запрос пользователя ходил бы через всю страну именно до них без локального кэша. А если уж делать локальный кэш, то почему сразу же не сделать там же на узле и серверные приложения?
Отдалённые регионы
Если вы живёте в отдалённых регионах, куда не ведут широкие кабельные магистрали, то вам было бы совсем грустно. В начале нулевых вполне типичной была ситуация, когда жители Сахалина могли по пять минут ждать загрузки обычной веб-страницы. С современным вебом всё было бы ещё хуже: много ресурсов просто было бы сброшено по тайм-ауту, не загрузившись.
Проблема долгого пинга
Вторая проблема, которую решает CDN, — это ускорение запросов. Около вас есть локальный сервер, который кэширует статический контент и иногда сам умеет выдавать динамический. Если вам знакомы тормоза 1С при забегах из Владивостока в Москву или особенности работы с SAP через какой-нибудь корпоративный VPN в Европе из Новосибирска, то вы понимаете всю глубину боли. Сотни запросов незаметны при обычных сетевых задержках внутри города, но, когда расстояния увеличиваются, неиллюзорно тормозить начинает всё. Россия в этом плане выделяется тем, что у нас страна такого размера, где от случайного города до столицы может оказаться дальше, чем от этого же города до столицы другой страны. Это рождает интересные особенности туннелирования трафика серверных приложений той же MS.
Так что внутри современной CDN?
CDN — это общее название множества различных технологий, призванных доставлять статический контент как можно ближе и быстрее по отношению к клиенту. Например, torrent-раздача новой версии Ubuntu — это тоже CDN. А вы становитесь одним из узлов раздачи, помогая другим пользователям быстрее получить новую версию дистрибутива и не положить основной сайт под нагрузкой.
В случае классического понимания речь идёт о специально созданных и предназначенных только для решения подобных задач сетях. Часто проприетарных. Если вам нужен CDN общего назначения, то вы обращаетесь к кому-то из крупных вендоров, имеющих серверы по всему миру и достаточные каналы связи. Крупнейшие из них, такие, как Amazon и Google, тянут свои собственные кабели связи для обеспечения нужной пропускной способности и снижения задержек.
1. Выбираем ближайший узел
Для начала пользователю при DNS-запросе отдаётся адрес ближайшего к нему узла. Это нужно для того, чтобы ваш браузер не полез качать фотографию откуда-то из Ванкувера, когда ближайшая к вам копия файла есть в кэше на сервере в вашем городе. Обычно это делается с помощью GeoDNS, но иногда используется специально сконфигурированный Anycast. Например, всем известный 8.8.8.8 от Google будет вести на ближайший узел, который чаще всего расположен во внутренней сети вашего провайдера. Это возможно благодаря правильному анонсированию сетей, по которому роутеры провайдера выбирают наиболее короткий маршрут.
2. Кэшируем
Это ключевой момент в работе CDN. Кэширование очень важно для снижения трансграничного трафика, каналы для которого совсем не резиновые. Более того, очень важно, чтобы кэширование происходило строго в соответствии с географией пользователей. Например, локальный Google Global Cache не должен хранить YouTube-видео с рекламой российского сотового провайдера на серверах в Нью-Йорке. Маловероятно, что она будет кому-то там нужна. Аналогично нет смысла кэшировать рецепты приготовления лягушачьих лапок на французском языке где-то в Перми. Поэтому основной принцип довольно прост. Первый пользователь, который запросил контент, ждёт дольше всех, пока он не подтянется откуда-то из франкфуртского дата-центра. Зато все последующие обращения будут происходить с минимальными задержками и нагрузками на сеть провайдера.
Причём у крупных вендоров схема очень похожа на работу классического DNS. Мы вначале спрашиваем ближайший к нам узел, нет ли у него нужной картинки. Потом он идёт не к корневому узлу, а к географически ближайшим. И если он и там не сможет найти нужное, то только тогда пойдёт к первоисточнику на другом континенте. Таким образом, мы получаем максимально эффективное хранение тяжёлых файлов как можно ближе к локальным клиентам с учётом их потребностей.
3. Доставляем динамику
Динамический контент генерируется на стороне вашего origin-сервера. Например, создаётся страница с новостями, отсортированными под конкретного клиента. Кэшировать всё это очень сложно, так как контент, по сути, уникальный. В большинстве случаев динамическое содержимое вроде текста «В Лондоне +23 градуса» доставляется от origin-сервера, а статическое вроде картинки с Биг-Беном прилетает от CDN.
Чтобы ещё больше повысить скорость загрузки страницы, некоторые компании предлагают кэширование динамического контента за счёт переноса выполнения скриптов на сторону их инфраструктуры. Например, такой вариант предлагает сервис Cloudflare Workers. При этом код кэшируется и выполняется быстро и в географически нужных локациях. При этом тот же Cloudflare использует свою проприетарную технологию маршрутизации трафика Argo Smart Routing, что позволяет оптимизировать доставку запросов пользователей по наиболее быстрым маршрутам внутри своих сетей.
4. Реализуем OPES-протокол
OPES (Open Pluggable Edge Services) — это протокол, предназначенный для адаптации одного и того же контента под нужды конкретного клиента. Работает это примерно так.
В Сети есть куча клиентов, origin-сервер с исходным контентом, кэширующий сервер CDN и специальный callout-сервер, отвечающий за адаптацию контента:
5. Правильно отдаём картинки, Image CDN
CDN — это намного больше, чем просто тупой кэш для файлов. Хороший пример — правильная работа с изображениями. Обычный CDN общего назначения не обращает внимания на особенности клиента, который к нему обратился. Попросили отдать картинку — он её отдаст, неважно, запросил её Samsung Galaxy, iPad или PC с 8К-дисплеем. Правильный Image CDN отдаст картинку в нужном формате, сжав её под размеры дисплея клиента. Тем самым экономится большое количество трафика и ускоряется загрузка страниц на тех устройствах, которым не нужна графика в огромном разрешении.
6. Делаем ещё кучу нужных вещей
Помимо доставки контента, узлы CDN могут обеспечивать терминирование HTTPS-трафика, WAF (Web Application Firewall), защиту от DDoS и кучу других задач.
Что нужно для подключения к CDN?
Каждый проект уникален. Но в целом в минималистичном варианте задача сводится к нескольким этапам:
Управление кэшированием
CDN — это сложный интеллектуальный кэш. Кроме того, каждый браузер на стороне клиента также старается запрашивать только тот контент, который изменился, чтобы снизить нагрузку на интернет-канал.
Проблема любого кэша в том, что мало отрегулировать скорость его протухания. Нужно убедиться, что ни промежуточные узлы, ни браузер не додумаются закэшировать особо чувствительные данные. Например, реквизиты банковской карты. Замечали, что их каждый раз приходится вводить заново? Вот это оно и работает.
Для этого необходимо использовать специальные валидаторы в заголовках веб-страниц.
cache-control: private
Заголовок говорит о том, что контент может быть закэширован только конечным клиентом, но не промежуточным узлом, таким, как прокси или CDN.
cache-control: public
Контент может быть кэширован кем угодно.
cache-control: no-store
Контент не должен быть кэширован никем и никогда. Чаще всего используется для страниц с особо чувствительной информацией, например, форме ввода реквизитов банковской карты.
cache-control: no-cache
Контент не должен использоваться до тех пор, пока клиент не убедится, что он просматривает последнюю версию. Это реализуется за счёт хедера ETag, который представляет собой идентификатор, уникальный для конкретного ресурса. По сути, это хэш.
Клиент при запросе посмотрит, что у него лежит в кэше, и отдаст ETag в заголовке If-None-Match. Если ETag от клиента соответствует актуальной версии у сервера, то он ответит клиенту, что можно пользоваться кэшем. Иначе пришлёт новую версию.
cache-control: max-age
В этом заголовке указывается срок жизни ресурса в секундах с момента первого получения.
Помимо управления кэшированием через заголовки, владелец ресурса всегда может внести дополнительные изменения через панель управления или сбросить кэш, ткнув CDN через API.
Кому выгоден CDN
Практически всем. Клиент получает самые низкие пинги при обращении к ресурсу и отсутствие ожидания при массовой нагрузке на сервис, например, при выходе очередного дистрибутива ОС или игры.
Источник контента получает конкурентное преимущество. Современный веб приучил людей, что страница, которая не грузится больше нескольких секунд, скорее всего, сломана и можно просто перейти к следующей ссылке. Тот же Google заинтересован, чтобы его поиск работал как минимум не медленнее, чем у его конкурентов, а видео и реклама воспроизводились без задержек. Иначе клиентура быстро перебежит к кому-то ещё. По сути, монополия таких крупных гигантов во многом строится именно на очень широких каналах связи и множестве CDN по всему миру. Вы можете быть очень крутой компанией с точки зрения технологии, но вам не запустить второй YouTube без многомиллиардных вложений в дата-центры.
Ну и, наконец, провайдер. Он будет только рад максимально замкнуть трафик пользователей внутри своей сети и минимизировать свои затраты на пиринг с другими провайдерами на точках обмена трафиком. Это особенно актуально с учётом того, что видеоконтент сейчас является одним из основных потребителей мобильного и стационарного трафиков. Не зря тот же Netflix и другие компании согласились принудительно снизить качество своего видео с 4К до 1080p, чтобы разгрузить сети европейских провайдеров на время пандемии коронавируса. Множество людей ушло в вынужденный простой, перегрузив сети потоковым видео, не давая возможности нормально работать удалённо всем остальным.
Жутковатая олигополия
CDN — несомненно, очень крутая технология. Проблема в том, что она требует больших капитальных затрат и закладывает потенциальную мину под будущее Всемирной паутины. По сути, если вы достаточно крупная компания, то вам почти неизбежно надо идти к кому-то из небольшого списка компаний. Крупнейшие сети:
Или можно вспомнить массовое падение кучи сервисов в России во время блокировок IP-адресов Amazon по распоряжению Роскомнадзора (перебои в работе Viber, некоторых платёжных систем, сервисов регистрации на авиарейсы, системы продажи электронных полисов ОСАГО, сети научных контактов ResearchGate, центрального репозитория библиотек Java, сайтов СколТеха, МГУ, Высшей школы экономики и других вузов, научных архивов, системы подачи заявок в РФФИ и других).
Таким образом, теряется основное преимущество, сделавшее Интернет глобальным, — децентрализованность. Более того, есть ещё одна очень важная проблема. Зашифрованный мусор нельзя нормально кэшировать. Поэтому в большинстве реализаций вам придётся отдать CDN-провайдеру самое ценное — шифрование трафика между вами и клиентом. По сути, вы соглашаетесь на классический Man-in-the-middle с целью оптимизации доставки контента. Это создаёт дополнительные риски концентрации приватной информации пользователей в одних и тех же руках. Более подробно проблему олигополии мы раскрывали тут.
Можно ли обойтись без CDN?
Да, можно. Если ваша потенциальная аудитория находится в одном регионе и не будет страдать от большого пинга, то CDN вам не нужен. Что делать, если я хочу просто играть локально или обеспечить высокий пинг людям не в Москве?
Можно ограничиться локальным сервером. Собственно, у нас часто берут VDS в Екатеринбурге, Новосибирске, Казани и Петербурге как раз для игровых серверов либо для проектов для локальных офисов. А VDS во Франкфурте, Лондоне или Амстердаме нужны тем, кто использует тех же трейдинговых ботов или что-то парсит: там ближе к биржам и источникам данных.
Услуга игровых серверов локально для города настолько востребованная, что у нас уже есть возможность создавать тот же серверный клиент Майнкрафта сразу вместе с заказом нового сервера, уже предустановленный на свежую VPS-машину.
Если на вашем сервере Minecraft стоит лимит в 30 игроков, то вы получите вполне прогнозируемый трафик между вами и клиентами. Более того, статическими данными в данном случае будут разве что кастомные текстуры, наборы плагинов со стороны сервера или что-то подобное. Всё остальное будет обрабатываться на стороне клиента.
В зависимости от выбранного типа сервера вам потребуется развернуть на виртуальной машине либо полностью ванильную версию игры, либо, что более вероятно, использовать платформу, поддерживающую сторонние моды, например, Bukkit. На 30–50 игроков вам потребуется порядка 6 Гб оперативной памяти в зависимости от числа модов, которые вы навесите на свой сервер, и размеров карты. К CPU тоже предъявляются высокие требования. Из-за архитектуры игры вы сможете задействовать только одно ядро для вычислений, поэтому предпочтительнее высокая частота, нежели число ядер.
И самое интересное — сеть. В целом довольно скромного канала в 10–20 Мегабит/с будет вполне достаточно. Гораздо критичнее сразу предусмотреть размещение игровых серверов как можно ближе к игрокам. Поверьте, крипер, который вас убивает через секунду после того, как вы успешно от него убежали, или проваливание сквозь блок из-за большой задержки гарантированно вызовет много нецензурной лексики со стороны игроков. Поэтому близкие к вашей аудитории сервера с низкими пингами — вполне себе альтернатива CDN в некоторых случаях. У нас, например, есть свободные мощности в Новосибирске и Казани с хорошей сетевой связностью.
Итого
Вам, скорее всего, не нужен CDN, если:
На что обратить внимание при переходе на CDN: