Главная

Новости

Статьи и обзоры
  Горожанин
  Обнинск в Internet
  Web Design
  Hardware
  Software
  Безопасность
  Серфинг
  Игродром
  Relax
  Технологии
  Web-обзор
  Интернет-ликбез
  Опросник
  УП-Технологии
  ART.net

Ссылки

Архив

О нас

Контакты

Форумы

POPULAR.RU

ЗАЧЕМ НУЖЕН ПРОКСИ-СЕРВЕР?

© Олег Бринев

Продолжение: начало в №9(197)
FTP-ПРОКСИ

FTP-прокси бывает двух основных видов в зависимости от протокола работы самого прокси. С FTP-серверами этот прокси, конечно, всегда работает по протоколу FTP. А вот с клиентскими программами - браузерами и ftp-клиентами (CuteFTP, FAR etc) прокси может работать как по FTP, так и по НТТР. Браузер запрашивает ресурс у прокси, указывая протокол целевого сервера в URL - http или ftp. В зависимости от этого прокси выбирает протокол работы с целевым сервером, а протокол работы с браузером не меняется - НТТР. Поэтому, как правило, функцию работы с FTP-серверами также встраивают в НТТР-прокси, т.е. НТТР-прокси, описанный выше, обычно с одинаковым успехом работает как с НТТР, так и с FTP-серверами.

НТТРS-ПРОКСИ

НТТРS-прокси - фактически часть НТТР-прокси. "S" в названии означает "secure", т.е. безопасный. Обычно этот протокол применяют, когда требуется передача секретной информации, например, номеров кредитных карт. При использовании обычного НТТР-прокси всю передаваемую информацию можно перехватить средствами самого прокси (т.е. это под силу, например, администратору локальной сети). Поэтому в таких случаях применяют secure НТТР-протокол, и вся передаваемая информация при этом шифруется.

Mapping-ПРОКСИ

Mapping-прокси - способ заставить работать через прокси те программы, которые умеют работать с Интернетом только напрямую. При настройке такого прокси администратор создает как бы "копию" целевого сервера, но доступную через один из портов прокси-сервера для всех клиентов локальной сети - устанавливает локальное "отображение" заданного сервера. Например, если пользователи локальной сети хотят работать с почтовым сервером mail.ru не через браузер, а с использованием почтовой программы Outlook Express или The Bat!. Простейший способ работать с mail.ru по РОР3 через прокси - устанавливать локальное отображение сервера pop.mail.ru. И в Outlook вместоpop.mail.ru написать имя прокси-сервера и порт отображения. Outlook будет соединяться с прокси-сервером, а прокси при этом будет соединяться с pop.mail.ru и прозрачно передавать всю информацию между Outlook и pop.mail.ru, таким образом "превращаясь" на время соединения в РОР3-сервер. Неудобство Mapping-прокси в том, что для каждого необходимого внешнего сервера нужно вручную устанавливать отдельный порт на прокси.

Socks-ПРОКСИ

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

· Он не зависит от высокоуровневых протоколов (HTTP, FTP, POP3, SMTP, NNTP etc), так как осуществляет представительство клиентов на более низком уровне (TCP, UDP).
· Приложение в локальной сети может попросить Socks-сервер выступить в роли сервера от лица клиента. То есть приложение в локальной сети сможет принимать соединение извне, несмотря на отсутствие реального IP-адреса.

Вообще говоря, многие из описанных проблем решаются просто путем отображения портов с помощью Mapping-прокси, но Socks - более рациональное средство, не требующее, в отличие от МАР, знания тонкостей конкретных протоколов и приложений. Через Socks можно заставить работать даже приложения, которые и понятия не имеют о прокси! Например - Mirabilis ICQ, MS Internet Explorer, Netscape Navigator - хотя все же с некоторыми оговорками, о которых позже.
Фактически Socks-сервер является программно-управляемым Mapping-прокси, причем с описанным единым интерфейсом. Все Mapping-прокси так или иначе программно управляются, но под руководством администратора сети (человека), и отображения их портов статичны. А Socks-сервер управляется прикладными программами, и отображенния устанавливаются, только когда они нужны, и на то время, пока они нужны.
Но имеются и минусы у Socks-серверов. Во-первых, Socks-прокси не знает, какие высокоуровневые протоколы он через себя пропускает, он не может им "помогать". В основном это касается кэширования. Socks не может узнать, какие ресурсы сети извлекаются с его помощью, и соответственно, не может при следующем обращении к этому ресурсу "подставить" старое содержание немедленно без выполнения запроса. Во-вторых, когда клиентская программа просит Socks-прокси выполнить за него серверную функцию, он не гарантирует, что он обратится именно к тому номеру порта, который хотел бы клиент, так как на шлюзовой машине этот порт может быть уже занят другим сервером или другим потоком Socks-сервера, обслуживающим другого клиента.
Таким образом, почти невозможно организовать работу, например, Web-сервера, находящегося внутри локальной сети, но принимающего соединения через Socks-сервер, - так как внешний клиент не будет заранее знать, с каким портом соединяться. Для выдачи постоянных внутренних серверов "наружу" через прокси лучше пользоваться обычным Mapping-прокси с постоянным отображением портов.

Продолжение следует.