|
<< Click to Display Table of Contents >> Прокси-сервер, настройки и возможности |
  
|
|
<< Click to Display Table of Contents >> Прокси-сервер, настройки и возможности |
|
HTTP прокси-сервер и SOCKS работает на всех IP-адресах внутренних интерфейсов, в том числе на локальном (127.0.0.1). С внешних сетей он всегда недоступен.
Прокси-сервер, входящий в Traffic Inspector – это классический HTTP/FTP прокси-сервер. Учитывая наличие NAT, где производительность работы существенно выше, служба, на первый взгляд, необязательная. Но его применение во многих случаях целесообразно, поскольку обеспечивает следующие возможности.
Прокси-сервер поддерживает туннельные TCP-соединения методом CONNECT, позволяя работать с протоколом SSL.
Если требуется работа через прокси-сервер с приложениями, которые используют входящие TCP- и UDP-соединения со стороны пользователя, то использование SOCKS-сервера – единственная возможность это сделать. Текущая версия программы поддерживает SOCKS версии 4 и 5.
Для ограничения доступа пользователей по протоколу SOCKS используются правила (подробнее см. в п. Виды и предназначение правил, наборы правил), но при этом условия уровня приложений не работают. Для вторичных соединений, как входящих, так и исходящих, правила на запрещение не применяются – любой трафик с хостом, на который установлено первичное соединение, не блокируется.
Особенности реализации протокола HTTP/1.1
Прокси-сервер оптимизирован для работы с протоколом HTTP/1.1, полностью соответствует стандарту RFC 2616, в нем реализованы механизмы Keep-Alive и Pipelining.
Keep-Alive – процедура удержания и повторного использования TCP-соединений. Все современные браузеры и большинство веб-серверов ее поддерживают, но для них могут потребоваться особые настройки. Использование Keep-Alive существенно экономит трафик, что особенно заметно при загрузке страниц с большим количеством объектов. В некоторых случаях это приводит к ускорению загрузки страниц.
Pipelining – возможность в рамках одного TCP-соединения передавать запросы, не дожидаясь принятого ответа от сервера. Если на странице объектов много, то браузер отправляет сразу все запросы на сервер через одно TCP-соединение. В прокси-сервере Traffic Inspector реализована параллельная асинхронная обработка запросов и ответов: данные запросов также сразу отправляются на сервер, при этом количество запросов в очереди не ограничено.
Функция Pipelining поддерживается не всем веб-серверами и не всеми браузерами. Кроме того, в некоторых браузерах она по умолчанию отключена (подробнее см. документацию на соответствующие браузеры). Нужно учитывать, что если исходящий канал медленный или время отклика сервера большое (большие задержки в каналах связи), то использование Pipelining существенно ускоряет загрузку данных.
Все эти функции работают и в режиме каскадирования на другой прокси-сервер, но здесь все зависит от поддержки данных функций на вышестоящем прокси. Наиболее распространенные прокси-сервера – ISA и Squid – в полном объеме Pipelining не поддерживают.
Особенности реализации кэширования
Кэширование в прокси-сервере выполняется путем сохранением загруженных страниц в кэше для их повторного использования при последующих обращениях к данным ресурсам. Это позволяет экономить трафик и ускоряет загрузку страниц при медленных каналах связи. Обратной стороной использования кэша является проблема получения всегда достоверных данных для сохраненных ресурсов – необходимо проверять, обновились ли они на веб-сервере. Стандарты на HTTP/1.1 и другие подробно регламентируют работу серверов, но реалии сети Интернет таковы, что не все им следуют. Задача получить реальную экономию за счет кэширования и при этом передать на пользователя достоверные данные оказывается весьма сложной и противоречивой.
Прокси-сервер Traffic Inspector позволяет произвести настройку кэша достаточно тонко в соответствии с поставленными задачами. При установке эти настройки включены в режим небольшого сбережения трафика, при этом пользователи практически всегда получают достоверные данные от сервера.
Алгоритм работы программы при кэшировании следующий.
При сохранении ресурса в кэше запоминается время его получения с сервера и время создания (модификации) на самом сервере. Правда, этот атрибут может и отсутствовать – сервер по какой-то причине может его не выдать. Если далее на прокси-сервер поступает запрос на доступ к этому ресурсу, а он есть в кэше, то производится вычисление параметра TTL – прогнозируемого времени жизни. Он берется как процент от времени, в течение которого ресурс существовал с момента его записи в кэш. Смысловым значением данного параметра является прогноз: если ресурс не изменялся какое-то время, то он и в дальнейшем не будет меняться.
Следует отметить, что серверы для некоторых ресурсов выдают атрибут времени существования объекта. Если он был выдан, то тдже сохраняется при кэшировании. При его наличии прогноз вычисляться не будет; TTL же определяется на основании этого атрибута. Использование времени существования объекта, полученного от сервера, может быть отключено. Причина в том, что данный параметр довольно часто по вине небрежности программистов и администраторов веб-сервера выдается некорректным, и для определения TTL лучше полагаться на собственную логику.
На полученное значение TTL дополнительно накладываются ограничения по минимуму и максимуму. Если на момент запроса текущее время не превысило TTL, то ресурс считается непросроченным, в этом случае он берется из кэша. Иначе ресурс будет считаться просроченным. А значит его потребуется перепроверить на сервере, для чего посылается соответствующий запрос с условиями проверки. Если сервер такие запросы поддерживает, и ресурс за последнее время не изменен, то после ответа сервера ресурс будет взят из кэша. Такой ответ по размеру данных гораздо меньше полного ответа с самим объектом, но для экономии трафика желательно минимальное количество подобных проверок.
Вычисление TTL и прогнозирование можно совсем отключить – прокси-сервер перепроверяет ресурсы всегда. Экономия трафика сведется к минимуму, зато пользователи будут иметь гарантированно свежие данные.
Данные могут быть отмечены и как личные – иметь HTTP-атрибут private. Они будут кэшироваться, но в дальнейшем доступны из кэша только тому пользователю, кто их сохранил. Cookie с сервера также сохраняются в кэше и выдаются в будущем пользователю. Но, если данные отмечены как личные и имеют cookie, то в кэш они не записываются. Подразумевается, что они могут нести важные личные сведения. Плюс к тому отметим, что кэшируются только запросы типа GET.
Таким образом видно, что для увеличения реальной экономии трафика за счет кэширования следует увеличивать параметры, связанные с вычислением TTL. Для того чтобы при этом можно было нормально просматривать быстроменяющиеся ресурсы, в Traffic Inspector предусмотрена возможность оперативного переключения режимами кэширования самим пользователем с помощью агента (подробнее об агентах см. в п. Клиентский агент Windows).
Для большего сбережения трафика можно рекомендовать следующие параметры: TTL – 70-150%, минимум 12-24 часа, максимум 15-30 дней. При таких настройках можно экономить до 25-35% трафика, но придется переключать режимы кэширования агентом при посещении быстрообновляемых ресурсов.
Для облегчения этой работы есть возможность для отдельных ресурсов задавать собственные правила кэширования. В них для соответствующих сайтов задаются индивидуальные параметры кэширования.
Данные кэша хранятся в одном большом файле, он имеет постоянный размер и сразу создается при конфигурировании прокси-сервера. Это позволяет полностью исключить фрагментацию файловой системы. Внутри кэша данные фрагментации не подвержены. Алгоритм размещения объектов в кэше очень эффективен и позволяет без ухудшения производительности работать с большим количеством объектов. Данные в кэше не имеют ограничений по времени хранения. Если лимит свободного места в кэше исчерпан, то по необходимости будут удаляться объекты, имеющие наибольший срок хранения.
Индекс кэша реализован в виде SQL-базы данных, файл proxy.db3. В случае потери или порчи файла индекса данные в кэше будут потеряны.
Подробно настройка кэширования и правила кэширования описаны в п. Кэширование и правила кэширования.
Особенности преобразования и анализа контента
Прокси-сервер может работать с различным типом контента и форматом получаемых данных. В процессе передачи данных от сервера пользователю во время работы сервера данные могут быть преобразованы.
Компрессию должен поддерживать, прежде всего, веб-сервер. Он обычно настраивается так, чтобы сжимать не все типы данных, а только те, для которых это имеет смысл (например, картинки типа gif, jpeg или архивы сжимать бессмысленно). Сервер будет выдавать сжатые данные, только если в пользовательском запросе есть HTTP-атрибут, заявляющий о поддержке клиентом соответствующих форматов компрессии данных. Компрессия обычно применяется в запросах по протоколу HTTP/1.1.
Прокси-сервер поддерживает форматы компрессии gzip и deflate, т.е. он может их при необходимости распаковывать. Если браузер сам поддерживает компрессию, то прокси-сервер будет распаковывать сжатые данные только по необходимости. Имеется режим, позволяющий использовать компрессию в том случае, если браузер ее не поддерживает.
В кэш могут записываться как сжатые данные, так и несжатые. При выборке сжатых данных из кэша прокси-сервер также будет их распаковывать по необходимости.
Если браузер запросил сжатые данные и сервер выдал их в формате компрессии, который прокси-сервер не поддерживает, то такие данные будут прозрачно переданы пользователю.
В прокси-сервере предусмотрено два режима передачи контента от сервера пользователю – потоковый и с предварительной загрузкой. В первом режиме данные с сервера передаются пользователю порциями прозрачно, сразу по мере их приема. Во втором режиме данные передаются пользователю только после получения всего объекта с сервера. Для небольших объектов большой разницы для пользователя нет, но для больших второй режим может вызывать проблемы – пользователь не видит процесса загрузки данных с сервера. Прокси-сервер использует второй режим только при необходимости, например, когда требуется распаковка сжатых данных или для антивирусной проверки.
Для данных, размер которых более двух гигабайт, может использоваться только потоковый метод. Такие файлы никогда не кэшируются, а антивирусная проверка для них недоступна. Кроме того, они не могут быть распакованы прокси-сервером.
Антивирусная проверка HTTP- и FTP-контента позволяет выявлять данные, зараженные вирусами, а также имеющие нежелательные составляющие: программы-шпионы, скрипты и т.д. Проверка данных выполняется антивирусными сканерами, которые являются дополнительными модулями программы (подробнее см. в п. Дополнительные модули).
С точки зрения антивирусной проверки оптимальным вариантом является использование режима с предварительной загрузкой (то есть проверка осуществляется только после полной загрузки объекта). В этом случае, если в объекте антивирусом найден вредоносное ПО, а файл лечению не поддается, то будет произведена фильтрация объекта аналогично срабатыванию правила на запрещение – выдано стандартное сообщение прокси-сервера о блокировке с отчетом антивирусного сканера, а для картинок и флеш-файлов – "пустышка".
При загрузке больших файлов использование этого режима может вызвать проблемы. Поэтому предусмотрен режим антивирусной проверки "по последнему пакету". В этом случае данные передаются пользователю прозрачно, антивирусная проверка производится только тогда, когда с сервера пришел последний пакет. Если в данных антивирус что-то найдет, последний пакет пользователю передаваться не будет, т.е. файлы будут неполные, архивы повреждены.
Лечение зараженных данных в этом режиме уже невозможно. Также существует вероятность того, что даже не полностью загруженный зараженный файл будет представлять опасность. На браузер пользователя в этом случае никакого предупреждающего сообщения не выдается. Поэтому в настройках прокси-сервера предусмотрено много настроек, позволяющих гибко задавать условия выбора этих режимов (подробнее см. в п. Основные настройки прокси-сервера).
Все данные о выявлении вирусов записываются в отдельный общий журнал, плюс отправляется сообщение на агент пользователя.
Реализация режимов перенаправления трафика на прокси-сервер
Работа через прокси-сервер позволяет реализовать более тонкий контроль за HTTP-трафиком, т.к. доступна информация прикладного уровня. Со стороны пользователя с помощью настроек браузера можно выбрать, использовать прокси-сервер или нет. И у администратора не всегда имеет возможность выставить эти настройки принудительно.
Для принудительного перенаправления HTTP-трафика на прокси-сервер в Traffic Inspector реализована специальная функция, реализованная на уровне драйвера программы. Перенаправление на прокси-сервер программы происходит в момент начала TCP-соединения. Однако в данный момент еще неизвестно, какой протокол уровня приложений (HTTP или другой) будет использоваться. Поэтому перенаправление может быть произведено только для TCP/80, причем в данном случае перенаправляется любой TCP-трафик.
Аутентификация браузера с прокси-сервером здесь невозможна, т.к. браузер "не знает", что работает через прокси. Для этого при авторизации по имени придется обязательно использовать агента (подробнее см. в п. Способы авторизации пользователей).
Следует учитывать возникновение в этом режиме некоторых других проблем, связанных с тем, что браузер при работе через прокси-сервер "не знает", как именно он работает. Поэтому стоит рассматривать режим только как меру пресечения работы пользователя мимо прокси-сервера. Оптимальным вариантом является настройка браузеров пользователей для работы с прокси-сервером.
В дополнение к этому в Traffic Inspector реализована функция блокирования любого другого HTTP-трафика, идущего мимо прокси-сервера, что позволит гарантированно пресечь работу пользователя мимо прокси-сервера. Применение этих функций задается отдельно для пользователей (авторизованный трафик) и "неавторизованного пользователя". Они настраиваются в общих настройках пользователей (подробнее см. в п. Общие настройки пользователей), свойствах групп (подробнее см. в п. Создание и настройка групп) и свойствах отдельных пользователей (подробнее см. в п. Создание и настройка пользователей).
Данные функции никогда не применяются для трафика:
Также в Traffic Inspector реализована функция перенаправления любых TCP-соединений со стороны пользователей, с помощью которой можно гибко реализовать Transparent Proxy для любого HTTP-трафика на любой прокси-сервер (подробнее см. в п. Перенаправление запросов).
Особенности реализации протокола FTP
Обычно для FTP лучше всего использовать NAT. Но могут быть случаи, когда полезны и другие варианты работы.
Для работы с FTP-серверами в режиме только чтения такими браузерами, как Mozilla или Opera, использутся метод GET. В этом случае прокси-сервер будет генерировать HTML-страницы каталогов FTP-сервера. Активный или пассивный режим при этом может выбираться автоматически. Достоинство этого метода – наличие фильтрации по контенту.
Полноценную работу с FTP обеспечивает SOCKS. Доступны все режимы активный и пассивный.
Особенности тарификации и учет трафика в прокси-сервере и SOCKS
В программе предусмотрено два метода съема трафика с целью учета при работе пользователя через прокси-сервер и SOCKS.
Режим учета в каждой сессии прокси-сервера и SOCKS отображается в консоли с целью диагностики работы программы.
Режимы выбираются автоматически. Логика выбора режима учета такова, что application-режим выбирается только тогда, когда kernel использовать возможности нет.
Для HTTP-прокси в kernel-режиме трафик снимается на интерфейсе, через который идет соединение между прокси-сервером и веб-сервером. Если этот интерфейс в программе не назначен, то используется режим application.
Для FTP через HTTP используется режим application.
Для SOCKS всегда используется kernel-режим, но трафик снимается между пользователем и SOCKS-сервером.
Во время работы через спутник пакеты TCP-сессии передаются и принимаются на разных интерфейсах. Для того, чтобы корректно работал kernel-режим, при конфигурировании надо обязательно указать интерфейс, на котором принимаются пакеты, иначе входящий трафик учитываться не будет (подробнее см. в п. Конфигуратор).