УДК 004.7
Р.Б. АНДРУЩЕНКО*, А.Д. БЕСКОСТИЙ*, С.В. ЗАЙЦЕВ*, Я.Ю. УСОВ*, М.А. ПИСЬМЕНЮК*
ДОСЛ1ДЖЕННЯ МЕТОД1В П1ДВИЩЕННЯ ДОСТОВ1РНОСТ1 ПЕРЕДАЧ1 ДАНИХ У СТЕКАХ ПРОТОКОЛ1В ТСР/1Р СИСТЕМ ПУБЛ1ЧНОГО АДМ1Н1СТРУВАННЯ
Чершпвський нацiональний технологiчний ушверситет, м. Чершпв, Украша
Анотаця. Стек протокол1в TCP/IP та модель OSI зарекомендували себе як надтну, eidnocno про-сту, техnологiю передачi даних у комп 'ютерних мережах. Проте, за nаявnостi надлишкового шуму у каnалi передачi даних вините nеобхiдniсть у застосуваню додаткових методiв тдвищення достовiрnостi передачi тформацИ В роботi проведено аnалiз iсnуючих методiв тдвищення цмс-nостi передачi даних у комп'ютерних мережах, побудованих на базi амейства протоколiв TCP/IP за рахунок застосування завадостткого кодування. Виявлено гх особливостi функ^онування, переваги i недолти тарозглянуто основю напрями до^джень у цт областi. Ключов1 слова: канал передачi даних, TCP/IP, комп 'ютерна мережа, кодування.
Аннотация. Стек протоколов TCP/IP и модель OSI зарекомендовали себя как надежную, относительно простую, технологию передачи данных в компьютерных сетях. Однако, при наличии избыточного шума в канале передачи данных возникает необходимость в применении дополнительных методов повышения достоверности передачи информации. В работе проведён анализ существующих методов повышения целостности передачи данных в компьютерных сетях, построенных на базе семейства протоколов TCP/IP за счет использования помехоустойчивого кодирования. Изучены их особенности функционирования, преимущества и недостатки, рассмотрены основные направления исследований в данной области.
Ключевые слова: канал передачи данных, TCP/IP, компьютерная сеть, кодирование.
Abstract. The TCP/IP protocol stack and the OSI model have already proved their reliability and relatively simplicity in data transmitting over the computer networks. However in case of presence of the excessive noise in the data transmitting channel, the additional methods of increasing of data reliability are required. The paper analyzes the existing methods of increasing the reliability of data transmission in computer networks based on TCP/IP protocol family using anti-jamming coding techniques. It discovers the characteristics of their functionality, advantages and disadvantages; considers the main directions of research in this area.
Keywords: data transmission channel, TCP/IP, computer network, coding.
1. Вступ. Актуальшсть теми дослщження
Анал1з тенденцш розвитку комп'ютерних мереж показуе, що стек прототшв передач! даних TCP/IP використовуеться у величезнш кшькосп корпоративних мереж, а також забез-печуе зв'язок вузл1в всесв1тньо! шформацшно! мереж1 1нтернет. Масове поширення без-провщних мереж та зростання кшькосп пристро!в, яю взаемод1ють м1ж собою за допомо-гою мережевих прототшв амейства TCP/IP та як1 потребують доступу до глобально! ме-реж1 1нтернет, приводить до необхщносп придшяти бшьшу увагу до реал1зацп прототшв зв'язку, !х безпеки та пропускно! здатносп.
2. Постановка проблеми
Починаючи ще з 90-х рок1в минулого стшття комп'ютерш мереж1 з кожним роком стають все складшшими та поширешшими. З того часу змшилось декшька поколшь мобшьного зв'язку, а кшьюсть пристро!в, що мають доступ до всесв1тньо! мереж 1нтернет, зросла в тисяч1 раз1в. Незважаючи на це, найпоширешш1 протоколи передач! даних транспортного р1вня - Transmission Control Protocol (TCP) та User Datagram Protocol (UDP), майже не за-
© Андрущенко Р.Б., Бескостий А.Д., Зайцев С.В., Усов Я.Ю., Письменюк М.А., 2018
ISSN 1028-9763. Математичш машини i системи, 2018, № 2
знали змш. У бiльшостi випадкiв вони добре справляються з поставленими перед ними за-вданнями. Однак в останнш час все бшьшо!' популярносп набувають безпровiднi мережi, якi характеризуются певними особливостями, зокрема, значно бшьшим впливом завад на пакети даних, що, у свою чергу, знижуе ефективнiсть каналу передачi даних. Тому постае важливе питання, як саме можна знизити вплив завад та збшьшити пропускну здатшсть i достовiрнiсть передачi даних протоколiв транспортного рiвня. Саме аналiзу iснуючих ме-тодiв i присвячена дана стаття.
3. Анал1з останн1х дослщжень i публжацш
Загалом, усi роботи в даному напрямi можна роздiлити на три види [1-6]. Першi [1-3] - це використання оптимiзованих апаратних ршень у пристроях прийому/передачi даних, друп [4, 5] - пiдвищення ефективност протоколiв зв'язку, третi [6] - комбшоваш. До других та третсх вiдносять рiзноманiтнi методи пiдвищення цшсносп пакетiв TCP i UDP за рахунок застосування корекцшних кодiв Forward Error Correction (FEC), методiв Automatic Repeat Request (ARQ - автоматичш запити на повторну передачу), а також пбридних методiв (FEC-TCP та ARQ) в умовах пщвищеного шуму в канал^ який призводить до викривлення передано! шформацп. Аналiз дослщжень щодо порушення цiлiсностi протоколiв мiжмере-жево'1 взаемодп свiдчить, що в тепершнш час протоколи TCP/IP широко використовують-ся в безпровiдних каналах передачi даних, якi характеризуються пщвищеним рiвнем шуму. Це призводить за певних обставин до виникнення багатьох помилок у прийнятих пакетах даних, а, отже, до повторних передач цих пакетiв. Крiм того, на зниження цшсносп про-токолiв TCP/IP впливають вiддаленi мережевi атаки, наприклад, атаки типу «зашумлення». Iснуючi методи пщвищення цiлiсностi передачi даних прототшв TCP/IP за певних умов завадово'1 обстановки не забезпечують гарантовану доставку повщомлень.
4. Мета CTaTTi
Головною метою дано'1 роботи е визначення основних методiв пiдвищення цiлiсностi пере-дачi даних у сучасних комп'ютерних мережах, аналiз основних напрямiв дослщжень у цш галузi, а також визначення подальших шляхiв пiдвищення цшсносп протоколiв мiжмере-жево'1 взаемодп TCP/IP.
5. Виклад основного матерiалу
Для бiльш повно'1 картини спочатку розглянемо стандартний протокол гарантовано'1 доставки повщомлень транспортного рiвня - TCP-протокол.
Протокол ТСР реалiзуе взаемодiю в режимi встановлення логiчного (вiртуального) з'еднання, забезпечуе двостороннш дуплексний зв'язок. Вш органiзовуе потоковий (з точки зору користувача) тип передачi даних та надае можливють пересилання частини даних як екстрених. Для щентифшацп вузлiв на транспортному рiвнi протокол ТСР використовуе 16-бiтовi номери портив. Також протокол ТСР реалiзуе принцип sliding window для пщви-щення швидкостi передачi й пiдтримуе ряд механiзмiв для забезпечення надшно! передачi даних. Незважаючи на те, що для користувача передача даних з використанням протоколу TCP виглядае як потокова, насправдi ж обмш мiж вузлами здшснюеться за допомогою па-кетiв даних [7].
У бшьшосп випадкiв документ, електронна пошта або шша iнформацiя не надсила-еться вся i вiдразу. Замiсть цього, вона розбиваеться на невелию пакети даних, кожен з яких мютить частину даних та заголовок, що визначае правильну послщовшсть даних. Коли пакети даних надсилаються по мереж1, вони можуть надходити до адресата рiзними маршрутами та в рiзний момент часу. Але це не мае значення. Приймач оргашзовуе ва при-йнятi пакети даних повторно в належному порядку. Шсля того, як уа пакети отримаш, ге-
неруеться повщомлення до вихщно'1 мережi. Якщо ж деякий пакет не надходить до адресата, то вщправляеться повщомлення до вихщно'1 мереж про необхщшсть повторно'1 вщпра-вки пакета. Таким чином, TCP забезпечуе гарантовану доставку даних до адресата [8, 9].
У протоколi ТСР використовуеться контрольна сума для перевiрки цшсносп паке-тсв даних - 16-бггне доповнення суми всiх 16-бiтних ошв заголовка й даних. Якщо сегмент мютить у заголовку й текст непарну кiлькiсть октетiв, що пщлягають облiку в контрольнiй сумi, то останнш октет буде доповнений нулями праворуч для того, щоб утворити для на-дання контрольнiй сумi 16-бiтне слово. Утворений при такому вирiвнюваннi октет не пе-редаеться разом iз сегментом по мережг Перед обчисленням контрольно'1 суми поле ще'1 суми заповнюеться нулями.
Контрольна сума, крiм усього шшого, враховуе 96 бiтiв псевдозаголовка, який для внутршнього використання розмщуеться перед TCP-заголовком. Цей псевдозаголовок мютить адреси вiдправника, одержувача, протокол та довжину TCP-сегмента [7].
Коли TCP-пакет надходить до мюця призначення, приймаюче програмне забезпе-чення виконуе той же самий розрахунок контрольно'1 суми. Вш також виконуе ди по ство-ренню псевдозаголовка, який потм так само приеднуеться перед фактичним TCP-сегментом, а потм розраховуе контрольну суму (встановлюючи значення поля контрольно! суми в 0 для розрахунку, як i вузол, що вщправив даш). Якщо юнуе невщповщшсть мiж його розрахунком та значенням у полi контрольно! суми, це означае, що виникла по-милка, i пакет зазвичай вщхиляеться [7].
Легко бачити, що використовувана контрольна сума надто прим^ивна. У випадку надлишкового шуму в каналi передачi даних маемо велику кшькють запитiв на повторну передачу, що значно знижуе пропускну здатшсть каналу.
Альтернативою е використання, наприклад, FEC-кодiв. Особливо це стосуеться пе-редачi мультимедiйних даних великого об'ему, оскiльки найбiльше навантаження на мережу спричиняеться саме мультимедшними даними.
Forward Error Correction (FEC) - кодування/декодування сигналу з можливютю ви-явлення помилок i корекцп шформаци. Таким чином, приймач може виявляти i виправляти помилки, що виникають у каналi передачi без запштв на повторну передачу фрагментiв даних, що були втрачеш або пошкоджеш. Отже, FEC-кодування доцiльно застосовувати у випадках, якщо ретранслящя пакетiв е дорогою операщею. 1снуе кiлька FEC-алгоритмiв кодування, якi розрiзняються за складшстю та продуктивнiстю. Одним iз найбшьш поши-рених кодiв першого поколшня FEC е, наприклад, код Рща-Соломона. Коди Рiда-Соломона - це ци^чш коди, що дозволяють виправляти помилки у блоках даних. Елеме-нтами кодового вектора е не б^и, а групи бтв (блоки). Дуже поширенi коди Рiда-Соломона, що працюють з байтами (октетами).
Ця особливiсть робить коди Рiда-Соломона особливо корисними для протиди гру-повим помилкам: шють послiдовних бiтових помилок, наприклад, можуть пошкодити максимум два байти. Тому навт верая коду Рща-Соломона з корекщею подвшно! помилки може забезпечити достатнiй запас мщносп. Математично коди Рiда-Соломона засноваш на арифметицi кiнцевих полiв [10].
Код Рща-Соломона мае мшмальну вщстань:
Це код з максимально досяжною кодовою вiдстанню, тобто при фшсованих п i к не юнуе коду, у якого м1шмальна вщстань бшыпа, шж у коду Рща-Соломона. Код Рща-Соломона будуеться на довжинах N = д-1 у пол1 ОР(^) за породжувальним многочленом:
d = 2t + l = n-k-l.
(1)
g( х) = (х- aJ° )-(x-aJo+1 )...(*- аУо+2t~1),
(2)
де а - пршштивш елементи поля GF( q) , j0 - (1, п) - довшьш елементи поля, t - виправля-
юча здатшсть коду. Змша будь-якого з параметр1в (n, a, j, i) породжувального многочлена
коду Рща-Соломона призводить до утворення нового сум1жного класу коду. Варто зазна-чити, що якщо на приймальнш сторош не вщомий закон змши параметр1в g (х), то деко-дування е складним обчислювальним завданням. Кр1м того, коди Рща-Соломона мають структурну властивють: змшюючи основу алфав1ту q, можна виправляти як одиночш по-милки, так i пакети помилок [10, 11].
1снуе метод покращання медiа-протоколiв за допомогою використання FEC. У цьо-му методi разом iз медiа-пакетами транспортного протоколу Real-time Transport Protocol (RTP) в режимi реального часу надсилаються резервш пакети для перевiрки наявно! про-пускно! здатностi. Резервш пакети - це закодоваш RTP-пакети з FEC-кодами [12].
Основна щея використання FEC для yправлiння швидкютю полягае в тому, щоб пе-редавати надлишковi FEC-пакети разом iз потоком даних та використовувати !х для пере-вiрки доступно! пропускно! здатностi. Якщо умови в середовищi забезпечують стабiльнy та надiйнy передачу, то потш FEC-пакетiв зменшуеться, тим самим швидюсть кодування даних стае бшьшою. Потiк FEC-пакетiв може навггь взагалi припинятись у разi дшсно ста-бiльного каналу.
Якщо бути бшьш точним, то суть цього методу - в пщрахунку кшькосп втрат над-лишкових FEC-пакетiв. Якщо в мереж вщсутш втрати надлишкових пакетiв, вiдправник може збiльшити швидкють передачi за рахунок зменшення кшькосп надлишкових FEC-пакетiв. У випадку ж втрат через конфлшти в середовищi кiлькiсть резервних пакетiв, на-впаки, збiльшyеться. Бiльша кiлькiсть резервних паке^в дозволяе вiдновити бiльше втра-чених пакетiв.
На сторонi передавача модуль керування швидкютю обчислюе новий б^рейт. Якщо нова швидкiсть передачi даних вище, нiж попередня, то модуль FEC, залежно вщ його внутршнього стану, додае FEC-данi. Шсля цього вiн вказуе модулю керування поточний б^рейт для потоку даних, який може бути меншим, шж розрахункова швидкють передачi.
На сторош приймача модуль FEC реконструюе втрачеш пакети даних. Якщо пакети устшно вщновлюються, то модуль створюе зв^ про втрати пiсля ремонту для вщповщних пакетiв даних. Також модуль FEC отримуе додатковi данi Real-time Transport Control Protocol (RTCP), пов'язаш з основним потоком даних, та зв^ про виправлеш помилки. Вш ви-користовуе RTCP-данi для розрахунку ефективносп FEC.
Типова схема з модулем FEC зображена на рис. 1 нижче.
Основна перевага даного тдходу полягае в тому, що алгоритм керування швидюс-тю в ньому може бути легко масштабовано та змшено в залежносп вщ наявно! потyжностi каналу, оскшьки пiдвищена надiйнiсть компенсуе можливi помилки, яю виникають у зв'яз-ку з надмiрним використанням каналу зв'язку [12].
TCP with dynamic FEC (TCP-dFEC). Основна вщмшшсть цього методу полягае в тому, що в залежносп вщ втрат паке^в у мереж регулюеться не кшьюсть надлишкових пакетив, а складнiсть виправляючого коду.
Протокол TCP-dFEC може змшювати рiвень складностi коду. Тобто, вiн е адаптив-ним. Адаптивнiсть базуеться на пщрахунку значення залишкових втрат. Залишковi втрати показують не саму кшькють втрат, а !! змiнy в часг Тобто, значення залишкових втрат може показати, наскшьки надшною стала мережа передачi даних у даний момент часу у порь внянш з попереднiм моментом часу. Якщо бути бшьш точним, то у прототш TCP-dFEC значення залишкових втрат розраховуеться протягом заданого перюду Т. Воно розрахову-еться як сшввщношення кiлькостi повторно переданих паке^в за даний та попереднiй пе-рiоди. Далi береться середне значення залишкових втрат за декшька перiодiв (це зроблено для того, щоб згладити значення), яке по^м i порiвнюеться з заранi заданою константою -
^.nbOBHM piBHeM BTpaT. ^k^o oTpHMaHe cepegHe 3HaneHHa BH^e, Hi» ^.boBe, to CK.agHicTb Kogy FEC 3MeHmyeTbca, iHaKme - 36i.bmyeTbca.
Media Encoder/Decoder
Rate Control Module
RTP FE
RTP
FEC Code
-4-►
Source RTP
FEC Module
RTP FR
Repair RTP
Source RTP
RTP Processing Layer (queue)
Transport Layer (TCP / UDP)
IP
Endpoint
Phc. 1. CxeMa BHKopHCTaHHa Mogyna FEC-KogyBaHHa gna Komponro HaBaHTa»eHHa
TCP-dFEC 3a6e3nenye TaKy » mBugKÏCTb nepegani gaHHx, aK i 3BHHaßHHH TCP npu hh-3bKHx BTpaTax y KaHani nepegani gaHHx. Ane b toh »e nac bïh 3a6e3nenye b cepegHboMy Ha 40% 6i.bmy mBHgKÏCTb nepegani gaHHx npu bhcokhx BTpaTax y KaHani [13].
Phc. 2. nopiBHaHHa TCP Ta TCP-dFEC
TaKo» pi3HoBHgoM igeï BHKopucTaHHa KogiB Kope^iï noMHnoK e 3a.yneHHa Fountain-Kogiß. ïx ocoÔJiHBicTb nonarae y TOMy, mo gjia nepegani M naKeri b BHKopucTOByeTbCH min {M + F) 3aKogoBaHnx naKeriB, toôto gogaeTbca gogaTKOBa iHC^opMauia. IIpiiHOMy gna yc-nimHoro npuHoMy gaHHx Heo6xigHo ycnimHo npuHHaTH 6ygb-aKi N naKeTÏB 3 Ha6opy [14]:
M <N <mm(M + F). (3)
1 1 1 1 i 1 i i i i 1 1 1 i i i i i 1 1 i i i i i i i 1 1 1 i i i i 1 i 1 i
1 1 i i i i i 1 i i 1 i i i i 1 i i i i 1 i i
i i i i i i i i i 1 i i i i i i i i i i i i i 1 i
1 ■ 1 i i 1 1 i i 1 i 1 1 i
1 1 1 1 1 i - 1 1 1 i i 1 1 i
1 1 i i i i i i i i i i i i i i i
Пepeдaнi naRe™
I I_LJ_II_I_I_III_III_I I I I_LJ_l_
w яАвщтМ
OrpHKani пaкeти
i i i 1 i i
1 i i i i i
i
i
■
•
i i i
■ ■
i -
i
i i 1 i 1 1
i
i i
i ■
i i
1
i i i i i
Ha croporn пepeдaвaчa мoжнa м визнaчaти, ^льки та^^в нeoбxiднo пepeдaти. Heмa нeoбxiднocтi зacтocoвy-вaти зaпити нa пoвтopнy пepeдaчy. na-кeти гeнepyютьcя дo тиx mp, пoки пpиймaч нe пpиймe будь-яю N пaкeтiв.
У peзyльтaтi кoдyвaння нa виxoдi oтpимyeмo мaтpицю дaниx для пepeдaчi. Пpиймaч y paзi втpaти пaкeтiв oтpимye poзpiджeнy мaтpицю. Пpoтe, мaючи дoc-тaтню кшькють cтoвпчикiв, вiн мoжe пoвнicтю дeкoдyвaти пepeдaнy iнфopмa-цiю [14].
Одним iз нaйпoтyжнiшиx мeтo-дiв, щo y cвoïй poбoтi викopиcтoвyють ^ди ^pe^ii пoмилoк, e AprilFEC. №го зacтocyвaння дopeчнe бiльшe для repe-дaчi мyльтимeдiйниx фaйлiв. AprilFEC пoбyдoвaний нa UDP i зaбeзпeчye тадш-ну дocтaвкy шляxoм викopиcтaння fountain-кoдiв. Цi кoди eфeктивнo aдaп-тyютьcя дo piвня втpaт y ^тал^ тoмy AprilFEC мoжe пiдтpимyвaти дocтoвipнy тa швидку пepeдaчy дaниx ^и мiнiмiзaцiï нaклaдниx витpaт нa мepeжy.
Пicля тoгo, як кopиcтyвaч пepeдacть дaнi в AprilFEC, cиcтeмa poзбивae ïx нa мeншi фpaгмeнти, пpидaтнi для пepeдaчi в кopиcниx нaвaнтaжeнняx пaкeтiв UDP. Бaзyючиcь нa oцiнцi митreвoï швидкocтi втpaти пaкeтiв, AprilFEC oбчиcлюe тa пepeдae пapтiю зaкoдoвa-ниx фpaгмeнтiв. Cиcтeмa миrтeвo пpизyпиняeтьcя i чeкae oтpимaння пiдтвepджeння вщ кь нцeвoгo вyзлa, пicля чoгo вiн пpипиняe пpoцec пepeдaчi. Якщo ACK нe oтpимaнo, AprilFEC пoвтopить пpoцec iз бiльш виcoким cтyпeнeм втpaти пaкeтiв. Пicля дeкiлькox пoвтopeнь AprilFEC зaвepшye пpoцec пepeдaчi тавт зa вiдcyтнocтi бyдь-якoгo ACK [15].
У кiнцeвoмy вyзлi AprilFEC збиpae зaкoдoвaнi фpaгмeнти i нaмaгaeтьcя вiднoвити opигiнaльнe пoвiдoмлeння вiд ниx. Коля тoгo, як вoнo змoжe вiднoвити виxiднi дaнi, AprilFEC пepeдae дaнi кopиcтyвaчeвi тa нaдcилae ACK нaзaд дo пepeдaвaльнoгo вyзлa.
Чacткa ycпiшниx пepeдaч пiд чac мoдeлювaння пoтoкoвoгo зoбpaжeння, кepoвaнoгo реальними робочими мережевими даними, зображена на рис. 4.
PKC. 3. У peзyльтaтi втpaти пaкeтiв нeмae ж-oбxiднocтi викopиcтoвyвaти зaпити na пoвтopнy nepeAaHy. Дocтaтньo зiбpaти будь-яю N пaкeтiв
Pkc. 4. Bipoгiднicть ycnimnoi' nepeAaHÍ зoбpaжeння в зaлeжнocтi вщ poзмipy дaниx npK вккopкcтaннi AprilFEC тa бeз ньoгo
AprilFEC значно перевершуе TCP, традицiйний надшний протокол доставки. Коли частота втрати пакетв висока, частота появи повщомлень ACK збiльшуеться через те, що TCP припиняе очiкування повторно! передачь Для порiвняння AprilFEC використовуе ада-птивну схему виправлення помилок для передачi даних з високою ймовiрнiстю навiть в умовах погано! мережь
Не зважаючи на збiльшення втрат пакетв, AprilFEC продовжуе передавати зобра-ження. Причому, чим бiльша кшькють втрачених пакетiв, тим бiльш ефективно працюе AprilFEC по вiдношенню до класичного TCP (рис. 5).
AprilFEC
0,0 - 0,1 0,1 - 0,2 0,2 - 0,3 0,3 - 0,4 0,4 - 0,5 0,5 - 0,6 0,6 - 0,7 0,7 - 0,8 0,8 - 0,9
Вфопджсть втрати пакепв
phc. 5. BiporigmcTb ycnimHoi nepegani 3o6pa^eHHa 1 M6 3ane^Ho Big BiporigHOCTi BTpaTH naKeTiB
3 puc. 4 MO^Ha 3po6uTH bhchobok, qo Naive Fountain 3HanHO Kpaqe cnpaB^aeTbca 3 nocTaB^eHHMH nepeg hhm 3aBgaHHAMH. OgHaK цe He TaK.
y 6rnbmocri BunagKiB BHKopucTaHHA Naive Fountain npu3BoguTb go Ha6araTo 6mbmux HaKnagHHx BHTpaT nopiBHAHo 3 AprilFEC. TaK ak Naive He 3grncHroe o^HKy KmbKocri $par-MeHTiB, AKi Heo6xigHo 3aKogyBaTH Ta nepegaTH, ToMy 3MeHmye nponycKHy 3gaTHicTb KaHa^y nepegani iH^opMa^i. Koe^i^eHT HaKnagHux BrnpaT 3o6pa^eHo Ha puc. 6 [15].
Koei|)iqieHi накладных витрат
Рис. 6. Коефiцieнт накладних витрат
Метод End-to-end FEC-TCP. Реал!зусться або як частина транспортного р!вня, або безпосередньо на р!вень нижче, як на сторон! в!дправника даних, так i на сторон! прийма-ча. Це найб!льш п!дходящий сценар!й для впровадження FEC-FTP. Кодер FEC може легко
отримати шформащю про поточне значення вшна TCP i виконати миттеве сповщення у випадку втрат, пов'язаних з перевантаженням, безпосередньо з TCP-piBra.
Як видно на рис. 7, пропускна здатшсть FEC-TCP бшьш нiж у двiчi бiльша вiд кла-сичного TCP для вiрогiдностi втрати пакетв мiж 0,01 та 0,02. Пропускну здатшсть можна пщвищити шляхом застосування бшьш складних алгоритмiв кодування та збшьшенням надлишково! шформацп на один блок даних.
0.9
0.8
— 0.7 ■а
¿L 0.6 Л
■=Е 0.5
та °-4
I
*
| 0.3 о а С
0.2 0.1 0
Рис. 7. Пор1вняння ТСР та End-to-end TCP-FEC (при розм1р1 пакета 1000 байпв)
End-to-end FEC-TCP також можна використовувати не лише для пщвищення пропу-скно! здатностi каналу зв'язку, а i для ощнки ймовiрностi втрати пакетiв у мережь Тобто End-to-end FEC-TCP також можна застосувати як альтернативне ршення для попереджую-чого виявлення максимально! пропускно! здатностi каналу зв'язку [16].
6. Висновки i пропозицп
1. Cтек протоколiв TCP/IP та модель OSI зарекомендували себе як надшну, вщносно прос-ту технологiю передачi даних у комп'ютерних мережах. Проте за наявносп надлишкового шуму у каналi передачi даних виникае необхiднiсть у застосуванш додаткових методiв т-двищення достовiрностi передачi шформацп.
2. Протоколи TCP i UDP, що широко застосовуються у комп'ютерних мережах, майже не зазнали змш. У бшьшосп випадкiв вони добре справляються з поставленими для них за-вданнями, проте виникають ситуацп, за яких стандартних рiшень не достатньо для забез-печення необхiдного рiвня достовiрностi передачi даних.
3. Розглянуто методи модифшацп стеку протоколiв TCP/IP на транспортному та вищих рь внях: RTP-FEC для управлшня потоком даних, адаптивний dFEC-TCP, Fountain-кодування, AprilFEC та End-to-end FEC-TCP, що дозволило визначити напрями подальших дослщжень у цш галузi за рахунок застосування завадостшких кодiв.
4. Недолiком методiв, яю використовують FEC-коди, е низька адаптившсть до змiни характеристик каналу передачi даних. Крiм того, для FEC-методiв характерна деяка затримка у чаа, що витрачаеться на кодування, декодування та використання надлишкових ресурав каналу для передачi закодовано! шформацп. AprilFEC показуе хорошi результати за умови вчасного прогнозування втрати пакетв. Однак втрати в ненадшних каналах передачi даних можуть залежати вщ чинникiв, якi важко спрогнозувати. Використання Fountain-кодiв мо-же призводити до велико! кшькосп надлишкових пакетiв у каналi у випадку, якщо переда-вач не отримае за якихось причин повщомлення вiд приймача про устшний прийом даних.
5. Для пщвищення характеристик достовiрностi шформацп у сучасних комп'ютерних мережах пропонуеться додаткове застосування методiв завадостшкого кодування, зокрема, турбокодiв та кодiв Рща-Соломона.
CnHCOK A^EPE^
1. Nair R. A Symbol Based Algorithm for Hardware Implementation of Cyclic Redundancy Check (CRC) / R. Nair, G. Ryan, F. Farzaneh // VHDL International Users' Forum. - 1997. - P. 82 - 87.
2. Liu Q. Implementation of hardware TCP/IP stack for DAQ systems with flexible data channel / Q. Liu, X. Zhiqiang, L. Zhengying // Electronics Letters. - 2017. - Vol. 53, Issue 8. - P. 530 - 532.
3. Assar A. A hardware implementation of the TCP protocol applying TCP-BIC and TCP-CUBIC standards / A. Assar, K. Hofmann // Microelectronics (ICM), 28th International Conference. - Giza, Egypt, 2016. - P. 37 - 40.
4. Dalessandro D. iWarp protocol kernel space software implementation / D. Dalessandro, A. Devulapalli, P. Wyckoff // Parallel and Distributed Processing Symposium, IPDPS 2006. - Rhodes Island, Greece, 2006. - P. 274.
5. Thanh V.T. Mobile TCP socket for secure applications / V.T. Thanh, Y. Urano // Advanced Communication Technology (ICACT), The 12th International Conference. - Nangang, China, 2010. - P. 971 - 974.
6. Hong R.L. Research and application of TCP/IP protocol in embedded system / R.L. Hong // 2011 IEEE 3rd International Conference on Communication Software and Networks. - 2011. - P. 584 - 587.
7. AHHHKHH C.A. npoTOKonw нн$opмaцнoннo-вbIннcпнтeпbHbIx ceTeM / C.A. AHHHKHH, C.A. EenoB,
A.B. EepHmTeMH; nog peg. H.A. Mu3HHa h A.n. KynemoBa. - M.: Pagno h CB33b, 1990. - 504 c.
8. Winkelman R. An educator's Guide to School Networks / Winkelman R. - Florida Center for Instructional Technology, College of Education, University of South Florida, 2009. - P. 1 - 15.
9. Core TCP/IP protocols / L. Parziale, N. Rosselot, W. Liu [et al.] // International Technical Support Organization, IBM. - 2016. - P. 4 - 9.
10. CugenbHHKOB B.M. KpunTorpa^ua h Teopua KogupoBaHua / B.M. CugenbHHKoB // MaTepuami koh$. «MockobckhM yHHBepcHTeT h pa3BHTue Kpumorpa^HH b Pocchh». - M.: Mry, 2002. - 22 c.
11. MenbHHK A.n. ^HHaMinm cxeMH 3axucTy rn^opMa^i' Ha Kogax Piga-C0n0M0Ha / A.n. MenbHHK,
B.I. Tpa6naK // Te3H gonoBigeM II Mi^Hap. HnK «Ee3neKa Ta 3axucT iн^opмaцii B iH^opMa^HHHx CH-CTeMax». - 2009. - Bun. 7. - C. 139 - 140.
12. Congestion Control using FEC for Conversational Multimedia Communication / M. Nagy, V. Singh, J. Ott [et al.] // MMSys '14 Proceedings of the 5th ACM Multimedia Systems Conference. - 2014. -P. 191 - 202.
13. Ferlin S. TCP with dynamic FEC For High Delay and Lossy Networks / S. Ferlin, O. Alay // International Conference on emerging Networking Experiments and Technologies. - 2016. - P. 1 - 3.
14. MacKay D.J.C. Fountain codes / D.J.C. MacKay // Capacity approaching codes design and implementation, EE Proc.-Commun. - 2005. - Vol. 152, N 6. - P. 1062 - 1068.
15. Marcotte R.J. AprilFEC: Real-Time Channel Estimation and Adaptive Forward Error Correction / R.J. Marcotte, W. Xipeng, E. Olson // Robot Communication in the Wild 2017. - 2017. - P. 68.
16. Lundqvist H. TCP with End-to-End FEC / H. Lundqvist, G. Karlsson // Communications, International Zurich Seminar. - 2004. - P. 152 - 155.
Cmammn nadiumna do pedaKU,ii 10.04.2018