Шрифт:
И все-таки лучшее, что может сделать браузер, — кэшировать все веб-страницы, которые посетил пользователь. Из нашего обсуждения популярности сайтов вы, вероятно, помните, что кроме нескольких популярных страниц, постоянно посещаемых многими людьми, существует огромное число непопулярных страниц. На практике это ограничивает эффективность кэширования браузером, потому что пользователи заходят на многие страницы однократно и их каждый раз нужно получать с сервера.
Единственный способ использовать кэш эффективнее — сделать его общим для нескольких пользователей. При этом страница, уже доставленная для одного из них, может быть возвращена другому, когда тот сделает такой же запрос. Без кэширования в браузере обоим пользователям пришлось бы получать страницы с сервера. Конечно, общий доступ невозможен в случае зашифрованного трафика, страниц, требующих аутентификации, и возвращаемых программами некэшируемых страниц (например, с информацией о текущих курсах акций). Динамические страницы, особенно создаваемые программами, также часто не позволяют эффективно использовать кэширование. Однако есть множество веб-страниц, которые доступны многим и выглядят для всех одинаково (например, изображения).
Чтобы обеспечить пользователям общий доступ к кэшу, используется веб-прокси (Web proxy). Прокси — это агент, который действует от чужого имени, например другого пользователя. Есть много видов прокси. Например, ARP-прокси отвечает на ARP-запросы от имени пользователя, который находится где-то в другом месте (и не может ответить сам). Веб-прокси выполняет веб-запросы от имени его пользователей. Обычно он кэширует веб-ответы, и так как он находится в совместном доступе, его кэш значительно больше, чем у браузера.
При использовании прокси типичный вариант для организации (компании или интернет-провайдера) — задействовать один веб-прокси для всех пользователей. В обоих случаях выгодно увеличить скорость веб-запросов для пользователей, а также сократить потребности в пропускной способности. Для домашних пользователей обычно устанавливается постоянная цена, независимо от потребления, но компании и провайдеры, как правило, платят в зависимости от используемой пропускной способности.
Конфигурация с использованием прокси показана на илл. 7.44. Каждый браузер настроен так, чтобы отправлять запросы к прокси, а не к реальному серверу страницы. Если у прокси есть эта страница, он сразу ее возвращает. В противном случае прокси берет страницу с сервера, добавляет ее к кэшу для будущего использования и возвращает клиенту то, что он запросил.
Илл. 7.44. Прокси-кэш между веб-браузерами и веб-серверами
Кроме отправки запросов к прокси, клиенты выполняют и собственное кэширование, используя кэш браузера. Обращение к прокси происходит только после того, как браузер попробовал удовлетворить запрос из своего кэша. Таким образом, прокси обеспечивает второй уровень кэширования.
Чтобы обеспечить дополнительные уровни кэширования, могут быть добавлены следующие прокси. Каждый прокси (или браузер) делает запрос к своему вышестоящему прокси (upstream proxy). Каждый вышестоящий прокси производит кэширование для нижестоящих прокси (downstream proxy) или браузеров. В результате может получиться, что браузеры компании используют ее прокси, который, в свою очередь, использует прокси интернет-провайдера, а тот контактирует с веб-серверами напрямую. Но на практике, чтобы извлечь большую часть потенциальной выгоды, часто достаточно одного уровня прокси-кэширования (см. илл. 7.44). Проблемой снова оказывается «длинный хвост» популярности. Исследования веб-трафика показали, что кэш общего доступа особенно полезен, пока число пользователей не превосходит количество сотрудников небольшой компании (скажем, 100 человек). Когда это число увеличивается, преимущества использования общего кэша становятся незначительными, поскольку для кэширования непопулярных запросов не хватает места.
Веб-прокси часто устанавливают ради дополнительных преимуществ, например из-за возможности фильтровать контент. Системный администратор может создать на прокси черный список сайтов или фильтровать запросы. К примеру, многие администраторы не одобряют просмотр YouTube (или, того хуже, порнографии) на рабочем месте и ставят соответствующие фильтры. Еще одно преимущество — конфиденциальность (или анонимность): прокси скрывает личность пользователя от сервера.
7.5.3. Сети доставки контента
Серверные фермы и веб-прокси помогают создавать большие сайты и улучшать работу сети, но этих инструментов недостаточно для действительно популярных веб-сайтов, которые должны предоставлять контент в глобальном масштабе. К ним требуется другой подход.
Сети доставки контента (Content Delivery Networks, CDN) переворачивают идею традиционного веб-кэширования с ног на голову. Клиентам больше не нужно искать копии страниц в ближайшем кэше. Вместо этого провайдер размещает копии страницы в наборе узлов в разных местах и направляет клиента, чтобы тот использовал в качестве сервера узел, расположенный поблизости.
Первой применять DNS для распределения контента начала компания Akаmаi в 1998 году. Тогда, на раннем этапе своего развития, интернет едва справлялся с нагрузкой. Akаmаi была первой крупной CDN и очень быстро стала лидером отрасли. Она построила удачную бизнес-модель и систему стимулирования (возможно, еще более удачную, чем сама идея использования DNS для соединения клиентов с ближайшими узлами). Компании платят Akаmаi за доставку своего контента клиентам, чтобы получить удобные для пользователей веб-сайты с низким временем отклика. Узлы CDN должны располагаться там, где есть хорошая скорость подключения; изначально это подразумевало сети интернет-провайдера. На практике узел CDN представляет собой стандартную 19-дюймовую аппаратную стойку с компьютером и множеством дисков, из которой выходит оптоволоконный кабель для подключения к внутренней LAN интернет-провайдера.
ISP выгодно иметь узел CDN в своих сетях, поскольку это снижает величину необходимой им исходящей пропускной способности (за которую они платят). Кроме того, при наличии узла CDN контент доставляется пользователям с меньшей задержкой. Таким образом, выигрывают и интернет-провайдер, и клиенты, а CDN делает деньги. Начиная с 1998 года в этой сфере бизнеса появилось множество других компаний, включая Cloudflare, Limelight, Dyn и т.д., так что сейчас это конкурентная отрасль с большим количеством провайдеров. Как уже упоминалось, многие крупные провайдеры контента, такие как YouTube, Facebook и Netflix, используют собственные сети доставки контента.