World Wide Web Введение

Вид материала

Документы

Содержание Согласование кодировок сервера и программы просмотра Netscape Navigator 3.0 Протокол HTTP Отсутствие «навигации» Нет поддержки распределённости История развития Структура протокола Коды состояния 2xx Success 3xx Redirection 4xx Client Error 5xx Server Error Заголовки HTTP Http/1.0 200 ok Как это работает Открытый прокси-сервер Причины возникновения Запреты на анонимные открытые прокси-серверы

Подобный материал:

• Введение. Из истории сетевых технологий, 341.5kb.
• «История Интернет», 57.92kb.
• Юридические аспекты применения сети Интернет в России Введение, 1695.12kb.
• Утина (World Wide Web или сокращенно www) название самого распространенного на сегодняшний, 335.68kb.
• Всемирная паутина. Файловые архивы. Поиск информации в сети Интернет, 167.86kb.
• Монография: Позитивная семиотика (о знаках, знаковых системах и семиотической деятельности), 2604.26kb.
• Transmission Control Protocol / Internet Protocol (Протоколы управления процессом передачи, 479.59kb.
• Лабораторная работа, 157.58kb.
• Роль Интернет-услуг в практической маркетинговой деятельности, 294.77kb.
• 1 Призначення html, 333.23kb.

Согласование кодировок сервера и программы просмотра

Если попытаться прочитать русскоязычный WWW-документ, закодированный при помощи одной кодовой таблицы, программой просмотра, использующей шрифты, рассчитанные на другую таблицу, то русский текст будет выглядеть как бессмысленный набор знаков. Например, слово Привет!, высланное сервером в кодировке KOI8-r, при использовании программой просмотра шрифта в кодировке Windows-1251 выглядит на экране как «рТЙЧЕФ!» Еще "забавнее" - - изображает это слово программа просмотра, "думающая", что этот документ написан на одном из европейских языков в кодировке Latin-1. Как же заставить сервер и программу просмотра настроиться на какую-либо одну кодировку?

Иногда заботу о соответствии кодовых таблиц сервера и программы просмотра берет на себя сервер. При этом он должен определить кодировку, на которую настроена программа просмотра, и высылать документы именно в этой кодировке. Для автоматического определения используется возможность протокола HTTP 1.0 передавать в заголовке запроса перечисление допустимых форматов документов и наборов символов MIME content-type и charset. По многим причинам этот подход довольно часто не срабатывает. В таком случае авторы документов, размещенных на сервере, часто прибегают к более универсальному приему, предлагая читателю из нескольких гиперссылок выбрать ту, которая указывает на нужный документ в желаемой кодировке.

Некоторые программы просмотра, например, Netscape Navigator 3.0 и Microsoft Internet Explorer 3.0, умеют сами подстраиваться под кодировку документа, высылаемого сервером, если кодировка правильно указана в заголовке ответа WWW-сервера в специальном поле charset, предусмотренном протоколом HTTP 1.0. К сожалению, многие серверы не настроены так, чтобы добавлять это поле автоматически.


Протокол HTTP

HTTP (от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — сетевой протокол прикладного уровня передачи данных в виде текстовых сообщений. Основой протокола HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Протокол HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46%, из которых почти половина — это передача потокового видео и звука.

Основным объектом манипуляции в HTTP являются ресурс, на который указывает URL (ссылка) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но зачастую это могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формат, кодировка, язык и т.д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными хотя данный протокол является текстовым.

Достоинства

Простота. Протокол настолько прост в реализации, что позволяет с лёгкостью создавать не только клиентские приложения, но и примитивные сервера.

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

Распространённость. При выборе протокола HTTP для решения конретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различных документаций по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.

Недостатки

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

Отсутствие «навигации». Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов. Например, клиент не может явным образом запросить список доступных файлов как в протоколе FTP. Предполагалось, что конечный пользователь уже знает URI необходимого ему документа, закачав который он будет производить навигацию благодаря гиперссылкам. Это вполне нормально и удобно для человека, но затруднительно когда стоят задачи автоматической обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы лежит полностью на плечах разработчиков приложений, использующих данный протокол.

Нет поддержки распределённости. Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вообще не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается беспомощен. В 1998 году W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием внимания именно на этой области. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.

История развития

HTTP/0.9. HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодей­ствия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.

HTTP/1.0. В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.

HTTP/1.1. Последняя версия протокола. Последняя версия стандарта была принята в июне 1999 года. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.

Структура протокола

HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

• Стартовая строка (англ. Starting line) — определяет тип сообщения.
  
• Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения.
  
• Тело сообщения (англ. Message Body) — непосредственно данные сообщения.
  

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

Стартовая строка. Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI — для версии протокола 0.9.

Метод URI HTTP/Версия — для остальных версий.

Здесь:

• URI определяет путь к запрашиваемому документу.
  
• Метод (англ. Method) — английское слово в верхнем регистре, указывающее тип запроса. В версии HTTP 0.9 использовался только метод GET.
  
• Версия (англ. Version) — пара разделённых точкой арабских цифр. Например: 1.0.
  

Чтобы запросить странницу данной статьи клиент должен передать строку:

GET /wiki/Http HTTP/1.0

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния Пояснение

Здесь:

• Версия — пара разделённых точкой арабских цифр как в запросе.
  
• КодСостояния (англ. Status Code) — три арабские цифры. По коду статуса определяется дальнейшее содержимое сообщение и поведение клиента.
  
• Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
  

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

HTTP/1.0 200 Ok

Методы

• OPTIONS. Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.
  
• GET. Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: le.net/resource?param1=value1¶m2=value2). Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[4] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
  
• HEAD. Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения мета-информации, заданной в заголовках ответа, без пересылки всего содержимого.
  
• POST. Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. В отличие от метода GET, метод POST не считается идемпотентным[4], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
  
• PUT. Загружает указанный ресурс на сервер.
  
• DELETE. Удаляет указанный ресурс.
  
• TRACE. Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе.
  
• CONNECT. Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.
  

В основном используются методы GET и POST.

Коды состояния. Код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая указывает на причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния.

• 1xx Informational (русск. Информационный). В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
  
• 2xx Success (русск. Успешно). Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
  
• 3xx Redirection (русск. Перенаправление). Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект). Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производиться автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.
  
• 4xx Client Error (русск. Ошибка клиента). Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов кроме HEAD сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
  
• 5xx Server Error (русск. Ошибка сервера). Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
  

Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут информацию для браузера или для серверных программ (таких, как CGI-приложения). Между заголовками и телом обязательно должна быть пустая строка.

Пример диалога HTTP:

Запрос:

GET /wiki/HTTP HTTP/1.1

Host: ru.wikipedia.org

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Connection: close


Ответ:


HTTP/1.0 200 OK

Server: Apache

Content-Language: ru

Content-Type: text/html; charset=utf-8

Content-Length: 1234

(далее следует текст запрошенной страницы)

Протокол HTTPS

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP порт 443. Эта система была разработана компанией Netscape Communications Corporation, чтобы обеспечить аутентификацию и защищенное соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах. В настоящее время HTTPS поддерживается наиболее популярными браузерами.

Как это работает

Строго говоря, HTTPS не является отдельным протоколом. По сути это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Это обеспечивает защиту от атак, основанных на фальсификации либо прослушивании среднего уровня сетевого соединения — т.н. man-in-the-middle (например, от снифферских атак).


По умолчанию HTTPS использует 443 TCP-порт (для незащищенного HTTP — 80). Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен создать публичный ключ сертификата для этого веб-сервера. Такие сертификаты могут быть созданы для серверов, работающих под Unix, с помощью таких утилит, как ssl-ca от OpenSSL или gensslcert от SuSE. Сертификат должен быть подписан уполномоченной стороной (Certificate Authority), которая гарантирует, что держатель сертификата является тем, за кого себя выдает. Веб-браузеры обычно распространяются с подписями основных сертификационных организаций, поэтому они могут проверить сертификаты, выданные этими организациями.

Организации могут также выпускать свои сертификаты, особенно, если они сами ответственны за установку браузеров, которые будут открывать их сайты (например, в Интранете). Для этого можно просто добавить свои собственные подписи сертификатов в доверительный список браузера.

Некоторые сайты используют собственные сертификаты. Такое использование защищает от прослушивания, но без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) этот метод не будет являться вполне безопасным.

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

В HTTPS используется длина ключа всего 40, 56, или 128 бит. По мнению большинства специалистов по информационной безопасности, сегодня надежной длиной ключа может быть длина, сравнимая с 1024 бит. Поэтому длина ключа даже в максимальные 128 бит HTTPS явно недостаточна. Кроме того, большинство браузеров использует длину ключа 40 бит (пример тому — IE). Это связано с экспортными ограничениями в США. И, следовательно, не следует считать, что HTTPS обеспечивает достойный уровень шифрования. Но такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.


Прокси-сервер

Прокси-сервер (от англ. proxy — «представитель, уполномоченный») — служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, файл), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если прокси имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях.

Использование

Чаще всего прокси-серверы применяются для следующих целей:

• Обеспечение доступа с компьютеров локальной сети в Интернет.
  
• Кэширование данных: если часто происходят обращения к одним и тем же внешним ресурсам, то можно держать их копию на прокси-сервере и выдавать по запросу, снижая тем самым нагрузку на канал во внешнюю сеть и ускоряя получение клиентом запрошенной информации.
  
• Сжатие данных: прокси-сервер загружает информацию из Интернета и передаёт информацию конечному пользователю в сжатом виде. Такие прокси-серверы используются в основном с целью экономии внешнего трафика.
  
• Защита локальной сети от внешнего доступа: например, можно настроить прокси-сервер так, что локальные компьютеры будут обращаться к внешним ресурсам только через него, а внешние компьютеры не смогут обращаться к локальным вообще (они «видят» только прокси-сервер). См. также NAT.
  
• Ограничение доступа из локальной сети к внешней: например, можно запретить доступ к определённым веб-сайтам, ограничить использование интернета каким-то локальным пользователям, устанавливать квоты на трафик или полосу пропускания, фильтровать рекламу и вирусы.
  
• Анонимизация доступа к различным ресурсам. Прокси-сервер может скрывать сведения об источнике запроса или пользователе. В таком случае целевой сервер видит лишь информацию о прокси-сервере, например, IP-адрес, но не имеет возможности определить истинный источник запроса. Существуют также искажающие прокси-серверы, которые передают целевому серверу ложную информацию об истинном пользователе.
  

Многие прокси-серверы используются для нескольких целей одновременно. Некоторые прокси-серверы ограничивают работу несколькими портами: 80 (Браузер), 443 (Шифрованное соединение (HTTPS)), 20, 21 (FTP).

В отличие от шлюза, прокси-сервер чаще всего не пропускает ICMP-трафик (невозмо­ж­но проверить доступность машины командами ping и traceroute).

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

Открытый прокси-сервер

Открытый прокси-сервер — прокси-сервер, обрабатывающий запросы от любых IP-адресов в Интернете. В отличие от обычных прокси-серверов, которыми пользуется ограниченное количество доверенных лиц (обычно в зоне ответственности владельца прокси-сервера — например, в локальной сети), открытый прокси-сервер позволяет практически любому узлу сети обращаться через себя к другим узлам сети.

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

Причины возникновения. Прокси-сервер может быть сделан открытым (общедоступным) по воле владельца сервера или в результате неправильной конфигурации обычного прокси-сервера (ошибка при проверке принадлежности пользователя, в настройке «слушающего» интерфейса, в списке транслируемых портов в NAT/PAT).

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

Анонимные открытые прокси-серверы могут использоваться для обеспечения (частичной) анонимности в Интернете, так как скрывают IP-адрес пользователя, направляя все пользовательские запросы от своего адреса. При этом сам прокси-сервер может вести логи обращений.

Запреты на анонимные открытые прокси-серверы. Потенциальное использование открытых прокси-серверов для скрытия адреса пользователя приводит к тому, что сайты некоторых интернет-сервисов запрещают доступ к своим ресурсам с открытых прокси-серверов. Например, почтовые службы «Yandex» отказываются работать с пользователями открытых прокси-серверов.

Пример ошибочного появления открытого прокси. В приватной сети 192.168.0.0/8 установлен прокси-сервер 192.168.1.2, имеющий доступ во внешнюю сеть через NAT на маршрутизаторе с внешним адресом 100.100.100.100. Фильтрация запросов по IP-адресам не осуществляется (т. к. доступ к серверу имеют только пользователи локальной сети). Если в случае ошибки маршрутизатор начнёт пропускать пакеты из внешней сети на узел 192.168.1.2 (например, при настройке PAT для веб-сервера на узле 192.168.1.2 не будет ограничен список портов), то обращаясь к адресу, для которого настроен PAT (например, 100.100.100.101, где настроен веб-сервер на 80-ом порту) по порту прокси-сервера (например, 8080), любой пользователь сети сможет получить и отправить информацию через прокси-сервер, который и будет с этого момента считаться открытым.

Редиректор

Редиректор (англ. redirector, перенаправляющий) — модуль в прокси-серверах, отвечающий за фильтрацию и обработку адресов (URL) запросов от клиентов к серверам. Может быть как встроенным в прокси-сервер, так и запускающийся отдельным приложением (скриптом).

Задачи, решаемые с помощью редиректора:

• Закрытие доступа к определённым адресам по сложным критериям.
  
• Замена одного содержимого на другое (например, баннеров на пустые изображения)
  
• Выдача сообщения о точной причине запрета доступа к странице
  
• Выдача предупреждения о возможной фишинг-атаке (при наличии фишинг-фильтра)
  
• Анализ статистики обращения к определённым ресурсам (как разрешённым, так и запрещённым)
  

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


Черные и белые списки