Наверх

Фото: Сирант Андрей Васильевич

Сирант Андрей Васильевич

Факультет компьютерных наук и технологий

Кафедра программной инженерии

Специальность «Программная Инженерия»

Исследование эффективности сетевых протоколов в клиент-серверных приложениях

Научный руководитель: к.т.н., доцент Грищенко Виктор Игоревич

Реферат по теме выпускной работы

Содержание

Цель

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

Задачи

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

  1. Обзор существующих протоколов передачи данных
  2. Обзор продвинутых протоколов на основе UDP и TCP
  3. Формулировка задач в виде критериев эффективности сетевых протоколов и способов измерения метрик
  4. Выбор инструментальных средств для анализа сетевого трафика и измерения эффективности сетевых протоколов
  5. Исследование протоколов транспортного уровня в Unity [1]
  6. Разделение сетевого трафика клиент-серверного приложения по каналам связи использующих различные протоколы Unity
  7. Измерение эффективности сетевых операций, анализ трафика в различных операционных средах и с использованием веб-сокетов
  8. Оптимизация клиент-серверного приложения с учетом полученных данных

Актуальность темы работы

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

Предполагаемая научная новизна

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

Планируемые практические результаты

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

1 Обзор исследований и разработок

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

Данные протоколы были разработаны десятилетия назад и в некоторых случаях не отвечают поставленным перед ними требованиям. Данная проблема, например, возникла при повышении производительности распределенных вычислений, когда по магистральным сетям требовалось передавать огромные массивы данных – TCP был слишком медленен, а UDP ненадежен [2]. Поэтому было разработано множество усовершенствованных протоколов, как на основе UDP, так и на основе TCP [3,4]. Однако, в ключе производительности протоколы, основанные на UDP, выгодно выделяются на фоне расширений TCP, поэтому им было уделено особое внимание исследователей за последнее десятилетие.

1.1 Обзор международных разработок

Согласно исследованиям [5], на производительность протоколов TCP и UDP влияет не только ширина канала связи, размер буфера сокета или выбранный размер сообщений, но и такие факторы как:

  • использование возможностей ядра ОС во избежание создания лишних временных копий памяти, и, таким образом, оптимизация времени использования ЦП, чтобы между посылкой двух отдельных пакетов не было простоя
  • использование высокочастотного таймера для контроля уровня отправки пакетов, чтобы избегать их массовых одновременных выбросов (актуально для огромного количества данных и канала связи, например 1Гбит/с)
  • использование многопоточности, которое может как ускорить процесс обмена данными, так и замедлить, так как добавляется процесс синхронизации потоков
  • алгоритм подтверждений о доставке пакета или набора пакетов
  • алгоритм обработки ситуации, когда пакет был потерян

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

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

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

UDP-based Data Transfer Protocol (UDT) – высокопроизводительный протокол для передачи данных большого объёма на высокой скорости по магистральным сетям [8]. Первоначально был разработан и протестирован на очень высокоскоростных сетях (1Гбит / с, 10 Гбит / с, и т.д.), тем не менее, последние версии протокола были обновлены для поддержки обычного Интернета. Это - одно из самых популярных решений для поддержки высокоскоростной передачи данных и является частью многих научно-исследовательских проектов и коммерческих продуктов.

Scalable TCP – модификация TCP, которая предназначена для обеспечения гораздо более высокой пропускной способности и масштабируемости [3]. Масштабируемый TCP изменяет алгоритм управления перегрузкой. Вместо того, чтобы сократить вдвое размер окна перегрузки, каждая потеря пакета уменьшает окно перегрузки на небольшую долю (в 1/8 раз вместо 1/2 стандартного TCP), пока потеря пакетов не остановится. Когда потеря пакетов прекращается, скорость увеличивается на медленной фиксированной скорости (один пакет добавляется для каждой сотни успешных подтверждений) вместо стандартной скорости восстановления TCP, где это обратная от размера окна перегрузки величина (таким образом, для очень больших окон восстановление занимает очень много времени). Это позволяет сократить время восстановления на канале связи 10 Гбит/с с 4+ часов (с использованием стандартного TCP) до менее чем 15 секунд, когда время пакета в пути составляет 200 миллисекунд.

QUIC (Quick UDP Internet Connections) – новый протокол от Google поверх протокола UDP. Протокол предназначен, в первую очередь, для работы с HTTP/2, так как мультиплексирование и установка соединения (части HTTP/2 протокола) уже реализованы в QUIC. Также QUIC имеет собственный слой шифрования вместо TLS 1.2. Также в протокол включена превентивная коррекция ошибок – каждый пакет на 10% содержит в себе данные других пакетов, что позволяет реконструировать любой потерянный пакет по данным в его соседях. Браузер Chrome имеет экспериментальную поддержку QUIC с 2014-го года, со стороны бэкенда QUIC поддерживают такие сервисы от Google как Youtube и Google Search. Если QUIC докажет свою эффективность, то есть шанс, что опробованные в нём идеи станут частью следующей версии TCP [9].

1.2 Обзор национальных разработок

В Украине разработка сетевых протоколов общего назначения на основе UDP или TCP практически не велась. Однако есть работа связанная с использованием стека TCP/IP для телекоммуникаций с изменяющимся размером сетевого адреса (EX) [12]. Данная работа была проведена в Институте телекоммуникаций и глобального информационного пространства Национальной академии наук Украины старший научным сотрудником Гуляевым Кириллом Дмитриевичем.

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

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

В Национальном техническом университете Киевский политехнический институт была создана работа Реализация сетевых протоколов как независимых процессов. В статье рассматривается подход к реализации протоколов, который позволяет реализовывать логику каждого сетевого протокола в стеке полностью независимо от других протоколов[13].

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

Так, в Харьковском национальном университете воздушных сил в 2009 году вышло издание Особенности реализации протокола TCP в современных компьютерных сетях, где рассматриваются вопросы реализации современных версий ТСР [11]. А в Национальном авиационном университете было проведено исследование протоколов для построения маршрутов в сетях Ethernet класса Metro [14].

1.3 Обзор локальных разработок

Магистры ДонНТУ прежде не разрабатывали или подробно исследовали сетевые протоколы транспортного уровня на основе TCP или UDP, однако есть некоторые исследования по реализации протоколов маршрутизации и протоколов канального уровня:

2 Сетевые протоколы в Unity

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

В Unity реализован высокопроизводительный транспортный протокол на основе UDP, которому можно задавать разные параметры QoS (Quality of Service – качество обслуживания). QoS – это критерий, которым должен руководствоваться протокол во время своей работы. Разработчики Unity реализовали несколько вариантов QoS параметра [1]:

  • Unreliable – ненадежное сообщение, которое может быть потеряно из-за сетевых проблем или внутреннего переполнения буфера, аналогично UDP пакету. Канал связи с данным типом QoS может быть использован для логирования некритичных процессов в приложении.
  • UnreliableFragmented – максимальная длина пакета неизменна, но этот тип канала перед отправлением будет разбирать длинные сообщения на фрагменты и собирать их обратно перед получением. Так как такое качество обслуживания ненадежно, доставка не гарантируется. Пример применения: логирование длинных записей в журнал.
  • UnreliableSequenced – канал обеспечивает порядок доставки, но так как это качество обслуживания ненадежно, сообщение может быть потеряно. Данный тип канала может применяться для передачи голосовых или видео-сообщений, позволяя высокую производительность.
  • Reliable – канал гарантирует доставку (или разрыв соединения), но не гарантирует порядок. Пример применения: передача данных о единовременных событиях в игре, например, получение урона игроком.
  • ReliableFragmented – то же, что и UnreliableFragmented, но в дополнение к нему гарантирует доставку. Применять в случаях когда нужен надежный канал данных, при этом не важен порядок и пакеты имеют большой размер.
  • ReliableSequenced – то же, что и UnreliableSequenced, но дополнительно гарантирует доставку. Этот QoS аналогичен потоку TCP. Пример применения: передача файлов и патчей.
  • StateUpdate – ненадежный тип канала, принудительно сбрасывающий пакеты старше получаемого/отправляемого. Если при передаче буфер содержит более одного сообщения, отправлено будет только самое свежее. Если буфер получателя при чтении содержит более одного сообщения, только самое свежее будет доставлено. Пример применения: передача расположения.
  • ReliableStateUpdate – то же, что и StateUpdate, но дополнительно гарантирует доставку.
  • AllCostDelivery – очень похож на Reliable, но есть отличия. Надежный канал будет повторно отсылать сообщения на основании времени прохождения сигнала в обоих направлениях (round trip time value (RTT)), которое определяется динамически, в то время как AllCostDelivery будет автоматически пересылать сообщения после определенного промежутка времени (задается в настройках). Это может быть полезно для маленьких но важных сообщений.

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

Рисунок 1 - Настройки каналов связи компонента NetworkManager

Рисунок 1 – Настройки каналов связи компонента NetworkManager

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

Данные о положении и перемещении любых сущностей имеющих положение в пространстве передаются с помощью компонента NetworkTranform. Для остальных данных (для каждой переменной в коде программы) создаются так называемые атрибуты синхронизации SyncVar – значения этих переменных будут синхронизироваться между сервером и клиентами. Эти данные по умолчанию отправляются по каналу номер 0 (нуль), который по умолчанию имеет QoS Reliable Sequenced (что практически эквивалентно отправке по TCP).

Однако, данные каналы можно менять на уровне скриптов-компонентов с помощью атрибута NetworkSettings [7]. Данный атрибут принимает два параметра - номер канала и интервал синхронизации. Стоит учесть, что интервал синхронизации в данном случае действует лишь как ограничитель. Состояния переменной с атрибутом SyncVar передаются по сети лишь в тот момент, когда она была изменена. Если такая переменная меняется очень часто, например, при каждом кадре просчета игровой сцены, то это может привести к переполнению канала связи, поэтому с момента изменения переменной ожидается указанный интервал времени, и только затем состояние переменной передается по сети. Стандартный интервал-ограничитель равен 100 мс. Пример кода простейшего скриптового компонента Unity с синхронизацией данных по сети показан ниже на рис.2. 

using UnityEngine.Networking;

[NetworkSettings(channel = 1, sendInterval = 0.2f)]
class MyScript : NetworkBehaviour
{
    [SyncVar]
    int value;
}

Рисунок 2 – Код компонента Unity с атрибутом NetworkSettings и переменной с атрибутом SyncVar

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

Данное множество тестов будет также проведено на нескольких платформах - Windows, Linux и WebGL (с использованием технологии веб-сокетов). Тестирование функционирования приложения на Linux и WebGL будет проведено как локально, так и удаленно, с развертыванием приложения на реально выделенном сервере (VPS) и веб-сервере (хостинге) соответственно.

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

Исследуемое клиент-серверное приложение является игровым приложением, основанным на технологии Unity, которая обеспечивает хорошую кроссплатформенность, и будет развертываться в виде десктопного приложения на PC (Windows, Linux) и в виде браузерного приложения на WebGL.

Серверная часть приложения находится на удаленном сервере, который функционирует на операционной системе CentOS 7. В приложении используется технология Barebones Master Server, которая обеспечивает быстрое создание инфраструктуры для функционирования данного онлайн-приложения. Серверная часть состоит из трех модулей: Мастер Сервера (Master Server), Спавнера (Spawner) и Хоста (Host).

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

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

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

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

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

Функционирование сетевой архитектуры исследуемого клиент-серверного приложения в динамике

Рисунок 3 – Функционирование сетевой архитектуры исследуемого клиент-серверного приложения в динамике (анимация: 15 кадров, 5 циклов повторения, 124 килобайт)

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

Первая БД – это упрощенная БД аккаунтов и профилей на Мастер Сервере. По умолчанию Barebones Master Server использует LiteDB – эта технология является легковесной СУБД на основе файлов.

Вторая БД содержит полную информацию об аккаунтах и созданных игровых картах, которые привязаны к аккаунту. Она расположена на облачном сервисе MLab, при этом используется NoSQL СУБД MongoDB. Преимущества данной технологии в том, что размер записи может сильно варьироваться в зависимости от размера сохраненной игровой карты, что позволяет экономить место на носителе. Недостаток данной СУБД в том, что при запросе к ней используется не SQL, а RESTful API. Таким образом, сложные логические операции и фильтрование данных должно происходить уже в самом приложении, после получения всех сырых данных.

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

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

Первый недостаток – это излишняя информация об аккаунтах, которая частично дублируется и в LiteDB, и в MongoDB. Таким образом, для входа в игру приложение на стороне пользователя ждет пока не пройдут успешно оба запроса об авторизации. Также возникают вопросы с точки зрения информационной безопасности. Данный недостаток возник из-за недостатка временных ресурсов и может быть устранен путем реализации класса-адаптера для СУБД MongoDB (фреймворк предусматривает это).

Второй недостаток, который заметен самому пользователю – это медленное извлечение и запись данных в MongoDB. Дело в том, что в целях безопасности на стороне веб-хостинга было написано промежуточное API для обращения к базе данных на сервисе MLab. Приложение общается с БД аккаунтов и карт исключительно через это API. Более того, быстродействие замедляется еще больше из-за того, что на сервисе MLab выбран бесплатный тестовый тарифный план (так называемая песочница), который ограничен в быстродействии. Все это приводит к длинной авторизации при входе в игру и загрузке игровых карт при входе в редактор карт. Для устранения данного недостатка рассматривается перенос данных на собственный выделенный сервер и запуск СУБД MongoDB.

4 Методы и инструменты измерения эффективности сетевых протоколов

Рассмотрим несколько инструментов для измерения эффективности сетевых протоколов . Первый из них – это встроенный в Unity профилировщик, который может измерять производительность не только CPU и GPU, но и количество сетевых операций. Окно данного профилировщика показано ниже на рис.4.

Профилировщик сети в Unity

Рисунок 4 – Профилировщик сети в Unity

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

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

Однако, при всей мощи у Wireshark есть небольшой недостаток - это отсутствие обширного графического представления статистики. В меню Статистика предоставляется общий обзор набора перехваченных данных, в основном в табличном виде. Хотя есть и некоторые графики, такие как График Входа/Выхода (I/O Graph) – данный график полностью редактируем, в него можно добавлять элементы, получаемые с помощью той же мощной системы фильтрации перехваченного потока данных. Пример такого графика с добавлением отображения статистики по UDP пакетам представлен ниже на рис.5.

I/O Graph в Wireshark

Рисунок 5 – I/O Graph в Wireshark

Существуют дополнительные способы представления данных, захваченных с помощью Wireshark – это инструменты, которые расширяют графические возможности Wireshark (однако, многие из них являются платными), а также любые другие инструменты, визуализирующие данные в формате CSV. Wireshark может экспортировать все данные в такой файл, который в дальнейшем можно открыть в другом приложении, например Microsoft Excel.

В качестве альтернативы была рассмотрена программа Colasoft Capse Free. Данная программа представляет множество информации в графическом формате и имеет удобный интуитивно понятный интерфейс. Скриншот данной программы представлен ниже на рис. 6.

Интерфейс программы Colasoft Capse Free

Рисунок 6 – Интерфейс программы Colasoft Capse Free

Однако, бесплатная версия данной программы ограничена. Например, максимальный объем буфера для записанных в память пакетов составляет всего 8Мб, что очень мало для исследуемого клиент-серверного приложения, которое интенсивно использует сетевой трафик. Поэтому выбор пал на Wireshark в качестве основного инструмента исследования.

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

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

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

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

Данное множество тестов будет проведено на платформах Windows, Linux и WebGL (с использованием технологии веб-сокетов). При тестировании в ОС Windows есть возможность локального запуска как клиентской, так и серверной части приложения, что облегчит сбор данных. В ОС Linux самым главным объектом тестирования является серверная часть, которая будет протестирована при разных нагрузках на приложение. Для тестирования веб-сокетов на платформе WebGL серверная часть, которая все так же будет работать на ОС Linux, должна будет быть перекомпилирована. При этом клиентская часть будет расположена на веб-ресурсе и запускаться через любой современный браузер.

Выводы

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

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

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

Список источников

  1. UNET — новая сетевая технология в Unity 3D // Хабрахабр [Электронный ресурс]. — Режим доступа: https://habrahabr.ru/post/228395/
  2. Eric He, Jason Leigh, Oliver Yu, Thomas A. DeFanti. Reliable Blast UDP : predictable high performance bulk data transfer // ResearchGate [Электронный ресурс]. — Режим доступа: https://www.researchgate.net/publication/3985811...
  3. Tom Kelly. Scalable TCP: Improving Performance in Highspeed Wide Area Networks // CERN [Электронный ресурс]. — Режим доступа: http://datatag.web.cern.ch/datatag/papers/pfldnet2003-ctk.pdf
  4. David X. Wei, Cheng Jin, Steven H. Low, Sanjay Hegde. FAST TCP: Motivation, Architecture, Algorithms, Performance // NetLab CalTech [Электронный ресурс]. — Режим доступа: http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf
  5. Yunhong Gu, Robert L.Grossman. Optimizing UDP-based Protocol Implementations // SourceForge [Электронный ресурс]. — Режим доступа: http://udt.sourceforge.net/doc/pfldnet2005-v8.pdf
  6. Sean Riley. UNET SyncVar // Unity Blogs [Электронный ресурс]. — Режим доступа: https://blogs.unity3d.com/ru/2014/05/29/unet-syncvar/
  7. NetworkSettingsAttribute // Unity Documentation (Version: 2017.2) [Электронный ресурс]. — Режим доступа: https://docs.unity3d.com/ScriptReference/Networking.NetworkSettingsAttribute.html
  8. UDT: Breaking the Data Transfer Bottleneck // SourceForge [Электронный ресурс]. — Режим доступа: http://udt.sourceforge.net/
  9. Протокол QUIC: переход Web от TCP к UDP // Хабрахабр [Электронный ресурс]. — Режим доступа: https://habrahabr.ru/company/infopulse/blog/315172/
  10. Изотов А.С., Немченко В.П., Анализ конформности на этапе проектирования сетевых протоколов // КНТУ [Электронный ресурс]. — Режим доступа: http://epr.kntu.net.ua/116/1/34.pdf
  11. А. В. Карпухин. Особенности реализации протокола TCP в современных компьютерных сетях. Системи обробки інформації. — 2009. — № 6(80). — С. 49-53.
  12. Гуляев К.Д. Реалізація прикладного програмного забезпечення, що використовує телекомунікаційну технологію із змінним розміром мережної адреси // ХАИ [Электронный ресурс]. — Режим доступа: https://www.khai.edu/csp/nauchportal/Arhiv/REKS/2012/REKS412/Gulyayev.pdf
  13. Орлова М.М., Шандиба Д.В. Реалізація мережевих протоколів як незалежних процесів // IT-Вестник КПИ [Электронный ресурс]. — Режим доступа: http://it-visnyk.kpi.ua/wp-content/uploads/2011/03/51_19.pdf
  14. В. Клобуков, В. Рябоконь, С. Єрмак. Дослідження протоколів побудови маршрутів в мережах Metro Ethernet // НАУ [Электронный ресурс]. — Режим доступа: http://avia.nau.edu.ua/doc/2011/4/avia2011_4_6.pdf
  15. Как использовать возможности фильтров отображения Wireshark по максимуму // Журнал Хакер [Электронный ресурс]. — Режим доступа: https://xakep.ru/2013/11/05/wireshark-filtres/

Copyright Андрей Сирант © 2017