Ссылки Артемия Трегубенко о веб-разработке за октябрь 2010
Навеяно постом про самопальный СНГовый «гео-хостинг» на хабре: 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, хочет убить одного или двух зайцев:
- Сэкономить на логистике поддержания и развития оборудования для своего дата-центра. Одно дело — заботиться о масштабировании базы данных и о логике приложения, а другое — иметь в штате специалистов, бюджет и план развития фермы серверов, которые ничем кроме как отдачей картинок не занимаются. В структуре планирования такие статические вещи могут занимать десятки процентов внимания. В случае, например, крупных порносайтов, организация отдачи статического контента может приближаться к ста процентам от всех организационных затрат.
- Сэкономить на стоимости трафика. CDN покупает большое количество толстых каналов у крупных поставщиков, и поэтому в действие вступает economy of scale. Например, покупая трафик по $1 за мегабит в секунду, CDN'у, чтобы предложить цену, сравнимую или дешевле цен IP-провайдеров, нужно предложить трафик клиенту за $10-15-20/mbps. На эти два процента и живут, причём часто клиенту это может выйти дешевле, чем покупать трафик непосредственно для своего хостинга.
- Самое главное предложение 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
Примерно так.
Shared by arty
грустно это всё, конечно. Зато не приходится рассчитывать на людей, которые не умеют читать и считать : )
Here are the slides of my FrontTrends presentation. Mostly new material about why we need SMS messages for transferring JSON, web servers over Bluetooth, why we don't need app stores, and other mobile web ideas.
Overal verdict: fun conference! If it runs again in 2011, go there. And they plan an event called Falsy Values, too.
…в Группу Видимой Красоты, а серверных — в Группу Невидимой Красоты.
 |
 |
Bluetile is a tiling window manager for Linux, designed to integrate with the GNOME desktop environment. It provides both a traditional, stacking layout mode as well as tiling layouts where windows are arranged to use the entire screen without overlapping. Bluetile tries to make the tiling paradigm easily accessible to users coming from traditional window managers by drawing on known conventions and providing both mouse and keyboard access for all features. - Anton Yuzhaninov |
|
сегодня случайно наткнулся в блоге автора script.aculo.us на любопытный трюк. Нередко бывает нужно выполнять какую-то функцию не только по событию, но и однократно при загрузке страницы. Обычно это делается так: определяем функцию как именованную, вызываем её и назначаем как обработчик:
function fix(){…}
fix();
document.addEventListener('click', fix, false);
однако есть более любопытный и красивый способ добиться этого:
document.addEventListener('click', (function(){
// do something
return arguments.callee;
})(), false);
анонимная функция выполняется сразу и возвращает саму себя, чтобы это возвращённое значение можно было сразу использовать. Очень симпатичный трюк! Впрочем, неясно, стоит ли его использовать: из-за своей нетривиальности он заметно повышает WTF-фактор кода. Как думаете, стоит игра свеч?
Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.
Под катом:
- как упростить код вьюх ровно в 2 раза
- легкий способ рисования графиков
- почему Ian Bicking воскликнул «Cool!»
- приложения для ВКонтакте на django за 5 минут
- хорош ли pymorphy?
- пара фишек насчет выкладки пакетов на pypi
- что общего между декораторами и with-контекст-менеджерами
- принимаем оплату на django-сайтах
- показываем Яндекс.Карту для заданного адреса
Internet Explorer впервые за мнооооооого лет уступил половину рынка браузеров, то есть опустилися ниже 50%. В Европе - ниже 40%. Как радостно воскликнул бы Гераклит, увидев эту статистику, Все течет, все меняется.
← предыдущий месяцследующий месяц →
