Можно ограничивать скорость работы для отдельных пользователей, групп или ресурсов. Например, установить правило, чтобы файлы *.mp3 качались на скорости не более 1кб/сек, чтобы предотвратить забивание вашего интернет-канала трафиком меломанов, но не лишать их полностью этого удовольствия. Эта возможность, к сожалению, есть не во всех прокси. В Eproxy эта возможность есть. Она реализуется дополнением TrafC, который кроме ограничения пропускной способности (скорости) может ограничивать и суммарный трафик.
Ведутся журналы работы прокси – можно подсчитывать трафик за заданный период, по заданному пользователю, выяснять популярность тех или иных ресурсов и т.д.
Можно маршрутизировать веб-запросы – например, часть направлять напрямую, часть через другие прокси (прокси провайдера, спутниковые прокси и т.д.). Это тоже помогает эффективнее управлять стоимостью трафика и скоростью работы прокси вцелом.
Мы перечислили основные, но не все возможности HTTP-proxy. Но уже одних перечисленных достаточно чтобы убедиться, что без HTTP-proxy в серьезной сети не обойтись
FTP-прокси бывает двух основных видов в зависимости от протокола работы самого прокси. С ftp-серверами этот прокси, конечно, всегда работает по протоколу FTP. А вот с клиентскими программами – браузерами и ftp-клиентами (CuteFTP, FAR, и др.) прокси может работать как по FTP, так и по HTTP. Второй способ удобнее для браузеров, т.к. исторически является для них «родным». Браузер запрашивает ресурс у прокси, указывая протокол целевого сервера в URL – http или ftp. В зависимости от этого прокси выбирает протокол работы с целевым сервером, а протокол работы с браузером не меняется – HTTP. Поэтому, как правило, функцию работы с FTP-серверами также вставляют в HTTP-прокси, т.е. HTTP-прокси, описанный выше, обычно с одинаковым успехом работает как с HTTP, так и с FTP-серверами. Но при «конвертации» протоколов FTP<->HTTP теряется часть полезных функций протокола FTP. Поэтому специализированные ftp-клиенты предпочитают и специальный прокси, работающий с обеими сторонами по FTP. В Eserv и Eproxy мы называем этот прокси FTP-gate, чтобы подчеркнуть отличие от FTP-прокси внутри HTTP-прокси. Также этот прокси называется в некоторых ftp-клиентах. Хотя встречаются и вносящие путаницу названия. Например, в программе CuteFTP FTP-gate называют firewall, хотя FireWall в общем случае – это вообще не прокси, а фактически программа обратного назначения – не для подключения к интернету, а для изоляции от него
Для прокси в FireWall оставляют специальные «дыры». FTP-gate поддерживают различные способы указания в FTP-протоколе целевого сервера, с которым FTP-клиент хочет работать, в настройке FTP-клиентов обычно предлагается выбор этого способа.
HTTPS-прокси – фактически часть HTTP-прокси. S в названии означает “secure”, т.е. безопасный. Не смотря на то, что программно это часть HTTP-прокси, обычно HTTPS выделяют в отдельную категорию (и есть отдельное поле для него в настройке браузеров). Обычно этот протокол – безопасный HTTP – применяют, когда требуется передача секретной информации, например, номеров кредитных карт. При использовании обычного HTTP-прокси всю передаваемую информацию можно перехватить средствами самого прокси (т.е. это под силу администратору ЛС) или на более низком уровне, например, tcpdump (т.е. и администратор провайдера и любого промежуточного узла и вообще любой человек, имеющий физический доступ к маршрутам передачи ваших данных по сети, может при большом желании узнать ваши секреты). Поэтому в таких случаях применяют secure HTTP – всё передаваемое при этом шифруется. Прокси-серверу при этом дается только команда «соединится с таким-то сервером», и после соединения прокси передает в обе стороны шифрованный трафик, не имея возможности узнать подробности (соответственно и многие средства управления доступом – такие как фильтрация картинок – не могут быть реализованы для HTTPS, т.к. прокси в этом случае неизвестно, что именно передается). Собственно в процессе шифрации/дешифрации прокси тоже участия не принимает – это делают клиентская программа и целевой сервер. Наличие команды «соединиться с таким-то сервером» в HTTPS-прокси приводит к интересному и полезному побочному эффекту, которым все чаще пользуются разработчики клиентских программ. Так как после соединения с указанным сервером HTTPS-прокси лишь пассивно передает данные в обе стороны, не производя никакой обработки этого потока вплоть до отключения клиента или сервера, это позволяет использовать прокси для передачи почти любого TCP-протокола, а не только HTTP. То есть HTTPS-прокси одновременно является и простым POP3-прокси, SMTP-прокси, IMAP-прокси, NNTP-прокси и т.д. – при условии, что соответствующая клиентская программа умеет так эксплуатировать HTTPS-прокси (увы, далеко не все еще это умеют, но есть вспомогательные программы, «заворачивающие» трафик обычных клиентов через HTTPS-прокси). Никаких модификаций целевого сервера не требуется. Фактически HTTPS-прокси является программируемым mapping-proxy, как и Socks-proxy.
Mapping-прокси – способ заставить работать через прокси те программы, которые умеют работать с интернетом только напрямую. При настройке такого прокси администратор создает как бы «копию» целевого сервера, но доступную через один из портов прокси-сервера для всех клиентов локальной сети – устанавливает локальное «отображение» заданного сервера. Например, пользователи локальной сети хотят работать с почтовым сервером mail.ru не через браузер, а с использованием почтовой программы Outlook Express или TheBat?. Эти программы не умеют работать через прокси (кроме случая, когда Outlook получает почту по HTTP с hotmail.com – тогда он, как и браузер, пользуется HTTP-прокси). Простейший способ работать с mail.ru по POP3 через прокси – установить локальное отображение сервера pop.mail.ru. И в Outlook'ах вместо pop.mail.ru написать имя прокси-сервера и порт отображения. Outlook будет соединяться с прокси-сервером ("думая", что это почтовый сервер), а прокси при этом будет соединяться с pop.mail.ru и прозрачно передавать всю информацию между Outlook и pop.mail.ru, таким образом «превращаясь» на время соединения в POP3-сервер. Неудобство mapping-прокси в том, что для каждого необходимого внешнего сервера нужно вручную устанавливать отдельный порт на прокси. Но зато не требуется модификация ни серверов, ни клиентов. Особенно это помогает в случае необходимости «проксирования» многочисленных «доморощенных» протоколов, реализованных в играх или финансовых программах. Почему-то они часто игнорируют существование прокси и стандартных протоколов. Такие программы можно «обмануть» и направить через прокси практически всегда, если они не делают другой глупости – передачи клиентского IP-адреса внутри протокола и пытаются с ним соединяться напрямую еще раз (что невозможно, т.к. локальные адреса недоступны извне).
Socks-прокси. Об этом виде прокси и его уникальных возможностях мы писали отдельную статью в «Компьютерре» в марте 1998 года. С тех пор протокол Socks не менялся. А программ, работающих через Socks, стало заметно больше. Кроме того исправили ошибки ICQ при работе с Socks-сервером
Прочтите эту статью, может быть лучше прояснится и описанное выше. См. также Socks5
Если при прочтении этого краткого введения в мир прокси-серверов у вас возникли вопросы, или если вы нашли здесь неточности и ошибки – пишите нам, мы постараемся расширить и исправить описание.
Все перечисленные виды прокси (кроме NAT ) реализованы в Eserv и Eproxy. NAT реализован в Windows.
--
Андрей Черезов, 26 декабря 2001 г.
взято
http://www.eserv.ru/WhatIsProxyServer