Читаем Linux глазами хакера полностью

□ quick_abort_max n KB — максимальный остаток объекта, при котором закачка будет прервана в случае обрыва соединения. По умолчанию установлено значение 16;

□ quick_abort_pct n — параметр аналогичен quick_abort_min n, но в данном случае указывается максимальный процент уже полученной информации;

□ negative_ttl n minutes — количество минут, которые нужно кэшировать негативный ответ сервера. Например, пользователь зашел на сервер и получил ошибку, которая может быть временной, поэтому нельзя кэшировать ответ на длительный срок. Значение по умолчанию 5 минут. Если пользователь обратится по этому же адресу по истечении этого времени, то копия из кэша не будет использоваться, а произойдет попытка вновь зайти на сайт;

□ positive_dns_ttl n hours — время в часах, в течение которого нужно кэшировать положительный результат DNS-запроса. В этот промежуток времени при повторных обращениях к DNS IP-адрес будет взят из кэша. По умолчанию используется значение 6 часов, в настоящее время его можно увеличить до 24 часов. Несколько лет назад IP-адреса имели тенденцию очень часто меняться, поэтому приходилось ограничивать время жизни запросов. Сейчас большинство сайтов имеют статичный адрес, который изменяется только при смене хостинга, а крупные порталы зарезервировали себе собственные постоянные IP-адреса. Если вы не хотите использовать кэширование IP-адресов, встроенное в squid, то можно установить этот параметр в 0;

□ negative_dns_ttl n minutes — промежуток времени в минутах, в пределах которого нужно кэшировать негативный ответ DNS-сервера. Если не найден DNS-адрес, то это может быть проблема с самим сервером имен, а не сайтом. Такие вопросы, чаще всего, решаются в течение 2–3 минут, поэтому отрицательный ответ не стоит держать в кэше дольше, иначе все это время клиенты не смогут обратиться к сайту. Я делаю этот параметр равным 1 или нулевым, чтобы пользователи увидели нужный сайт сразу после устранения проблемы;

□ range_offset_limit n KB — параметры кэширования. Если указать значение -1, то сервер загрузит из Интернета требуемый объект полностью, а потом будет транслировать пользователю полученные данные уже из собственного кэша. При значении о информация в запрошенном объеме будет передаваться между сервером и клиентом без кэширования на прокси- сервере, т.е. ни грамма лишнего. Если указано число более о, то proxy может кэшировать с интернет-сервера указанное количество килобайт. Например, пользователь запрашивает файл размером в 1 Мбайт и squid разрешено подкачивать 100 Кбайт, которые он сразу же может кэшировать. Это удобно, если пользователь не прервет передачу и не откажется забирать эту порцию, иначе получится, что сервер потратил трафик зря.

<p>9.3.4. Журналы</p>

В конфигурационном файле есть несколько параметров, влияющих на работу прокси-сервера с журналом (легко читаются в любом текстовом редакторе):

□ cache_access_log файл — журнал, в котором сохраняется вся активность пользователей, а именно HTTP- и ICP-запросы. По умолчанию этот параметр равен /var/log/squid/access.log;

□ cache_log файл — файл для хранения основной информации о кэше. По умолчанию используется /var/log/squid/cache.log;

□ cache_store_log файл — журнал операций над объектами в кэше (убраны или помещены, на какое время). По умолчанию используется файл /var/log/squid/store.log, но вы без проблем можете отключить этот журнал, указав в качестве значения none, потому что нет утилит для анализа сохраняемых данных, да и пользы в них мало, только расходы на сохранение;

□ log_mime_hdrs параметр — если в качестве параметра указано on, то в журнале access будут сохраняться заголовки MIME;

□ useragent_log — журнал, в котором сохраняется поле User-agent заголовков HTTP. Смысла в этом поле нет, потому что его легко подделать, и ничего полезного журнал не даст, поэтому по умолчанию он не используется.

В разд. 12.5 мы будем говорить о журналах Linux и различных сервисах, а в разд. 12.5.4 подробно рассмотрим содержимое основного журнала squid — /var/log/squid/access.log.

<p>9.3.5. Разделение кэша</p>

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

Дня этого есть следующие директивы:

□ icp_port n — номер порта, который будет использоваться для ICP-протокола. По умолчанию установлено значение 3130. Если указать 0, то протокол будет заблокирован;

□ htcp_port n — номер порта, который будет использоваться для ICP-протокола, работающего поверх TCP/IP. По умолчанию принято значение 4827. Если указать 0, то протокол будет заблокирован;

Перейти на страницу:

Похожие книги