Посібник з UDP (протокол дейтаграм користувача)

Посібник з UDP

Протокол дейтаграм користувача – це як “Потворне каченя” Ганса Крістіана Андерсена. Після десятиліть занедбаності та висміювання цей простий протокол раптово привернув шанувальників як транспортний протокол для нових, гламурних мультимедійних додатків, які стали можливими завдяки широкосмуговій швидкості. Сьогодні будь-яка програма, якій потрібно доставити дані, швидко вибирає UDP за домінуючим раніше TCP (протокол управління передачею).

Історія UDP

UDP існує майже так само довго, як і Інтернет. Інтернет з’явився в травні 1974 року, коли Інститут інженерів електротехніки та електроніки опублікував “Програма взаємодії пакетної мережі“Від Винт Серф і Боб Хан. Концепцію потрібно було розробити, і Хан і Серф продовжували вдосконалювати свої ідеї, працюючи для уряду США Агентство прогресивних дослідницьких проектів в галузі оборони, який також відомий як DARPA. Джон Постель залучились і запропонували розділити єдину структуру, запропоновану в оригінальній ідеї Серфа і Хана. Це створило шарувату концепцію. Оригінальна програма контролю передачі, що міститься в конспекті 1974 року, була розділена на протокол управління передачею на більш високому рівні та Інтернет-протокол на нижньому рівні (звідси TCP / IP).

Модульний підхід Постеля мав сенс, коли команда почала думати про втілення теорії. Існував чіткий розподіл праці між тим, що стало відомим як “Росія” Транспортний шар, місце розташування протоколу управління передачею та Інтернет-шар, де проживає Інтернет-протокол. Однак Серф і Хан передбачали необхідність швидкого вибору. Вони склали схему того, як будуть підготовлені дані для передачі шляхом передачі від одного шару до іншого. Завдання на обробку були представлені як пряма вертикальна лінія, що спускається через нову діаграму стека, що показує прогресування від додаток до TCP та до IP.

Коли справа доходила до малювання у швидкій доріжці, вони не хотіли промальовувати вигнуту лінію об’їзду, яка уникала проходження через TCP. Натомість вони намалювали довгасту форму, яка представляла Інтернет-шар трохи ширше, ніж блок, який представляв транспортний шар. За допомогою цього візуального регулювання як звичайний маршрут, так і швидкий маршрут слід спускатися через стек як паралельні лінії. Однак ця хитрість залишила прогалину, яку Постель відчув необхідною для заповнення. Ось чому був винайдений протокол User Datagram. Саме там діаграма стека протоколу виглядала збалансованою.

Переваги TCP

Протокол управління передачею забезпечує важливі послуги для даних, що перебувають у дорозі. Він гарантує, що всі пакети в потоці дійсно надходять, і перевіряє, чи надходять вони в порядок. Ці процедури контролю, що забезпечують впорядковану передачу, неможливі без міри координації між двома сторонами. Отже, TCP спочатку встановлює угоду між двома пристроями, які мають намір обмінюватися даними. Ця угода називається сеанс. Це також саме визначення поняття “з’єднання.”UDP не має процедур встановлення сесії, і це називається”без зв’язку.”

Сеанс надає обом сторонам з’єднання посилання на номер, який вони можуть позначити на своїх адміністративних обмінах. Сесія також дозволяє ввести концепцію портів. Ідентифікатор сеансу – це комбінація ідентифікаторів, що містяться в заголовку TCP. За допомогою цього посвідчення дизайнери процедур TCP змогли придумати ідею «розетка.”Номери портів також призначаються UDP, однак цей протокол може використовувати лише IP-адреса призначення та номери портів як унікальний ідентифікатор. Ідентифікатор, отриманий із цієї комбінації, блокував би всі інші процеси, що намагаються отримати доступ до того ж порту, хоча вони працювали на різних комп’ютерах, UDP була створена лише система доставки, без процедур для включення двостороннього діалогу.

Концепції підключення TCP розробились у дуже складний універсальний метод, який гарантує, що дані, що передаються між комп’ютерами, не змішуються та не перекладаються. Розетка дозволила відкрити декілька з’єднань між тими ж двома комп’ютерами одночасно. Ця ідея створила можливість мати декілька каналів, які працюють для передачі даних. Це часто використовувана процедура, якою скористалися багато ранніх мережевих додатків. The Протокол передачі файлів, наприклад, використовується два канали: один для передачі даних та окремий канал для адміністративного зв’язку. Різні номери портів для каналів передачі даних та керування створюють два різних гнізда.

Унікальний ідентифікатор для кожного сеансу означав, що TCP додав значення для зв’язку між двома комп’ютерами. В кінці 70-х – початку 80-х лише великі організації та академічні установи мали комп’ютери та мережі. Отже, велика ймовірність, що дві організації потребують своїх великих мейнфреймів, щоб одночасно з’єднуватися одна з одною для різних цілей. Поки професор надсилав файл колезі в інший університет, дослідник може також захотіти відкрити сеанс Telnet для комп’ютера в тому ж віддаленому університеті. Завдяки TCP, два комп’ютери могли підтримувати декілька з’єднань одночасно, і кожен з цих сеансів міг працювати одночасно декількома каналами. Ці паралельні з’єднання були б неможливими, якби комунікації регулювалися лише Інтернет-протоколом з виділенням однієї IP-адреси на комп’ютер. UDP, не маючи жодного механізму сеансу, був нездатний керувати програмами, які потребували контакту з комп’ютером для надсилання відповіді.

Безпека даних

Блискучі конструкції TCP зробили можливим зв’язок між мережами, і Інтернет почав розширюватися поза Академією до ділового світу. Створення Всесвітня мережа, яка стала загальнодоступною у 1991 році, була можлива лише через легкість, з якою веб-сторінка, що містить протокол передачі гіпертексту (HTTP), могла сісти на вершину TCP.

Вчені та технічні працівники, які об’єднали Інтернет та розробили загальнодоступну всесвітню мережу, були сині небесні мислителі. Вони були схвильовані технологією та її можливостями прискорити дослідження та покращити взаємодію між людьми у всьому світі. Вони не змогли пояснити той факт, що їх чудовий винахід був подарунком для злодіїв, шахраїв та міських терористів. Ні Інтернет, ні Всесвітня павутина взагалі не мали жодної безпеки.

Це сприйняло споживачів Netscape Corporation щоб помітити цю проблему. Netscape створив провідний веб-браузер у світі та роздав його безкоштовно, щоб заохотити використання Інтернету серед широкої громадськості. План працював, а обмін інформацією та контактними каналами розповсюджувався, заохочуючи все більше представників громадськості підписатися на послуги Інтернету. Однак відсутність безпеки створила перешкоду для комерціалізації Інтернету. Без можливості спонукати людей платити за онлайн-послуги, не було стимулів для бізнесу інвестувати в розробку нових додатків, веб-сайтів чи онлайн-сервісів..

Основним бар’єром для збирання платежів через Інтернет була його відсутність безпеки. Кілька заголовків про крадіжку даних при передачі Інтернету відключили можливість зробити Інтернет комерційно життєздатним. Однак, Netscape придумав HTTPS захищена версія HTTP, яка захищала передачу. Ідеальне місце розташування в стеку TCP / IP для цих процедур безпеки було під час процесів встановлення сеансу TCP. Тому, TCP став ще більш важливим для роботи в Інтернеті і, здавалося, ще ймовірніше, що UDP ніколи не буде використаний.

UDP злітає

Незважаючи на те, що існує з 1980 року, UDP був повністю не помічений поки послуги широкосмугового Інтернету не стали доступними на початку цього століття. Протокол User Datagram був значною мірою ігнорований, тоді як веб-програми та інші Інтернет-програми розширювали функціональність TCP.

Однак, можливість вести голосові розмови та відеоконференції через Інтернет завжди подобається бізнесу. Ці програми існували раніше широкосмугового зв’язку, але лише для використання у швидших приватних мережах. За допомогою технології передачі звуку та відео через мережі, більш високі швидкості широкосмугового зв’язку принесли можливість зробити ці програми доступними для широкої громадськості стала здійсненною ідеєю. Однак швидкості, доступні через Інтернет, були не досить хорошими.

Безпосереднім рішенням витіснення достатньо додаткової швидкості з Інтернету було виривання всіх адміністративних процедур TCP та зверніться до майже забутого УДП.

Проблеми з TCP

Інтерактивні програми швидше вирішують деякі проблеми, що виникають під час самої передачі. Однією з головних особливостей TCP, якої ці програми справді не хочуть, є буферизація.

TCP гарантує, що пакети надходять послідовно. Якщо пакет відсутній у потоці, реалізація TCP, що приймає, надішле запит програмі TCP, що надсилає, щоб повторно надіслати цей конкретний пакет. Тим часом цей пакет може надійти пізно. TCP використовує систему розсувного кадру для обробки пакетів, що надходять, і якщо сегмент запізнюється або втрачається, цей слайд заклинюється. Тимчасове зберігання декількох кадрів у пам’яті – це те, що відомо як буферизація. TCP чекає, поки він не зможе заповнити порожній слот пакетом, який містить пропущений порядковий номер. У випадку Інтернет-телефонії така дія призвела б до того, що лінія мовчить. У потоковому потоці відео очікування відсутнього пакету змусить відеоплеєр замерзнути.

В інтерактивних додатках немає процедур, щоб заощадити буфер TCP. Основним шаром стеків є те, що більш високі шари запитують послугу і залишають її нижньому шару для надання. Немає жодного сигналу “вступити з цим”, що заявка може надсилати на транспортний шар.

Якщо пакет загубиться в цифровій телефонній розмові, абоненти відчують коротку тишу, але додаток з обох сторін буде просто рухатися далі та продовжувати надсилати та отримувати наступні пакети. До моменту відновлення відсутнього пакету інтерактивна розмова вже б продовжилася, тому немає сенсу намагатися ввести її назад у потік; просто краще списати втрати і продовжувати. Аналогічно, втрачений пакет означав би лише короткий пропуск у прямому ефірі, і глядачі могли б швидше перенести це відео вперед, ніж затримувати сюжет на одну мілісекунд кадрів.

Ви, напевно, бачили, як відеоплеєр робить паузу та накладає повідомлення “буферизація”Над картиною. Зазвичай існує також лічильник, який показує відсоток буферизації, який був завершений. Це буферизація відбувається, якщо швидкість передачі з’єднання є меншою, ніж частота кадрів відтворення відео. Важливим моментом у цьому повідомленні є те, що воно показує, що буферизацією керує гравець, а не транспортний протокол.

Протоколи партнерства

Хоча інтерактивна програма не хотіла затримок, викликаних TCP, вони хотіли деяку функціональність цього протоколу. Вони хотіли більшого, ніж міг забезпечити UDP. Таким чином, були складені інші протоколи для заповнення частин можливостей TCP.

Протокол ініціації сесії

Протокол ініціації сеансу (SIP) був винайдений для програм Voice over IP (VoIP). Інтернет-телефонія не хотіла буферизації TCP, але їм потрібно було наслідувати традиційні процедури встановлення викликів телефонів набрати, зателефонувати, зайнятись, забрати та закінчити дзвінок. Однак SIP не керує всім сеансом, він просто піклується про створення підключення та функції закриття TCP. Кожен дзвінок, який проходить через Інтернет, використовує SIP. Настільки, що “SIP” майже став взаємозамінним терміном з “VoIP.”

Запуск голосового трафіку на високошвидкісних цифрових з’єднаннях масово відомий як “SIP-магістраль.”Перемикання дзвінка з Інтернету на звичайний стаціонарний телефон називається”SIP-припинення.Індустрія цифрової телефонії використовує SIP для ідентифікації своєї технології, але основою всієї їх діяльності є UDP.

Транспортний протокол у режимі реального часу

Незважаючи на рішення, що TCP був занадто великим накладним накладенням на інтерактивний трафік і його слід скинути, інженери зв’язку продовжували повертатися до засобів, передбачених TCP і вони побажали, щоб вони могли мати їх з UDP. Транспортний протокол у режимі реального часу (RTP) компенсує чималий дефіцит функціональності, який виникає при використанні UDP.

Основна особливість цих додаткових протоколів, які роблять UDP релевантним для потокового передавання медіа, – це те, що вони дозволяють перенести деякі програми, традиційно керовані TCP, до програми. RTP обробляє деякі функції управління трафіком TCP, але не всі.

RTP здатний переупорядкувати з послідовних пакетів і помітити втрачені пакети. Однак функцію послідовності не потрібно реалізовувати і неможливо реалізувати без буферизації на транспортному шарі.

Протокол управління RTP

RTP завжди співпрацює з RTCP, що є протоколом управління RTP. RTPC емулює деякі функції управління сеансом TCP, за винятком того, що керівний принцип протоколу – не втручатися в потік і не уповільнювати передачу медіа; тому його діяльність нечаста. Протокол збиратиме дані про продуктивність, включаючи втрати пакетів, та швидкість передачі інформації. Програвач, що приймає, може використовувати цю інформацію для вирішення питання про перехід на відео з меншою роздільною здатністю або на інший стандарт кодування відео.

Якщо ви використовуєте відео- та аудіо-додаток, майже впевнено, що задіяні і RTP, і RTCP. Існує “переплетення“У визначенні RTSP (див. Нижче), який переміщав би RTP передачі на TCP. Однак це незвичайна пропозиція, яка ніколи не була реалізована за межами лабораторії. Без цієї специфікації всі RTP та RTCP заходи здійснюються UDP.

Протокол потокового потоку в реальному часі

Протокол потокового потокового передачі в реальному часі (RTSP) майже завжди бере участь у програмах для відтворення відео та аудіо чи запису. Цей протокол надає кнопки управління на вашому програвачі та диктофоні. Це пауза, запис / відтворення, швидка перемотка вперед та назад. Що цікаво, хоча RTSP може працювати над UDP, він зазвичай транспортується через TCP, навіть незважаючи на те, що він співпрацює з підтримкою UDP відео або аудіо потоку.

Програми лише для UDP

Ряд легких мереж, що підтримують додатки, використовують UDP без будь-яких інших протоколів, що складають моделювання функцій TCP. Ці функції майже виключно призначені лише для використання в приватних мережах оскільки вони не включають жодних процедур аутентифікації або шифрування передачі.

Якщо ви керуєте мережею, ви будете знайомі з Мережевий протокол часу (NTP), то Система доменних імен (DNS), то Протокол динамічної настройки хоста (DHCP), і Тривіальний протокол передачі файлів (TFTP). Усі ці служби адміністрування працюють над UDP. Поза цими приватними мережевими програмами дуже важко знайти будь-яку програму, що працює лише над UDP.

UDP проти TCP

Порівняння структури заголовка UDP та структури заголовка TCP показує вам обмеження UDP.

Структура заголовка UDP

Заголовок UDP містить лише чотири поля. З цих чотирьох Джерело Порт поле необов’язкове і може бути порожнім. У IPv4, the Контрольна сума поле також необов’язкове, хоча воно є обов’язковим для реалізації IPv6. Це означає, що у випадку передачі IPv4 заголовку UDP потрібно мати лише два фрагменти інформації.

Заголовок TCP може містити набагато більше інформації.

Структура заголовка TCP

Як видно з ілюстрації, заголовок пакета TCP має серію з дев’яти прапорів, які адаптують значення заголовка. У цій події є “невідкладне” поле. Це дає системі TCP набагато більше гнучкості, ніж UDP, і це показує, що набагато більше часу було вкладено в процедури для TCP та структури його заголовка пакетів, ніж було витрачено на розробку UDP.

Той факт, що заголовок TCP повинен включати порт джерела, дозволяє створити більш унікальний сокет, створивши ідентифікатор сеансу з IP-адреси джерела та призначення та номерів порту джерела та призначення. З UDP, оскільки він не має процедур для створення сеансу, кожне повідомлення трактується як виконане завдання, і протокол не намагається з’єднати пакети разом. Тому програми, які використовують USP, повинні самі керувати цією наступністю.

Безпека для UDP

Методи TCP, орієнтовані на з’єднання, значно спрощують реалізацію цього протоколу в UDP. Однак існують стандарти шифрування для UDP. Основний варіант, який безпосередньо спрямований на захист UDP, – це протокол безпеки транспортного рівня Datagram або DTLS.

На щастя, DTLS доступний у ряді безкоштовних бібліотек з відкритим кодом, тому вам не потрібно розчісувати визначення протоколу і писати свою відкриту програму для того, щоб її реалізувати. OpenSSL, що є бібліотекою відкритого коду, є найпоширенішим джерелом впровадження безпеки транспортного шару, що є найбільш широко впровадженою системою безпеки для TCP. Ця бібліотека також включає реалізацію DTLS, тож вам слід мати змогу зустріти захищені параметри UDP в тих самих програмах, які пропонують захищені TCP-з’єднання.

Інший варіант для користувачів UDP – покластися на систему безпеки, розроблену для роботи на Інтернет-шарі. Це є IPSec, або безпека Інтернет-протоколу. Оскільки IPSec працює нижче транспортного шару, він не в змозі працювати з портами, тому факт, що UDP не в змозі підтримувати сеанс, не має значення, коли IPSec займається Протоколи IP-рівня не можуть також створювати сеанси. Як система нижнього шару, IPSec може підтримувати будь-який протокол транспортного шару, включаючи UDP.

IPSec включає способи аутентифікації, а також шифрує пакети, щоб захистити їх від прослуховування прослуховувань. ІТ пропонує так само безпеку, як і популярний TLS, але є менш широко впровадженою. IPSec використовує систему Internet Key Exchange (IKEv2) для налаштування автентифікації, тому досить часто IPSec виставляється як IKEv2. Використовується методологія IKEv2 Діффі-Гелман, ключові процедури обміну, яка є точно тією самою системою, яку використовує TLS для методології сеансу захищеної веб-сторінки HTTPS.

Kerberos та керберизовані Інтернет-переговори ключів (KINK) – це два елементи системи безпеки, які зазвичай називають Kerberos. Процедури встановлення сесії в Керберосі використовують систему “квитків”, яка аналогічна методу TLS щодо використання “сертифікатів”. У самому низу стеку Kerberos лежить в основі IPSec. Одноіменний шар Kerberos розташований поверх UDP і використовує UDP-розетки для полегшення зв’язку. Отже, це безпечна система захисту від UDP. Захоплюючим засобом Kerberos є те, що він дозволяє вам використовувати шифрування AES для захисту ваших передач UDP. AES – це, напевно, найбезпечніший шифр із загальним використанням сьогодні, і це рекомендований метод безпеки для кращих у світі систем захисту конфіденційності VPN.

Незважаючи на очевидні труднощі щодо узгодження ключів шифрування в середовищі, що не забезпечує ніякого управління зв’язком, UDP пропонує варіанти безпеки. Тож, реалізуючи додаток на базі UDP, не відмовляйтесь від завдання забезпечити передачу.

Майбутнє УДП

Чисті програми на основі UDP, які не включають сторонні протоколи для імітації TCP, є рідкісними, і вони, швидше за все, стануть ще рідшими. Легкі утиліти мережі, які використовують UDP, процвітають у захищених локальних мережах. Однак, оскільки загрози безпеці від нових атак з нульовим днем ​​зростають щотижня, концепція наявності незахищених протоколів управління ключовими службами управління конфігурацією та адресацією здається нерозумно поступливою.

По мірі того, як мережі переходять на хмарну службу, послуги TFTP та DHCP на базі UDP почнуть замінюватися більш безпечними альтернативами. Просте рішення серфінгу програм через HTTPS, щоб забезпечити їм безпеку без додаткових зусиль програмування, косує майбутнє на TCP, який несе HTTPS і позбавляє можливості подалі від списку компетенцій UDP.

Ніша UDP підтримки передачі засобів масової інформації, ймовірно, збережеться. Уже існує багато конкурентних транспортних систем, запропонованих для підтримки інтерактивних додатків, але жодна з них не вивела UDP зі своєї позиції як перший вибір для VoIP та потокового відео. Цей список суперників включає:

Надійний протокол дейтаграм користувача (RUDP), який має реалізацію Cisco та Microsoft.

Протокол передачі управління потоком (SCTP), який невдало пропонувався замінити комбо UDP / RTP / RTCP, але ніколи не збився з місця.

Це потворне каченя під назвою UDP було виявлено лебедям завдяки магічним перетворюючим можливостям широкосмугових та інтерактивних додатків. Ця відроджена зірка буде продовжувати без особливих зусиль плавати по водах Інтернету.

Які способи передачі ви використовуєте? Ти бачиш, що УПР потворне каченя лебідь? Про свої враження пишіть у розділі коментарів нижче.

Пов’язані:
Кінцевий посібник з TCP / IP
Що таке TCPdump?
Огляд сервера SolarWinds TFTP
Огляд сервера TFTPD32 TFTP

Зображення:
Завідувач UDP від ​​Devarshi в англійських Wikibooks, ліцензованих під CC BY-SA 2.5
Макет пакету TCP з бітовою шкалою від Quliyevferman через Wikimedia Commons. Ліцензовано під CC BY-SA 4.0

Kim Martin
Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me