Привет студент

Факультет информационных технологий           ВЫПУСКНАЯ  КВАЛИФИКАЦИОННАЯ  РАБОТА   Анализ потоков трафика при построении логической схемы корпоративной сети Пояснительная записка

 

Аннотация     В данной выпускной квалификационной работе была разработана программная система анализа потоков трафика. Программная система позволяет автоматизировать процессы: документирования  структуры  крупных  сетей.  Кроме  того,  для  упрощения процедур  устранения  неисправностей,  проектирования  и  управления  сетью  решается задача наглядного представления сетевой инфраструктуры. В ходе разработки была определена цель разработки программной системы, сформулированы принципы системы, выявлена сфера применения данной программной системы, выявлены информационные потоки процесса автоматизации, сформулирована постановка задачи, были рассмотрены инструментальные средства использованные для разработки данного программного продукта, разработаны и построены структура модулей и описано назначение каждого из них,  функциональная схема программной системы и подробно расписана каждая функция приложения, рассмотрен укрупненный алгоритм программной системы, спроектированы таблицы данных, сгенерированы SQL-скрипты, а также составлены  руководство по установке программной системы, руководство администратора базы данных и пользователя программной системы. Пояснительная записка содержит 67 страниц, в том числе 36 рисунков, 24 таблиц и 2 приложения.
Изм	Лист	№ докум.	Подп.	Дата
Разраб.					Анализ потоков трафика при построении логической схемы корпоративной сети Пояснительная записка	Лит	Лист	Листов
Проверил.							2	82
Рецензент
Н. контр.
Утв.

 

Содержание

 

Введение………………………………………………………………………………….4

1 Исследовательский раздел……………………………………………………………..5

1.1 Проблемы вычислительных сетей…………………………...………………………5

1.2 Корпоративная сеть передачи данных………………………………………………7

1.3 Классификация параметров, характеризующих работу сети……………………...11

1.3.1 Время реакции…………………………………………………………………….11

1.3.2 Скорость передачи трафика………………………………………………………12

1.3.3 Пропускная способность………………………………………………………….12

1.3.4 Задержка передачи и вариация задержки передачи……………………………...14

1.4 Аппаратно-программные средства анализа  корпоративной сети ………………..16

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

сетевого трафика………………………………………………………………………..20

1.6 Постановка задачи…………………………………………………………………..22

2 Разработка программной системы …………………………………………………...24

2.1 Разработка архитектуры программной системы…………………………………..24

2.2 Реализация функционального назначения программной системы……………….26

2.3 Обоснование выбора инструментальных средств разработки……………………27

2.4 Разработка алгоритм сбора информации  о трафике………………………………31

2.5 Методика построения маршрутной матрицы ……………………………………..34

2.6 Разработка алгоритма построения маршрутной матрицы………………………...41

2.7 Проектирование базы данных……………………………………………………...47

2.7.1 Выбор метода проектирования БД……………………………………………….47

2.7.2 Информационно - логическая модель предметной области…………………….47

2.7.3 Даталогическая модель БД……………………………………………………..…50

2.7.4 Физическая модель БД……………………………………………………………54

2.7.5 Реализация ограничений целостности БД………………………………………..57

2.7.6 Реализация мероприятий по защите данных………………………………….…57

2.8 Тестирование программной системы………………………………………………59

3 Технологический раздел…………………………………………………………...…61

3.1 Руководство администратору баз данных…………………………………………61

3.1.1 Общие сведения о программной системе……………………………..…………61

3.1.2 Установка программной системы………………………………..………………61

3.1.3 Проверка программной системы …………………………………………...……63

3.2 Руководство пользователя программной системы……………………...…………63

3.2.1 Условия выполнения программного средства…………………………………...63

3.2.2 Эксплуатация программного средства…………………………………………...64

Заключение………………………………………………………………………...……66

Список использованных источников………………………………………….……67

Приложение  A Листинг программы………………………………………….……69

Приложение Б SQL-скрипты……………………………………………….….………76

 

                  Введение

 

 

  Телекоммуникационные технологии в последние годы переживают масштабные перемены, связанные с интеграцией сетей и услуг связи. Появляются новые сервисы, традиционные сервисы и услуги переходят на платформу  IP, количество потребителей таких сервисов растет  очень высокими темпами. Именно  появление новых инфокоммуникационных услуг и сервисов вызвало бурное развитие     технологий, в которых на первое место  встают вопросы качества предоставления услуг. Главным требованием, предъявляемым к сетям, является выполнение их основной функции  – обеспечение пользователям потенциальной возможности     доступа к разделяемым ресурсам сети. Все остальные требования связаны с качеством выполнения основной задачи. Для разных логических типов сетей приоритетными характеристиками являются: производительность, надежность, совместимость,  управляемость, защищенность, расширяемость, масштабируемость и их совокупность.

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

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

Вопросами оценки  производительности занимается большое количество ученых многих стран: такие как  Клейнрок Л., Феррари Д., Вишневский В.М., Цыбаков В.И. и      многие др. Производительность сети является основополагающим свойством для самой возможности интеграции сервисов и повышения качества их предоставления.   Однако методам оценки именно показателей производительности интегрированных          сетей как основной задачи уделяется недостаточное внимание.  

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

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

 

 

 

 

 

 

1 Исследовательский раздел

 

1.1 Проблемы вычислительных сетей

 

 

В настоящее время в использовании локальных вычислительных сетей(ЛВС) можно отметить две тенденции: создание мощных корпоративных сетей и переход на технологию клиент-сервер [3].

Корпоративные ЛВС  характеризуются многосегментной структурой, большим числом рабочих станций (РС), наличием нескольких серверов (файловых, баз данных, печати, модемов), маршрутизаторов, мостов и т.п. Эффективное использование технологии клиент-сервер в таких сетях ставит ряд сложных задач перед администраторами и пользователями ЛВС. Важнейший комплекс задач обеспечение требуемой производительности, пропускной способности сети и планирование ее мощностих [1].

Типичная корпоративная сеть  представлена на рисунке 1.1. 

 

Рисунок 1.1 - Типичная сетевая топология предприятия

 

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

Производительность и пропускная способность ЛВС определяется рядом

 

факторов: выбором серверов и рабочих станций, сетевого оборудования, операционных систем рабочих станций, серверов и их конфигураций, распределением файлов базы данных по серверам сети, организацией распределенного вычислительного процесса, защиты, поддержания и восстановления работоспособности в ситуациях сбоев и отказов и т.п. Максимальные возможности корпоративной ЛВС для конкретных приложений (банковская, офисная, проектно-конструкторская, управленческая деятельность и др.) могут быть достигнуты только на основе комплексного подхода к оптимизации ЛВС на всех этапах жизненного цикла (от технико-экономического обоснования и технического задания на разработку до эксплуатации и модернизации) .

Для решения задач оптимизации производительности и пропускной способности ЛВС используются методы и средства измерения (анализа) и моделирования. Особенности трафика ЛВС делают моделирование сетей более трудным, чем моделирование систем с главной машиной. В ЛВС трафик может сильно варьироваться, что определяется природой распределенной обработки. Так как такая обработка выполняется и клиентом, и сервером, есть много способов распределения обработки информации между ними, но в первую очередь необходимо знать о производительности самих приложений и влиянии приложений на общую производительность и пропускную способность сети.

Как правило, средства моделирования позволяют определить производительность и пропускную способность ЛВС на основе показателей ее фактического оцениваемого трафика, указываемых администратором сети. Многие пакеты моделирования могут воспринимать данные и от инструментальных средств анализа сети (сетевых анализаторов), таких, например, как анализатор протокола Sniffer фирмы Network General. Для крупномасштабных моделей такая возможность имеет важное значение, поскольку в этом случае отпадает необходимость во вводе в моделирующую программу множеств данных. Установив в сети программные измерительные средства и уяснив картину полного сетевого трафика, можно использовать и данные с помощью продуктов административного управления сетью, таких, как Sun Net Manager фирмы Sun Microsystem и Open View фирмы Hewlett Packard [8].

Другим подходом к моделированию является создание вариантов «сценариев» работы ЛВС, что позволяет программировать уровень трафика на основе действий сетевых приложений.

Средства моделирования обычно включают модули, эмулирующие все сетевые устройства. Например, пакет PlanNet фирмы Comdisco позволяет моделировать все оборудование ЛВС Token Ring  [17] и Ethernet  [10] вплоть до средств передачи речевых данных и телекоммуникаций.

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

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

 

Следует иметь в виду, что для решения задач оптимизации ЛВС необходимы точные исходные данные (например, получаемые от сетевого анализатора), правильная оценка роста трафика, генерируемого новым сетевым приложением, а также понимание возможности программы (пакета) моделирования и какие из «сценариев» жизнеспособны.

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

 

 

1.2 Корпоративная сеть передачи данных

 

 

Корпоративная сеть передачи данных – это система, обеспечивающая передачу информации между различными приложениями, используемыми в системе предприятиях[10].

Цель построения корпоративных сетей передачи данных (КСПД) – обеспечение транспорта для территориально распределенных бизнес-приложений. К таким приложениям обычно относят:

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

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

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

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

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

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

• модуль внешних сервисов;
• модуль WAN;
• модуль ЛВС.

 

 

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

 

Ключевым компонентом, связующим узлы КСПД, является услуга связи, которая обеспечивает передачу трафика между узлами. Виды услуг связи, используемые при организации каналов между узлами, делятся на следующие группы [23]:

• выделенные линии связи – оптические или медные кабеля соединяющие узлы сети заказчика (это могут быть как свои, так и арендуемые линии связи);
• выделенные каналы данных – каналы данных предоставляемые оператором связи по верх своей сети передачи данных:
• Frame Relay (PVC);
• ATM (PVC);
• E1/E3/STM-1;
• Ethernet VLAN;
• услуги по соединению на базе «группового» доступа:
• IP VPN;
• VPLS – Virtual Private LAN Service. Технология позволяет эмулировать распределенную ЛВС по верх сети Оператора;
• сеть Интернет.

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

Рисунок 1.3 -  Узлы системы передачи данных

 

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

Узлы системы передачи данных можно классифицировать в три группы [10]:

• центральный узел;
• отделение/крупный узел;
• конечный узел.

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

Отделение/крупные узлы – «основная масса» сети. Здесь размещаются информационные ресурсы, имеющие только локальное значение и предоставляющие сервисы только локально - абонентам данного узла.

Конечный узел – данный тип узла является самым маломощным. В его составе нет никаких информационных ресурсов и серверов приложений. Данные узлы предназначены только для подключения пользователей.

Для образования подсистемы WAN (Wide-Area Network) [10] всех типов узлов предлагается использовать оборудование компании Cisco Systems – маршрутизаторы с интеграцией сервисов, которые обеспечивают решение задач:

• традиционных для маршрутизатора – передача IP трафика и обеспечение связности по протоколу IP
• обеспечения безопасности:
• межсетевое экранирование и обнаружение атак – защита от возможных сетевых атак злоумышленника, нацеленных на перебой штатного функционирования сети;
• шифрование данных – обеспечение конфиденциальности передаваемой по сети информации;
• контроль целостности данных – обеспечение невозможности манипуляции данными при передаче через сеть.
• бесперебойного функционирования приложений IP телефонии:
• маршрутизация вызовов;
• голосовая почта;
• стыковка с традиционной телефонией.

При построении ЛВС узлов предлагается использовать следующие принципы в зависимости от типа узла КСПД и количества пользователей.

 

Таблица 1.1- Архитектура ЛВС в зависимости от класса узла и количества абонентов

Класс узла	Кол-во абонентов	Архитектура построения
SOHO	до 48	SOHO ЛВС: –        строится на базе одного устройства; –        возможно совмещение маршрутизатора и коммутатора в одном устройстве; –  созможно построение только на базе беспроводной связи
Отделение	до 300	Традиционная ЛВС: –    в большинстве случаев ЛВС может быть построена на базе «плоской» архитектуры; при построении обычно используют наиболее «слабые» или «средние» коммутаторы
Центральный офис	не ограничено	«Кампусная» ЛВС

 

1.3 Классификация параметров, характеризующих работу сети

 

 

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

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

Основные характеристики производительности сети [12]:

• время реакции;
• скорость передачи трафика;
• пропускная способность;
• задержка передачи и вариация задержки передачи.

 

 

1.3.1 Время реакции

 

 

Обычно в качестве временной характеристики производительности сети используется такой показатель как время реакции. Термин «время реакции» может использоваться в очень широком смысле, поэтому в каждом конкретном случае необходимо уточнить, что понимается под этим термином.

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

Время реакции [7] сети имеет несколько составляющих. В общем случае в него входит:

• время подготовки запросов на клиентском компьютере;
• время обработки запросов на сервере;
• время передачи ответов от сервера.

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

Рисунок 1.4  -  Время реакции - интервал между запросом и ответом

 

Можно было бы выделить еще более мелкие этапы выполнения запроса, например, время обработки запроса каждым из протоколов стека TCP/IP на сервере и клиенте.

 

 

1.3.2 Скорость передачи трафика

 

 

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

Скорость передачи трафика может быть мгновенной,  максимальной

и средней.

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

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

Максимальная скорость — это наибольшая скорость, зафиксированная в течение периода наблюдения.

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

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

 

 

1.3.3 Пропускная способность

 

 

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

Существует большое количество вариантов определения критериев этого вида, точно также, как и в случае критериев класса «время реакции». Эти варианты могут отличаться друг от друга: выбранной единицей измерения количества передаваемой информации, характером учитываемых данных - только пользовательские или же пользовательские вместе со служебными, количеством

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

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

Так как вычислительные сети работают по принципу коммутации пакетов (или кадров), то измерение количества переданной информации в пакетах имеет смысл, тем более что пропускная способность коммуникационного оборудования, работающего на канальном уровне и выше, также чаще всего измеряется в пакетах в секунду. Однако, из-за переменного размера пакета, измерение пропускной способности в пакетах в секунду связано с некоторой неопределенностью - пакеты какого протокола и какого размера имеются в виду. Чаще всего подразумевают пакеты протокола Ethernet, как самого распространенного, имеющие минимальный для протокола размер в 64 байта. Пакеты минимальной длины выбраны в качестве эталонных из-за того, что они создают для коммуникационного оборудования наиболее тяжелый режим работы - вычислительные операции, производимые с каждым пришедшим пакетом, в очень слабой степени зависят от его размера, поэтому на единицу переносимой информации обработка пакета минимальной длины требует выполнения гораздо больше операций, чем для пакета максимальной длины.

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

Критерии, отличающиеся учетом служебной информации. В любом протоколе имеется заголовок, переносящий служебную информацию, и поле данных, в котором переносится информация, считающаяся для данного протокола пользовательской. Например, в кадре протокола Ethernet минимального размера 46 байт (из 64) представляют собой поле данных, а оставшиеся 18 являются

служебной информацией. При измерении пропускной способности в пакетах в

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

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

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

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

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

1.3.4 Задержка передачи и вариация задержки передачи

 

 

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

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

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

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

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

 

Рисунок 1.5 - Задержки при передаче данных

 

значительному снижению качества предоставляемой пользователю информации — возникновению эффекта «эха», невозможности разобрать некоторые слова, вибрации изображения и т. п.

Все указанные характеристики производительности сети достаточно независимы. В то время как пропускная способность сети является постоянной величиной, скорость передачи трафика может варьироваться в зависимости от загрузки сети, не превышая, конечно, предела, устанавливаемого пропускной способностью. Так в односегментной сети 10 Мбит/с Ethernet компьютеры могут обмениваться данными со скоростями 2 Мбит/с и 4 Мбит/с, но никогда — 12 Мбит/с.

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

весьма высокой, например 2 Мбит/с, в то время как задержка передачи всегда составляет не менее 0,24 с, что определяется скоростью распространения электрического сигнала (около 300000 км/с) и длиной канала (72000 км).

 

 

1.4 Аппаратно-программные средства анализа  корпоративной сети

 

 

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

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

Аппаратное средство OptiView Series III [4] захвата/анализа пакетов в реальном времени, а также отображения уведомлений и показателей QoS.

 

Рисунок 1.6 - OptiView Series III

 

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

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

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

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

команд, он приступает к обнаружению устройств с помощью мониторинга трафика и активного опроса хостов.

 

 

Рисунок 1.7 -  Основное окно OptiView Series III

 

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

Анализатор классифицирует устройства по одной из следующих категорий: активное сетевое оборудование (маршрутизаторы, коммутаторы, концентраторы, SNMP и точки доступа), серверы, принтеры, агенты SNMP и другие хосты. Кроме того, сети классифицируются по подсетям IP, виртуальным локальным сетям (VLAN), доменам NetBIOS и сетям IPX, с указанием принадлежности пользователей к каждой из указанных категорий. Также анализатор позволяет выявить сетевые.  Обнаружение устройств устройства, которые имеют определенные проблемы. Например, анализатор позволяет определить: дублирование IP-адресов, неправильные маски подсети, не отвечающие (не существующие) маршрутизаторы по умолчанию и многое другое.

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

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

Simple Network Management Protocol (SNMP) - используется для сбора информации (или конфигурирования) с сетевых устройств.

Основные функции:

–программные «агенты» на управляемых устройствах собирают

информацию, которая хранится в базе данных;

– управляющее ПО опрашивает агентов используя SNMP команды (такие как «GET» или «GET NEXT») для сбора информации об устройстве или трафике, проходящем через него.

На данный момент существует 3 версии SNMP:

 

 

Рисунок 1.8 - Трендинг данных, собранных по SNMP

 

SNMP Version 1  версия SNMP, созданная для обеспечения сбора cтатистических данных с устройства и отчета об ошибках, без использования дополнительных системных ресурсов. Защита ограничена Community String и контролем доступа на базе IP адресов. Обмен данными не шифруется.

SNMP Version 2 часто называемый v2c – это вторая версия протокола SNMP , которая имеет расширенное число поддерживаемых кодов ошибок, и улучшенным механизмом запросов, позволяющим более эффективно выгружать данные. SNMP v2c имеет полную обратную совместимость с SNMP первой версии.

SNMP Version 3 эта версия обеспечивает большую защищенность и

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

доступа не ограничивается community string «только для чтения» и «для чтения/записи». Существуют логины и пароли, которые можно настраивать. Поддерживается шифрование передаваемых SNMP данных.

NetFlow Tracker – программное решение для сбора и анализа NetFlow информации, предоставляемой оборудованием Cisco. Программное обеспечение

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

отчеты о сетевом трафике как в реальном масштабе времени (до 14 дней), так и за любой период времени (до 999 лет) с различным уровнем детализации от 1 минуты.

 

Рисунок 1.9 - Трендинг данных, собранных по NetFlow

 

Ниже описаны задачи решаемые с использованием  NetFlow Tracker.

Мониторинг сети — NetFlow Tracker позволяет осуществлять всесторонний мониторинг сети практически в реальном масштабе времени (за последнюю минуту). Анализ трафика, основанный на контроле за каждым потоком данных (flow) позволяет визуализировать существующую модель трафика для каждого подключенного к сети маршрутизатора или коммутатора для обеспечения эффективного поиска, быстрой идентификации и своевременного устранения проблем.

Мониторинг и профилирование приложений – NetFlow Tracker позволяет ИТ специалистам получить детальную информацию по приложениям, которые передаются в сети за любой период времени. Данная информация полезна для планирования внедрения новых приложения и сервисов, для оценки правильности внесенных изменений в конфигурацию сети или активного сетевого оборудования, а также для оценки использования имеющихся ресурсов

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

Мониторинг и профилирование пользователей – NetFlow Tracker позволяет оценить и понять, как пользователи используют сеть и сетевые

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

Планирование развития сети – NetFlow Tracker позволяет аккумулировать данные за большой период времени (от 1 минуты до 999 лет), предоставляя возможность планировать развитие сети и модернизацию сети или обновление ее отдельных элементов (переход на высокоскоростные модели коммутаторов, маршрутизаторов, полосы пропускания). С помощью NetFlow Tracker мы можем выявить нежелательный трафик в WAN каналах, убедиться, что доступная полоса пропускания используется должным образом с требуемыми настройками QoS. Программное обеспечение NetFlow Tracker позволит минимизировать затраты на обслуживание сети и максимизировать ее производительность и надежность. NetFlow Tracker предоставит ценную информацию, которая позволяет снизить операционные издержки на обслуживание и поддержание сети.

Анализ системы безопасности  — NetFlow Tracker позволяет идентифицировать и классифицировать DDOS атаки, вирусы и черви в реальном времени. Анализ NetFlow информации позволяет выявить необычную сетевую активность и аномалии.

 

 

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

 

 

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

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

Для моделирования сетей передачи данных существует множество разнообразных решений от ведущих производителей, таких как Opnet, MathSoft,

Comdisco, HP, IBM и многих других.

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

 

Таблица 1.2 - Основные решения для моделирования сетей

Компания и продукт	Описание
CACI Product, COMNET III	Позволяет моделировать уровни: приложений, транспортный, сетевой, канальный. Использует все известные на сегодня технологии и протоколы, а также системы клиент-сервер.
Make System, Netmaker	Проектирование топологии, средства планирования и анализа сетей широкого класса. Состоит из различных модулей для расчета, анализа, проектирования, визуализации, планирования и анализа результатов
Network Analysis Center, MIND	Средство проектирования, оптимизации сети, содержит данные о стоимости типичных конфигураций с возможностью точного оценивания производительности
Network Design and Analysis Group, AutoNet/ MeshNET	Моделирование полосы пропускания и оптимизация расходов на организацию ГС путем имитации поврежденных линий
Network Design and Analysis Group, AutoNet/ Performance-3	Моделирование производительности многопротокольных объединений локальных и глобальных сетей; оценивание задержек в очередях
Network Design and Analysis Group, AutoNet/ Designer	Определение оптимального расположения концентратора в ГС, возможность оценки экономии средств за счет снижения тарифной платы, смены поставщика услуг и обновления оборудования

1.6 Постановка задачи

 

 

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

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

 

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

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

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

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

Требования к составу и параметрам технических средств:

• процессор Pentium 4-2500 MHz и выше;
• объем оперативной памяти 1024 Mb и выше;
• 100 Mb свободного места на жестком диске;
• доступ в локальной сети.

Требования к информационной и программной совместимости:

• Windows 98/ME/2000/2003 Server/XP/7;
• Microsoft Office (рекомендуется Microsoft Office 2003).

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

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

 

2 Разработка программной системы

 

2.1 Разработка архитектуры программной системы

 

 

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

 

 

Рисунок 2.1 – Архитектура  ПС

Спецификация модулей показана в таблице 2.1.

 

Таблица 2.1  – Спецификация модулей программы

Название	Исходные данные	Выполняемые задачи
1	2	3
Модуль подключения к базе данных	Имя пользователя и пароль для подключения к базе данных	Обеспечивает  соединение с сервером баз данных, выполнение запросов SQL и получение результатов
Модуль сбора информации о трафике	Список сенсоров	С каждой единицы оборудования последовательно происходит получение данных о трафике по конкретным портам устройств
Модуль считывание из БД	Путь к каталогу с базами данных системы мониторинга сети	Считывание необходимого количества статистических данных из базы данных
Модуль считывание из файла	Путь к каталогу с файлам системы мониторинга сети	Считывание необходимого количества статистических данных из файла
Модуль анализа баз данных статистики	Количество анализируемых отсчетов трафика	Анализ полученных данных с использованием выбранного критерия и определение топологии сети
Модуль построения карты сети	Текстовый файл, описывающий топологию сети	Считывание данных из файла с описанием топологии сети, разбор формата и визуализация в графическом виде

 

Продолжение таблицы 2.1

1	2	3
Модуль сохранения результатов	Сохранение результатов работы в удобном формате, который может быть интерпретирован любой другой программой с целью визуализации или дальнейшего анализа	Все данные заносятся в базу данных в таблицы промежуточных измерений

 

 

 

2.2 Реализация функционального назначения программной системы

 

 

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

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

Ввод информации возможен с нескольких видов внешних сенсоров и с внутренних сенсоров (SNMP, Sniffing). Анализ размера пакетов, типа трафика, протоколов. Результат заносится в базу банных и отображается на дисплее.

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

На основе шагов 1 и 2 расчет характеристик хостов – участников  трафика, а также расчет основных характеристик производительности всей сети в целом.

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

На основе расчета шага 3 распознаются узкие места сети (каналы, узлы) и делается рекомендация по модернизации участка сети.

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

Листинг основного модуля расчета характеристик функционирования модели сети приведен в приложении A.

 

 

Рисунок  2.2 – Функциональная схема программы

 

 

2.3 Обоснование выбора инструментальных средств разработки

 

 

Для разработки программного средства были выбраны следующие  средства:

• Python;
• NumPy;
• Matplotlib;
• MySQL Server

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

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

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

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

В составе Python поставляется большое число собранных и переносимых функциональных возможностей, известных как стандартная библиотека. Эта библиотека предоставляет массу возможностей, востребованных в прикладных программах, начиная от поиска текста по шаблону и заканчивая сетевыми функциями. Кроме того, Python допускает расширение как за счет ваших собственных библиотек, так и за счет библиотек, созданных сторонними разработчиками. Из числа сторонних разработок можно назвать инструменты создания веб-сайтов, программирование математических вычислений, доступ к последовательному порту, разработку игровых программ и многое другое. Например, расширение NumPy позиционируется как свободный и более мощный эквивалент системы программирования математических вычислений Mathlab.

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

возможностей программных продуктов. На сегодняшний день программный код на языке Python имеет возможность вызывать функции из библиотек на языке C/C++, сам вызываться из программ, написанных на языке C/C++, интегрироваться с программными компонентами на языке Java, взаимодействовать с такими платформами, как СОМ и .NET, и производить обмен данными через последовательный порт или по сети с помощью таких протоколов, как SOAP, XML-RPC и CORBA. Python - не обособленный инструмент.

NumPy- это расширение языка Python, добавляющее поддержку больших многомерных массивов и матриц, вместе с большой библиотекой высокоуровневых математических функций для операций с этими массивами. NumPy можно рассматривать как хорошую свободную альтернативу MATLAB, поскольку язык программирования MATLAB внешне напоминает NumPy: оба они интерпретируемые, и оба позволяют пользователям писать быстрые программы пока большинство операций производятся над массивами или матрицами, а не над скалярами. Преимущество MATLAB в большом количестве доступных дополнительных тулбоксов, включая такие как пакет Simulink. Основные пакеты, дополняющие NumPy, SciPy — библиотека, добавляющая больше MATLAB-подобной функциональности.

Matplotlib - библиотека языка программирования Python и его расширения NumPy, предназначенная для визуализации данных.

СУБД My SQL Server - одна из наиболее мощных СУБД архитектуры клиент - сервер. Он не предназначен непосредственно для разработки пользовательских приложений, а выполняет функции управления базой данных. My SQL Server может работать с информацией в БД иных форматов включая Oracle, BM DB2, Sybase, Microsoft Access и другие СУБД (при наличии ODBC драйвера, отвечающего определенным требованиям), что недоступно другим СУБД. My SQL Server - это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В сервер My SQL Server включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Кроме того, My SQL Server полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.

 К основным преимуществам My SQL Server с точки зрения рассматриваемой предметной области, можно выделить:

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

В My SQL Server 4 в полном объеме используются преимущества многозадачности и параллельной обработки данных, такие как надежная работа с разделяемыми на уровне пользователей или приложений базами данных, разделение потока данных между серверами, параллельное создание индексов, ускорение сканирования баз данных в многопроцессорных системах, а также синхронизирует данные на всех серверах в кластере независимо от их местонахождения.

Продукт переустанавливает и восстанавливает любую ветвь при сбое в кластере, не затрагивая остальные, легко конфигурируется для репликации и распределения потоков, обладает встроенной технологией клонирования серверов. My SQL Server 2000 позволяет анализировать собираемые реляционные и OLAP данные, включая входные потоки и историю обращений, чтобы понять тренды и сформировать прогнозы, выполняет анализ больших объемов данных (10М+ записей), за счет связанного хранения. При этом продукт оставляет сервер доступным для других задач при обновлении индексов, поддерживает быстрое архивирование с небольшими затратами системных ресурсов, архивируя только измененные элементы, позволяет перемещать и копировать базы данных и объекты между серверами, используя специальные мастера.

В My SQL Enterprise Edition есть возможность регулярно копировать журнал транзакций и восстанавливать его на другом сервере. Это позволяет, во-первых, при отказе основного сервера использовать резервный сервер, а во-вторых, перенести на другие сервера нагрузку, связанную с запросами на чтение.

Немаловажной чертой для предприятия выбирающего то или иное СУБД является стоимость. Здесь необходимо учесть стоимость не только самой СУБД но и её требования к аппаратному обеспечению.

На основе выше приведенных преимуществ My SQL Server и специфики разрабатываемой системы, было принято решение использовать именно My SQL Server в качестве СУБД.

2.4 Разработка алгоритма сбора информации  о трафике

 

 

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

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

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

По технологии ARP poisoning based sniffing происходит отделение маршрутизаторов, коммутаторов и брандмауэров от остальных узлов.

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

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

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

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

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

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

В случае наличия информации о связях в сети (например по протоколу CDP) эти данные добавляются к топологии. Также возможно ручное указание связей.

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

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

Данные о трафике на одном интерфейсе, полученные из разных сенсоров сравниваются, и, в случае расхождения более чем в 5% происходит выбор только 1 источника, по заданными приоритетам типов сенсоров. Результат сохраняется в базу данных.

В случае наличия информации по протоколам, поставляющим данные об адресах и номерах портов (netflow, sflow, netgraph) [5] сразу проводится предварительная идентификация потоков и результаты записываются в базу данных.

На основании объема полученных данных за один промежуток времени делается вывод об увеличении или уменьшении промежутка. Проверка значимости производится по критерию Стьюдента.

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

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

Проводится идентификация отдельных потоков трафика и их поиск на разных сенсорах.

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

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

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

В каждом декомпозированном сегменте строится маршрутная матрица по результатам идентификации потоков для каждого вида трафика.

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

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

Решением уравнений баланса потоков уточняются характеристики сетевой модели.

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

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

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

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

 

Рисунок 2.3 -  Алгоритм сбора информации

 

2.5 Методика построения маршрутной матрицы

 

 

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

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

Если сеть построена с уменьшенной структуризацией, то есть основная часть сети расположена в зоне около четырех-пяти подсетей, то данные маршрутизаторов будут полезны только для анализа трафика между подсетями, тогда как при такой логической топологии трафик, скорее всего, будет распределен по правилу 80/20, то есть 80% внутри сегмента, и только 20% наружу сегмента [9]. Таких сетей в области малых и средних организаций подавляющее большинство.

В этом случае основной инструмент для сбора статистики — Simple Тetwork Management Protocol (SNMP) счетчики коммутаторов сегмента. SNMP системы часто дают ошибочную информацию о производительности, т.к. они полагаются на данные полученные от программных агентов, а не на анализ реального трафика приложения. Если сеть построена на оборудовании нескольких фирм (в большинстве случаев), видов счетчиков два: количество пакетов в секунду за период наблюдения на интерфейсе (кол-во/с) и количество бант (бит) в секунду за период наблюдения на интерфейсе (bandwith).

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

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

Так как большинство сетей строится по физической топологии «расширенная звезда», сеть имеет древовидную структуру. Вследствие этого внешний график коммутатора легко отследить по определенным портам.

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

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

Рисунок 2.4– Простейший пример зависимости трафика на портах

 

Например, исходящий трафик порта 8 коммутатора 1 будет в точности совпадать, с входящим трафиком порта 5 центрального коммутатора. Учитывая это, возможно заменить сеть коммутаторов эквивалентным единым коммутатором с уже известными связями внутри себя (рисунок 2.6).                                                                                                                                                                                

 

Рисунок 2.5 – Пилотная сеть

 

 

Рисунок 2.6 – Схема  потока трафика точка-точка

 

Если трафик идет от компьютера РС1 на сервер Serverl, то при отсутствие посторонних трафиков выборки, опять будут совпадать в той или иной мере, в зависимости от межконцевых задержек [6]. Оценить степень совпадения можно, рассчитав коэффициент корреляции между входящим трафиком порта 1 нового виртуального коммутатора и исходящим трафиком порта 26. При этом поток затронет порты 8 и 26, так как они связаны кабелем напрямую, но, учитывая это, при поиске ушедшего трафика они не используются.

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

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

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

Например, возьмем два графика трафиков на портах 1 и 26 за сутки представлен на рисунке 2.7.

Коэффициент корреляции равен 0,437, то есть весьма низок. К тому же на других портах наблюдаются большие шумы, которые тоже отразились на остальных коэффициентах корреляции представлен на рисуноке 2.8.

 

Рисунок 2.7- График входящего трафика 1 порта и исходящего 26

 

 

Рисунок 2.8 – Матрица корреляции для портов 1, 25 и 26

 

Корреляция для элемента corr_ij определяется как корреляция входящего трафика i-ого элемента и исходящего трафика j-ого элемента. По диагонали -корреляции входящего и исходящего трафиков для одного порта. Она обычно очень высока вследствие пропорциональности работы протокола TCP.  На рисунке 13 показаны графики для портов 8 и 26.

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

Возьмем один из интервалов активного поведения трафика - от 1100 до 1200 с коэффициент корреляции входящего трафика порта 1 и исходящего порта 26 ранен 0,918 представлен на рисунке 2.9.

 

Рисунок 2.9-  График на портах  8 и 26 и матрица корреляции для

портов 1, 25, 26

 

Возьмем следующий интервал 1300- 1500с для этих же портов представлен на рисунке 2.12. Как видно, характер трафика стал совершенно другим - коэффициент корреляции равен 0,56, наблюдается аномальный скачок в исходящем трафике 26 порта. Следовательно, в этот интервал времени можно найти источник этого скачка, с высокой вероятностью. Главное, таким образом можно определить, что в данный порт этот скачок трафика не пришел. По пути от обратного можно также найти порт с таким же скачком. Если такого скачка не наблюдается на других портах, значит, это был мгновенный распределенный запрос с нескольких машин, и отследить его практически невозможно. Такие моменты, как кратковременный скачок трафика, являются нестационарным поведением сети, и статистическими методами построить в таких режимах маршрутную матрицу не представляется возможным.

После отсева незначительных коэффициентов, а также приравнивания к 0 элементов главной диагонали (коммутатор никогда не пошлет пакет в тот интерфейс, откуда он пришел), получаем следующую матрицу корреляции для  интервалов 1100-1200 представлен на рисунке 2.11:

 

 

Рисунок 2.10 – График на портах 8 и 26 на следующем интервале и матрица корреляции для портов 1, 25, 26

 

 

 

Рисунок 2.11- Матрица корреляции для портов 1, 25, 26 после удаления незначимых и недостоверных результатов

 

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

При исследование всех интервалов наблюдаются закономерности в поведение коэффициентов корреляции представлен на рисунке 2.12.

                     Рисунок 2.12 – Поведения коэффициента корреляции входящего трафика 1 порта и исходящего трафика 26 порта в зависимости от номера исследуемого интервала

 

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

На рисунке 2.13 покачаны коэффициенты корреляции обратного трафика для портов 1 и 26.

Рисунок 2.13 – Поведения коэффициента корреляции входящего трафика 1 порта и исходящего трафика 26 порта в зависимости от номера исследуемого интервала

 

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

Рисунок 2.14 – Разность коэффициентов корреляции прямого и обратного    трафиков портов 1 и 26 в зависимости от номера исследуемого интервала

 

В каждом интервале (временном срезе) будет своя маршрутная матрица. Чем меньше длина среза, тем более точной должна быть маршрутная матрица, но минимальная величина среза - не менее 100 значений данных о трафике. При таком размере можно определять значимость коэффициентов и отбраковывать аномальные измерения.

 

 

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

 

 

Имея данные о среднем количестве пакетов в секунду за период времени (на входе и выходе интерфейса) и объем трафика за тот же период легко перейти к необходимой в моделирование величине средний период времени между пакетами (и ее дисперсии). Для этого от количества пакетов N переходим к длине интервала времени между пакетами  для каждого временного среза

 

(1)

где - время наблюдения.

Дисперсия вычисляется аналогичным образом:

 

(2)

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

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

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

Стационарные вероятности P(n):

 

(3)

где - нормализирующая константа

- коэффициент передачи общей интенсивности в i-ый узел

- интенсивность обслуживания i-ого узла.

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

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

Матрица с временными срезами трафика:

 

 

 

                                                                                                               (4)

 

                                                                                                

                                                                                                             (5)

 

 

где ingress_traf- входящий трафик в порт i;

     outgress_traf- исходящий трафик из порт i.         

Нормирование исходных значений переменных по формуле:

 

 

                                                                                                              (6)

 

 

где  - среднее значение по j столбцу; 

                        - среднее квадратическое отклонение по j столбцу;

                 -значение элемента матрицы на i строке и j столбце.

Построение матрицы корреляции для всех портов

 

 

 

 

                                                                                                              (7)

Коэффициент корреляции Пирсона определяется как:

 

 

 

                                                                                                             (8)

 

где  -ковариация   случайного вектора (Х, Y);

  MX– математическое ожидание случайной    величины X;

 DX - дисперсия случайной величины X.

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

Решением системы уравнений равновесия потоков относительно интенсивностей   потоков на входе и выходе каждой СМО [5] сети (9) определяем средние значения интервалов времен между соседними заявками  для каждого потока в сети

                                          (i=1,..., n; λ_0i=)                          (9)

где  - интенсивность потока извне в i-й узел.

 

 

 

 

 

 

 

 

 

 

 

 

 

         Для удобства применения систему уравнений (10) приводят к каноническому виду с вводом нулевого узла для внешнего источника заявок. Тогда система уравнений примет следующий вид:

                                                              (10)

 

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

Пусть мы имеем точку композиции потоков точка A на рисунке 2.16, где сходятся два независимых потока заявок с параметрами:  (i=1,2) – среднее время между соседними заявками в потоке i,  - дисперсия этого же времени. Тогда среднее значение и дисперсия времени в суммарном потоке

 

                                                                                     (11)

                                

                                   .                            (12)

 

 

Рисунок 2.16 - Мультиплексирование потоков

 

Пусть N(t) означает число событий в потоке за время t. Тогда среднее N(t):, где  - среднее время между событиями в потоке N(t). Так как дисперсия числа событий N(t): , то для суммы двух независимых потоков  справедливы равенства: - для среднего времени между соседними событиями в суммарном потоке и -  для дисперсии того же времени. Эти результаты получены при непрерывном приближении потока при больших значениях t.

Из последних равенств уже следует справедливость выражений (11) и (12).

Формулы (11) и (12) фактически являются математической моделью операции мультиплексирования (агрегирования) потоков.

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

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

 

                                                        ,                                                (13)

 

где  - среднее время обслуживания.                                                       

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

В общем случае ρ - ма­тематическое ожидание доли используемой пропускной способности системы.

В любом случае стабильной системой (т. е. такой системой, которая имеет конечные средние задержки и длины очередей) является система, для ко­торой 0≤ρ<1. Чем ближе значение ρ к единице, тем больше очереди и время ожидания; именно в этой величине наиболее существенно отражается изме­нение характеристик СМО при изме­нении средней нагрузки.

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

 

                                                                                                (14) 

 

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

 

                                                                                                        (15)

 

где  — средняя длина очереди.

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

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

значения.

• источники задержек и узких мест сети.

Общая укрупненная схема алгоритма работы программной системы показана на рисунке 2.17.

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

 

 

Рисунок 2.17– Схема  алгоритма программы

2.7 Проектирование базы данных

 

2.7.1 Выбор метода проектирования БД 

 

 

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

В настоящий момент существует ручной способ проектирования и проектирование с помощью CASE средств (Computer Aided Software Engineering).

Существуют ряд методов разработки модели БД [20]:

• восходящий метод РБД на основе нормализации схем отношений;
• метод нисходящего проектирования;
• на основе UML;
• проектирование методом Буча [10].

Из представленного выше списка, был выбран метод нисходящего проектирования  с использованием приложения AllFusion ErWin Data Modeler. Так как нисходящий метод является на сегодняшний день наиболее популярным и рациональным, то использование данного метода предпочтительнее. При «нисходящем» проектировании осуществляется структурное проектирование сверху—вниз. 
             Такое проектирование называют анализом – происходит изучение целого (описания предметной области), затем разделение целого на составные части и затем следует последовательное изучение этих частей. Нисходящий метод  более удобен, быстр, нагляден и, что самое главное, проще, чем  восходящий метод. Выше перечисленные преимущества и повлияли на выбор используемого метода проектирования.

 

 

2.7.2 Информационно - логическая модель предметной области

 

 

Прежде, чем приступать к созданию программной системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model). Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом [7]. В дальнейшем данное направление  моделирования развивалось в разных направлениях. Одним из результатов развития данного направления стало появление ER-диаграмм Ричарда Баркера. Проектирование логической модели БД целесообразно проводить с помощью ER-диаграммы предложенной Ричардом Баркером представлена на рисунке 2.18.

Рисунок 2.18 – Уровни создания модели данных

 

IE обеспечивает инфраструктуру поддержки требований к информации путем интеграции корпоративного стратегического планирования с разрабатываемыми информационными системами. Подобная интеграция позволяет более тесно увязать управление информационными ресурсами с долговременными стратегическими перспективами корпорации. Инфологическая модель предметной области, решаемой задачи, представлена в виде ER-диаграммы на рисунке 2.19.

Рисунок 2.19  – Инфологическая схема БД

Связи между объектами и их свойства представлены в таблице 2.2.

 

Таблица 2.2- Связи между объектами

Объект		Мощность		Опциональность
Главный	Подчиненный	Главный	Подчиненный	Главный	Подчиненный
Сенсор	Имя хоста	1	М	М.Б.	Д.Б.
	Интерфейс	1	М	М.Б.	Д.Б.
Объект	Имя	1	М	М.Б.	Д.Б.
	Тип	1	М	М.Б.	Д.Б.
Маршртная матрица	Размер	1	М	М.Б.	Д.Б.
	Примечание	1	М	М.Б.	Д.Б.
	Срез	1	М	М.Б.	Д.Б.
Протокол	Протокол	1	М	М.Б.	Д.Б.
Временной срез	Сигнатура	1	М	М.Б.	Д.Б.
	Время	1	М	М.Б.	Д.Б.
	Объект	1	М	М.Б.	Д.Б.
Привяза объекта	Номер элемента	1	М	М.Б.	Д.Б.
	Примечание	1	М	М.Б.	Д.Б.
Элемент матрицы	Значение	1	М	М.Б.	Д.Б.
Статистика         и-ка	Время	1	М	М.Б.	Д.Б.
	Всего байт	1	М	М.Б.	Д.Б.
Данные	Данные	1	М	М.Б.	Д.Б.

 

 

2.7.3       Даталогическая модель БД

 

 

Основная задача даталогической модели (ДЛМ) - получение структуры данных, описанной на языке конкретной математической модели, ориентированной на выбранную СУБД.

При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, а также с учетом специфики конкретной предметной области на ос­нове ее инфологической модели. Для конкретной реализации даталогической модели проектируется физическая модель, ото­бражающая первую на конкретные программные и аппаратные средства [9] (ОС, внешняя память, работа с данными на физическом уровне и т.д.). Наполненная конкретной информацией физическая модель и, составляет, собственно БД. Система, обеспечивающая со­ответствующее совместное функционирование указанных компонент, и составляет суть конкретной СУБД.

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

1) правила организации структуры данных;

2) правила манипулирования данными;

3) ограничения модели.

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

Технология получения ДЛМ РБД на основе ER-диаграммы:

• класс объектов становится отношением, таблицей;
• свойство становится атрибутом, полем, столбцом;
• опциональность свойства становится опциональностью атрибута;
• уникальный идентификатор, первичный ключ становится первичным ключем;
• связь становится внешним ключом – атрибутом, полем;
• опциональность связи становится опциональностью внешнего ключа.

Логическая структура базы данных программной системы в нотации IE представлена на рисунке 2.20.

 

Рисунок 2.20 – Даталогическая схема БД в нотации IE

В таблицах 2.3-2.11 представлено формализованное описание даталогической модели.

В таблице 2.3 представлен вид таблицы «Cенсор».

 

 Таблица 2.3 - Формализованное описание таблицы «Сенсор»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код сенсора	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Имя хоста		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Интерфейс		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Фильтр		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.4 представлен вид таблицы «Объект».

 

Таблица 2.4 - Формализованное описание таблицы «Объект»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код Объекта	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г, Пр
Тип		ЧИСЛО(10)		Ограниченно	Вв, Пр, Ред
Имя		ЧИСЛО(10)		Ограниченно	Вв, Пр, Ред

 

В таблице 2.5 представлен вид таблицы «Маршрутная матрица».

 

Таблица 2.5 - Формализованное описание таблицы «Маршрутная матрица»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код матрицы	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г, Пр
Размер		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Примечание		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.6 представлен вид таблицы «Протокол».

 

Таблица 2.6 - Формализованное описание таблицы «Протокол»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код протокола	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Протокол		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.7 представлен вид таблицы «Временной срез».

 

Таблица 2.7 - Формализованное описание таблицы «Временной срез»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код Среза	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Код сигнатуры		ЧИСЛО (10)		Неограниченно	Вв,Пр, Ред
Время		ЧИСЛО (10)		Ограниченно	Вв,Пр, Ред
Код объекта		ЧИСЛО (10)	NOT NULL	Неограниченно	Вв,Пр, Ред

 

В таблице 2.8 представлен вид таблицы «Данные».

 

Таблица 2.8 - Формализованное описание таблицы «Данные»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код среза	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Данные		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.9 представлен вид таблицы «Статистика».

 

 

Таблица 2.9 - Формализованное описание таблицы «Статистика»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код объекта	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Код записи		ЧИСЛО(10)		Неограниченно	Вв,Пр, Ред
Время		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Всего байт		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.10 представлен вид таблицы «Привязка объекта».

 

Таблица 2.10 - Формализованное описание таблицы «Привязка объекта»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код матрицы	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Код объекта		ЧИСЛО(10)		Неограниченно	Вв,Пр, Ред
Номер элемента		ЧИСЛО(10)		Неограниченно	Вв,Пр, Ред
Примечание		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

В таблице 2.11 представлен вид таблицы «Элемент матрицы».

 

Таблица 2.11 - Формализованное описание таблицы «Элемент матрицы»

Название	Ключи	Физические параметры	Обязательность	Логические ограничения	Процессы
Код матрицы	ПК	ЧИСЛО(10)	NOT NULL	Неограниченно	Г,Пр
Столбец		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Строка		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред
Значение		ЧИСЛО(10)		Ограниченно	Вв,Пр, Ред

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Primary Key– первичный ключ;

Foreign Key – внешний ключ;

Not Null – запрет на пустое поле;

Сheck – условие ограничения.

 

 

2.7.4      Физическая модель БД

 

 

Для проектирования базы данных была выбрана СУБД  My SQL Server. Рассмотрим физическую модель разрабатываемой БД в виде технического описания таблиц на языке описания данных (ЯОД) My SQL Server. Данное техническое описание таблиц представлено в таблицах 2.12 - 2.20.

В таблице 2.11 представлен вид таблицы «Object».

 

Таблица 2.12 - Физическое описание таблицы «Object»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Object Code	INTEGER	Да		NOT NULL
Type	CHAR			NOT NULL
Name	CHAR			NOT NULL

 

В таблице 2.11 представлен вид таблицы «Sensor».

 

Таблица 2.13 - Физическое описание таблицы «Sensor»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Code Sensor	INTEGER	Да	Да	NOT NULL
Hostname	CHAR			NOT NULL
Interface	CHAR			NOT NULL
Filter	CHAR			NOT NULL

 

В таблице 2.14 представлен вид таблицы «Routing Matrix».

 

Таблица 2.14 - Физическое описание таблицы «Routing Matrix»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Code Matrix	INTEGER	Да	Да	NOT NULL
Size	INTEGER			NOT NULL
Note	CHAR			NOT NULL
Code Cut	CHAR	Да	Да	NOT NULL

 

В таблице 2.15 представлен вид таблицы «Protocol».

 

Таблица 2.15 - Физическое описание таблицы «Protocol»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Code Protocol	INTEGER	Да		NOT NULL
Protocol	CHAR			NOT NULL

 

В таблице 2.16 представлен вид таблицы «Time Slice».

 

Таблица 2.16 - Физическое описание таблицы «Time Slice»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Code Cut	INTEGER	Да	Да	NOT NULL
Code Signature	INTEGER	Да		NOT NULL
Time	DATATIME			NOT NULL
Object Code	INTEGER		Да	NOT NULL

 

В таблице 2.17 представлен вид таблицы «Data».

 

Таблица 2.17 - Физическое описание таблицы «Data»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность
Code Cut	INTEGER	Да		NOT NULL
Data	CHAR			NOT NULL

 

В таблице 2.18 представлен вид таблицы «Stats».

Таблица 2.18 - Физическое описание таблицы «Stats»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность	Логическое имя
Object Code	INTEGER	Да		NOT NULL
Recording Code	INTEGER	Да		NOT NULL
Time	DATATIME			NOT NULL
Total Bytes	INTEGER			NOT NULL

 

В таблице 2.19 представлен вид таблицы «Binding Object».

 

Таблица 2.19 - Физическое описание таблицы «Binding Object»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность	Логическое имя
Code Matrix	INTEGER	Да	Да	NOT NULL
Object Code	INTEGER	Да	Да	NOT NULL
Item Number	INTEGER	Да		NOT NULL
Note	INTEGER			NOT NULL

 

В таблице 2.20 представлен вид таблицы «Element Matrix».

 

Таблица 2.20 - Физическое описание таблицы «Element Matrix»

Имя	Тип	Первичный ключ	Внешний ключ	Опциональность	Логическое имя
Code Matrix	INTEGER	Да	Да	NOT NULL
Colum	INTEGER	Да		NOT NULL
Row	INTEGER	Да		NOT NULL
Value	INTEGER			NOT NULL

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

• Реализация ограничений целостности БД

 

 

Ограничения целостности (constraints)  гарантируют целостность данных для таблиц и столбцов. Ограничения обычно добавляются после создания таблицы и могут быть определены на уровне столбцов или на уровне таблицы. SQL Server поддерживает ограничения целостности пяти типов.

Ограничение PRIMARY  KEY  (ограничение по первичному ключу) - ограничение этого типа используются для обеспечения логической целостности. Оно гарантирует, что для всех строк таблицы будет существовать уникальный ключ, не равный NULL. Применение  ограничения первичного ключа,  кроме  всего,  создает уникальный индекс по таблице.

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

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

Ограничение CHECK (ограничение на значения) - это ограничение, обеспечивающее контроль значений, которые могут быть введены в столбец. Например, можно задать ограничение проверки, при котором данные в столбце будут иметь значения только в диапазоне от 1 до 100. Для столбца можно указать одно или несколько ограничений CHECK.

Ограничение NOT NULL (ограничение на неопределенное значение) - это ограничение используется для   гарантии того, что столбец не будет содержать значений NULL. Неопределенное значение обозначается как NULL. Это ограничение может действовать только на уровне столбца.

 

 

2.7.6      Реализация мероприятий по защите данных

 

 

Для защиты базы данных от несанкционированного доступа пользователей приложения, минуя клиентское приложение, был использован механизм защиты SQL сервера - роль приложения  (Application role).

Начиная с версии MySQL сервера 3.0, в нем появилась очень интересная и полезная функциональность, связанная с безопасностью - роль приложения (Application role). Разумеется, в версии 4.x эта функциональность сохранилась.

В программной системе была использована роль приложения для усиления безопасности работы с MySQL сервером. MySQL сервер поддерживает различные роли:

• фиксированные роли сервера;
• фиксированные роли базы данных;
• пользовательские роли базы данных;
• роли приложения.

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

Пользовательские роли  предназначены для объединения пользователей со схожими задачами и назначения им прав на использования различных объектов базы данных: таблицы, представления (view), хранимые процедуры и прочие. В этом они похожи на группы Windows NT (Windows 2000).

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

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

После успешной проверки имени пользователя и его пароля активизируется роль приложения путем вызова на SQL сервере системной хранимой процедуры «sp_setapprole».

После выполнения данной хранимой процедуры на сервере, программная система становиться членом роли приложения «ASU» и получает все права данной роли. Вывести программную систему из роли «ASU» можно только путем отключения от SQL сервера.

Следовательно, для того чтобы пользоваться объектами базы данных необходимо быть членом роли «ASU». Роль «ASU» является ролью приложения и для того, чтобы стать членом этой роли, необходимо ее активизировать с помощью системной хранимой процедуры «sp_setapprole».

Но для выполнения этой системной процедуры необходимо знать пароль этой роли, который был ей присвоен при ее создании. Данный пароль не сообщается пользователю, его "знает" только программная система.

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

«A» - администратор базы данных;

«O» – Оператор.

 

 

 

2.8 Тестирование программной системы

 

 

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

 

 

Рисунок 2.21 – Ошибка авторизации

 

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

 

 

Рисунок 2.22 – Ошибка при вводе данных

 

При анализе использовалась следующая маршрутная матрица представленная  на рисунке 2.23.

 

Рисунок 2.23- Маршрутная матрица

 

Затем на основе значений маршрутной матрицы строится дерево свичей (рисунок 2.24).

 

Рисунок 2.24- Логическая схема сети

3 Технологический раздел

 

 

 

3.1 Руководство администратору баз данных

 

3.1.1 Общие сведения о программной системе

 

 

Программная система предназначена для автоматизированного осуществления платежных операций операторами через счета дилеров на счета провайдеров. Приложение построено на принципе клиент-сервер и для его работы необходим сервер СУБД MySQL.

Внесение изменений в программный комплекс должно производится только опытным программистом или системным администратором. Для внесения изменений необходимо наличие на вашем компьютере инструментальной среды разработки WingIDE 101.

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

• процессор Pentium IV 2000 MHz;
• ОЗУ 1024 МБ;
• клавиатура;
• мышь;
• жесткий диск с наличием свободного места не менее 50 МБ.

 

 

• Установка программной системы

 

 

Для корректной работы системе необходим SQL сервер MySQL. Для его установки необходимо запустить дистрибутив mysql-server.exe.

 

Рисунок 3.1 – Установка Mysql

 

 

После стандартных ответов переходим к настройке Mysql (рисунок 3.2)

 

 

Рисунок 3.2 – Настройка Mysql

 

При установке MySQL необходимо выбрать номер порта и другие параметры, показанные на рисунок 3.3.

 

 

Рисунок 3.3 – Настройка порта Mysql

 

После этого необходимо поменять пароль БД .

 

Рисунок 3.4 – Смена пароля БД Mysql

 

После настройки адреса сервера и пароля для администратора  можно пользоваться другими службами. Для запуска клиентского приложения необходимо запустить Stat.exe.

 

 

3.1.3 Проверка программной системы

 

 

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

 

 

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

 

3.2.1 Условия выполнения программного средства

 

 

Для нормального функционирования программы достаточно иметь компьютер с тактовой частотой процессора не менее 500 МГц, объемом оперативной памяти – 256 Мб, объемом свободного места на диске около 25 Мб. На нем должна быть установлена и нормально функционировать операционная система не ниже Windows XP.

Кроме того, необходимы такие аппаратные средства, как мышь
(совместимая с IBM или MicroSoft), клавиатура (стандартная, 101-102 клавиши) и принтер.

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

 

 

3.2.2 Эксплуатация программного средства

 

 

При запуске система запрашивает учетные данные, представленные на рисунке 3.5.

 

Рисунок  3.5 – Запрос учетных данных

 

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

 

Рисунок 3.6  – Режим «Редактирования»

 

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

При нажатии на кнопку «Анализ» производится анализ, и строиться маршрутная матрица представлена на рисунке 3.6. Ненулевые элементы матрицы на пересечении i столбца и j строки означают, что существует вероятность того, что трафик был передан с i на j порт коммутатора.

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

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

 

 

Рисунок 3.6- Маршрутная матрица

 

 На вкладке «Схема»  представлена карта сети, построенная в графическом

 

виде представлена на рисунке 3.7. При нажатии на кнопку «Построить»  модуль считывает данные из файла с описанием топологии сети, разбирает формат и визуализирует  в графическом виде.

 

Рисунок 3.7- Карта сети

 

Во время работы программной системы пользователю возможны сообщения от системы, представленные в таблице 3.1.

 

Таблица 3.1 - Сообщения пользователю

Сообщение об ошибке	Действия пользователя
1	2
Не удалось подключится к базе данных!	Укажите путь к базе данных, если путь указан, то неправельно введены логин и пароль. Если ошибка повторяется обратитесь к администратору базы данных.
Пароль неверен!	Повторите вводе пароля, проверьте раскладку клавиатуры и клавишу Caps Lock
Сервер MySQL не отвечает	Это означает недоступность операций с программной системой. Проверьте VPN соединение.

Заключение

 

 

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

В работе получены следующие основные результаты:

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список использованных источников

 

 

1 Абросимов, Л.И. Методология анализа вероятностно-временных характеристик вычислительных сетей на основе аналитического моделирования  / Л.И. Абросимов. - М., 1996.- 412 с.

2 Авен, О.И. Оценка качества и оптимизация вычислительных систем / О.И.Авен, Н.Н. Турин, Я.А.Коган. - И.: Наука, 1982. - 464 с.

3 Анализатор протоколов Any Test [Электронный ресурс]. - Электрон. дан. - AnyTest.ru. - М.: сор. 2007. - Режим доступа: http://www.anytest.  su/products/analizator/.

4 Байковский, В.А. Исследование и разработка методов оценки вероятностных характеристик цифровых управляющих систем центров коммутации сообщений: дис… канд. техн. наук / В.А. Байковский. - Л.: 1976. - 193 с.

5 Бахарева, Н.Ф. Интерактивная система вероятностного моделирования компьютерных сетей на основе метода двумерной диффузионной аппроксимации: дис… канд. техн. наук / Н. Ф. Бахарева. – Оренбург: 2004. - 133с.

6 Березко, М.П. Информационные процессы. Математические модели исследования алгоритмов маршрутизации в сетях передачи данных в 2 т. / М.П. Березко, В.М. Вишневский. – М.: Институт проблем передачи информации, 2001. - Т. 1. - 120с.

7 Бусленко, Н.П. Моделирование сложных систем / Н.П. Бусленко. - М.: Наука, 1978. - 399 с.

8 Вишневский, В.М. Теоретические основы проектирования компьютерных сетей / В.М. Вишневский. - М.: Техносфера, 2003. - 512с.

9 Гадасин, Д.В. Разработка методов и средств анализа однородных стохастических мегасетей и исследование их вероятностных характеристик : дис... канд. техн. наук / Д.В. Гадасин. - М.: 1998. - 138с.

10 Галкин, В.А. Телекоммуникации и сети / В.А. Галкин, Ю.А. Григорьев. - М.:Издат-во МГТУ им.Н.Э.Баумана, 2003 г. - 608 с.

11 Герасимов, А.И. Аналитические методы исследования и оптимизации вычислительных систем и сетей на основе сетевых моделей массового обслуживания / А.И.Герасимов дисс.. канд. техн. наук. - М.: 1999. – 359 с.

12 Герасимов, А.И. Теория и практическое применение стохастических сетей / А. И. Герасимов. - М.: Радио и связь, 1994. - 175 с.

13 Головко, Н.И. Исследование моделей систем массового обслуживания в информационных сетях: дис... докт. техн. наук / Н.И. Головко. – Владивосток: 2007. - 145 с.

14 Гончаров, А.А. Исследование условий обеспечения гарантированного качества обслуживания в сети Интернет : дис… канд. техн. наук / А.А. Гончаров. - М.: 2007. - 118 с.

15 Гончаров, А.А., Лемешко Б.Ю. [Электронный ресурс]. - Электрон, дан. - Заводская лаборатория. - М.: сор 1997. - Режим доступа: http://www.ami.nstu.ru/headrd/seminar/publikhtml/Zlabl.htm

16 Гуляев, В.К. Численный метод исследования систем массового обслуживания / В.К.Гуляев Техническая кибернетика, 1975, № 6, с. 140-146.

17 Две технологии компании Cisco Systems [Электронный ресурс].- Электрон. дан.- Jet Info информационный бюллетень. - М.: сор. 2008. - Режим доступа : http://www.jetinfo.ru/1998/2-3/1/article 1.2-3.1998274.html

18 Дэвис, Д. Вычислительные сети и сетевые протоколы / Д. Дэ-вис, Д. Барбер, У. Прайс, С. Соломонидес ; пер. с англ. под ред. С.И.Самойленко. - М.: Мир, 1982. - 562 с.

19 Евреинов, Э.В. Однородные вычислительные системы / Э.В. Евреинов, В.Г. Хорошевский. - Новосибирск: Наука, 1978. - 320 с.

20 Евреинов, Э.В. Однородные вычислительные системы, структуры и среды / Э. В. Евреинов - М.: Радио и связь, 1981. - 208 с.

21 Ерохин, А.Е. О пропускной способности агрегирующих портов коммутатора / А.Е.Ерохин, С.П.Сущенко. - Тезисы VI Всероссийского симпозиума по прикладной и промышленной математике. - Томск, 2006.

22 Искусство диагностики локальных сетей [Электронный ресурс].-Электрон, дан.- P-STONE.ru информационный портал. - М.: сор.2006. - Режим доступа : http://www.p-stone.ru/libr/nets/monitor/data/publicl4/.137

23 История информационно-образовательного портала HY4.NET.RU [Электронный ресурс]. - Электрон, дан. - М..: сор. 2008. - Режим доступа: http://razgon.net.ru/history/portal/net.htm.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Приложение А

(обязательное)

 

Листинг программы

 

import numpy as np

import matplotlib.pyplot as plt

 

plt.subplots_adjust(wspace=0.5)

dt = 0.01

t = np.arange(0, 30, dt)

nse1 = np.random.randn(len(t))                

nse2 = np.random.randn(len(t))               

r = np.exp(-t/0.05)

 

cnse1 = np.convolve(nse1, r, mode='same')*dt 

cnse2 = np.convolve(nse2, r, mode='same')*dt  

 

# two signals with a coherent part and a random part

s1 = 0.01*np.sin(2*np.pi*10*t) + cnse1

s2 = 0.01*np.sin(2*np.pi*10*t) + cnse2

 

plt.subplot(211)

plt.plot(t, s1, 'b-', t, s2, 'g-')

plt.xlim(0,5)

plt.xlabel('time')

plt.ylabel('s1 and s2')

plt.grid(True)

 

plt.subplot(212)

cxy, f = plt.csd(s1, s2, 256, 1./dt)

plt.ylabel('CSD (db)')

plt.show()

 

import matplotlib

matplotlib.rcParams['legend.fancybox'] = True

import matplotlib.pyplot as plt

import numpy as np

 

def myplot(ax):

    t1 = np.arange(0.0, 1.0, 0.1)

    for n in [1, 2, 3, 4]:

        ax.plot(t1, t1**n, label="n=%d"%(n,))

ax1 = plt.subplot(3,1,1)

ax1.plot([1], label="multi\nline")

ax1.plot([1], label="$2^{2^2}$")

ax1.plot([1], label=r"$\frac{1}{2}\pi$")

ax1.legend(loc=1, ncol=3, shadow=True)

 

ax2 = plt.subplot(3,1,2)

myplot(ax2)

ax2.legend(loc="center left", bbox_to_anchor=[0.5, 0.5],

           ncol=2, shadow=True, title="Legend")

ax2.get_legend().get_title().set_color("red")

ax3 = plt.subplot(3,1,3)

 

myplot(ax3)

ax3.legend(shadow=True, fancybox=True)

plt.draw()

plt.show()

 

import numpy as np

import matplotlib.mlab as mlab

import matplotlib.pyplot as plt

 

mu, sigma = 100, 15

x = mu + sigma*np.random.randn(10000)

 

n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75)

 

y = mlab.normpdf( bins, mu, sigma)

l = plt.plot(bins, y, 'r--', linewidth=1)

 

plt.xlabel('Smarts')

plt.ylabel('Probability')

plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')

plt.axis([40, 160, 0, 0.03])

plt.grid(True)

 

plt.show()

 

fig = plt.figure()

ax = fig.gca(projection='3d')

X, Y, Z = axes3d.get_test_data(0.05)

ax.plot_surface(X, Y, Z, rstride=8, cstride=8, alpha=0.3)

 

cset = ax.contour(X, Y, Z, zdir='z', offset=-100)

cset = ax.contour(X, Y, Z, zdir='x', offset=-40)

cset = ax.contour(X, Y, Z, zdir='y', offset=40)

 

ax.set_xlabel('X')

ax.set_xlim3d(-40, 40)

ax.set_ylabel('Y')

ax.set_ylim3d(-40, 40)

ax.set_zlabel('Z')

ax.set_zlim3d(-100, 100)

 

plt.show()

 

ax = subplot(111)

subplots_adjust(left=0.25, bottom=0.25)

t = arange(0.0, 1.0, 0.001)

a0 = 5

f0 = 3

s = a0*sin(2*pi*f0*t)

l, = plot(t,s, lw=2, color='red')

axis([0, 1, -10, 10])

 

axcolor = 'lightgoldenrodyellow'

axfreq = axes([0.25, 0.1, 0.65, 0.03], axisbg=axcolor)

axamp  = axes([0.25, 0.15, 0.65, 0.03], axisbg=axcolor)

 

sfreq = Slider(axfreq, 'Freq', 0.1, 30.0, valinit=f0)

samp = Slider(axamp, 'Amp', 0.1, 10.0, valinit=a0)

 

def update(val):

    amp = samp.val

    freq = sfreq.val

    l.set_ydata(amp*sin(2*pi*freq*t))

    draw()

sfreq.on_changed(update)

samp.on_changed(update)

 

resetax = axes([0.8, 0.025, 0.1, 0.04])

button = Button(resetax, 'Reset', color=axcolor, hovercolor='0.975')

def reset(event):

    sfreq.reset()

    samp.reset()

 

button.on_clicked(reset)

rax = axes([0.025, 0.5, 0.15, 0.15], axisbg=axcolor)

radio = RadioButtons(rax, ('red', 'blue', 'green'), active=0)

def colorfunc(label):

    l.set_color(label)

    draw()

radio.on_clicked(colorfunc)

 

show()

 

x,y = np.random.randn(2,100)

fig = plt.figure()

ax1 = fig.add_subplot(211)

ax1.xcorr(x, y, usevlines=True, maxlags=50, normed=True, lw=2)

ax1.grid(True)

ax1.axhline(0, color='black', lw=2)

 

ax2 = fig.add_subplot(212, sharex=ax1)

ax2.acorr(x, usevlines=True, normed=True, maxlags=50, lw=2)

ax2.grid(True)

ax2.axhline(0, color='black', lw=2)

 

plt.show()

 

fig = plt.figure()

x = np.linspace(0,2*np.pi,100)

y = 2*np.sin(x)

ax = fig.add_subplot(1,2,1)

ax.set_title('dropped spines')

ax.plot(x,y)

for loc, spine in ax.spines.iteritems():

    if loc in ['left','bottom']:

        spine.set_position(('outward',10)) # outward by 10 points

    elif loc in ['right','top']:

        spine.set_color('none') # don't draw spine

    else:

        raise ValueError('unknown spine location: %s'%loc)

 

ax.xaxis.set_ticks_position('bottom')

ax.yaxis.set_ticks_position('left')

 

ax = fig.add_subplot(1,2,2,sharex=ax)

 

ax.plot(x,y)

ax.set_title('normal spines')

 

 

fig = plt.figure()

x = np.linspace(-np.pi,np.pi,100)

y = 2*np.sin(x)

 

ax = fig.add_subplot(2,2,1)

ax.set_title('centered spines')

ax.plot(x,y)

ax.spines['left'].set_position('center')

ax.spines['right'].set_color('none')

ax.spines['bottom'].set_position('center')

ax.spines['top'].set_color('none')

ax.spines['left'].set_smart_bounds(True)

ax.spines['bottom'].set_smart_bounds(True)

ax.xaxis.set_ticks_position('bottom')

ax.yaxis.set_ticks_position('left')

 

ax = fig.add_subplot(2,2,2)

ax.set_title('zeroed spines')

ax.plot(x,y)

ax.spines['left'].set_position('zero')

ax.spines['right'].set_color('none')

ax.spines['bottom'].set_position('zero')

ax.spines['top'].set_color('none')

ax.spines['left'].set_smart_bounds(True)

ax.spines['bottom'].set_smart_bounds(True)

ax.xaxis.set_ticks_position('bottom')

ax.yaxis.set_ticks_position('left')

 

ax = fig.add_subplot(2,2,3)

ax.set_title('spines at axes (0.6, 0.1)')

ax.plot(x,y)

ax.spines['left'].set_position(('axes',0.6))

 

ax.spines['right'].set_color('none')

ax.spines['bottom'].set_position(('axes',0.1))

ax.spines['top'].set_color('none')

ax.spines['left'].set_smart_bounds(True)

ax.spines['bottom'].set_smart_bounds(True)

 

ax.xaxis.set_ticks_position('bottom')

ax.yaxis.set_ticks_position('left')

 

ax = fig.add_subplot(2,2,4)

 

 

ax.set_title('spines at data (1,2)')

ax.plot(x,y)

ax.spines['left'].set_position(('data',1))

ax.spines['right'].set_color('none')

ax.spines['bottom'].set_position(('data',2))

ax.spines['top'].set_color('none')

ax.spines['left'].set_smart_bounds(True)

ax.spines['bottom'].set_smart_bounds(True)

ax.xaxis.set_ticks_position('bottom')

ax.yaxis.set_ticks_position('left')

# ----------------------------------------------------

 

def adjust_spines(ax,spines):

    for loc, spine in ax.spines.iteritems():

        if loc in spines:

            spine.set_position(('outward',10)) # outward by 10 points

            spine.set_smart_bounds(True)

        else:

            spine.set_color('none') # don't draw spine

 

    # turn off ticks where there is no spine

    if 'left' in spines:

        ax.yaxis.set_ticks_position('left')

    else:

        # no yaxis ticks

        ax.yaxis.set_ticks([])

 

    if 'bottom' in spines:

        ax.xaxis.set_ticks_position('bottom')

    else:

        # no xaxis ticks

        ax.xaxis.set_ticks([])

fig = plt.figure()

 

x = np.linspace(0,2*np.pi,100)

y = 2*np.sin(x)

 

ax = fig.add_subplot(2,2,1)

ax.plot(x,y)

adjust_spines(ax,['left'])

ax = fig.add_subplot(2,2,2)

ax.plot(x,y)

adjust_spines(ax,[])

ax = fig.add_subplot(2,2,3)

ax.plot(x,y)

adjust_spines(ax,['left','bottom'])

ax = fig.add_subplot(2,2,4)

ax.plot(x,y)

adjust_spines(ax,['bottom'])

 

# ----------------------------------------------------

 

fig = plt.figure()

 

x = np.linspace(0,2*np.pi,50)

y = np.sin(x)

y2 = y + 0.1*np.random.normal( size=x.shape )

ax = fig.add_subplot(1,1,1)

line1,=ax.plot(x,y,'--')

line2,=ax.plot(x,y2,'bo')

adjust_spines(ax,['left','bottom'])

 

ax.set_xlim((0,2*np.pi))

ax.set_xticks([0,np.pi,2*np.pi])

pichr = unichr(0x03C0)

ax.set_xticklabels(['0',pichr,'2 '+pichr])

 

ax.set_yticks([-1,0,1])

 

for artist in (line1,line2):

    artist.set_clip_on(False)

 

# adjust spine to be within ticks

ax.spines['left'].set_bounds( -1, 1 )

 

show()

 

 

 

 

 

Приложение Б

(обязательное)

 

SQL-скрипты

 

Ниже представлен скрипт генерации параметров для анализа

SELECT points.name, Count(*), Sum(platej.summ)

FROM points, operators, platej

WHERE points.id=operators.pointid And operators.id=platej.operator And platej.stateid=3

GROUP BY points.name;

 

SELECT events.id, events.text, events.summ, pl_state.name, provider.name

FROM provider INNER JOIN (pl_state INNER JOIN events ON pl_state.id = events.state) ON provider.id = events.provider;

 

Далее идет скрипт для создания БД

 

CREATE TABLE cachin

(

     id  INTEGER NOT NULL,

     dom  INTEGER NULL,

     korpus  INTEGER NULL,

     litera  char(3) NULL,

     name  char(40) NOT NULL,

     descript  text NULL,

     tel  char(20) NULL,

     kupur  INTEGER NULL,

     summ  INTEGER NULL,

     paper  INTEGER NULL,

     version  char(10) NULL,

     streetid  INTEGER NULL,

     cityid  INTEGER NULL,

     cachin_stateid  INTEGER NULL

)

;

CREATE TABLE cachin_log

(

     id  INTEGER NOT NULL,

     event  text NOT NULL,

    

           dat  DATETIME NOT NULL,

     cachin_log_typeid  INTEGER NOT NULL,

    

cachinid  INTEGER NOT NULL

)

;

 

CREATE TABLE cachin_log_type

(

     id  INTEGER NULL,

     name  char(50) NULL

)

;

 

CREATE TABLE call_center

(

     id  INTEGER NOT NULL,

     tel  INTEGER NULL,

     dom  INTEGER NULL,

     korpus  INTEGER NULL,

     litera  char(3) NULL,

     user_stateid  INTEGER NULL,

     userid  INTEGER NULL,

     cityid  INTEGER NULL,

     streetid  INTEGER NULL,

     stateid  INTEGER NULL,

     name  char(50) NOT NULL

)

;

 

CREATE TABLE cashin_state

(

     id  INTEGER NOT NULL,

     name  CHAR(50) NULL

)

;

 

CREATE TABLE city

(

     id  INTEGER NOT NULL,

     name  CHAR(50) NOT NULL,

           raionid  INTEGER NOT NULL

)

;

CREATE TABLE dealer

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL,

     key  text NULL,

     balans  DECIMAL(14,4) NULL,

     overdraft  DECIMAL(14,4) NULL

)

;

 

CREATE TABLE direction

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

 

CREATE TABLE event

(

     id  INTEGER NOT NULL,

     summ  DECIMAL(14,4) NULL,

     komiss  DECIMAL(14,4) NULL,

     bonus  DECIMAL(14,4) NULL,

     event_type_id  INTEGER NULL,

     event_state_id  INTEGER NULL,

     from_cashinid  INTEGER NULL,

     userid  INTEGER NULL,

     providerid  INTEGER NULL,

     dealer_fromid  INTEGER NULL,

     dealer_toid  INTEGER NULL,

     descr  text NULL

)

;

 

CREATE TABLE event_type

(

     id  INTEGER NOT NULL,

     name  VARCHAR(50) NOT NULL

)

;

 

 

 

CREATE TABLE komiss

(

     komiss  DECIMAL(14,5) NULL,

     bonus  DECIMAL(14,5) NULL,

     min_komiss  DECIMAL(14,5) NULL,

     max_bonus  DECIMAL(14,5) NULL,

     min_pay  DECIMAL(14,5) NULL,

     max_pay  DECIMAL(14,5) NULL,

     day_limit  DECIMAL(14,5) NULL,

     providerid  INTEGER NOT NULL,

     dealerid  INTEGER NOT NULL,

     descr  text NULL

)

;

 

CREATE TABLE log

(

     id  INTEGER NOT NULL,

     prevous_id  INTEGER NULL,

     dat  INTEGER NOT NULL,

     sum  DECIMAL(14,5) NULL,

     komiss  DECIMAL(14,5) NULL,

     bonus  DECIMAL(14,5) NULL,

     descr  text NULL,

     operationid  INTEGER NULL,

     userid  INTEGER NULL,

     providerid  INTEGER NULL,

     cachinid  INTEGER NULL,

     osnovanieid  INTEGER NULL,

     date_osnovanie  INTEGER NULL,

     date_operation  INTEGER NULL

)

;

 

CREATE TABLE object

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE oblast

(

     id  INTEGER NOT NULL,

 

name  char(50) NOT NULL

)

;

 

CREATE TABLE operation

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE osnovanie

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE provider

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL,

     script  text NULL,

     key  text NULL,

     min_komiss  DECIMAL(14,5) NULL,

     max_bonus  DECIMAL(14,5) NULL,

     min_pay  DECIMAL(14,5) NULL,

     max_pay  DECIMAL(14,5) NULL,

     day_limit  DECIMAL(14,5) NULL,

     provider_stateid  INTEGER NULL,

     provider_typeid  INTEGER NULL

)

;

CREATE TABLE provider_state

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE provider_type

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

 

CREATE TABLE raion

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL,

     oblastid  INTEGER NULL

)

;

CREATE TABLE street

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE street

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

 

CREATE TABLE user

(

     id  INTEGER NOT NULL,

     login  char(50) NOT NULL,

     mail  INTEGER NULL,

    

 

           pass  char(50) NOT NULL,

     key  text NULL,

     call  INTEGER NULL,

     tel  char(50) NULL,

     user_typeid  INTEGER NULL,

    

user_stateid  INTEGER NULL,

     dealerid  INTEGER NULL

)

;

CREATE TABLE user_right

(

     descr  INTEGER NOT NULL,

    

 

objectid  INTEGER NOT NULL,

     userid  INTEGER NOT NULL,

    

           operationid  INTEGER NULL,

     user_right_typeid  INTEGER NULL

)

;

CREATE TABLE user_right_default

(

     descr  text NOT NULL,

     user_typeid  INTEGER NOT NULL,

     user_right_typeid  INTEGER NOT NULL,

     operationid  INTEGER NOT NULL,

     objectid  INTEGER NOT NULL

)

;

CREATE TABLE user_right_type

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL,

     user_right_type_stateid  INTEGER NULL

)

;

CREATE TABLE user_right_type_state

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

 

CREATE TABLE user_state

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

CREATE TABLE user_type

(

     id  INTEGER NOT NULL,

     name  char(50) NOT NULL

)

;

 

Скачать:  Diplom.rar