Комментарий редактора. Марк Ноттингем интересуется всем, что связано с кэшированием информационного наполнения Web как на proxy-серверах, так и на уровне браузеров. Он подготовил ряд советов относительно контроля за тем, как кэшируются ваши страницы Web — они могут вам пригодиться при работе в вашей сети Intranet, ведь, в конце концов, все, что без нужды пересекает вашу сеть дважды, просто забивает ее каналы. Возможности управления стали гораздо шире, как, впрочем, и число проблем. Более подробную информацию о кэшировании можно почерпнуть на его узле на эту тему по адресу: http://www.mnot.net/cache_docs/.

Кэш Web располагается между серверами Web (или источниками) и клиентом (или множеством клиентов) и просматривает запросы на страницы HTML, изображения и файлы (собирательно они называются объектами), сохраняя их копию у себя. Затем при поступлении другого запроса на тот же самый объект он возвращает имеющуюся копию, не запрашивая ее повторно у источника. Кэши Web используются по двум основным причинам:

1. для сокращения задержки. Ввиду того, что запросы выполняются кэшем (располагающимся ближе к клиенту), а не сервером, где изначально находятся запрашиваемые объекты, получение и отображение клиентом объекта занимают меньше времени. В результате, с точки зрения пользователя, узел Web функционирует более оперативно;

2. для сокращения трафика. Ввиду того, что каждый объект передается с сервера только однажды, потребление клиентом пропускной способности сокращается. Это экономит деньги, когда клиенту приходится платить за трафик, и позволяет уменьшить требования к пропускной способности и сделать их более приемлемыми.

Кэширование Web — одна из не до конца понимаемых технологий Internet. В частности, администраторы Web бояться потерять контроль за своими серверами, потому что кэш «скрывает» от них пользователей, затрудняя наблюдение за тем, кто посещает узел.

К сожалению, даже если никакого кэширования Web не используется, Internet имеет слишком много переменных, чтобы администраторы Web могли быть уверены в том, что они получают достоверную картину того, кто и как пользуется их сервером. Если это представляет для вас проблему, то, ознакомившись с документом Web, упоминаемым в комментарии редактора, вы сможете узнать, как получить необходимую статистику так, чтобы ваш узел не препятствовал кэшированию.

Озабоченность вызывает также то, что кэши будут предоставлять устаревшее информационное наполнение. Однако сервер можно сконфигурировать так, чтобы этого не происходило и чтобы вместе с тем он способствовал кэшированию.

С другой стороны, при правильном планировании сервера кэширование способно ускорить загрузку с вашего узла и уменьшить нагрузку на ваш сервер и канал Internet. Разница может оказаться весьма существенной: загрузка с сервера, плохо поддающегося кэшированию, может занять несколько секунд, в то время как загрузка с сервера, использующего преимущества кэширования, будет происходить почти мгновенно. Пользователи ценят узлы, загрузка с которых осуществляется быстро, и посещают их гораздо охотнее.

На эту проблему можно взглянуть следующим образом: многие крупные компании, занимающиеся Internet, тратят миллионы долларов на создание по всему миру парков серверов для тиражирования информационного наполнения, чтобы пользователи могли получить к нему как можно более быстрый доступ. Кэши способны сделать для вас то же самое, причем они находятся еще ближе к конечным пользователям. Главное же, что вам даже не придется платить за них.

Правда в том, что кэши будут использоваться вне зависимости от того, нравится вам это или нет. Если вы сами не позаботитесь о том, чтобы информационное наполнение вашего сервера кэшировалось правильно, то оно будет кэшироваться в соответствии с установками по умолчанию, который администратор кэша сочтет нужным выбрать.

Авторы текстов HTML могут поместить теги в раздел документа с описанием его атрибутов. Эти мета-теги часто используются в надежде, что они будут сигнализировать о том, что документ является некэшируемым или что его требуется обновить через определенное время.

Мета-теги просты в использовании, но не очень эффективны. Это связано с тем, что обычно они воспринимаются только кэшами браузеров (так как те действительно читают текст HTML), а не кэширующими посредниками (они практически никогда не разбирают разметку HTML в документах). При всей соблазнительности помещения на домашнюю страницу мета-тега «кэшированию не подлежит», оно не гарантирует ее получения пользователем со всеми последними изменениями, если обращение к серверу происходит через разделяемый кэш.

С другой стороны, заголовки HTTP предоставляют множество возможностей контроля за тем, как ваши объекты кэшируются браузером и обрабатываются посредниками. Они не отображаются в тексте HTML и обычно генерируются серверами Web автоматически. Однако у вас есть определенные возможности контроля за ними — все зависит от того, какой сервер вами используется. Заголовки HTTP передаются сервером прежде HTML, причем они видны только браузеру и всем промежуточным кэшам. Типичные заголовки ответа HTTP 1.1 выглядят следующим образом:

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998
13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600,
must-revalidate
Expires: Fri, 30 Oct 1998
14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998
02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html

Документ HTML следует за этими заголовками и отделен от них пустой строкой.

Заголовок HTTP Expires представляет собой основное средство контроля за кэшем: он сообщает кэшу, как долго объект может считаться не устаревшим; по истечении этого срока кэш всегда справится у источника, был ли документ изменен. Заголовки Expires поддерживаются практически всеми клиентами.

Большинство серверов Web позволяют задавать при ответе заголовки Expires одним из следующих способов. Как правило, вы можете указать абсолютное время истечения срока годности; время в зависимости от того, когда клиент последний раз видел объект (время последнего обращения); или время в зависимости от того, когда документ был последний раз изменен (время последнего изменения).

Заголовки Expires наилушим образом подходят для кэширования статических объектов (таких, как навигационные линейки и кнопки). Такие объекты изменяются редко, поэтому для них вы можете задать большой «срок годности», в результате ваш узел будет восприниматься пользователями как более оперативный. Эти заголовки также полезны для контроля за кэшированием регулярно обновляемых страниц. Например, если новостная страница обновляется один раз в день, в 6 утра, то срок истечения годности объекта можно указать равным этому времени, так что кэш сам, без вмешательства пользователя, будет знать, что ему требуется получить свежую копию.

Единственная имеющая смысл величина в заголовке Expires — это дата HTTP, все остальное скорее всего будет рассматриваться как «относящееся к прошлому», т. е. что объект не является кэшируемым. Напомню, что время в дате HTTP указывается не местное, а по Гринвичу (GMT). Например:

Expires: Fri, 30 Oct 1998
14:19:41 GMT

При всей полезности заголовка Expires его возможности весьма ограничены. Во многих ситуациях, когда информационное наполнение является кэшируемым, протокол HTTP 1.0 не в состоянии сообщить кэшу, что оно собой представляет и как с ним следует поступить.

HTTP 1.1 вводит новый класс заголовков — заголовки ответа Cache-Control, с помощью которых издатели Web могут определить способ обработки страниц кэшем. Эти заголовки содержат указания о том, что следует кэшировать, что может храниться в кэше, как следует изменить механизм определения срока годности, а также как выполнять повторную проверку и загрузку.

Наибольший интерес представляют следующие заголовки Cache-Control:

max-age=[секунды] указывает максимальный срок, в течение которого объект можно не обновлять. Эта директива схожа с Expires, но предоставляет более гибкие возможности. Часть заголовка [секунды] содержит указание на количество секунд, в течение которых объект считается не устаревшим начиная с момента, когда поступил запрос;

s-maxage=[секунды] аналогичен max-age, за тем исключением, что он применим только к разделяемым кэшам (кэширующим посредникам);

public характеризует ответ как кэшируемый, даже если обычно он является некэшируемым. Например, если ваши страницы предполагают идентификацию, то директива public делает их кэшируемыми;

no-cache вынуждает кэши (как посредника, так и браузер) каждый раз, прежде чем предоставить имеющуюся копию, обращаться для подтверждения с запросом к источнику.

Эта директива полезна в целях обеспечения выполнения процедуры идентификации (в сочетании с заголовком public) или гарантирования новизны объекта без потери преимуществ кэширования;

must-revalidate сообщает кэшу, что он должен соблюдать все требования в отношении новизны объекта, которые вы предъявляете.

HTTP предоставляет кэшам определенную свободу в отношении новизны объектов; вставив этот заголовок, вы сообщаете кэшу, что он должен строго придерживаться ваших правил;

proxy-revalidate аналогичен must-reva-lidate, за тем исключением, что он применим только к кэширующим посредникам.

Заголовок Cache-Control может выглядеть следующим образом:

Cache-Control: max-age=3600,
must-revalidate

Если вы собираетесь использовать заголовки Cache-Control, то я советовал бы вначале ознакомиться с превосходной документацией по проекту стандарта HTTP 1.1 на http://www.w3.org/Protocols/rfc2616/rfc2616.html.

Комментарий редактора. Мы регулярно публикуем сообщения BugNet в разделе «Тысяча мелочей». О других ошибках и заплатах вы можете узнать на http://www.bugnet.com/.

Lotus Notes and Domino Quarterly Maintenance Release 4.6.2b исправляет ошибку, из-за которой производительность сервера может снизиться, если при открытии адресной книги клиенты модифицируют нечитаемые знаки. По информации Lotus, эта проблема характерна для версий Notes, начиная с 4.5.

В Microsoft Systems Management Server 2.0 Service Pack 1 минимальный интервал обновления для групп фиксирован и составляет 15 минут. Вы можете задать более короткий интервал времени, но обновления будут по-прежнему проводиться каждые 15 минут. Если вы измените график обновления членства, то вам придется ждать 15 минут до первой проверки. Обойти это никак нельзя.

Вы можете поделиться своим опытом решения проблем, возникающих при работе в сети (возможно, очень полезным многим читателям в их повседневной работе). Наиболее интересные материалы будут опубликованы в ближайших номерах журнала LAN.

Присылайте ваши отклики по электронной почте: lan@lanmag.ru,
или по факсу: (095) 253-9204.