Предисловие

Началась эта история из-за того, что мне не понравился SQUID. Рискуя быть оплеванным сквидофилами все равно скажу - для меня это крайне неудобная софтина. Прежде всего в администрировании. Также мне не понравилась скорость работы SQUID'a, но это обстоятельство вытекает из его "неродной" для OS/2 природы.

Юниксоиды (и им сочувствующие:), конечно же, со мной не согласятся, но их можно понять. У них ведь, по большому счету, ничего функионально подобного SQUID'у в качестве кеширующего прокси нет, так что им волей-неволей приходится восхищаться SQUID'ом. В OS/2 же, к счастью, ситуация не такая безвыходная. В природе есть нативные ОСевые кеширующие прокси! Одному из них и посвящен данный обзор.

Кто есть кто

Сразу же хочу сказать, что IBM WEB Traffic Express (в дальнейшем - WTE) не единственный нативный кеширующий прокси. Есть еще IBM Internet Connection Server, IBM Internet Connection Secure Server, а так же Lotus GO WEB Server. Если последний является практически 100% функциональным аналогом WTE, то два первых - это довольно древние программы, хотя тоже вполне работоспособные. WTE занимает в этом ряду как бы среднюю позицию. Он старше ICS(S)'ов, но моложе Lotus GO WEB Server'a. Хотя, как я уже говорил ранее, IBM WTE - функционально практически аналогичен Lotus GO WEB Server'у. Мой выбор WTE для этого обзора обусловлен только практическими соображениями. У меня сейчас есть в распоряжении OS/2 интранет-сервер, на котором в качестве кэширующего прокси работает WTE v1.1.2. Забегая немного вперед скажу, что и SQUID там тоже имеется :). Есть у нас сквидофилы, которым нравится ходить в инет именно через SQUID. :)

Что из себя представляет IBM WEB Traffic Express ?

Это прежде всего полнофункциональный WEB-сервер с поддержкой CGI, JSP, авторизацией пользователей и т.д. Тем, кому интересны все его возможности, я рекомендую почитать документацию идущую в пакете с дистрибутивом. Данный же обзор посвящен одной из возможностей WTE - умение работать как кеширующий прокси сервер. Причем он может работать в цепочке других прокси-серверов. Наш WTE именно так и настроен. Есть главный кеширующий прокси (у провайдера) и наш WTE выходит в инет через него. Думаю, что сторонникам командной строки, T-Shell, detach, а также тем, кто любит после установки отдирать от серверов клавиатуры, мониторы и вообще все, что только можно отодрать оставив голую коробку системного блока лучше дальше не читать ибо это просто "ужасно"! У WTE PM интерфейс! (в зале слышны плевки, улюлюканья и хлопанье дверями). Ну, что ж, любителям "гнуть пальцы" - скатертью дорога...

Для тех, кто остался, я продолжаю свое повествование. Итак, у WTE графический интерфейс.

Вот его внешний вид:

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

Инсталляция и настройка параметров WTE

Насколько мне известно в виде отдельных дистрибутивов существуют 3 версии WTE: 1.0, 1.1.1 и 1.1.2. На самом деле их, конечно же, больше. Могу сказать, что WTE является составной частью IBM WEB Sphere серверов, а они существуют не только для OS/2 платформы, но давайте остановимся на последней "одиночной" версии WTE - 1.1.2.

Процесс инсталляции не должен вызвать у Вас сложностей. Там все очень просто и понятно. Единственное, что я хочу сказать в плане перевода WTE "на рельсы" кешируюшего прокси (а не HTTP-сервера) - указание порта отличного от стандартного 80 порта для HTTP протокола при соответствующем запросе инсталлятора. У меня, к примеру, WTE "сидит" на 8080 порту (3128-й порт занят сквидом). В принципе, все эти настройки можно спокойно внести и после инсталляции, так что не огорчайтесь если "упустили момент".
Если Вы не меняли путей, предлагаемых инсталлятором, WTE установится в каталог \WWW на Вашем диске. Исполняемые файлы лежат в \WWW\BIN, лог-файлы - в \WWW\LOGS и т.д. Учитывая то обстоятельство, что кеширующий прокси сервер много работает с диском, а также наличия файлов с длинными именами я настоятельно рекомендовал бы Вам устанавливать WTE на HPFS раздел. Для увеличения производительности можно установить HPFS386 драйвер. Поверьте мне - не пожалеете!

Итак, инсталляция завершена и Вам предлагается перегрузиться. Это требование связано с добавлением путей и переменных в CONFIG.SYS. Перегружайтесь.

После перезагрузки можно приступать к конфигурированию WTE. Это, пожалуй, самый главный этап всей работы и он потребует от Вас внимания и понимания того, что Вы делаете. Конфигурирование само по себе не представляет технической сложности. Конфигурационный файл WTE называется httpd.cnf и располагается там, куда указывает системная переменная %ETC% - обычно это \MPTN\ETC каталог. HTTPD.CNF является обычным текстовым файлом в котором для каждого параметра присутствует целый блок комментариев (правда на английском). Т.е Вы можете редактировать этот файл из любого текстового редактора, а чтобы WTE воспринял изменения необходимо его перезапустить. Те, кто уже знаком с настройкой параметров SQUID'a, ничего нового пока не узнали, однако у WTE есть очень удобная возможность настройки с удаленного компьютера. Нет, не телнетом, хотя можно и им, но это было бы слишком "в лоб". Оставим телнет сквидофилам. :)

Хочу напомнить, что WTE является в первую очередь полноценным WWW-сервером и неудивительно, что IBM предусмотрела возможность редактирования параметров в HTTPD.CNF из любого WWW-броузера, с любой машины в сети. Потребуется только пройти авторизацию. Указать имя и пароль администратора. Подобное конфигурирование может и несколько медленнее, но гораздо более информативно и удобно (особенно для начинающих администраторов). Если для задействования изменененных параметров необходим перезапуск WTE, то WWW-интерфейс Вам нарисует кнопочку "Restart" нажав которую на WTE отправится команда о перезапуске. Обратите внимание - в этом случае задача WTE не закрывается! Просто сервер останавливается и стартует снова. Этот процесс наглядно отображается в его PM окошке.

Раз уж мы заговорили о наглядности PM окошка и удаленном WWW управлении было бы неплохо это PM окошко наблюдать на той машине, с которой осуществляется управление. WTE и это позволяет сделать. Естественно графический вид окошка не передается. Передаются только основные параметры отображаемые в нем. Любознательные админы сами найдут как добраться до этой возможности, а для ленивых админов :) я укажу конкретную ссылку: "Server Activity Monitor" = http://WTE_host_address:порт/Usage/Initial

На страничке мониторинга 4 ссылки: "Basic status", "Network status", "Access log" и "Proxy log", а также кнопка "Refresh now" для обновления вывода.

Рассказывать про удаленное управление WTE через WWW-интерфейс можно очень долго и много, но так как там все понятно даже на интуитивном уровне я ограничусь темой данного обзора. Итак, давайте рассмотрим...

Параметры отвечающие за работу WTE в качестве кеширующего прокси

#        Port directive:
#
#        Port used by the server.
#        NOTE: If you are not root, you have to use a port above 1024;
#              good defaults are 8000, 8001, 8080.
#
#        Default:  80
#        Syntax:   Port {num}
Port  8080

#        If you want logging, specify locations for your logs:
#
#           AccessLog      - used for logging local document requests
#           AgentLog       - used for logging browser requests
#           RefererLog     - used for logging requests which are refered
#           ErrorLog       - used for logging any errors
#           CgiErrorLog    - used for logging any CGI errors
#           ProxyAccessLog - used for logging proxy requests
#           CacheAccessLog - used for logging hits on proxy cache
#                            (only valid if server running as proxy)
#
#        NOTE: To enable logging of requests to the proxy cache, the
#              following must be defined:
#
#              Caching MUST be turned ON (default is OFF)
#              CacheRoot MUST be defined (by default, no CacheRoot is defined)
#              CacheAccessLog MUST be defined
#
#        Defaults:  AccessLog     d:\www\logs\httpd-log
#                   AgentLog      d:\www\logs\agent-log
#                   RefererLog    d:\www\logs\referer-log
#                   ErrorLog      d:\www\logs\httpd-errors
#                   CgiErrorLog   d:\www\logs\cgi-error
#        Syntax:    {directive} {fullpath-filename}
# Example:
ProxyAccessLog   C:\WWW\LOGS\proxy-access
CacheAccessLog   C:\WWW\LOGS\cache
ErrorLog         C:\WWW\LOGS\error
AccessLog        C:\WWW\LOGS\access
AgentLog         C:\WWW\LOGS\agent
RefererLog       C:\WWW\LOGS\referer
CgiErrorLog      C:\WWW\LOGS\cgi-error

proxy-access.Aug312001
cache.Aug312001
error.Aug312001
access.Aug312001
agent.Aug312001
referer.Aug312001
cgi-error.Aug312001

Для анализа лог-файлов и составления красивых отчетов я настоятельно рекомендую использовать анализатор логов компании WEB Trends. К сожалению это Win32 приложение и оно не бесплатное, но ничего удобнее и лучше для подобной работы Вы просто не найдете. Я перепробовал несколько анализаторов и остановил свой выбор именно на "WEB Trends Log Analizer". Тем, кому он тоже понравится, я могу рассказать как умерить его меркантильный пыл. :)

Далее идут несколько блоков параметров также посвященных лог-файлам (формат логов, размер, вывод в PM-окно WTE и т.д.). Думаю Вы сами разберетесь какие параметры за что отвечают. Каждый блок параметров снабжен достаточными комментариями.

Следующий блок параметров (Mapping rules) является, пожалуй, самым интересным. Он отвечает за перенаправление(маппирование) запроса пользователя на определенный ресурс если запрос совпал с неким шаблоном. Как многие уже догадались - это тот самый фильтр баннеров, рекламы и порнографии, который будет вырезать все то, извиняюсь за выражение, информационное дерьмо, которым в последнее время буквально кишит интернет. Для организации фильтра контента достаточно всего двух директив: Pass и Fail. В качестве примера приведу часть своего фильтра контента:

Pass       http://ad*.*.*/*  C:\WWW\ICONS\empty.gif
Fail       http://ad*.*.*/*
Pass       http://az.yandex.ru/*  C:\WWW\ICONS\empty.gif
Fail       http://az.yandex.ru/*
Pass	   http://banne*.*.*/*  C:\WWW\ICONS\empty.gif
Fail	   http://banne*.*.*/*
Pass       http://www.penilesecrets.com/*  C:\WWW\ICONS\empty.gif
Fail       http://www.penilesecrets.com/*
Pass       http://ww*.yandex.ru/cgi-bin/*  C:\WWW\ICONS\empty.gif
Fail       http://ww*.yandex.ru/cgi-bin/*
Pass       http://*.linkexchange.*/*  C:\WWW\ICONS\empty.gif
Fail       http://*.linkexchange.*/*
Pass       http://ww*.reklama.ru/*  C:\WWW\ICONS\empty.gif
Fail       http://ww*.reklama.ru/*
Pass       http://affiliate.km.ru/img/*  C:\WWW\ICONS\empty.gif
Fail       http://affiliate.km.ru/img/*

В принципе для организации фильтра достаточно одной директивы Fail, но тогда на тех местах страничек, на которых должны "красоваться" реламно-порнушные баннеры, Вы бы наблюдали "дырки" с надписями "403 Forbidden by rule.", что, согласитесь, в плане эстетичности выглядит не очень привлекательно. Исправляет положение директива Pass, выполняющая подстановку катринки из файла empty.gif, на место того самого вырезанного баннера.

Что представляет из себя эта картинка? Да что угодно! Конкретно мой empty.gif представляет из себя прозрачное изображение размером 1х1. Т.е это просто невидимая картинка. Таким образом в окне броузера баннеры не только дезактивируются (с помощью Fail), но и становятся невидимыми (с помощью Pass).

К сожалению WTE не умеет налету залезать в поток данных для вырезания JavaScript выпоняющего открытие новых окон броузера (обычно рекламно-порнушного содержания), но все же можно попытаться если и не предотвратить это, то хотя бы запретить броузеру обращаться по этим адресам. Для этого достаточно директивы Fail с самыми общими щаблонами. У меня они имеют вид:

Fail       http://*porn*/*
Fail       http://*sex*/*
Fail       http://*xxx*/*
Fail       http://*erot*/*
Fail       http://*fuck*/*
Fail       http://*hardcore*/*

Следующие блоки параметров (Performance directives) отвечают за настройку производительности прокси сервера. Как и в любой другой области деятельности производительность чего либо будет максимальной только в случае индивидуального подхода к типу решаемых задач. Давайте рассмотрим блоки параметров отвечающие за производительность прокси сервера WTE. Итак:

#        MaxActiveThreads directive:
#
#        Defines the maximum number of threads in system thread pool.
#
#        Default:  40
#        Syntax:   MaxActiveThreads  {num}
MaxActiveThreads  32

А вот тут у меня стоит число в 2 раза превышающее значение по-умолчанию.

#        MaxPersistRequest directive:
#
#        Maximum number of request to receive on a persistent connection.
#
#        Default:  100
#        Syntax:   MaxPersistRequest {num}
MaxPersistRequest 200

#        ServerPriority directive:
#
#        Default:  1
#        Syntax:   ServerPriority  {0 | 1 | 2}
#
#        Note:    This is the priority on your system you want your server to run.
#                 0 -  background process (no priority)
#                 1 -  maximum priority as a background process
#                 2 -  maximum priority as a foreground process.
ServerPriority 1

Тайм-аут параметры (Timeout directives) тоже можно отнести к параметрам связанным с производительностью.

#
#        Use these directives to:
#           * limit the time to wait for the client to send a request
#             after connecting to the server before cancelling the connection.
#           * limit the time to allow for sending output to the client.
#           * limit the time to allow for server scripts to finish.
#             (If the program does not finish within allotted time, the server
#              will send a TERM signal and then a KILL signal 5 seconds later
#              to stop the program.)
#           * limit the time to wait for the client to send a request
#             after establishing a persistent connection to the server
#             before cancelling the connection.
#
#        Default:  InputTimeout    2 minutes
#        Default:  OutputTimeout  20 minutes
#        Default:  ScriptTimeout   5 minutes
#        Default:  PersistTimeout  10 secs
#        Syntax:   {directive} {time-spec}
InputTimeout   30 secs
OutputTimeout  20 minutes
ScriptTimeout   5 minutes
PersistTimeout 10 secs

Теперь рассмотрим несколько блоков параметров управляющих прокси-сервером в цепочке других прокси.

#
#        Specify the protocols that this proxy server will forward:
#
Proxy   http:*
Proxy   ftp:*
#Proxy   gopher:*

А в этом блоке параметров Вы указываете адрес следующего прокси сервера, причем хочу обратить Ваше внимание, что для разных протоколов можно указать разные прокси сервера!

#
#        Proxy-to-Proxy directives:
#
#        Pass requests for a particular protocol to another (proxy) Web Server
#        instead of contacting the the system named in the URL.
#
#        Default:  {none}
#        Syntax:   {request_proxy} {URL}
#
# Example:
http_proxy    http://192.168.1.15:3128/
ftp_proxy     http://192.168.1.15:3128/
# gopher_proxy  gopher://other.proxy.name/

Следующий блок параметров отвечает за "хождение напрямую". Т.е можно указать WTE, что запросы определенных адресов не надо проксировать.

#
#        no_proxy directive:
#
#        Specify the domains to which the server should directly connect.
#        Specify the value as a string of domain names or domain name
#        templates. Separate each entry in the string with a comma.
#
#        Do NOT put any spaces in the string.
#        You CANNOT use the wildcard character (*).
#        You CAN specify a template by including only the last part of a domain name.
#
#        Default:  {none}
#        Syntax:   no_proxy {non-proxy domain specification}
#
# Example:
no_proxy   .ourdomain.ru,.ourdomain.net,192.168,10.10

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

#
#        Turn on proxy caching here.
#
#        NOTE: You MUST also specify the CacheRoot directive.
#
#        Default:  off
#        Syntax:   Caching {on | off}
Caching on

Потом надо указать где, собственно, Вы собираетесь хранить кеш:

#
#        CacheRoot directive:
#
#        Specify the directory that the server will use for caching files.
#        If this directory is not specified, the proxy server will not attempt
#        to cache documents.
#
#        NOTE: If this directive is specified using the Configuration and
#              Administration forms, the directory will be created automatically.
#              If you define the directory by manually editing the configuration
#              file, you need to create the directory with the appropriate
#              permissions to enable the server to cache documents in it.
#
#        NOTE: You MUST also turn "on" the Caching directive.
#
#        Default:  {none}
#        Syntax:   CacheRoot {directory}
#
# Example:
CacheRoot       c:\www\cache

Следующий блок параметров отвечает за установку срока хранения информации в кеше.

#
#        CacheDefaultExpiry directive:
#
#        Specify the expiry date for files which do not include an explicit
#        expiry date and do not have a last-modified date that would allow us
#        to compute an expiry based on the CacheLastModifiedFactor. This is
#        most useful for protocols that do not have any way to transmit this
#        information, such as FTP or Gopher.
#
#        NOTE: The default expiration for HTTP is 0. HTTP should be kept at 0
#              because many script programs don't give an expiration date, yet
#              their output expires immediately. A value other than zero may
#              cause problems.
#
#        Defaults:  http:*    0 days
#                   ftp:*     1 day
#                   gopher:*  2 days
#        Syntax:    CacheDefaultExpiry {URL pattern} {time period}
#
# Example:
# CacheDefaultExpiry ftp:*   1 hour

CacheDefaultExpiry     http:*         0 days
CacheDefaultExpiry     ftp:*          1 day
# CacheDefaultExpiry     gopher:*       2 days

А вот этот блок отвечает за настройку временного промежутка хранения неиспользующихся файлов в кеше WTE. Забегая немного вперед скажу, что процесс автоматического удаления неиспользуемых файлов из кеша называется Garbage Collection.

#
#        CacheUnused directive:
#
#        Specify how long the proxy cache should keep files which have not
#        been used (requested by a client). Unused files which have been in
#        the cache longer than this will be removed during garbage collection.
#
#        Default:  {none}
#        Syntax:   CacheUnused {URL pattern} {time period}
#
# Example:

CacheUnused   ftp:*    1 day
CacheUnused   http:*   2 days
# CacheUnused   gopher:* 1 day

Следующий блок параметров отвечает за установку верхнего и нижнего лимитов на размер кешируемых файлов:

#
#        CacheLimit_1 and CacheLimit_2 directives:
#
#        The caching system has two limits for filesizes. The upper limit
#        (CacheLimit_2) specifies the maximum size for any file that will be
#        cached. The lower limit (CacheLimit_1) is used by the garbage-collection
#        algorithm to decide what pages to remove from the cache. Any files smaller
#        than the lower limit will not have their size considered when the server
#        decides what files to remove from the cache; files larger than the
#        lower limit are progressively more likely to be removed from the cache.
#        The value for CacheLimit_1 and CacheLimit_2 can be specified in
#        bytes (B), kilobytes (K), megabytes (M), or gigabytes (G).
#
#        Default:  CacheLimit_1  20 K
#                  CacheLimit_2  400 K
#        Syntax:   CacheLimit_1  {bytes} {B|K|M|G}
#                  CacheLimit_2  {bytes} {B|K|M|G}
#
# Example:
# CacheLimit_1 4 K
# CacheLimit_2 64 K

CacheLimit_1       20 K
CacheLimit_2       400 K

А вот этот блок параметров отвечает за установку периода в течении которого кешированный файл будет заблокирован для изменения:

#
#        CacheLockTimeOut directives:
#
#        Specify how long a file being cached can remain locked.
#
#        NOTE: Set CacheLockTimeOut to a value equal to
#              or greater than OutputTimeOut.
#
#        Default:  20 Mins
#        Syntax:   CacheLockTimeout {num} Mins
#

CacheLockTimeOut  20 Mins

Данный блок параметров отвечает за указание URL с которых только либо надо кешировать, либо вообще не надо кешировать. Чаще всего этот блок параметров закомментирован, так как редко кому нужны подобные крайности, но все же он есть и этот факт только добавляет WTE функциональности:

#
#        CacheOnly and NoCaching directives:
#
#        The server allows control over the files to be cached in two ways.
#
#        CacheOnly - specifies a set of URLs which will be considered for
#                    caching (URLs not in that list will never be cached)
#        NoCaching - specifies a set of URLs which must never be cached,
#                    (all other URLs are candidates for caching)
#
#        Default:  {none} (for both CacheOnly and NoCaching)
#        Syntax:   CacheOnly {URL pattern}
#                  NoCaching {URL pattern}
#
# Example:
# CacheOnly   http://www.ibm.com/*
# NoCaching   http://www.ourdomain.ru/*

Следующий блок отвечает за установку размера кеша (в мегабайтах) на диске компьютера. Это весьма важный и полезный параметр и его, как и остальные параметры, надо устанавливать хорошенько поразмыслив над вопросом о достаточности не в ущерб производительности:

#
#        CacheSize directive:
#
#        Specify the size of the proxy server's cache (in megabytes).
#
#        Default: 5 M (5 megabytes)
#        Syntax:  CacheSize {size} M
#
# Example:
# CacheSize 20 M
CacheSize       500 M

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

#
#        Gc (Garbage Collection) directive:
#
#        In order for a caching proxy server to function efficiently, it needs to
#        sweep through the cache and remove out-of-date files on a regular basis.
#        This is called 'garbage collection'. It should only be turned "off" in
#        special circumstances, such as during an extended network outage.
#
#        Default:  on
#        Syntax:   Gc {on | off}
Gc on

#
#        GcDailyGc directive:
#
#        Because garbage collection can take a significant amount of CPU resources,
#        it should be scheduled to take place when the load on the proxy server is
#        low. Use this directive to specify the time for garbage collection, using
#        a 24-hour clock; this will be assumed to be local time (not GMT).
#
#        Default:  03:00
#        Syntax:   GcDailyGc {hh:mm}
#
# Example:

GcDailyGc 03:00

Как и любому процессу GC нужна оперативная память для ее выполнения. Следующий блок параметров как раз отвечает за это:

#
#        GcMemUsage directive:
#
#        Used to restrict the amount of memory used by the garbage collection
#        process. Memory usage is specified in Kbytes (only). Setting this to
#        a small value will cause garbage collection to be extremely inefficient.
#        The minimum value is 20.
#
#        Default:  1000
#        Syntax:   GcMemUsage {Kbytes}
#
# Example:

GcMemUsage 32000

На этом мой обзор WTE, как кеширующего прокси сервера, завершен. Я надеюсь, что смог доходчиво и в полной мере рассказать как использовать этот продукт в данном качестве и с помощью этого обзора Вы сможете настроить WTE для решения Ваших задач. Но если вдруг Вам все же что-то непонятно или же Вы считаете, что некоторые вопросы недостаточно полно освещены в этой статье, то я настоятельно рекомендую Вам прежде чем обращаться с расспросами к автору или в различные конференции - почитайте документацию. Она у WTE очень полная и там все очень подробно изложено. Думаю Вам удастся найти ответы на Ваши вопросы в первую очередь именно там.

Также хочу сказать: не бойтесь экспериментировать с параметрами! (естественно не наобум, а сознательно) Ничего плохого не случится. Максимум что может быть - просто неработоспособный прокси, но, с другой стороны, если Вам удастся его настроить под свои задачи, Вы получите ни с чем не сравнимый практический опыт, который поможет Вам же в дальнейшей работе.

Ссылки: