Скромные помощники Сети

Прокси?

Прежде всего, несколько слов о самом слове "proxy". Его общепринятыми вариантами перевода являются: уполномоченный, доверенное лицо, заместитель. Административно-бюрократический быт, одним словом. Порывшись несколько глубже в толковых словарях английского языка, можно обнаружить еще двух претендентов: адвоката и агента. Ну, с адвокатом все ясно. А вот агент, хоть и звучит привычно русскому уху, и как бы современно, но известен в столь многочисленных ипостасях, что применить его для перевода еще одного термина просто рука не поднимается. Поэтому было решено оставить "proxy" как "прокси". Иначе: назовем кошку кошкой.

История появления прокси-серверов очень проста. Их никто не изобретал, они просто появились в начале 90-х, поскольку были нужны. Это случилось еще в эпоху до протоколов HTTP (Hyper-Text Transfer Protocol) и Всемирной Паутины. Для пересылки файлов тогда использовался и ныне здравствующий протокол FTP (File Transfer Protocol). И всем известно, как грузятся FTP-серверы, когда на них просматриваются каталоги, с них скачиваются файлы, а не просто странички WWW. Вот тогда в некоторых компактных сетевых сообществах, например, в университетских и корпоративных сетях, и стали устанавливать серверы-посредники, хранящие в общем поле памяти (кэше) часто используемые документы.

Одновременно шел процесс включения в Internet корпоративных и общественных сетей, появились корпоративные сети технологии intranet. В связи с этим у прокси-серверов появилась еще одна функция: они стали использоваться в качестве шлюзов доступа к Сети, позволяя обходить брандмауэры (firewall), устанавливаемые на основных корпоративных серверах. Брандмауэры, как известно, предназначены для защиты сетей и клиентов от всевозможных неожиданностей и неприятностей, вроде несанкционированных проникновений из общего Internet. Прокси-серверы прислушиваются к клиентским запросам и направляют эти запросы к удаленным серверам вне корпоративной среды, окруженной брандмауэрами. Получив ответ, прокси-сервер переправляет его клиенту. И подключившись к прокси-серверу, пользователи чувствуют себя так, будто они работают напрямую с удаленными серверами.

Таким образом, в настоящее время прокси-сервером называется специализированный сервер, работающий с протоколом HTTP, возможно, и с другими протоколами, который и обеспечивает в первую очередь указанные выше две функции: кэширование данных для клиентов подсети и посредничество в связи клиента с общим пространством Internet.

Прокси-серверы могут быть полезны и во многих других ситуациях. К примеру, они способны:

• разрешать и ограничивать доступ клиентов к Сети на основе анализа их IP-адресов;
• вести селективный контроль доступа к Internet и его подсетям на основе запрошенного URL;
• решать вопросы доступа к Сети для компаний, у которых есть собственные корпоративные сети;
• преобразовывать данные в форматы, удобные для конечного пользователя.

Рассмотрим более подробно, как осуществляются эти и другие функции.

Что и как

Случается, что программа-клиент (например, браузер WWW или FTP-клиент) не имеет возможности напрямую обратиться к ресурсам Сети. В таком случае требуемые файлы могут быть получены через прокси-сервер, как это показано на рис. 1. Прокси-сервер принимает запросы от клиента в форме URL (Universal Resource Locator). Получив ответ на запрос с удаленного сервера, прокси-сервер преобразует его в документ формата HTML и отправляет на браузер, который находится за защитным экраном. Таким образом, прокси-сервер обрабатывает все без исключения сетевые запросы: это машина, подключенная к Сети непосредственно. Обычно корпоративные клиенты ограничиваются в правах доступа к прокси-серверам. Это достигается указанием соответствующей маски для IP-адресов каждого из используемых протоколов доступа.

Рисунок 1.

Как правило, все клиенты корпоративной или общественной сети имеют доступ к одному и тому же прокси-серверу - для них он и создавался. Мы уже отметили, что большинство прокси-серверов WWW обладает способностью кэшировать документы. Важно учесть и то обстоятельство, что члены корпорации или сообщества чаще всего ходят по одним и тем же дорожкам, то есть пользуются пусть большим, но ограниченным множеством информационных ресурсов Сети. Можно очень просто сконфигурировать прокси-сервер для обслуживания целого сообщества, сохраняя в кэше получаемые документы. Если затребованные клиентом документы имеются в кэш-области, то прокси-сервер выдает их немедленно, без обращения к удаленному серверу, содержащему оригиналы. Это позволяет не только сократить время поиска информации, но и снижает общий трафик в Сети.

Можно сконфигурировать прокси-сервер таким образом, что он будет самостоятельно принимать решения: какие запросы клиентов исполнять, а какие - отклонять. К примеру, можно задать правила контроля доступа для каждого клиента по таким параметрам, как метод (протокол) доступа, адреса затребованных узлов, домены и т. п. Программные средства прокси-серверов позволяют задавать конкретные URL и маски URL, доступ к которым запрещен.

Прокси-серверы могут помочь и тем клиентам, которые по каким-то причинам не имеют доступа к службе доменных имен (DNS - Domain Name Services). Такая ситуация характерна для корпоративных сетей на основе протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). Для выхода в Internet в программе клиента нужно просто задать IP-адрес прокси-сервера, который и будет выполнять все нужные разрешения доменов.

Организации и предприятия, использующие одну или несколько собственных сетей, могут включить их с определенными целями, например, для рассылки и получения почты, в Internet. Чтобы это сделать, нужно только определить прокси-сервер, который просматривается как из Internet, так и из их корпоративной сети или сетей, и подключиться к нему.

С прокси и без них

Рисунок 2.

Большинство клиентов имеют собственные IP-адреса (возможно, назначенные динамически) и входят в прямое соединение с удаленными серверами Сети. Запрос пользователя в виде URL специфицирует полный путь к каталогу, где содержится нужный документ. И когда пользователь указывает своей программе-клиенту что-то вроде: http://company.com/information/detail.html, то клиент сначала соединяется с сервером company.com, а потом выдает команду вида GET /information/detail.html, как это показано на рис. 2. В ответ сервер может отправить либо затребованный документ, либо сообщение об ошибке поиска. Заметим, что в этом примере можно было бы с успехом рассматривать вместо протокола HTTP - протоколы FTP, Gopher...

Рисунок 3.

А вот как осуществляется тот же запрос в случае использования прокси-сервера. Когда программа-клиент направляет запрос на прокси-сервер, он практически всегда осуществляется в виде транзакции HTTP. И это справедливо даже в тех случаях, когда требуется доступ к удаленному серверу, который работает с другим протоколом, например, FTP. Важно заметить, что когда запрос идет на прокси-сервер, он задается как полный URL, в отличие от прямого запроса на удаленный сервер, как это было только что описано. Допустим, пользователь задает тот же самый полный URL: http://company.com/information/detail.html, а программа-клиент преобразует его в команду GET http://company.com/information/detail.html. Затем клиент соединяется с прокси-сервером, который, в свою очередь, соединяется с удаленным сервером в Сети, содержащим затребованный документ. В этом случае команда GET /information/detail.html формируется уже не клиентской программой, а прокси-сервером, и выдается серверу, размещенному по адресу company.com. Результаты, полученные от удаленного сервера, принимаются прокси-сервером и пересылаются клиенту. Вся эта схема достаточно наглядно изображена на рис. 3. Таким образом, прокси-сервер выступает посредником между клиентом и удаленным сервером.

Рисунок 4.

На рис. 4 показана процедура запроса клиентом ресурса, размещенного на удаленном сервере FTP, через прокси-сервер. Характерно, что запрос выполняется в форме HTTP, даже если клиенту требуется документ, размещенный на FTP-сервере. Прокси-сервер получает файл с удаленного FTP-сервера и отправляет его обратно клиенту, используя протокол HTTP. Сведения о каталогах FTP представлены в формах HTML.

Кэш: что такое хорошо и что такое плохо

Как уже затвержено, одним из главных полезных применений прокси-серверов является кэширование документов. Это означает, что найденные по запросам клиентов документы сохраняются локально на прокси-сервере, и нет необходимости обращаться на удаленный сервер в следующий раз, когда клиент захочет получить доступ к этому же документу. На рис. 5 показано, как сервер-агент кэширует документ, полученный с удаленного сервера. Клиент (клиенты) может затребовать и получить локально сохраненные документы позднее, как показано на рис. 6.

Рисунок 5.

Кэширование документов обеспечивает значительную экономию времени и усилий для клиента при получении документов, находящихся где-то в Сети. А это означает снижение общей стоимости работы в Сети. Кроме того, принимая во внимание корпоративные или общественные ресурсы, кэширование минимизирует использование дискового пространства, поскольку в кэше хранится единственная копия документа, нужного многим клиентам. На практике иногда конфигурируют несколько прокси-серверов таким образом, что они используют общее пространство памяти для кэширования.

Рисунок 6.

Иногда бывает нужно интенсивно использовать или демонстрировать определенные ресурсы, обнаруженные в Сети, скажем, заполнять интерактивные формы обновления баз данных. В этих случаях можно разместить и клиентскую часть (браузер), и прокси-сервер на одном компьютере и сконфигурировать общий кэш. Таким образом удастся "работать в Сети" вообще в нее не входя. Если это будет ноутбук, то можно эмулировать деятельность в Сети где угодно, например, в дороге, - без фактического подключения.

Всякая медаль имеет оборотную сторону. Есть недостатки и у метода кэширования на прокси-серверах. Многие документы в Сети являются "живыми", они изменяются в реальном времени. И определение того, обновлять такой документ, или нужно его вообще стереть, может стать сложной задачей. Документ может оставаться неизменным очень долго, а потом внезапно измениться. Как противоположная крайность: документ может обновляться ежедневно и даже по несколько раз в день. Поэтому прежде, чем применять приемчики работы с кэшем, администраторы прокси-серверов в каждом случае должны дать ответы на такие "простенькие" вопросы:

• какие именно документы нужно сохранять;
• как долго можно хранить документ в кэше, не опасаясь потери его актуальности.

И действительно, на практике для каждого прокси-сервера разрабатывается своя собственная дисциплина обслуживания кэша, причем, алгоритмы бывают очень сложными.

Принятие окончательных решений об обновлении документов в большинстве случаев лучше оставить на усмотрение пользователя. Чтобы получить свежую копию документа, достаточно нажать в браузере кнопку "Reload" в пункте меню "View". На более глубоком уровне это вызовет выдачу команды GET с опцией "pragma: no-cache", так называемого условного GET. Приняв такую команду, прокси-сервер заменит затребованный документ в кэше новой версией, немедленно полученной из источника.

Взаимодействия прокси-прокси

Как это уже понятно, прокси-серверы дают эффективные (и эффектные) решения общих локальных полей памяти для структурных подразделений корпораций. Такие внутренние прокси-серверы подразделений можно связывать с корпоративными прокси-серверами, которые стоят на обходных путях брандмауэров - между сетью предприятия и открытой Сетью. В этом случае взаимодействия происходят так, как это показано на рис. 7. Любые правила доступа, заданные на сервере предприятия, здесь имеют приоритет по сравнению с правилами, заданными на прокси-серверах подразделений.

Рисунок 7.

К примеру, прокси-сервер 1 не имеет ограничений доступа ко всему пространству URL. А сервер корпорации, согласно ее политике, может запрещать доступ к URL всех онлайновых публикаций конкурирующей компании. Вряд ли в таком случае сотрудники смогут ознакомиться с мнениями конкурентов. И наоборот, прокси-сервер 1 можно сконфигурировать так, что будет невозможно получать с него доступ к внешним серверам (по списку) и скачивать с них игрушки тайком от начальства, а прокси-серверы 2, 3 и корпоративный прокси-сервер не будут ограничивать доступа к ресурсам Сети. Практически неограниченные возможности конфигурирования прокси-серверов дают необычайную гибкость в администрировании корпоративных сетей.

Нужно, однако, при работе с прокси-серверами соблюдать некоторые предосторожности:

• нельзя устраивать на прокси-серверах циклические структуры;
• в программах-клиентах следует задавать доменное имя внешнего прокси-сервера, через который будет осуществляться выход в открытую Сеть, а не промежуточных прокси-серверов.

Кажется, эти рекомендации в комментариях не нуждаются.

А что клиенты?

Использование прокси-серверов в настоящее время является общепринятой практикой, и большинство клиентских программ поддерживает ее. Программу-клиента можно сконфигурировать таким образом, что все запросы будут отправляться на прокси-сервер, который и будет выполнять поручения. Клиента совершенно не волнует, какой именно прокси-сервер используется - для обхода брандмауэров, для кэширования, для преобразования протоколов... Нужно просто задать адреса и прочие параметры серверов для определенных протоколов (HTTP, FTP, Gopher...). Кроме того, многие (хотя, не все) клиенты позволяют указывать определенные домены, которые будут доступны прямо, а не через прокси-серверы. Это имеет смысл в тех очевидных случаях, когда нужно избежать зацикливаний в виде ссылок на себя, бессмысленной нагрузки на сервер и сохранения локальных документов в кэше.

Наиболее распространенные сейчас клиенты WWW - браузеры Microsoft и Netscape Communications - позволяют легко, быстро и гибко настроить конфигурацию работы с прокси-серверами (или без них). Например, последние версии браузеров Netscape позволяют:

• работать без прокси-серверов;
• делать ручную настройку на прокси-сервер;
• автоматически настроиться на прокси-сервер, используя файл конфигурации.

Рассмотрим последний вариант настройки, как самый многообещающий. Сначала войдем в пункт меню Edit, выберем Preferences, далее - Advanced и, наконец, Proxy. Из трех возможностей задания конфигурации нужно выбрать Automatic Proxy Configuration и задать полный URL файла, содержащего текст программы, написанной на JavaScript. После этого нужно кликнуть на "Reload" и "OK". Это все можно увидеть на рис. 8. Установки будут сделаны после запроса следующего URL. Браузер сам выйдет на размещенный в Сети файл конфигурации и отработает его. Например, для прокси-сервера телекоммуникационного проекта "Ботик", который осуществляется в Переславле-Залесском Институтом программных систем РАН и Российским НИИ региональных проблем, на такой файл указывает URL http://www.botik.ru/proxy.config. Конечно, это только пример, поскольку "Ботик" обслуживает только свою публику.

Рисунок 8.

Если ожидается много работы без прямого подключения к Сети, можно разместить описания настроек на прокси-серверы прямо на локальном жестком диске и вызывать их по необходимости, указывая, к примеру, на файл - file:///C|proxies/proxy.config.

Проза жизни

Если любой публичной поисковой машине дать запрос "proxy server", она выдаст вам несколько тысяч ссылок. Даже после избавления от дублированных ссылок, их останется не менее тысячи. Небольшую часть составят указания на общие документы, вроде технических отчетов, рекомендаций, документов W3C (WWW Consortium), IETF (Internet Engineering Task Force) и т. п. Оставшиеся не менее 90 процентов ссылок будут описывать одну и ту же, на второй раз кажущуюся туповатой, процедуру настройки браузеров на конкретные прокси-серверы. Особенно преуспели в создании таких документов Австралия и страны Дальнего Востока. Нас, однако, ждет разочарование. Во-первых, большая часть прокси-серверов, как и задумано, обслуживает только ограниченные сообщества. Нас они обслуживать не будут. А те серверы, которые обслуживают всех кого угодно, вращаются в слишком далеких от нас сферах: прямой доступ будет работать быстрее. Поэтому остается ждать и надеяться, что со временем удастся примкнуть к некой местной технически продвинутой группе, владеющей прокси-сервером, и в полной мере насладиться возможностями обширных кэшей.

А вот статистика от британской организации HENSA (Higher Education National Software Archive), владеющей одним из самых мощных в Европе прокси-сервером и обслуживающей пользователей из домена .ac.uc. Из 10 Гбайт кэша, которые в динамике поставляются клиентам, из внешних источников подкачивается только 4 Гбайт. 30 процентов всех запросов отрабатываются в течение не более одной секунды, а 50 - в течение не более 4 секунд. Время отработки замеряется от установления соединения клиента с прокси-сервером до отправки заказчику последнего байта. Среднее время улучшения условий обслуживания, то есть разница между временем отработки через прямое соединение и временем отработки через прокси-сервер, составляет не менее 25 секунд. Это значит, что пользователи HENSA экономят в среднем на каждом документе 25 секунд. А поскольку каждый день прокси-сервер отрабатывает около 950 тыс. обращений, то это, как в шутку замечено администраторами сервера, означает ежедневную экономию около 800 человеко-дней! Сколько за это рабочее время может заработать в Соединенном королевстве специалист в области high-tech с высшим образованием?