Yandex cdn что это
CDN для статики и измерения: как Яндекс.Почта стала быстрее в регионах
Скорость работы веб-интерфейса — очень важная вещь, и мы в Яндексе особенно хорошо понимаем это. От ощущения лёгкости и того, с какой скоростью у пользователя загрузятся важные ему элементы, может зависеть и то, каким сервисом он в итоге будет пользоваться.
Мы в Яндекс.Почте много работаем над ускорением клиентской части. Только на Хабре мы рассказывали о том, как оптимизируем верстку, отказались от XSL и перешли на новый шаблонизатор.
Но добиться увеличения скорости работы можно не только за счет оптимизации фронтенда. Сегодня мы хотим рассказать о переезде статических файлов Яндекс.Почты на специальный CDN Яндекса для статики и о том, как это ускорило её работу, особенно в регионах.
Подробности о том, куда переехали, как устроен новый хостинг, почему он устроен именно так, и как мы измеряли, насколько стало быстрее, — читайте дальше.
Что тормозит загрузку?
Когда человек заходит в почту, первое, что у него загружается, — минимальный HTML и так называемый bootstrap (загрузчик). Он отвечает за асинхронную загрузку всех необходимых JavaScript-модулей, шаблонов и CSS-файлов для отрисовки интерфейса, а также за первоначальную подгрузку данных. В Яндекс.Почте HTML загружается с нашего основного домена mail.yandex.ru, а bootstrap — со статического кластера mailstatic.yandex.net.
В него входит около сотни машин, расположенных в нескольких датацентрах Москвы и Подмосковья. Единственная задача этого кластера — отдавать клиенту статические файлы, которые нужны для отображения и работы веб-интерфейса Почты.
Чтобы увидеть проблему скорости в полный рост, нужно задуматься о географии пользователей Яндекс.Почты. Даже если говорить только о России, самой большой стране в мире. Например, если ориентироваться на протяжённость Транссибирской магистрали, расстояние между Москвой и Владивостоком — почти 9300 км. Пакеты с данными пользователей, разумеется, не двигаются по железной дороге — они путешествуют по линиям связи. А скорость передачи данных в оптоволокне примерно в полтора раза ниже скорости света в вакууме. Свою долю задержек вносит и сетевое оборудование на пути следования данных. Таким образом, RTT от наших датацентров в Москве до Владивостока составляет 120-130ms, а, например, до Новосибирска — около 60ms.
Локальные сервера
Для решения проблем со скоростью у Яндекса есть CDN-хостинг — yandex.st. Yandex.st — это несколько кластеров машин, большая часть из которых, как и mailstatic.yandex.net, расположена в московских датацентрах. Но, в отличие от mailstatic.yandex.net, у него есть представительства во многих крупных городах России, ближнего зарубежья и мира.
На данный момент наш CDN-хостинг поддерживает более трехсот провайдеров в 11 регионах. Кстати, yandex.st третий в мире по популярности хостинг библиотеки jquery.
Он работает на технологии anycast. Это значит, что пользователю на запрос файла отвечает топологически ближайший к нему сервер. То есть, если человек находится во Владивостоке, его запрос будет направлен на сервер, расположенный во Владивостоке, а значит он получит ответ быстрее, чем если бы его запрос пошёл в Москву.
Переезд Яндекс.Почты на yandex.st
Прежде чем переехать, нужно было оценить то, насколько эффективен будет переезд и какую пользу он принесёт. Для этого мы обвесили веб-интерфейс Почты датчиками, построили графики и перевезли на yandex.st только 50% пользователей. Это было сделано для того, чтобы можно было сравнить всё с эталоном — mailstatic.
В клиентскую часть веб-интерфейса мы встроили специальный таймер скорости загрузки статики. В этом нам помог Navigation Timing API, которое есть в большинстве современных браузеров. API с точностью до миллисекунд знает, в какой момент пользователь начинает открывать почту, а javascript-платформа — в какой момент загрузились все необходимые статические файлы. Если мы вычтем из второго таймстемпа первый, можем получить время, за которое загружалась вся статика. Полученное число вместе с другими метриками отправляется GET-запросом от пользователя на специальные сервера.
В отличие от таймингов access-логов nginx (для которых, разумеется, у нас тоже есть графики), такая метрика позволяет учитывать время загрузки всей почты, вне зависимости от того, какие файлы и сколько загружает каждый пользователь. Грубо говоря, мы можем точно узнать, за какое время у пользователя грузится вся почта, а не каждый файл по отдельности.
В менее чем одном проценте случаев из-за непонятных причин эти цифры прилетают откровенно неправдоподобными. Например, отрицательными или равными 50 годам.
Для того чтобы отсечь такие значения, мы решили построить график времени, в которое укладывается 75%, 95% и 99% загрузок.
Но и этих цифр недостаточно — скорость загрузки меняется в том числе и из-за изменения размеров файлов и их количества. Для того чтобы понять, насколько в других регионах статика почты стала грузиться быстрее, в качестве KPI переезда мы выбрали сравнение скорости загрузки в каждом регионе со скоростью загрузки в Москве. То есть мы точечно начали отнимать от времени загрузки из региона время загрузки из Москвы. Если значение получалось отрицательным, мы считали, что делаем всё правильно и скорость в этом регионе стала быстрее.
Этот график помог найти несколько узких мест и проблем на региональных машинках, которые мы быстро починили.
Результат
В результате переезда Яндекс.Почта стала отвечать и грузиться быстрее: в зависимости от региона от нескольких сот миллисекунд до секунд. Скорость загрузки статики в Новосибирске и Казани увеличилась в два раза, в Екатеринбурге и в Владивостоке — примерно в полтора.
График среднего времени загрузки статики в некоторых городах
Благодаря настройке региональных серверов, мы нашли несколько возможностей увеличить скорость и в «домашнем» регионе: Яндекс.Почта стала быстрее не только в регионах, но и в Москве, так что предлагаем всем желающим начать использовать yandex.st.
Владельцам сайтов
Если в вашем проекте используется jquery или другие популярные javascript-фреймворки и библиотеки, вы можете подключить их с наших серверов.
Яндекс отключил расширения с аудиторией в 8 млн пользователей. Объясняем, почему мы пошли на такой шаг
Сегодня мы приняли решение отключить расширения SaveFrom.net, Frigate Light, Frigate CDN и некоторые другие, установленные у пользователей Яндекс.Браузера. Совокупная аудитория этих инструментов превышает 8 млн человек.
В этом посте мы расскажем о причинах и поделимся с сообществом результатами анализа деятельности расширений. Вы узнаете про тайное воспроизведение видео из онлайн-кинотеатров с целью накрутки просмотров. Увидите фрагмент кода, содержащий механизм для перехвата токенов социальных сетей. Мы покажем, как организована динамическая загрузка и выполнение произвольного кода без обновления расширений.
Предыстория
Некоторое время назад пользователи Яндекс.Браузера стали обращаться в поддержку с жалобами на странный звук, который можно было принять за аудиорекламу. Примеры таких жалоб:
Общение с пользователями помогло нам понять, что источником звука на самом деле была видеореклама. Но странность заключалась в том, что никакое видео в этот момент на экране не воспроизводилось. Сначала мы подумали, что оно проигрывалось в другой открытой вкладке или за пределами видимости, но эта гипотеза не подтвердилась. Начали запрашивать у пользователей дополнительную информацию. В том числе список установленных расширений.
Так мы заметили общий признак: у пострадавших было установлено расширение для загрузки видео от сервиса SaveFrom.net. Начали тестировать. Догадка оказалась верной: отключение расширения отключало и фоновый шум. Затем связались с его разработчиками. Они высказали предположение, что это ошибки конвертера, и внесли исправления. После обновления расширения жалобы на звук прекратились.
Новая история
В ноябре команда антифрода Яндекса заподозрила неладное. Она получила сигнал о том, что кто-то использует аудиторию популярных браузеров для накрутки просмотров видео в онлайн-кинотеатрах. Пользователи видео не видели, потому что оно воспроизводилось в фоне. Тем не менее оно потребляло существенный трафик и перегружало работой вычислительные ресурсы компьютера, поэтому такое поведение нельзя назвать добросовестным.
При этом в поддержку на посторонний звук больше никто не жаловался. Это можно было легко объяснить сознательным исключением аудитории Яндекс.Браузера из целевой. Подобные попытки избежать внимания со стороны нашего антифрода мы уже неоднократно встречали в прошлом при анализе поведения расширений из Chrome Web Store (напомним, что наш браузер поддерживает установку в том числе из этого каталога).
Но всё оказалось куда проще: на этот раз фоновое воспроизведение видео проходило в беззвучном режиме. Вскоре коллеги из Службы информационной безопасности выяснили, что проблема затрагивает не только внешних пользователей нашего браузера, но и даже наших коллег. Так мы получили проблемные ноутбуки для исследования и наконец-то смогли детально разобраться в происходящем.
На проблемных устройствах наших коллег были установлены расширения SaveFrom.net, Frigate Light или Frigate CDN. Источник их установки значения не имел (SaveFrom.net мог быть установлен с сайта, а Frigate — напрямую из каталога Chrome Web Store).
Далее мы поделимся с вами результатами нашего анализа. Приведём фрагменты исходного кода и объясним суть их работы. Начнём с объяснения того, как функциональность может подгружаться в расширение без его обновления, и закончим, собственно, воспроизведением видео на компьютере ничего не подозревающего пользователя.
Динамическая загрузка и выполнение кода
Frigate
(полный код расширения доступен по ссылке)
Оба расширения из этого семейства (Light и CDN) имеют один и тот же участок кода, который отвечает за динамическую подгрузку и исполнение JS-скриптов. Специалистам рекомендую обратить внимание на то, как хитро тут спрятана функция eval(). Кстати, обфускация кода и скрытие функциональности запрещены в Chrome Web Store.
Этот код совершает запрос по адресу fri-gate.org/config.txt и получает адрес командного сервера для дальнейшей работы. Такое решение позволяет без обновления расширения менять адреса командного сервера, если с ним что-то пошло не так. В момент нашего анализа командным сервером был gatpsstat.com.
Раз в час расширения совершают запрос к командному серверу в обработчик /ext/stat. При первом запросе им выставляется cookie, которая содержит uuid пользователя. Ответ сервера декодируется и попадает в функцию debug(), которая, по сути, является функцией eval() для выполнения JS-кода.
SaveFrom.net
(полный код расширения также доступен по ссылке)
На 19122-й строке файла background.js начинается блок сбора и выполнения кода.
Стоит обратить внимание на строку “x = m(99, 111, 110, 115, 116, 114, 117, 99, 116, 111, 114)”, которая аналогична “fromCharCode(99, 111, 110, 115, 116, 114, 117, 99, 116, 111, 114)” из расширения Frigate.
Далее идёт большой switch, который ответственен за загрузку и выполнения JS-кода.
По блокам выполнение происходит так:
Одинаковая часть для всех расширений
/ext/stat
Итак, все рассматриваемые расширения имеют возможность динамически выполнять JS-код, который они получают раз в час из обработчика /ext/stat. Этот JS-код в разные моменты времени может быть любым, сколь угодно опасным. Скрытое воспроизведение видео может быть лишь одним из множества возможных симптомов. Но поймать (и задокументировать) подобные симптомы не так-то и просто. Поначалу мы пытались дампить трафик через функциональность браузера, но это не приносило результатов. Даже начали сомневаться, что выбрали правильный путь. Обратились к более медленному, но надёжному варианту: завернули весь трафик через Burp Suite (это такая платформа для анализа безопасности веб-приложений, которая, среди прочего, позволяет перехватывать трафик между приложением и браузером).
Вскоре детальный анализ трафика принёс плоды. Оказалось, что наши предыдущие попытки получить правильный ответ были неуспешны из-за конфига dangerRules. Он содержал список адресов, после посещения которых потенциально опасная деятельность прекращалась.
Обратите внимание: сомнительная активность прекращалась, если пользователь открывал адрес поддержки Яндекс.Браузера или служебную страницу для анализа трафика. Хитро!
Расследование продолжилось. Предстояло разобраться с обработчиком /ext/up, которому и передавался конфиг. Его ответ был сжат и зашифрован, а код обфусцирован. Но это нас не остановило.
/ext/up
Ещё один обработчик с исполняемым кодом. Его ответ маскируется под GIF-картинку.
Расшифрованный ответ содержит JSON с тремя кусками кода. Названия блоков намекают на контекст исполнения кода: bg.js (применяется на фоновой странице расширения), page.js (используется для инъекций в просматриваемые страницы), entry_point.js (код, который отдаётся на /ext/stat).
bg.js и page.js умеют получать и внедрять в страницы iframe с video для показа рекламы. Кроме того, bg.js имеет функциональность, которая может использоваться для перехвата oAuth-токенов сервиса ВКонтакте. Мы не можем однозначно утверждать, что этот механизм в реальности использовался, но он присутствует в коде, поэтому мы рекомендуем отозвать токены для vk.com.
Кроме того, в bg.js мы видим код, который подменяет браузерный API, чтобы просмотры засчитывались даже при скрытом видео.
/ext/def
Предположительно, этот обработчик отвечает за отдачу списка текущих заданий для открутки видео. Запрос клиента и ответ сервера сжаты и зашифрованы на ключе из параметра hk.
В результате выполнения выданного задания видно, что браузер открывает видеоплеер и включает в нём видео. При этом сам видеоплеер не виден пользователю и действие происходит скрытно.
/ext/beacon
Отчёт о выполнении задания расширение отправляет на /ext/beacon. С уже знакомым нам сжатием и шифрованием.
Краткий пересказ того, что делают расширения
Повторим ещё раз всё то же самое, но кратко.
Принятые нами меры
Мы считаем описанное поведение потенциально опасным и недобросовестным, поэтому приняли решение отключить в Яндекс.Браузере уже установленные копии расширений SaveFrom.net, Frigate Light, Frigate CDN и некоторых других. Пользователи этих расширений получат уведомление, в котором мы расскажем о причинах отключения. После этого они смогут принять осознанное решение и при необходимости включить их вновь (хотя мы настоятельно рекомендуем так не поступать).
Кроме того, мы передали результаты нашего технического анализа коллегам из «Лаборатории Касперского» и Google. В «Лаборатории Касперского» уже подтвердили наличие потенциально вредоносной составляющей в расширениях, теперь продукты компании детектируют эту угрозу и блокируют связанные с ней URL-адреса и фрагменты скриптов.
Также в ходе исследования было обнаружено более двух десятков менее популярных браузерных расширений, использующих аналогичный код. Их мы также отключаем. Мы призываем экспертов присоединиться к поиску и других потенциально опасных расширений. Результаты можно присылать через форму. Вместе мы сможем побороть эту угрозу.
Что такое CDN и нужен ли он вашему сайту
Скорость загрузки контента — показатель, который влияет на лояльность пользователей и позицию сайта в поисковых системах. Согласно информации Google, медленная скорость загрузки увеличивает число отказов (уходов пользователей). Так, если страница загружается 6 секунд, оно достигает 106%.
Чтобы сайты с большим количеством данных открывались быстрее, используют технологию CDN. В статье расскажем, в каких ситуациях нужен CDN-хостинг и какие проблемы он помогает решить.
Что такое CDN и как это работает
Как устроена передача данных на обычном хостинге:
CDN-хостинг (Content Delivery Network) добавляет в это простое уравнение ещё один компонент — серверы, на которых кешируется часть контента или страница целиком. Они находятся между сервером и конечным пользователем, хранят информацию разных сайтов для быстрой загрузки и передают её друг другу.
CDN-хостинг предоставляют провайдеры. Они размещают сеть взаимосвязанных кеширующих CDN-серверов в разных точках мира. За счёт этого расстояние между клиентами и основным сервером не влияет на скорость передачи данных. Сайты, которые используют CDN-хостинг, загружаются быстрее.
Рассмотрим, в решении каких задач помогает CDN-хостинг.
1. Увеличивает скорость загрузки сайта
Предположим, у вашего проекта большая аудитория, и на сайт заходят люди из разных стран. Если все файлы хранятся на одном сервере, который расположен, например, в Польше, скорость загрузки сайта будет отличаться по мере удалённости от сервера. Те, кто живут поблизости (жители Белоруссии, Украины), будут получать контент с хорошей скоростью.
Но если посетитель живёт на Дальнем Востоке: в Хабаровске (7 202 км от Польши), на Камчатке (7 459 км от Польши) или на Сахалине (7 521 км от Польши), он будет долго ждать загрузки контента.
Чтобы скорость загрузки не зависела от географии пользователей, выбирают CDN-хостинг. В этом случае запросы пользователей, удалённых от основного сервера, будут автоматически переадресованы к ближайшему CDN-серверу (например, в Магадане), и проблем со скоростью не возникнет.
2. Разгружает основной сервер
Сейчас сайты состоят из статического и динамического контента. К статическому относится содержимое страницы, которое не меняется: тексты, картинки, видео- и аудиофайлы, скрипты. Это «тяжёлый» контент, который должен быстро загружаться у пользователей. К динамическому относятся файлы, которые отображаются по-разному у разных пользователей. Например, местоположение, пол, блок рекомендаций, история просмотра.
Динамический и статический контент создают разную нагрузку на сервер. Первый задействует оперативную память, а второй зависит от скорости сети. Если оба типа контента хранятся на одном сервере, это создаёт на него двойную нагрузку, поэтому страницы могут загружаться дольше.
Решить эту проблему помогает CDN-хостинг. Часть сайта (статический контент) передаётся на серверы из CDN-сетей, а динамический контент остаётся на основном сервере. Таким образом, нагрузка распределяется, и страницы загружаются быстрее.
3. Повышает безопасность
Если вы храните данные только на одном сервере, это делает ваш сайт менее устойчивым к кибератакам, например, к DDoS (Distributed Denial of Service). В этом случае злоумышленники будут бомбардировать сервер массой запросов/обращений, чтобы вызвать перебои в его работе. Когда сервер «ляжет», сайт будет недоступен.
При использовании CDN-хостинга запросы к вашему сайту будут обрабатывать сразу несколько серверов в зависимости от месторасположения «клиентов». Это значит, что нагрузка распределится равномерно, и сайт продолжит работу, несмотря на попытки снизить производительность ресурса.
Каким сайтам нужен CDN
Разумеется, далеко не всем сайтам требуется CDN-хостинг. В частности, проблем со скоростью загрузки контента может не быть на сайтах с небольшим количеством статического содержимого или интернет-магазинах, которые ориентируются на локальную аудиторию (город или область).
Если проблемы со скоростью загрузки сайта всё-таки есть, попробуйте решить их с помощью программистов:
Грамотно настроив код и сервер, вы сократите время загрузки сайта. Это решение не требует регулярных затрат, в отличие от CDN-хостинга.
Если вы уверены, что проблема со скоростью загрузки вызвана большим спросом, а не проблемами с кодом сайта, обратитесь к CDN-провайдерам.
Кому не обойтись без CDN:
Как используют CDN
Рассмотрим, как используют CDN-хостинг реальные компании. Например, интернет-магазин Ozon хранит на CDN-серверах статический контент (все изображения, шрифты, js-скрипты), поэтому в URL-адресах этих объектов фигурирует аббревиатура сервера:
Магазин техники «М.Видео» также использует CDN-хостинг. В отличие от Ozon, его файлы содержатся на нескольких серверах, поэтому один и тот же контент доступен по разным адресам. Например:
Популярные CDN-провайдеры
На CDN-хостинге специализируются многие компании. Мы расскажем о четырёх наиболее популярных.
CDNvideo — провайдер услуг в России и СНГ. Узлы сети (CDN-серверы) установлены в 20 городах РФ, на Украине, в Казахстане, Молдавии, Германии, Нидерландах, США и других странах. Согласно исследованию iKS-Consulting «Облачный провайдинг 2018–2022: экономика, стратегия, бизнес-модели» от 2019 года, компания заняла первое место на рынке CDN-провайдеров с долей 38,6%.
Cloudflare CDN — сеть, которая охватывает 200 городов в 100 странах. Другой важный момент: серверы обрабатывают не только статический, но и динамический контент. Ещё и базовые функции предоставляются бесплатно.
selectel.ru — российский CDN-провайдер. Вы платите за количество ТБ: чем больше трафик на серверы, тем меньше стоимость одного Гб. Компания предоставляет свои серверы и CDN зарубежного партнёра, Akamai. Вторые стоят дороже, отличаются высокой пропускной способностью и большим количеством точек присутствия.
Amazon Cloudfront — 216 точек присутствия. Подходит для кеширования статических и динамических файлов, прямой трансляции видео. Сервис бесплатный первый год и за счёт медийности компании сотрудничает с известными брендами (Canon, Slack и др.).
Клиенты RU-CENTER, которые приобрели или собираются купить лицензию 1C-Битрикс, могут подключить CDN-модуль автоматически и пользоваться им бесплатно. Подробности вы можете узнать из описания 1С-Битрикс.
Подытожим
Если ваш сайт рассчитан на широкую аудиторию и/или содержит большое количество контента (много товаров, видео, аудио и т. п.), то пользователи могут ждать загрузки дольше обычного. Чтобы сократить скорость загрузки, попробуйте исправить ошибки в коде и настройках сервера. Если это не решило проблему, воспользуйтесь CDN-хостингом.
CDN-хостинг позволяет кешировать часть контента (или страницы целиком) и быстрее загружать её для пользователей вне зависимости от их географического положения. Используя CDN-сеть, вы повысите скорость загрузки сайта, а значит — угодите пользователям и поднимитесь в поисковой выдаче.
Что такое 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 и другие).