Рассмотрим пример. Предположим, что вы прочитали Web-страницу www.servername.com/cgi-bin/ping.cgi, на которой можно через Web-интерфейс выполнить директиву ping. Допустим, что при первом обращении вы запустили команду ping к адресу 18.1.1.1. Результат будет сохранен в кэше прокси-сервера. В следующий раз вы обращаетесь к сценарию, чтобы выполнить ping 18.1.1.18, но браузер вернет первый результат, потому что возьмет его из своего кэша.
Страницы со сценариями могут возвращать разный результат, в зависимости от ситуации и параметров, которые выбрал пользователь. Если кэшировать такие страницы, то вы всегда будете видеть одно и то же. В результате вы получите только неудобства от соединения через proxy.
Вопросительный знак очень часто используется для передачи параметров в сценарии PHP, поэтому такие страницы тоже не рекомендуется кэшировать.
Тег hierarchy_stoplist запрещает брать страницу из кэша, а следующие две строки задают правило, по которому страницы с URL-адресом, содержащие слова "cgi-bin" или вопросительный знак, вообще не будут кэшироваться:
acl QUERY urlpath_regex cgi-bin ?
no_cache deny QUERY
Я думаю, вы согласитесь со мной, что незачем кэшировать то, что будет получаться с сервера, и зря расходовать дисковое пространство.
9.3.2. FTP-директивы
Для работы по FTP-протоколу тоже есть несколько директив:
□ ftp_passive параметр — режим работы. Если в качестве параметра указано значение on, то разрешен пассивный режим (устанавливается по умолчанию).
Сервер squid позволяет работать с FTP-протоколом, но может потребоваться некоторая настройка. Например, если squid находится за сетевым экраном, запрещающим пассивный режим, то лучше изменить значение параметра по умолчанию, установив для этого следующую директиву:
ftp_passive off
□ ftp_user адрес — определяет E-mail-адрес, который будет использоваться в качестве пароля при авторизации на анонимном FTP-сервере.
Ни один сервер не может точно сказать, правильно ли вы указали адрес, поэтому проверка может быть отключена. Но некоторые FTP-серверы проверяют корректность написания адреса. По умолчанию squid использует в качестве E-mail слово [email protected]:
ftp_user [email protected]
Правда, по умолчанию в файле /etc/squid/squid.conf эта строка закомментирована, но желательно поменять в ней E-mail-адрес, например:
ftp_user [email protected]
Такой адрес любой FTP-сервер воспримет как корректный, потому что он соответствует всем правилам написания E-mail;
□ ftp_list_width n — число n задает ширину листинга при просмотре содержимого FTP-сервера. Это значение должно быть достаточным, чтобы увидеть все файлы. Если установить слишком маленькое значение, то имена файлов будут обрезаться.
9.3.3. Настройка кэша
От того, как вы настроите кэш, будет зависеть удобство работы через прокси- сервер, поэтому я постараюсь показать все директивы, которые относятся к этому разделу, и подробно рассмотреть каждую из них:
□ cache_dir тип директория размер L1 L2 опции — определяет параметры директории, в которой будет храниться кэш. Основными для нас являются тип, директория и размер. В большинстве случаев для типа применяется значение ufs, но если вы используете асинхронный ввод/вывод (я не советую, потому что вызывает проблемы в работе), то может быть установлено aufs.
В качестве директории вы должны выбрать такую, которая находится в самом большом разделе, чтобы информация не разобщалась по нескольким дискам. Если у вас используется один диск с одним разделом, то расположение не имеет особого значения.
Размер директории по умолчанию равен 100 Мбайтам. Этого достаточно для ускорения работы трех пользователей. Если в вашей сети много пользователей и у каждого свои вкусы (любимые сайты), то значение желательно увеличить. Я использую не менее 1 Гбайта кэша. Выделенное пространство быстро исчезает, если серверу разрешено кэшировать большие файлы.
□ cache_mem n MB — задает максимальный размер оперативной памяти, необходимый для программы. По умолчанию используется n=8 Мбайт. Если ваш сервер решает задачи только proxy, то можно указать значение, равное разнице объемов оперативной памяти и памяти, необходимой для ОС. Например, если у вас ОЗУ 512 Мбайт, то для ОС в текстовом режиме 64 Мбайта будет более чем достаточно. Остальную память (448 Мбайт) можно отдать прокси-серверу — чем больше у него оперативной памяти, тем быстрее он сможет отвечать на часто запрашиваемые страницы;
□ cache_swap low n — процент заполнения кэша. Когда размер кэша превышает значение n, сервер начинает чистить его, убирая устаревшие объекты, пока размер не станет удовлетворять параметру;
□ cache_swap_high n — процент заполнения кэша. Команда аналогична предыдущей, но сервер начинает освобождать кэш более интенсивно. Это необходимо, чтобы не возникла ситуация, когда кэш будет переполнен;
□ minimum_object_size n KB — минимальный размер объекта, попадающего в кэш. По умолчанию установлено значение 0, при котором порог отсутствует;
□ maximum_object_size n KB — максимальный размер объекта, который должен кэшироваться. По умолчанию стоит значение 4096 Кбайт, что соответствует 4 Мбайтам. Для повышения производительности сервера необходимо понизить это значение, но тогда вы можете потерять на расходовании трафика. Если экономия трафика стоит более остро, то значение n необходимо увеличить;
□ maximum_object_size_in_memory n KB — максимальный размер объекта в памяти. По умолчанию установлено значение 8 Кбайт;
□ ipcache_size n — размер кэша для хранения IP-адресов. По умолчанию используется значение 1024 Кбайт;
□ ipcache_low n и ipcache_high n — соответственно минимальный и максимальный проценты заполнения кэша для IP-адресов;
□ reference_age параметр — время жизни объекта в кэше. Если объект пролежал дольше, то его можно удалять по старости. Рассмотрим несколько примеров использования директивы:
reference_age 1 week
reference_age 3.5 days
reference_age 4 months
reference_age 2.2 hours
По умолчанию используется значение в один год:
reference_age 1 week
□ quick_abort_min n KB — минимальный размер объекта, устанавливающий при обрыве соединения необходимость закончить его скачивание и полностью сохранить. Это позволяет сократить трафик и значительно увеличить скорость работы в сети. Например, пользователь запустил на скачивание файл для проверки соединения и оборвал связь. Если сервер успел сохранить файл, то при повторной попытке не надо снова скачивать те же данные. Достаточно их взять из кэша. По умолчанию установлено значение 16. Поставьте -1, чтобы отключить эту возможность;
□ 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 Кбайт, которые он сразу же может кэшировать. Это удобно, если пользователь не прервет передачу и не откажется забирать эту порцию, иначе получится, что сервер потратил трафик зря.
