"Прокси-серверы выполняют две основные функции - посредника и кэша"

Старые идеи — не самые популярные, но часто они оказываются наилучшими. Взять, к примеру, 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 предназначены специально для кэширования потокового аудио и видео.

Джонатан Эйнджел — старший редактор Network Magazine. С ним можно связаться по адресу: jangel@mfi.com.