Цифры и факты (вместо введения)


  • В 2010 году средний размер веб-страницы составлял 481 кБ. В 2019 — уже 1936.7 кБ (подробная статистика). За последние три года значение этого показателя выросло на 314.7%. Как показывают исследования, тенденция к увеличению размера веб-страниц сохраняется.
  • В настоящее время набирают популярность стриминговые аудио- и видеосервисы. По состоянию на апрель 2019 года число подписчиков популярного сервиса Spotify составило 217 миллионов.
  • По данным опросов 25% пользователей уходят с веб-страницы, если она загружается дольше 4 секунд. 74% пользователей, загружающих сайт с мобильного устройства, предпочитают не ждать, если загрузка длится более 5 секунд. 46% пользователей отказываются иметь дело с веб-сервисом, если он медленно работает.


О чём свидетельствуют вышеприведенные факты?

О том, что в Интернете с каждым годом становится все больше «тяжелого» контента.
А также о том, что в современном мире огромную роль играет скорость работы веб-сайтов и сервисов. Если скорость слишком мала ? это чревато потерей аудитории, а во многих случаях ? ещё и прибыли. Один из надёжных способов решения этой проблемы ? использование сетей доставки контента (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 и другие).

Комментарии (10)


  1. Mako_357
    19.08.2019 13:55

    Есть статистика сколько сейчас в среднем страницы потребляют цпу и озу на устройствах пользователей?


  1. questor
    19.08.2019 14:05

    Во всех этих CDN бесит то, что приходится в NoScript постоянно указывать очередной поддомен, которые постоянно меняются.


    1. fortyseven
      20.08.2019 10:39

      Почему постоянно меняется? Вы сами делаете поддомен для вашего CDN-ресурса и он остается неизменным.


  1. ntfs1984
    19.08.2019 18:27
    -1

    Статью писал человек, который никогда не пробовал с этим работать?

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


    Не понятная мне эта цифра «гораздо». Где тесты, сравнения?

    Судя по моим личным тестам, передача в Николаев статического CSS размером в 20Кб из Киева занимает 42ms, из Лос-Анжелеса — 45ms.

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


    Не снижает. Основную нагрузку дает связка «веб-сервер->php->mysql<-php<-веб-сервер». Они и формируют так называемый TTFB, и именно это называется «ожиданием» и именно поэтому злятся посетители.

    Берем тестовый сайт на Вордпрессе, о котором никто кроме нас не знает. Открываем его в Хроме с панелью разработчика. Смотрим на тайминги.

    image

    Инициализация подключения — 80 мс
    SSL. Рукопожатия и прочая ерунда — 40 мс
    TTFB (пока Wordpress читает свои wp_options на каждый чих) — 45 мс
    А вот передача контента мне в браузер — 5 мс.

    Поставив CDN, мы ускорим только передачу контента. Будет не 5 мс, а 2 мс, что разумеется будет тут же заметно на фоне всего остального, да.

    Для работы через CDN создать домен вида cdn.example.com.

    То что ваш сайт использует этот cdn.example.com, браузер узнает тогда, когда получит страницу с example.com.

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


    Только вот проблема этой скорости — не в скорости отдачи контента origin-сервером. Если автор хочет в этом убедиться — может написать средний сайт на том же Wordpress, накидать туда столько мути, чтобы его мобильник открывал его скажем за 5 секунд по таймеру на часах на руке, а потом разместить этот сайт у себя в локальной сетке, и открыть его же с этого же мобильного. Разницы в скорости не будет, потому что бутылочное горлышко совсем в другом месте.


    1. Sarymian
      20.08.2019 03:43

      Почему Вы считаете, что «нагрузкой» может быть только CPU или RAM. Разве NET безлимитный и каждый хостинг на каждый сервер заводит сотни и тысячи гигабитов (да я знаю, что это не реализуемо, я спец. преувеличиваю). И тогда надо смотреть не со стороны 1 пользователя сайта на WP «о котором ни кто не знает» (и видимо ни кто не пользуется как следствие), а в первую очередь со стороны сервера. Потом со стороны пользователя. Потом со стороны перспективы (какая сейчас посещаемость? растет ли она? как быстро растёт? как скоро ресурсов текущего сервера станет не хватать? Какого ресурса будет не хватать? Можно ли увеличить ресурс и сколько это будет стоит?). И только рассмотрев вопрос со всех сторон и поняв, что через 2-3 месяца посещаемость вырастет на столько, что кеш NGINX'а (пусть и очень отличный кеш) начнёт не справляться с отдачей статики так как упрётся в пропускную способность канала. Тут сравниваем, сколько будет стоит арендовать ещё один сервер (пусть даже слабее) для раздачи статики и стоимость использования CDN — и делаем выводы.

      Делаем или первое или второе — снижаем нагрузку на канал, а так же чутка на CPU (NGINX же должен принимать решение, что отдавать из кеша). И живём дальше пока не упрёмся в ресурсы опять.

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


    1. alkonae
      20.08.2019 10:26
      +1

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


    1. Jokerzp
      20.08.2019 10:26
      +2

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


      Берем тестовый сайт на Вордпрессе, о котором никто кроме нас не знает.

      А теперь берем проект, на котором чуть больше, чем 1 пользователь. И каждая загрузка страницы влечет за собой с десяток обращений веб-сервера к файловой системе (без учета браузерного кеша). Когда таких запросов становится 100/1000/10000rps, то не так уже и весело тратить на ресурсы сервера на отдачу статического контента.


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


  1. Nexus7
    20.08.2019 14:13

    На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли дожидаться полной загрузки простой веб-страницы полновесные 5, а то и все 10, минут.

    У вас это личный опыт или фантазии на тему? Может быть дело было в плохой древней АТС и модеме на 14400? Или тощих магистральных каналах через спутник, потому что кабелей ещё не завезли? По моему опыту в конце 90-х американские сайты вполне себе быстро загружались на европейской части этой страны и на тощем модемном соединении.

    IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.
    При передаче больших файлов задержка передачи IP-пакетов HTTP-запроса практически исчезает на фоне времени передачи всего файла, которая напрямую коррелирует только с быстродействием файловой системы сервера и толщиной самого узкого канала на пути к клиенту. При больших нагрузках на промежуточные маршрутизаторы и каналы пакеты могут отбрасываться (сейчас можно считать, что у нас практически идеальные каналы и в них нет ошибок передачи) и тогда добавится время на TCP-таймауты и перепосылку IP-пакетов.

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


    1. edo1h
      21.08.2019 19:49

      IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.

      не могу с вам согласиться.
      смотрю в гугле расстояние до NY, делю на скорость света в оптоволокне, умножаю на два — получаю идеальный RTT 80мс. пингую — получаю 120мс.
      до москвы получаю идеальный RTT 7мс, реальный — 13мс.
      нужно учесть, что реальная длина оптоволокна заметно больше, чем расстояние от точки до точки по прямой, так что «уменьшение временных задержек из-за конечной скорости света в оптоволокне» имеет огромный смысл.

      P.S. только проблема в том, что «географически близко» ещё не гарантирует малых задержек. постоянно наблюдаю, как трафик между провайдерами в нашем городе бегает через Москву, а раньше, помнится, зачастую и через европу бегал.


      1. Nexus7
        21.08.2019 21:30

        По большей части всё так и есть, но если прикинуть (грубо округляя) время передачи файла в 1 Мбайт на скорости в 100 Мбит/с будет того же порядка, что и задержка передачи первого бита этого файла через Атлантику ~ 80 мс. Здесь есть табличка с задержками в трансатлантических кабелях. Ещё раз повторю свою мысль: приближение контента не так сильно влияет на скорость его получения клиентом, как снятие нагрузки с основного сервера сайта и распределение этой нагрузки на несколько серверов CDN.

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

        PS. Работу сайтов осложняет в основном слабо технически обученные генераторы контента, которые вместо 50 кБайт картинки заливают её оригинал на пару-тройку метров ;) Если я глазами вижу, как картинка загружается, то это именно такой клинический случай. Из-за больших дисков и толстых каналов многим стало наплевать, что у них на сайте за контент и какого он там размера. Ну а мода на длинные бэкграунды да с видео помогает CDN-провайдерам успешно зарабатывать.