diff options
Diffstat (limited to 'files/ru/web/http/caching/index.html')
| -rw-r--r-- | files/ru/web/http/caching/index.html | 30 |
1 files changed, 15 insertions, 15 deletions
diff --git a/files/ru/web/http/caching/index.html b/files/ru/web/http/caching/index.html index 9e6efe7d3e..d292181c07 100644 --- a/files/ru/web/http/caching/index.html +++ b/files/ru/web/http/caching/index.html @@ -11,13 +11,13 @@ original_slug: Web/HTTP/Кэширование --- <div>{{HTTPSidebar}}</div> -<p><strong>Производительность веб-сайтов и приложений можно значительно повысить за счет повторного использования ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой трафик, уменьшая тем самым время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более отзывчивыми.</strong></p> +<p><strong>Производительность веб-сайтов и приложений можно значительно повысить за счёт повторного использования ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой трафик, уменьшая тем самым время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более отзывчивыми.</strong></p> <h2 id="Различные_виды_кеширования">Различные виды кеширования</h2> -<p>Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к исходному серверу выполняется загрузка копии из кеша. Таким образом снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов, и повышается производительность — кеш ближе к клиенту и ресурс передается быстрее. Кеширование является основным источником повышения производительности веб-сайтов. Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.</p> +<p>Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к исходному серверу выполняется загрузка копии из кеша. Таким образом снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов, и повышается производительность — кеш ближе к клиенту и ресурс передаётся быстрее. Кеширование является основным источником повышения производительности веб-сайтов. Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.</p> -<p>Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надежности, производительности и масштабируемости веб-сайтов и веб-приложений.</p> +<p>Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.</p> <p><br> <br> @@ -27,7 +27,7 @@ original_slug: Web/HTTP/Кэширование <h3 id="Приватный_private_кеш_браузера">Приватный (private) кеш браузера</h3> -<p>Приватный кеш предназначен для отдельного пользователя. Вы, возможно, уже видели параметры кеширования в настройках своего браузера. Кеш браузера содержит все документы, загруженные пользователем по HTTP. Он используется для доступа к ранее загруженным страницам при навигации назад/вперед, позволяет сохранять страницы, или просматривать их код, не обращаясь лишний раз к серверу. Кроме того, кеш полезен при отключении от сети.</p> +<p>Приватный кеш предназначен для отдельного пользователя. Вы, возможно, уже видели параметры кеширования в настройках своего браузера. Кеш браузера содержит все документы, загруженные пользователем по HTTP. Он используется для доступа к ранее загруженным страницам при навигации назад/вперёд, позволяет сохранять страницы, или просматривать их код, не обращаясь лишний раз к серверу. Кроме того, кеш полезен при отключении от сети.</p> <h3 id="Общий_shared_прокси-кеш">Общий (shared) прокси-кеш</h3> @@ -35,7 +35,7 @@ original_slug: Web/HTTP/Кэширование <h2 id="Цели_кеширования">Цели кеширования</h2> -<p>Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохраненные ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом {{HTTPMethod("GET")}}, а другие отклоняют.</p> +<p>Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохранённые ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом {{HTTPMethod("GET")}}, а другие отклоняют.</p> <p>Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:</p> @@ -49,7 +49,7 @@ original_slug: Web/HTTP/Кэширование </li> </ul> -<p>Запись в кеше может также состоять из множества ответов, различаемых по вторичному ключу, если при формировании ответа производится согласование данных. Подробнее об этом рассказано <a href="#Varying_responses">ниже</a>, в разделе, посвященном заголовку {{HTTPHeader("Vary")}}.</p> +<p>Запись в кеше может также состоять из множества ответов, различаемых по вторичному ключу, если при формировании ответа производится согласование данных. Подробнее об этом рассказано <a href="#Varying_responses">ниже</a>, в разделе, посвящённом заголовку {{HTTPHeader("Vary")}}.</p> <h2 id="Управление_кешированием"><span class="long_text short_text" id="result_box" lang="ru"><span>Управление</span> </span>кеш<span class="long_text short_text" lang="ru"><span>ированием</span></span></h2> @@ -89,23 +89,23 @@ Cache-Control: public <h4 id="Проверка_актуальности">Проверка актуальности</h4> -<p>При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истекшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе <a href="#Cache_validation">Валидация кеша</a>.</p> +<p>При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе <a href="#Cache_validation">Валидация кеша</a>.</p> <pre class="notranslate">Cache-Control: must-revalidate</pre> <h3 id="Заголовок_Pragma">Заголовок <code>Pragma </code></h3> -<p>{{HTTPHeader("Pragma")}} является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надежной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично "Cache-Control: no-cache" когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.</p> +<p>{{HTTPHeader("Pragma")}} является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надёжной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично "Cache-Control: no-cache" когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.</p> -<h2 id="Свежесть_сохраненной_копии"><a id="Freshness" name="Freshness">Свежесть сохраненной копии</a></h2> +<h2 id="Свежесть_сохранённой_копии"><a id="Freshness" name="Freshness">Свежесть сохранённой копии</a></h2> -<p>Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют <em>вытеснением данных из кеша</em> (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохраненной копии. До его истечения ресурс считается <em>свежим </em>(fresh), после — <em>устаревшим </em>(stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении ее срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком {{HTTPHeader("If-None-Match")}} на случай, если копия все еще актуальна. Если это так, сервер возвращает заголовок {{HTTPStatus("304")}} <code>Not Modified</code> («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.</p> +<p>Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют <em>вытеснением данных из кеша</em> (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии. До его истечения ресурс считается <em>свежим </em>(fresh), после — <em>устаревшим </em>(stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком {{HTTPHeader("If-None-Match")}} на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок {{HTTPStatus("304")}} <code>Not Modified</code> («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.</p> <p>Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:</p> <p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p> -<p>Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок {{HTTPHeader("Expires")}}, и, если он есть, то срок действия берется равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.<br> +<p>Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок {{HTTPHeader("Expires")}}, и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.<br> Время устаревания (expirationTime) вычисляется следующим образом:</p> <pre class="notranslate">expirationTime = responseTime + freshnessLifetime - currentAge @@ -115,9 +115,9 @@ Cache-Control: public <h3 id="Обновление_статических_ресурсов_Revved_resources">Обновление статических ресурсов (Revved resources)</h3> -<p>Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование дает больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.</p> +<p>Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.</p> -<p>Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал <em>revving</em><sup><a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></sup>, что можно перевести как "оборачиваемость". Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечет за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.</p> +<p>Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал <em>revving</em><sup><a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></sup>, что можно перевести как "оборачиваемость". Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечёт за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.</p> <p>Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.</p> @@ -133,7 +133,7 @@ Cache-Control: public <h3 id="Заголовки_ETag">Заголовки ETag</h3> -<p>Заголовок ответа {{HTTPHeader("ETag")}} является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет ее значение. Если в ответе присутствует заголовок <code>ETag</code>, клиент может транслировать его значение через заголовок {{HTTPHeader("If-None-Match")}} будущих запросов для валидации кешированного ресурса.</p> +<p>Заголовок ответа {{HTTPHeader("ETag")}} является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок <code>ETag</code>, клиент может транслировать его значение через заголовок {{HTTPHeader("If-None-Match")}} будущих запросов для валидации кешированного ресурса.</p> <p>Заголовок ответа {{HTTPHeader("Last-Modified")}} можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок <code>Last-Modified</code>, то для валидации кешированного документа клиент может выводить в запросах заголовок {{HTTPHeader("If-Modified-Since")}}.</p> @@ -143,7 +143,7 @@ Cache-Control: public <p>Заголовок HTTP-ответа {{HTTPHeader("Vary")}} определяет, как по заголовкам будущих запросов понять, может ли быть использована копия из кеша, или нужно запросить новые данные у сервера.</p> -<p>Если кеш получает запрос, который можно удовлетворить сохраненным в кеше ответом с заголовком <code>Vary</code>, то использовать этот ответ можно только при совпадении всех указанных в <code>Vary</code> полей заголовка исходного (сохраненного в кеше) запроса и нового запроса.</p> +<p>Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком <code>Vary</code>, то использовать этот ответ можно только при совпадении всех указанных в <code>Vary</code> полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.</p> <p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;"></p> |