Совместимость и взаимодействие протоколов

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

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

Сначала мы рассмотрим, как интерпретируются номера версии в заголовках сообщений, а затем остановимся на различных уровнях требований к совместимости. Заметим, что требования к совместимости присутствуют только в документах RFC, считающихся стандартами. Например, RFC 1945, описывающий НТТР/1.0, является информационным документом, и в связи с этим не содержит требований к совместимости. RFC 2616, описывающий НТТР/1.1, является проектом стандарта. О принципах совместимости для протокола НТТР/1.1 мы поговорим в главе 15 (раздел 15.3).

Номер версии и совместимость

Когда НТТР-компопенты взаимодействуют друг с другом, помер версии в сообщении указывает на возможности отправителя и получателя. HTTP-сервер должен быть способен интерпретировать все сообщения, имеющие помер версии, меньший или равпый его собственному. Требования к интерпретации сообщения затрагивают как синтаксис (формат сообщений), так и семаигику (возможности и особенности этой версии протокола). Ответ сервера должен быть представлеп в версии протокола, которая понятна для клиента. HTTP-клиент должен правильно указать собственный помер версии и интерпретировать сообщения с сервера в формате версии, равпой или меньшей, чем его собственная.

Номер версии HTTP состоит из старшей и младшей части. Например, в НТТР/1.0 старшей частью является 1, а младшей частью — 0. Правила для старшей и младшей частей относительно просты. Предположим, что возможности отправителя расширены путем добавления в HTTP-сообщение семаптики, по алгоритм синтаксического анализа сообщений остался неизменным. Младший помер может быть измепеп (изменение номера версии предполагает добавление единицы к текущему значению) без изменения старшего номера. Однако если требуется изменение формата сообщения, то должен быть также измепеп старший иомер. Измепепие старшего номера существенно влияет на совместимость.

Детали интерпретации номера версии поясняются в документе RFC 2145 [MFGF97J. Требования к надежности коммуникационного взаимодействия требуют, чтобы компоненты четко представляли, как интерпретировать помер версии в сообщении. Как мы увидим в следующей главе, серверы-посредники вызывают значительные проблемы в интерпретации номера версии.

Уровни требований MUST (обязательный), SHOULD (желательный) и MAY (возможный)

Чтобы гараптировать, что реализации протокола следуют правилам, задаются различные уровни требований. Это свойственно многим протоколам, и язык для задания уровней требований был формализован в документе RFC 2119 [Bra96a]. RFC 2119 определяет уровепь требований, используемых в спецификациях протоколов Internet. Имеется три уровня требований: MUST (обязательный), SHOULD (желательный) и MAY (возможный). Имеются также отрицательные требовапня MUST NOT (пе должен) и SHOULD NOT (иежелателыю).

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

Обязательный уровепь требований (MUST) означает, что совместимость абсолютно необходима. Реализация протокола, не обладающая этой характеристикой, не соответствует спецификации протокола. Если хотя бы одно из требований уровня MUST не соблюдается, реализация не является совместимой. Требование уровня SHOULD трактуется как рекомендация, и реализация может быть условно совместимой со спецификацией, если опа не содержит данную функцию. Однако рекомендация подразумевает, что функция по возможности должна быть реализована. Реализация, удовлетворяющая всем требованиям уровней MUST и SHOULD, считается безусловно совместимой.

Требования уровня MAY являются дополнительными, и хотя подобные функции могут быть представлены в некоторых реализациях, их наличие не является обязательным. Реализация, отвечающая требованиям уровней MUST и SHOULD, будет считаться совместимой, даже если в ней не выполнены требования уровня MAY.

Различные уровни требований к совместимости оказывают сильное влияние на набор функций, которые могут присутствовать в различных реализациях Web-cepвера, посредника или клиента.Хотя некоторые функции являются необязательными, разработчики Web-компонентов должны уделить особое внимание требованиям уровней MUST и SHOULD. Отсутствие совместимости со стороны одного компонента является основной проблемой для сложных систем, таких как Web, поскольку это может привести к пекорректпой интерпретации результата другими компонентами. Например, предположим, что сервер игнорирует требование уровня MUST и генерирует некорректный ответ. Расположенный на пути сообщения прокси-сервер может предположить, что оп получил корректный ответ и кэшировать его. Некорректный ответ будет переправлен как верпый ответ многим клиентам, которые запросят этот же ресурс в дальнейшем.

Имеется пееколько общих правил совместимости для клиентов и серверов HTTP, посылающих иомера версий. Например, HTTP-сервер не должен (MUST NOT) отправлять помер версии, для которой не имеет места по меньшей мере условная совместимость. Если серверу известно о наличии программных ошибок на клиенте, оп может (MAY) отправить меньший помер версии. Точно так же, если клпепт предполагает, что взаимодействующий с ним сервер содержит ошибки, оп может (MAY) отправить меньший помер версии.

Резюме

Хотя текущей версией HTTP является версия НТТР/1.1 (она будет рассмотрена в следующей главе), полезно начать изучение эволюции протокола HTTP с первых дней возникновения World Wide Web. Что еще более важно, имеется ряд клиентов, серверов-посредников и Web-серверов, которые все еще используют НТТР/1.0. Значительная часть трафика в Web приходится на НТТР/1.0. По-прежнему еще создаются встроенные клиенты НТТР/1.0. Некоторые решения при разработке НТТР/1.0 определялись популяриостыо других систем, которые широко использовались в копне 80-х и в пачале 90-х годов прошлого века. Введение гипертекстовых ссылок способствовало взрывному росту Web и массовому применению протокола HTTP. Систематизация имеющихся методов, заголовков и кодов ответов помогает Web-компо- пептам без проблем взаимодействовать друг с другом.

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

Применение НТТР/1.0 на практике привело к ряду усовершенствований, от долговременных соединений до безопасности. Эти усовершенствования стали побудительной причиной появления НТТР/1.1. Хотя некоторые популярные Web-браузеры п многие Web-серверы, поддерживающие функционирование популярных Web- сайтов, перешли на НТТР/1.1, версия НТТР/1.0 по-прежнему широко используется.

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