UDP

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

User Datagram Protocol, UDP (укр. Протокол дейтаграм користувача) — один із протоколів в стеку TCP/IP. Від протоколу TCP він відрізняється тим, що працює без встановлення з'єднання. UDP — це один з найпростіших протоколів транспортного рівня моделі OSI, котрий виконує обмін дейтаграмами без підтвердження та гарантії доставки. При використанні протоколу UDP обробка помилок і повторна передача даних має виконуватися протоколом вищого рівня. Але, незважаючи на всі недоліки, протокол UDP є ефективним для серверів, що надсилають невеликі відповіді великій кількості клієнтів.

Протокол UDP використовують такі сервіси та протоколи вищого рівня:

  • TFTP (англ. Trivial File Transfer Protocol, найпростіший протокол передачі файлів),
  • SNMP (англ. Simple Network Management Protocol, простий протокол управління мережею),
  • DHCP (англ. Dynamic Host Configuration Protocol, протокол динамічної конфігурації вузла),
  • DNS (англ. Domain Name System, служба доменних імен).

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

Технічний огляд[ред.ред. код]

UDP є одним з найпростіших протоколів транспортного рівня моделі OSI. Його детальний опис можна знайти в IETF RFC 768. UDP забезпечує дуже простий інтерфейс між мережним та програмним рівнями. UDP не гарантує доставку повідомлень, та відправник не запам'ятовує стан вже відісланих повідомлень. З цієї причини протокол UDP іноді розшифровують як <<Unreliable Datagram Protocol>>(протокол ненадійних дейтаграм). Якщо на базі UDP треба організувати надійну передачу даних, то для цього необхідно залучити протоколи більш високого рівня.

Заголовок UDP конверту складається з 4 полів, з яких 2 є опціональними. «Порт відправника» та «порт одержувача» — це 16-бітні поля, котрі ідентифікують відправляючий та одержуючий процеси. «Порт відправника» є необов'язковим, оскільки UDP працює без встановлення з'єднання та відправник може не потребувати відповіді. В такій ситуації «порт відправника» повинен дорівнюватися нулю. Поле «Розмір» є обов'язковим, воно визначає довжину усієї UDP дейтаграми в байтах, з полем «Дані» включно. Мінімальне значення цього поля дорівнює 8 байт.

Останнє поле заголовка довжиною 16 біт містить у собі контрольну суму заголовка і поля даних. «Контрольна сума» теж є необов'язковим полем, але на практиці воно майже завжди використовується.

Програми, що використовують UDP в якості транспортного протоколу, мають бути готові до помилок, втрати деяких конвертів та повторної передачі даних. Деякі програми, такі як TFTP, можуть використовувати додаткові програмні механізми для підвищення надійності передачі. Але у більшості випадків, для таких програм, надійність не є необхідною і може навіть завадити уповільненням зв'язку. Потокове відео, ігри реального часу та VoIP(голос поверх IP) є прикладами програм, що дуже часто використовують UDP. Якщо ж програма потребує високого рівня надійності, то може використовуватися такий протокол як TCP або надлишковість коду, за допомогою якої можна знаходити помилки при передачі даних.

Оскільки у протоколі UDP відсутній будь-який контрольний механізм запобігання перевантаженням, мережні механізми повинні мати засоби для зменшення ефекту потенційних перевантажень від великого, неконтрольованого потоку UDP-трафіку. Кажучи інакше, оскільки UDP-відправники не спроможні виявляти перевантаженість, мережні елементи, такі як роутери, що використовують «черги конвертів» та <<відкидання конвертів>>, залишаються єдиним інструментом для призупинення надмірного UDP-трафіку. DCCP(англ. Datagram Congestion Control Protocol, протокол контролю навантаженості дейтаграм) був створений як часткове рішення цієї проблеми. Він контролює навантаження на кінцевих вузлах високошвидкісних потоків UDP-трафіку, наприклад, потокового відео.

Хоча кількість UDP трафіку в типовій мережі сягає лишень кількох відсотків, проте багато важливих програм використовують UDP. Серед них: DNS(Domain Name System, служба доменних імен), SNMP(англ. Simple Network Management Protocol, простий протокол управління мережею), DHCP(англ. Dynamic Host Configuration Protocol, протокол динамічної конфігурації вузла), RIP(англ. Routing Information Protocol, протокол маршрутизації інформації) та багато інших.

Див. також[ред.ред. код]

Структура[ред.ред. код]

пакету UDP є мінімальним послати-орієнтовано протокол Транспортного Шару, який документується в IETF RFC 768.

, UDP не забезпечує ніяких гарантій до верхнього протоколу шару, бо постачання повідомлення і UDP шар протоколу не зберігає ніякої держави повідомлень UDP одного разу, послав. Тому, UDP іноді називається Ненадійний Датаграмний Протокол.[3]

UDP забезпечує прикладне мультиплексування(через портові номери) і верифікацію(через контрольну суму) цілісності заголовка і корисного вантажу.[4] Якщо надійність передачі бажана, це повинно здійснюватися в додатку користувача.

Біти 0-15 16-31
0-31 Початковий Номер Порту Номер Порту Призначення
32-63 Довжина Контрольна сума
64-... Дані (Data)

Заголовок UDP складається з 4 полів, кожен з якого становить 2 байти(16 бітів).[1] Використання двоє з тих необов'язкове в IPv4(рожева підготовка в таблиці). У IPv6 тільки початковий порт необов'язковий(подивіться нижче).

Початковий номер порту

Це поле ідентифікує порт посилача, коли значимо і треба передбачатися, щоб бути портом, щоб відповісти, якщо треба. Якщо не використано, то це повинно бути нульовим. Якщо початковий вузол - клієнт, номер порту, ймовірно, є ефемерним номером порту. Якщо початковий вузол - сервер, номер порту, ймовірно, є відомим номером порту.[2]

Номер порту призначення

Це поле ідентифікує порт одержувача і вимагається. Подібний до початкового номера порту, якщо клієнт - вузол призначення потім номер порту ймовірно буде ефемерним номером порту і якщо вузол призначення - сервер потім номер порту ймовірно буде відомим номером порту.[2] Перші 64 біта (8 байт) датаграми є UDP- заголовком, іншими бітами — ці повідомлення: Довжина

Поле, яке конкретизує довжину у байтах повної datagram : заголовок і дані. Мінімальна довжина становить 8 байтів відколи це довжина заголовка. Розмір поля встановлює, що теоретичні обмежують 65,535 байтів(8 байтового заголовка 65,527 байтів даних) для datagram UDP. Практичні обмежують, бо довжина даних, яку накладає основний IPv4 протокол, становить 65,507 байтів(65,535 − 8 байтовий UDP заголовок − 20 заголовок байтовий IP).[2]

У IPv6 Jumbograms можливо мати UDP пакети розміру, більшого, ніж 65,535 байтів.[5] Це дозволяє значення максимальної довжини 4,294,967,295 байтів(2^32 - 1) з 8 байтами, що представляють заголовок і 4,294,967,287 байти для даних.

Контрольна сума Поле контрольної суми використане для error-checking заголовка і даних. Якщо ніякої контрольної суми не генерує посилач, поле користується цілком-нулями значення.[6] Це поле не необов'язкове для IPv6.[7]

Порівняння UDP і TCP[ред.ред. код]

Основна стаття: Протокол Елементу управління Передачі Транспортного Рівня

  • - орієнтований на з'єднання протокол, який означає, що це вимагає, щоб процедура встановлення зв'язку встановила наскрізні зв'язки. Як тільки підключення встановлене призначені для користувача дані, можливо, посилається bi-directionally над підключенням.
  • Надійний - TCP управляє підтвердженням повідомлення, повторною передачею і таймаутом. Множник намагається доставити зроблені повідомлення. Якщо це заблукало уздовж шляху, сервер повторно запросить частину втрати. У TCP, там є або немає відсутніх даних, або, у разі множинних таймаутів, підключення пропущене.
  • Замовлено - якщо два повідомлення посилаються над підключенням один за іншим, перше повідомлення досягне одержуючого застосування спочатку. Коли сегменти даних прибувають в неправильне замовлення, TCP буферизує out-of-order дані до усі дані не можуть бути належним чином повторно замовлені і доставлені застосуванню.
  • Важкоатлет - TCP вимагає, щоб три пакети встановили підключення сокета, перед тим, як будь-які призначені для користувача дані зможуть бути послані. TCP обробляє надійність і елемент управління перевантаження.
  • Витікаючи - Дані вичитаний як байтовий потік, ніякі розрізняючі вказівки не передаються межам сигнального повідомлення(сегмент).

UDP - те, що простіше послати-базував connectionless протокол. Connectionless протоколи не встановлюють віддане наскрізне підключення. Комунікації досягає передача інформації в одному напрямі від джерела до адресата без підтвердження готовності або стану одержувача. Проте, одна первинна вигода від UDP над TCP - застосування, щоб виразити над протоколом(VoIP) міжмережевої взаємодії, де б будь-яка процедура встановлення зв'язку перешкоджала ясній голосовій комунікації. Це передбачається в VoIP UDP, що кінцеві користувачі забезпечують будь-яке необхідне реальне підтвердження часу що повідомлення було отримане.

  • Ненадійний - Коли повідомлення послане, це не може бути відоме, якщо це досягне його адресата; він зміг заблукати уздовж шляху. Немає ніякого концепту підтвердження, повторної передачі або таймауту.
  • Не замовляється - Якщо два повідомлення відправлені тому ж одержувачеві, замовлення, в якому вони прибувають, не може бути передбачений.
  • Легка вага - немає ніякого впорядкування повідомлень, ніяких гончих підключень, і т.п. Це - маленький транспортний рівень, що проектується на довершення IP.
  • Datagrams - Пакети посилаються індивідуально і є був відмічений для цілісності, тільки якщо вони прибувають. Пакети мають певні межі, які шануються, означаючи, що операція читання даних в сокеті одержувача приводитиме повне повідомлення, оскільки це було спочатку послане.
  • Немає елементу управління перевантаження - UDP безпосередньо не уникає перевантаження, і можливо для високих застосувань пропускної спроможності запустити колапс перевантаження, якби тільки вони здійснювали елемент управління перевантаження зважений в прикладному рівні.

UDP[ред.ред. код]

Біти 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

0-31 Порт посилача(Source port) Порт одержувача(Destination port)

32-63 Довжина датаграми(Length) Контрольна сума(Checksum) 64 -… Дані(Data)

Значення поля «довжина датаграми» вказує на довжину усього UDP- повідомлення, тобто включаючи і UDP- заголовок. Вимірюється в октетах(байтах).

Максимальна довжина даних Для обчислення максимальної довжини даних в UDP- повідомленні при передачі в IP мережах необхідно врахувати, що UDP- повідомлення у свою чергу є вмістом області даних IP- повідомлення. Максимальна довжина IP- повідомлення(з урахуванням заголовка) дорівнює 65535 октетів. Тому максимальна довжина UDP- повідомлення(за вирахуванням мінімального IP- заголовка) дорівнює 65535 − 20 = 65515 октетів. Довжина заголовка UDP- повідомлення дорівнює 8 октетам, отже, максимальна довжина даних в UDP- повідомленні дорівнює 65515 − 8 = 65507 октетів. На практиці нераціонально використати максимальну величину IP пакету, оскільки такий розмір перевищує MTU основних протоколів канального рівня, і отже вимагає фрагментації IP пакету, тому зазвичай використовується розмір, співвіднесений з MTU використовуваного канального протоколу.

Октети IP- повідомлення 65535 20 Мінімальний IP- заголовок 65515 Цих IP- повідомлень: UDP- повідомлення 8 UDP- заголовок 65507 Дані

Псевдозаголовок При обчисленні контрольної суми до UDP- датаграмі додається спеціальний псевдо-заголовок з даними про одержувача і посилача наступного формату : Біти 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

0-31 IP- адреса посилача(Source address)

32-63 IP- адреса одержувача(Destination address)

64-95 0 0 0 0 0 0 0 0 Протокол(Protocol) Довжина UDP- датаграми(UDP length) Полі «протокол» містить в собі значення 17(00010001 в двійковому виді, 11 — в шістнадцятиричному) — ідентифікатор UDP- протоколу. Полі «довжина UDP-датаграми» містить в собі довжину UDP-повідомлення без псевдозаголовка в октетах, тобто збігається з однойменним полем в UDP-заголовку. Псевдозаголовок по мережі не передається, для перевірки контрольної суми відновлюється на хості призначення використовуючи дані з IP — і

Розрахунок контрольної суми Перед розрахунком контрольної суми UDP- повідомлення доповнюється у кінці нульовими бітами до довжини, кратної 16 бітам (псевдозаголовок і додаткові нульові біти не вирушають разом з повідомленням). Полі контрольної суми в UDP- заголовку під час розрахунку контрольної суми повідомлення, що відправляється, приймається нульовим. Для розрахунку контрольної суми псевдозаголовок і UDP- повідомлення розбивається на слова(1 слово = 2 байти(октету) = 16 біт). Потім розраховується порозрядне доповнення до одиниці суми усіх слів з порозрядним доповненням. Результат записується у відповідне поле в UDP- заголовку. Нульове значення контрольної суми зарезервоване, і означає що датаграма не має контрольної суми. У разі, якщо вичислена контрольна сума вийшла рівною нулю, поле заповнюють двійковими одиницями.

При отриманні повідомлення одержувач рахує контрольну суму наново(вже враховуючи поле контрольної суми), і, якщо в результаті вийде двійкове число з шістнадцяти одиниць - сума вірна.

Приклад розрахунку контрольної суми Для прикладу розрахуємо контрольну суму декількох 16-бітових слів : 0x398a, 0xf802, 0x14b2, 0xc281. Знаходимо їх суму з порозрядним доповненням. 0x398a 0xf802 = 0x1318c → 0x318d 0x318d 0x14b2 = 0x0463f → 0x463f 0x463f 0xc281 = 0x108c0 → 0x08c1

Тепер знаходимо порозрядне доповнення до одиниці отриманого результату : 0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e або, інакше — 0xffff − 0x08c1 = 0xf73e. Це і є шукана контрольна сума.

Поля Якщо задіяний порт посилача, то він вказує порт процесу, що посилає датаграму. Можна прийняти, що це той порт, на який за відсутності якої-небудь іншої інформації слід адресувати датаграму у відповідь. Якщо це поле не задіяне, то в нього слід записати нуль. Порт одержувача має сенс тільки в контексті конкретної Internet адреси одержувача. Довжина — довжина в октетах цієї датаграми, включаючи як заголовок, так і дані(це означає, що мінімальне значення поля довжини рівне восьми). Інтерфейс протоколу IP Модуль протоколу UDP повинен мати можливість витягати з Internet заголовка датаграми Internet адреси посилача і одержувача, а також тип протоколу. Один з можливих інтерфейсів UDP/IP міг би повертати у відповідь на команду отримання повну Internet датаграму, включаючи Internet заголовок цілком. Такий інтерфейс міг би також дозволити протоколу UDP передавати протоколу IP для посилки деяку готову Internet датаграму разом із заголовком.

External links[ред.ред. код]