Запросы на диапазоны

Возможности подключения пользователей к Internet не росли наравне с ростом популярности Web. Многие пользователи имели (и продолжают иметь) иизкоско- ростиые соединения с Internet. Медленная загрузка ресурсов приводит к недовольству пользователей, которые часто разрывают установленные соединения, загрузив только часть ресурсов. Если на пути между Web-сервером и клиентом был кэширующий прокси-сервер или если кэширование осуществлялось на уровне браузера, то уже загруженная часть ресурса обычно находится в кэше. Однако повый запрос того же ресурса обычно приводит к полной перезагрузке ресурса. При этом впустую увеличивается трафик и общая задержка.

Первопачалыюе предложение [Din95] по запросам на диапазоны было сделано в начале 1995 г. и относилось к развитию FTP, при этом приводились два характерных довода: (i) устранение нолиых перезагрузок при возобповлепии прерванных передач данных большого объема и (2) возможно, клиентам пужпа только часть ресурса. Возобновление прерванных передач в FTP было уже возможно. Более интересное различие между FTP и HTTP заключалось в том, что в FTP редко осуществлялась передача динамически генерируемых ресурсов. Если прерывалась передача динамически генерируемого ответа, то этот ответ приходилось генерировать снова, увеличивая задержку. В последнем случае отдельные файлы могли извлекаться из файловых архивов (в Internet это обычное дело). В экспериментальных серверах такие возможности уже были реализованы до появления данного предложения [Fra95].

Запрос отдельных частей ресурса может быть полезным и в других ситуациях. Например, Агент пользователя может избирательно запрашивать копкретпый фрагмент в середине ресурса большого объема, не загружая его начала и конца. Пользователям не всегда нужен весь ресурс. Например, если ресурс постоянно обновляется, пользователей, возМожно, шггересует только обновленная часть. Или если ресурс представляет собой структурированный документ (например, кпига с главами, разделами, страницами и т.д.), избирательный запрос на часть ресурса является естественным желанием пользователя.

Некоторые типы ресурсов позволяют эффективно и легко использовать запрос на диапазон, например, в формате Portable Document Format (PDF) компании Adobe указывается положение начального и конечного байта каждой страницы документа. Клиент может установить несколько параллельных соединений, осуществлять выборку различных страниц одновременно и восстановить исходный ресурс.

Фактически, необходимость извлекать части документов в формате Adobe PDF в браузерах была одной из движущИх сил введения запросов на диапазоны в их окончательной форме [FL95J.

Эти проблемы могут быть решены, если инициаторы запросов (например, агенты пользователя или прокси-серверы) способны указывать отдельные части ресурса, представляющие для них интерес. Способность формулировать запрос к частям ресурса обеспечивается в НТТР/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) помогает получателю разместить загружаемую часть данных в нужное место внутри содержимого ресурса.

Код ответа 206 Partial Content указывает клиенту на то, что полученный ответ не полоп. Клиент может также запросить только последние N байтов ресурса, указав, что его иптересует конечная часть — суффикс ресурса. Например, следующий запрос касается только последних 1000 байтов ресурса:

GET bigfile.html НТТР/1.1 Host: www.justwhatiwant.com Range: -1000

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

GET bigfile.html НТТР/1.1 Host: www.justwhatiwant.com Range: 9120-

Можно запрашивать не один диапазон, а сразу несколько. Мотив запрашивать несколько диапазонов очевиден: раз уж клиенту известпы отдельные и независимые части ресурса, оп может запросить их все в одном запросе, а сервер может отправить их в виде составного ответа. Сервер использует особый тип для такого типа ответа — multipart/byteranges. Этот тип включает две и более части, каждая из частей включает свой собственный заголовок Content-Range, указывающий диапазон для этой части.

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

GET bigfile.html НТТР/1.1 Host: www.justwhatiwant.com Range: 0-100, 2000-2400, 9600-

Ответом будут первые 101 байг, 401 байт из середины ресурса и все байгы, иа- чнная с байта с номером 9600. Ответ Обычно выглядит следующим образом:

НТТР/1.1 206 Partial Content Date: Thu, 10 Feb 2000 20:25:23 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Fri, 24 Dec 1999 06:21:42 GMT ETag: cc678-12dl2-66394036

Content-type: multipart/byteranges; boundary=———— R0PE—-

——— R0PE—-

Content-Type: text/html Content-Range: bytes 0-100/15044 …первые 101 байтов ресурса…

——— R0PE—-

Content-Type: text/html Content-Range: bytes 2000-2400/15044 …401 байт из середины ресурса…

——— R0PE—-

Content-Type: text/html

Content-Range: bytes 9600-15043/15044

…все байты ресурса, начиная с байта с номером 9600…

——— R0PE——

Строка-разделитель (—— ROPE—) называется граничной строкой и используется для разделения разных диапазонов. Сообщение заканчивается граничной строкой с двумя дополнительными гире. Тип multipart/byteranges является саморазграничительным и не требует, чтобы сервер предоставлял размер содержимого.

В НТТР/1.1 введен ответ 416 Requested Range Not Satisfiable для обработки запросов на диапазоп, который не может быть возвращен из данного ресурса. Например, если клиент сделал запрос

GET /small.html НТТР/1.1 Host: www.justwhatlwant.com Range: 10000-12000, 14000-19000

на ресурс small.html, размер которого меньше 10000 байтов, то будет возвращен код состояния 416 Requested Range Not Satisfiable. Вместе с этим кодом ответа возвращается текущий размер запрашиваемого ресурса в следующем виде:

НТТР/1.1 416 Requested Range Not Satisfiable Content-Length: 9600

НТТР/1.1 не требует от серверов способности обрабатывать запросы на диапазоп, несмотря на то, что в пем подразумевается, что они должпы это делать, если могу г. Сервер способный принимать запросы на диапазоны может объявить о своих возможностях с помощью заголовка ответа

Accept-Ranges: bytes

Тем не менее, клиенты могут делать запросы на диапазоны, не получая такого заголовка ответа от сервера. Если сервер не может обрабатывать запросы на диапазоны, оп просто возвращает полный ответ и код ответа 200 ОК. Серверы могут использовать заголовок Accept-Ranges, чтобы сообщить о неготовности принимать запросы на любые виды диапазонов для ресурса, указав

Accept-Ranges: none

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

Синтаксис запроса на диапазоп со временем менялся. Сначала был предложен синтаксис для определения диапазона байтов как части URL. Например, запрос

http://www.halfway-svc.com/partial/firstpage; byterange=0-49

являлся способом запросить первые 50 байтов ресурса, определяемого ссылкой http://www.halfway-svc.com/partial/firstpage, а запрос

http://www.halfway-svc.com/partial/firstpage; byterange=1500-

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

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

Запрос на диапазон можно разумно комбинировать с условными запросами. Предположим, что запрос на диапазон был сделап для ресурса, находящегося в кэше, по не весь запрошенный диапазон входит в содержимое из кэша. Возможно, что данный ресурс на исходном сервере не изменился, тогда для кэша достаточно получить недостающую часть. Однако если ресурс на Web-сервере изменился, то следует получить весь ресурс. Обычно такая ситуация требует двух запросов: один, чтобы убедиться, что ресурс не изменился, а если ресурс не изменился, то выдается второй с запросом диапазона. Чтобы решить эту задачу одним запросом, НТТР/1.1 предоставляет повое поле заголовка — If-Range. Заголовок If-Range имеет следующую семантику: если ресурс изменен, то в качестве ответа возвращается весь ресурс; в противном случае возвращаются только запрошенные диапазоны. Заголовок If-Range определяет тот вариапт ресурса, по отношению к которому выполняется условный запрос.

Например, рассмотрим следующий запрос:

GET bigfile.html НТТР/1.1 Accept-Language: en-us Accept-Encoding: gzip, deflate Range: bytes=1300-1500 If-Range: cc678-12dl2-66394036 User-Agent: Mozilla Host: www.notonline.com

Если атрибут содержимого ресурса на сервере-источнике совпадает с атрибутом содержимого в заголовке If-Range, сервер вернет только 201 байт из запрошенного диапазона 1300— 1500, иначе оп вернет весь ресурс.

Новый заголовок ответа If-Unmodified-Since в НТТР/1.1 можно использовать в сочетании с запросами на диапазоны, чтобы получить части ресурса, только если ресурс не изменялся. Например, запрос клиента

GET /ads/game03.gif?0CYES НТТР/1.1 Host: www.theads.com Range: bytes=8353-

If-Unmodified-Since: Tue, 26 Oct 1999 10:54:20 GMT

используется, чтобы получить все байты ресурса /ads/game03.gif?OCYES, начиная с байта помер 8353, если ресурс не изменялся с указанной даты. Если ресурс изменился, клиенту требуется весь ресурс. Если ресурс не измепился с указанной даты, сервер может ответить следующим образом:

НТТР/1.1 206 Partial content Server: Microsoft-IIS/3.0 Date: Wed, 27 Get 1999 18:17:29 GMT Content-Type: image/gif

Last-Modified: Tue, 26 Oct 1999 09:54:20 GMT

Content-Length: 14255

Content-Range: bytes 8353-22607/22608

В таблице 7.14 представлен ряд примеров запросов на диапазоны, которые могли быть сделаны для ресурса объемом в 1001 байт. Синтаксис запросов на диапазон довольно гибок. В таблице 7.14 показано, как запрашивать один диапазоп, несколько диапазонов, все байты после байта с заданным помером, определенное число байтов, начиная с конца, и так далее. Представлены также примеры неправильного задания диапазонов, когда сервер не сможет извлечь запрашиваемые байты.

Таблица 7.14. Примеры запросов на диапазоны для 1001-байтного ресурса

Синтаксис диапазона

Интерпретация

100-300

10-30, 50-100, 300-600

920-950, 951-1000

920-970, 951-1000

920- -450

0-0, 1000-1000

0-0, -1

950-1100

950-900

201 байт от 100 до 300

373 байта от 10-30, 50-100 и 300-600

81 байт от 920 до 1000

81 байт от 920 до 1000

81 байт от 920 до 1000

последние 450 байтов от 551 до 1000

Первый и последний байты

Первый и последний байты

Неправильный диапазон (превышает 1000)

Неправильный диапазоп (помер первого байта превышает номер второго)

Первоначальная идея диапазонов [FL95J вышла за пределы просто диапазонов байтов и подсказала способы запроса строк документов или глав статьи, то есть того, что диапазоны должны быть независимыми от типа документа. Хотя текущий стандарт НТТР/1.1 разрешает только запросы на диапазоны байтов, в будущем это может быть расширено на семантически более значимые диапазоны. Например, Можно себе представить запрос разделов статьи, фрагментов аудиоресурсов или видеоклипов из кинофильмов. Протокол оставляет возможность для таких расширений в будущем открытой. Фактически, протокол Real Time Streaming Protocol (RTSP) [SRL98] допускает запросы на диапазоны по времени (см. главу 12, раздел 12.4).

Источник: 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