Вгору

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

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

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

Кафедра праграмної інженерії

Спеціальність Інженерія програмного забезпечення

Дослідження ефективності мережних протоколів в клієнт-серверних програмах

Науковий керівник: к.т.н., доцент Грищенко Вiктор Iгоревич

Реферат за темою випускної роботи

Зміст

Мета

Метою даної роботи є вивчення, вибір і підвищення ефективності роботи мережевих протоколів транспортного рівня, і, як наслідок, підвищення продуктивності клієнт-серверної програми з інтенсивним обміном мережевого трафіку.

Завдання

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

  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% містить в собі дані інших пакетів, що дозволяє реконструювати будь втрачений пакет з даниx його сусідів. Браузер 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 циклів повторення, 114 кілобайт)

Також варто відзначити, що в програмі використовується 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