Lev Walkin (lionet) wrote,
Lev Walkin
lionet

Category:

Про CDN

Навеяно постом про самопальный СНГовый «гео-хостинг» на хабре: http://habrahabr.ru/company/hostpro/blog/106944/

Что такое Content Delivery Network?


CDN — это прежде всего сервис оптимизации производительности интернет-сайтов (e.g. apple.com) и приложений (e.g. ecwid.com) путём расположения некоторых видов ресурсов ближе всего к конечному пользователю. На этом рынке играют множество игроков, самыми известными из которых являются Akamai, Amazon CF, LimeLight.

CDN предложения отличаются по цене, по фичам, по способу обеспечения производительности.

В простейшем случае на CDN возлагают достаточно банальную задачу: хостинг статической информации. Например, js-скрипты, картинки и даже многие статические HTML-страницы можно безболезненно перетащить на любой CDN. Таким образом, человек, зашедший на оптимизированный с использованием CDN сайт, на самом деле с самого сайта будет тащить только динамические ответы, а ссылки на встроенные изображения, скрипты и другие ресурсы будут показывать на URL, ассоциированный с каким-либо CDN'ом.

Взять, к примеру, сайт Apple.com, как вопиющий представитель оптимизированности с использованием CDN-партнёра. Если мы внимательно посмотрим на то, куда нас посылает DNS по запросу www.apple.com, мы увидим следующее:
# dig www.apple.com
www.apple.com.          1657    IN      CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 60 IN     CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21465 IN     CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 20      IN      A       96.6.237.15


Видно, что мы попадаем не в Apple, а в Akamai, откуда грузится статический HTML заглавной страницы. То же самое касается изображений, встроенных на заглавную страницу: они грузятся с домена images.apple.com, который тоже разрешается DNS'ом в один из IP адресов, контролируемых Akamai. Таким образом, практически весь трафик, идущий в браузер с первой страницы Apple, на самом деле идёт в браузер от Akamai.

Зачем это нужно Apple?


Компания, заказывающая CDN, хочет убить одного или двух зайцев:
  1. Сэкономить на логистике поддержания и развития оборудования для своего дата-центра. Одно дело — заботиться о масштабировании базы данных и о логике приложения, а другое — иметь в штате специалистов, бюджет и план развития фермы серверов, которые ничем кроме как отдачей картинок не занимаются. В структуре планирования такие статические вещи могут занимать десятки процентов внимания. В случае, например, крупных порносайтов, организация отдачи статического контента может приближаться к ста процентам от всех организационных затрат.
  2. Сэкономить на стоимости трафика. CDN покупает большое количество толстых каналов у крупных поставщиков, и поэтому в действие вступает economy of scale. Например, покупая трафик по $1 за мегабит в секунду, CDN'у, чтобы предложить цену, сравнимую или дешевле цен IP-провайдеров, нужно предложить трафик клиенту за $10-15-20/mbps. На эти два процента и живут, причём часто клиенту это может выйти дешевле, чем покупать трафик непосредственно для своего хостинга.
  3. Самое главное предложение CDN — это оптимизация быстродействия сайта с точки зрения конечного пользователя. Когда пользователь делает DNS запрос на apple.com, то, после нескольких DNS-пинг-понгов с акамаевскими серверами, клиенту выдаётся IP-адрес ближайшего к клиенту сервера. В моём случае пинг из Нью-Йоркского датацентра до apple.com (без CDN) — 84ms, а пинг до www.apple.com (идёт через Akamai) — 0.5ms. Если учесть что в TCP есть slow-start и распространены маленькие окошки, то для загрузки одной страницы среднего размера нужно 10-30 RTT. Для задержки 84ms это уже одна-три секунды на открытие страницы независимо от толщины клиентского канала.


Некоторые клиенты, приходящие к CDN, хотят убить только одного из вышеуказанных зайцев. Например, третьего — оптимизировать быстродействие сайта для конечных пользователей. Это даёт возможность CDN'ам "умалчивать" о структуре стоимости их решения и брать неимоверные суммы денег с клиентов. В начале века я слышал о $6000 за один мегабит в секунду, и нет, это был не дорогущий Akamai.

Как CDN размещает данные ближе к пользователю?


У CDN'ов есть много точек присутствия в США а также в разных регионах мира. Одна точка присутствия — это обычно набор серверов (стойка-две-двадцать), на которых размещается пользовательский контент. Есть несколько способов обеспечения "свежести" контента:
1. Клиент периодически заливает куда-то новый контент с помощью REST/SOAP API или FTP/SCP/rsync/etc, а дальше он разъезжается по разным точкам присутствия. В случае Amazon CloudFront контент можно залить в какой-то центральный букет Amazon S3, и он начнёт быть доступным везде.
2. CDN является таким мега-кэшом (типа nginx или squid), который отдаёт кешированный контент, а когда тот протухает, то тянет контент с какого-то клиентского сервера. Про некоторые CDN известно, что там реально стоит модифицированный squid или подобное опенсорсное решение.
3. Есть специальный API, которому можно сказать что такой-то контент "протух" (по regexp), и его нужно забрать с предопределённого домена.

Как CDN направляет пользователя к ближайшей к нему точке присутствия?


Сначала сразу скажу, что использование GeoIP — это курам на смех. GeoIP — это детектирования географического местоположения пользователя по его IP. GeoIP можно использовать с переменным успехом когда у тебя есть две-три точки присутствия, например, когда одна в Штатах, другая в Европе, а третья — в Китае. Если нужна большая гранулярность, GeoIP не подходит, так как нужно определять топологическую близость, а не географическую. Например, два провайдера в Ульяновске могут не разговаривать между собой, а общаться через Москву. Потому определения того, что клиент находится в Ульяновске, совсем недостаточно, надо ещё знать, к какому провайдеру абонент подключен, а также связи провайдеров между собой. При наличии же информации о топологическом расположении абонентов, пользователи будут направлены через DNS к тому CDN-серверу, котрый доступен им с наименьшей стоимостью (выраженной в сетевых задержках — RTT), а не географической близостью.

Таким образом, каждому CDN необходимо иметь базу данных топологической близости его клиентов. Из-за специфики задачи (немногим пригодится база близости к нодам Akamai, например, хотя GeoIP нужна всем, особенно порнограферам) такие базы собираются самими CDN компаниями, и в свободном обращении не крутятся.

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

Когда к DNS серверу CDN приходит запрос от клиента (провайдера), то DNS-сервером производится запрос в топологическую базу данных. Если в базе есть информация для запрашивающего IP или для /25-окрестности от него, то в DNS-ответе содержится адрес ближайшего к клиенту CDN сервера, профильтрованный картой доступности серверов (вдруг ближайший сервер вышел из строя). Если же в базе информации нет, то отвечается "чем нибудь", а параллельно ставятся в очередь на обработку "пинги" IP адреса DNS-клиента ото всех точек присутствия CDN.

В каждой точке присутствия CDN стоит prober, который может определять RTT до данного IP адреса несколькими способами одновременно: IP, UDP(:53), ICMP, TCP(SYN/ACK/RST). Работает он примерно как traceroute, то есть, если конечный пункт был недоступен, как это часто бывает, берётся результат измерения RTT, который наиболее близок к конечному пункту. Часто ICMP на последних милях запрещён, но из-за специфики работы DNS (провайдер выступает как прокси для своих клиентов) вместо ICMP можно посылать UDP/DNS пакеты на 53 порт того, кто производит запрос. Результаты измерения пробером стекаются в базу, которая присутствует на каждом DNS сервере CDN. Через несколько месяцев работы база из нескольких миллионов записей содержит информацию о том, какие /25 префиксы нужно посылать в какие точки присутствия CDN. База непрерывно обновляется.

Но ведь есть же BGP Anycast...


BGP Anycast для TCP работает хреново. Можно сказать, на практике не работает, особенно если клиент находится где-то в хорошо соединённом месте: флуктуации BGP connectivity делают так, что пакеты, которые шли в одно место, иной раз начинают роутится в другое и, естественно, соединения завершаются с RST посередине передачи данных. Если вы хотите использовать BGP Anycast для TCP — подумайте о том, какое SLA вы хотите дать своим бедным пользователям.
http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-anycast.pdf

Другие услуги CDN


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

Akamai, например, предлагает EdgeSuite — возможность хостить какие-то нетривиальные приложения на серверах поближе к пользователю. Детали того, как они синхронизируют данные при этом, мне неизвестны.

Противоположное решение было изобретено Netli: вместо того, чтобы переносить логику приложений на края сети (edges), предлагалось, что своей активной логикой должен заведовать сам клиент CDN (имеется ввиду тот, кто покупает CDN, а не конечный пользователь), разрабатывая и разворачивая приложения на своих серверах. При этом конечные клиенты этих приложений идут не напрямую к таким серверам, а всё-же к CDN, который умеет быстро доставлять их до клиента. Изобретение получило акроним ADN (Application Delivery Network, http://www.highbeam.com/doc/1G1-128215864.html) и соответствующие патенты. Суть ADN состоит в том, чтобы предоставить быстрый доступ из разных краёв интернета к приложению, размещённому в единственном месте, централизованно. Вкратце как этого достигнуть: надо устранить TCP slow start и открыть большие TCP окна между сервером CDN, расположенным ближе к клиенту, и комплементарным сервером CDN, расположенным ближе к акселерируемому сайту (идеально — на хостинговой площадке конечного сервера).

Клиент, который запрашивает контент у ADN, направляется к ближайшему ADN серверу через тот же DNS механизм, показанный ранее для CDN. Далее вместо того, чтобы совершать длительные TCP танцы со slow start'ом, ADN сервер запрашивает контент у своего комплементарного сервера, размещённого рядом с конечным сайтом, через специально модифицированный стек TCP, который позволяет передавать данные обычного веб-размера (10-100kb) за 1xRTT вместо 10-30xRTT. Затем этот контент отдаётся клиенту, но вместо 10xBIG_RTT он отдаётся за 10xSMALL_RTT, так как RTT между клиентом и ближайшим к нему сервером меньше, чем RTT между клиентом и конечным сервером.

Список преимуществ у ADN короче, чем у CDN, и сводится только к третьему пункту — ускорение передачи данных конечному пользователю. В тестах на таких клиентах как HP, Dell, решение ADN от Netli ускоряло страницу с 30 секунд до 0.5-1.5 секунд.

На закуску: как ADN может обойти Великий Китайский Файерволл: http://lionet.livejournal.com/28584.html

Примерно так.
Tags: cdn, netli
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 23 comments