Как сделать Squid+c-icap

Аватар пользователя Meloman

Сравнивая эту статью и эту, я сделал выбор в пользу второй. Во второй есть конфигурация, которая не работает:

Цитата:
Добавление поддержки ICAP в squid.conf

При старте SQUID "ругается", что эти строки ему вообще не знакомы. Верно ли это? Или нужны какие-то дополнительные действия?

Аватар пользователя DRVTiny

Re: Как сделать Squid+c-icap

Не знаю уж, чем Вас HAVP не устроил (во всяком случае, памяти он кушает несколько меньше, нежели SQUID с I-Cap'ом), но вообще 3-я версия SQUID, в отличие от "знакомой до боли" версии 2.5, поддерживает протокол I-Cap безо всяких дополнительных плясок с бубном, так что статья на nixp.ru уже морально устарела. Что, впрочем, относится и к моей статье-"инструкции по применению HAVP", опубликованной на этом сайте.

Аватар пользователя sergeil

Re: Как сделать Squid+c-icap

DRVTiny писал(а):
3-я версия SQUID, в отличие от "знакомой до боли" версии 2.5, поддерживает протокол I-Cap безо всяких дополнительных плясок с бубном

O, хорошая новость... не знал, спасибо...

Аватар пользователя DRVTiny

Re: Как сделать Squid+c-icap

Цитата:
O, хорошая новость... не знал, спасибо...

Наздоровье Улыбка

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

ОФФТОПИК (предлагаю это не читать Улыбка )
По-моему гораздо более эффективным является использования принципа разделения труда в соответствии с классическим UNIX-way: на каждую крупную подзадачу должна быть отдельная программа (желательно - множество конкурирующих между собой программ), качественно и эффективно решающая свою узкую задачу. Да, безусловно, из теории надёжности известно, что при работе нескольких соединённых между собой однотипных звеньев вероятность отказа выше, чем при работе одного такого звена. Но насколько корректно использовать этот постулат применительно к технологиям разработки кода? Разве модульная программа, состоящая из тысяч процедур и функций, работает менее надёжно по сравнению с программой, написанной каким-нибудь столетним дедушкой, привыкшим писать код на длиннющих манускриптах (впрочем, здесь уже условие однотипности не соблюдено)? Также и со SQUID: не знаю, чего уж его так все любят (сказывается, наверное, врождённая консервативность мышления системных администраторов, выражающаяся в том, что подавляющее их большинстов во главу угла до сих пор ставит проблему "экономии трафика и денег", которая с каждым днём становится всё менее и менее актуальной в виду мизерной стоимости этого трафика уже сейчас и существенного роста доли некешируемого контента в общем трафике (фильмы, музыка, дистрибутивы ПО и т.д. - всё то, что раньше на радиорынках покупали)), но по моему личному убеждению использование программы, пытающейся быть универсальной "вопреки всему", мягко говоря, нерационально: представьте себе, сколько лишних условных проверок делает такая программа, как она размазывает на сотни килобайт памяти одни и те же константы, как вместо коротких переходов типа jmp SHORT она совершает стремительные марш-броски от одной функции к другой через десятки мегабайт кода... К сожалению, человеческий разум не всесилен и ни один программист, будь он хоть трижды гениален, не может писать код в виде "фрактальной" мозаики, в которой каждый маленький кусочек повторяет свойства целого, но ведь никто же и не заставляет кодеров создавать кособокие монолиты, неповторимые в своём несовершенстве: пожалуйста, разбейте программу на модули, каждый из которых должен решать свою узкую задачу, сделайте эти модули действительно независимыми друг от друга, работающими как самостоятельные библиотеки, а не как своеобразные придатки "основного кода" и - главное - предоставьте пользователю удобный механизм, позволяющий те или иные модули подключать/отключать не на этапе сборки программы (с этим, к счастью, у того же SQUID'а всё более-менее нормально), а на этапе её эксплуатации. В UNIX такими "модулями" являются сами программы - маленькие, быстрые, удобные. Их как детальки конструктора можно ставить друг за другом в любом порядке менять местами, их составленную из них систему легко отлаживать, поскольку нетрудно выяснить, какое именно звено "полетело" и разбираться уже конкретно с данным звеном, а не пытаться подстраиваться под особенности работы всего комплекса, работающего как чёрный ящик (по принципу "мусор на входе, мусор на выходе, но это не важно - важен сам процесс").

RSS-материал