Джонатан Эйнджел
"Прокси-серверы выполняют две основные функции -
посредника и кэша"
Старые идеи - не самые популярные, но часто они оказываются
наилучшими. Взять, к примеру, Yahoo!, чьи отцы-основатели Джерри Янг и Дэвид
Фило обратили внимание на то, что при всех достоинствах механизмов поиска
достопочтенная концепция предметного каталога остается весьма привлекательной.
Не прибегая к помощи профессиональных библиотекарей, Янг и Фило сделали все по
собственному разумению и весьма преуспели на пути к богатству и славе.
Или, скажем, proxy-серверы. Эта концепция считается модной и
передовой, но и она уходит корнями в древнее и пыльное библиотечное дело.
Помните, как в университете вам вначале приходилось заказывать книгу из
закрытого для доступа хранилища? Так как читатели в закрытую часть библиотеки не
допускались, библиотекарь выступал в качестве вашего посредника (proxy) и
приносил заказанную книгу.
Конечно, как правило, этот процесс занимал больше времени, чем
если бы вы сами имели доступ к стеллажам с книгами. Но предположим, что каждый
раз, когда библиотекарь приносил книгу для одного студента, он делал несколько
ее копий и оставлял у себя на столе выдачи для тех студентов, кому потребуется
та же самая книга. Результат - идеальная комбинация быстрого обслуживания и
надежной защиты.
Приведенная аналогия объясняет две основные функции
proxy-сервера. Во-первых, proxy-сервер действует как посредник, помогая
пользователям частной сети получить информацию из Internet, когда она им
необходима, при этом он обеспечивает защиту сети. Во-вторых, proxy-сервер может
сохранять часто запрашиваемую информацию в кэше на локальном диске, быстро
доставляя ее пользователям без повторного обращения в Internet.
УРОВНЕВЫЙ ПОДХОД
Proxy-сервер обычно является лишь одним из компонентов
программного обеспечения, предоставляющего множество других сервисов, таких, как
услуги шлюза для подключения локальной сети к Internet или брандмауэра для
защиты от проникновения извне.
Из-за того, что proxy-серверы и брандмауэры часто поставляются
в одном пакете, многие их путают. Однако если брандмауэр с фильтрацией пакетов
функционирует на сетевом уровне модели OSI, то proxy-серверы работают на
прикладном уровне. Фильтры пакетов используют маршрутизаторы для фильтрации
поступающей в сеть и исходящей информации. Маршрутизаторы проверяют каждый пакет
по той или иной таблице контроля доступа (где перечислены, например, IP-адреса
заслуживающих доверия серверов), поэтому они могут без труда блокировать не
заслуживающий доверия трафик. Брандмауэры могут также изымать пакеты из
обращения на основании их номеров портов TCP и UDP; как следствие, некоторые
определенные типы соединений (например, telnet или ftp) могут быть разрешены
только особо доверенным серверам.
Брандмауэры с фильтрацией пакетов работают весьма быстро, и они
не предполагают никакой специальной конфигурации приложений конечных
пользователей. Вместе с тем создание сложных правил доступа может оказаться
весьма непростой задачей. Далее все, что могут делать фильтры пакетов, - это
разрешать или запрещать доступ на основании указанного адреса отправителя или
получателя. Хакеры могут обмануть такие брандмауэры посредством подмены
IP-адреса отправителя пакета. Соединения между клиентом и сервером являются
прямыми, поэтому хакеры могут без особого труда воспользоваться анализаторами
пакетов для выяснения адресной структуры сети.
Следуя аналогии с библиотекой, эквивалентом брандмауэра с
фильтрацией пакетов был бы библиотекарь, ведущий список заслуживающих доверия
студентов и допускающий только их в закрытое для других книгохранилище. Это
ускорило бы процесс получения книг, но вынудило бы вести список доступа. Кроме
того, такое решение чревато злоупотреблениями, когда студенты представляются под
чужим именем.
Proxy-серверы - нечто иное. Они разрывают прямое соединение
между клиентом и сервером при этом (или, если угодно, между студентом и ценной
книгой), при этом все внутренние IP-адреса сети отображаются на
один-единственный 'надежный' IP-адрес. Злоумышленнику известен только этот
адрес, поэтому атаки с подменой адресов становятся невозможны.
Благодаря функционированию на прикладном уровне модели OSI
proxy-серверы могут делать многое. Любой proxy-сервер состоит из множества
специфических посредников для конкретных приложений: посредника HTTP для страниц
Web, посредника ftp, посредника SMTP/POP для электронной почты; посредника HTTP
для серверов новостей, посредника RealAudio/RealVideo и т. д. Каждый из этих
посредников принимает пакеты только тех служб, для копирования, передачи и
фильтрации которых он создан.
Посредники для приложений имеют практически неограниченное
число опций конфигурации. Например, они могут быть настроены на блокирование
доступа к конкретным серверам Web все время, разрешать только определенным
пользователям воспроизводить клипы RealAudio, допускать лишь загрузку, но не
выгрузку по ftp или запрещать сотрудникам регистрацию в их персональных бюджетах
в America Online в рабочие часы. Proxy-серверы могут также блокировать
определенные типы MIME и, совместно с подключаемыми модулями независимых
производителей, такими, как SurfWatch, даже фильтровать содержимое.
Кроме того, proxy-серверы прекрасно справляются с задачами
протоколирования сетевого трафика и обеспечения постоянного соединения для
некоторых типов трафика. Например, небольшой офис может быть постоянно подключен
к Internet для просмотра Web через единственное коммутируемое соединение; а
proxy-сервер может автоматически установить второе коммутируемое соединение,
когда какой-либо пользователь инициирует длительный процесс загрузки по ftp.
Как обычно, оборотной стороной множества вариантов конфигурации
является сложность. Клиентские приложения, такие, как браузеры Web и плейеры
RealAudio, часто приходится переконфигурировать для указания им proxy-серверов.
Кроме того, при появлении новых сервисов Internet и новых протоколов и портов
должны быть написаны новые посредники для их поддержки. Процесс добавления
пользователей и предоставления прав также может оказаться весьма непростым, хотя
некоторые proxy-серверы облегчают эту задачу благодаря поддержке LDAP.
СОЗДАНИЕ ВИРТУАЛЬНОГО СОЕДИНЕНИЯ
Proxy-серверы для соединений проще в конфигурации. Они
функционируют как 'передаточное звено' между прикладным и транспортным уровнями,
контролируя обмен подтверждениями TCP между заслуживающими доверия клиентами или
серверами и не заслуживающими доверия хостами. Proxy-сервер по-прежнему является
посредником между двумя сторонами, но теперь он устанавливает между ними
виртуальное соединение.
При использовании proxy-серверов для соединений программное
обеспечение больше не требуется конфигурировать на каждом клиенте. Например, в
случае Proxy Server от Microsoft после установки программного обеспечения
WinSock Proxy на клиентский компьютер - а это однократная процедура - клиентское
программное обеспечение, такое, как Windows Media Player, Internet Relay Chat
(IRC) или telnet, будет функционировать так, как если бы оно имело прямое
соединение с Internet.
Недостаток посредников для соединений состоит в том, что они не
способны анализировать содержимое пакетов на прикладном уровне. Кроме того,
некоторые компьютеры (такие, как Macintosh) могут не иметь необходимого
клиентского программного обеспечения. (В этом случае браузеры Web и ему подобные
программы будут работать, но их придется конфигурировать вручную.) Эту проблему
решает такая программная технология, как SOCKS.
SOCKS была предложена в 1990 году и теперь достигла пятой
версии (см. RFC 1928). Она представляет собой не зависящий от платформы стандарт
для доступа к посредникам для соединений. Доступ может осуществляться либо через
специальное 'SOCKS-ифицированное' приложение с клиентского компьютера, в других
отношениях не подвергавшегося никаким изменениям, либо с каждого приложения,
выполняющегося на компьютере, на котором установлено передаточное звено SOCKS
(разделяемые или динамически компонуемые библиотеки).
Помимо стандартизации SOCKS имеет и другие преимущества. Версия
5 поддерживает идентификацию как с помощью имен/паролей (RFC 1929), так и на
базе API (RFC 1961). Кроме того, она поддерживает шифрование с помощью открытых
и личных ключей.
Исторически создание посредников для сервисов на базе UDP
представляет собой весьма трудную задачу, так как данный протокол не
предполагает установления соединения: каждый пакет передается как отдельное
сообщение. SOCKS 5 способен решить и эту проблему посредством установления
соединения TCP с последующей передачей по нему данных UDP.
Наконец, функции брандмауэров с фильтрацией пакетов,
посредников для приложений и посредников для соединений объединены в
брандмауэрах с контекстной проверкой. Эти устройства могут перехватывать и
анализировать все проходящие через них пакеты с использованием алгоритмов для
распознавания данных прикладного уровня. В отличие от посредников для
приложений, брандмауэры с контекстной проверкой не изменяют клиент-серверной
модели в целях анализа данных.
КЭШИРОВАНИЕ В ЛУЧШЕМ ВИДЕ
Выше основное внимание мы уделяли вопросам архитектуры и
безопасности, но многих пользователей proxy-серверы интересуют по одной причине,
и эта причина - кэширование. Хотя теоретически оно не является для них
обязательным, кэширование тесно связано с proxy-серверами Web с того момента,
когда они были впервые описаны на Международной конференции по World Wide Web
(Женева, апрель 1994 г.).
Базовая функция кэширования proxy-сервера работает во многом
аналогично встроенной в браузеры Web за тем отличием, что содержимое кэша
proxy-сервера доступно для множества пользователей. Всякий раз, когда какой-либо
пользователь локальной сети запрашивает страницу из Internet, она сохраняется
локально, что значительно ускоряет скорость доступа (см. Рисунок 1). Например,
как заявляет Novell, если ее BorderManager FastCache сконфигурирован на работу с
оперативной памятью, то он способен обслуживать свыше 5000 обращений в
минуту.
Некоторые proxy-серверы предлагают упреждающее кэширование, т.
е. они загружают в кэш изображения и другие содержащиеся на странице Web объекты
до того, как браузер их запросит. Кэш может заполняться заранее с помощью
механизма, известного как 'множитель последних изменений'. При этом proxy-сервер
анализирует даты создания часто запрашиваемых страниц, прогнозирует вероятный
срок изменения и запрашивает их по его наступлении. И конечно, proxy-серверы
позволяют администраторам проводить плановое пакетное копирование страниц Web в
любое время дня и ночи, когда объем сетевого трафика невелик.
Некоторые proxy-серверы имеют такую дополнительную функцию, как
обратное кэширование. При этом кэш-серверы сохраняют не только страницы из
Internet для локальных пользователей, но и локальные страницы для пользователей
в Internet.
ВЗАИМОДЕЙСТВИЕ НЕСКОЛЬКИХ КЭШЕЙ
Как бы быстро он ни работал, ни один кэш-сервер не в состоянии
сохранить все. Неизбежно наступает момент, когда какой-либо пользователь
запрашивает отсутствующие в кэше данные, которые затем медленно передаются по
Internet. Однако эту проблему можно смягчить посредством организации
взаимодействия между несколькими кэш-серверами так, чтобы они могли получать
информацию друг от друга. В RFC 2187 описан протокол кэширования Internet
(Internet Cache Protocol, ICP) для организации иерархической структуры
кэшей.
В иерархической (или многосвязной) структуре каждый кэш
устанавливает отношения с другим кэшем. Отношения бывают двух типов: подчиненные
и равноправные. При отсутствии запрошенного объекта кэш посылает запрос ICP о
наличии требуемого объекта у какого-либо из равноправных кэшей. В случае его
отсутствия и у равноправных кэшей запрос направляется вышестоящему серверу.
Типичная иерархия кэшей показана на Рисунке 2.
Связывая кэш-серверы между собой, ICP порождает и некоторые
проблемы. Одна из них состоит в том, что запросы ICP создают посторонний сетевой
трафик. Чем больше кэш-серверов в группе, тем больше трафик. Как следствие,
масштабируемость такого решения ограничена.
Другая проблема с ICP состоит в том, что со временем такие
группы серверов оказываются избыточными. В конечном итоге у каждого из серверов
в группе появляются свои копии часто запрашиваемых URL. По этой причине ICP
постепенно вытесняется протоколом маршрутизации для группы кэш-серверов (Cache
Array Routing Protocol, CARP), предложенным Microsoft.
В случае CARP кэш-серверы отслеживаются посредством 'списка
членства в группе', автоматически обновляемого с помощью функции Time-to-Live
(TTL), регулярно проверяющей дееспособность активных серверов. Затем с помощью
алгоритма хэширования определяется, кто из членов группы должен обслуживать
запрос к конкретному URL.
КЭШИРОВАНИЕ БЕЗ ГРАНИЦ
Кэш-серверы долгое время рассматривались как полезные
бесплатные приложения к proxy-серверам. Теперь, когда нагрузка на Internet
неизмеримо возросла, и все большее число клиентов имеет высокоскоростные
соединения, термины 'кэш-сервер' и 'proxy-сервер' вряд ли можно по-прежнему
использовать взаимозаменяемо.
Proxy-серверы будут продолжать предлагать кэширование как одну
из своих функций. Однако возрастающий спрос на специализированное кэширование
означает, что кэш-серверы все чаще будут рассматриваться в качестве отдельных
продуктов. Например, CacheQube от Cobalt Networks устанавливается между
локальной сетью и маршрутизатором для обеспечения прозрачного кэширования.
Streaming Media Cache от Inktomi и MediaMall от InfoLibria предназначены
специально для кэширования потокового аудио и видео.
Литература по серверам: разное
|