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

В главах 13 и 14 рассматривались перспективы исследований, связанных с кэшированием и измерениями. В этой главе мы поговорим об исследованиях некоторых проблем, связанных с Web-протоколами, главным образом с TCP и HTTP. На практике HTTP выполняется поверх TCP, используемого в качестве транспортного протокола. Мы рассмотрим песколько предложений, относящихся к TCP, которые могут оказать существенное влияние на Web. Мы также рассмотрим несколько идей, связанных с изменениями и расширениями HTTP. Поскольку Web-трафик занимает доминирующее положение в Internet, было предпринято несколько попыток усовершенствовать HTTP. В главе 7 мы рассмотрели различные попытки исправить присущие НТТР/1.0 недостатки, которые в итоге привели к появлению НТТР/1.1. Хотя протокол в процессе создания прошел через несколько этапов (проект стапдарга, предложение по стандарту), ряд проблем остался нерешенным. Вот песколько причин, но которым в процессе стандартизации не был решен ряд проблем:

•          Проблемы не были признаны достаточно серьезными, чтобы задерживать из-за них стандартизацию протокола.

•          Срочпая необходимость выпустить улучшенную версию протокола, чтобы устранить имеющиеся в НТТР/1.0 проблемы.

•          Появление многочисленных версий Web-комнонентов, якобы поддерживающих НТТР/1.1 до завершения процесса стандартизации. Такие компоненты объявлялись согласующимися с документом RFC 2068 [FGM+97], который далек от стандарта.

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

В этой главе будут обсуждаться следующие темы:

•      Мультиплексирование HTTP-передач. Взаимодействие между HTTP и TCP оказывает существенное влияние на производительность Web в частности и на эффективность Internet в целом. Web-клиент Обычно устанавливает несколько ТСР-соедипепий с одинм и тем же сервером для параллельной загрузки встроенных изображений и уменьшения времени ожидания на стороне пользователя. Однако параллельные ТСР-соединения порождают ряд проблем, связанных с тем, что активно работающий клиент получает большую часть пропускной способности сети, чем другие клиенты. Кроме этого, мпогие мультимедийные приложения используют UDP и не реагируют на заторы в сети так, как эго делают ТСР-соединения. Для решения этих проблем необходимо вновь обратиться к взаимодействию протоколов прикладного уровня, включая HTTP, с транспортным уровнем. Мы познакомимся с тремя предложениями, которые предполагают изменения способа мультиплексирования HTTP-передач: WebMux, TCP Control Block Interdependence и Integrated Congestion Management.

•      Добавление механизма отличий (дельта-механизма) в НТТР/1.1. Предположим, в кэше содержится экземпляр ресурса, а изменившийся экземпляр на исходном сервере несколько отличается от кэшированиой версии. Вместо того, чтобы передавать новую версию ресурса целиком, исходный сервер может отправить имеющиеся но сравнению с предыдущей версией отличия в предположении, что они небольшие. Передача только отличий умеиьшает время ожидания на стороне пользователя и объем данных, передаваемых по сети. Мы обсудим нобудительные причины для введения механизма отличий (или «дельты»), поговорим об имеющихся алгоритмах, об оценке алгоритмов на основе измерений в Web, а также рассмотрим соображения, связанные с внедрением механизма в НТТР/1.1.

•      Совместимость с протоколом HTTP. Совместимость с протоколом подразумевает, что реализации компонентов отвечают требованиям MUST (Обязательно), SHOULD (Желательно) и MAY (Возможно), изложенным в спецификации. Хотя стандартизация протокола требует тестирования на совместимость компонента каждой из функций, общего механизма нроверки на совместимость не существует. В распоряжении разработчиков отдельных компонентов имеются перечни тестов, помогающих проверить совместимость различных функций. Отсутствие надежного, исчерпывающего и, что самое важное, обязательного механизма тестирования на совместимость является слабым местом процесса стандартизации. Несовместимые реализации могут привести к возникновению проблем для пользователей, владельцев Web-сайтов и сети. HTTP в этом смысле не является исключением — большинство разработанных IETF протоколов формалыю не тестировались на совместимость. Мы обсудим методологию проверки совместимости HTTP (под названием PRO-COW) и рассмотрим результаты обширного исследования, в ходе которого тестировались серверы большой Группы популярных Web-сайтов.

•      Комплексное измерение параметров для изучения воздействия усовершенствований протоколов на производительность Web. Несколько измепепий в протоколе HTTP были обсуждены Рабочей грунной и впедрены без каких-либо измерений показателей производительности. На практике детальное измерение показателей производительности нри внедрении невозможно без доработки компонентов. Комплексное (от одной конечной точке к другой) измерение производительности Web потребует измерения параметров ответов у

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

• Другие расширения HTTP. Ряд предложенных расширений HTTP не пашел широкого признания. Однако некоторые из них показали себя более перспективными, чем другие. Мы рассмотрим в этой главе три таких расширения, па- чипая с интегрированной инфраструктуры расширения HTTP, предложенной в RFC 2774. Затем мы рассмотрим концепцию прозрачной доставки содержания (Transparent Content Negotiation), исключенную из НТТР/1.1 в ходе дискуссии, результатом которой стало появление документа RFC 2616, представляющего собой проект стандарта для НТТР/1.1. Наконец, мы рассмотрим протокол Distributed Authoring and Versioning (WebDAV), нризванный дагь возможность нескольким авторам совместно редактировать ресурсы.

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