Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

240

Часть

III. Web-протоколы

в HTTP/1.1 добавлен новый общий заголовок Cache-Control. И в запросах, и в от-

ветах можно использовать несколько директив управления кэшем, состав которых

можно расширять. Web-серверы могут потребовать, чтобы ответ был приватным и

предназначался единствегнюму пользователю. Можно также заставить кэш прове-

рять но прошествии определенного времени актуальность сохраненных ответов пе-

ред тем, как возвращать их инициаторам запроса. Промежуточные серверы должны

передавать далее директивы управления кэшем, так как они могут относиться ко

всем прокси-серверам и шлюзам в цепочке запрос-ответ. Заметим, что эти директи-

вы относятся к обязательным требованиям (уровень MUST) и все кэши должны

подчиняться им. При этом важно помнить, что требование совместимости, предъ-

являемое протоколом, не означает, что кэши на самом деле будут выполнять эти

директивы. В главе 15 (раздел 15.3), мы рассмотрим последствия несовместимости

Web-компонентов.

Хотя некоторые директивы могут применяться и в запросах, и в ответах, нали-

чие директивы в запросе не требует присутствия или отсутствия аналогичной ди-

рективы в ответе. Далее мы рассмотрим директивы запросов и ответов, относящие-

ся к управлению кэшированием.

Таблица 7.12. Директивы запросов, относящиеся к управлению кэшированием

Директива Краткое описание

no-cache

only-if-cached

no-store

max-age

max-stale

min-fresh

no-transform

extension

tokens

Пргшуднтсльная загрузка с Web-ссрвера

Получение ресурса только из кэша

Кэшам не разрешено сохранять запрос, ответ

Возраст ответа должен быть не больше данного значения

Возможно использование устаревшего ответа, но не старше указанного

значения

Ответ до.чжен оставаться актуальным по меньшей мере указанное время

Прокси-сервер не долл^ен изменять тип данных ресурса

Новые лексемы, представляющие новые директивы запросов

Директивы запросов, относящиеся к управлению кэшированием. Директивы

запросов, относящиеся к управле1Н410 кэшированием, являются для клиента средст-

вом изменить способ обработки запросов, используемый кэшем по умолчанию.

В таблице 7.12 представлен набор директив запросов управления кэшированием.

Клиентам бывает иногда необходимо, чтобы их запросы пе кэшировались для со-

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

чтобы ответ приходил только из кэша и чтобы промежуточные средства пе изменя-

ли ответ. Заметим, что хотя существует ряд директив запроса, реализации браузе-

ров могут пе предоставлять пользователям возможности использовать эти дирек-

тивы. Далее рассматриваются различные директивы запросов.

• no-cache. Директива запроса no-cache выполняет ту же функцию, что и ди-

ректива НТТР/1.0 Pragma: no-cache; то есть любому прокси-серверу па пути

между отправителем и сервером-источником пе разрешено возвращать ответ

из кэ1па. Вместо этого прокси-сервер обязан пересылать запрос дальше серве-

ру-источнику. Этот процесс известен как «сквозная перезагрузка (end-to-end

reload)». Например, когда пользователь щелкает мышью па кнопке Reload

браузера Netscape (при нажатой клавише Shift), браузер посылает директиву

Глава 7. HTTP/1.1 241

Pragma: no-cache. Пользователь получает текущую версию ресурса, независи-

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

• only-if-cached. Зеркальным отраже1Н1ем директивы no-cache является дирек-

тива only-if-cached. Вместо уверенности в том, что ответ на запрос будет по-

лучен от сервера-источника, а не из кэша, в этом случае, отправителю нужен

ответ только из кэша. Может быть, отправитель озабочен задержкой ответа

или его не беспокоит актуальность кэшированного ответа. Кэш может послать

ответ, если это соответствует условиям запроса, по в других обстоятельствах

может вернуть код ответа 504 Gateway Timeout. Прокси-сервер может вер-

нуть заведомо устаревший ответ, но только если запрос не содержит других

ограничений, таких как заголовка If-Modified-Since. Условия семантической

прозрачности требуют только, чтобы прокси-серверы не возвращали устарев-

ший ответ, не зная о том, что он устарел.

• no-store. Директива запроса no-store пе допускает coxpaneinm запроса и ответа

в кэше. Возможно, пользователь пе хочет, чтобы запрос был сохранен даже на

короткое время. Директива no-store полезное средство, отвечающее требовани-

ям конфиденциальности. Эта директива запрещает сохра1шть в кэше запрос, а

также любой ответ на него. Однако не существует гарантии, что запрос (или от-

вет) не будут случайно где-либо сохранены. Возможно, было бы лучше для

пользователя зашифровать этот запрос.

• max-age. Чтобы решить, является ли ответ в кэше устаревшим, агент пользо-

вателя может изме1пггь действующий по умолчанию механизм истечения сро-

ка годности с номоп_1ью др1рективы управле!пш кэшированием max-age. Ответ

должен иметь «возраст» меньше, чем значение времени (в секундах), опреде-

ленное в директиве max-age. Таким образом, директива max-age=0 форсирует

сквозную проверку актуальности.

• max-stale. Директива max-stale выражает готовность клиеггга принимать от-

веты из кэша, срок годности которых возможно истек. Однако время истече-

ния срока годности ответа не должно превышать значе1Н1е, указанное в значе-

нии параметра директивы (если оно имеется). Если значение параметра не за-

дано,

клиент готов принять любой ответ. Задание max-stale позволяет клиен-

там обойти правила, которыми руководствуется прокси-сервер. Директива

max-stale=60 означает, что агент пользователя готов принять ответ, который

может быть устарел, но не более чем на минуту.

• min-fresh. Директива min-fresh выражает желание клиента принять ответ, кото-

рый будет актуальным но меньшей мере зада1нюе число секунд. Если в качестве

значе1Н1я параметра директивы min-fresh задано число 60, ожидаемый резуль-

тат состоит в том, что ответ не будет устаревшим через 60 секунд.

• no-transform. Директива no-transform не допускает, чтобы кэш изменял тип

(например, text/html, image/gif) тела содержимого. Преобразование тела со-

держимого может включать изменение алгоритма кодирования содержания

(например, сжатие тела содержимого), типа содержания (изменение формата

изображения GIF на формат JPEG) или проверку целостности (контрольная

сумма). Одной из нричин преобразования тела содержимого является эффек-

тивность — сжатие ответа ускоряет его передачу. Однако в некоторых случа-

ях, ответ не должен изменяться; так измепепие CTeneini детализации медицин-

ского снимка может привести к потере критически важной информации. Если

получатель тела содержимого полагается на свою контрольную сумму при

242

Часть

III. Web-протоколы

проверке целостности, даже незначительное изменение приведет к тому, что

проверка целостности закончится неудачей.

Промежуточный кэш не имеет права отменять сквозные соглашения от-

правителя и получателя. Директива запроса no-transform возвращает управ-

ление отправителю (и получателю в случае директивы ответа). Однако кэши

могут игнорировать и игнорируют сквозные соглашения, принимая локаль-

но-оптимальные решения. Одним из примеров, когда у кэша может быть за-

конное основание проигнорировать директиву, является академический сайт,

игнорирующий запросы на загрузку обновленных копий ресурсов сомнитель-

ного характера. Но, если кэш игнорирует любые явно заданные директивы за-

проса (например, no-cache), он должен включить в ответ предупреждение,

указывая, что ответ, возможно, устарел.

• лексемы расширений. Наличие возможностей расширения набора директив

управления механизмом кэширования позволяет добавлять новые директивы

запросов. Однако если кэши не воспринимают или не намерены выполнять

новые директивы, они могут благополучно их игнорировать. Протокол требу-

ет (требование уровня MUST), чтобы нераспознанные директивы управления

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

кэша является главным фактором.

Директивы ответов, относящиеся к управлению кэшированием. Директивы от-

ветов, относящиеся к управлению кэшированием, являются для сервера средством

обеспечения особого характера функционирования кэшей, расположе1П1ых на пути

следования ответа. Список различных директив ответов, относящихся к управлению

кэшированием, приведен в таблице 7.13. Директивы ответов предоставляют серверу

возможность ограничивать кэширование ответов. Можно управлять кэшированием

в диапазоне от разрешения кэшировать ответ до определения того, какие части отве-

та можно кэшировать и кто имеет доступ к кэширован1юму ответу.

Таблица 7.13. Директивы ответов, относящиеся к управлению кэшированием

Директива

public

private

no-store

no-cache

no-transform

must-revalidate

proxy-revalidate

max-age

s-maxage

лексемы расширений

Краткое описание |

Разрешение кэшировать ответ, где угодно

Ответ только для конкретного пользователя

Не разрешено кэшировать ответ, запрос

Не обслуживать из кэша без предварительной проверки

актуальности

Прокси-сервер не должен изменять трш содержания

Можно кэшировать, по проверять актуальность

Форсирует проверку ответа в кэшах, совместно использусхмых

агентами пользователей

Возраст ответа не должен превышать заданного значения

Максимальный возраст ответа в совместно используемых кэшах

Лексемы, представляюш^ие новые директивы ответов

Далее мы рассматриваем различные директивы ответов, относящиеся к управ-

лению кэшированием.

Глава 7. HTTP/1.1 243

• public. Управление кэшированием в НТТР/1.1 по большей части является

симметричным. И серверы, и клиенты имеют одинаковые возможности управ-

лять кэшированием ответов. Сервер может установить режим кэширования

конкретного ответа, и эти установки будут иметь приоритет над любыми уста-

новками, используемыми кэшами по умолчанию. Например, принимая во

внимание, что кэш, возможно, решит не сохранять определенные ответы из

опасения нарушить их конфиденциальность, сервер, включая заголовок отве-

та Cache-Control: риЬИс, может показать, что данный конкретный ответ мож-

но сохранять в кэше.

• private. Директива ответа private ограничивает возможность кэширования от-

вета только одним пользователем. Слово private (частный, личный, нргн^ат-

ный) вероятно было не лучшим вариантом, так как эта директива ни коим об-

разом не влияет на копфидепциальпость сообщения. Разработчики искали ан-

тоним к слову shared (совместно используемый), так как директива private

препятствует сохранению ответа в совместно используемом кэше. Кроме того,

область действия директивы private может быть сужена со всего сообщения

до его частей путем добавления параметра с именем ноля. Например, включе-

ние в ответ

Cache-Control: private = "CustomerlD"

приведет к тому, что только содержание ноля CustomerlD не будет сохра-

няться в совместно используемом кэше.

• no-store. Директива ответа no-store аналогична такой же директиве запроса и

используется, чтобы не допустить сохранения ответа в кэше. Если эта дирек-

тива присутствует в ответе, пи ответ, пи соответствующий запрос не должны

сохраняться в кэше.

• no-cache. В отличие от директивы no-store, директива no-cache не занреп1ает

сохранять ответ в кэше. Тем не менее, директива no-cache эффективно пре-

пятствует такому сохранению, вынуждая кэш проверить актуальность ответа

на сервере-источнике до того, как отвечать на запрос. Основное назначение

этой директивы

—

существенно снизить вероятность возврата некоторыми кэ-

шами устаревших ответов. Ответ но-нрежнему может храниться в кэше, по

кэш должен гарантировать его актуальность путем донол]Н1тельной проверки

актуальности. Хотя донолнительная проверка увеличивает задержку, если

проверка оказывается успешной, можно все же снизить издержки на загрузку

ресурса с исходного сервера.

Директиву no-cache можно использовать и с именами нолей заголовков и без

них. Если директива включает одно или несколько имен нолей заголовков, то

ее действие распространяется на указанные 1юля заголовков. Например,

предположим, что запрос выглядит следующим образом:

НТТР/1.1 200

ОК

Server: Apache/1.2.6

Red Hat

Date:

Thu,

24 Feb

2000 18:13:36

GMT

Content-Type: text/html

Location: http://kinghascome.com/ads/elvis_has_left.gif

Cache-Control: no-cache=Location

Смысл директивы ответа no-cache смягчен присутствием в ней дополнитель-

ных полей заголовков. Остальное содержание ответа, за исключение заголов-

244

Часть

III. Web-протоколы

ка Location, может использоваться повторно, снижая, таким образом, неэф-

фективную нагрузку на сеть и воспринимаемую пользователем задержку. Но

существует предел контролю Web-сервера над ответом. Кэш должен удалять

ноле заголовка Location, прежде чем отправлять ответ клиенту. Исходный

сервер, отказавшись при управлении кэшированием ответа от концепции все

или ничего, может сохранить частичный контроль за ресурсами. Аналогично,

с помощью директивы Cache-Control: no-cache=set-cookie2 исходный сервер

может запретить сохранять в кэше заголовок Set-Cookie2 [KMOOJ.

• no-transform. Директива ответа no-transform аналогична такой же директиве

запроса и используется, чтобы не допустить изменения ответа (например,

уменьшение разрешения изображения).

• must-re validate. Директива must-revalidate позволяет Web-серверу обратить

внимание на то, что для некоторых ответов может оказаться слишком риско-

ванным для кэша возвращать возможно устаревшие копии. Эта директива вы-

нуждает кэш провести дополнительную проверку актуальности ресурса на

сервере-источнике. Более важно то, что если прокси-сервер не может осущест-

вить проверку актуальности на сервере-источнике (например, если про-

кси-сервер не может связаться с Web-сервером), то кэш должен вернуть кли-

енту не устаревший ответ, а сообщение об ошибке. Различие между директи-

вой must-revalidate и похожей на первый взгляд директивой no-cache заклю-

чается в том, что кэши вряд ли сохранят ответы, которые включают директиву

no-cache. Если ответ включает директиву must-revalidate, то он может быть

сохранен в кэше, но актуальность его должна быть проверена. Директива

no-cache вынуждает кэш провести проверку независимо от того, когда этот

ответ устарел. На практике, так как кэши вряд ли сохранят ответы, которые

включают директиву no-cache, запрос на такое содержимое приведет к загруз-

ке данных с сервера-источника, а не просто к их проверке. Использование ди-

рективы must-revalidate по сравнению с использованием директивы no-cache

экономнее в отношении нагрузки па сеть. Однако пользователь, пользующий-

ся «магазинной тележкой» в приложениях электронной коммерции, предпоч-

тет либо точно знать ее содержимое, лР1бо получить сообщение об ошибке, по

не устаревшие данные.

Предположим, что кэш ждет ответа от предыдущего сервера на пути сооб-

ще1Н1я и не получает этот ответ в течение некоторого времени. Если это вы-

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

зан передать новый код ответа HTTP/1.1 504 Gateway Timeout (как и в слу-

чае директивы only-if-cached). Сервер может выбрать конкретное время для

таймаута. Ответ 504 Gateway Timeout выглядит более содержательным, чем

ответ общего характера 500 Internal Server Error.

Директива управления кэшем no-store гарантирует, что запрос-ответ не

будет сохранен, тогда как no-cache допускает сохранение, но гарантирует, что

не будут возвращаться устаревшие ответы. Директива must-revalidate допус-

кает сохранение ответа, по гарантирует, что устаревшие ответы будут обнов-

ляться. Однако ответ, который кэш считает обновленным, может быть уже

изменен на сервере-источнике. Это различие между директивами является

ключевым для понимания необходимости обеих директив: no-cache и must-

revalidate. Директива no-store вообще исключает кэширование. В случае

no-cache существует возможность кэширования, но отсутствует риск возвра-

щения ответа, который уже изменен. В случае must-revalidate существует ре-

Глава 7. HTTP/1.1 245

альная возможность кэширования и не существует возможности устаревания,

хотя остается возможность возвращения ответа, который уже был изменен.

• proxy-revalidate. Директива ответа proxy-revalidate является менее ограничи-

тельной, чем директива must-revalidate. В то время как последняя относится

ко всем кэшам, proxy-revalidate не относится к не используемым совместно

кэшам агентов пользователей. Кэш агента пользователя (в отличие от кэи1а

прокси-сервера) может возвращать ответы из кэша без перепроверки. Некото-

рые действия (например, аутентификация) могут без риска выполняться кэ-

шем агента пользователя однократно и запоминаться. Однако совместно ис-

пользуемый кэш используется многими пользователями и, следовательно,

действия предпринятые от лица одного пользователя могут не подходить дру-

гому. Поэтому перепроверка ответов в совместно используемых кэшах являет-

ся необходимой. Детализированное управление кэшированием типично для

усовершенствований в НТТР/1.1.

• max-age. Директива ответа max-age является предпочтительным способом за-

дать срок годности содержимого. Наличие директивы ответа Cache-Control:

max-age отменяет любое значение заголовка Expires при вычислении периода

актуальности кэшированного ответа. Это пример нового свойства НТТР/1.1,

обеспечивающего большую гибкость вновь разрабатываемым компонентам:

кэш, использующий НТТР/1.1, гюлуча>1 директиву max-age, будет придержи-

ваться указанного там срока годности, тогда как кэш, использующий НТТР/1.0,

обычно игнорирует директиву max-age.

• s-maxage. Заголовок s-maxage имеет отношение только к совместно исполь-

зуемым кэшам и применяется для отмены значений директивы Expires и ди-

рективы max-age. Как уже обсуждалось ранее, совместно используемые кэши

обязаны перепроверять ответы с истекшим сроком s-maxage.

• лексемы расширений. Директивы ответов, относящиеся к управлению кэширо-

ванием, могут также использовать новые лексемы, определенные использую-

щими их кэшами.

ЗАГОЛОВОК ETAG

Атрибут содержимого (ETag) был сначала введен в НТТР/1.1 в качестве инди-

катора непрозрачности [Mog95] для сравнения содержимого кэша с возможно бо-

лее новой версией. Данный ресурс может иметь разные версии, и каждая версия

будет иметь индивидуальный атрибут содержимого. Атрибут содержимого всегда

связан с конкретным ресурсом и не должен использоваться для сравнения разных

ресурсов. Структура атрибута содержимого сознательно сделана непрозрачной

в том смысле, что от получателей не требуется делать никаких умозаключений, ис-

следуя строку атрибута содержимого.

Атрибут содержимого гарантирует следующее: если существует различное со-

держимое, сопоставленное с одним и тем же ресурсом, то атрибуты содержимого

этих версий различаются. Следовательно, для одного и того же самого ресурса,

если атрибуты содержимого идентичны, соответствующие версии ресурсов должны

рассматриваться как идентичные.

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

шированный ресурс остается актуальным) от срока хранения (с помощью которого

сервер явно задает время, после истечения которого ресурс не может рассматри-

ваться как актуальный). Кроме того, ресурсы, когда oini изменяются, могут не все-

гда иметь совершенно новое значение: некоторые версии ресурса возможно суще-

246

Часть

III. Web-протоколы

ствовали в прошлом. До введения атрибутов содержимого не уделялось серьезного

внимания проблеме асиихронности часов (на компьютерах с кэшами и серверах) и

тому факту, что некоторые ресурсы могут возвращаться к прежней версии. Еще од-

ним стимулирующим фактором была возможность надежной идентификации вер-

сий ресурсов с шагом квантования менее одной секунды.

Ответ для ресурса foo.html может включать атрибут содержимого следующим

образом:

НТТР/1.1 200

ОК

Date:

Sun,

26 Dec 26

1999 18:12:26

GMT

Server: Apache/1.2.6

Red Hat .

Last-Modified: Fri,

24 Dec

1999 06:21:42

GMT

ETag: cc678-12d12-66394036

Content-Length: 15044

Content-Type: text/html

<содержание foo.html>

HTTP/1,1 принимает во внимание тот факт, что существуют многочисленные

версии ресурсов, и запрос мог быть сделан на любую из этих версий. Новые моди-

фикаторы запроса в НТТР/1.1 If-Match и If-None-Match используют атрибуты со-

держимого. В частности эти модификаторы запроса могут быть использованы вме-

сте с атрибутами содержимого, чтобы указать на конкретную версию ресурса. Мо-

дификатор запроса If-Match позволяет клиенту задать один и более атрибутов

содержимого, чтобы проверить, совпадают ли они с текущим вариантом на сервере.

Например, отправитель, использующий метод PUT для обновления ресурса, может

использовать условный PUT, задавая ту версию ресурса, которую он хочет изме-

нить,

чтобы убедиться, что ресурс за это время не изменился. Если у ресурса дру-

гая версия, попытка окажется неудачной и сервер вернет код состояния 412

Precondition Failed.

Например, предположим, что клиент посылает следующий запрос:

PUT /big.html НТТР/1.1

If-Match:

"er82s1poy", "weoi2re"

Сервер сравнит атрибут содержимого текущей версии big.html, чтобы опреде-

лить совпадает ли он с "er82slpoy" или с "weoi2re". Если атрибут содержимого

совпал с любым из них, сервер выполнит запрашиваемое действие. В этом случае,

выполнение запроса приведет к обновлению той версии big.html, которая соответ-

ствует атрибуту содержимого. Если ни один из атрибутов содержимого в запросе

не совпадает с текущей версией, сервер не будет выполнять этот запрос. Вместо

этого он вернет код ответа 412 Precondition Failed.

Новый заголовок запроса If-None-Match также можно использовать с атрибута-

ми содержимого. Хорошее применение этого заголовка

—

это страховка от случай-

ного изменения существующего ресурса. Например, использование заголовка If-

None-Match: * с методом PUT гарантирует, что запрос не будет успешно завершен,

если ресурс существует.

Спецификация НТТР/1.1 проводит различие между строгими и слабыми атри-

бутами содержимого. Строгий атрибут содержимого изменяется всякий раз, когда

одно содержимое отличается от другого хотя бы па один байт. Однако Web-сервер

Глава 7. HTTP/1.1 247

может изменить строгий атрибут содержимого, даже когда содержимое вариантов

не различается. Слабый атрибут содержимого изменяется только тогда, когда су-

ществует семантическое отличие. Предполагается, что слабый атрибут содержимо-

го не изменяется, если Web-сервер не считает, что между вариантами существует

семантическое отличие.

В отличие от НТТР/1.0 ответы 201 Created в НТТР/1.1 могут включать атри-

бут содержимого. Заголовок ответа ETag, включенный в ответ 201 Created, содер-

жит атрибут содержимого того варианта, который был создан (часто в качестве ре-

зультата запроса POST).

ЗАГОЛОВОК VARY

В НТТР/1.0 URI используется в качестве юпоча при сохранении и извлечении

ответа из кэша. Однако различные варианты представления одного и того же ресур-

са делают URI неадекватным ключом. Согласование содержания допускает выбор

ответа, основанный не только на хранящемся в кэше содержании, по и на вариантах

его представления (таких как язык и набор символов). Если кэшируются ответы

с согласованным содержимым, кэш должен отбирать соответствующие варианты. За-

головок ответа Vary используется для перечисления набора заголовков запросов, ко-

торые должны использоваться для выбора соответствующих вариагггов из набора,

хранящегося в кэше.

Сервер определяет, какие критерии должны быть использованы для выбора

подходящего варианта. Например, рассмотрим следующий ответ, который посыла-

ет Web-сервер:

НТТР/1.1 200 ОК

Date:

Sun. 26 Dec 26 1999 18:12:26 GMT

Server: Apache/1.2.6 Red Hat

Last-Modified: Fri, 24 Dec 1999 06:21:42 GMT

ETag:

cc678-12d12-66394036

Content-Length: 15044

Content-Type: text/html

Vary: Accept-Language

Кэш, сохраняющий данный ответ, должен также сохранить значение заголовков

запросов перечисленных в заголовке ответа Vary (в данном примере Accept-

Language). Если последующий запрос, сделанный к кэшу, касается получения кэ-

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

торые перечислены в заголовке Vary, идентичны тем, которые были в исходном за-

просе. Таким образом, если в исходном запросе, результатом которого стал данный

ответ, было

Accept-Language: en-us

тогда для того, чтобы кэш вернул кэшированный ответ па последующий запрос,

в нем должно быть Accept-Language: en-us. Если в последующем запросе имеется

Accept-Language: en-cockney

тогда кэш не сможет вернуть кэшированный ответ и вместо этого должен пере-

слать этот запрос Web-серверу.

248 Часть III. Web-протоколы

7.4. Оптимизация загрузки сети

Сразу после того, как популярность Web стала расти, следующие факторы при-

вели к драматическому росту загрузки сети:

• Размеры ресурсов стали увеличиваться и стали гораздо чаще использоваться

изображения. Размеры графических ресурсов часто превышали размеры тек-

стовых.

• Изображения часто встраиваются в текстовый документ. Типовая Web-стра-

ница включает в среднем около десятка встроенных изображений.

• Пользователей Web становится все больше и больше, совершенствуются спо-

собы подключения к сети.

• Netscape Navigator, популярный браузер середины 90-х годов, использовал

множественные соединения для параллельной загрузки ресурсов.

Необходимость оптимизации загрузки сети привела к исследованию различных

сгюсобов, с помощью которых ресурс можно было преобразовать, сократить его раз-

мер или не передавать его по сети совсем. В HTTP были введены три категории из-

менений, относящиеся к оптимальному использованию полосы пропускания сети:

• Если не нужно передавать весь ресурс (например, если пользователь заинте-

ресован только в части ресурса), то это можно использовать для сокращения

загрузки сети. В протокол необходимо было включить возможность задавать

нужные фрагменты ресурса и передавать их.

• Если отправителю заранее известно, что получатель не сможет обработать

тело сообщения, не следует передавать такой ресурс совсем. Обмен служебной

информацией, которая могла бы подтвердить это, помогла бы избежать пере-

дачи ненужных данных.

• Одним из способов снижения трафика является преобразование ресурса пе-

ред передачей и полное его восстановление на стороне получателя. Преобра-

зование должно по возможности снижать объем ресурса перед передачей.

Новый механизм запроса на диапазон {range request) был введен для решения

первой из трех категорий описанных выше проблем. Механизм Expect/Continue ре-

шает вторую, а сжатие данных решает третью. Мы рассмотрим каждую из этих

трех возможностей, с помощью которых НТТР/1.1 пытается содействовать опти-

мизации трафика в сети.

7.4Л. Запросы на диапазоны

Возможности подключения пользователей к Internet не росли наравне с ростом

популярности Web. Многие пользователи имели (и продолжают иметь) низкоско-

ростные соединения с Internet. Медленная загрузка ресурсов приводит к недоволь-

ству пользователей, которые часто разрывают установленные соединения, загрузив

только часть ресурсов. Если на пути между Web-сервером и клиентом был кэши-

рующий прокси-сервер или если кэширование осуществлялось на уровне браузера,

то уже загруженная часть ресурса обычно находится в кэше. Однако новый запрос

того же ресурса обычно приводит к полной перезагрузке ресурса. При этом впус-

тую увеличивается трафик и общая задержка.

Первоначальное предложение [Din95] по запросам на диапазоны было сделано

в начале 1995 г. и относилось к развитию FTP, при этом приводились два харак-

Глава 7. HTTP/1.1 249

терных довода: (1) устранение полных перезагрузок при возобновлении прерван-

ных передач данных большого объема и (2) возможно, клиентам нужна только

часть ресурса. Возобновление прерванных передач в FTP было уже возможно. Бо-

лее интересное различие между FTP и HTTP заключалось в том, что в FTP редко

осуществлялась передача динамически генерируемых ресурсов. Если прерывалась

передача динамически генерируемого ответа, то этот ответ приходилось генериро-

вать снова, увеличивая задержку. В последнем случае отдельные файлы могли из-

влекаться из файловых архивов (в Internet это обычное дело). В эксперименталь-

ных серверах такие возможности уже были реализованы до появления данного

предложения [Fra95].

Запрос отдельных частей ресурса может быть полезным и в других ситуациях.

Например, агент пользователя может избирательно запрашивать конкретный фраг-

мент в середине ресурса большого объема, не загружая его начала и конца. Пользо-

вателям не всегда нужен весь ресурс. Например, если ресурс постоянно обновляет-

ся,

пользователей, возможно, интересует только обновленная часть. Или если ре-

сурс представляет собой структурированный документ (например, книга с главами,

разделами, страницами и т.д.), избирательный запрос на часть ресурса является ес-

тественным желанием пользователя.

Некоторые типы ресурсов позволяют эффективно и легко использовать запрос на

диапазон, например, в формате Portable Document Format (PDF) компании Adobe

указывается положение начального и конечного байта каждой страницы документа.

Клиент может установить несколько параллельных соединений, осуществлять вы-

борку различных страниц одновременно и восстановить исходный ресурс.

Фактически, необходимость извлекать части документов в формате Adobe PDF

в браузерах была одной из движущих сил введения запросов на диапазоны в их

окончательной форме [FL95J.

Эти проблемы могут быть решены, если инициаторы запросов (например, агенты

пользователя или прокси-серверы) способны указывать отдельные части ресурса,

представляющие для них интерес. Способность формулировать запрос к частям ре-

сурса обеспечивается в HTTP/1.1 механизмом запроса гш диапазон.

Например, используя заголовок Range, клиент может указать, что его интересуют

байты в диапазоне 2000-3999, даже если весь ресурс имеет объем 100 000 байт, толь-

ко 2000 байт будут отправлены сервером. Например:

GET bigfile.html НТТР/1.1

Host: www.justwhatiwant.com

Range:

2000-3999

Метод GET изменен таким образом, чтобы запросить только часть ресурса.

Указанный запрос приведет к следующему ответу сервера, способного обраба-

тывать запросы на диапазоны:

НТТР/1.1 206 Partial Content

Date:

Thu, 10 Feb 2000 20:02:06 GMT

Last-Modified: Wed. 9 Feb 2000 14:58:08 GMT

Content-Range: bytes 2000-3999/100000

Content-Length: 2000

Content-Type: text/html

Заголовок содержимого Content-Range (новый заголовок НТТР/1.1) помогает

получателю разместить загружаемую часть данных в нужное место внутри содер-

жимого ресурса.