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

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

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

Код ответа 206 Partial Content указывает клиенту на то, что полученный ответ

не полон. Клиент может также запросить только последние N байтов ресурса, ука-

зав,

что его интересует конечная часть

—

суффикс ресурса. Например, следующий

запрос касается только последних 1000 байтов ресурса:

GET bigfile.html НТТР/1.1

Host; www.justwhatiwant.com

Range:

-1000

Если клие1ггу не известен текущий размер ресурса, а его начальная часть уже

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

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

вить следующий запрос:

GET bigfile.html HTTP/1.1

Host: www.justwhatiwant.com

Range:

9120-

Можно запрашивать не один диапазон, а сразу несколько. Мотив запрашивать

несколько диапазонов очевиден: раз уж клиенту известны отдельные и независи-

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

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

тина ответа

—

multipart/by teranges. Этот тин включает две и более части, каждая из

час гей включает свой собственный заголовок Content-Range, указывающий диана-

зон для этой части.

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

ким. Набор диапазонов задается с помощью разделяющих эти диапазоны запятых.

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

juero вида:

GET bigfile.html HTTP/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/byte

ranges;

boundary= ROPE

ROPE

Content-Type: text/html

Content-Range: bytes 0-100/15044

...первые

101

байтов ресурса...

ROPE

Content-Type: text/html

Content-Range: bytes 2000-2400/15044

...401 байт

из

середины ресурса...

ROPE

Content-Type: text/html

Глава

HTTP/1.1 251

Content-Range: bytes 9600-15043/15044

...все байты ресурса, начиная

байта

номером

9600...

ROPE

Строка-разделитель ( ROPE—) называется граничной строкой и использу-

ется для разделения разных диапазонов. Сообщение заканчивается граничной

строкой с двумя дополнительными тире. Тип multipart/byteranges является само-

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

В НТТР/1.1 введен ответ 416 Requested Range Not Satisfiable для обработки

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

пример, если клиент сделал запрос

GET /small.html HTTP/1.1

Host: www.justwhatiwant.com

Range: 10000-12000, 14000-19000

на ресурс small.html, размер которого меньше 10000 байтов, то будет возвращен

код состояния 416 Requested Range Not Satisfiable. Вместе с этим кодом ответа

возвращается текущий размер запрашиваемого ресурса в следующем виде:

НТТР/1.1 416 Requested Range Not Satisfiable

Content-Length: 9600

HTTP/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 означает,

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

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

возвращать сообщение об 011Н1бке, а не полный ответ. Если же добавить новый за-

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

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

полный ответ. Та тщательность, с которой создаются расширения протокола, отра-

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

Запрос на диапазон можно разумно комбинировать с условными запросами.

Предположим, что запрос на диапазон был сделан для ресурса, находящегося

в кэше, но не весь запрошенный диапазон входит в содержимое из кэша. Возмож-

но,

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

но получить недостающую часть. Однако если ресурс па Web-сервере изменился,

то cjieviycT получить весь ресурс. Обычно такая ситуация требует двух запросов:

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

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

НТТР/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 байт из запрошенного

диапазона 13.00-1500, иначе он вернет весь ресурс.

Новый заголовок ответа If-Unmodified-Since в НТТР/1.1 можно использовать

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

ресурс не изменялся. Например, запрос клиента

GET /ads/game03.gif?0CYES НТТР/1.1

Host: www.theads.coin

Range: bytes=8353-

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

используется, чтобы получгггь все байты ресурса /ads/game03.gif?OCYES, начи-

ная с байта номер

8353,

если ресурс не изменялся с указанной даты. Если ресурс

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

даты, сервер может ответить следуюи1им образом:

НТТР/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. HTTP/1.1

253

В таблице 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 1

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

81 байт от 920 до 1000

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

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

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

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

номер второго) 1

Первоначальная идея диапазонов [FL95J вышла за пределы просто диапазонов

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

что диапазоны должны быть независимыми от тина документа. Хотя текущий стан-

дарт НТТР/1.1 разрешает только запросы на диапазоны байтов, в будущем это мо-

жет быть расширено на семантически более значимые диапазоны. Например, можно

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

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

дущем открытой. Фактически, протокол Real Time Streaming Protocol (RTSP)

[SRL98] допускает запросы на диапазоны по времени (см. главу 12, раздел 12.4).

7.4.2. Механизм Expect/Continue

Если HTTP-сервер не может обрабатывать запросы большого объема, было бы

полезно для клиента знать об этом до того, как посылается запрос. Клие1гг может

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

правки запросов на большие ресурсы. Рассмотрим пример обработки Web-серве-

ром больших форм с помощью методов PUT или POST. Хотя протокол не накла-

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

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

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

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

тельные усилия и время на заполнение формы. У агентов пользователя могут быть

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

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

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

проса, полезен для клиента и сокращает бесполезный трафик.

254

Часть

IIL Web-протоколы

Механизм Expect обеспечивает именно такое решение. Он позволяет клиенту

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

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

обработать данный запрос, он может сообщить об этом с помощью ответа 100

Continue. Сервер, неспособный обработать такой запрос, может послать соответст-

вующий код ответа, основанный на конкретной причине неспособности обработать

/1а1Н1ый запрос. Если запрос имеет слишком большой объем, сервер может послать

413 Request Entity Too Large. Если данному клиенту не было разрешено сделать

такой запрос, сервер может послать 403 Forbidden. Если сервер получает неизвест-

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

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

он посылает ответ в виде кода состояния 417 Expectation Failed. Ответ посылается

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

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

Клиент планирует послать тело запроса размером 23248 байтов.

POST /foo/bar HTTP/1.1

Content-Length: 23248

Expect: 100-Continue

Сервер может ответить так:

HTTP/1.1 100 Continue

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

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

iHHO.

Если сервер не сможет обработать такой запрос, он отправит следующий от-

вет и, возможно, закроет соединение:

НТТР/1.1 417 Expectation Failed

Клиенты могут включать дополнительные значения в заголовок Expect. Напри-

мер,

клиент может послать аутентификационную информацию пользователя, ини-

циировавшего этот запрос. Если сервер принимает эту информацию, он обычно по-

сылает ответ 100 Continue, и клиент может отправлять тело сообщения-запроса

в следующем виде:

POST /secure.txt НТТР/1.1

Host: www.topsecret.org

Authorization: Basic ZGufaWP6J29atWU=

Expect: 100-Continue

Если сервер возвращает промежуточный код ответа

НТТР/1.1 100 Continue

клиент может продолжать запрос. Если вместо этого сервер возвращает

НТТР/1.1 401 Authorization Failed

оставшаяся часть запроса не передается. Клиенту придется или посылать новые

цттые для авторизации, или отказаться от запроса.

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

бов дальнейшего развития протокола его разработчиками. Полезность некоторых

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

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

ществует несколько несовместимых версий так называемых НТТР/1.1-реализаций

Глава 7. HTTP/1.1 255

компонентов, что вынуждает спецификацию протокола относиться более терпимо

к операциям с механизмом Expect. Может случиться так, что клиент, который посы-

лает заголовок Expect: 100-Continue, будет ждать ответа 417 Expectation Failed или

100 Continue неопределенное время. Чтобы исключить такую ситуацию, клиент дол-

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

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

реализации клиента). Протокол запрещает клиенту ждать неопределегнюе время,

хотя и не определяет продолжительность таймаута. Поэтому клиент использует для

ожидания не детерминированный, а случайный период времени.

Механизм Expect является механизмом промежуточных передач. Ожидание оп-

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

дующий сервер не соответствует ожиданиям, то этот сервер должен вернуть код

ошибки 417 Expectation Failed. Однако заголовок запроса Expect является заго-

ловком сквозного тина. Если следующий сервер (например, прокси-сервер) пере-

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

слать вместе с ним также и заголовок запроса Expect.

Хотя механизм Expect был предложен для обработки запросов большого объема,

связанных с методами PUT и POST, он может использоваться в будущем и для дру-

гих расширений. Серверы, которые пока еще не воспринимают новых расширений,

обязаны возвращать код состояния 417 Expectation Failed. Возможным расширени-

ем механизма Expect является совершенствование схемы согласований НТТР/1.1.

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

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

связанной с ответом 100 Continue. Ответ 100 Continue был предложен почти за

два года до введения заголовка Expect. Ответ 100 Continue был введен, чтобы сер-

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

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

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

мет его запрос. Если Web-сервер не намерен продолжать чтение входных данных,

он может послать сообщение об ошибке. Например, если запрос клиента POST,

включает заголовок Content-Length, и сервер знает, что не сможет обработать за-

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

такой запрос, он может послать ответ 100 Continue. Такое решение требует, чтобы

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

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

посылать ни 100 Continue, пи сообщение об ошибке. Первым предложением было

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

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

чаях. Еще важнее было то, чтобы клиенты, использующие НТТР/1.0, не могли вос-

принимать ответ 100 Continue, так как он был определен только в НТТР/1.1.

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

четом, чтобы ответ 100 Continue был возможен только в том случае, если в запросе

присутствовал заголовок Expect. Не все клиенты должны ждать ответ 100 Continue.

Окончательная формулировка правил для клиентов и серверов в НТТР/1.1 содержит

следующее: клиент должен гюслать заголовок Expect, если он намерен ждать ответ

100 Continue, а сервер должен верпръ или 100 Continue, или заключительное сооб-

щение об ошибке. Если клиент, отправивший заголовок Expect, так и не получил от

Web-сервера ответ 100 Continue, он не должен ж^ать неопределенно долго, а может

продолжать свою работу и отправить содержимое запроса.

256

Часть

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

7.4.3.

Сжатие

Хороший способ снижения загрузки сети

—

это сжать ответ так, чтобы это было

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

ного уровня и входит в НТТР/1.0. Некоторые популярные форматы графических

да1Н1ых являются предварительно сжатыми. Например, популярными форматами

изображений являются GIF и JPEG, в которые включено сжатие

jx'diuihix.

От по-

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

которые обычно хранятся в несжатом виде (например, обычный текст) могут быть

сжаты Web-сервером перед их передачей. Допустимо даже сжатие заголовков за-

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

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

Кодирование содержания было возможно в НТТР/1.0 (с помощью заголовка

содержимого Content-Encoding) и указывало на способ преобразования ресурса по

сквозному принципу. Поскольку НТТР/1.0 не делал различий между механизмом

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

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

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

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

мы.

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

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

лучателю не обязаны ничего знать об этом алгоритме. Кроме того, если имеется

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

на предпочтительный алгоритм. И то, и другое возможно в HTTP/1.1.

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

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

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

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

ния предпочтительных схем кодирования при передаче. Например,

ТЕ:

vdcomp; q=0.9, compress; q=0.1

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

соким коэффициентом качества 0.9 и compress с низким коэффициентом качества

0.1.

Клиент при выборе коэффициента качества (0.9 для vdcomp и 0.1 для

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

соответствующих программ и быстродействие этих алгоритмов. Сервер, получив

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

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

значение коэффициента качества, равное

(то есть рассматриваемый как неприем-

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

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

ном выше, сервер может выбрать кэшированпое значение в формате compress, иг-

норируя тот факт, что инициатор запроса может предпочитать формат vdcomp.

Сервер, который или не может, или не готов выполнить специфическое кодирова-

ние при передаче, не осуществляет преобразование ответа. Заголовок ТЕ применим

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

щие алгоритм сжатия vdcomp, могут извлечь из этого выгоду, включив этот заго-

ловок.

Глава 7. HTTP/1.1 257

7.5.

Управление соединениями

Фактически все известные реализации HTTP используют TCP в качестве

транспортного протокола. Однако TCP не был оптимизирован для краткосрочных

соединений, типичных для обмена сообщениями в HTTP. Использование TCP

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

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

того соединения (глава 5, раздел 5.2.3). Типичное НТТР-сообщение состоит из 10

пакетов. Таким образом 7 из 17 пакетов представляют собой накладные расходы.

Это также означает, что ни одна Web-трапзакция не обходится без медленной на-

чальной фазы установления ТСР-соединепия [Jac88J (обсуждалось в главе 5, раз-

дел 5.2). Прежде чем размер скользящего окна TCP сможет существенно увели-

читься, соединение закроется. Это означает, что доступная полоса пропускания ни-

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

По мере роста популярности Web, в Web-страницы стали включать встроенные

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

бражений требовала нескольких HTTP-транзакций и, следовательно, нескольких

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

ощущал задержку, являющуюся результатом последовательности соединений. По-

добным образом был реализован Mosaic

—

один из первых популярных браузеров.

Одним из способов снизить задержку было введение параллельных НТТР-соеди-

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

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

грузку всего документа. Однако это увеличивало общую загрузку сети, на сервер

ложилась дополнительная нагрузка по поддержанию множества ТСР-соединений.

Другим решением данной проблемы было использование одного ТСР-соедипе-

иие для нескольких HTTP-транзакций. Это привело к введению в НТТР/1.1 долго-

временных соединений (persistent connections). Основной идеей, лежащей в основе

долговременных соедиР1ений, было сокращение числа открываемых и закрываемых

ТСР-соединений. Вместе со снижением числа открытий и закрытий ТСР-соедине-

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

ло ее загрузку. Увеличение времени существования ТСР-соединений позволяет

серверу получить информацию о загруженности сети. Если загрузка меньше, мож-

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

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

при последовательной передаче ответов по одному соединению получается за счет

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

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

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

ния нового и фазы медленного старта ТСР-соединепия. Сообщения об ошибках за-

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

В этом разделе мы проследим эволюцию механизма долговременных соедине-

ний в HTTP до их теперешнего стандартизованного состояния.

• В разделе 7.5.1 рассматривается старый механизм Keep-Alive, существовав-

ший в некоторых реализациях НТТР/1.0.

• Раздел 7.5.2 посвящен нескольким первым предложениям по долговременным

соединениям в НТТР/1.1 и множестве1Н1ым параллельным соединениям, ко-

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

механр1зма долговременных соединений, который был введен в НТТР/1.1.

258

Часть

III.

Web-протоколы

• В разделе 7.5.3 анализируется роль заголовка Connection в долговременных

соединениях HTTP/1.1, особенно той роли, которую играет этот заголовок

при сохранении открытых соединений и при их закрытии.

• В разделе 7.5.4 рассматривается роль конвейеризации в долговременных со-

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

в процессе обработки последовательности запросов.

• В разделе 7.5.5 анализируется решения, которые должны принимать клиенты

и серверы перед закрытием долговременного соединения. Протокол не дает

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

ся открытым.

Существенные изменения, относящиеся к управлению соединениями, обсужда-

ются подробно из-за их важности.

7.5.1.

Заголовок Connection.

Механизм Keep-Alive в НТТР/1.0

Возможность продлевать http-соединение за пределы одной транзакции за-

прос-ответ в НТТР/1.0 первоначально отсутствовала. Однако по мере роста попу-

лярности Web некоторые реализации НТТР/1.0 ввели разновидность долговре-

менных соединений. Некоторые браузеры включали заголовок запроса Keep-Alive

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

нения текущего запроса. Серверы, готовые оставить соединение открытым, прини-

мали данный заголовок и не закрывали соединение после передачи ответа.

Идея, лежащая в основе Keep-Alive, та же, что и у долговремегнхых соединений

в НТТР/1.1. Клиент, заинтересованный в сохранении соединения открытым, про-

сил, чтобы Web-сервер не закрывал данное соединение. Это делалось следующим

образом:

GET /home.html НТТР/1.0

Connection: Keep-Alive

Если сервер также был заинтересован в сохранении открытого соединения, он

отправлял следующий ответ:

НТТР/1.0 200

ОК

Connection: Keep-Alive

<тело ответа>

Однако если сервер, использующий НТТР/1.0, передает динамическое содер-

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

закрытия этого соединения сервером. Динамически генерируемое содержание

обычно не включает заголовок Content-Length, поскольку ожидание вычисления

длины после завершения формирования содержания увеличивало задержку для

клиента.

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

ков),

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

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

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

лать по этому долговремегпюму соединению более определенного числа запросов.

Глава

HTTP/1.1

259

7.5.2. Эволюция механизма долговременных соединений

в НТТР/1.1

Еще до введения современного механизма долговременных соединений

в НТТР/1.1 предпринимались разнообразные попытки сохранять НТТР-соедипе-

пия за пределами одной транзакции запрос-ответ. Их можно подразделить па два

больших класса: (1) новые методы HTTP, которые можно было использовать для

получения более чем одного ресурса и (2) использование нескольких параллель-

пых соединений для выборки ресурсов. Первый подход включал вариации меха-

низма многократного метода GET, позволяющего выполнить многократные запро-

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

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

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

време1Н1ых соединений в НТТР/1.1, начиналась с попыток избежать необходимо-

сти создавать несколько параллельных соединений.

Подход, связанный с новыми методами HTTP: MGET, GETLIST, GETALL.

Первый подход предлагал новые методы HTTP для передачи нескольких запросов

по одному и тому же транспортному соединению. Было предложено три метода:

MGET, GETLIST и GETALL. Ни одно из этих предложений не сохранилось в про-

цессе эволюции протокола и не вошло в НТТР/1.1. Однако рассмотреть предлагав-

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

Предложение но введению нового метода MGET, было сделано в [Fra94a,

Fra94bJ. Метод MGET похож на комагщу FTP mget, посредством которой можно

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

ределенному шаблону. В FTP, команда mget требовала нескольких соединений для

передачи данных, то есть отдельных ТСР-соедипепий. Предложенный метод HTTP

MGET не требовал установления нескольких ТСР-соедипепий, путем перечисле-

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

Web-сервером последовательно. В следующем примере запроса MGET, заимство-

ванном из [Fra94a], приводится список нескольких URI вместе с модификаторами

запроса:

MGET НТТР/1.0 ^

URI:

/image1.gif

URI:

/image2.gif

If-Modified-Since: Saturday 29-0ct-94 20:04:01

GMT

URI:

/image3.gif

GRLF

Сервер откликается на запрос MGET, посылая ответы для каждого из запрошен-

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

ния, что позволяет клиенту правильно обработать ответ:

НТТР/1.0 200

ОК

URI:

/imagel.gif

Content-Type: image/gif GRLF

2200

...

2200 байтов данных изображения

GRLF

НТТР/1.0 304

Not

Modified

URI:

/image2.gif