Андрей Тр. aka RH писал(а):Все же с этого места можно поподробнее ? Просто я сам со Сквидом напрямую не общаюсь. Что есть дисковая система под названием null и ежели контент не кэшируется, то почему это sotware называется прокси-сервер ( "proxy" = "близкий" ). Я всю жизнь считал, что основная функция прокси-сервера - предоставлять локальную копию контента в ответ на запросы клиентов ( обновлять ее в кэше по истечению срока и т.д. ). Остальное уже как бы бонус ( управление полосой пропускания, фильтрация контента и пр. ).
О терминах - "proxy" - посредник, представитель. И NAT почти прокси, и портмаппер любой, и SOCKS все частные случаи прокси серверов, кеширующий прокси сервер тоже.
Что именно кешировать можно, а что нельзя не нарушая RFC для всех кеширующих проски едино (за искючением недопонимания RFC) т.е. все что говорилось ранее о том что процент попаданий к кеш не является характеристикой продукта - верно на 100%, пару телодвижений по исходникам и Squid будет кешировать вообще все, включая POST запросы, только кому это понравится?
А вот количество запросов в секунду (вспомните Nimda, CodeRed на СЕРВЕРАХ - это же 600 req/sec!!!! с одного сервера и 200 req/sec с одного W2K Pro, простите, но Squid с этим не живет, найти и убить в небольшой организации - реально, а возьмите ISP! Им-то что делать?) масштабируемость (гигабитный интерфейс), реальное снижение нагрузки на дисковую подсистему при изменении железа (типа SCSI Ultra 320), позволяет ли конфигурация кеширующего прокси бороться с бичом РуНет-а в настройках по умолчанию - Apache RUS (Expired: 01-Jan-1970...), работа со сторонними системами фильтрации контента (а это деньги, которые можно снять с клиента - все в подряд - по стандартным расценкам, без вирусов, окошек, толстых баннеров - по другим) это то что волнует при выборе производителя кеширующего прокси.