Мониторинг пакетов НТТР-трафика. Восстановление упорядоченного потока

При обработке пакетов в составе потока монитор должен выполнять многие функции получателя ТСР-пакетов. В частности монитор должен обрабатывать полученные вне естественного порядка, поврежденные и повторяющиеся пакеты. IP не гарантирует надежной, упорядоченной доставки пакетов, следовательно, пакеты могут быть повреждепы или повторяться. Кроме того, монитор может получать повторные пакеты, появившиеся в результате повторной передачи на стороие отправителя ТСР-пакегов. Отправитель может ошибочно предположить, что пакет был утерян, и передать данные еще раз. Кроме того, первоначальный пакет может быть утерян где-то между отслеживаемым каналом и TCP-получателем. Таким образом монитор может перехватить пакет, который пикогда не достигнет предполагаемого получателя. В любом случае монитор может получить повторные пакеты. Еще более осложняет ситуацию то, что TCP не гарантирует, что повторно передаваемые данные будут сформированы в пакеты таким же образом, как первоначальные данные. Следовательно, монитор не сможет легко обнаружить и удалить пакеты-дубликаты. Вместо этого монитор должен выявлять повторяющиеся области байтов в ТСР-нотоке.

Как и TCP-получатель, монитор пакетов может использовать информацию TCP-заголовков, чтобы сформировать упорядоченный поток байтов из последовательности пакетов! Поврежденные пакеты могут выявляться и удаляться на основе анализа ноля контрольной суммы в TCP-заголовке. Поступившие вне естественного порядка пакеты могут быть переупорядочены на основе значения поля порядкового номера в TCP-заголовке. Повторяющиеся данные могут быть выявлены на основе порядковых номеров и длин сегментов. Например, рассмотрим два пакета с одинаковыми адресами источника, получателя и номерами портов. При этом один пакет имеет порядковый помер 50 и длину 10, а другой пакет имеет порядковый номер 55 и длину 20. Последние нять байтов в нервом пакете перекрываются с первыми пя- тыо байтами второго пакета. При обработке данных в этом потоке монитор должен учесть эти пять байтов один раз, отвергнув последние пять байтов первого пакета или первые пять байтов второго пакета. В других случаях, когда один пакет полпо- стыо поглощен другим, монитор может отвергнуть избыточный пакет.

В определенный момент монитору потребуется определить, что поток завершен. Возможность поступления пакетов не в том иорядке и повторная передача пакетов затрудняют этот процесс. Поток считается завершенным, если он имеет начало, конец и все, что находится между пими. Таким образом, поток должен нредставлять собой закопченное TCP-соединение с пакетом SYN, пакетом FIN или RST и полным объемом данных. Количество байтов, ожидаемое между’5УМ и FIN/RST, может быть определено на осиове порядковых номеров в пакетах SYN и FIN/RST. Однако поток может не удовлетворять этим трем критериям. Монитор мог иропус- тить пакеты, некоторые пакеты могли проходить по пути.’который не включает в себя отслеживаемый канал, какая-либо причина могла заставить ТСР-соединение закончиться до того, как будут повторно переданы все потерянные пакеты. В самом крайнем случае TCP-отправитель мог прекратить работу (по причине фатального сбоя) до завершения соединения, в результате чего поток не будет содержать пакетов FIN или RST. В любом из этих сценариев мопитор пакетов может быть не в состоянии успешно завершить восстановление упорядоченного, надежного байтового потока на основе исходного потока.

Незавершенные потоки потребляют ресурсы монитора пакетов. Кроме того, в определенный момент в будущем другое ТСР-соединение между этими же компьютерами может использовать те же номера портов. Это может заставить мопитор ошибочно связать пакеты нового ТСР-соединения с потоком старого ТСР-соедиие- ния. Чтобы этого не случилось, монитор должен прекратить ожидание поступления дополнительных пакетов в поток. Наиболее просто это реализуется в схеме на основе таймаутов. Если поток не получил каких-либо новых пакетов в течение определенного периода времени, мопитор может предположить, что ТСР-соединеиие закончено. Выбор соответствующего интервала времени — непростая задача. Большое время таймаута обусловливает высокие требования к ресурсам монитора пакетов и увеличивает вероятность, что новое ТСР-соединеиие продолжит погок закрытого TCP-соединения. В то же время малое значение таймаута повышает вероятность того, что поток будет завершен, когда ТСР-соединеиие еще остается активным. Например, долговременное соединение может находиться в состоянии простоя иесколько десятков секунд между последовательными запросами или ответами HTTP.

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

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