Московский государственный университет имени М.В. Ломоносова

Факультет вычислительной математики и кибернетики

Магистерская программа "Прикладные интернет технологии"

Магистерская диссертация

Алгоритмы балансировки нагрузки в сети

доставки контента

Работу выполнил

студент Лихобабин Сергей Михайлович

Научный руководитель:

доцент, к.ф.-м.н. Абрамов Владимир Геннадиевич Москва 2013 Оглавление Оглавление

Аннотация

Введение

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

Ключевые особенности

Исследование предметной области

Анализ существующих сетей доставки контента и готовых решений для их создания

Akamai CDN

Amazon CloudFront

CacheBoy

OpenCDN

P2P-Next

CloudFlare Railgun

Обзор технологий используемых для построения CDN

Программно-конфигурируемые сети (SDN)

Архитектура SDN

Openflow

Архитектура

Сетевая операционная система

Виртуализация в SDN

Преимущества SDN

Распределение контента внутри CDN

BitTorrent

Принцип работы протокола

Алгоритм обмена данными

Общие особенности

Трекер и работа без трекера

Multicast

Статический и динамический контент

Балансировка на уровне DNS

Недостатки

BGP

Мониторинг состояния сети

SNMP

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

Реализация

Характеристика модельной сети доставки контента

Инструменты и технологии

Django

Twisted

Nginx

Numpy

Инфраструктура

Автоматизация установки и сборки

Инструменты разработки

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

Методика использования

Заключение

Литература

Глоссарий

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

Таким образом крупным поставщикам контента требуется распределенная сеть серверов, называемая Сетью Доставки Контента (англ. Content Delivery Network CDN). При построении CDN могут возникать различные проблемы – оптимизация трафика внутри CDN, оптимизация распределения контента по серверам.

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

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

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

На скорость загрузки веб-страницы и её содержимого сильно влияет удаленность пользователя от сервера. Это происходит из-за того, что при использовании технологии TCP/IP, применяемой для распространения информации в сети Интернет, задержки при передаче информации зависят от количества маршрутизаторов, находящихся на пути между источником и потребителем контента. Размещение контента между несколькими серверами средствами CDN сокращает сетевой маршрут передачи данных и делает загрузку сайта быстрее с точки зрения пользователя.

Использование CDN снижает количество переходов между узлами сети, что существенно увеличивает скорость скачивания контента из сети Интернет.

Конечные пользователи испытывают меньшую задержку при загрузке контента, отсутствие резких изменений скорости загрузки и высокое качество потока данных. Пропускная способность позволяет операторам CDN доставлять видеоконтент высокого разрешения (1080p, 4K), обеспечивать быструю загрузку файлов больших размеров или организовывать видеовещание с высоким качеством сервиса (QoS) и низкими затратами на сеть.

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

Размещение серверов в непосредственной близости от конечных пользователей может увеличить исходящую пропускную способность всей системы. К примеру, наличие единственного порта 100 Мбит/с не означает данную скорость на всех участках сети, так как свободная пропускная способность связующего канала в момент передачи может быть всего 10 Мбит/с. В случае, когда используются распределённых серверов, суммарная пропускная способность может составить 10100 Мбит/с.

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

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

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

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

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

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

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

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

Анализ существующих сетей доставки контента и готовых решений для их создания Akamai CDN The Akamai Network[2][11] - одна из крупнейших в мире распределенных вычислительных платформ. Это сеть из более чем 105,000 серверов со специальным программным обеспечением, расположенных в 78 странах. Сильной стороной сети Akamai являются алгоритмы распределения нагрузки внутри сети.

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

Основные способы оптимизации доставки контента:

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

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

Перемещение вычислений ближе к конечным пользователям во избежание задержек.(EdgeComputing). [1][8] Amazon CloudFront Amazon CloudFront — веб-сервис для доставки контента. Amazon CloudFront интегрируется с другими Amazon Web Services. Цель сервиса — дать разработчикам и предприятиям простой способ распространять контент для конечных пользователей с минимальными задержками, высокой скоростью передачи данных.

Сервис не является свободным для пользования и входит в инфраструктуру сервисов Amazon Web Services.[25] CacheBoy Cacheboy предоставляет открытую платформу для осуществления эффективной доставки контента. Зеркальная инфраструктура открытого проекта поддерживается сервис-провайдерам по всему миру. Проект перенаправляет пользователя на ближайшее зеркало. Cacheboy распространяется под лицензией GPLv3.

OpenCDN OpenCDN - CDN уровня приложения, который реплицирует контент и разделяет трансляции и записанный контент. OpenCDN написан на Perl и использует технологию Relay для разделения медиа пакетов. Связь между узлами и источниками осуществляется по средством XML – RPC. Распространяется под лицензией Perl Artistic.[18] P2P-Next P2P-Next - программное обеспечение следующего поколения для доставки контента, которое может быть использовано для одновременной передачи миллионам людей. Оно использует мультикастинг для передачи данных миллионам пользователей одновременно. Поток данных распределяется по локальным серверам и прямой эфир может быть ретранслирован локальным зрителям. Так как IP роутеры не поддерживают мультикастинг, оптимизированные механизмы uni-cast, broadcast и multicast были адаптированы для P2P.

CloudFlare Railgun Один из путей снижения нагрузки внутри CDN - кэшировать максимальное количество контента. Но в реальности держать в кэше можно только около 66% объектов, а остальные 34% приходится заново запрашивать с сервера в случае обновления. Для сжатия этого трафика и был создан Railgun.

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

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

Технически, Railgun состоит из двух компонентов: отправителя (sender) и получателя (listener). Отправители установлены в каждом дата-центре CDN-сети.

Получатель — программный компонент, который устанавливается на пограничные узлы сети. Между отправителем и получателем устанавливается TCP-соединение, защищённое TLS, по которому бинарный протокол Railgun осуществляет асинхронную передачу HTTP-запросов. Для веб-клиента система Railgun выглядит как прокси-сервер, хотя на самом деле это специализированная система со специфическими функциями. Одна из них — сжатие контента, который невозможно кэшировать, за счёт синхронизации версий страниц. При обновлении версии страницы по сети передаётся только изменение между предыдущей и новой версией.

Исследования показали, что максимальное сжатие достигается на новостных сайтах с большой посещаемостью. Например, бинарное сравнение главной страницы сайта reddit.com показывает изменение в среднем 2,15% в течение минут и 3,16% в течение часа. Главная страница The New York Times бинарно изменяется на 0,6% за пять минут и на 3% в течение часа. Для главной страницы BBC News эти показатели составляют 0,4% и 2%, соответственно. В общем случае, для самых популярных сайтов при повторном запросе изменений разница занимает один пакет TCP.

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

Виртуализация сетевого уровня Контроль целостности сети Управление пограничным траффиком Программно-конфигурируемые сети (SDN) Для облегчения масштабируемости сетевой инфраструктуры CDN возможно использовать принципы программно-конфигурируемых сетей SDN(Software Defined Networks).[9][12] В SDN уровни управления сетью и передачи данных разделяются за счет переноса функций управления (маршрутизаторами, коммутаторами и т. п.) в приложения, работающие на отдельном сервере (контроллере). Идея таких сетей была сформулирована специалистами университетов Стэнфорда и Беркли еще в году, а инициированные ими исследования нашли поддержку не только в академических кругах, но и были активно восприняты ведущими производителями сетевого оборудования, образовавшими в марте 2011 года консорциум Open Networking Foundation (ONF). Его учредителями выступили Google, Deutsche Telekom, Facebook, Microsoft, Verizon и Yahoo. Состав ONF быстро расширяется, в нее уже вошли такие компании, как Brocade, Citrix, Oracle, Dell, Ericsson, HP, IBM, Marvell, NEC и ряд других. Одной из первых практическую реализацию SDN предложила компания Nicira, вошедшая недавно в состав VMware.[ Заинтересованность ИТ-компаний в SDN вызвана тем, что такие технологии позволяют повысить эффективность сетевого оборудования на 25–30%, снизить на 30% затраты на эксплуатацию сетей, превратить управление сетями из искусства в инженерию, повысить безопасность и предоставить пользователям возможность программно создавать новые сервисы и оперативно загружать их в сетевое оборудование. [27][28] Основные разработки в области SDN ведутся участниками программы GENI (Global Environment for Network Innovations) исследования будущего Интернета, силами объединенного центра Стэнфорда и Беркли (Open Network Research Center), выполняющего исследования и разработки в области Internet2; а также с Седьмой рамочной программой исследований Европейского Союза Ofelia и проектом FEDERICA.

Основные задачи SDN:

разделение процессов передачи и управления данными;

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

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

виртуализация физических ресурсов сети.

Архитектура SDN В архитектуре SDN можно выделить три уровня:

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

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

3. уровень сетевых приложений для гибкого и эффективного управления Рис. 1. Архитектура программно-конфигурируемых сетей Наиболее перспективным и активно развивающимся стандартом для SDN является OpenFlow — открытый стандарт, в котором описываются требования, предъявляемые к коммутатору, поддерживающему протокол OpenFlow для удаленного управления.

С помощью современных маршрутизаторов обычно решаются две основные задачи: передача данных (forwarding) — продвижение пакета от входного порта на определенный выходной порт и управление данными — обработка пакета и принятие решения о том, куда его передавать дальше, на основе текущего состояния маршрутизатора. Это соответствует уровню передачи данных, на котором собраны средства передачи (линии связи, каналообразующее оборудование, маршрутизаторы, коммутаторы), и уровню управления состояниями средств передачи данных. Развитие маршрутизаторов до сих пор шло по пути сближения этих уровней, однако с уклоном на передачу (аппаратное ускорение, совершенствование ПО и внедрение новых функциональных возможностей для увеличения скорости принятия решения по маршрутизации каждого пакета), тогда как уровень управления оставался достаточно примитивным и опирался на сложные распределенные алгоритмы маршрутизации и замысловатые инструкции по конфигурированию и настройке сети. Разумеется, ПО маршрутизаторов, реализующее уровень управления, было проприетарным и закрытым.

Рис. 2. Традиционные сети и SDN Согласно спецификации 1.3 стандарта OpenFlow, взаимодействие контроллера с коммутатором осуществляется посредством протокола OpenFlow — каждый коммутатор должен содержать одну или более таблиц потоков (flow tables), групповую таблицу (group table) и поддерживать канал (OpenFlow channel) для связи с удаленным контроллером — сервером. Спецификация не регламентирует архитектуру контроллера и API для его приложений. Каждая таблица потоков в коммутаторе содержит набор записей (flow entries) о потоках или правила. Каждая такая запись состоит из полей-признаков (match fields), счетчиков (counters) и набора инструкций (instructions).

Механизм работы коммутатора OpenFlow достаточно прост. У каждого пришедшего пакета «вырезается» заголовок (битовая строка определенной длины).

Для этой битовой строки в таблицах потоков, начиная с первой, ищется правило.

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

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

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

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

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

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

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

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

Openflow Openflow (открытый поток)[32] — протокол (и технология) управления процессом обработки данных, передающихся по компьютерой сети маршрутизаторами и коммутаторами.

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

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

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

Версии микропрограмм с поддержкой Openflow разработаны для устройств многих производителей, включая Cisco, Juniper, HP, IBM, NEC.[1] В настоящий момент протокол имеет версию 1.2 (принята 5 декабря 2011 года).

Архитектура Информация о пути прохождения данных (datapath) представляет из себя таблицы потоков (flow table) и действий, назначенных для каждой записи. Сами таблицы могут относиться как к Ethernet (или других протоколов канального уровня), так и к другим протоколам вышестоящих уровней (IP, TCP). Точный список действий может варьироваться, но основные это: перенаправление (пересылка PDU (пакета, фрейма) в заданный порт), пересылка PDU на контроллер через безопасный канал для дальнейшего исследования, отбрасывание PDU (drop). Для устройств, совмещающих Openflow и обычную обработку пакетов средствами микропрограммы устройства, добавляется четвёртый тип действия: обработка PDU 'обычными' средствами. Оборудование, поддерживающее эти четыре действия являются устройствами первого типа(Type0).

Устройство OpenFlow состоит, как минимум, из трёх компонент:

таблицы потоков (англ. flow table);

безопасного канала (англ. secure channel), использующегося для управления коммутатором внешним «интеллектуальным» устройством (контроллером);

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

Использование этого протокола позволяет избежать необходимости писать программу для управляемого устройства;

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

Заголовок может состоять из множества полей разного уровня (например, MACадресов отправителя и получателя, полей из заголовка IP-пакета, полей из заголовка TCP-сегмента). Каждое поле может иметь особое значение (звезда), означающее соответствие любому значению соответствующего поля в PDU.[24] Устройства второго типа (Type1), которые будут обеспечивать трансляцию адресов (NAT), поддержку классов и приоритетов, запланированы, но их спецификация пока не определена.

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

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

Сетевая ОС (СОС) обеспечивает приложениям доступ к управлению сетью и постоянно отслеживает конфигурацию средств сети. В отличие от традиционного толкования термина ОС, под СОС понимается программная система, обеспечивающая мониторинг, доступ и управление ресурсами всей сети, а не ее конкретного узла.[13] Подобно традиционной операционной системе, СОС обеспечивает программный интерфейс для приложений управления сетью и реализует механизмы управления таблицами коммутаторов: добавление, удаление, модификацию правил и сбор разнообразной статистики. Таким образом, фактически решение задач управления сетью выполняется с помощью приложений, реализованных на основе API сетевой операционной системы, позволяющих создавать приложения в терминах высокоуровневых абстракций (например, имя пользователя и имя хоста), а не низкоуровневых параметров конфигурации (например, IP- и MAC-адресов). Это позволяет выполнять управляющие команды независимо от базовой топологии сети, однако требует, чтобы СОС поддерживала отображения между высокоуровневыми абстракциями и низкоуровневыми конфигурациями.

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

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

Рис. 3. Альтернативный подход к построению распределенного масштабируемого контроллера Сегодня получили развитие несколько подходов к построению распределенного масштабируемого контроллера: HyperFlow, Onix и Kandoo.[27] Однако, наиболее перспективным считается альтернативный подход (рис. 3)[28]. Поскольку каждый контроллер может быть соединен с несколькими коммутаторами, а каждый коммутатор — с несколькими контроллерами, то контроллеры, управляющие одним и тем же коммутатором, можно объединить в групповой контроллер (ГК).

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

3, С1 – С3 — контроллеры, S1 – S4 — коммутаторы, а V1 – V3 — фрагменты сети, к которым обеспечивает доступ коммутатор S1, S2, S3 соответственно. Тогда ГК образуют контроллеры C1 и C2, ГК2 — С2 и С3, а все приложения в ГК1 должны иметь согласованное представление о топологии V1 и V2, все приложения в ГК2 — о топологии V2 и V3. В случае выхода из строя, например, контроллера С1 его может заменить С2, взяв на себя управление V1. Представление о состоянии соответствующей части сети контроллеры могут согласовывать либо через коммутатор S4, либо через S1, S2 и S3.

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

Виртуализация в SDN Одна из идей, активно развиваемая в рамках SDN, — это виртуализация сетей с целью более эффективного использования сетевых ресурсов (рис. 4). Под виртуализацией сети понимается изоляция сетевого трафика — группировка (мультиплексирование) нескольких потоков данных с различными характеристиками в рамках одной логической сети, которая может разделять единую физическую сеть с другими логическими сетями или сетевыми срезами (network slices). Каждый такой срез может использовать свою адресацию, свои алгоритмы маршрутизации, управления качеством сервисов и т. д.

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

Одним из примеров виртуализации ресурсов SDN, разделения сети на срезы и управления ими является FlowVisor — программа-посредник (proxy), действующая на уровне между OpenFlow- коммутаторами и различными контроллерами SDN.

Посредством FlowVisor можно создавать логические сегменты сети, использующие разные алгоритмы управления потоками данных, обеспечивая изоляцию данных сетей друг от друга. Это означает, что каждый контроллер управляет только своей логической сетью и не может оказывать влияния на функционирование других. Для контроллера, взаимодействующего с оборудованием OpenFlow через FlowVisor, весь обмен сообщениями выглядит так же, как если бы контроллер взаимодействовал с обычной сетью SDN. Всю необходимую модификацию сообщений, требующуюся для поддержки различных изолированных сегментов сети, выполняет FlowVisor. То есть для контроллера логической сети не требуется модификации — это может быть любой контроллер SDN, например сетевая операционная система NOX с произвольным набором программ.[19] Преимущества SDN Благодаря снятию с коммутаторов нагрузки по обработке тракта управления, SDN позволяет этим устройствам направить все свои ресурсы на ускорение перемещения трафика, что существенно повышает производительность. При этом за счет виртуализации управления сетью снижаются расходы на их построение и сопровождение. По результатам тестов, проведенных на базе крупнейших провайдеров США, использование SDN позволяет на 20–30% увеличить утилизацию ресурсов ЦОД и в несколько раз снизить эксплуатационные расходы.

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

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

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

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

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

BitTorrent BitTrrent[31] — пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет.

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

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

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

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

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

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

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

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

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

Сегменты делятся на блоки размером 16-4096 килобайт, и каждый клиент запрашивает именно эти блоки. Одновременно могут запрашиваться блоки из разных сегментов. Более того, некоторые клиенты поддерживают скачивание блоков одного сегмента у разных пиров. В этом случае описанные выше алгоритмы и механизмы обмена применимы и к уровню блоков.

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

Общие особенности Отсутствие очередей на скачивание.

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

Клиенты (peers) обмениваются сегментами непосредственно между собой, по принципу «ты — мне, я — тебе».

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

Контролируется целостность каждого фрагмента.

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

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

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

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

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

Multicast Multicast — специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов — не одному (unicast), и не всем (broadcast).[5][21] Наряду с приложениями, устанавливающими связь между источником и одним получателем, существуют такие, где требуется, чтобы источник посылал информацию сразу группе получателей. В качестве таких приложений можно упомянуть дистанционное обучение, рассылку корпоративной информации, репликацию баз данных и информации веб-сайтов и многое другое. При традиционной технологии IP-адресации требуется каждому получателю информации послать свой пакет данных, то есть одна и та же информация передается много раз. Технология групповой адресации представляет собой расширение IP-адресации, позволяющее направить одну копию пакета сразу всем получателям. Множество получателей определяется принадлежностью каждого из них к конкретной группе. Рассылку для конкретной группы получают только члены этой группы.

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

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

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

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

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

Технология IP Multicast использует адреса с 224.0.0.0 до 239.255.255.255.

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

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

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

Статический и динамический контент CDN может проектироваться как для раздачи статического контента(медиа-файлы, статические файлы js и css, крупные файлы любого типа) так и динамического(ускорение отдачи динамических веб-страниц, edge-computing, потоковые данные). Проблемы возникающие при построение этих двух типов CDN различных, хотя и частично пересекаются. Алгоритмы и решения рассматриваемые в данной работе в первую очередь относятся к сетям со статическим контентом, но некоторые из них(выбор оптимального пути внутри CDN) могут быть применены и для сетей с динамическим контентом.[ Балансировка на уровне DNS Round robin DNS — один из методов распределения нагрузки, или отказоустойчивости за счёт избыточности количества серверов, с помощью управления ответами DNS-сервера в соответствии с некой статистической моделью. Обычно применяется к таким интернет-протоколам, как веб-серверы, FTP-серверы.[15][6] В простейшем случае Round robin DNS работает, отвечая на запросы не только одним IP-адресом, а списком из нескольких адресов серверов, предоставляющих идентичный сервис. Порядок, в котором возвращаются IP-адреса из списка, основан на алгоритме round-robin. С каждым ответом последовательность ipадресов меняется. Как правило, простые клиенты пытаются устанавливать соединения с первым адресом из списка, таким образом разным клиентам будут выданы адреса разных серверов, что распределит общую нагрузку между серверами.

Не существует стандартной процедуры для определения того, какие адреса будут использоваться запрашивающим приложением — некоторые серверы пытаются изменить порядок списка, уделяя приоритетное внимание численно более «близким» сетям. Некоторые настольные клиенты пытаются получить альтернативные адреса после того, как не удалось установить соединение в течение 30-45 секунд.

Круговая система DNS часто используется для распределения нагрузки территориально распределённых веб-серверов. Например, у компании есть один домен и три идентичных веб-сайта, расположенных на трёх серверах с тремя разными адресами. Когда один пользователь получает доступ к главной странице, он будет направлен на первый адрес IP. Второй пользователь, обращающийся к главной странице, будет отправлен на следующий адрес IP, а третий пользователь будет отправлен на третий адрес IP. В каждом случае, когда IP-адрес выдается, он отправляется в конец списка. Четвертый пользователь, следовательно, будет отправлен вновь на первый адрес IP, и так далее.

Недостатки Хотя Round robin DNS (RR DNS) легко реализовать, всё же этот алгоритм имеет несколько проблематичных недостатков, связанных с кэшированием записи в иерархии RR DNS самого себя, а также с кэшированием на стороне клиента, выданного адреса и его повторного использования, сочетание которых трудно управляемо. RR DNS не опирается на доступность услуг. К примеру, если сервис на одном из адресов недоступен, RR DNS будет продолжать раздавать этот адрес и клиенты будут по-прежнему пытаться соединиться с неработающим сервером.

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

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

Некоторые проблемы DNS балансировки, такие как скорость переключения на новый сервер, можно частично решить при помощи IPVS. IPVS реализует балансировку на транспортном уровне внутри ядра Linux. IPVS является частью Linux Virtual Server, в рамках которого работает в качестве балансировщика перед кластером реальных серверов. IPVS может перенаправлять запросы на реальные сервера так, что для внешнего наблюдателя сервисы реальных серверов будут находиться на одном IP-адресе.[16] BGP BGP (англ. Border Gateway Protocol, протокол граничного шлюза) — основной протокол динамической маршрутизации в Интернете.[30] Протокол BGP предназначен для обмена информацией о достижимости подсетей между автономными системами (АС), то есть группами маршрутизаторов под единым техническим управлением, использующими протокол внутридоменной маршрутизации для определения маршрутов внутри себя и протокол междоменной маршрутизации для определения маршрутов доставки пакетов в другие АС.

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

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

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

BGP является протоколом прикладного уровня и функционирует поверх протокола транспортного уровня TCP (порт 179). После установки соединения передаётся информация обо всех маршрутах, предназначенных для экспорта. В дальнейшем передаётся только информация об изменениях в таблицах маршрутизации. При закрытии соединения удаляются все маршруты, информация о которых передана противоположной стороной.[28][26] Мониторинг состояния сети Управляющая система должна иметь полную информацию о состоянии сетевого оборудования и серверов поддерживающих ее функционирование. Для этого используются следующие технологии.

SNMP SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IPсетях на основе архитектур UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.[23] SNMP предоставляет данные для управления в виде переменных, описывающих конфигурацию управляемой системы. Эти переменные могут быть запрошены (а иногда и заданы) управляющими приложениями.

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

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

Агенты SNMP обрабатывают данные о конфигурации и функционировании управляемых систем и преобразуют их во внутренний формат, удобный для поддержания протокола SNMP. Протокол также разрешает активные задачи управления, например, изменение и применение новой конфигурации через удаленное изменение этих переменных. Доступные через SNMP переменные организованы в иерархии. Эти иерархии, как и другие метаданные (например, тип и описание переменной), описываются базами управляющей информации (базы MIB, от англ. Management information base).

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

Управляемое устройство;

Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;

Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети.

Управляемое устройство — элемент сети (оборудование или программное средство), реализующий интерфейс управления (не обязательно SNMP), который разрешает однонаправленный (только для чтения) или двунаправленный доступ к конкретной информации об элементе. Управляющие устройства обмениваются этой информацией с менеджером. Управляемые устройства могут относиться к любому виду устройств: маршрутизаторы, серверы доступа, коммутаторы, мосты, концентраторы, IP-телефоны, IP-видеокамеры, компьютеры-хосты, принтеры и т.п.

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

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

Алгоритмы распределения запросов Существует несколько алгоритмов, которые могут быть использованы для выбора сервера при маршрутизации запроса. Наиболее простыми в реализации являются случайный выбор (англ. Random Choice - RC) и поочередный выбор (англ. Round Robin - RR). Кроме этих двух алгоритмов существуют алгоритмы, выбирающие наиболее подходящий сервер исходя из некоторых параметров, таких как доступная пропускная способность канала (англ. bandwidth availability - BW), доступность носителя информации (англ. hard disk availability - HD) и количество текущих подключений к серверу или доступность соединения (англ. connection availability - CON).[12][17] Когда система направляет запрос пользователя к одному из серверов с использованием одного из пяти приведенных алгоритмов пропускная способность канала от клиента до сервера, загруженность носителя информации и количество подключений к серверу являются тремя важными факторами, по которым определяется, может ли сервер обслужить запрос клиента. Если хотя бы по одному из этих параметров сервер перегружен, запрос будет отклонен, а это значит что CDN не сможет обработать запрос клиента. В архитектуре сетей доставки контента минимизация процента отклоненных запросов наиболее важный фактор при сравнении производительности различных алгоритмов.

Алгоритм принятия решений с использованием нечеткой логики Для данного алгоритма BW, HD и CON являются входными параметрами.

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

На первом этапе входные параметры преобразуются в соответствующие значения нечеткой логики согласно функциям принадлежности. Определяются функции принадлежности для каждого входного параметра. Для параметра доступности канала (BW) эта функция будет выглядеть следующим образом. HBW - высокая значение принадлежности для пропускной способности канала, MBW - среднее значение и LBW - низкое значение соответственно.[20][22] Значения принадлежности HHD, MHD, LHD для носителя информации и HCON, MCON, LCON для количества соединений определяются аналогично.

На втором этапе происходит вычисление правил. Имеется 9 значений принадлежности (HBW, MBW, LBW, HHD, MHD, LHD, HCON, MCON, LCON).

Существует 27 возможных комбинаций этих значений. Для каждой из этих комбинаций мы определяем нечеткое решение из четырех возможных Настоятельно рекомендуемый сервис - Да (Yes, Y) Рекомендуемый сервис - Возможно да (Probably yes, PY) Не рекомендуемый сервис - Возможно нет (Probably no, PN) Настоятельно не рекомендуемый сервис - Нет (No, N) Каждое значение нечеткого решения FD является минимумом из трех значений принадлежности.

FD = min {HBW/MBW/LBW, HHD/MHD/LHD, HCON/MCON/LCON}

BW HD CON FD

HBW HHD HCON Y

HBW HHD MCON Y

HBW HHD LCON PY

HBW MHD HCON Y

HBW MHD MCON Y

HBW MHD LCON PY

HBW LHD HCON PY

HBW LHD MCON PY

HBW LHD LCON PN

MBW HHD HCON PY

MBW HHD MCON PY

MBW HHD LCON PY

MBW MHD HCON PY

MBW MHD MCON PN

MBW MHD LCON PN

MBW LHD HCON PY

MBW LHD MCON PN

MBW LHD LCON PN

LBW HHD HCON PY

LBW HHD MCON PN

LBW HHD LCON PN

LBW MHD HCON PN

LBW MHD MCON N

LBW MHD LCON N

LBW LHD HCON PN

LBW LHD MCON N

LBW LHD LCON N

Таким образом получается 27 значений принадлежащих к четырем группам. Из каждой группы берется минимум. В результате получается четыре значения FD(Y), FD(PY), FD(PN) и FD(N).

На третьем этапе алгоритма четырем значениям решения назначается набор взвешенных значений. Каждое значение представляет различный набор весов.

Итоговое "четкое" значение (англ. Crisp Value - CV) вычисляется на основе взвешенных значений и значений нечетких решений.

Каждый сервер вычисляет собственное CV. Система распределения запросов может использовать CV для определения наиболее подходящего сервера для обработки запроса. Сервер с самым высоким CV является предпочтительным для достижения оптимальной производительности CDN.

Симуляция проводилась в сравнении с алгоритмами RC, RR, BW, HD, CON. По вертикальной оси графика количество отклоненных запросов в процентах. По горизонтальной оси среднее время между запросами в миллисекундах.

Так как алгоритмы RC и RR не используют никаких параметров для распределения запросов, для них процент отклоненных запросов высок. При использовании только одного параметра (BW, HD, CON) процент отклоненных запросов ниже чем у RC и RR. Описанный алгоритм показывает лучшие результаты так как учитывает сразу все три параметра.

Рассмотренный алгоритм можно развить введя дополнительные параметры, такие как задержка(latency) или загруженность процессора. Также возможно развитие в направлении комбинирования с алгоритмами нахождения пути во взвешенном графе, где веса дуг будут определятся с использованием рассмотренного алгоритма.[14] Реализация Характеристика модельной сети доставки контента Модельная сеть доставки контента создавалась на основе виртуальных машин находящихся на двух физических хост-машинах. Это позволило моделировать различные топологии сети, а также варьировать производительность виртуальных машин и пропускную способность каналов. Количество виртуальных машин варьировалось от 5 до 15 в различных тестах. Отдача контента осуществлялась при помощи веб-сервера nginx. Управление распределением копий контента и маршрутизацией запросов осуществлялась при помощи изменения конфигурационных файлов nginx управляющим модулем системы.

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

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

Django Фреймворк - Это каркас программной системы (или подсистемы). Может включать вспомогательные программы, библиотеки кода, язык сценариев.

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

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

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

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

Twisted Twisted — это событийно-ориентированный сетевой фреймворк, написанный на Python и распространяемый под лицензией MIT. Архитектура и концепции twisted оптимально подходят для модуля управления узлом сети. Все операции выполняемые модулем являются реакцией на некие внешние события. Также модуль выполняет большое количество операций связанных с сетевым взаимодействием и асинхронность выполнения этих операций является необходимым атрибутом. В twisted уже реализовано большое количество сетевых протоколов, в частности необходимые для данной задачи SNMP и HTTP.

Nginx nginx — быстрый и надёжный сервер, обладающий всем необходимым для построения модельной сети функционалом.

Основные особенности:

обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кеш дескрипторов открытых файлов проброс запросов без кэширования, распределение нагрузки и отказоустойчивость поддержка кеширования при ускоренном проксировании и FastCGI ускоренная поддержка FastCGI и memcached серверов, простое распределение нагрузки и отказоустойчивость модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), частичные ответы, HTTP-аутентификация, SSI-фильтр несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно поддержка SSL поддержка PSGI, WSGI В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их асинхронными вызовами операционной системы такими как select, epoll. Рабочие процессы выполняют цикл обработки событий от дескрипторов. Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту.

Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива server). Виртуальные серверы разделяются на отдельные расположения (location). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать * для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.

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

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

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

Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок.

Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.

nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде Radix tree (сжатое префиксное дерево или сжатый бор) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева, таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.

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

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

Поскольку Python — интерпретируемый язык, математические алгоритмы часто работают в нём гораздо медленнее, чем в компилируемых языках, таких как Cи или Java. NumPy пытается решить эту проблему для большого количества вычислительных алгоритмов, обеспечивая поддержку многомерных массивов и множество функций и операторов для работы с ними. Таким образом, любой алгоритм, который может быть выражен в основном как последовательность операций над массивами и матрицами, работает так же быстро, как эквивалентный код, выполняемый в MATLAB, а после специальной оптимизации скорость может достигнуть скорости компилируемых языков типа Cи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для решения этой задачи был применен Марковский процесс принятия решений[22][34][35]. Состояние процесса описывается вектором, определенным выше. Множество состояний определяется как:

Моделируем агрегированный запрос к контенту k на сервере как процесс рождения смерти с коэффициентом рождаемости и коэффициентом смертности В зависимости от состояния системы может быть принято решение - удаление копии контента. Пространство действий описывается как Индикатор отображает решение добавить копию контента k на сервер отображает решение убрать копию контента k с сервера. Если все индикаторы равны нулю, то расположений копий остается неизменным. Для упрощения модели только одна копия может быть добавлена или удалена в каждый из моментов принятия решения.

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

Переходы связанные с отправкой ответа на запрос на контент сервера :

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

Таким образом формулируется неоднородная функция стоимости:

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

Норма однородного процесса определяется следующим образом.

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

Оптимальное решение описывается с помощью переменной принятия решения отражающей вероятность системы принять решение d будучи в состоянии x.

Задача линейного программирования для данного Марковского процесса минимизирующая издержки в долгосрочной перспективе формулируется следующим образом:

Где S это конечно множество всех возможных пар векторов (состояние, решение).

Данная задача может быть решена средствами известных методов исследования операций[35].

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

Возможность обслуживать запросы; Минимизация количества копий;

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

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

На основании этих наблюдений предлагается следующий эвристический алгоритм.

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

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

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

Топология а Средняя дистанция Среднее кол-во копий % отклоненных запросов решение Средняя дистанция Среднее кол-во копий % отклоненных запросов решение Топология б Средняя дистанция Среднее кол-во копий % отклоненных запросов решение Средняя дистанция Среднее кол-во копий % отклоненных запросов Для топологии C расчет оптимального расчет оптимального решения не проведен ввиду вычислительной сложности.

Топология с Средняя дистанция Среднее кол-во копий % отклоненных запросов Средняя дистанция Среднее кол-во копий % отклоненных запросов Средняя дистанция Среднее кол-во копий % отклоненных запросов Результаты симуляций показывают, что эвристический алгоритм почти не уступает оптимальному решению на простых топологиях. На сложных топологиях прямое сравнение невозможно, но можно заметить, что результаты близки к оптимальному решению. Мы можем вычислить среднее количество запросов с каждого узла доступа равное 0,4. Умножение на количество серверов дает 19.2 запросов в среднем. Каждая копия может обслуживать K = 2 запросов. Таким образом, для C = 1и ожидается не менее 10 копий. Результаты симуляции эвристического алгоритма близки к 10. При этом его вычислительная сложность допускает использование в реальных системах.

Заключение В магистерской диссертации получены следующие основные результаты:

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

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

Алгоритм реализован в рамках модельной сети доставки контента Алгоритм опробован на модельных данных, результаты подтверждают снижение процента отклоненных пакетов и равномерность распределения запросов по серверам Литература 1. J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl, “Globally Distributed Content Delivery,” IEEE Internet Computing, pp. 50-58, September/October 2002.

2. Akamai Technologies, Inc., www.akamai.com, 3. Y. Rekhter, and T. Li, “A Border Gateway Protocol 4,” Internet Engineering Task Force RFC 1771, March 1995.

4. J. Ni, and D. H. K. Tsang, “Large Scale Cooperative Caching and Applicationlevel Multicast in Multimedia Content Delivery Networks,” IEEE Communications, Vol. 43, Issue. 5, pp. 98-105, May 2005.

5. Internet Content Distribution: Developments and Challenges. Adrian Popescu, David Erman, Dragos Ilie, Doru Constantinescu 6. On the Optimal Placement of Web Proxies in the Internet. Li B., Golin M.J., Italiano G.F., Deng X. and Sohraby K., IEEE INFOCOM 1999, New York, USA, 7. ROVER.Routing in Overlay Networks. Popescu A., Kouvatsos D., Remondo D.

and Giordano S., EuroNGI project JRA.S.26, 8. M. Esteve, G. Fortino, C. Mastroianni, C. E. Palau, and W. Russo, “CDNsupported Collaborative Media Streaming Control,” IEEE Multimedia, 2007.

9. S. Scellato, C. Mascolo, "Track Globally, Deliver Locally: Improving Content Delivery Networks by Tracking Geographic Social Cascades" 10. H. Yin, X. Liu, T Zhan, "Design and Deployment of a Hybrid CDN-P2P System for Live Video Streaming" 11. Akamai Technologies, Inc. A Distributed Infrastructure for e-Business — Real Benefits, Measurable Returns. 12. Amit Aggarwal and Michael Rabinovich. Performance of dynamic replication schemes for an internet hosting service. Technical Report HPL-2001-8, AT&T Labs, October 1998.

13. William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, and Jeremy Lilley.

The design and implementation of an intentional naming system. In Proceedings of the 17th ACM Symposium on Operating System Principals, December 1999.

14. Yair Bartal. Probabilistic approximation of metric space and its algorithmic applications. In 37th Annual IEEE Symposium on Foundations of Computer Science, October 1996.

15. M. Baentsch, L. Baum, G. Molter, S. Rothkugel, and P. Sturm. Enhancing the web infrastructure - from caching to replication. IEEE Internet Computing, pages 18– 27,Mar-Apr 1997.

16. Rajkumar Buyya, Al-Mukaddim Khan Pathan, James Broberg and Zahir Tari. A Case for Peering of Content Delivery Networks 17. G. Peng, CDN: Content Distribution Network, Technical Report TR-125, Experimental Computer Systems Lab, Department of Computer Science, State University of New York, Stony Brook, NY 2003.

http://citeseer.ist.psu.edu/peng03cdn.html 18. OpenCDN project home page. http://labtel.ing.uniroma1.it/opencdn/ 19. A. Vakali and G. Pallis, Content Delivery Networks: Status and Trends, IEEE Internet Computing, IEEE Computer Society, pp. 68-74, November-December 2003.

20. A Fuzzy-based Decision Approach for Supporting Multimedia Content Request Routing in CDN. Jian-Bo Chen, Shao-Jun Liao 21. Jian-Bo Chen, Tsang-Long Pao, "Designing the Burst Web Load Balancing Architecture Using Fuzzy Decision," Trans. International Journal of Innovative Computing, Information and Control, Vol. 5, No. 6, pp. 1689-1698, June. 2009.

22. Broberg, J., Zeephongsekul., P., and Tari, Z. Approximating bounded general service distributions, In Proc. of IEEE Symposium on Computers and Communications, Aveiro, Protugal, Jul. 2007.

23. Day, M., Cain, B., Tomlinson, G., and Rzewski, P. A model for content internetworking. IETF RFC 3466, Feb. 2003.

24. Architecture and Performance Models for QoS-Driven Effective Peering of Content Delivery Networks. Mukaddim Pathan, Rajkumar Buyya 25. Amazon CloudFront. http://aws.amazon.com/cloudfront/ 26. oStream: Asynchronous Streaming Multicast in Application-Layer Overlay Networks. Cui Y., Li B. and Nahrstedt K.,, IEEE Journal on Selected Areas in Communications, Vol 22, No 1, January 27. Martin Casado, Tal Garfinkel, Aditya Akella, Michael J. Freedman Dan Boneh, Nick McKeown, Scott Shenker. SANE: A Protection Architecture for Enterprise Networks, 15-th Usenix Security Symposium, Vancouver, Canada, August 2006.

28. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner. Openflow: Enabling innovation in campus networks.

SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008.

29. RFC 3170, IP Multicast Applications: Challenges and Solutions 30. RFC 4271, A Border Gateway Protocol 4 (BGP-4); RFC 4274, BGP-4 Protocol Analysis 31. Arnaud Legout, Guillaume Urvoy-Keller: Understanding BitTorrent: An Experimental Perspective, PLANETE(INRIA Sophia Antipolis), 32. Openflow project site, http://www.openflow.org/ 33. A.T.Bharucha-Raid. Elements of theory of Markov processes and their applications. McGraw-Hill, 34. J.Keilson. Markov chain models. Rarity and exponentiality. Springer-Verlag, New York, 35. Акулич И.Л. Математическое программирование в примерах и задачах. — М.: Высшая школа, 1986.

Глоссарий SDN (Software Defined Network) - программно конфигурируемая сеть, сеть использующая технологии виртуализации сетевого оборудования.

Хоп - переход от одного узла сети к другому при маршрутизации запроса Нода(англ. node) - сервер входящий в сеть доставки контента Пир — в протоколе BitTorrent клиент, участвующий в раздаче.

Лич — в протоколе BitTorrent пир, не имеющий пока всех сегментов, то есть продолжающий скачивание.

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