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

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

480

Часть

VI.

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

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

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

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

Большинство исследований, посвященных упреждающей выборке, основное

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

этих исследований довольно разнородны. Снижение времени ожидания на стороне

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

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

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

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

информацш! DNS, метаданных HTTP и установление ТСР-соединений не слиш-

ком увеличивает сетевой трафик. Однако упреждающая выборка информации DNS

загружает DNS-серверы, а упреждающее создание ТСР-соединений и упреждаю-

щая выборка метаданных HTTP загружает Web-серверы. В некоторых случаях уп-

реждающая выборка метаданных HTTP через существующее ТСР-соедипение мо-

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

танавливать отдельные ТСР-соединения в будущем.

Внедрение технологии упреждающей выборки в Web зависит от того, перевесит

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

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

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

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

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

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

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

ры и магистральные сети.

13.4.

Резюме

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

шированием в Web. В первом разделе речь шла о проверке актуальности элементов

кэша как важном факторе, обеспечивающем семантическую прозрачность при кэ-

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

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

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

сти.

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

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

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

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

ритмы для построения томов

—

обширная область для дальнейших исследований.

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

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

уровне DNS, TCP и HTTP раскрывает различные пути к снижению времени ожи-

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

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

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

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

хранилищ данных (см. главу 14) могут способствовать тому, что рожденР1ые в ре-

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

альных данных измерений.

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

связанных с измерениями

Сбор и анализ данных измерений играет важную роль в оценке Web-нротоко-

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

журналов регистрации событий при определении характеристик Web-трафика и

оценке новых идей по совершенствованию Web. В связи с этим в сообществе ис-

следователей Web ведется интенсивная работа по поиску эффективных способов

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

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

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

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

ние.

В Web-измерениях обычно участвуют большие массивы данных. Подобно

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

ний. Несмотря на важность сбора данных измерений, генерирование точных и ис-

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

шинства реализаций Web-серверов и прокси-серверов. В связи с этим подобные за-

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

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

веряющих синтаксис и семантику записей.

Эффективность Web зависит от взаимодействия между рядом протоколов. Время

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

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

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

сообщений, данных аудио и видео, данных о текущем состоянии сети. Чтобы охарак-

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

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

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

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

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

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

ляя информации о протоколах прикладного уровня, такой как HTTP-заголовки, ко-

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

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

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

информации о сообщениях прикладного уровня.

В этой главе мы рассмотрим следующие четыре вопроса:

• Мониторинг пакетов НТТР-трафика. Большинство исследований характери-

стик \^еЬ-тр21фика основаны на данных из журналов регистрации прокси-сер-

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

482

Часть

VI.

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

информации о запросах и ответах HTTP, а также о временных параметрах

различных этапов Web-транзакций. Трассировка пакетов путем мониторинга

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

лось в главе 9 (раздел 9.2.4). В этой главе мы опишем проблемы, связагпхые

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

ТСР-соединения и восстановлением сообщений запросов и ответов HTTP.

• Анализ журналов Web-серверов. Данные журналов серверов используются

в большинстве исследований. Однако анализ журна^юв серверов сопряжен

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

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

Предварительная обработка журна/юв может значительно уменьшить слож-

гюсть программы анализа, как говорилось в главе 9 (раздел 9.4). В этой главе

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

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

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

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

разработки надежного и эффективного программгюго обеспечения.

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

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

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

Данные измерений обычно являются доступными в Web. Мы представим

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

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

в различных форматах по принципу «как есть». Консорциум World Wide Web

Consortium (W3C) разработал официальное описание синтаксиса и семанти-

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

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

• Измерение параметров мультимедийных потоков. Хотя большинство работ по

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

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

нию параметров мультимедийного трафика. При измерениях, проводимых на

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

ки,

что и для НТТР-трафика, однако учитываются и уникальные для мультиме-

дийных дагнгых характеристики. Измерение характеристик мультимедийного

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

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

дел 12.3). Мы познакомимся с четырьмя исследованиями, основанными па ста-

тическом анализе мультимедийных файлов в Web, анализе журна7юв мульти-

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

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

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

чения в сборе и анализе измерений трафика.

14.1.

Мониторинг пакетов НТТР-трафика

Мониторинг пакетов

—

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

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

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

Глава

14.

Перспективы

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

связанных

измерениями

483

жащий программное обеспечение, которое обрабатывает пакеты с целью формиро-

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

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

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

ки пакетов НТТР-трафика:

• Подключение к IP-сети.

• Перехват пакетов HTTP-передач.

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

• Восстановление упорядоченного гютока байтов.

• Извлечение HTTP-сообщений из потока байтов.

• Формирование журнала HTTP-сообщений.

При измерении параметров НТТР-трафика с помощью монитора пакетов требу-

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

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

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

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

прерванные передачи. Помимо этого, монитор должен мириться с HTTP-сообще-

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

с этими протоколами. Первая попытка восстановления HTTP-сообщений из IP-

трасс в онеративгюм режиме описывается в [FelOOa].

14,1

Л.

Подключение к каналу

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

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

технологии и конфигурации сети, а именно:

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

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

net, кольцо FDDI или беспроводную сеть. Каждая машина в сети видит каж-

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

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

тор пакетов к сети, как показано на рис. 14.1 а. Обычный компьютер в сети

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

правленных ему пакетов. Однако многие сетевые карты допускают настройку

для работы в

смешанном

режиме,

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

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

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

при их поступлении. Эта операция является пассивной и не оказывает влия-

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

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

• Мост. Альтернативный подход предусматривает мониторинг трафика па мос-

ту, который передает трафик между сегментами сети, как показано на рис. 14.1

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

передаваемого от одного сегмента другому. Участвуя в пересылке каждого па-

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

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

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

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

484

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

Компьютер А Компьютер

Монитор

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

Компьютер

Мост/

Монитор

б) Мост

Компьютер

в) Коммутатор

Компьютер

Монитор

Маршрутизатор

Монитор

Маршрутизатор

г) Расщепление канала

Рис.

14.1. Методы подключения

сети

• Коммутатор. Некоторые сети включают

себя коммутаторы, которые направ-

ляют пакеты

из

входных каналов

выходные каналы. Коммутаторы обычно

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

чем

среда передачи данных,

по-

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

по

каждому

из

каналов.

В сравнении

мониторингом

общей среде передачи данных, перехват паке-

тов

на

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

Ни

один

из

каналов

не

видит

все

копии пакетов. Один

из

способов получить каждый

из

пакетов

—

подключить монитор пакетов

каждому входному каналу или

ка-

ждому выходному каналу. Однако

это

может оказаться слишком дорогостоя-

Ш.ИМ.

Другая альтернатива

—

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

монитора пакетов

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

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

как

показано

на

рис.

14.1

в.

Коммутатор будет направлять пакет

предназначенный

для

него

исходящий канал

и в

монитор. Однако копирование пакетов

из

каждого вход-

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

ка-

нала,

которому подключен монитор.

этой связи групповая пересылка

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

• Канал точка-точка. Установка моста или коммутатора

возможностями груп-

повой передачи не всегда возможна. Альтернативный подход

мониторингу па-

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

на две

части,

как

показано

на

рис.

14.1 г. На

рису1Гке представлен двунаправленный канал, который состоит

из двух однонаправленных кана/юв между нарой маршрутизаторов. Каждый

Глава 14. Перспективы исследований, связанных с измерениями 485

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

В некоторых случаях канал в действующей сети может уже быть расщеплен для

целей тестирования и диагностики. Подюночение к расщепленному каналу дает

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

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

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

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

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

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

14.1.2.

Перехват пакетов

Кроме подключения к каналу передачи данных, монитор должен иметь эффек-

тивный способ идентифицировать, какие IP-пакеты перехватывать при их постун-

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

том, например, HTTP использует порт 80. Для отслеживания НТТР-трафика мо-

нитор пакетов может ограничиться учетом ТСР-трафика на гюрту 80. Такое

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

протокола в IP-заголовке и номеров портов источника и места назначения в ТСР-

заголовке. Однако выделить весь НТТР-трафик достаточно трудно. Некоторые

Web-сайты не используют данный порт, а порты 8000 или 8080. Кроме того, неко-

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

токол. Хотя порты выделяются определе1Н1ым приложениям, разработчик прило-

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

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

Кроме того, в Web имеется протокол HTTPS, использующий порт 443. Мони-

тор пакетов может захватить HTTPS-трафик путем отслеживания ТСР-трафика,

содержащего в качестве номера порта источника и места назначения порт 443. Од-

нако данные, передаваемые через HTTPS, зашифрованы с применением Secure

Socket Layer (SSL). Монитор не может идентифицировать HTTP-сообщения, пере-

даваемые через эти ТСР-соединения. Однако может перехватывать ТСР-трафик на

порту 443 с целью расчета основных статистических показателей, таких как число

соединений и байтов, передаваемых с помощью HTTPS. Другие передачи, иниции-

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

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

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

протоколы, которые динамически назначают номера порто» при передаче данных.

Например, клиент и сервер File Transfer Protocol (FTP) могут динамически выби-

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

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

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

подробнее будет говориться далее в разделе 14.4.4.

Перехват трафика с определенными IP- и ТСР-заголовками требует примене-

ния фильтра к IP-пакетам по мере их поступления. Как можно более ранняя

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

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

ное аппаратное обеспечение, которое осуществляет классификацию пакетов при их

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

фильтровываться операционной системой или приложением. Большое число про-

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

486

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

[JLM, TcpJ на основе фильтра пакетов Berkeley Packet Filter (BPF) [MJ93J.

BPF-фильтры пакетов анализируют комбинации полей заголовков IP и TCP/UDP,

а также сохраняют фиксированное число байтов для каждого пакета, прошедшего

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

вые 40 байтов всех пакетов, использующих TCP на порту 80 в качестве источника

или назначения, либо UDP-пакетов с портом назначения 23. Программное обеспе-

чение BPF может быть установлено на большом числе платформ.

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

заться достаточным хранить заголовки IP и TCP. Однако для просмотра HTTP-со-

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

заголовков IP и TCP. НТТР-сообщепия могут быть разбиты на IP-пакеты различ-

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

ся в любом IP-пакете ТСР-соединеиия, как показано на рис. 14.2. Первое сообще-

ние HTTP-запроса или ответа в соединении начинается с первого пакета, переда-

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

Однако НТТР-заголовок может размещаться в нескольких пакетах. Кроме того, по

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

щений. HTTP-заголовки могут встретиться в любом месте ТСР-соединения. Фак-

тически заголовок может начинаться даже в середине IP-пакета. Таким образом,

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

IP-пакетов.

Сегменты TCP

ж^

Тело HTTP

Тело HTTP FIN

Заголовок HTTP Заголовок HTTP Заголовок HTTP

Рис.

14.2. НТТР-сообщепия, состоящие из последовательности ТСР-ссгмептов

Мониторинг пакетов НТТР-трафика предусматривает перехват всего содержи-

мого каждого IP-пакета, который содержит ТСР-сегмент с портом 80 для источни-

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

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

не может справиться с большим объемом поступающих пакетов. При перехвате и

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

ни,

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

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

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

тупу к частной информации в HTTP-заголовках и телах сообщений. Пройдя через

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

или па диске для последующей обработки. По мере восстановления HTTP-сообще-

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

вергнув некоторые IP-пакеты. Монитор пакетов должен эффективно использовать

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

ростью перехватывать запросы и ответы HTTP.

Глава

14.

Перспективы

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

связанных

измерениями

487

14.1.3,

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

Любой стандартный канал в Internet обычно передает трафик в интересах не-

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

ния каждого пакета с соответствующим ТСР-соединением. Однако монитор паке-

тов не является источником или конечной точкой ТСР-соединеиия и может не ви-

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

должен подразумевать наличие ТСР-соединения, исходя из информации в заго-

ловках IP- и ТСР-пакета. ТСР-соединение идентифицируется по IP-адресам и но-

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

имеющие одни и те же IP-адреса и номера портов источника и получателя. Для

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

мы будем называть группу пакетов

потоком.

Пакеты с портом назначения 80 явля-

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

точника составляют часть потока ответов к Web-клиенту.

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

цу потоков, как показано на рис. 14.3. Предполагая, что Web-сервер использует

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

ние трех полей: IP-адреса клиента, IP-адреса сервера и номера порта клиента. Каж-

дая запись в хэш-таблице соответствует двум потокам: потоку запросов и потоку

ответов. Поступающий пакет ассоциируется с ключом и направлением на основе

IP-адресов и номеров портов. В зависимости от своего местоположения монитор

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

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

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

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

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

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

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

Хэш-таблица потоков запрос/ответ

IP-пакет

Адрес клиента,

порт клиента

и адрес сервера

Информационное

содержание на диске

Ответ

Рис.

14.3. Хэш-таблица для демультиплексирования пакетов на потоки

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

ты,

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

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

нагрузке. Необходимо эффективное проектирование монитора пакетов, чтобы из-

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

пространства. С этой целью монитор может присваивать наивысший приоритет не-

488

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

рехвату и фильтрации пакетов. Другим

задачам,

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

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

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

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

Для дальнейшего повышения эффективности программное обеспечение, выпол-

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

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

данных из заголовков IP и TCP, но не на основе содержимого пакетов. Доступ

к остальной части пакета может быть отложен до следующего этапа либо вообще

не осуществляться, о чем пойдет речь ниже.

14.1.4.

Восстановление упорядоченного потока

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

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

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

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

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

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

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

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

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

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

В любом случае монитор может получить повторные пакеты. Еще более осложняет

ситуацию то, что TCP не гарантирует, что повторно передаваемые данные будут сфор-

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

монитор не сможет легко обнаружить и удалить пакеты-дубликаты. Вместо этого мо-

нитор должен выявлять повторяющиеся области байтов в ТСР-потоке.

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

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

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

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

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

1юмера в ТСР-заголовке. Повторяющиеся данные могут быть выявлены на основе

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

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

имеет гюрядковый номер 50 и длину 10, а другой пакет имеет порядковый помер 55

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

тью байтами второго пакета. При обработке данных в этом потоке монитор должен

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

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

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

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

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

затрудняют этот процесс. Поток считается завершенным, если он имеет начало, ко-

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

собой законченное ТСР-соединение с пакетом SYN, пакетом FIN или RST и пол-

ным объемом данных. Количество байтов, ожидаемое между SYN и FIN/RST, мо-

жет быть определено на основе порядковых номеров в пакетах SYN и FIN/RST.

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

Глава

14.

Перспективы

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

связанных

измерениями

489

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

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

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

крайнем случае ТСР-отправитель мог прекратить работу (по причине фатального

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

тов FIN или RST. В любом из этих сценариев монитор пакетов может быть не в со-

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

потока на основе исходного потока.

Незавершенные потоки потребляют ресурсы монитора пакетов. Кроме того,

в определенный момент в будущем другое ТСР-соединепие между этими же ком-

пьютерами может использовать те же номера портов. Это может заставить монитор

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

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

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

основе таймаутов. Если поток не получил каких-либо новых пакетов в течение оп-

ределенного периода времени, монитор может предположить, что ТСР-соединение

закончено. Выбор соответствующего интервала времени

—

непростая задача. Боль-

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

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

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

ятность того, что поток будет завершен, когда ТСР-соединение еще остается

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

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

ветами HTTP.

Стратегия выбора значений таймаута для

потоков

зависит от деталей реализа-

ции TCP и HTTP. Значение таймаута для потока должно превышать допустимые

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

в TCP и для закрытия бездействующих ТСР-соединений клиентами и серверами

HTTP. Исследование данных измерений и серверного программного обеспечения

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

таймаута. На практике монитор может завершать бездействующие потоки, перио-

дически проверяя записи в хэш-таблице. Для каждой записи монитор может опре-

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

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

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

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

14.1,5.

Извлечение HTTP-сообщений

Извлечение HTTP-сообщений из потока требует от монитора просмотра после-

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

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

потерянные пакеты и как совместить извлечение HTTP-сообщений с восстановле-

нием упорядоченного байтового потока. Каждое НТТР-сообщеиие состоит из заго-

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

HTTP-сообщений, как показано на рис. 14.2. Обработка потока требует идентифи-

кации заголовка сообщения и обнаружения начала следующего сообщения. Поток

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

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

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