Учебное пособие Издательство спбгпу санкт-Петербург

Вид материала

Содержание

Описание программных средств анализа трафика
Вставить про
Пример: Agent/TCP set window_ 100; # влияет на класс
Agent/TCP set window_ 20
Agent/TCP set packetSize_ 1000
Agent/TCP set slow_start_restart_ true;# использование механизма медленного старта (1/0). Включено по умолчанию
Agent/TCP set cwnd_ 0;# текущее значение окна переполнения (packets)
Agent/TCP set srtt_ 0;# сглаженное (среднее) rtt
Инструмент имитационного моделирования AnyLogic_5.3
Принципы построения AnyLogic.
Моделирование систем с дискретными событиями.
Агентное моделирование.
Системная динамика

Подобный материал:

1 2 3 4 5 6 7 8

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

Wireshark

Для исследования процессов в компьютерных сетях широко используются программы перехвата и анализа пакетов. Эти программы являются основным инструментом при решении задач:

Обнаружение проблем и узких мест сети (troubleshooting)

Анализаторы трафика позволяют получить практически полную картину событий, происходящих в сети: интенсивность трафика по времени, по рабочим станциям, по протоколам, количество ошибок разных типов.

Отладка разрабатываемого сетевого ПО.

Часто только тщательный разбор заголовков отправляемых и принимаемых пакетов позволяет найти причину неверного функционирования ПО.

Обучение.

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

Протоколирование сетевого трафика.

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

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

В результате перехвата пакетов получают некий «сырой» дамп данных, обычно разделенный на блоки по границам кадров (пакетов).

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

Сетевые анализаторы могут перехватывать как свой трафик, так и весь трафик сетевого сегмента.

При работе в локальных сетях, сетевые платы в нормальном режиме захватывают только кадры со своим или широковещательным МАС-адресом назначения. Таким образом, в нормальном режиме имеется возможность перехвата и анализа только «своего» трафика. Для перехвата пакетов всех станций сегмента сетевые анализаторы переводят сетевую карту в «неразборчивый» режим, в котором карта принимает и не адресованные ей кадры.

Анализаторы трафика могут функционировать как на сетевых коммуникационных устройствах (маршрутизаторах, коммутаторах и пр.), так и на оконечных узлах сети.

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

Поддерживаемыми физическими интерфейсами и протоколами канального уровня;
Качеством декодирования и количеством распознаваемых протоколов;
Пользовательским интерфейсом и удобством отображения;
Дополнительными возможностями: статистика, просмотр в реальном времени, генерирование и модификация пакетов и др.

Для получения данных о трафике в рамках учебно-лабораторного комплекса используется программный пакет Wireshark [6] (ранее Ethereal) – анализатор сетевых протоколов, который позволяет фиксировать и в интерактивном режиме просматривать содержание пакетов.

Wireshark — открытое программное обеспечение, распространяющееся по лицензии GNU GPL. Что немаловажно при организации учебного процесса.

Поддерживаемые операционные системы: AIX, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, SCO, Solaris, True64 UNIX, Windows.

Фильтр по захвату трафика позволяет работать с различными сетевыми технологиями (Ethernet, Token Ring, ATM, ...). Ограничить захват можно с помощью различных триггеров (количество захваченных пакетов, время захвата, количество захваченных данных). При длительном захвате есть возможность сохранять дамп в несколько файлов. При выводе пакетов можно использовать мощную систему фильтрации Wireshark, отбирающую пакеты по большему, нежели в других анализаторах, числу полей.

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

Получить более подробную информацию о поддерживаемых программой форматах и других возможностях можно из руководства пользователя, доступного на сайте hark.org.

MTraffic

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

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

Функциональные возможности:

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

- исследование трафика с использованием методов статистического анализа (подсчет дисперсии, среднего, показателя Хэрста, коэффициенты пачечности и пиковости),

- исследование трафика с использованием методов нелинейной динамики (анализ числовых рядов, поиска внутренней зависимости в них (корреляции), построение уравнения, описывающего числовой ряд). Для ускорения вычислений предусмотрено распараллеливание наиболее трудоёмкого фрагмента кода и автоматический расчёт его на кластере.

Структура MTraffic приведена на рис. 2.1.

Структурная схема MTraffic

Разработанное инструментальное средство имеет модульную структуру:

Common_parametrs.m (общий анализ),
Classical_analyze.m (методы статистического анализа),
rtcp_test.m. (анализ протокола RTCP),
polyrebuild_diff.m (восстановление уравнения дифференциальным методом),
polyrebuild_razn.m (восстановление уравнения разностным методом),
Size_analyzer.m (обработка временного ряда),
MTraffic.m (главное меню).

Сетевой симулятор NS2

ВСТАВИТЬ ПРО NS

TCP объекты в NS-2:

Объекты типа TCP представляют собой класс объектов агентов, моделирующих транспортный протокол TCP Tahoe.

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

Пример:

Agent/TCP set window_ 100; # влияет на класс

$tcp set window_ 2.0;# меняет window_ только для объекта $tcp

Конфигурационные параметры

window_ - верхняя граница окна приемника (Advertisment Window) TCP соединения;

maxcwnd_ - верхняя граница окна переполнения TCP соединения. Для отмены ограничения устанавливается в 0 (значение по умолчанию).

windowInit_ - начальное значение окна переполнения для медленного старта.

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

windowThresh_ - постоянная сглаживающего фильтра, используемого для вычисления awnd (см. далее). Применяется для исследования различных алгоритмов управления окном.

overhead_ - диапазон случайно распределенной переменной, используемой для задержки каждого выходного пакета. Применяется только в версии tcp Tahoe, в tcp Reno не используется.

ecn_ - указатель использования (true/false) механизма явного оповещения (explicit congestion notification) в дополнение к отбрасыванию пакетов, при насыщении.

packetSize_ - размер пакетов источника;

tcpTick_ - интервал таймера TCP, используемый для оценки времени RTT (round-trip time). По умолчанию установлена нестандартная величина 100ms.

bugFix_ - указатель (true/false) запрета механизма быстрой повторной передаче при потере пакетов в одном окне данных. Установка в true запрещает быстрый повтор передачи нескольких пакетов, потерянных в одном окне данных.

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

slow_start_restart_ - признак использования (1/0) механизма медленного старта. Включено по умолчанию.

MWS (Maximum Window Size) – константа, определяющая максимальный размер окна (в пакетах), допустимый в симуляторе. По умолчанию MWS=1024 пакетам. Для Tahoe TCP параметр "window" представляет размер указанного окна получателя, которое должно быть меньше чем MWS-1. Для Reno TCP значение "window" должно быть меньше чем (MWS-1)/2.

Переменные состояния

dupacks_ - число дублирующих подтверждений (ACK), полученных после прихода последнего недублирующего подтверждения

seqno_ - наивысший последовательный номер сегмента (sequence number) для данных источника TCP;

t_seqno_ - текущий последовательный номер сегмента (пакета) пакета;

ack_ - наивысшее значение из полученных подтверждений;

cwnd_ - текущее значение окна переполнения;

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

ssthresh_ - текущее значение порога медленного старта;

rtt_ - оценка значения round-trip time;

srtt_ - оценка сглаженного значения round-trip time;

rttvar_ - оценка среднего отклонения значений round-trip time;

backoff_ - экспоненциальная постоянная задержки для round-trip time;

Наиболее часто модифицируемые переменные - window_ и packetSize_. Эти значения сильно влияют на поведение ТСР, их установка связывает модель с реальным ТСР, функционирующим в мировой сети. TCP с большим значением размера пакета, большим окном и меньшим RTT (результат топологии и перегрузки) более агрессивны в запросах к пропускной способности сети.

Значения по-умолчанию для каждого агента TCP:

Agent/TCP set window_ 20;

Agent/TCP set windowInit_ 1;

Agent/TCP set windowThresh_ 0.002;# постоянная сглаживающего фильтра, используемого для вычисления awnd. Применяется для исследования различных алгоритмов управления окном.

Agent/TCP set overhead_ 0;#!=0 (добавляет случайное время между передачами) Agent/TCP set ecn_ 0;#(explicit congestion notification) TCP должен реагировать на ecn бит. Указатель использования (true/faulse) механизма явного оповещения о насыщении в дополнение к отбрасыванию пакетов.

Agent/TCP set packetSize_ 1000;

Agent/TCP set bugFix_ true;# указатель (true/false)запрета механизма быстрой повторной передачи при потере пакетов в одном окне данных. Если true – запрет.

Agent/TCP set slow_start_restart_ true;# использование механизма медленного старта (1/0). Включено по умолчанию

Agent/TCP set maxrto_ 64; # RTO (seconds)

Agent/TCP set dupacks_ 0;# число дублирующих подтверждений ACK, полученных после последнего недублирующего подтверждения

Agent/TCP set ack_ 0;# наивысшее значение из полученных подтверждений ACK

Agent/TCP set cwnd_ 0;# текущее значение окна переполнения (packets)

Agent/TCP set awnd_ 0;# среднее cwnd (experimental)

Agent/TCP set ssthresh_ 0;# текущее значение порога медленного старта (packets)

Agent/TCP set rtt_ 0;# rtt отсчет

Agent/TCP set srtt_ 0;# сглаженное (среднее) rtt

Agent/TCP set rttvar_ 0;# среднее отклонение отсчета rtt

Agent/TCP set backoff_ 0;# экспоненциальная постоянная задержки RTO

Agent/TCP set maxseq_ 0;# максимальный посланный номер (packet) seq

В настоящее время ns2 поддерживает следующие TCP-агенты односторонних передач:

• Agent/TCP - a “Tahoe” TCP-отправитель

• Agent/TCP/Reno - a “Reno” TCP-отправитель

• Agent/TCP/Newreno - Reno с модификацией

• Agent/TCP/Sack1 - TCP с выборочным повтором (RFC2018)

• Agent/TCP/Vegas - TCP Vegas

• Agent/TCP/Fack - Reno TCP с «последующим подтверждением»

• Agent/TCP/Linux - a TCP-передатчик с поддержкой SACK который использует TCP с перезагрузкой контрольных модулей из ядра Linux

Односторонние агенты приема:

• Agent/TCPSink

• Agent/TCPSink/DelAck

• Agent/TCPSink/Sack1

• Agent/TCPSink/Sack1/DelAck

Двунаправленный агент в текущей версии поддерживается только агентом формы Reno TCP:

• Agent/TCP/FullTcp

Симулятор поддерживает несколько версий абстрактных TCP-отправителей. Эти объекты пытаются зарегистрировать присутствие TCP перегрузки и осуществить контроль ошибок поведения сети, но не являются достоверными моделями реального TCP. Они не содержат описания динамического окна, они вычисляют номер сегмента и номер ACK полностью в части пакета, нет SYN/FIN связи установления/завершения, и никакие данные не передаются (нет контрольных сумм или передающихся данных). По умолчанию ТСР агентом является агент версии Tahoe ТСР.

Объекты типа Tahoe-TCP-отправитель (cwnd = 1 на любую потерю)

В отличие от более ранних реализаций протокола TCP, в версии TCP Tahoe добавлен ряд новых алгоритмов управления передачей. К ним относятся:

медленный старт (Slow-Start),

предупреждение насыщения (Congestion Avoidance),

быстрый повтор передачи (Fast Retransmit),

новый метод оценки длительности цикла передачи (RTT - Round Trip Time), используемой для установки таймера повторной передачи (RTO - Retransmission TimeOut).

Рассмотрим их подробнее:

Если буфер переполнен, какое-то число сегментов будет потеряно. При этом может быть запущено несколько сценариев. Основной вариант - медленный старт, запускается в рамках классического алгоритма TCP-Tahoe при потере сегмента и сопряженным с ним таймаутом (RTO) у отправителя, так как отправитель не получит сигнала подтверждения -ACK для потерянного сегмента. Смысл этого алгоритма заключается в удержании значения CWND в области максимально возможных значений. По существу эта оптимизация осуществляется с помощью потери пакетов.

Потерянный пакет и все, посланные после него, пакеты (вне зависимости оттого, подтверждено их получение или нет) пересылаются повторно. При большой вероятности потери это существенно понижает пропускную способность и увеличивает и без того высокую загрузку канала^².

«Tahoe» TCP агент представляет контроль перегрузки и оценку RTT следующим образом: Окно перегрузки увеличивается на 1 пакет с каждым ACK, полученным в течение медленного старта (когда cwnd_ < ssthresh_) и увеличивается на 1/cwnd_ для каждого нового ACK, полученного при избегании перегрузки (когда cwnd_ ≥ ssthresh_).

Реакция на перегрузку: Tahoe TCP считает пакет потерянным (от перегрузки), когда он определяет NUMDUPACKS (определено в tcp.h, в настоящее время равно 3/кол-во пакетов, не получивших подтверждения) дублирующих ACKs, или когда истекает время повторной передачи. В каждом случае Tahoe TCP реагирует, устанавливая ssthresh_ в половину текущего размера окна (минимум из cwnd_ и window_) или в 2, в зависимости от того, что больше. Затем он снова присваивает cwnd_ значение windowInit_. Это обычно приводит к переходу ТСР в режим медленного старта.

Оценка Round-Trip Time и RTO

4 переменных используются для оценки round-trip time и они определяют время повторной передачи:

rtt_ - значение RTT,

srtt_ - сглаженное значение RTT,

rttvar_ - среднее отклонение значений RTT,

tcpTick_ - интервал таймера TCP,

backoff_ - экспоненциальная постоянная задержки для RTT.

TCP инициализирует rttvar_ = 3/tcpTick_ и backoff_ = 1. Когда таймер будущих повторных передач установлен, его timeout устанавливается в текущее время + max(bt(a + 4v + 1), 64) секунд, где

b – текущее значение backoff_ ,

t - значение tcpTick_,

a - значение srtt_,

v - значение rttvar_.

Отсчет RTT приходит с новым ACK. Отсчет RTT рассчитывается как разница между текущим временем и полем «времени эха» в пакете ACK. Когда первый отсчет взят, его значение используется как инициализируемое для srtt_. Половина первого отсчета используется для инициализации rttvar_. Для последующих отсчетов, значения изменяются следующим образом:

Конфигурация.

Запуск TCP симуляции предполагает создание и конфигурирование агента, прикрепление источника данных (генератора трафика) и их запуск.

Источник данных TCP.

TCP-агент не генерирует никаких прикладных данных, вместо этого пользователь может соединить любой генерирующий трафик модуль с ТСР-агентом для генерации данных. Обычно используется FTP и Telnet. FTP представляет массу передач большого объема, а telnet выбирает размер передачи случайно из tcplib (см. файл tcplib-telnet.cc.)

Объекты типа TCP/Reno являются подклассом объектов TCP, моделирующим протокол Reno TCP. Reno TCP очень похож на Tahoe TCP агент, за исключением того, что он содержит fast recovery. Новый алгоритм не требует освобождение канала и его медленного (slow-start) заполнения, после потери одного пакета. Отправитель переходит в режим быстрого восстановления, после получения некоторого предельного числа дублирующих подтверждений. Как правило, этот предел (tcprexmtthresh) устанавливается равным трем. После получения указанного числа дублирующих подтверждений, отправитель повторяет передачу одного пакета и уменьшает окно насыщения (cwnd) в два раза. Но, в отличие от версии TCP Tahoe, не переходит к алгоритму медленного старта. Он уменьшает размер окна до половины текущего размера и устанавливает ssthresh_ в соответствии с этим значением.

В Reno TCP при нормальной ситуации размер окна меняется циклически. Размер окна увеличивается до тех пор, пока не произойдет потеря сегмента. TCP-Reno имеет две фазы изменения размера окна: фаза медленного старта и фаза избегания перегрузки. При получении отправителем подтверждения доставки в момент времени t + tA (сек.), текущее значение размера окна перегрузки cwnd_(t) преобразуется в cwnd_(t + tA) согласно:

(1),

где

ssth(t) [ssthresh(t)] - значение порога в пакетах, при котором TCP переходит из фазы медленного старта в фазу исключения перегрузки. Когда в результате таймаута детектируется потеря пакета значения cwnd(t) и ssth(t) обновляются следующим образом:

cwnd(t)=1; ssth(t)=(cwnd(t))/2;

С другой стороны, когда TCP детектирует потерю пакета согласно алгоритму быстрой повторной передачи, cwnd(t) и ssth(t) обновляются иначе:

ssth(t) = (cwnd(t))/2;

cwnd(t) = ssth(t);

TCP-Reno после этого переходит в фазу быстрого восстановления. В этой фазе размер окна увеличивается на один пакет, когда получается дублированное подтверждение. С другой стороны, cwnd(t) делается равным ssth(t), когда приходит не дублированный отклик для пакета, посланного повторно. В случае таймаута ssth(t)= (cwnd(t))/2; cwnd=1 (см. описание алгоритма TCP-Tahoe).

Для этих объектов не определены никакие дополнительные методы, конфигурационные параметры и переменные.

Объекты TCP/NewReno являются подклассом объектов TCP, моделирующим модифицированную версию протокола BSD Reno TCP. Основан на Reno TCP-агенте, но с модификацией действий, предпринимаемых при получении новых подтверждений ACK. Для того чтобы избежать быстрого восстановления, отправитель должен получить ACK с наивысшим посланным номером в последовательности пакетов. Этот, новый “partial ACK” не влияет на окно.

При получении трех дублированных подтверждений (DUPACK) отправитель считает пакет потерянным и посылает его повторно. После этого отправитель может получить дополнительные дублированные подтверждения, так как получатель осуществляет подтверждение пакетов, которые находятся в пути, когда отправитель перешел в режим fast retransmit. В случае потери нескольких пакетов из одного окна отправитель получает новые данные, когда приходит подтверждение для повторно посланных пакетов. Если потерян один пакет и не было смены порядка пакетов, тогда подтверждение этого пакета будет означать успешную доставку всех предыдущих пакетов до перехода в режим fast retransmit. Однако, если потеряно несколько пакетов, тогда подтверждение повторно посланного пакета подтверждает доставку некоторых, но не всех пакетов, посланных до перехода в режим быстрой повторной пересылки (fast retransmit). Такие подтверждения называются частичными.

Разработчики назвали алгоритм быстрого восстановления NewReno, так как он значительно отличается от базового алгоритма Reno. Предложенный алгоритм дает определенные преимущества по сравнению с каноническим Reno при самых разных сценариях. Однако, при одном сценарии канонический Reno превосходит NewReno - это происходит при изменении порядка следования пакетов.

Конфигурационные параметры:

newreno_changes_ - указатель версии протокола. Установка в 0 соответствует основной версии NewReno, установка в 1 приводит к использованию дополнительных алгоритмов NewReno

Объекты типа TCP/Sack1 - подкласс объектов TCP, моделирующий протокол BSD Reno TCP с селективным подтверждением. Объекты Sack1 наследуют все функциональные особенности TCP объектов. Этот агент включает выборочные повторы, основанные на выборе ACKs, осуществленном получателем. Алгоритм TCP Sack использует поле "Опции" заголовка кадра ТСР для дополнительной информации о полученных пакетах станцией-получателем. Если произошла потеря, то каждый сегмент дублирующего ACK (dupACK), отправляемый получателем, содержит информацию о кадре, вызвавшем посылку данного сегмента. Таким образом, отправитель, получив данный кадр, имеет информацию не только о том, какой кадр был потерян, но также и о том, какие кадры успешно достигли получателя. Благодаря этому избегается ненужная повторная посылка сегментов, успешно буферированных на стороне получателя. Избыточные данные сохраняются в TCP-заголовке, 40 байт на сегмент. В переменную могут быть записаны два числа – 0 (выключено) и 1 (включено). Значение по-умолчанию – 1 (включено).

Как и Reno, TCP Sack входит в режим быстрого восстановления при получении трех дублирующихся подтверждений (dupACK). Во время быстрого восстановления отправитель поддерживает переменную pipe, отображающую число пакетов, находящихся в сети. Данная переменная увеличивается каждый раз, когда новый сегмент был отправлен и уменьшается, если было получено очередное подтверждение. Передача нового пакета в сеть разрешена, если значение pipe меньше окна перегрузки.

Отправитель также поддерживает структуру данных scoreboard, которая запоминает подтверждения из опции SACK прибывающих подтверждений. Если отправителю разрешена передача, он передает следующий пакет из списка пакетов, считаемых потерянными. Если таких пакетов, то посылается новый пакет.

Для этих объектов не определено никаких дополнительных методов, конфигурационных параметров и переменных.

Объекты типа TCP/Fack - подкласс объектов TCP, моделирующий протокол BSD Reno TCP с механизмом Forward Acknowledgement Congestion Control.

Переменная tcp_fack ответственна за систему Forward Acknowledgement (Упреждающее Подтверждение) в Linux. Forward Acknowledgement – это специальный алгоритм, который работает поверх SACK, и предназначен для контроля "заторов".

Главная идея алгоритма FACK состоит в отслеживании наибольшего номера выборочно подтвержденной последовательности как признака того, что все предыдущие не подтвержденные (выборочно) сегменты были потеряны. Это позволяет оптимизировать восстановление потерь. Однако, этот алгоритм становится неработоспособным в случае неупорядоченного потока данных, тогда он (алгоритм) автоматически отключается для данного конкретного соединения.

Изначально алгоритм FACK был разработан Мэттью Матисом (Matthew Mathis) с соавторами.

Переменная может принимать два значения – 0 (выключено) и 1 (включено). Значение по-умолчанию – 1 (включено). Эта опция используется только тогда, когда включена переменная tcp_sack.

Конфигурационные параметры:

ss-div4 – делит ssthresh_ на 4 (вместо 2) если переполнение выявляется в пределах 1/2 RTT от медленного старта (1=Enable, 0=Disable).

rampdown – медленно уменьшает окно переполнения вместо того, чтобы время от времени делить его пополам (1=Enable, 0=Disable).

Объекты типа TCP/Vegas - подкласс объектов TCP, моделирующий протокол Vegas TCP.

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

,

где

rtt - зарегистрированное RTT,

base_rtt - наименьшее встретившееся в данном цикле RTT,

a и b - некоторые константы.

Эта модификация ТСР требует высокого разрешения таймера отправителя.

Конфигурационные параметры:

v_alpha_

v_beta_

v_gamma_

v_rtt_

Объекты типа TCP/FullTcp являются подклассом объектов TCP, более детально моделирующим существующие реализации протокола TCP. Отличия от других агентов ТСР заключаются в следующем:

Моделируется обмен пакетами установления и завершение соединения (SYN/FIN).

Поддерживается двунаправленная передача данных.

Последовательная нумерация (sequence number) относится к байтам, а не к пакетам.

Генерация SYN пакетов (и их ACKs) может иметь критическое значение при попытке моделирования реального поведения ТСР в случае использования множества коротких передач данных. Эта версия TCP в настоящее время по-умолчанию посылает данные на 3-ем сегменте инициированного троекратного рукопожатия, и ее поведение несколько отличается от реального ТСР. Типичное ТСР соединение происходит с отправкой SYN-а активным элементом, пассивный элемент отвечает с SYN+ACK, активный отвечает с ACK, и спустя некоторое время посылает первый сегмент данных (в соответствии с первым запросом). Таким образом, эта версия ТСР посылает данные раньше. В настоящее время FullTCP настроен только под алгоритм Reno контроля переполнения, но в скором времени должны стать доступными и другие версии (Tahoe, SACK, Vegas, и т.д.).

Конфигурационные параметры

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

segsize_ - размер сегмента;

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

iss_ - начальный последовательный номер первого байта передаваемых данных;

nodelay_- отключение (false) алгоритма Найджела (Nagle);

data_on_syn_ - разрешение/запрет (True/False) передачи данных совместно с пакетом SYN;

dupseg_fix_ - исключение быстрого восстановления при получении дублирующих подтверждений;

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

Объекты типа TCPSink представляют собой подкласс объектов агентов моделирующий протокол TCP на стороне приемника. Отметим, что объекты TCP (кроме FullTcp) моделируют только однонаправленные TCP соединения, в которых TCP-источник посылает пакеты данных, а приемник – только подтверждения (ACK пакеты). Для этих объектов не определено никаких методов и переменных.

Конфигурационные параметры

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

maxSackBlocks_ - максимальное число блоков данных, которое может быть подтверждено в опции SACK. Этот параметр используется только подклассом объектов TCPSink/Sack1. Эта величина не может быть увеличена для TCPSink объекта после того как объект создан. (После создания TCPSink объекта величина может быть уменьшена, но не увеличена).

Объекты типа TCPSink/DelAck являются подклассом объектов TCPSink, моделирующим TCP-приемник с механизмом задержанных подтверждений. Они наследуют функциональность TCPSink объектов.

Конфигурационные параметры

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

Объекты типа TCPSink/Sack1 – подкласс объектов TCPSink, моделирующий TCP-приемник с селективным подтверждением пакетов. Для этих объектов не определено никаких дополнительных методов, конфигурационных параметров и переменных.

Объекты типа TCPSink/Sack1/DelAck - подкласс объектов TCPSink/Sack1, моделирующий TCP-приемник с задержанным селективным подтверждением пакетов.

Конфигурационные параметры:

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

Объекты типа DelayBox - задержка и потеря для потока пакетов.

DelayBox – это узел ns, который должен быть помещен между источником и приемником. С использованием DelayBox, пакеты ТСР-потока могут быть задержаны, потеряны или принудительно отправлены через топологию так называемого «бутылочного горлышка», прежде, чем будут переданы следующему узлу. Для задания задержки, потери и скорости передачи в «бутылочном горлышке» может быть использовано распределение. Каждый поток пакетов между источником-приемником берет свои характеристики из распределения. Задержки в DelayBox определяются для потока, а не для пакета. Так как DelayBox распознается между потоками, переменная fid_ (идентификатор потока flow identifier) должна быть установлена для каждого потока в симуляции. DelayBox может быть использован и с Tcp и с FullTcp-агентами.

Рассмотрим топологию «бутылочное горлышко». Эта топология – одна из наиболее часто используемых в симуляциях. Она изображена на рисунке ниже. Узлы соединены с маршрутизирующим узлом R1, посылающим пакеты узлам, соединенным с маршрутизатором R2. Объем данных, производимый узлами-источниками обычно больше, чем пропускная способность линии между маршрутизаторами R1 и R2, что создает своего рода «бутылочное горлышко». Эта связь также обладает определенной потерей пакетов и односторонней задержкой.

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

Описание объекта и его структуры

DelayBox включает две таблицы: таблицу правил и таблицу потока. Вводные данные для таблицы правил добавляются пользователем на языке OTcl в симуляционном скрипте и дают структурированное представление о том, как должны обрабатываться потоки от источника к приемнику. Имеются поля источника, приемника, задержки (в мс), потери (в доле отброшенных пакетов) и поле «бутылочного горлышка» - скорость (в Мбайтах/с). Поле скорости – опционально.

Вводные данные в таблице потока создаются внутренне и точно описывают, как каждый поток должен быть обработан. Их значения получаются путем выборки из распределения, данного в таблице правил. Поля: источник, приемник, ID потока, задержка, потеря, и скорость в «бутылочном горлышке» (если необходимо). Потоки Full-TCP определяются по началу приема первого SYN-а потока с новым ID и заканчиваются после отсылки первого FIN-а. Пакеты после первого FIN-а пересылаются без задержек (они не задерживаются и не отбрасываются в DelayBox). Для Tcp-агента, потоки определяются по началу приема первых 40 байтов пакета потока с новым ID. Так как Тср-агент не включает схему «троекратного рукопожатия» и FIN-пакетов, потоки Tcp-агента никогда не считаются законченными и не удаляются из таблицы потока.

DelayBox также содержит несколько очередей для обработки пакетов с задержкой. Одна очередь для каждого ввода в таблице потока. Эти очереди – очереди с возможной дельтой, в которых время доставки пакета содержится только в первом передаваемом пакете. Все остальные пакеты хранятся в очереди с разницей (дельтой) между временем, когда они должны быть переданы, и временем, когда предыдущий пакет должен быть передан. Время, когда предыдущий пакет действительно должен быть передан, хранится в переменной deltasum_, название которой отражает ее суть. Это время есть сумма всех значений дельта в очереди (включая время передачи первого пакета). Если скорость для потока в «бутылочном горлышке» была задана, задержка обработки вычисляется для каждого пакета делением размера пакета на скорость потока в «бутылочном горлышке». Когда пакет получен, вычисляется его время передачи (текущее время + задержка). Это время передачи – время, когда первый бит пакета начнет передаваться. Пакеты, ожидающие в очереди после этого пакета, должны быть задержаны на время, необходимое для передачи всех битов пакета через «бутылочное горлышко»

Существует 2 сценария определения дельты пакета:

1. Если пакет нужно переслать прежде последнего бита последнего пакета в очереди, его дельта (время между передачей предыдущего пакета и передачей этого пакета) устанавливается в задержку обработки предыдущего пакета. Текущий пакет должен стоять в очереди после предыдущего пакета, но будет готов к посылке, как только предыдущий пакет закончит свою передачу.

2. Если пакет нужно переслать после последнего бита последнего пакета в очереди, то его дельта – это разница между временем передачи текущего пакета и временем передачи предыдущего пакета.

Если текущий пакет – единственный в очереди, DelayBox назначает таймер для получения пакета. Когда этот таймер истечет, DelayBox передаст пакет стандартному передатчику пакетов для отправки. Когда пакет передан, DelayBox начинает искать следующий пакет в очереди для передачи, и устанавливает таймер для его передачи. Все пакеты – и данных, и ACKs, получают задержку таким образом.

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

Примечание: Потери пакетов в DelayBox не записываются в файл trace-queue.

Инструмент имитационного моделирования AnyLogic_5.3

Пакет AnyLogic является разработкой российской компании «XJ Technologies». Данный продукт ориентирован на моделирование широкого круга задач.

Основными строительными блоками модели AnyLogic являются активные объекты, которые позволяют моделировать любые объекты реального мира. Чтобы создать модель AnyLogic необходимо создать классы активных объектов и задать их взаимосвязи. AnyLogic интерпретирует классы активных объектов, создаваемые пользователем графически, в классы Java. Поэтому разработчик модели может пользоваться всеми преимуществами объектно-ориентированного моделирования: наследование, полиморфизм и т.д.

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

Активные объекты имеют четко определенные интерфейсы взаимодействия. Они взаимодействуют со своим окружением только посредством своих интерфейсных элементов – портов и переменных. Для взаимодействия активных объектов посредством портов в AnyLogic существует базовый класс сообщений, с помощью которого можно моделировать любые потоки (транспортные, информационные и т.д.).

В начальной поставке присутствуют готовые библиотеки для создания моделей той или иной сферы жизни. Библиотека «Enterprise Library» содержит объекты для имитации простейших общих сетей ЭВМ.

Окна редактора при разработке модели с дискретными событиями

Принципы построения AnyLogic. AnyLogic предлагает пользователю графическую среду для создания моделей на основе простых и ясных визуальных средств с дополнительным использованием всех возможностей современного объектно-ориентированного языка Java. Этим AnyLogic отличается от большинства инструментов моделирования, для пользования которыми нужно изучить еще специализированный язык, разработанный для работы только с этим инструментом.

Использование Java в комбинации с графической средой разработки моделей дает AnyLogic огромную гибкость и выразительность. Любой объект модели, разрабатываемой в AnyLogic, представляется как класс Java, пользователь может добавить в модель свои классы, переопределять методы базовых классов, использовать базовые и разработать свои библиотеки классов и т. п. По модели, представленной в графическом редакторе, AnyLogic генерирует Java программу, с которой работает написанный на Java «движок». При построении модели в AnyLogic разработчик, фактически, создает Java-классы активных объектов и определяет отношения между ними. Во время выполнения модель представляет собой иерархию экземпляров активных объектов. Собранная модель может работать локально, на одном компьютере, или же пользователь может одним кликом мыши построить Java апплет, который можно запустить под управлением браузера.

Основной сущностью в модели, разрабатываемой в среде AnyLogic, является активный объект. Активный объект имеет внутреннюю структуру и поведение и может инкапсулировать как элементы другие активные объекты. Структура активного объекта определяет, из каких элементов он состоит и какие связи существуют между инкапсулированными объектами. Поведение определяет реакции активного объекта на внешние события – логику его действий во времени. Структурные диаграммы и карты состояний в последнее десятилетие доказали свое удобство при визуальной спецификации сложных инженерных систем. Число уровней вложенности объектов структуры, и вложенность состояний в картах состояний произвольны, что позволяет отражать в моделях структурную и поведенческую иерархию сложных систем

Анимация в AnyLogic дает возможность наглядно представить динамику всей системы в процессе моделирования. Средства анимации позволяют пользователю легко создать виртуальный мир (совокупность графических образов, мнемосхему и т. п.), управляемый динамическими параметрами модели по законам, определенным пользователем с помощью уравнений и логики моделируемых объектов.

Моделирование систем с дискретными событиями. На рынке существует множество инструментов, облегчающих разработку дискретно-событийных моделей и проведение экспериментов с моделями в этой традиционной области моделирования. В первую очередь это GPSS, который стал революцией более 40 лет назад, задав парадигму моделирования в этой области в виде блоков и транзактов. Транзакты отображают динамические объекты моделирования (заявки), а блоки – объекты, обрабатывающие эти заявки. Большинство других инструментов моделирования (Arena, Extend, ProModel, SimProcess и другие) также используют эту парадигму.

Моделирование систем с дискретными событиями в AnyLogic основывается на механизме обмена сообщениями между активными объектами через порты, а на внутриобъектном уровне используются таймеры и события с очевидной семантикой. Логика обработки сообщений задается графически с помощью карт состояний. Поэтому AnyLogic имеет естественные аналоги блоков и транзакций языков блочного моделирования: блок GPSS естественно представить активным объектом в AnyLogic, а транзакты – сообщениями. Дополнительные объекты, такие как ресурсы или очереди, легко строятся базовыми средствами AnyLogic и включены в библиотеку. Общепринятые при современной методологии разработки моделей требования визуализации динамики процессов и статистическая обработка случайных параметров являются в AnyLogic встроенными и выполняются автоматически.

В то же время AnyLogic имеет преимущества перед перечисленными системами. Возьмем классический пример моделирования магазина. Естественно описать его СМО, заявки в которой представляют покупатели. Пусть, однако, представление людей как потока однородных заявок является неадекватным для получения результата, следует учесть их поведение и возможное взаимодействие. Такая модель представляется в GPSS с большими трудностями. Если при этом необходимо учесть и скорость передвижения людей, ее зависимость от числа людей в магазине и т. п., т. е. вводить непрерывные переменные, то это выводит нас из области моделей СМО, для которых был создан GPSS. В AnyLogic непрерывные параметры и поведения у объектов вводятся просто.

Агентное моделирование. Под интеллектуальным агентом понимается объект, имеющий внутреннее поведение и возможность взаимодействовать с другими агентами. Каждый агент имеет неполную информацию или недостаточные возможности для выполнения общей задачи и в отсутствии централизованного управления должен выполнить ее в кооперации с другими агентами. Моделирование многоагентных систем используется в анализе социальных процессов, процессов урбанизации и даже при исследовании рынка в анализе предпочтений различных социальных групп. Существуют несколько экспериментальных инструментов, поддерживающих моделирование в этой области.

Анимация модели с динамически порождаемыми агентами

Моделирование многоагентных систем не представляет каких-либо сложностей в AnyLogic ни в концептуальном, ни в техническом аспекте: основной концепцией AnyLogic является то, что модель состоит из активных объектов, имеющих каждый свое поведение и взаимодействующих между собой через явно определенные интерфейсы. Поэтому агентный подход к построению моделей является в AnyLogic естественным. На рис. 2.3 представлено окно анимации модели простой мультиагентной системы.

Системная динамика – это методология изучения и моделирования систем, характеризующихся циклами в сложных взаимных зависимостях их параметров. Математически эти системы описываются системами дифференциальных уравнений первого порядка. Эти модели применяются для корпоративного планирования и анализа политик управления корпорацией, политик управления социальными и экономическими системами и т. п. Более 40 лет назад Д.Форрестер заложил методологические принципы системной динамики, которые и сейчас являются основой инструментов моделирования, конкурирующих на рынке: VenSim, PowerSim, Stella, ModelMaker и др. Для построения моделей в них используются графическое представление зависимостей переменных в виде так называемых «stock and flow diagrams».

Введение в модель функциональности, выходящей за рамки стандартной методологии системной динамики, требует больших усилий при использовании указанных инструментов. Например, если модель требует учета влияния дискретных событий на поведение системы, разработчик модели в рамках традиционной методологии должен использовать специальные ухищрения. При этом теряется простота, естественность и наглядность модели. Другой аспект, трудно реализуемый в традиционных системах моделирования системной динамики, это использование агентов для представления, например, отдельных индивидуумов или социальных групп.

AnyLogic легко справляется с этими проблемами. Модели системной динамики могут быть представлены с помощью либо аналитической записи дифференциальных уравнений, либо графического их представления, аналогичного тому, которое используется в традиционных инструментах. Возможность введения агентов в модели AnyLogic при решении задач и в этой области является столь же простым, как и в других областях. Для сложных задач можно использовать гибридные автоматы.[9]

Усложнение задач, стоящих перед любым видом бизнеса в связи с увеличившейся динамикой рынка сделали принятие адекватных управленческих решений трудным делом. Проверить различные варианты решений на основе здравого смысла и интуиции уже невозможно без использования моделирования, которое позволяет перейти от эвристических решений по управлению системой к обоснованным решениям, подкрепленным сравнением различных вариантов, исследованием компьютерной модели этой системы, построенной с любой желаемой полнотой.

Наиболее удобные средства для разработки имитационных моделей в широком спектре областей применения предлагает новый инструмент моделирования AnyLogic, который основан на ясных и четких концепциях и современных информационных технологиях. Опыт разработки моделей в AnyLogic для самых разных областей – образование, компьютерные сети и протоколы, логистика и управление производством, управление рисками в банке и др., а также опыт его применения крупными фирмами от IBM и Boeing до НР и General Electric показывает, что AnyLogic является программным продуктом нового поколения, предлагающим качественно новые возможности при разработке и анализе моделей по сравнению с традиционными средствами.

Blog

Учебное пособие Издательство спбгпу санкт-Петербург

Содержание

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