Фактически это технология сводится к анонсированию сетевого адреса, в который резолвится сайт, помещенный в CDN, из этих “географически распределённых мест” и проксированию запросов к условному одному серверу.
Какой профит из этого можно получить?
Размещая данные ближе к клиенту, вы получаете меньшую задержку в ответе для пользователя, сокращаете нагрузку на свой сервер, защита от DDoS… бла-бла-бла - читаем описание любой коммерческой CDN-сети.
Кажется сложным и непонятным? На самом деле это проще чем кажется, ниже всё будет описано более подробно.
Скорость загрузки/сокращение трафика.
Размещая данные ближе к пользователю можно рассчитывать на то, что эти данные он быстрее получит. Логично. Что с сокращением трафика? Кеширование данных на узлах, позволяет сократить число обращений к “главному серверу”. Плюс, мы можем всегда передавать сжатые данные от главного сервера к узлу CDN, в keepalive-соединениях. Можно настроить узел CDN так, чтобы конкурирующий запросы, которые мы кешируем, не выполнялись параллельно. Это тоже позволяет экономить трафик и процессорное время на “главном сервере”. В случае sports.ru это всё в сумме позволяет сократить число запросов и трафик в 3,5 раза к “главному серверу”.
Так же узел CDN является прекрасным местом для размещения DNS-slave сервера. Собственно, по тем же причинам.
Нужно ещё будет как-то проксировать и сохранять ответы приходящих запросов.
Отказоустойчивость будем решать тем фактом, что Proxy и Anycast будем собирать на одном сервере. Если по каким-то причинам он отключится, это никак не повлияет на всю CDN в целом. Естественно, таких серверов должно быть как можно больше;)
А ещё это дело надо правильно настроить, чтобы заставить работать в полною силу. Тюнингу под большие веб-нагрузки и выжиманию всех соков из железа хорошо подходит FreeBSD 9.x. Можно использовать и Linux, но в плане прозрачноcти и простоты настройки, единого типа конфигов в моём личном рейтинге выигрывает FreeBSD
.
Чтобы не повторятся приведу примеры дельных рекомендаций по настройки FreeBSD под аналогичный тип нагрузки:
Или погууглить на соответствующую тему.
Анонсируемую сеть или часть этой сети я предлагаю разместить на интерфейсе локальной петли:
Добавляем строчки в /etc/rc.conf:
ifconfig_lo0_alias0=«inet/32»
ifconfig_lo0_alias1=«inet/32»
И, конечно, не забыть включить маршрутизацию:
Добавляем строчки в /etc/sysctl.conf:
Включаем электронный диск для кеша данных, будем использовать для этого tmpfs:
Добавляем строчки в /boot/loader.conf:
И /etc/fstab:
tmpfs /mnt/tmpfs tmpfs rw,mode=777 0 0
Анонсировать сеть CDN будем через OpenBGP
:
www.freshports.org/net/openbgpd
Он обладает всем необходимым функционалом и просто настраивается. Скупая информация о нём в интернете нивелируется подробным Man-ом. Так же он может интегрироваться с пакетным фильтром PF, если нам захочется использовать его. Вот простой конфиг, который будет делать всё, что необходимо:
/usr/local/etc/bgpd.conf:
AS <номер нашей AS>
router-id
network <анонсируемая сеть>
group «Uplink» {
neighbor <адрес провайдера> {
remote-as
descr «Uplink»
announce self
}
}
deny from any
deny to any
allow from <адрес провайдера>
allow to <адрес провайдера> prefix <анонсируемая сеть>
Перейдём к настройке Nginx . Фактически нам необходимо настроить на Nginx кешируюший статику proxy-сервер c агрегацией и сжатием остальных запросов и кеширумых данных.
Не забываем при сборке Nginx указать сборку с модулем gunzip, для разжимания данных для клиентов, не поддерживающих сжатие.
Nginx.conf:
worker_processes auto;
http {
include mime.types;
proxy_temp_path /mnt/tmpfs/tmp;
proxy_cache_path /mnt/tmpfs/cache/site_cache levels=1:2 keys_zone=site:128m max_size=<размер кеша> inactive=<время, которое хранятся данные а кеше>;
gzip on;
gzip_disable «msie6»;
gzip_comp_level 4;
gzip_types text/plain text/html application/xml application/x-javascript text/javascript text/css application/json text/xml application/rss+xml;
gunzip on;
server {
listen 80 default;
server_name localhost;
location / {
proxy_cache_use_stale updating timeout http_500 http_502 http_504;
proxy_cache site;
proxy_pass frontend;
proxy_http_version 1.1;
}
location ~* \.(3gp|7z|avi|bmp|css|doc|docx|gif|gz|jpg|jpeg|js|mov|mp3|mp4|ogg|png|ppt|pptx|rar|tar|tiff|torrent|ttf|svg|swf|wma|xls|xlsx|xsl|xslt|zip)$ {
proxy_cache_use_stale timeout updating http_500 http_502 http_504;
proxy_cache site;
proxy_cache_key $uri$is_args$args;
proxy_cache_valid <время на которое кешируем статику>;
proxy_pass frontend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
}
}
upstream frontend {
server <адрес фронтенда>;
}
Если по каким-то причинам не нужно кешировать динамические запросы на сайте, выключаем кеширование в секции location /. Раскешировать статические данные можно, изменив в них GET-парамметр, например, указывая номер ревизии.
Bind
.
Тут всё просто, устанавливаем и добавляем строчки в named.conf:
zone «site.ru» {
type slave;
file "/etc/namedb/slave/site.ru";
masters {
;
};
};
Не забываем разрешить скачивание всей DNS-зоны c мастер-сервера.
That’s all! CDN-сервер настроен. Немного будет переделок, если захочется CDN-нить ещё несколько сайтов;)
Теги:
Мы обратились в компанию CDNvideo, когда перед нами встала задача организовать качественную онлайн-трансляцию масштабной бизнес-конференции в СК Олимпийский. Мы ожидали большое количество зрителей в онлайне и хотели минимизировать риски, именно поэтому наш выбор пал на компанию с большим опытом оказания подобных услуг и высокой гарантией качества. К счастью, мы не ошиблись и сделали удачный выбор! Скорость доставки видео-контента, качество картинки и звука были на высоте на протяжении всего мероприятия. Отдельно хочется отметить отзывчивость и клиентоориентированность технической поддержки CDNvideo. По нашей просьбе ребята оперативно, буквально за день до мероприятия подкорректировали дизайн плеера, благодаря чему он вдобавок ко всем своим преимуществам, таким как адаптивность под различные браузеры и мобильные устройства, функция DVR и другие высокотехнологичные опции, еще и идеально вписался в нашу корпоративную стилистику сайта.
Показать полностьюАнастасия Михалко
Работаем с компанией CDNvideo уже более 6 лет (практически с самого основания компании).
С помощью CDNvideo мы транслируем прямой эфир наших телеканалов Шансон ТВ и Страна FM на наших сайтах, в мобильных приложениях (на платформах iOS, Android, Windows Phone) и в приложениях Smart TV. Кроме телеканалов, мы транслируем с помощью CDNvideo Радио Рокс.
В конце 2016 года компания CDNvideo выпустила новый плеер HTML5. С помощью этого плеера мы смогли запустить трансляцию телеканалов в социальной сети ВКонтакте (приложение с трансляцией в наших официальных группах).
Василий Покидько
Шансон ТВ / Страна FM
Для решения наших задач нам нужен был надежный многолетний партнер, который не боится предлагать нестандартные решения в кратчайшие сроки. Компания CDNvideo полностью соответствует этим требованиям. Мы уверены в долгосрочном сотрудничестве.
Показать полностьюАнтон Ламбрианов, директор по маркетингу «АТОМИ РУС»
Начали работать с компанией в 2016 году. В тот момент они нас очень выручили, поскольку в преддверии соревнований мы остались без платформы для трансляции соревнований. И возникла необходимость осуществлять трансляцию через наш сайт http://www.russwimming.ru. CDNvideo нам порекомендовали коллеги, которые уже имели богатый опыт сотрудничества с компанией. Для нас важно было подыскать авторитетную фирму и получить качественные бесперебойные трансляции на регулярной основе.
В процессе подготовки первой трансляции мы получали оперативные, высококвалифицированные, но в тоже время очень понятные для неспециалиста консультации.
Компания очень добросовестная, надежная, инициативная и профессиональная.
Проблемы на первом проекте возникали, но компания была на связи и оперативно исправляла ошибки. В беде не оставили даже в выходные.
Помимо трансляции мы заказали доступ к платформе хранения видеозаписей. И когда у нас по причинам, не зависящим от компании, возникли сложности с передачей диска с видео и его своевременным размещением на портале, CDNvideo помогли найти нам выход из ситуации, предложив в дальнейшем воспользоваться услугой автоматической записи и сохранения трансляции на платформе - таким образом мы получаем готовый файл сразу по окончании онлайн-трансляции на сервере без необходимости дополнительных действий, остается только разместить его коды на сайте. Уже неоднократно воспользовались услугами CDNvideo в организации видеотрансляции, планируем дальнейшее плодотворное сотрудничество!
Александра Некрасова
Всероссийская федерация плавания
Работа в сфере онлайн игр, обязывает предоставлять игровой контент быстро и качественно. Особо ценим скорость реакции технической поддержки и минимальное количество сбоев в работе сети. Наше сотрудничество продолжается более 2 лет, за это время CDNvideo показала себя как надежный партнер.
Показать полностьюВ определенный момент времени, аудитория нашего сайта и нагрузка на сайт стала настолько большой, что наш хостинг-провайдер просто перестал с ней справляться. Сайт зависал, служба поддержки отвечала с очень большой задержкой и все общение проходило только через тикеты. Ответы на вопросы приходили спустя несколько часов, что для нас было критичным. В итоге нами было принято решение воспользоваться услугами компании GPUCloud. В первую очередь очень приятное впечатление произвела служба технической поддержки, которая помогла перенести сайт с одного хостинга на другой без лишних проблем. Сегодня сайт работает стабильно, отлично справляется с нагрузкой, а служба поддержки в случае возникновения вопросов доступна 24/7 в Telegram. Ценовая политика компании, в целом, не сильно отличается от средней по рынку, но качество услуг, на наш взгляд выше, чем у конкурентов.
Показать полностьюНациональная Футбольная Лига
Каждому блоггеру и веб-мастеру нужно, чтобы их сайт или блог грузился быстро. Ведь большинство пользователей Интернета ненавидят медленные блоги, если блог медленно грузит, человек его просто закроет и пойдет дальше. Обычно пользователи WordPress используют много различных плагинов для ускорения своих блогов. Но неужели достаточно только одних плагинов для ускорения нашего блога? Конечно, нет! Есть также много других способов ускорить блог на WordPress, сжатие css и js, оптимизация базы данных, оптимизация картинок и т.д.
Но самым главным способом ускорения блога является использование Content Delivery Network (CDN) в своем блоге, что в переводи на русский, сеть доставки контента. А ведь большинство новичков блоггеров не знаю, что такое CDN .
Когда я начинал свою карьеру блоггера и прочел несколько статей относительно CDN, так как он использовался для ускорения блогов. Я подумал, что CDN является какой-то компанией, которая предоставляет людям быстрый хостинг. Но уже позже, провидя надлежащее исследование в области CDN, наконец, я узнал и понял, что такое CDN и как он работает. В этой статье я четко расскажу вам, что такое CDN и преимущества использования CDN в блогах и сайтах .
CDN означает сеть доставки контента или сеть дистрибуции контента, который используется для того, чтобы ускорить время загрузки вашего сайта или блога.
CDN является сетью различных серверов, которые используется для размещения статического контента, например, изображений, Flash файлов, видео и тематических файлов, таких как CSS, Javascripts и т.д., они поставляют это содержимое в кэше для пользователей со своих серверов на основе местонахождения пользователей.
Блоги/сайты не использующей CDN (сеть доставки контента):
Блоги/сайты использующий CDN (сеть доставки контента):
Чтобы вы все четко поняли, я постараюсь объяснить это по-простому. Когда пользователи будут, заходит на ваш блог, их будет перенаправлять на главный сервер, где будут находиться ваши файлы. Соответственно теперь каждый пользователь, который будет, заходит на ваш блог будет получать доступа к блогу только с одного сервера, т.е. с вашего главного сервера.
Когда на ваш блог поступает огромное количество трафика и основной сервер получает тяжелую нагрузку, то, что происходит с вашем блогам? Ваш блог может замедлиться или же ваш главный сервер просто поломается. Когда ваш основной сервер повредится, вам придется восстановить блог с помощью резервных копий данных, а затем вам нужно будет обновить ваш хостинг, который стоит немало денег.
В этой ситуации CDN (сеть доставки контента) поможет вам. Как мы уже говорили выше, CDN является сетью различных серверов, которые могут быть сконфигурированы в различных местах по всему миру. Он хранит статические файлы вашего блога, как изображения, видео, темы файлы и т.д. Он поддерживает копии ваших файлов размещенных на их различных точках с добавлением к основной сети быстрой доставки.
Например, когда пользователь заходит на ваш блог с Ямайки, то его перенаправляет к ближайшему серверу, на котором хранятся ваши кэшированные файлы. То есть, используя CDN в блоге, вы будет уменьшать загрузку на основной сервер, и ускорять время загрузки своего блога.
Итак, я думаю, что вы полностью поняли, чем является CDN, ниже я перечислю преимущества использования CDN .
Ускорьте время загрузки:
Используя сеть доставки контента в блоге, вы уменьшите время загрузки своего блога и скорость загрузки страниц в блоге. Большинство пользователей любят блоги, которые грузятся быстро, а не медленно, следовательно, отсюда трафик вашего блога будет в норме.
Ранжирование:
Google уже давно говорил, что время загрузки страниц в блоге является одним из лучших поисковых фактором ранжирования. Собственно, используя CDN, ваш блог будет на ранг выше остальных в поисковых системах, и это также поможет вам уменьшить показатели отказов.
Нереальный трафик:
Как мы уже говорили выше, когда на ваш блог поступает огромное количество трафика, это создает большую нагрузку на основной сервер и может замедлить, или вовсе поломает ваш главный сервер. Но CDN может обрабатывать огромное количество трафика, и сводит к минимуму время простоя сервера и ошибок. Это может спасти вам деньги, которые вы тратите на смену хостинга.
Выводы:
Используя CDN (сеть доставки контента) , время загрузки вашего блога улучшится и нагрузка на ваш основной веб-сервер уменьшится. Ваш блог никогда не будет выходить из строя, так как статические файлы вашего блога будут размещаться на различных серверах, и если один сервер перестанет работать, то файлы будут доставляться с другого сервера. Производительность вашего сайта улучшится и, следовательно, увеличиться трафик вашего блога.
Улучшите два критически важных показателя вашего сайта - производительность и защищенность, воспользовавшись подходящей сетью доставки контента.
Вряд ли кому-то нравится низкая скорость загрузки веб-страниц, которая может стоить миллионы из-за упущенных продаж. Факты говорят сами за себя:
Некоторые из следующих возможностей, предлагаемых Cloudflare, доступны бесплатно:
В случае, если безопасность имеет высокий приоритет, имеет смысл задуматься о тарифе PRO или еще более расширенной версии, в которых будет доступен файрвол для приложений , оптимизация изображений, оптимизация для мобильных устройств и многое другое.
Стоит отметить работу с приложениями Cloudflare. Она позволяет легко реализовать те или иные функции без дополнительной установки. Например, можно пользоваться Google Analytics, Pingdom Swiftype не внося изменений в код.
Кто пользуется Cloudflare?
Диаграмма показывает популярность Cloudflare (прим.пер.: доля рынка Cloudflare среди миллиона самых популярных сайтов по версии Alexa составляет 78.61% ). К самым именитым клиентам относятся:
В двух словах - Datapath оптимизирует трафик и сокращает время ожидания AWS.
В бесплатной версии доступны:
Ярослав Городецкий: Итак, меня зовут Ярослав Городецкий. Я представляю компанию CDNvideo. Мой доклад называется «Как мы строим CDN в России».
Что такое CDN?
CDN расшифровывается как Content Delivery Network (сеть доставки контента). Она используется для того, чтобы раздавать контент большому числу пользователей, находящихся в разных городах, в разных странах, на разных континентах, быстро и более качественно, чем если бы контент раздавался из одной точки. Это территориально-распределенная сеть серверов.
Конференция посвящена высоконагруженным приложениям. Поэтому в терминологии трехзвенной архитектуры HighLoad CDN соответствует уровню серверов front-end - серверов, с которых контент раздается конечному пользователю.
Сети доставки контента могут быть частными. У крупных контент-провайдеров (таких, как Google, Yandex, Mail.Ru, Facebook, VKontakte), как правило, есть собственные CDN, которые служат только для распространения контента этих крупных контент-провайдеров.
Также в мире и в России есть операторы CDN, которые построили свои собственные CDN и предоставляют свои ресурсы в пользование всем желающим.
Как работает CDN?
Наверное, многие и так это знают, но все-таки повторим основы.
Вам хочется, чтобы ваш контент доставлялся пользователям из разных городов как можно быстрее. Вы или сами строите сеть доставки контента, или покупаете услуги CDN у оператора. Вы используете серверы, которые находятся во всех крупных городах и подключены к Сети крупными интернет-провайдерами, и размещаете там свой контент.
Если пользователь обращается за вашим контентом на ваш сервер, то ответ он получит уже от ближайшего к нему сервера сети CDN, а не от того сервера, который стоит в централизованном дата-центре.
Как воспользоваться CDN?
Сначала вы выстраиваете взаимодействие с CDN-провайдером. Доставлять через сеть CDN можно видеоконтент, данные, статический веб-контент, любые приложения, дистрибутивы приложений и так далее. Этот контент распространяется по всем серверам CDN и отдается конечным пользователям.
Для распространения контента внутри сетей CDN и для забора контента от контент-провайдера, как правило, используется протокол HTTP. На самом деле, все эти сервера являются кэширующими HTTP-серверами. Для потокового видео используются протоколы RTMP/RTSP и другие подобные протоколы, обеспечивающие потоковую передачу данных (англ. Streaming).
CDN - это просто инструмент, который можно использовать для раздачи потокового видео, аудио или статического контента по протоколу HTTP в своем веб-сервисе или приложении.
Услуги операторов CDN позволяют получить доступ к большому количеству серверов, установленных в разных точках и, таким образом, сделать возможной реализацию высоконагруженных и отказоустойчивых сервисов меньшими силами, чем если бы вы сами расставляли сервера по всему миру.
Как правило, CDN используется для раздачи «тяжелого» контента (видео, аудио, фотографий, flash-анимации, CSS/JavaScript, клиентов игр и так далее).
В одном из сегодняшних докладов говорили о том, что CSS/JavaScript можно ужать на 40-50%. Это и в самом деле актуальная проблема. Для стабильной работы веб-сервисов требуется быстрая отдача CSS/JavaScript конечным пользователям. Можно ужимать, а можно использовать CDN для повышения скорости отдачи CSS/JavaScript конечным пользователям.
Как строить CDN?
Давайте более детально поговорим о том, как можно строить CDN, как мы это делаем и почему мы делаем именно так.
Сетей CDN в мире достаточно много. Тема CDN развивается с 1998-го года, когда появился один из первых высоконагруженных сайтов - CNN. Наверное, это один из первых высоконагруженных сайтов, который не принадлежал технологической компании. На тот момент нагруженные сайты были у Microsoft и у поисковых систем.
Появился контент-провайдер телеканала CNN, которому нужно было раздавать много контента, чтобы его сайт быстро грузился в разных точках мира. Но собственной технологии у него не было.
Тогда появилась компания Akamai, которая решила эту проблему за CNN, расставив серверы по всему миру.
Какими бывают CDN?
Они различаются:
Как расставить серверы сети CDN таким образом, чтобы обеспечить наилучшее среднее качество для всех пользователей?
Понятно, что если у вас есть интернет-ресурс с определенной аудиторией, эта аудитория как-то географически распределена, а у вас ограничен бюджет на серверы. Перед вами стоит задача: как именно расставить эти серверы по сети Интернет, чтобы получилось оптимальное качество в среднем для всех ваших пользователей. Если у вас российский ресурс, вам, скорее всего, не нужно ставить сервер где-нибудь в Австралии, потому что посетителей из Австралии, скорее всего, будет мало.
Что такое Интернет с точки зрения интернет-провайдеров, а не обывателя? Обычный человек полагает, что Интернет - это "облако". На самом деле, часть Интернета - это граф связанности нескольких интернет-провайдеров (российских и зарубежных). Я взял эти данные с очень хорошего ресурса rolltex.com, где можно для каждого интернет-провайдера получить такую карту связанности.
Когда вы строите CDN, вам нужно понять, где именно, у каких провайдеров есть ваши пользователи, и поставить туда свои серверы. Это один подход. Его использовала, в частности, компания Akamai. Этот же подход используем в своей деятельности мы.
Есть и другой вариант. Провайдеры, как правило, обмениваются между собой трафиком через Internet Exchange. Это точки бесплатного обмена трафиком. Их достаточно много в Европе. В Штатах их мало, потому что там обмен трафиком, в основном, платный. В России точки бесплатного обмена развиваются с переменным успехом. Московский Internet Exchange достаточно большой. Питерский Internet Exchange раз в 10 меньше московского.
Таким образом строит свои сети CDN ряд других провайдеров. Среди них - LimeLight (это основной западный конкурент Akamai) и российский интернет-провайдер NGENIX. Этот подход хорош тем, что вроде бы можно охватить большее количество провайдеров с одного узла. Но есть определенная проблема - такой подход требует достаточно приличных затрат на сетевое оборудование.
Третий подход. Если вы представляете магистрального оператора связи, то вы тоже можете построить сеть CDN. Чтобы получить CDN, по разным точкам сети нужно расставить серверы, но при этом в каких-то точках вы покупаете трафик, в каких-то - продаете.
У вас сразу возникнет проблема. Ваша непосредственная деятельность как магистрального провайдера может конфликтовать с целями вас как CDN-оператора, потому что CDN-оператору требуется отдавать трафик всем всегда и как можно больше. Магистральному оператору, наоборот, хочется чаще продавать этот трафик за деньги.
Теперь поговорим о классификации CDN по способам распределения нагрузки. Их несколько.
Наиболее часто используемый - это балансировка нагрузки при DNS-запросе. Пользователь направляет DNS-запрос на CDN с каким-то заданным именем. CDN отдает IP-адрес в ответ на запрос того сервера, который ближе к пользователю.
Есть и другой вариант, который используют российские частные CDN. HTTP-редирект. В ответ на HTTP-запрос какому-то стандартному имени выдается ошибка 304, и запрос перенаправляется на тот или иной сервер, который ближе к пользователю.
Есть еще пара способов. Подстановка URL при генерации HTML-страницы. Есть такой способ, как Anycast, когда ответы посылаются на ближайший сервер. У всех серверов один и тот же IP-адрес. Грубо говоря, какой сервер получил запрос первым, тот и ответит на этот запрос.
Какой из этих способов лучше?
DNS используют почти все. Тем не менее, у него есть одна существенная проблема. Есть пользователи, которые пользуются чужими DNS (например, Google DNS 8888). Для них балансировка нагрузки вообще не будет работать. Они будут перенаправляться на тот сервер, который находится ближе к Google, а не к их интернет-провайдеру. В результате выигрыша от использования CDN они не получат. По нашим данным, местоположение около 10% запросов определяется неправильно.
HTTP-редирект такой проблемы не создает, но зато он предполагает другую проблему. У него увеличивается время ответа, потому что происходит допольнительный HTTP-запрос - соответственно, есть лишняя установка TCP-соединения. Время ответа занимает несколько десятков миллисекунд, в лучшем случае.
Подстановка URL требует много серверных ресурсов. Anycast не всегда правильно работает с TCP, потому что при каких-то сетевых изменениях реальный сервер, который находится ближе, может поменяться.
Другой способ классификации CDN - по тому, как распространяется контент внутри самой сети CDN.
Крупные CDN используют иерархическое дерево. У них есть какое-то центральное хранилище контента, есть какие-то крупные региональные хранилища контента и есть более мелкие хранилища, которые находятся у конечных операторов, у региональных операторов связи.
Для небольших CDN такое иерархическое дерево строить не нужно. Достаточно схемы "точка-многоточка". Один источник контента распределяет свой контент на все остальные сервера. В схеме необязательно должен быть один центр, чтобы остальные "заливали" на него. В принципе, центром может быть любой сервис CDN, который ближе к источнику контента.
Последний вариант - одноранговая сеть (англ. peer-to-peer, P2P). Распространение контента в CDN осуществляется по принципу P2P. Серверы загружают контент друг другу, аналогично тому, как это делается в торрентах.
Такой способ использует одна известная академическая CDN (Coral CDN), а также некоторые провайдеры потокового вещания в интернет, те, кто делает возможной видеотрансляцию для большого числа пользователей. Пользователи перенаправляют запросы и тоже участвуют в распространении видеоконтента.
На западе есть компания Octoshape, которая этим занимается. В России примером такой компании можно назвать Lavina.TV.
Предпоследнее, о чем я буду говорить, это классификация по способу, которым определяется кратчайший путь до пользователя. Здесь также несколько способов.
Первый способ - по географии. Самый понятный, интуитивный способ. У нас есть сеть CDN. Например, можно поставить сервер в Новосибирске, и все пользователи из Новосибирска по этой GeoIP-базе направляются на этот новосибирский сервер.
Но, к сожалению, такой подход не работает в большинстве случаев. Многие интернет-провайдеры имеют между собой сложные взаимоотношения, между ними идут так называемые "пиринговые войны". Очень часто бывает так, что провайдеры из одного и того же города "тянут" трафик через другой город (а то и через другую страну) между собой.
Таким образом, не очень хорошо определять путь до конечного пользователя по географическому принципу. Лучше использовать метод определения кратчайшего пути на основании данных о сетевой топологии.
Это могут быть BGP-маршруты, если у вас есть возможность получать их в режиме реального времени от интернет-провайдеров.
Это может быть база данных RIPE. Она не в реальном времени, но в эту базу данных все провайдеры должны вносить те сети, те маршруты и пиринговые отношения, которые они имеют. Из этой базы данных можно вынести обширные познания о топологии сетей.
Если вы работаете с региональными провайдерами (в России, по крайней мере), как правило, у всех них есть некая база данных локальных адресов, которую они ведут. Это тоже полезная вещь.
Последний вариант - определение кратчайшего пути до пользователя по интегральным метрикам, которые связаны с сетевыми задержками, с количеством хопов до пользователя, с количеством автономных систем на пути до пользователя. Это тоже правильный способ, он помогает находить кратчайший путь. Даже если вы знаете, что есть несколько маршрутов до того или иного пользователя от разных ваших серверов, не всегда кратчайший маршрут, который вы получили из BGP, реально имеет наилучшую пропускную способность, наилучшие сетевые параметры.
Как мы строим CDN?
Теперь я расскажу о нашем опыте построения сети CDN. Мы находимся в России, хотя работаем и в СНГ, и за его пределами. Но наша основная цель - построить CDN для русскоязычного интернета. У российского интернета есть ряд особенностей. Они перечислены на слайде, не будем их зачитывать.
Суть в том, что в России много провайдеров, при этом трафик достаточно сильно сконцентрирован в Москве. Провайдеры не любят друг друга и ведут "пиринговые войны". Наша особенность: помимо сетевых параметров, дополнительно надо учитывать стоимость трафика для конечного пользователя. Где-то он до сих пор не бесплатен, безлимитные тарифы все еще есть не везде.
Исходя из всех вышеперечисленных причин, мы избрали свой способ построения CDN (он описан на слайде). Сеть CDN строится на сетях интернет-провайдеров с использованием DNS, для нахождения кратчайшего пути до пользователя применяются данные о сетевой топологии и интегральные метрики.
Теперь я скажу несколько слов о том, какие услуги предоставляют CDN-провайдеры.
Это кэширование HTTP-контента:
Потоковое вещание видео/аудио:
Также CDN может предлагать услуги по защите контента. Можно ограничить доступ контенту, предоставляя его только тем пользователям, которые авторизованы данным провайдером. Здесь используются одноразовые ссылки на контент, можно делать авторизацию каждого запроса на стороне контент-провайдера. Только для flash-видео можно также подписывать flash-плеер и, соответственно, давать доступ только тем, кто имеет flash-плеер, загруженный с сайта контент-провайдера.
Как правило, в CDN есть интерфейс программирования приложений (API) для управления услугами, которые позволяют очистить кэш для статического контента при списании этого контента. Например, нужно срочно удалить файл с сайта, а если он уже попал в CDN, то, соответственно, со всех CDN-серверов. Также можно посмотреть статус услуги (сколько у того или иного видеопотока просмотров, сколько его просматривали раньше), проверить, не близок ли порог возможности CDN.
Мы составили памятку касательно того, как подключиться к CDN. Это общие рекомендации для всех CDN-провайдеров.
На этом все. Спасибо за внимание! Жду ваших вопросов.
Вопросы и ответы
Вопрос из зала: Вопрос относительно отказоутойчивости. Предположим, что один из серверов CDN по каким-то причинам "умер". Вы маршрутизируете посредством DNS. DNS-запросы кэшируются у пользователей, они никак не могут узнать, что надо "ходить" уже в другое место. Как вы это решаете? Ярослав Городецкий: Если объем кэширования равен нулю, например. Тогда, соответственно, время на кэширование DNS равно нулю. Пользователь не будет кэшировать данные от DNS. Вопрос из зала: Это создает какие-то задержки - небольшие, но лишний запрос каждый раз. Ярослав Городецкий: Да. Но поскольку серверы расположены близко к пользователям, задержка минимальна. Вопрос из зала: Представьте, что у меня очень много контента (миллиард файлов) с каким-то очень длинным "хвостом", на который редко идут запросы. Как обычно раскладывается контент по CDN? Я как владелец контента говорю: «Разложите все мои файлы» - или это делается по запросу от пользователя? Пользователь пришел на сервер, там увидели, что файла нет, сходили ко мне, забрали, отдали пользователю. Ярослав Городецкий: Вообще CDN больше предназначена не для "длинного хвоста", а для популярного контента, на который много раз идет запрос от пользователя. Поэтому по умолчанию используется по запросу. Есть необходимость показать тот или иной контент пользователю - только тогда этот контент забирается с сервера контент-провайдера, и все следующие запросы идут сразу уже с CDN. В принципе, возможен и вариант, когда вся библиотека контента сначала загружается в CDN. Это больше для «тяжелого» контента, если нужно библиотеку фильмов, например, показывать. Фильмы загружаются долго. В стандартном варианте делается взаимодействие по запросам. Вопрос из зала: Большинство хостингов в России предоставляет бесплатный трафик. Почему в российских CDN надо платить за трафик? Можно по тем же самым городам сделать его бесплатным. Ярослав Городецкий: Вы про нас говорите? Вопрос из зала: И про вас тоже. Ярослав Городецкий: Надо за что-то платить. Самый простой честный способ посчитать затраты CDN на то, что этот трафик берется из одного места, доводится по всем серверам и дальше раздается с разных серверов географически распределенных, - это тарифицировать по трафику. Но, в принципе, мы предлагаем и другие варианты. Для распределения потокового видео у нас есть фиксированные тарифы по количеству одновременных подключений. Тогда это бесплатно. Вопрос из зала: Вопрос по поводу того, что построено у нас. Спрошу как человек, которому знакома тема видео. Какова скорость забора информации от клиента. Если я клиент CDN, и у меня есть видеофайл, насколько быстро вы можете его доставить через себя к абонентам? Второй вопрос. Какая сеть на данный момент имеется? Какая география, мощность? Ярослав Городецкий: Первый вопрос. Это во многом зависит от ширины вашего канала. У нас достаточно широкие каналы. Мы делаем в виде трансляций, каких-то мероприятий. Там это проблема. Чтобы показывать видеопоток в хорошем качестве, нам нужно, чтобы у контент-провайдера, который транслирует мероприятие, был достаточно приличный канал в Интернете, и при этом хорошего качества. По географии. У нас сейчас сеть развивается, к концу года будет 7 городов. Сейчас - Москва, Питер, Екатеринбург, Новосибирск, Киев, Западная Европа. Вопрос из зала: Как быстро вы сможете среагировать, если мы скажем, что у нас будет серьезная нагрузка. Вы сможете расширить возможности для наших требований? Ярослав Городецкий: В принципе, мы не лимитируем. Конечно, да, все возможно. Вопрос из зала: Сколько - месяц, два? Ярослав Городецкий: Меньше месяца. Вопрос из зала: Не совсем удобно, что Akamai можно использовать по всему миру, а в России надо идти в вашу сеть. Как можно решить эту проблему? Существует ли возможность интеграции? Ярослав Городецкий: Да, да, существует. Подходите, в кулуарах я вам расскажу об этом.
