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

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

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

Для обнаружения некорректных файлов и вычисления статистических показа-

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

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

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

MPEG, QuickTime и AVI, имеется общедоступное программное обеспечение. В не-

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

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

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

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

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

ких как требования к средней пропускной способности (битов в секунду) или от-

ношение ширины к высоте. Файлы с нетипичными параметрами могут быть ис-

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

личных статистических параметров и их представления в разных форматах

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

файл данные и аудио, и видео.

Хотя исследование дает широкое представление об имеющемся в Web наборе

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

исковая машина обладает неполным представлением об имеющихся в Web-pecyp-

сах. Некоторые Web-страницы со ссылками на видеоресурсы могли быть не под-

вергнуты индексированию. Кроме этого, некоторые URL для видеофайлов могут

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

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

деофайлов. Для определения популярности ресурсов требуется наличие трассы

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

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

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

методов выборки видеофайлов. Для потокового видео вместо HTTP все большее

применение находят протоколы Real-time Transport Protocol (RTP) и Real Time

Streaming Protocol (RTSP). Гиперссылки на Web-страницах часто являются указа-

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

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

14.4.2.

Журналы мультимедийных серверов

Для aHajHi3a поведения хюльзователей при запросах мультимедийных потоков

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

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

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

как к мультимедийному содержимому, так и к традиционному Web-содержанию.

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

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

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

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

ка, ускоренная перемотка. Функции видеомагнитофона оказывают существенгюе

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

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

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

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

ждается меняющимися требованиями к пропускной способности и офаничивает эф-

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

Глава

14.

Перспективы

исследований,

связанных

измерениями

501

В то время как Web-сервер записывает информацию о каждом HTTP-запросе,

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

кого как обращение к функциям видеомагнитофона. Для форматов журналов

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

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

дийных серверов не являются широко доступными. Существующие исследования

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

академическими учреждениями. Многие университеты, имеющие Web-сайты, пре-

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

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

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

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

ного типа. Большое разнообразие мультимедийных приложений затрудняет полу-

чение обобщенных результатов о характеристиках ресурсов и шаблонах доступа.

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

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

ниям и сообществам пользователей.

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

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

[РК99,

ASPOO]. Различаясь форматами, оба журнала содержат информацию одного

и того же вида, а именно, традиционные HTTP-запросы на HTML-файлы и изобра-

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

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

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

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

сов,

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

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

ния пользователей [ASPOO]. Кроме того, записи журнала, такие как повторяющиеся

команды «стоп» от одного и того же клиента, были сжаты до одгюй записи.

Традиционные параметры рабочей нагрузки имеют характеристики, сходные

с соответствующими характеристиками НТТР-трафика. Оба исследования выяви-

ли,

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

ватели прекращают просмотр потока после просмотра его начальной части; это на-

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

вере

—

достаточно эффективный способ снизить нагрузку на сервер и повысить

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

ются к функциям видеомагнитофона, таким как переход, обратная перемотка и ус-

коренная перемотка. При некоторых операциях обратной перемотки перемещение

осуществляется на небольшое число кадров. Это наводит на мысль сохранять не-

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

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

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

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

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

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

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

14.4.3,

Мониторинг пакетов мультимедийных потоков

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

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

502

Часть

VI.

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

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

Internet. В традиционных Web-передачах сервер записывает сообщение-ответ в бу-

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

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

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

тате чего трафик может сильно меняться. Получение характеристик мультимедий-

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

ных параметров потока. В недавно проведенном исследовании был представлен

подробный анализ транспортировки аудиопотоков с сервера RealAudio онлайновой

радиостанции [MHOOj. В ходе исследования были собраны данные трасс пакетов,

проанализированы параметры трафика на уровне пакетов и потоков, разработана

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

Для сбора трасс пакетов требуется перехват пакетов и генерирование записей

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

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

него,

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

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

пользованием UDP, TCP или HTTP поверх TCP. Перехват пакетов требует па-

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

ет IP-адрес, протоколы и номера портов, как описывалось ранее в разделе 14.1.2.

Хотя сервер всегда выбирает порт 80 для передач HTTP поверх TCP, при передаче

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

ный порт (т.е. порты с номерами от 1024 до 65535). На практике сервер использует

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

проводящим исследование. Монитор пакетов был настроен для перехвата пакетов

с этими номерами портов. Монитор записывает первые 90 байт каждого аудиопаке-

та, что гарагггирует включение в трассу заголовков IP и TCP/UDP, а также заго-

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

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

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

Программа анализа группирует пакеты, принадлежащие одному TCP- или

UDP-ceancy; т.е. пакеты с одними и теми же IP-адресами источника, получателя и

номерами портов считаются частью одного аудиопотока. Транспортный механизм

потока (UDP, TCP или HTTP поверх TCP) может быть определен на основе про-

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

UDP или TCP, а номер порта TCP сервера позволяет отличить НТТР-трафик

(порт 80) от остального ТСР-трафика. По большей части трафик состоит из

UDP-пакетов. Это важно, поскольку приложения, использующие UDP, необяза-

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

сто этого аудиосервер передает данные па периодической основе. Чтобы разрабо-

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

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

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

этих параметров оцениваются с учетом распределений вероятностей.

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

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

проведению экспериментов, оценивающих воздействие трафика аудиодштых па сер-

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

ния. Онлайновая радиостанция может иметь иные свойства по сравнению с сайтом,

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

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

Глава

14.

Перспективы

исследований,

связанных

измерениями

503

более 45 минут. По большей части потоки имеют несколько различных скоростей пе-

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

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

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

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

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

28,8 Кбит/с. Сервер также использует особые размеры пакетов для UDP-нередач. Из-

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

появление новых реализаций серверов могут привести к изменегшям характеристик

рабочей нагрузки.

14.4.4.

Многоуровневый мониторинг пакетов

в отличие от традиционных НТТР-передач, большинство потоковых приложе-

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

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

одного или нескольких RTP-потоков; каждый RTP-поток может иметь соответст-

вующий RTCP-noTOK (RTP Control Protocol) для обмена сигналами обратной свя-

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

медийного трафика может зависеть от наличия информации о каждом из этих про-

токолов. Запрашиваемые URL, запросы на управление видеопотоком на стороне

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

ются в RTP-пакетах. Измерение трафика команд и трафика данных несет в себе

две проблемы. Во-первых, содержимое управляющих сообщений должно восста-

навливаться из базового потока пакетов, подобно восстановлению HTTP-сообще-

ний (см. раздел 14.1). Во-вторых, монитор должен идентифицировать трафик дан-

пых, ассоциированный с управляющими сообщениями. На практике это сопряжено

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

мера портов UDP и TCP, которые могут не быть известны заранее. Вместо этого,

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

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

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

редачи данных и RTCP для обратной связи. После получе1Н1я описания сеанса

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

единений. Сообщение-ответ сервера содержит заголовок Transport, который иден-

тифицирует протокол (UDP или TCP) и номера портов на клиенте и на сервере,

как описывалось ранее в главе 12 (раздел 12.4.3). Клиент, запросивший сеанс с от-

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

групп соединений, по одной для каждого потока. Каждое соединение уникально

идентифицируется по группе из пяти чисел: IP-адресам клиента и сервера, номе-

рам портов клиента и сервера и протоколу.

Идентификация этих соединений довольно затруднительна. IP-адреса клиента

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

как номера портов и протокол зависят от ответа сервера на сообщение SETUP.

Простой подход к решению этой проблемы состоит в том, что монитор захватывает

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

портов (т.е. от 1024 до 65535). Далее отдельная программа может идентифициро-

вать,

какие передачи данных ассоциированы с каждым из командных сеансов. Од-

нако это может потребовать от монитора захватывать и хранить чрезвычайно боль-

шой объем данных, особенпо для высокоскоростных каналов. Например, монитор

может захватывать пакеты из передач больших файлов по FTP и сеансов 1Р-геле-

фонии, не связанных с какими-либо командными сеансами RTSP.

504 ;^

Часть

VI.

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

Вместо этого монитор может просматривать управляющие сообщения при их

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

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

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

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

Эти задачи выполняет инструментальное средство mmdump [vCCSOO]. Оно пере-

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

ния, идентифицируемого по известному номеру порта (например, 554 для RTSP),

и восстанавливает управляющие сообщения. Средство содержит программу для

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

таких как RTSP и Н.323. После извлечения информации о протоколе, номерах

портов и потоках данных,

mmdump

обновляет фильтр пакета для перехвата пакетов

данных. Инструментальное средство может перехватывать полное содержимое

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

чала каждого пакета данных.

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

1ЮГ0 вида анализа. Например, рассмотрим мультимедийную презентацию, в состав

которой входят изображения, аудио, видео и текст. Управляющие сообщения содер-

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

или скорости передачи для каждого потока. Знание URL также дает возможность

осуществлять анализ популярности различных мультимедийных ресурсов в Internet.

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

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

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

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

потока данных. Подобные эффекты, связанные с обратной связью, очень трудно учи-

тывать без совместного перехвата трафика команд и трафика данных.

14.5.

Резюме

Программное обеспечение анализа Web-трафика играет важную роль в оценке

эффективности Web. Мониторинг пакетов обеспечивает детальную информацию о

Web-передачах на уровнях HTTP и TCP. Однако для сбора трасс пакетов

Web-трафика требуется эффективное программное обеспечение для восстановле-

ния HTTP-сообщений из потока IP-пакетов. Многие исследования Web-трафика

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

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

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

ний Web-трафика предоставляют исследователям доступ к журналам и трассам.

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

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

за. В сравнении с исследованиями Web-трафика, технология измерений и анализа

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

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

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

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

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

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

нием функций видеомагнитофона.

Перспективы

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

В главах 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 яъл^^^с5\ достижение

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

токола в целом. Решение ряда проблем было передано рабочим группам с целью

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

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

числа посещений и прозрачная доставка содержания, не прошли процесс стандар-

тизации и были либо сняты с рассмотрения, либо выделены в отдельные стан-

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

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

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

другие пока обсуждаются неофициально. Новые идеи по совершенствованию про-

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

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

шения.

506 Часть VI. Перспективы исследований

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

• Мультиплексирование 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 потребует измерения параметров ответов у

Глава

15.

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

507

клиентов, находящихся в различных точках и связывающихся с различными

Web-серверами. Будет представлена методика оценки производительности и

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

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

жений клиентов. Принимая во внимание асимметричный характер трафика

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

ную часть всех запросов), можно изучить воздействие внесения изменений

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

этих сайтов.

• Другие расширения HTTP. Ряд предложенных расширений HTTP не нашел

широкого признания. Однако некоторые из них показали себя более перспек-

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

чиная с интегрированной инфраструктуры расширения HTTP, предложенной

в RFC 2774. Затем мы рассмотрим концепцию прозрачной доставки содержа-

ния (Transparent Content Negotiation), исключенную из НТТР/1.1 в ходе дис-

куссии, результатом которой стало появление документа RFC 2616, представ-

ляющего собой проект стандарта для НТТР/1.1. Наконец, мы рассмотрим

протокол Distributed Authoring and Versioning (WebDAV), призванный дать

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

15.1.

Мультиплексирование HTTP-передач

При загрузке Web-страниц Web-клиент обычно открывает несколько ТСР-со-

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

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

сов,

о чем говорилось ранее в главе 8 (раздел 8.3). В этом разделе мы рассмотрим

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

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

способ мультиплексирования нескольких НТТР-сеансов в одно ТСР-соединение.

Предложение TCP Control Block Interdependence предусматривает более тесное

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

ром. Предложение Integrated Congestion Management основное внимание уделяет

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

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

к изменениям пропускной способности.

15.1.1.

WebMux

—

экспериментальный протокол

мультиплексирования

При загрузке Web-CTpaiinubi браузер может устанавливать несколько параллель-

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

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

чения, присущие взаимодействию HTTP с транспортным уровнем. В HTTP сообще-

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

ТСР-соединегп1ем. Наличие нескольких одновреме1Н1ых передач требует от браузера

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

ТСР-соединений с сервером. Один из способов решения этой проблемы

—

расши-

рить HTTP, чтобы разрешить чередование нескольких сообщений в одном и том же

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

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

в протокол, а также изменений реализаций Web-клиентов, прокси-серверов и

Web-серверов. Процесс стандартизации и большая база имеющихся программных

компонентов Web делает это решение неприемлемым.

В качестве альтернативного подхода WebMux предлагает отказаться от одно-

значной связи между сокетами и ТСР-соединепиями. WebMux

—

эксперименталь-

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

в HTTP и программные компоненты Web [GN98]. Вместо этого WebMux предос-

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

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

ные,

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

лит данные из каждого сокета на фрагменты и передает фрагменты через

ТСР-соединение. Каждый фрагмент имеет заголовок WebMux с идентификатором

сеанса, который дает возможность принимающей стороне ТСР-соединения направ-

лять данные соответствующему получателю. Заголовок WebMux также содержит

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

ТСР-соединение трактует фрагменты WebMux как обычные да1Н1ые, подлежащие

доставке из одной конечной точки в другую.

Мультиплексирование нескольких сеансов в одно ТСР-соединение сопровожда-

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

и памяти. Отправка большого количества фрагментов в интересах одного сеанса

может привести к дискриминации других сеансов. Чтобы предотвратить эту дис-

криминацию, отправитель WebMux чередует передачу данных сеансов по кругу.

Хотя порядок пересылки определяет отправитель, базовое ТСР-соединение управ-

ляет передачей данных с помощью скользящего окна. На принимающей стороне

ТСР-получатель реконструирует входящие пакеты в упорядоченный поток дан-

ных. Получатель WebMux .связывает его с соответствующим сокетом на основе

идентификатора сеанса. Однако получатель WebMux должен сохранять фрагмент

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

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

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

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

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

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

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

ном уровне ТСР-получатель также имеет ограниченный объем буфера, что являет-

ся препятствием при передаче данных ТСР-отправителем. Один сеанс может

занять весь входной буфер TCP, что помешает ТСР-отправителю передавать дан-

ные в интересах других сеансов. Чтобы решить эту проблему, в WebMux вводятся

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

телю WebMux передавать определенный объем данных в интересах сеанса. За счет

ограничения количества ожидающих обработки кредитов получателем WebMux

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

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

окна приема в TCP. Однако кредиты ассоциируются с сеансами, тогда как окно

приема ассоциируется с ТСР-соединением.

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

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

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

нений в TCP, HTTP и программные компонегггы Web. Кроме того, поддержка

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

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

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

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

ноценной реализации WebMux требуется уделить особое внимание совместному

использованию сеансами пропускной способности сети и пространства буфера.

В случае принятия официального стандарта WebMux должен будет допускать

встраивание в основные операционные системы и развертывание на компьютерах

по всему Internet. Протокол WebMux был принят в качестве рабочего проекта

в конце 1998 г. [GN98] в результате усилий организации HTTP Next Generation

(HTTPng) [SJOOj. Однако дальнейшие работы были остановлены, и протокол

WebMux не прошел дальнейших этапов стандартизации IETF.

15.1.2.

TCP Control Block Interdependence

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

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

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

каждое ТСР-соединение функционирует независимо даже в том случае, если не-

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

нение само определяет время передачи в прямом и обратном направлении (RTT) и

максимальный размер сегмента (MSS) для передаваемых данных. Кроме того, каж-

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

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

в результате функционирования других соединений. Каждое соединение начинает-

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

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

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

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

ТСР-соединением.

Предложение TCP Control Block Interdependence [Tou97] подразумевает пере-

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

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

Каждое ТСР-соединение на локальном компьютере ассоциируется с управляющим

блоком, который хранит информацию о состоянии соединения. Управляющий блок

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

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

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

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

ваны различными ТСР-соединепиями. Однако другая информация о состоянии

соединения, вк7Почая оценки значений RTT, MSS и размер скользящего окна, отно-

сится к паре взаимодействующих между собой хостов. Эти параметры могут совме-

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

формации соединениями координируется операционной системой, что не требует

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

ложения (например, Web-браузер или Web-сервер). Предложение учитывает два

возможных сценария взаимодействия между ТСР-соединепиями с одним удален-

ным компьютером: согласованное (ensemble) и временное (temporal) совместное ис-

пользование.

Согласованное использование (ансамбль) имеет место, когда два или более ак-

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

стоянии. Простейший пример — инициализация управляющего блока нового со-