Знакомство с Content Delivery Network
Содержимое: что такое CDN? История возникновения. Зачем она нужна? Кому она нужна, а кому нет? Порог вхождения, стоимость, издержки. Основные технологии.
CDN — сокращение от content delivery network, то есть “сеть доставки контента”. Чаще всего это множество серверов с специализированным ПО, которые ускоряют доставку (“отдачу”) контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под “контентом” чаще всего подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js), но к “контенту” относятся и совсем неожиданные вещи — например, игры в Стиме (использует CDN для отдачи игр), обновления для операционных систем и т.д.
Немного истории
Резкий рост Интернета в середине 90-х привёл к ситуации, что сервера тех лет не могли в одиночку выдержать нагрузку (много ли может отдать могучий двухпроцессорный сервер на базе Pentium Pro на частоте в 266 МГц с 128 мегабайтами памяти?). Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом. В ходе разработки и внедрения разных решений была замечена одна важная особенность: есть два типа контента — статический и динамический.
Динамический контент формируется сервером в момент получения запроса сервером, чаще всего при активном участии базы данных. Если на странице снизу надпись “page was generated in 0.333 seconds” — это как раз пример динамического контента.
Статический контент на сервере находится в готовом виде — кто бы не прислал запрос, сервер будет отдавать одно и то же (с поправкой на возможные ACL). Важно, что содержимое при этом не меняется от запроса к запросу.
Статический и динамический контенты создают разный тип нагрузки на сервер. Когда раздаётся “динамика”, то важны процессор, IO (для базы данных) и сколько-то памяти. Когда раздаётся статика, процессор почти не важен, IO важно только для тех файлов, которые не кешированы, а основное требование — это скорость сети. Заставлять раздавать статику серверами, которые раздают динамику, можно, но это совмещение ролей, которое мешает друг другу. Особенно тяжело приходится в тот момент, когда IO от статики начинает мешаться с IO от динамики, а нагрузка на IRQ мешает выполнять скрипты динамики.
Ещё более важной деталью является то, что “динамический” обычно означает наличие “состояния” (сессии и связанных с ним данных), а статика — нет. Статику можно масштабировать горизонтально без сложных двухсторонних синхронизаций с центральным сервером. В случае с динамикой так не получится — нужна либо общая база данных, либо методы синхронизации и блокировок.
Средние и крупные компании начали раздавать статику и динамику с разных серверов, расположенных в разных местах планеты, уменьшая нагрузку на сайты с динамикой за счёт выноса с них статики на легко масштабируемые сервера. После чего сделать шаг до “аутсорса” раздачи статики было просто, и начали появляться компании, которые сделали раздачу статики основой (или хотя бы крупной составляющей) своего бизнеса.
О главном
Заметим, что CDN решает ещё более важную проблему, чем облегчение жизни серверам приложений.
Все современные CDN размещают копии контента на разных серверах по всему миру и направляют клиента на ближайший (к клиенту) сервер. Результат — сокращение latency, то есть задержки между запросом и ответом. Если на странице много изображений (пусть даже мелких картинок), то чем быстрее они окажутся у клиента, тем быстрее клиент увидит страницу. И если мы уберём из рассмотрения страдальцев на dialup/gprs, то время, за которое будет показана страница определяется практически только сетевой задержкой. Если мы говорим про расстояния в сотни километров (~10мс задержка), это не существенно. Но если речь про расстояния в континенты — то тут задержка в сотни миллисекунд (до 500-600!) начинает уже играть радикальную роль. А если же контент отдаётся с сервера, который в нескольких километрах от пользователя, то случается чудо! Австралия видит данные с сайта из США в единицы милисекунд, Китай из сайта из России, Франция с сайта из Бразилии. Без участия океанических кабелей.
Работает это и на меньшем масштабе: Например, Яндекс при помощи CDN в свое время знатно ускорил работу почты в регионах России, которым до Москвы по оптике топать и топать.
Ускорение доставки контента стало главной киллер-фичей CDN, а всё остальное (снижение нагрузки, её балансировка и т.д.) — стало второстепенным. Важным, но не критическим. В конце-концов, любую нагрузку можно завалить деньгами. Но никакими деньгами нельзя сделать так, чтобы без локальных точек присутствия сигнал из Перми доходил до Сан-Франциско за десятки миллисекунд.
При том, что экономия не является киллер-фичей, она тоже важна. CDN в некоторых ситуациях позволяет ощутимо экономить на трафике. Передать на другой континент файлы один раз, держать их там на локальном сервере и раздать через локальные линки дешевле, чем гонять тот же трафик десять тысяч раз через транс-атлантику. Чаще всего об экономии начинают думать в тот момент, когда это становится критичным (видеохостинги в первую очередь).
Однако, сервера по всему миру, система синхронизации контента и направления клиентов к ближайшим серверам и т.д. — всё это не бесплатно. Чаще всего CDN просят дополнительные деньги по сравнению с обычным трафиком аплинков, хотя для некоторых регионов может оказаться, что трафик CDN выгоднее, чем трафик аплинка (но это, скорее, говорит о том, что интернет в регионе не ахти).
Как это работает на практике?
Со стороны посетителя сайта: он заходит на сайт example.com, где ему отдают html-страницу. В этой html-странице все css, js, картинки и видео — указывают на сайт cdn.example.com — контент грузится оттуда. Когда браузер клиента обращается этот адрес, то благодаря магии BGP его запрос отправляется на ближайший узел присутствия. Сама магия BGP состоит в том, что провайдеру посетителя на IP-сеть, в которой находится cdn.example.com, присылается несколько анонсов от разных сетей (в которых есть точка присутствия), а маршрутизатор провайдера из них выбирает самый близкий. В результате, запрос уходит на ближайший сервер, который отвечает на него, и ответ уходит аналогично, тоже по короткому маршруту.
- файлы статики загружаются в объектное хранилище, по ftp, scp или иным удобным методом. На объектное хранилище (в панели управления) назначается dns-имя (своё, или выданное провайдером — зависит от технологии), которое и указывается в html-странице.
- Владелец сайта указывает ‘origin’ для домена, после чего, по обращению клиента, CDN идёт на сайт, к которому подключен cdn и скачивает к себе файлы и отдаёт их браузеру пользователя.
Кстати, она может быть тоже статической. По такому принципу работают, например, страницы на github.io — это чистый CDN, в нём всё раздаётся статикой.
Кому нужен CDN?
Тем, кому важно отдать статику быстро множеству посетителей, которые находятся далеко от серверов компании (ситуация ещё острее для компаний, у которых посетители раскиданы по большой территории, то есть даже перенос серверов “поближе” смысла не имеет — всё равно большинство окажется “далеко”).
Тем, у кого очень большой объём файлов — и стоимость трафика CDN оказывается ниже стоимости трафика, уходящего к аплинкам (у крупных сайтов обычно трафик стоит разных денег — локальный дешевле, “глобальный” дороже).
При определённой полосе, вынос статики на CDN оказывается выгоднее, чем апгрейд сетевого оборудования. Обычно статика занимает значительную часть полосы, и вместо апгрейда с 1G до 10G, или с 10G до 40G, куда дешевле выкинуть 80% трафика на CDN и оставаться на разумных по цене серверах.
Различия
Если с CDN всё понятно, то как насчёт их поставщиков? Компаний много, они различаются ценой, услугами и качеством.
Вот основные факторы, которые надо определить для себя при выборе поставщика:
1. Количество точек присутствия (Point of Presence)
Чем больше точек, тем лучше, однако… Oднако, зачем вам точки присутствия в Китае, если сайт русскоязычный? А количество точек присутствия в Австралии при выходе на американский рынок… При сравнении CDN следует учитывать число точек присутствия в интересующих странах и регионах. Просто заверений о большом числе точек присутствия и хорошей связности не достаточно — для информированного выбора нужно видеть список точек присутствия и сопоставлять их с потенциальной аудиторией сайта.
Сами точки присутствия так же не равнозначны — связность и пиринговые соглашения с локальными провайдерами очень важны. К сожалению, “иногородцу” оценить связность довольно сложно (нужно понимать расстановку сил на локальном провайдерском рынке), но, сравнивая предложения стоит уточнить о списке пиров каждого из кандидатов в самых важных точках присутствия.
- Репликация всего контента. Плюс — быстро работает сразу, даже первый запрос отдаётся быстро. Минус — дорого.
- Репликация по первому обращению (самая распространённая схема). Первое обращение медленное, дальше быстрее. Может быть дорого, в зависимости от политики устаревания (retention policy).
- Асинхронная репликация по превышению определённого порога обращений. Более экономичная версия, большее число клиентов получает медленное обслуживание.
3. SLA
Да, да, легендарный и необъятный Service Level Agreement. Перед тем, как радоваться длинной чреде девяток, уточните — это SLA для CDN “вообще” или для всех точек присутствия? Если в самой важной для вас локации ломается сервер и контент отдают “из соседней страны” это будет засчитываться за даунтайм по SLA? Ну и, основное, чем грозит несоблюдение SLA поставщику? Вам вернут копеечку от месячного платежа, или там есть солидные штрафные санкции?
Кстати, хоть продающий менеджер и будет сопротивляться, будет здорово, если вам покажут статистику отказов за предшествующее время. Отказы будут, и они бывают у всех (подсказка: если вам рассказывают про то, что у кого-то никогда не было аварий — либо это очень молодые, либо очень наглые) — весь вопрос в их длительности и частоте.
- real-time информирование об отказе отдельных узлов
- Аналитика
- Интеграция с CMS
- DRM для контента
- Готовый html/flash видеоплеер для видеофайлов с поддержкой особенностей CDN
- Управление политикой кеширования
Очень важно обратить внимание на поддержку нужны протоколов и файлов. Узнайте, поддерживает ли выбранный вами провайдер потоковое воспроизведение флеш- и медиафайлов (RTMP, RTSP), если вы планируете доставлять именно такой контент.
Возможно, провайдер очень хорош во всем остальном, но, если он не поддерживает нужные вам технологии, вам это вряд ли понравится.
5. Технические нюансы
Технология переадресации: Это либо эникаст на уровне DNS, либо переадресация через редиректы. Эникаст, по понятным причинам, работает быстрее.
Аккуратность переадресации: К сожалению, этот показатель сам поставщик объективно оценить не сможет, хотя как раз этот показатель очень важен — какая часть целевой аудитории попадает на ближайший сервер. Часто говорят про ожидаемую задержку (так как фактическое расстояние никого не волнует, а всех волнует время прохождения пакетов — например, бывает так, что стык между двумя сетями перегружен и пакеты ходят медленно, в этой ситуации лучше сходить чуть дальше, но быстрее).
6. Аккаунтинг
Как именно поставщик берёт деньги? За мегабайты или за мегабиты в секунду? Есть ли минимальный коммит (“если раздалось меньше предусмотренного договором доплатить до минимума”), что происходит при оверкоммите (превышении лимита) — отключают/берут больше денег? Есть ли минимальный срок контракта? Есть ли вообще контракт (заключающийся между владельцем сайта и поставщиком CDN), или же это автоматический self-serving on-demand provisioning, то есть “закинул денег на счёт и получил панель управления”?
Начиная с каких объёмов имеет смысл думать о CDN?
Повторим мысль: если нужно быстро обслужить клиентов, то объём трафика уже не важен — важны точки присутствия поближе к целевой аудитории.
Если же значительной потребности в низкой latency нет, а CDN используется для облегчения нагрузки на сервера, то осмысленный объём трафика, с которым стоит начинать думать о CDN — это несколько терабайт в месяц.
Главный вопрос: сколько это стоит?
Цена сильно варьируется от специфики CDN, степени “крутости” поставщика и адаптации CDN под конкретные специальные потребности. Диапазон цен на рынке — от $1 до $140/мегабит полосы, или $0.03-$0.3 за ГБ трафика. Фактическая цена очень часто зависит от добавленных услуг и возможностей CDN. Трафик в США и Европе обычно самый дешёвый, дальше идёт трафик в Азии/Австралии, самый же дорогой трафик — за пределами этих регионов.
Краткий обзор рынка
Все компании делятся на две категории — работающие по существующим публичным тарифам и работающие на основании договорённостей. Вторые компании крайне сложно сравнивать, так как условия в них могут сильно различаться. Однако, “приватный” не означает “маленький” — у приватных компаний чаще всего очень крупные клиенты с огромными объёмами в сотни терабит (полосы), а на “мелюзгу” с десятком гигабит они не заморачиваются.
Вот список популярных CDN (чтобы никого не обижать, список отсортирован в случайном порядке):
- NetDNA, 2009, минимальный контракт 1 год, цены от ¢1 до ¢6 за Гб в зависимости от объёма, трафик за пределами EU/US в полтора раза дороже, хранение бесплатно
- Rackspace Cloud Files — ¢4-¢12 за Гб полосы, ¢10 за Гб хранения (реселлит Акамай)
- MaxCDN от ¢3 до ¢8 за Гб трафика
- Amazon CloudFront — EU/US — от ¢6 до ¢12 за Гб, хранение бесплатно.
- CacheFly — ¢20-¢30, минимальный контракт $99/месяц, превышение места оплачивается ($15/Гб)
- CDN77 — ¢3-¢15/Гб
- CloudFlare — трафик не оплачивается, различный уровень сервиса стоит различных денег, начиная от базового бесплатного, следующего за ним в $5/месяц, до $200/месяц на лучшем.
- BitGravity — от ¢7 до ¢20 за Гб, в зависимости от объёма и региона
- Level 3 — от $100 в месяц, ¢10-¢25 за Гб
- Leaseweb — от ¢6 до ¢8 за Гб, с минимальной стоимостью от $60/месяц
- Windows Azure CDN от ¢3 до ¢20
- CDNsun — от ¢3 до ¢5 за Гб
- Internap
- Akamai
- Limelight Networks
- AT&T
- Peer1
- EdgeCast
- www.cdnplanet.com
- www.cdnfinder.com
Статья написана при поддержке наших коллег из компании UCDN, которые слишком скромны, чтобы включать себя в список выше.
- cdn
- content delivery network
- динамика
- статика
- спасибо за чтение
Быть, а не казаться
Предустанавливаемая в Windows 10 программа позволяет воровать пароли. Отключаем установку приложений без ведома пользователя.
Если на вашем ПК используется Windows 10, то есть вероятность, что на компьютере будет без вашего ведома установлено стороннее приложение для управления паролями, которое позволит злоумышленнику удаленно украсть все ваши учетные данные.
Начиная с обновления Windows 10 Anniversary Update (версия 1607), Microsoft добавила новую функцию под названием Content Delivery Manager, которая незаметно для пользователя устанавливает новые «предлагаемые приложения».
Исследователь Google Project Zero рассказал, что нашел ранее известный менеджер паролей «Keeper» на своей недавно установленной системе Windows 10, которую он загрузил непосредственно из Microsoft Developer Network (MSDN).
Он был не единственным, кто обнаружил менеджер паролей Keeper. Ранее некоторые пользователи Reddit жаловались на скрытый менеджер паролей около шести месяцев назад. При этом один из пользователей сообщил что обнаружил Keeper установленным на виртуальной машине под управлением Windows 10 Pro.
Все это было бы не так опасно, если бы не обнаруженная критическая уязвимость в этом менеджере, позволяющая вредоносным веб-сайтам воровать пароли.
Уязвимость в Keeper была почти идентична той, которую исследователь обнаружил в другой версии того же менеджера паролей в августе 2016 года.
После того, как команда разработчиков Keeper была уведомлена о проблеме, они выпустили исправление для версии 11.4.
Компонент Content Delivery Manager практически сразу после установки чистой ОС Windows 10 устанавливает незаметно от пользователя такие приложения как Adobe Photoshop Express, Asphalt 8: Airborne, FarmVille, Netflix и PicsArt. Все они устанавливаются без подтверждения со стороны пользователя. Мало того, это происходит, когда на компьютере не используется учетная запись Microsoft.
Чтобы запретить Content Delivery Manager устанавливать приложения без ведома пользователя, необходимо запустить редактор реестра: для этого откройте Пуск, введите regedit и нажмите Enter.
Перейдите к ключу:
\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager
Там необходимо дважды щелкнуть по SilentInstalledAppsEnabled и установить значение 0.
Эта несложная операция позволит вам запретить установку приложений без ведома пользователя.
Автор: Владимир Безмалый
Быть, а не казаться
Конкурентная разведка в Uber – игры в спецслужбы могут плохо закончиться для таксистов
Не успел утихнуть шум по поводу утечки 57 млн. данных клиентов и водителей Uber, как компанию догоняет совершенно новый скандал.
Много лет подряд Uber систематически собирали данные конкурирующих компаний по всему миру, включая информацию об их технологиях, водителях и руководстве. Uber использовали автоматизированные системы сбора и обработки данных, накапливая миллионы записей и иногда проводя физическое наблюдение в дополнение к сбору данных.
Усилия Uber в этом направлении возглавляла группа рыночной аналитики (Marketplace Analytics — MA), в то время как группа стратегических служб (Strategic Services Group — SSG) собирала информацию для целей безопасности. Это стало известно от трех человек, знакомых с операциями этих команд, из судебных показаний и внутренних документов Uber.
Сбор информации продолжался до сентября этого года, пока судебные разбирательства и многочисленные федеральные расследования не положили конец этой практике.
MA также собирала информацию о конкурентах Uber за пределами США для продвижения Uber на этих рынках.
Официально, миссия SSG состояла в том, чтобы защищать сотрудников, руководителей и водителей от насилия, что иногда включало отслеживание протестующих, которые считались угрозой для Uber.
Для хищения секретов других компаний, сотрудники MA и SSG использовали секретные серверы, устройства, связь которых с Uber отследить было невозможно, защищенные службы обмена сообщениями и физическое наблюдение.
Вполне возможно, что сбор данных Uber не нарушал никаких законов США – большая его часть происходила за пределами США, данные часто собирались с публично доступных веб-сайтов и приложений. Однако, работа групп MA и SSG привлекла внимание федеральных следователей и председательствующего судьи в ходе расследования кражи коммерческой тайны.
Работа MA и SSG была освещена в рамках подготовки судебного процесса Waymo против Uber, в котором утверждалось, что Uber похитил коммерческие секреты компании, разрабатывающей беспилотные автомобили для использования в своих собственных беспилотных автомобилях.
В двух письмах, написанных ранее в этом году, Ричард Джейкобс (Richard Jacobs), бывший сотрудник Uber, обвинил компанию в использовании своих подразделений промышленного шпионажа для кражи коммерческой тайны у Waymo и других компаний. Эти письма и показания Джейкобса стали основой в судебном процессе.
Из слов Джейкобса стало известно, что инженер Энтони Левандовски (Anthony Levandowski) за день до увольнения из Waymo, скачал себе 14000 файлов технической документации, составляющей коммерческую тайну компании Waymo и передал эти файлы компании Otto, которую позже купил Uber.
Судебный процесс, первоначально запланированный на начало этого месяца, был отложен до февраля 2018 года, чтобы позволить Waymo расследовать факты, изложенные Джейкобсом.
Команда MA возникла на базе предыдущей группы в Uber, которая была известна как Competitive Intelligence, или COIN.
COIN также создавала не связанные с Uber серверы для хранения информации о конкурентах и контролировала Hell — программу Uber, используемую для отслеживания водителей конкурирующей компании Lyft. Uber собирали данные о водителях прямо из приложения Lyft и предлагали им переключиться на Uber.
COIN использовала сервер Amazon, который, согласно данным домена, был зарегистрирован инженером Uber в марте 2015 года, используя свой личный адрес и номер телефона (то есть формально сервер не был связан с компанией Uber). По словам источников, секретный сервер, используемый COIN, был закрыт в конце 2016 года, и команда начала разрабатывать новую, более сложную инфраструктуру под новым кодовым именем.
По мере роста, команда COIN из примерно дюжины программистов и аналитиков была объединена в группу MA, в то время как ее нетехническое подразделение, SSG, было доукомплектовано несколькими бывшими государственными служащими.
Аналитики MA начали сосредотачивать свои усилия исключительно на зарубежных конкурентах
MA провели тщательное исследование нескольких зарубежных конкурентов Uber, в том числе Ola, крупной платформы в Индии, и Didi Chuxing, конкурент Uber в Китае, которая выкупила бизнес Uber в стране.
Вся информация, собранная о конкурентах, хранилась на безопасном сервере, отделенном от корпоративной инфраструктуры Uber и скрытом от большинства сотрудников компании. Сотрудники группы MA использовали отдельные компьютеры исключительно для доступа к этому серверу, чтобы данные об устройствах не могли быть официально прослежены до Uber. Они также использовали приложения Wickr и Telegram для обмена шифрованными сообщениями друг с другом.
Многое из этого, вероятно, никогда бы не всплыло, если бы Энтони Левандовски не скачал себе служебные документы Waymo и позже не передал их своему новому работодателю.
Вопрос. Как смог сотрудник скачать эти документы? Неужели в компании никто не отслеживал какие данные сотрудники скачивают? Или в компании отсутствует DLP-система и непонятно чем занимается служба безопасности?
Автор: Владимир Безмалый
Встроенные в Windows 10 сторонние приложения угрожают безопасности данных
Функция Content Delivery Manager без разрешения пользователя устанавливает на систему уязвимые приложения.
Исследователь безопасности из команды Google Project Zero Тэвис Орманди (Tavis Ormandy) обнаружил в Windows 10 предустановленный сторонний менеджер паролей Keeper, позволяющий удаленно похищать хранящиеся в нем учетные данные. Начиная с Windows 10 Anniversary Update (версия 1607), Microsoft добавила в свою ОС новую функцию под названием Content Delivery Manager. Функция автоматически устанавливает на компьютеры «предлагаемые приложения» без разрешения пользователей. Менеджер паролей Keeper был загружен на ПК Орманди с Microsoft Developer Network. Узнав, что сторонние приложения теперь устанавливаются по умолчанию, исследователь решил протестировать Keeper на наличие уязвимостей. Вскоре он обнаружил уязвимость, позволяющую «полностью скомпрометировать безопасность Keeper и предоставляющую любым сайтам возможность похищать любые пароли». Выявленная Орманди уязвимость практически идентична той, которую исследователь обнаружил в невстроенной в Windows 10 версии менеджера еще в августе 2016 года. «Я проверил, и оказалось, в новой версии они делают то же самое. Думаю, с моей стороны является большой щедростью посчитать эту уязвимость новой и подождать 90 дней до ее раскрытия. Я в прямом смысле просто поменял селекторы, и атака снова работает», — сообщил исследователь. Орманди выпустил PoC-эксплоит, позволивший ему похитить из встроенного в Windows 10 менеджера Keeper пароль для авторизации вTwitter. Исследователь сообщил разработчикам приложения о своей находке, и в пятницу, 15 декабря, была выпущена исправленная версия Keeper 1.4.
Ваша приватность умирает красиво, но мы можем спасти её. Присоединяйтесь к нам!