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

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

260

Часть

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

CRLF

HTTP/1.0

200 OK

URI:

/image3.gif

Content-Type: image/gif

CRLF

7180

...

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

CRLF

Клиент просматривает каждый ответ до CRLF и извлекает отдельные ответы. Оче-

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

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

грузки сети.

Предложение MGET возникло в контексте дискуссий о получении страницы вме-

сте с встроенными в нее изображениями. Имея информацию о размерах изображе-

ний, встроенных в HTML-страницу, браузер мог осуществлять ее отображение, хотя

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

информацию либо средствами HTML, либо от сервера. Например, информация о

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

та-контейнера. Однако это потребовало бы от протокола сведений о содержимом

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

сервер мог бы включать эту информацию в заголовок ответа. Однако зависимость от

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

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

том же Web-сервере, что и документ-контейнер.

GETLIST и GETALL [PM95J но сути похожи на МОЕТ. Используя GETLIST,

клиент может запросить конкретный список ресурсов. Чтобы запросить все ресур-

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

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

все составляющие документа, не требуя отдельных запросов GET. Преимущество

GETLIST по сравнению с GETALL заключалось в том, что клиент, имеет возмож-

ность выбирать, какие из встроенных ресурсов запрашивать. Один и тот же ресурс

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

шивать такой ресурс более одного раза.

Подход, связанный с параллельными соединениями. Альтернативным подхо-

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

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

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

параллельно. Параллельные соединения были реализованы в 1994 г. в одной из

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

нять ограниченную точку зрения на опыт эксплуатации Web исключительно с по-

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

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

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

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

ТСР-соединений, увеличивают зафузку сети. Если слишком много клиентов нач-

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

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

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

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

Глава 7. HTTP/1.1 261

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

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

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

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

альную пропускную способность.

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

связанный с отменой запросов. Рассмотрим следующий сценарий: на Web-сервере

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

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

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

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

были затрачены напрасно.

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

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

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

должно отдельно «платить свою плату» за установление ТСР-соединения и за прохо-

ждение фазы медленного старта (согласно изложенгюму в главе 5, раздел 5.2.6).

Долговременные соединения в НТТР/1.1. Наряду с множеством предлагав-

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

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

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

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

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

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

ного соединения была похожа на предложения, рассмотренные ранее, и преследо-

вала три цели:

• Снижение «стоимости» ТСР-соединения (меньше открытий и закрытий).

• Уменьшение задержки путем сокращения фаз медленного старта ТСР-соеди-

нений.

• Сокращение потерь полосы пропускания и снижение общей загрузки.

Предложенные изменения на уровне HTTP были незначительными. Можно

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

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

Этот способ известен как конвейеризация {pipelining) и излагается в разделе 7.5.4.

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

используют долговременные соединения. Потребности нескольких конкретных

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

прокси-сервером и Web-сервером, если прокси-сервер поддерживает долговремен-

ное соединение с данным Web-сервером.

Значительным шагом, обеспечивающим широкое использование долговременных

соединений, было введение в НТТР/1.1 данного типа соединения в качестве умалчи-

ваемого. Соединение Keep-Alive было необязательным в реализациях НТТР/1.0.

В спецификации НТТР/1.1 реализация долговременных соединений относится к ре-

комендуемым требованиям (требования уровня SHOULD). Хотя ничто не мешает

администратору Web-сайта отключить установку долговременных соединений в ка-

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

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

оставлять долговременные соединения в качестве соединений по умолчанию. Адми-

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

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

ных соединений в качестве установки гю умолчанию в настройках сервера должны

сделать это в явном виде. Поскольку в большинстве случаев установки по умолча-

нию оставляются «как есть», преимущества долговременных соединений вероятно

должны стать доступны большинству пользователей.

Предложения GETALL и GETLIST преобразовались в механизм долговремен-

ных соединений, который стал частью стандарта НТТР/1.1. Ни один из предло-

женных методов (MGET, GETALL и т.д.) не сохранился в окончательном варианте

протокола. Хотя множественные параллельные соединения довольно распростра-

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

чивают наиболее эффективное использование сетевых ресурсов и минимальное

время ожидания для пользователей.

Еще одна тема, касающаяся долговреме1Н1ых соединений, — это наличие про-

кси-серверов и кэшей. Должно ли долговременное соединение осуществляться по

сквозному принципу (между клиентом, цепочкой прокси-серверов и Web-серве-

ром)? Необходимо позаботиться о прокси-серверах, которые работают по протоко-

лу НТТР/1.0 и не воспринимают долговременных соединений. Эта тема обсужда-

ется более подробно в разделе 7.11.

7.5.3.

Заголовок Connection

Некоторые реализации НТТР/1.0 используют заголовок Connection чтобы ос-

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

прос-ответ. Однако в НТТР/1.1 в соответствии с тенденцией к обеспечению управ-

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

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

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

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

больше нет оснований сохранять открытое соединение с данным конкретным сер-

вером. Обе стороны могут включить заголовок Connection:close, чтобы сообщить о

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

мерений другой стороны.

Общий заголовок Connection был описан выше, как имеющий более широкое

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

щего соединения транспортного уровня с соседним сервером. Иначе говоря, сервер,

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

ловки перечисленные в нем. Вариант Connection: close был введен в качестве спо-

соба обеспечения совместимости с прежней (НТТР/1.0) формой долговремегн1ых

соединений. Некоторые реализации НТТР/1.0 поддерживают заголовок Connec-

tion: Keep-Alive. Вместо того чтобы изобретать новый заголовок, семантика кото-

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

в НТТР/1.1 использовал Keep-Alive в качестве одной из многих возможных лек-

сем заголовка Connection. Защита заголовка (т.е. обеспечение того, чтобы данный

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

с существующей лексемой Keep-Alive. Так как но умолчанию в НТТР/1.1 реализу-

ется долговременное соединение, то это выглядит, как если бы заголовок Connec-

tion: Keep-Alive включался в каждое сообщение. Проблема, связанная с поддержа-

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

заголовки Connection, обсуждается в разделе 7.11.3.

Глава 7. НТГР/1.1 263

7.5.4. Конвейеризация в долговременных соединениях

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

ходимых для создания и закрытия ТСР-соединений. Клиент, посылающий запрос

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

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

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

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

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

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

ся благодаря конвейеризации [Pad95].

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

долговременному соединению:

GET /foo1.jpg НТТР/1.1

CRLF

GET /foo2.jpg НТТР/1.1

GRLF

GET /foo3.jpg НТТР/1.1

CRLF

GET /foo4.jpg НТТР/1.1

CRLF

В примере присутствуют запросы четырех ресурсов: fool.jpg, foo2.jpg, foo3.jpg и

foo4.jpg, объединенных в конвейер в одном HTTP-соединении. Клиент извлекает

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

каждого ответа до отправки следующего запроса.

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

него,

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

ны.

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

чить актуальное содержание ресурса. Спецификация протокола предполагает, что

только идемпотентпые методы (глава 6, раздел 6.2.2) должны использоваться после-

дователыю. Например, если запрос GET следует за предшествующим ему запросом

PUT,

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

сурса (возможно измененного запросом PUT). Однако это предполагает, что оба

конвейеризированных запроса были обработаны без перерыва. Если соответствую-

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

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

БЛОКИРОВКА ТИПА «ПЕРВЫЙ В ОЧЕРЕДИ«^

Если один из предшествующих запросов ресурса в конвейере занимает значи-

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

проблема обостряется, когда соединение осуществляется с прокси-сервером, кото-

рый передает запросы конвейера разным Web-серверам. Возможно, что первый

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

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

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

шой) запрос. Эта ситуация известна как блокировка «первый в очереди (head of

line)» [Get97]. Таким образом, если отправителю известно, что предыдущие запро-

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

просы, следующие за продолжительными запросами. Отправителю, тем не менее,

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

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

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

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

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

были получены запросы. Это самое простое, что может сделать сервер. Специфика-

ции протоколов предпочитают ошибаться «по простоте своей».

СЛУЧАИ НЕПРЕДВИДЕННОГО ЗАКРЫТИЯ ПОТОКА

КОНВЕЙЕРИЗИРОВАННЫХ ЗАПРОСОВ

Существует множество причин, по которым HTTP-соединение может завер-

шиться аварийно. Пользователь может намеренно прервать соединение, нажав

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

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

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

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

Долговременные соединения страдают от всех помех, связанных с аварийными

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

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

тель может просто повторить его (если он сам не инициировал этого завершения)

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

ние).

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

стояния для таких методов как GET и HEAD. Однако в случае методов PUT и

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

последовательность запросов представляет собой конвейер, и пользователь завер-

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

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

тальные запросы.

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

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

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

были обработаны. Обычно это не является проблемой. Однако если сама последо-

вательность запросов имеет существегнюе значение (то есть существует зависи-

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

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

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

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

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

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

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

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

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

токолов нижних уровней является некорректным проектным решением. Эта тема

обсуждается более подробно в главе 8 (раздел 8.2.1).

7.5.5.

Закрытие долговременных соединений

При установлении долговременного соединения рождается естественный во-

прос,

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

рает никакой роли, оставляя его на усмотрение компонентов, участву10ш;их в со-

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

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

Глава 7. HTTP/1.1 265

формулировать отказ от сохранения соединения открытым. Однако не существует

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

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

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

Должны быть согласованы следующие противоречивые интересы:

• Серверу нужно обслуживать множество различных клиентов. Сохранение от-

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

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

ных прав.

• Сервер может принять решение обработать больше запросов от какого-то кли-

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

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

• Серверу может потребоваться закрыть соединение при достижении некоторо-

го лимита времени, чтобы обеспечить равноправие клиентов. Лимит может от-

носиться к общему времени существования соединения в открытом состоянии

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

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

и полосы пропускания сети.

• Сервер может быть подключен к особому клиенту (или прокси-серверу), мо-

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

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

вания клиентов.

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

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

ние параметров долговременных соединений (и в запросе, и в ответе). Среди пред-

ложений были:

• timeout. Дагнхый параметр задает время существования долговремегнюго со-

единения.

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

но по данному долговременному соединению.

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

требуется сохранения их состояний.

Однако перечисленные дополнительные параметры создавали проблемы. Пара-

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

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

ные прокси-серверы могли использовать собственные значения параметров. Ис-

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

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

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

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

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

закрыть. Параметры timeout и max были реализованы в одной из ранних версий

сервера NCSA [Sin95]. Поскольку запросы должны появляться последовательно,

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

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

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

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

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

были большие заголовки Accept. Однако параметр state существенно увеличивает

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

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

говременного соединения.

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

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

гда закрывать долговременное соединение. Фактически при реализации долговре-

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

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

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

менно закрытыми соединениями. Например, НТТР/1.1 требует, чтобы запросы POST

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

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

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

ответа от сервера. Попытка может повторяться после того, как пройдет некоторое вре-

мя несколько раз, пока не будет получен код состояния (4хх или 5хх).

7.6. Передача сообщений

Осгювная задача при обмене HTTP-сообщениями состоит в том, чтобы стороны

могли распознать полное и без каких-либо потерь получение сообщений. Надежная

доставка сообщения по сети — главное для поддержания целостности транзакций.

Размер ответа — это полезный признак, позволяющий получателю определить, что

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

ры,

использующие НТТР/1.0, могли сообщить размер тела содержимого, было поле

заголовка Content-Length. Длина статического ресурса могла быть легко определена

с помощью системного вызова операционной системы. При динамически генерируе-

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

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

поле заголовка Content-Length не может быть заполнегю. Следовательно, исходный

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

Это требует буферизации ответа, увеличивая таким образом задержку для конечного

пользователя.

В НТТР/1.0 сервер указывает на конец динамически генерируемого ресурса пу-

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

—

единственный способ ука-

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

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

чания сообщения без закрытия соединения.

НТТР/1.1 решает проблему надежной передачи сообщений с помощью разбг/^-

ния тела сообщения на фрагменты {chunks), что позволяет отправителю передавать

их независимо. Каждой части предшествует ее размер, позволяющий получателю

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

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

получение его указывает, что все сообщение было благополучно передано. Разбие-

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

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

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

НТТР/1.0. Этот механизм также устраняет задержку, связанную с ожиданием за-

Глава

HTTP/1.1

267

вершения генерации всего ответа перед добавлением заголовка Content-Length

(как это обсуждалось выше).

Рассмотрим следующий пример ответа разбитого на фрагменты:

НТТР/1.1 200

ОК

Server: Apache/1.2.7-dev

Date:

Tue.

Jul 1998 18:21:41

GMT

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: text/html

691

<...1681 байтов первого фрагмента данных...>

<...118 байтов второго фрагмента данных...>

Заголовок Transfer-Encoding (имеющий значение chunked) указывает получа-

телю,

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

роваться иначе, чем ответы, не разбитые на фрагменты. Ответ, приведенный в при-

мере, разбит на три фрагмента: первому фрагменту длиной 1681 байт (691 в шест-

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

первым фрагментом идет второй фрагмент длиной 118 байтов (шестнадцатерич-

ное 76), которому также предшествует указатель длины фрагмента. Наконец, сле-

дует фрагмент нулевой длины

—

указатель размера фрагмента

без следующего за

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

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

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

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

тогда, когда они были сгенерированы. Это сокращает задержку за счет того, что не

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

какой-либо его фрагмент.

Разбиение сообщения на фрагменты не оказывает влияния на то, как транспорт-

ный уровень может воспринимать HTTP-сообщение. Один фрагмент может разби-

ваться на несколько пакетов, или в одном пакете может поместиться несколько

фрагментов. Разбиение на фрагменты

—

это механизм, который полностью реали-

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

просы, так и сообщения-ответы.

Сообщение-ответ, разбитый на фрагменты, завершается фрагментом нулевой

длины. Однако за сообщением может следовать необязательный завершающий

фрагмент, трейлер (trailer). Трейлер является отдельной от тела ответа частью со-

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

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

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

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

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

мой).

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

сумму для проверки его целостности (например, с использованием алгоритма MD5

[Riv92]), но до того как будут обработаны все байты ответа, невозможно вычислить

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

фрагменты тела ответа можно отправлять по мере их генерации, без увеличения за-

держки. Подобным же образом, трейлер может включать заголовок Authen-

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

tication-Info, как это описано в RFC, посвященном аутентификации с помощью

дайджестов [FHBH^99J.

Чтобы предупредить получателя о наличии дополнительной информации, заго-

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

Б трейлере сообще1Н1я. Трейлеры могут включать обязательную и необязательную

информацию. Готовность принять трейлеры на стороне клие1гга явным образом

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

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

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

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

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

В соответствии с духом симметричного управления НТТР/1.1 требует, чтобы трей-

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

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

в буфер. Это достигается включением заголовка запроса TEitrailers.

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

принимать поля трейлера в ответе, разбитом на фрагменты:

GET /foo.html НТТР/1.1

Host: www.checktrailers.com

ТЕ:

trailers

Сервер возвращает разбитый на фрагменты ответ с заголовком Trailer, указываю-

щим, какие заголовки получатель должен найти в завершающем фрагменте ответа:

НТТР/1.1

200

ОК

Trailer:

Splinfo

Transfer-encoding:

chunked

CRLF

691

<1681

байтов первого фрагмента данных>

<118

байтов второго фрагмента данных

Splinfo: vol=7; pe="u4, 895527629, 5465";

CRLF

Разбитьн"! па фрагменты ответ состоит из обычного набора фрагментов с указа-

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

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

в заголовке Trailer) и набор значений для этого заголовка. Последняя строка пред-

ставляет собой символы возврата каретки и перевода строки (CRLF), которые

должны завершать разбитое на фрагменты сообщение.

В то время как НТТР/1.0 требует наличия корректного поля Content-Length во

всех запросах POST, НТТР/1.1 этого не требует. В НТТР/1.0 не было другого спо-

соба отделить тело содержимого, в НТТР/1.1 это можно сделать с помощью меха-

низма разбиения на фрагменты. Заметим, что разделенные на фрагменты сообще-

ния не обязаны иметь заголовок Content-Length, так как длина такого сообщения

вычисляется на основе информации о длине фрагментов. Предположим, что сер-

вер,

поддерживающий НТТР/1.1, посылает разбитое па фрагменты сообщение про-

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

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

tent-Length, прокси-сервер, использующий НТТР/1.1, проигнорирует этот заголо-

Глава 7. HTTP/1.1 269

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

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

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

Content-Length.

7.7. Расширяемость

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

ность внесения изменений. Любому протоколу неизбежно приходится развиваться.

Хотя некоторые изменения можно предусмотреть на этапе создагпш спецификации

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

тельная проблема: имелось несколько популярных реализаций различных Web-ком-

понентов, разработанных на базе промежуточных «стандартов». Версия НТТР/1.1

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

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

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

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

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

Учитывая прошлые уроки, разработчики НТТР/1.1 решили зарезервировать не-

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

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

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

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

столкнулись разработчики протокола НТТР/1.1, они попытались ограничить буду-

щие трудности в следующих версиях этого протокола.

В НТТР/1.1 были предприняты попытки обеспечения расширяемости с помо-

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

Путем включения методов для получения информации о возможностях сер-

вера до осуществления запросов и для получения информации о том, что дей-

ствительно получено сервером.

Путем добавления новых заголовков для получения информации о промежу-

точных серверах, включенных в цепочку Web-транзакции.

Путем введения поддержки для перехода на другие протоколы.

7.7.1.

Получение информации о сервере

Два новых метода получения информации о сервере были введены в НТТР/1.1.

Это методы OPTIONS и TRACE. Мы рассмотрим их здесь подробно.

МЕТОД OPTIONS

В НТТР/1.0 у клиента не было средств узнать о возможностях Web-сервера.

Метод OPTIONS был введен в НТТР/1.1, чтобы удовлетворить эту потребность.

Рассмотрим следующие ситуации:

• Возможно, что клиенту нужно узнать, реализован ли в Web-сервере метод, не

являющийся обязательным для реализации (любой метод, не относящийся

к уровню требований MUST). Предположим, что клиентом был послан запрос

PUT большого объема, который был отклонен сервером из-за невозможности