Веб-прокси (Web proxy) используется для того, чтобы обеспечить пользователям общий доступ к кэшу. Прокси — это агент, который действует от имени кого-то другого, например пользователя. Есть много видов прокси. Например, ARP-прокси отвечает на запросы ARP от имени пользователя, который находится где-то в другом месте (и не может ответить за себя). Веб-прокси выполняет веб-запросы от имени его пользователей. Он обычно обеспечивает кэширование веб-ответов, и так как он находится в совместном доступе, веб-прокси имеет существенно больший кэш, чем браузер.
Когда используется прокси, типичный вариант для организации — задействовать один веб-прокси для всех пользователей. Организация — это компания или интернет-провайдер. В обоих случаях выгодно увеличить скорость веб-запросов для пользователей, а также сократить потребности в пропускной способности. Для конечных пользователей обычно устанавливается постоянная цена, независимо от использования, а плата с большинства компаний и интернет-провайдеров взимается в зависимости от использованной пропускной способности.
На рис. 7.39 показана конфигурация с использованием прокси. Каждый браузер настроен так, что он отправляет запросы к прокси, а не к реальному серверу страницы. Если прокси имеет эту страницу, он возвращает ее немедленно. В противном случае, прокси берет страницу с сервера, добавляет ее к кэшу для будущего использования и возвращает клиенту то, что он запросил.
Рис. 7.39. Вспомогательный кэш между веб-браузерами и веб-серверами
Кроме отправки запросов к прокси вместо реального сервера, клиенты выполняют и собственное кэширование, используя кэш браузера. Обращение к прокси происходит только после того, как браузер попробовал удовлетворить запрос из своего собственного кэша. Таким образом прокси обеспечивает второй уровень кэширования.
Для того чтобы обеспечить дополнительные уровни кэширования, могут быть добавлены следующие прокси. Каждый прокси (или браузер) делает запрос к своему вышестоящему прокси (upstream proxy). Каждый вышестоящий прокси производит кэширование для нижестоящих прокси (downstream proxy) или браузеров. Таким образом, возможно, что браузеры компании используют прокси компании, который использует прокси интернет-провайдера, который контактирует непосредственно с веб-серверами. Однако на практике, чтобы получить большую часть потенциальных преимуществ, часто достаточно одного уровня прокси-кэширования, который мы показали на рис. 7.39. Проблемой снова оказывается длинный хвост популярности.
Исследования веб-трафика показали, что кэш общего доступа особенно выгоден, пока число пользователей не превосходит количества сотрудников небольшой компании (скажем, 100 человек). Когда количество пользователей увеличивается, выгоды от использования общего кэша становятся незначительными из-за того, что непопулярные запросы не могут кэшироваться в связи с нехваткой пространства для хранения (Wolmаn и др., 1999).
Веб-прокси обеспечивают дополнительные преимущества, которые часто являются фактором в решении об их установке. Одно из преимуществ — возможность фильтровать контент. Администратор может создать на прокси черный список сайтов или фильтровать запросы, которые он делает. Например, многие администраторы неодобрительно смотрят на сотрудников, которые смотрят на рабочем месте видео на YouTube (или, еще хуже, порнографию), и устанавливают соответствующие фильтры. Еще одно преимущество наличия прокси — конфиденциальность или анонимность, когда прокси защищает идентичность пользователя от сервера.
7.5.3. Сети доставки контента
Серверные фермы и веб-прокси помогают строить большие сайты и улучшать работу сети, но они не достаточны для действительно популярных веб-сайтов, которые должны предоставлять контент в глобальном масштабе. Для этих сайтов нужен другой подход.
CDNs (Content Delivery Networks — сети доставки контента) переворачивают идею традиционного веб-кэширования с ног на голову. Вместо того чтобы клиенты искали копии страниц в ближайшем кэше, сам поставщик размещает копии страницы в наборе узлов в различных местах и направляет клиента, чтобы тот использовал в качестве сервера ближайший узел.
На рис. 7.40 показан пример пути следования данных в случае их распространения CDN. Это — дерево. Исходный сервер в CDN распространяет копию контента по другим узлам в CDN, расположенным в этом примере в Сиднее, Бостоне и Амстердаме. Этот процесс показан пунктирными линиями. Затем клиенты забирают страницы с ближайших узлов CDN. Этот процесс показан сплошными линиями. Таким образом, оба клиента в Сиднее берут копию страницы, которая расположена в Сиднее; они не достают страницу с исходного сервера, который, возможно, находится в Европе.
Использование древовидной структуры имеет три преимущества. Во-первых, распространение контента может масштабироваться до любого необходимого числа клиентов, используя большее количество узлов CDN (и больше уровней в дереве, когда распределение среди узлов CDN станет узким местом). Древовидная структура эффективна независимо от того, сколько имеется клиентов. Исходный сервер не перегружен, так как он взаимодействует с клиентами через дерево узлов CDN; ему не придется самому отвечать на каждый запрос страницы. Во-вторых, каждый клиент получает хорошую производительность за счет доставки страницы с ближайшего сервера, а не с отдаленного сервера. Это связано с тем, что время установки связи короче, из-за чего медленный старт TCP происходит быстрее, а более короткий сетевой путь с меньшей вероятностью пройдет через области затора в Интернете. Наконец, общая загруженность сети также сведена к минимуму. Если узлы CDN хорошо размещены, каждая страница передается в каждом участке сети только один раз. Это важно, поскольку в конечном счете кто-то платит за полосу пропускания.
Рис. 7.40. Дерево распределения CDN
Идея использования дерева распределения проста. Менее простая задача — организовать использование этого дерева клиентами. Например, прокси-серверы, казалось бы, должны обеспечить решение. На рис. 7.40 видно, что если каждый клиент настроен на использование одного из узлов CDN — в Сиднее, Бостоне или Амстердаме — в качестве кэширующего веб-прокси, распределение было бы древовидным. Однако на практике эта стратегия не срабатывает по трем причинам. Первая причина состоит в том, что клиенты в данной части сети возможно относятся к различным организациям и поэтому используют различные веб-прокси. Напомним, кэширование обычно не бывает общим для разных организаций в связи с ограниченностью выгоды от кэширования при большом количестве пользователей, а также из соображений безопасности. Во-вторых, при наличие многих CDN каждый клиент может использовать только один прокси кэш. Какой из CDN он должен использовать в качестве прокси? Наконец, возможно самая практическая проблема в том, что вебпрокси настраиваются клиентами. Они могут быть настроены или не настроены на получение преимуществ от распределения контента CDN, и CDN мало что может с этим сделать.
Другой простой путь поддерживать дистрибутивное дерево с одним уровнем — использовать зеркалирование (mirroring). В этом подходе, как и в предыдущих, исходный сервер повторяет контент в узлах CDN. Узлы в различных местах сети CDN называются зеркалами. Веб-страницы на исходном сервере содержат явные ссылки на различные зеркала, обычно сообщающие пользователю их местоположение. Такая схема позволяет пользователю вручную выбрать ближайшее зеркало и использовать его для загрузки контента. Пример типичного использования зеркал — размещение большого пакета программного обеспечения на серверах, расположенных, например, на восточном и западном побережье США, в Азии и в Европе. Сайты-зеркала обычно неизменны, и выбор этих сайтов остается постоянным месяцами или даже годами. Это испытанная и проверенная техника. Однако распределение в этом случае зависит от пользователя, так как зеркала — это действительно различные веб-сайты, даже если они связаны друг с другом.
