Normandy cdn mozilla net что это

Обновлено: 04.07.2024

Отравление веб-кэша (Web Cache Poisoning) долгое время было неуловимой уязвимостью, «теоретической» угрозой, используемой главным образом для того, чтобы напугать разработчиков, которое никто не мог использовать.

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

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

Вы также можете посмотреть мою презентацию об этом исследовании или просмотреть ее в виде документа.

Основные понятия

Кеширование 101

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

Существуют также другие типы кэшей, такие как клиентские кэши браузеров и DNS-кэши, но они не являются предметом данного исследования.

Ключи кеша

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

Это означает, что кэши считают, что следующие два запроса эквивалентны, и с радостью ответят на второй запрос ответом, кэшированным с первого запроса:

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

Cache Poisoning (отравления веб-кэша)

Целью отравления веб-кэша является отправка запроса, который вызывает вредоносный ответ, который сохраняется в кэше и передается другим пользователям.

Методология

Мы будем использовать следующую методологию, чтобы найти уязвимости отравления кэша:

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

Первым шагом является определение неключевых входных параметров (unkeyed inputs). Делать это вручную утомительно, поэтому я разработал расширение Burp Suite с открытым исходным кодом под названием Param Miner, которое автоматизирует этот шаг, угадывая имена заголовков/файлов cookie и отслеживая, влияют ли они на ответ приложения.

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

Кэшированные ответы могут маскировать unkeyed inputs, поэтому, если вы пытаетесь вручную обнаружить или исследовать unkeyed inputs, решающее значение имеет очистка кеша. Если у вас загружен Param Miner, вы можете убедиться, что каждый запрос имеет уникальный ключ кэша, добавив параметр со значением $randomplz в строку запроса.

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

Тематические исследования

Ответ от некоторых владельцев сайтов был смешанным; Unity исправила все быстро и хорошо вознаградила за работу, Mozilla, по крайней мере, быстро исправила, а другие, включая data.gov и Ghost, ничего не делали месяцами и исправляли только из-за угрозы предстоящей публикации.

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

Основы отравления

Несмотря на свою внушающую страх репутацию, отравление кэша часто очень легко использовать. Чтобы начать, давайте посмотрим на домашнюю страницу Red Hat. Param Miner на которой сразу же обнаружил unkeyed input:

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://canary/cms/social.jpg" />

GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."><script>alert(1)</script>

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/>

HTTP/1.1 200 OK
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/>

Осторожное отравление

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

HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800
…
<script src="https://portswigger-labs.net/sites/files/foo.js"></script>

Выборочное отравление

GET / HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 … Firefox/60.0
X-Forwarded-Host: a"><iframe onload=alert(1)>

HTTP/1.1 200 OK
X-Served-By: cache-lhr6335-LHR
Vary: User-Agent, Accept-Encoding
…
<link rel="canonical" href="https://a">a<iframe onload=alert(1)>
</iframe>

Изначально это выглядит практически идентично первому примеру. Однако заголовок Vary сообщает нам, что наш User-Agent может быть частью ключа кеша, и ручное тестирование подтверждает это. Это означает, что, поскольку мы заявили, что используем Firefox 60, наш эксплойт будет доступен только другим пользователям Firefox 60. Мы могли бы использовать список популярных пользовательских агентов, чтобы гарантировать, что большинство посетителей получат наш эксплойт, и такое поведение дало нам возможность более выборочных атак. При условии, что вы знаете их пользовательского агента, вы можете адаптировать атаку к конкретному человеку или даже скрыться от группы мониторинга сайта.

DOM Отравление

Использование unkeyed input не всегда так просто, как вставка полезной нагрузки XSS. Рассмотрим следующий запрос:

Файл содержит карту для перевода фраз на выбранный пользователем язык. Создав собственный файл перевода и используя отравление кэша, чтобы указать пользователям на это, мы можем перевести фразы в эксплойты:

Конечный результат? Любой, кто просматривал страницу, содержащую текст «Show more», будет взломан.

Взлом Mozilla SHIELD

Правило сопоставления/замены «X-Forwarded-Host», которое я настроил, чтобы помочь разобраться с последней уязвимостью, имело неожиданный побочный эффект. В дополнение к взаимодействиям из catalog.data.gov я еще кое что узнал:

Ранее я сталкивался с «нулевым» origin в своем исследовании CORS vulnerability research, но никогда раньше не видел, чтобы браузер генерировал полностью строчный заголовок Origin. Поиск в журнале истории прокси показало, что виновником был сам Firefox. Firefox попытался получить необходимые ему данные как часть своей системы SHIELD для автоматической установки расширений в маркетинговых и исследовательских целях. Эта система, вероятно, наиболее известна тем, что принудительно распространяет расширение «Mr Robot», что вызывает значительную негативную реакцию пользователей.

В любом случае, похоже, что заголовок X-Forwarded-Host обманул эту систему и направил Firefox на мой собственный сайт для получения этих данных:

HTTP/1.1 200 OK
"action-list": "https://xyz.burpcollaborator.net/api/v1/action/",
"action-signed": "https://xyz.burpcollaborator.net/api/v1/action/signed/",
"recipe-list": "https://xyz.burpcollaborator.net/api/v1/recipe/",
"recipe-signed": "https://xyz.burpcollaborator.net/api/v1/recipe/signed/",
…
>

Данные имеют следующий формат:

[ "id": 403,
"last_updated": "2017-12-15T02:05:13.006390Z",
"name": "Looking Glass (take 2)",
"action": "opt-out-study",
"addonUrl": "https://normandy.amazonaws.com/ext/pug.mrrobotshield1.0.4-signed.xpi",
"filter_expression": "normandy.country in ['US', 'CA']\n && normandy.version >= '57.0'\n)",
"description": "MY REALITY IS JUST DIFFERENT THAN YOURS",
>]

Эта система использовала NGINX для кеширования, которая, естественно, была счастлива сохранить мой отравленный ответ и передать его другим пользователям. Firefox извлекает этот URL-адрес вскоре после открытия браузера, а также периодически обновляет его, что в конечном итоге означает, что все десятки миллионов ежедневных пользователей Firefox могут в конечном итоге получить данные с моего веб-сайта.

Я сообщил об этом в Mozilla, и они исправили свою инфраструктуру менее чем за 24 часа, но были некоторые разногласия по поводу серьезности, поэтому за нахождение этой уязвимости было выплачено только 1000 долларов.

Отравление маршрутизации запросов

Некоторые приложения глупо используют заголовки для генерации URL-адресов и глупо используют их для внутренней маршрутизации запросов:

Cloudflare с радостью кешировал этот ответ и передал его последующим посетителям.

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

Скрытое отравление маршрутизации

Уязвимости отравления маршрутов не всегда так очевидны:

Важно отметить, что это перенаправление также может быть запущено с помощью заголовка X-Forwarded-Host:

Цепочка Unkeyed Inputs

Иногда unkeyed input может привести к путанице только в части стека приложения, и вам потребуется объединить в цепочку другие unkeyed input, чтобы получить пригодный для использования результат. Возьмите следующий сайт:

Заголовок X-Forwarded-Host позволяет переопределить домен в cookie. Само по себе это бесполезно. Тем не менее, есть еще один unkeyed input:

Эти данные также бесполезны сами по себе, но если мы объединяем их вместе, мы можем преобразовать ответ в перенаправление на произвольный домен:

Взлом Open Graph

На другом сайте unkeyed input затрагивал исключительно URL-адреса Open Graph:

Как вы могли заметить, приложение устанавливает «Cache-Control: private», и Cloudflare отказывается кэшировать такие ответы. К счастью, другие страницы сайта явно позволяют подобное кеширование:

Заголовок «CF-Cache-Status» здесь является индикатором того, что Cloudflare рассматривает возможность кэширования этого ответа, но, несмотря на это, ответ никогда не кэшировался. Я предположил, что отказ Cloudflare кешировать может быть связан с cookie session_id, и повторил попытку с этим cookie:

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

Здесь строка colo=AMS показывает, что Facebook получил доступ к waf.party через кеш в Амстердаме. Доступ к веб-сайту осуществлялся через Atlanta, поэтому я арендовал там VPS за 2 доллара в месяц и снова попытался отравить кеш:

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

Отравление локального маршрута

До сих пор мы видели перехват параметра language на основе cookie и множества атак с использованием различных заголовков переопределяющих хост. На этом этапе исследования я также обнаружил несколько вариантов, использующих причудливые нестандартные заголовки, такие как «translate», «bucket» и «path_info». Мое следующее значительное улучшение в исследование произошло после того, как я расширил список слов заголовков, загрузив и изучив 20 000 лучших PHP-проектов на GitHub для названий заголовков.

Это выявило заголовки X-Original-URL и X-Rewrite-URL, которые переопределяют путь запроса. Я впервые заметил, что они влияют на сайты, работающие на Drupal, и копаясь в коде Drupal, выяснилось, что поддержка этого заголовка исходит от популярной PHP-платформы Symfony, которая, в свою очередь, взяла код от Zend. Конечным результатом является то, что огромное количество PHP-приложений невольно поддерживают эти заголовки. Прежде чем мы попытаемся использовать эти заголовки для отравления кэша, я должен отметить, что они также отлично подходят для обхода WAF и правил безопасности:

Если приложение использует кеш, то эти заголовки могут быть использованы, чтобы запутать сервер для получения неверных страниц. Например, этот запрос имеет ключ кеша /education?x=y, но извлекает контент из /gambling?x=y:

Конечный результат заключается в том, что после отправки этого запроса любой, кто пытается получить доступ к странице Unity for Education, получает сюрприз:

Способность переключать страницы более забавна, чем серьезна, но, возможно, она может быть использована в более крупной цепочке эксплойтов.

Внутреннее отправление кеша

Drupal часто используется со сторонними кешами, такими как Varnish, но он также содержит внутренний кеш, который включен по умолчанию. Этот кеш знает заголовок X-Original-URL и включает его в свой ключ кеша, но допускает ошибку, включая строку запроса из этого заголовка:

В то время как предыдущая атака позволила нам заменить путь другим путем, этот позволяет переопределить строку запроса:

Drupal Open Redirect

Еще раз, само по себе открытое перенаправление вряд ли интересно, но теперь у нас наконец есть все строительные блоки для серьезного использования.

Постоянный взлом перенаправления

Мы можем объединить атаку переопределения параметра с Open Redirect, чтобы постоянно перехватывать любое перенаправление. На некоторых страницах сайта Pinterest происходит импорт JavaScript с помощью перенаправления. Следующий запрос отравляет запись в кэше, показанную синим цветом, с параметром, показанным оранжевым:

Вложенное отправление кеша

Далее мы отравляем внешний кеш, чтобы заменить /download?v=1 нашим предварительно отравленным /redir:

Вот видео одной из таких атак на стандартную установку Drupal:

Cross-Cloud отравление

Как вы, наверное, догадались, некоторые из этих отчетов об уязвимостях вызвали интересные реакции.

Один из экспертов, оценивающих мою отправку с использованием CVSS, дал отчету об отравлении кеша CloudFront сложность выполнения «высокий», поскольку злоумышленнику может понадобиться арендовать несколько VPS, чтобы отравить все кеши CloudFront. Не поддаваясь искушению спорить о том, что представляет собой «высокую» сложность, я использовал это как возможность исследовать, возможны ли межрегиональные атаки без использования VPS.

Поскольку у Cloudflare большое количество региональных кешей, я решил посмотреть и на них. Cloudflare публикует список всех своих IP-адресов в Интернете, поэтому я написал быстрый скрипт для запроса waf.party/cgn-cgi/trace через каждый из этих IP-адресов и записи, какой кеш я использовал:

Это показало, что при таргетинге на waf.party (который находится в Ирландии) я мог получить доступ к следующим кешам из моего дома в Манчестере:

104.28.19.112 LHR 172.64.13.163 EWR 198.41.212.78 AMS
172.64.47.124 DME 172.64.32.99 SIN 108.162.253.199 MSP
172.64.9.230 IAD 198.41.238.27 AKL 162.158.145.197 YVR

Защита

Аналогичным образом, предотвращение получения входных данных от заголовков и файлов cookie является эффективным способом предотвращения заражения кэша, но трудно понять, содержать ли другие уровни и фреймворки возможность изменения дополнительных заголовков. В связи с этим я рекомендую проводить аудит каждой страницы вашего приложения с помощью Param Miner для выявления unkeyed inputs.

Как только вы определили unkeyed inputs в своем приложении, идеальным решением будет их полное отключение. В противном случае вы можете удалить inputs на уровне кэша или добавить их в ключ кэша. Некоторые кэши позволяют использовать Vary header для unkeyed inputs, а другие позволяют вам определять пользовательские ключи кэша, но могут ограничивать эту функцию для «корпоративных» клиентов.

Заключение

Наконец, я поставил перед людьми небольшую задачу проверить свои знания и с нетерпением жду возможности увидеть, когда другие исследователи будут отравлять веб-кеш в будущем.

Обновление 2020: мы выпустили шесть бесплатных интерактивных лабораторий, чтобы вы могли сами попробовать отравить веб-кеш в рамках нашей Академии веб-безопасности:

О том, что в Интернете с каждым годом становится все больше «тяжелого» контента.
А также о том, что в современном мире огромную роль играет скорость работы веб-сайтов и сервисов. Если скорость слишком мала ― это чревато потерей аудитории, а во многих случаях ― ещё и прибыли. Один из надёжных способов решения этой проблемы ― использование сетей доставки контента (Content Delivery Networks, CDN).

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

Основные термины

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

Ориджин (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 необходимо выполнить следующие шаги:

Статический контент, предназначенный для раздачи, часто помещается в объектные хранилища (об этом мы писали еще шесть лет назад). Существует множество плагинов и расширений для популярных CMS (Wordpress, Joomla, Drupal, 1C Битрикс и других), с помощью которых можно настроить интеграцию с облачными сервисами хранения и раздачу статики через CDN.

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

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

Как CDN понимает, где находится ближайший кэширующий сервер?

Как правило, для подгрузки контента из CDN используются две популярные технологии: GeoDNS и AnyCast.

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

Как кэшируется контент?

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

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

Для преодоления ограничений, накладываемых этой схемой, используются технологии регионального извлечения: соседние серверы, входящие в состав 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. Что это такое? Расшифровка этой аббревиатуры переводится с английского как сеть доставки контента юзеру, распределённая регионально.

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

CDN: что это и как это работает?

Самый актуальный вопрос - как это устроено? На самом деле односложно ответить нельзя. В качестве ответа можно привести несколько различных вариантов.

Итак, что это – CDN? Можно начать с более знакомого варианта (максимальная экономия). Сеть - это совокупность крупных провайдеров, держащих собственные ДЦ (к примеру, "Мегафон", Центральный телеграф и тому подобное, в том числе региональные фирмы). Бэкбона как такового нет, все переходит по одним каналам с абонентским и клиентским траффиком.

Взаимосвязь с провайдерами в таком случае крайне слабая. В данных примерах, как правило, без своего оборудования не обойтись, потому что все упирается в дисковую подсистему, а она (несмотря на заявления множества адептов профильных "стальных" компаний), виртуализируется в высшей степени плохо. Нередко можно услышать о том, что ценные IOPS-ы в процессе виртуализации теряются. SSD при этом практически не используются, поскольку это обходится весьма недешево.

Сервисы CDN (Jquery и другие), как правило, сами по себе серверы "универсальные". Они применяются под поточное радиовещание и под веб-кэши, стримовые серверы для flv и mp4-файлов. На подобных серверах используются и всем известные DNS. Балансировка ведется лишь только способами DNS- view по регионам/провайдерам и так далее. Также широко известны Image CDN, облегчающие передачу крупных графических файлов.

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

Более высокий уровень

Более мощные CDN (в ведущем большинстве нероссийские - Akamai, L3, CDNetworks) обычно не экономят на собственной инфраструктуре вследствие того, что понимают перспективность таких инвестиций. У них устроено все по-другому. Так, сеть у них своя (backbone-сеть), которая служит как для внутреннего, так и для служебного траффика. Кроме того, они обладают и своими AS (автономными системами). Вопросы маршрутизации они также держат в своих руках. Пиринговые взаимоотношения с интернет-провайдерами у них тоже хорошо налажены.

Балансировка здесь построена по принципу anycast + DNS + LVS. Из архитектуры сети и вышеуказанной маршрутизации проистекает и вероятность балансировки запросов от потребителя более продвинутыми способами. Это осуществляется не только путем view-DNS, но и anycast. На любом айпи-адресе закрепляется балансировщик, позволяющий отправлять запросы различным серверам.

Конечно, ни о каких "универсальных" нодах речи нет, как и о виртуализации абсолютно всех сервисов. Существуют серверы, закачивающие контент, а также для раздачи мгновенного контента. Также есть промежуточные места для хранения больших объемов данных, которым необходимы стримящие и раздающие составляющие.

Кроме того, бывают серверы: исходные, промежуточные и оконечные мультиплексоры, на которые клиент публикует поток. В случае, если на выходе необходим hls, hds или же sliverlight-стриминг, оконечными серверами, как правило, считаются веб-кэши для очень качественного и быстро загружаемого контента.

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

Какие серверы находят свое применение?

С точки зрения техники, такие сервисы применяют веб-кеши nginx, т. к. у сервера есть все необходимое для проксирования запросов и кэширования. К нему можно писать собственные модули, в т. ч. для закачки нужного контента в кеш, «чистки» определенных объемов информации в нем, сбора статистических данных (и, к примеру, отправки ее в mongo-базу). Также обычно предусматривается сервисное обслуживание со стороны компании-изготовителя. Так, L3 создала для себя собственный nginx (собственный web-сервер CDNJS).

Стримящие серверы - зачастую это что-то собственное (обычно на основе готовых моделей типа red5 или что-то подобное) или Wowza Media Server. Серверы, куда заказчик публикует потоки, – обычно Adobe FMS. Как правило, к ним относятся Game CDN.

Серверы хранения могут быть и объектными хранилищами типа mogilefs, hadoop, и весьма большими FS типа Lustre либо Gluster, которые сейчас приобретают популярность. Распространены также OpenStack-хранилища Swift (Files CDN), несмотря на то, что они еще не доработаны и не получили широкого одобрения из-за некой «сыроватости».

Транскодеры представляют собой классический вариант ffmpeg с крупной самописной обвязкой (следящее программное обеспечение, менеджер очередности выполнения заданий и пр.)

Статистические данные

Многое зависит от методик по тарифообразованию и схемам биллинга. Но есть моменты, которые нельзя обойти. Учет статистики с использованием netflow в основном невозможен, поскольку объем траффика большой, и нерационально выделять целую статью затрат на такое количество оборудования по обсчету и распараллеливанию процесса. Статистику производят по логам. Начиная с оконечных нод, при схлопывании повторяющихся запросов (на 1 CDN URL с 1 IP или подсети), затем агрегированные логи молотят на специальных серверах, там выводят статистические данные для технических нужд и биллинга.

Статистика детальнее

Как работает статистика в CDN? Что это такое в подробностях? Она включает в себя следующие компоненты:

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

Сжатый обзор самых популярных CDN-провайдеров

Каждому продвинутому пользователю полезно узнать о нескольких наиболее популярных сервисах сетей доставки контента (Jquery CDN и тому подобных). Некоторые из них нашли широкое применение, в то время как другие находятся на стадии роста и развития.

Сеть CloudFlare

На сегодняшний день это наиболее известный и распространенный сервис CDN URL. В сети CloudFlare возможно приобрести платный тарифный пакет или воспользоваться бесплатным тарифом. Компания функционирует на рынке уже более полутора десятков лет и заработала за это время себе безупречную репутацию. Одно из ключевых достоинств сервиса – CloudFlare не задает определенную пропускную способность, как у компаний-конкурентов.

Сеть MaxCDN

Также один из популярнейших CDN-сервисов, которым владеет компания NetDNA (лидер по распределенной доставке). Ключевое достоинство MaxCDN – сервис легко интегрировать с самыми распространёнными системами управления содержимым (WP, Joomla, Drupal, Magento и др.). В этой сети (Frigate CDN) тестовая версия предоставляется бесплатно на неделю, бесплатного тарифа пока нет. Однако стоимость использования вполне доступна.

Сеть TinyCDN

Соласно отзывам пользователей, один из лучших сервисов. В его основе – база Amazon Web Services (одной из самых известных в этой сфере компаний), потому он один из самых надёжных. Цена за пользование им ненамного выше, чем у компаний-конкурентов. В TinyCDN есть бесплатная версия для тестирования, предоставляющая на 30 дней возможность пользования услугой.