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

Основная задача при обмене НТТР-сообщениями состоит в том, чтобы стороны могли распознать полное и без каких-либо потерь получение сообщений. Надежная доставка сообщения rio сети — главное для поддержания целостности транзакций. Размер ответа — это полезный признак, позволяющий получателю определить, что получеи весь ответ. Едипствепиым средством, с помощью которого исходные серверы, использующие НТТР/1.0, могли сообщить размер тела содержимого, было иоле заголовка Content-Length. Длина статического ресурса могла быть легко определена с помощью системного вызова операционной системы. При динамически генерируемых ответах, исходному серверу приходится ждать завершения процесса генерации, прежде чем вычислить длину ответа. До того как ответ полностью сформирован, поле заголовка Content-Length не может быть заполнено. Следовательно, исходный сервер не может начать передачу ответа до того, как будет заполнено поле заголовка. Это требует буферизации ответа, увеличивая таким образом задержку для конечного пользователя.

В НТТР/1.0 сервер указывает на копец динамически генерируемого ресурса путем закрытия соединения. Если закрытие соединения — единственный способ указать на завершение ответа, то долговременные соединения становятся невозможными. Таким образом, был пужен альтернативный способ задапия признака окончания сообщения без закрытия соединения.

НТТР/1.1 решает проблему падежной передачи сообщений с помощью разбиения тела сообщения на фрагменты (chunks), что позволяет отправителю передавать их независимо. Каждой части предшествует ее размер, позволяющий получателю убедиться, что он получил данный фрагмент нолностыо. Еще важнее то, что отправитель генерирует фрагмент нулевой длины при завершении передачи сообщения, получение его указывает, что все сообщение было благополучно передано. Разбиение сообщения на фрагменты избавляет от необходимости поддержки буферов произвольного размера, которые могут потребоваться, если прокси-сервер будет сохранять ответ до его передачи устаревшей версии клиента, использующей НТТР/1.0. Этот механизм также устраняет задержку, связапиую с ожидапием завершения генерации всего ответа неред добавлением заголовка Content-Length (как это обсуждалось выше).

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

НТТР/1.1 200 0K

Server: Apache/1.2.7-dev

Date: Tue, 07 Jul 1998 18:21:41 GMT

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: text/html

691

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

76

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

0

Заголовок Transfer-Encoding (имеющий значение chunked) указывает получателю, что ответ разбит на фрагменты, и, следовательно, этот ответ должен анализироваться иначе, чем ответы, не разбитые на фрагменты. Ответ, нриведенпый в примере, разбит на три фрагмента: первому фрагменту длиной 1681 байт (691 в шест- надцатеричной системе счисления), предшествует указатель длины части, за первым фрагментом идет второй фрагмент длиной 118 байтов (шестпадцатерич- ное 76), которому также предшествует указатель длины фрагмента. Наконец, следует фрагмент нулевой длины — указатель размера фрагмента 0 без следующего за ним тела, что является для получателя признаком завершения ответа. Получатель проверяет длину отдельных фрагментов, а после получения фрагмента нулевой длины он знает, что ответ им был принят полностью. В случае динамически генерируемых ответов сервер может отправлять генерируемые фрагменты в том виде и тогда, когда они были сгенерированы. Это сокращает задержку за счет того, что не нужно ждать завершения процесса генерации всего ответа, нрежде чем посылать какой-либо его фрагмент.

Разбиение сообщения на фрагменты не оказывает влияния на то, как транспорт- пый уровень может воспринимать HTTP-сообщение. Один фрагмент может разбиваться на несколько пакетов, или в одном пакете может поместиться несколько фрагментов. Разбиение на фрагменты — это механизм, который полностью реализуется на прикладном уровне. Разбивать на фрагменты можно как сообщения-за- просы, так и сообщения-ответы.

Сообщение-ответ, разбитый на фрагменты, завершается фрагментом нулевой длииы. Однако за сообщением может следовать необязательный завершающий фрагмент, трейлер (trailer). Трейлер является отдельной от тела ответа частью сообщения, и сервер-получатель или Агент пользователя определят, что уже получено все тело до обработки следующего за ним трейлера. Трейлер в ответе, разбитом на фрагменты, может состоять только из полей и значений заголовка содержимого. Предположим, что ответ генерируется динамически и отправителю нужно вычислить дайджест всего ответа (можно считать дайджест обычной контрольной суммой). Например, отправителю может потребоваться включить в ответ контрольную сумму для проверки его целостности (например, с использованием алгоритма MD5 [Riv92]), но до того как будут обработаны все байты ответа, невозможно вычислить контрольную сумму. Однако если включить заголовок MD5 в трейлер ответа, то фрагменты тела ответа Можно отправлять по мере их генерации, без увеличения задержки. Подобным же образом, трейлер может включать заголовок Authentication-Info, как это описано в RFC, посвящеипом аутентификации с помощью дайджестов [FHBH+99J.

Чтобы предупредить получателя о паличии дополнительной информации, заголовок Trailer используется для перечисления других заголовков, которые иоявягся в трейлере сообщения. Трейлеры могут включать обязательную и необязательную информацию. Готовность иринять трейлеры на стороне клиента явным образом указывает на то, что клиент будет, если эго потребуется, помещать информацию, предшествующую трейлеру, в буфер. Например, исходный сервер может включить в ответ некоторую аутеитификационную информацию, которая определяет, должен ли принимающий прокси-сервер передавать ответ дальше или нет. Однако это означает, что принимающему прокси-серверу придется поместить весь ответ в буфер. В соответствии с духом симметричного управления НТТР/1.1 требует, чтобы трейлеры посылались в ответе, разбитом на фрагменты, только в том случае, если прокси-сервер ранее подтвердил свою готовность помещать, если нужпо, весь ответ в буфер. Это достигается включением заголовка запроса TE:trailers.

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

GET /foo.html НТТР/1.1 Host: www.checktrailers.com ТЕ: trailers

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

НТТР/1.1 200 0K Trailer: Splinfo Transfer-encoding: chunked CRLF 691

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

76

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

0

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, проигнорирует этот заголовок. Так как клиенту пичего неизвестно о механизме разбиепня на фрагменты, прокси-сервер, использующий НТТР/1.1, из получепных фрагментов создаст Обычное сообщение и передаст его клиенту, используя НТТР/1.0, вместе с заголовком Content-Length.

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