Третий подход, который преодолел трудности предыдущих двух подходов, использует DNS и называется переназначением DNS (DNS redirection). Предположим, что клиент хочет получить страницу с URL http://www.cdn.com/page.html. Чтобы получить эту страницу, браузер будет использовать DNS, чтобы определить www.cdn. com по IP-адресу. Этот просмотр DNS происходит обычным образом. Используя протокол DNS, браузер узнает IP-адрес сервера имен для cdn.com, затем контактирует с сервером имен, чтобы попросить его выдать IP-адрес www.cdn.com. А теперь происходит действительно умная вещь. Сервер имен управляется CDN. Вместо того чтобы возвращать один и тот же IP-адрес для каждого запроса, он посмотрит на IP-адрес клиента, делающего запрос, и возвращает различные ответы. Ответ будет IP-адресом узла CDN, который расположен ближе всего к клиенту. Так, если клиент в Сиднее запрашивает сервер имен CDN выдать IP-адрес www.cdn.com, сервер имен вернет IP-адрес узла CDN в Сиднее, а если такой же запрос делает клиент в Амстердаме, сервер имени вернет IP-адрес узла в Амстердаме.
Эта стратегия вполне законно соответствует семантике DNS. Мы заранее видим, что серверы имен могут возвращать изменяющийся список IP-адресов. После анализа имени клиент в Сиднее получает страницу непосредственно из узела CDN в Сиднее. Дальнейшие страницы с того же «сервера» будут также взяты непосредственно с узла в Сиднее вследствие кэширования DNS. Полная последовательность шагов показана на рис. 7.41.
Рис. 7.41. Направление клиентов к ближайшим узлам CDN с использованием DNS
Сложный вопрос в описанном выше процессе — что означает найти самый близкий узел CDN и как это сделать. При определении понятия «ближайший» главный фактор — не география. При определении соответствия клиента и узла CDN следует принять во внимание как минимум два фактора. Первый фактор — сетевое расстояние. Клиент должен иметь короткий и большой емкости сетевой путь к узлу CDN. Это сделает загрузку более быстрой. Чтобы определить по IP-адресу клиента его сетевое местоположение, CDN используют заранее вычисленное отображение. Выбираемый узел может находиться на кратчайшем расстоянии, по прямой, а может и нет. Значение имеет некоторая комбинация длины сетевого пути и ограничений емкости на нем. Второй фактор — нагрузка, которая уже имеется на узле CDN. Если узлы CDN перегружены, они будут посылать ответы медленно, точно так же, как перегруженные веб-серверы, чего мы стремимся избежать в первую очередь. Поэтому может быть необходимо балансировать загруженность узлов CDN, отправляя часть клиентов к узлам, которые находятся несколько дальше, но менее загружены. Применение DNS для распределения контента было впервые разработано Akаmаi в 1998 году, когда Паутина стонала под грузом своего раннего роста. Akаmаi была первым большим CDN и стала лидером индустрии. Вероятно еще более умной, чем использование DNS для соединения клиентов с ближайшими узлами, была стимулирующая роль бизнеса. Компании платили Akаmаi за доставку их контента пользователям, так что они имели хорошо откликающиеся веб-сайты, которые были удобны клиентам. Узлы CDN должны быть размещены в местах сети с хорошей связностью, что изначально означает внутренние сети интернет-провайдеров. Для интернет-провайдеров преимущество наличия узла CDN в их сетях заключается в том, что узел CDN ограничивает необходимое количество расположенной выше сетевой пропускной способности, которая им нужна (и за которую надо платить), только прокси-кэшами. Кроме того, узел CDN улучшает отзывчивость для клиентов интернет-провайдеров, что позволяет провайдерам хорошо выглядеть в их глазах, предоставляя конкурентоспособное преимущество над провайдерами, которые не имеют узла CDN. Эти преимущества, ничего не стоящие для интернет-провайдера, делают для него установку узла CDN привлекательной. Таким образом, и поставщик контента, и интернет-провайдер, и клиенты — все выигрывают, а CDN делает деньги. Начиная с 1998 года другие компании вошли в этот бизнес, так что сейчас это конкурентная отрасль со многими поставщиками.
Как подразумевает это описание, большинство компаний не строят своих собственных CDN. Вместо этого они используют для доставки своего контента услуги поставщика CDN, например Akаmаi. Чтобы позволить другим компаниям использовать обслуживание CDN, нам нужно добавить к нашей картине еще один, последний шаг.
После подписания контракта владелец веб-узла предоставляет свой контент CDN. Этот контент отправляется в узлы CDN. Кроме того, владелец переписывает все ссылки из его веб-страниц, которые ведут к такому контенту. Вместо связывания с контентом на своем веб-сайте, страницы связываются с контентом через CDN. Как пример работы этой схемы, рассмотрим исходный код для веб-страницы Пушистое Видео, показанный в листинге 7.11, а. После предварительной обработки он преобразован в листинг 7.11, б и размещен на сервере Пушистое видео как страница www. fluffyvideo.com/index.html.
Когда пользователь печатает в своем браузере URL www.fluffyvideo.com, DNS возвращает IP-адрес сайта Пушистое видео, позволяя получить главную (HTML) страницу обычным способом. Когда пользователь щелкает на любой из гиперссылок, браузер просит DNS найти www.cdn.com. В процессе поиска происходит контакт с DNS-сервером CDN, который возвращает IP-адрес ближайшего узла CDN. Затем браузер отправляет обычный HTTP-запрос к узлу CDN, например к /fluffyvideo/ koalas.mpg. URL идентифицирует страницу для возвращения пользователю, начиная путь с fluffyvideo таким образом, что узел CDN может разделить запросы от различных
компаний, который он обслуживает. Наконец, видео получено, и пользователь видит милых пушистых животных.
Стратегия после разделения контента на хранящийся на CDN и у владельца страницы состоит в том, чтобы предоставить владельцу контента контроль, а на CDN переместить большую часть данных. Большинство «входных» страниц имеют небольшой размер, так как содержат только HTML-текст. Эти страницы часто связываются с большими файлами, например видео и изображения. А большие файлы поддерживаются CDN, даже если CDN целиком открыт для пользователей. Сайт выглядит точно так же, но работает быстрее.
Листинг 7.11. HTML-текст исходной страницы (а); та же страница после переключения на CDN (б)
Есть и другое преимущество использования сайтами общих CDN. Будущий спрос на веб-сайт может быть трудно предсказать. Часто возникают большие волны спроса, известные как «flash crowds» (резкое увеличение обращений на веб-сайт). Такая большая волна может возникнуть, например, когда выпущена новая версия продукта, когда прошел показ мод или другое событие, или компания появилась в новостях. Даже веб-сайт, который был ранее неизвестным, непосещаемым болотом, может внезапно стать центром Интернета, если он освещен в новостях и на него поставлены ссылки с популярных сайтов. Так как большинство сайтов не готово выдерживать большое увеличения трафика, многие из них в результате таких волн выходят из строя.
Рассмотрим один случай. Обычно веб-сайт Florida Secretary of State не очень загружен, хотя вы можете найти там информацию о корпорациях, нотариусах и культурных событиях штата Флорида, а также информацию о голосованиях и выборах. По некоторой причине, 7 ноября 2000 года (дата американских президентских выборов,
Буш против Гора), множество людей были внезапно заинтересованы в результатах выборов, опубликованных на этом сайте. Сайт внезапно стал одним из самых занятых веб-сайтов в мире и, естественно, в результате вышел из строя. Если бы там использовалась CDN, он бы, возможно, устоял.
Используя CDN, сайт получает доступ к очень большой емкости для размещения контента. Самые большие CDN имеют десятки тысяч серверов, расположенных в разных странах по всему миру. Так как в каждый момент времени только небольшое количество сайтов будет испытывать всплески количества обращений (по определению), эти сайты могут использовать емкость CDN для управления нагрузками, пока волна не схлынет. Таким образом, CDN может быстро увеличить предоставляемую сайту емкость.
