Лучшие Сети доставки контента (CDN) — 2022, список программ

Лучшие Сети доставки контента (CDN) - 2022, список программ Хостинг

Так что внутри современной cdn?

CDN — это общее название множества различных технологий, призванных доставлять статический контент как можно ближе и быстрее по отношению к клиенту. Например,

новой версии Ubuntu — это тоже CDN. А вы становитесь одним из узлов раздачи, помогая другим пользователям быстрее получить новую версию дистрибутива и не положить основной сайт под нагрузкой.

В случае классического понимания речь идёт о специально созданных и предназначенных только для решения подобных задач сетях. Часто проприетарных. Если вам нужен CDN общего назначения, то вы обращаетесь к кому-то из крупных вендоров, имеющих серверы по всему миру и достаточные каналы связи.

Что нужно для подключения к cdn?

Каждый проект уникален. Но в целом в минималистичном варианте задача сводится к нескольким этапам:

Почему возникла необходимость в cdn

Представьте, что вы одновременно открыли два сайта по одной теме. Один загрузился быстро, а на другом изображения или другой контент ещё не загрузился. Каким сайтом вы предпочтёте пользоваться? Скорее всего, первым. А второй будет терять значительную часть новых посетителей и вызывать неудовольствие постоянных пользователей.

Для человека это не является проблемой, ведь он сможет найти информацию на другом сайта. А вот для владельца медленного веб-ресурса уход посетителей — это катастрофа. Теряются потенциальные клиенты, поисковики снижают рейтинг сайта, а рекламные бюджеты спускаются на ветер.

Поскольку сайты открываются одновременно, проблема явно не в скорости интернета, браузере или компьютере. Значит, что-то не так работает на сервере. Можно ли решить эту проблему и ускорить загрузку? Да, с помощью CDN. Объединённые в одну сеть сервера, расположенные по всему миру, позволяют быстро загружать контент на устройство пользователя вне зависимости от того, сколь велико расстояние от источника до устройства конечного пользователя.

Почему не взлетел чистый multicast?

imageСхема работы multicast.

Мультикаст очень хорош. В отличие от юникаста он позволяет исходному серверу бросить в сторону клиентов только один пакет, который будет ретранслирован строго тем, кто его ожидает. В отличие от броадкаста не будет слать пакеты всем кому надо и не надо, засоряя Сеть мусором.

Начиная с каких объёмов имеет смысл думать о cdn?


Повторим мысль: если нужно быстро обслужить клиентов, то объём трафика уже не важен — важны точки присутствия поближе к целевой аудитории.

Если же значительной потребности в низкой latency нет, а CDN используется для облегчения нагрузки на сервера, то осмысленный объём трафика, с которым стоит начинать думать о CDN — это несколько терабайт в месяц.

Выбираем ближайший узел

Для начала пользователю при DNS-запросе отдаётся адрес ближайшего к нему узла. Это нужно для того, чтобы ваш браузер не полез качать фотографию откуда-то из Ванкувера, когда ближайшая к вам копия файла есть в кэше на сервере в вашем городе. Обычно это делается с помощью

, но иногда используется специально сконфигурированный Anycast. Например, всем известный 8.8.8.8 от Google будет вести на ближайший узел, который чаще всего расположен во внутренней сети вашего провайдера. Это возможно благодаря правильному анонсированию сетей, по которому роутеры провайдера выбирают наиболее короткий маршрут.

Доставляем динамику

Динамический контент генерируется на стороне вашего origin-сервера. Например, создаётся страница с новостями, отсортированными под конкретного клиента. Кэшировать всё это очень сложно, так как контент, по сути, уникальный. В большинстве случаев динамическое содержимое вроде текста «В Лондоне 23 градуса» доставляется от origin-сервера, а статическое вроде картинки с Биг-Беном прилетает от CDN.

Чтобы ещё больше повысить скорость загрузки страницы, некоторые компании предлагают кэширование динамического контента за счёт переноса выполнения скриптов на сторону их инфраструктуры. Например, такой вариант предлагает сервис Cloudflare Workers.

При этом код кэшируется и выполняется быстро и в географически нужных локациях. При этом тот же Cloudflare использует свою проприетарную технологию маршрутизации трафика Argo Smart Routing, что позволяет оптимизировать доставку запросов пользователей по наиболее быстрым маршрутам внутри своих сетей.

Реализуем OPES-протокол


OPES (

) — это протокол, предназначенный для адаптации одного и того же контента под нужды конкретного клиента. Работает это примерно так.

В Сети есть куча клиентов, origin-сервер с исходным контентом, кэширующий сервер CDN и специальный callout-сервер, отвечающий за адаптацию контента:

  1. Клиент с PC запрашивает контент у CDN.
  2. CDN забирает его у origin-сервера, кэширует и отдаёт клиенту.
  3. Клиент с мобильного телефона запрашивает тот же ресурс у CDN.
  4. CDN не беспокоит origin-сервер, отправляет на переработку свой кэш в сторону callout-сервера.
  5. Callout-сервер адаптирует контент под мобильного клиента и отдаёт его CDN.
  6. CDN кэширует новый вариант ресурса и отдаёт его мобильному клиенту.

Правильно отдаём картинки, Image CDN

CDN — это намного больше, чем просто тупой кэш для файлов. Хороший пример — правильная работа с изображениями. Обычный CDN общего назначения не обращает внимания на особенности клиента, который к нему обратился. Попросили отдать картинку — он её отдаст, неважно, запросил её Samsung Galaxy, iPad или PC с 8К-дисплеем.

Cache-control: max-age


В этом заголовке указывается срок жизни ресурса в секундах с момента первого получения.

Помимо управления кэшированием через заголовки, владелец ресурса всегда может внести дополнительные изменения через панель управления или сбросить кэш, ткнув CDN через API.

Cache-control: no-cache

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

Клиент при запросе посмотрит, что у него лежит в кэше, и отдаст ETag в заголовке If-None-Match. Если ETag от клиента соответствует актуальной версии у сервера, то он ответит клиенту, что можно пользоваться кэшем. Иначе пришлёт новую версию.

Cache-control: no-store

Контент не должен быть кэширован никем и никогда. Чаще всего используется для страниц с особо чувствительной информацией, например, форме ввода реквизитов банковской карты.

Cache-control: private

Заголовок говорит о том, что контент может быть закэширован только конечным клиентом, но не промежуточным узлом, таким, как прокси или CDN.

Cache-control: public

Контент может быть кэширован кем угодно.

Главный вопрос: сколько это стоит?

Цена сильно варьируется от специфики CDN, степени “крутости” поставщика и адаптации CDN под конкретные специальные потребности. Диапазон цен на рынке — от $1 до $140/мегабит полосы, или $0.03-$0.3 за ГБ трафика. Фактическая цена очень часто зависит от добавленных услуг и возможностей CDN.

Жутковатая олигополия

CDN — несомненно, очень крутая технология. Проблема в том, что она требует больших капитальных затрат и закладывает потенциальную мину под будущее Всемирной паутины. По сути, если вы достаточно крупная компания, то вам почти неизбежно надо идти к кому-то из небольшого списка компаний. Крупнейшие сети:

  1. Cloudflare.
  2. Azure CDN.
  3. Amazon CloudFront.
  4. Akamai Technologies.
  5. Google Cloud CDN.

В результате в случае программной ошибки на любом из них у вас попросту отвалится множество сервисов, которые хостятся на их мощностях, например,

в 2022 году. Они тогда залили кривое правило на Cloudflare Web Application Firewall и распространили его глобально. В итоге они получили стопроцентную нагрузку на свои ноды по CPU. Клиенты по всему миру на сотнях ресурсов в это время массово получали 502 ошибки (Bad Gateway). Из крупных ресурсов пострадали Discord, Reddit, Twitch и другие.

Или можно вспомнить массовое падение кучи сервисов в России во время блокировок IP-адресов Amazon по распоряжению Роскомнадзора (перебои в работе Viber, некоторых платёжных систем, сервисов регистрации на авиарейсы, системы продажи электронных полисов ОСАГО, сети научных контактов ResearchGate, центрального репозитория библиотек Java, сайтов СколТеха, МГУ, Высшей школы экономики и других вузов, научных архивов, системы подачи заявок в РФФИ и других).

Таким образом, теряется основное преимущество, сделавшее Интернет глобальным, — децентрализованность. Более того, есть ещё одна очень важная проблема. Зашифрованный мусор нельзя нормально кэшировать. Поэтому в большинстве реализаций вам придётся отдать CDN-провайдеру самое ценное — шифрование трафика между вами и клиентом.

По сути, вы соглашаетесь на классический Man-in-the-middle с целью оптимизации доставки контента. Это создаёт дополнительные риски концентрации приватной информации пользователей в одних и тех же руках. Более подробно проблему олигополии мы раскрывали тут.

Кому выгоден cdn


Практически всем. Клиент получает самые низкие пинги при обращении к ресурсу и отсутствие ожидания при массовой нагрузке на сервис, например, при выходе очередного дистрибутива ОС или игры.

Кому нужен cdn

Технология необходима большим проектам, чья аудитория находится в разных городах и странах. Например, это может быть девелоперский сайт, сайт объявлений и т. д. Как правило, CDN используют:

  • Интернет-магазины, посетители которых могут находится на всей территории страны или мира. 
  • Стриминговые сервисы (Netflix,Spotify). 
  • Игровые порталы, предлагающих услугу облачного гейминга. 
  • Дистрибьюторы ПО. 
  • Проекты, для работы мобильных приложений которых необходима высокая скорость загрузки данных.

Кому нужен cdn?

Тем, кому важно отдать статику быстро множеству посетителей, которые находятся далеко от серверов компании (ситуация ещё острее для компаний, у которых посетители раскиданы по большой территории, то есть даже перенос серверов “поближе” смысла не имеет — всё равно большинство окажется “далеко”).

Тем, у кого очень большой объём файлов — и стоимость трафика CDN оказывается ниже стоимости трафика, уходящего к аплинкам (у крупных сайтов обычно трафик стоит разных денег — локальный дешевле, “глобальный” дороже).

При определённой полосе, вынос статики на CDN оказывается выгоднее, чем апгрейд сетевого оборудования. Обычно статика занимает значительную часть полосы, и вместо апгрейда с 1G до 10G, или с 10G до 40G, куда дешевле выкинуть 80% трафика на CDN и оставаться на разумных по цене серверах.

Краткий обзор рынка

Все компании делятся на две категории — работающие по существующим публичным тарифам и работающие на основании договорённостей. Вторые компании крайне сложно сравнивать, так как условия в них могут сильно различаться. Однако, “приватный” не означает “маленький” — у приватных компаний чаще всего очень крупные клиенты с огромными объёмами в сотни терабит (полосы), а на “мелюзгу” с десятком гигабит они не заморачиваются.

Вот список популярных CDN (чтобы никого не обижать, список отсортирован в случайном порядке):

Публичные CDN:

  • NetDNA, 2009, минимальный контракт 1 год, цены от ¢1 до ¢6 за Гб в зависимости от объёма, трафик за пределами EU/US в полтора раза дороже, хранение бесплатно
  • Rackspace Cloud Files — ¢4-¢12 за Гб полосы, ¢10 за Гб хранения (реселлит Акамай)
  • MaxCDN от ¢3 до ¢8 за Гб трафика
  • Amazon CloudFront — EU/US — от ¢6 до ¢12 за Гб, хранение бесплатно.
  • CacheFly — ¢20-¢30, минимальный контракт $99/месяц, превышение места оплачивается ($15/Гб)
  • CDN77 — ¢3-¢15/Гб
  • CloudFlare — трафик не оплачивается, различный уровень сервиса стоит различных денег, начиная от базового бесплатного, следующего за ним в $5/месяц, до $200/месяц на лучшем.
  • BitGravity — от ¢7 до ¢20 за Гб, в зависимости от объёма и региона
  • Level 3 — от $100 в месяц, ¢10-¢25 за Гб
  • Leaseweb — от ¢6 до ¢8 за Гб, с минимальной стоимостью от $60/месяц
  • Windows Azure CDN от ¢3 до ¢20
  • CDNsun — от ¢3 до ¢5 за Гб


Приватные CDN:

Дополнительная информация

Статья написана при поддержке наших коллег из компании UCDN, которые слишком скромны, чтобы включать себя в список выше.

Магазины

Остались бы исключительно в формате странички локального мясного магазина с картой проезда и телефоном. А ещё придётся вспомнить старые добрые бумажные распечатки прайсов в магазинах компьютерных комплектующих. Amazon и Aliexpress просто не смогли бы существовать.

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

Просто они шли бы медленнее. В случае отказоустойчивости в виде двух площадок часть проблем резервирования решилась бы, но каждый запрос пользователя ходил бы через всю страну именно до них без локального кэша. А если уж делать локальный кэш, то почему сразу же не сделать там же на узле и серверные приложения?

Мессенджеры

Выживут, но без всяких модных стикеров, трансляции геопозиции и прочих радостей. А ещё вы, скорее всего, можете забыть про пуши со стороны Google Services. То есть в Сети вы будете только тогда, когда запущено приложение, что означает непрерывное потребление батарейки.

Мир без cdn

Итак, мы определились с тем, что нам потребуется очень много ресурсов для того, чтобы обслуживать всех посетителей из единой точки. Давайте попробуем представить, как выглядел бы современный веб без CDN. Каждая компания строит себе один огромный дата-центр и собирает все ресурсы в одной-единственной точке мира.

image
Централизованная раздача контента и распределённая схема через CDN.

Небольшие веб-ресурсы

Почти не пострадают. Даже сейчас есть множество местечковых форумов, посвящённых узкой тематике разведения, ну, например, алтайских перепелов. Там почти никогда не бывает огромного наплыва посетителей, почти нет тяжёлого контента. Они как жили в начале нулевых, так и продолжают в 2020 году, принося ценность своему небольшому сообществу.

Немного истории

Резкий рост Интернета в середине 90-х привёл к ситуации, что сервера тех лет не могли в одиночку выдержать нагрузку (много ли может отдать могучий двухпроцессорный сервер на базе Pentium Pro на частоте в 266 МГц с 128 мегабайтами памяти?). Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом.

Динамический контент формируется сервером в момент получения запроса сервером, чаще всего при активном участии базы данных. Если на странице снизу надпись “page was generated in 0.333 seconds” — это как раз пример динамического контента.

Статический контент на сервере находится в готовом виде — кто бы не прислал запрос, сервер будет отдавать одно и то же (с поправкой на возможные ACL). Важно, что содержимое при этом не меняется от запроса к запросу.Статический и динамический контенты создают разный тип нагрузки на сервер.

Когда раздаётся “динамика”, то важны процессор, IO (для базы данных) и сколько-то памяти. Когда раздаётся статика, процессор почти не важен, IO важно только для тех файлов, которые не кешированы, а основное требование — это скорость сети. Заставлять раздавать статику серверами, которые раздают динамику, можно, но это совмещение ролей, которое мешает друг другу.

Ещё более важной деталью является то, что “динамический” обычно означает наличие “состояния” (сессии и связанных с ним данных), а статика — нет. Статику можно масштабировать горизонтально без сложных двухсторонних синхронизаций с центральным сервером. В случае с динамикой так не получится — нужна либо общая база данных, либо методы синхронизации и блокировок.

Средние и крупные компании начали раздавать статику и динамику с разных серверов, расположенных в разных местах планеты, уменьшая нагрузку на сайты с динамикой за счёт выноса с них статики на легко масштабируемые сервера. После чего сделать шаг до “аутсорса” раздачи статики было просто, и начали появляться компании, которые сделали раздачу статики основой (или хотя бы крупной составляющей) своего бизнеса.

О главном

Заметим, что CDN решает ещё более важную проблему, чем облегчение жизни серверам приложений.

Все современные CDN размещают копии контента на разных серверах по всему миру и направляют клиента на ближайший (к клиенту) сервер. Результат — сокращение latency, то есть задержки между запросом и ответом. Если на странице много изображений (пусть даже мелких картинок), то чем быстрее они окажутся у клиента, тем быстрее клиент увидит страницу.

И если мы уберём из рассмотрения страдальцев на dialup/gprs, то время, за которое будет показана страница определяется практически только сетевой задержкой. Если мы говорим про расстояния в сотни километров (~10мс задержка), это не существенно. Но если речь про расстояния в континенты — то тут задержка в сотни миллисекунд (до 500-600!) начинает уже играть радикальную роль.

А если же контент отдаётся с сервера, который в нескольких километрах от пользователя, то случается чудо! Австралия видит данные с сайта из США в единицы милисекунд, Китай из сайта из России, Франция с сайта из Бразилии. Без участия океанических кабелей.

Работает это и на меньшем масштабе: Например, Яндекс при помощи CDN в свое время знатно ускорил работу почты в регионах России, которым до Москвы по оптике топать и топать.

Ускорение доставки контента стало главной киллер-фичей CDN, а всё остальное (снижение нагрузки, её балансировка и т.д.) — стало второстепенным. Важным, но не критическим. В конце-концов, любую нагрузку можно завалить деньгами. Но никакими деньгами нельзя сделать так, чтобы без локальных точек присутствия сигнал из Перми доходил до Сан-Франциско за десятки миллисекунд.

При том, что экономия не является киллер-фичей, она тоже важна. CDN в некоторых ситуациях позволяет ощутимо экономить на трафике. Передать на другой континент файлы один раз, держать их там на локальном сервере и раздать через локальные линки дешевле, чем гонять тот же трафик десять тысяч раз через транс-атлантику. Чаще всего об экономии начинают думать в тот момент, когда это становится критичным (видеохостинги в первую очередь).

Однако, сервера по всему миру, система синхронизации контента и направления клиентов к ближайшим серверам и т.д. — всё это не бесплатно. Чаще всего CDN просят дополнительные деньги по сравнению с обычным трафиком аплинков, хотя для некоторых регионов может оказаться, что трафик CDN выгоднее, чем трафик аплинка (но это, скорее, говорит о том, что интернет в регионе не ахти).

Отдалённые регионы

Если вы живёте в отдалённых регионах, куда не ведут широкие кабельные магистрали, то вам было бы совсем грустно. В начале нулевых вполне типичной была ситуация, когда жители Сахалина могли по пять минут ждать загрузки обычной веб-страницы. С современным вебом всё было бы ещё хуже: много ресурсов просто было бы сброшено по тайм-ауту, не загрузившись.

Преимущества cdn

  • Увеличение скорости загрузки. Сеть доставки контента укорачивает до минимума сетевой маршрут между источником контента и пользователем. Благодаря этой технологии время отклика сервера-источника редко превышает 10 мс. Контент одинаково быстро открывается везде.
  • Уменьшение нагрузки на сервер-источник. Благодаря сети доставки контента пользовательская нагрузка «размазывается» между всеми серверами, состоящими в сети. Источник же задействуется только для раздачи в сеть обновлённых данных и настроек. Если на нём нет динамического контента, а обновления выходят редко, то стоимость хостинга будет невелика, а требования к производительности — минимальны.
  • Повышение доступности сайта. CDN-сервера резервируют друг друга. Если один из них засбоит, трафик пойдёт через другие. Отказоустойчивость обеспечивается даже при DDoS-атаках, так как стоимость такой атаки на приложение или сайт с работающим CDN очень высока.
  • Возможность размещения «тяжёлого» контента. Если на сайте находится ресурсоёмкое ПО или интерактивные медиафайлы, сервер-источник может быть перегружен «тяжелыми» запросами, обработка которых занимает минуты, а порой и часы. Благодаря CDN становится возможным одновременное обслуживание нужного количества «медленных» запросов.
  • Улучшение SEO-параметров. Сайт грузится быстрее и пользователи чаще остаются на нём. Количество отказов уменьшается, в результате чего поисковые системы присваивают ресурсу более высокий приоритет в выдаче.

Проблема долгого пинга

Вторая проблема, которую решает CDN, — это ускорение запросов. Около вас есть локальный сервер, который кэширует статический контент и иногда сам умеет выдавать динамический. Если вам знакомы тормоза 1С при забегах из Владивостока в Москву или особенности работы с SAP через какой-нибудь корпоративный VPN в Европе из Новосибирска, то вы понимаете всю глубину боли.

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

Проблема ширины канала

У вас есть много иллюстраций и видео, которые надо доставить клиенту. Передать однократно несколько Мегабайт не очень трудно: современные каналы связи позволяют делать это за секунды. Всё становится гораздо хуже, когда к вам на сайт одновременно заходят вначале несколько десятков, а потом — тысяч посетителей.

Давайте считать. Допустим, у вас один-единственный сервер и у вас типичная страница весом в 1,8 Мегабайта. Клиенты приходят к вам впервые и с «холодным» кэшем, то есть в браузере нет ранее загруженных материалов с вашего ресурса.

Чтобы отдать за приемлемые три секунды страницу, нам потребуется ширина канала в 4,8 Мегабита на одного посетителя. Если их придет 100, то это уже 480 Мегабит. А если вдруг потребуется отдать тем же людям небольшой видеофайл размером 10 Мегабайт, то нам потребуется канал в 2,7 Гигабита.

Таким образом, у вас появляется два основных типа контента: динамический и статический. Статический контент, как следует из названия, не изменяется или меняется крайне редко. Например, это логотип веб-сайта. Или залитые образы с дистрибутивами ПО.

Динамический контент отличается тем, что он генерируется сервером «на лету». Обычно это происходит в момент самого запроса. Например, при клике на кнопку формируется плей-лист, уникальный для конкретного пользователя.

Именно для решения проблемы кэширования статического контента и были созданы CDN. Но, как мы увидим дальше, и с динамическим контентом CDN тоже могут помочь.

Различия


Если с CDN всё понятно, то как насчёт их поставщиков? Компаний много, они различаются ценой, услугами и качеством.

Вот основные факторы, которые надо определить для себя при выборе поставщика:

1. Количество точек присутствия (Point of Presence)Чем больше точек, тем лучше, однако… Oднако, зачем вам точки присутствия в Китае, если сайт русскоязычный? А количество точек присутствия в Австралии при выходе на американский рынок… При сравнении CDN следует учитывать число точек присутствия в интересующих странах и регионах.

Сами точки присутствия так же не равнозначны — связность и пиринговые соглашения с локальными провайдерами очень важны. К сожалению, “иногородцу” оценить связность довольно сложно (нужно понимать расстановку сил на локальном провайдерском рынке), но, сравнивая предложения стоит уточнить о списке пиров каждого из кандидатов в самых важных точках присутствия.

2. Политика кешированияДля того, чтобы быстро отдавать контент с локального сервера, надо, чтобы контент на локальном сервере появился (и оставался). Схем кеширования множество, вот самые очевидные:

Рядом с политикой кеширования идёт политика устаревания (retention policy): когда именно объект удаляется с сервера в точке присутствия? По таймауту, по снижению числа обращений ниже некоторой величины, “никогда”, через фиксированное время? И кто оплачивает хранение копии?

3. SLAДа, да, легендарный и необъятный Service Level Agreement. Перед тем, как радоваться длинной чреде девяток, уточните — это SLA для CDN “вообще” или для всех точек присутствия? Если в самой важной для вас локации ломается сервер и контент отдают “из соседней страны” это будет засчитываться за даунтайм по SLA?

Кстати, хоть продающий менеджер и будет сопротивляться, будет здорово, если вам покажут статистику отказов за предшествующее время. Отказы будут, и они бывают у всех (подсказка: если вам рассказывают про то, что у кого-то никогда не было аварий — либо это очень молодые, либо очень наглые) — весь вопрос в их длительности и частоте.

4. Value added servicesCDN может предоставлять дополнительные услуги. Пример (список неполный):

Очень важно обратить внимание на поддержку нужны протоколов и файлов. Узнайте, поддерживает ли выбранный вами провайдер потоковое воспроизведение флеш- и медиафайлов (RTMP, RTSP), если вы планируете доставлять именно такой контент.

Возможно, провайдер очень хорош во всем остальном, но, если он не поддерживает нужные вам технологии, вам это вряд ли понравится.

5. Технические нюансыТехнология переадресации: Это либо эникаст на уровне DNS, либо переадресация через редиректы. Эникаст, по понятным причинам, работает быстрее.

Аккуратность переадресации: К сожалению, этот показатель сам поставщик объективно оценить не сможет, хотя как раз этот показатель очень важен — какая часть целевой аудитории попадает на ближайший сервер. Часто говорят про ожидаемую задержку (так как фактическое расстояние никого не волнует, а всех волнует время прохождения пакетов — например, бывает так, что стык между двумя сетями перегружен и пакеты ходят медленно, в этой ситуации лучше сходить чуть дальше, но быстрее).

6. АккаунтингКак именно поставщик берёт деньги? За мегабайты или за мегабиты в секунду? Есть ли минимальный коммит (“если раздалось меньше предусмотренного договором доплатить до минимума”), что происходит при оверкоммите (превышении лимита) — отключают/берут больше денег?

Управление кэшированием


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

Проблема любого кэша в том, что мало отрегулировать скорость его протухания. Нужно убедиться, что ни промежуточные узлы, ни браузер не додумаются закэшировать особо чувствительные данные. Например, реквизиты банковской карты. Замечали, что их каждый раз приходится вводить заново? Вот это оно и работает.

Для этого необходимо использовать специальные валидаторы в заголовках веб-страниц.

Чек-лист по выбору провайдера cdn


Узнайте количество точек присутствия (мест расположения кэширующих серверов), размер зоны покрытия. Чем больше мест присутствия, чем шире зона покрытия — тем лучше.

Узнайте, как организовано взаимодействие с провайдерами связи. Наличие точек присутствия в большом количестве городов не всегда гарантирует высокую скорость загрузки. На это влияет и количество стыков с провайдером связи. У CDN-провайдера могут быть точки присутствия в 15 огородах, но благодаря большому количеству стыков с провайдером связи он сможет обеспечивать более высокую скорость загрузки по сравнению с другим провайдером, у которого точек присутствия больше, а стыков — меньше.

Оцените панель управления, её функционал. Наличие удобной панели управления, хороший набор инструментов — важный маркер качества предлагаемого сервиса. Гибкость и настраиваемость означают, что специалисты CDN-провайдера развивают сервис, улучшают его.

Итого

Вам, скорее всего, не нужен CDN, если:

Оцените статью
Хостинги