Упреждающая выборка в HTTP

После установления ТСР-соединения Web-клиент выдает НТТР-запрос Web- серверу. Даже если клиент имеет кэшировапную копию запрашиваемого ресурса, у пего может возникнуть необходимость связаться с сервером для проверки актуальности кэшированной версий. Время ожидания получения НТТР-ответа зависит от множества факторов, в том числе от времени создания ответа на сервере, размера сообщения-ответа и пропускной способности сети. Клиент может замаскировать задержку на стороне пользователя, выдав заранее HTTP-запрос и кэшировав ответ. Если пользователь запрашивает ресурс, клиент может нредоставить ресурс непосредственно из своего кэша. Предполагая, что кэшированпый ответ не устарел, клиент может удовлетворить пользовательский запрос без оиределепия IР-адреса сервера, открытия соединения с сервером и отправки HTTP-запроса. Пользователь получит ответ практически немедленно. Кроме того, упреждающая выборка может сделать использование ТСР-соедипепий более эффективным, нежели при традиционных Web-передачах, управляемых действиями пользователя. Клиент с упреждающей выборкой может осуществить конвейерную обработку ряда запросов в ходе одного постоянного соединения, а совместная передача сообщений-ответов позволяет избежать дополнительных затрат, связанных с повторением фазы медленного старта нри управлении скользящим окном.

Упреждающей выборке HTTP-ответов носвящеиы многочисленные исследования [Bes95, PM96, JK98, CB98, Duc99]. Несмотря на потенциальное уменьшение времени Ьжидания на стороне пользователя, извлечение с упреждением Web-pecypcoB может вызвать значительное увеличение нагрузки на Web-сервер и сеть. Упреждающая выборка не принесет пользы, если запросы пользователя на ресурс и выбираемый с упреждением ответ не будут оставаться актуальными. Кроме того, пропускная способность сети и сервера, выделенная под передачу ответа, испытывает конкуренцию со стороны других текущих передач. Например, предположим, что пользователь осуществляет доступ в Web через модем с низкой пронускпой способпостыо [HL96, LB97]. С одной стороны, упреждающая выборка в моменты бездействия позволит более эффективно использовать ограниченную пропускную способность. С другой стороны, упреждающая выборка в момент загрузки пользователем другой Web-страницы увеличит время ожидания для текущей страницы. Кроме того, упреждающая выборка ресурса может привести к вытеснению других ресурсов из кэша клиента, что в будущем увеличит время ожидания ответов на другие запросы.

Вместо упреждающей выборки ресурса сервер может осуществить выборку метаданных ресурса. Например, клиент может отправить запрос HEAD серверу, как говорилось ранее в разделе 13.1.2. HTTP-ответ будет иметь те же заголовки, что и ответ на запрос GET. Эта информация особенно полезна, если клиент уже имеет кэшировапную копию ресурса. В зависимости от того, был ли ресурс изменен исходным сервером, клиент может аннулировать кэшировапный ресурс, либо обновить информацию об актуальности ресурса. Заголовки в сообщении-ответе могу г быть полезными даже в том случае, если клиент не имеет кэшированпой копии ресурса. Например, клиент может просмотреть заголовки, относящиеся к кэшированию, такие как Last-Modified, Cache-Control или Content-Type, чтобы определить, стоит ли осуществлять упреждающую выборку ресурса. Клиент может принять решение не выбирать с упреждением ресурс, который не кэшируется или часто изменяется. Кроме того, клиент может просмотреть заголовок Content-Length с целью определения размера ресурса. Клиент может решить осуществить упреждающую выборку ресурса, если заголовок Content-Length указывает, что размер ресурса меньше некоторого порогового значения. Это позволит избежать упреждающей выборки ресурсов, отвлекающих на себя значительную часть сетевого трафика.

Вместо того чтобы выдавать запрос HEAD для определения размера ресурса, клиент может непосредственно управлять объемом данных, выбираемых с упреждением, путем передачи запроса GET с заголовком Range (в предположении, что Web-сервер допускает запросы на диапазоны). Например, клиент может запросить первые 1000 байтов ресурса. Это позволит клиенту загружать небольшой ресурс целиком, а для большого ресурса загружать его начальную часть. В некоторых случаях может оказаться полезной упреждающая выборка префикса ресурса [Hor98, SRT99]. Например, первые песколько байтов GIF-файла содержат размер изображения и могут представлять собой версию рисунка с меньшим разрешением. Имея префикс изображения до запроса пользователя, браузер может начать воспроизведение изображения. Аналогично префикс аудио- или видеоклипа может содержать достаточное количество кадров, чтобы начать воспроизведение потока [SRT99, GRB00]. Как только пользователь запросит ресурс, браузер может отправить второй запрос Range, чтобы осуществить выборку оставшегося содержимого. С точки зрения пользователя содержимое начинает воспроизводиться немедленно, несмотря на то, что браузер заранее осуществил выборку только начальной части ресурса.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100