Мониторинг пакетов НТТР-трафика. Извлечение НТТР-сообщений

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

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

•          Отсутствие тела сообщения. В некоторых случаях монитор может предположить, что сообщение не содержит тела, а также следующее сообщение начинается сразу же после двойного CRLF. Например, запросы GET и ответы 304 Not Modified не содержат тела сообщения.

•          Наличие поля Content-Length. Некоторые сообщения содержат заголовок Content-Length, который указывает размер тела сообщения. Это позволяет монитору идентифицировать место в байтовом потоке, с которого начинается следующее сообщение, не просматривая байты в геле первого сообщения.

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

•          Multipart/byteranges. Сообщение-ответ с заголовком типа содержимого Con- tent-Type:multipart/byteranges имеет в теле сообщения несколько дианазо- иов данных, о чем говорилось ранее в главе 7 (раздел 7.4.1). Заголовок HTTP-ответа идентифицирует разграничитель, который помечает начало каждого байтового диапазона в теле. Монитор может выявить пачало каждого диапазона и перейти к началу следующего диапазона подобно тому, как это делается в сообщении с разбиением на фрагменты.

•          Конец TCP-соединения. Последний способ обнаружения монитором коица сообщения-ответа — это выявить, что ТСР-соединение было завершено пакетами FIN или RST. Это может случиться, если сервер использует закрытие ТСР-соедииеиия для указания конца тела ответа, либо если клиент или сервер прервали ТСР-соедипегше.

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

После определения конца одного сообщения монитор может начать извлечение следующего сообщения. Процесс повторяется до тех нор, пока все сообщения не будут извлечены из потока. Однако потерянные пакеты вносят дополнительные сложности в процесс извлечения. В действительности, в ряде случаев потерянный пакет может сделать невозможным продолжение обработки потока. Например, вос- стаповлепие при отсутствии заголовка Content-Length или дважды повторяющейся последовательности CRLF может оказаться затруднительным, либо вообще невозможным, поскольку монитор не будет знать, как идентифицировать конец тела данного сообщения и начало следующего сообщения. Утеря заголовка фрагмента или заголовка раздела внутри тела сообщения затруднит определение конца сообщения. Столкнувшись с такого рода потерями пакетов, монитор может просто записать сообщение об ошибке для указания, что оставшаяся часть потока не может быть обработана. Иметь низкую долю потерянных пакетов чрезвычайно важно. В противном случае значительная часть потоков будет иметь одну или несколько невоснолнимых потерь. Вероятность потери пакета зависит от скорости передачи данных и загруженности канала, а также от эффективности работы программных и аннаратных компонентов монитора пакетов.

В то время как потеря пакета с HTTP-заголовком порождает существенные проблемы, потеря пакета в середине тела содержимого не обязательно нарушает обработку потока. Потеря нескольких сотен байтов в большом документе в формате Postscript не мешает монитору находить следующее сообщение в потоке. На самом деле обработка тела содержимого может вообще быть не нужна. Если мопитор записывает тело содержимого или статистические данные, вычисленные на основе тела содержимого, то потеря пакета не даст монитору возможности получить информацию для этого запроса. Тем не менее, мопитор может без особых затруднений перейти к следующему сообщению в потоке. Если монитор регистрирует только НТТР-за- головки, тело содержимого вообще не подлежит обработке. В этом случае мопитор может избежать дополнительных затрат, связанных с чтением содержимого большинства захваченных IP-пакетов. Типовое сообщение НТТР-ответа содержит около 300 байтов в заголовке и около 10 килобайтов в теле сообщения. Игнорирование тела сообщения избавляет от необходимости просматривать примерно 97% перехва- чеипых данных.

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