UDP

UDP ( англ. User Datagram Protocol - Протокол користувацьких датаграм) - один з ключових елементів Internet Protocol Suite (більш відомого як TCP / IP), набору мережевих протоколів для Інтернету. З UDP комп'ютерні додатки можуть надсилати повідомлення (в даному випадку звані датаграми) іншим хостам по IP-мережі без необхідності попереднього повідомлення для установки спеціальних каналів передачі або шляхів даних. Протокол був розроблений Девідом П. Рідом в 1980 році і офіційно визначений в RFC 768.

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

Природа UDP як протоколу без збереження стану також корисна для серверів, які відповідають на невеликі запити від величезного числа клієнтів, наприклад DNS і потокові мультимедійні додатки на зразок IPTV, Voice over IP, протоколи тунелювання IP і багато онлайн-ігри.


1. Службові порти

UDP-додатки використовують датаграммной сокети для установки з'єднання між хостами. Додаток пов'язує сокет з його кінцевою точкою передачі даних, яка є комбінацією IP-адреси і порту служби. Порт - це програмна структура, визначувана номером порту - 16 - бітним цілочисловим значенням (тобто від 0 до 65535). Порт 0 зарезервований, хоча і є припустимим значенням порту джерела в разі, якщо процес-відправник не очікує відповідь повідомлень.

IANA розбила номери портів на три групи.

  • Порти з номерами від 0 до 1023 використовуються для звичайних, добре відомих служб. В Unix -подібних операційних системах для використання таких портів необхідно дозвіл суперкористувача.
  • Порти з номерами від 1024 до 49151 призначені для зареєстрованих IANA служб.
  • Порти з 49152 по 65535 - динамічні і можуть бути використані для будь-яких цілей, оскільки офіційно не розроблені для якоїсь певної служби. Вони також використовуються як ефемерні (тимчасові) порти, на яких запущене на хості програмне забезпечення може випадковим чином вибрати порт для самовизначення. По суті, вони використовуються як тимчасові порти в основному клієнтами при зв'язку з серверами.

2. Структура пакета

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

UDP не надає жодних гарантій доставки повідомлення для протоколу верхнього рівня і не зберігає стану відправлених повідомлень. З цієї причини UDP іноді називають Unreliable Datagram Protocol (англ. - Ненадійний протокол датаграм).

UDP забезпечує багатоканальну передачу (за допомогою номерів портів) і перевірку цілісності (за допомогою контрольних сум) заголовка та суттєвих даних. Надійна передача в разі необхідності повинна реалізовуватися користувальницьким додатком.

Біти 0 - 15 16 - 31
0-31 Порт відправника (Source port) Порт одержувача (Destination port)
32-63 Довжина датаграми (Length) Контрольна сума (Checksum)
64 - ... Дані (Data)

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

Порт відправника

У цьому полі вказується номер порту відправника. Передбачається, що це значення задає порт, на який при необхідності буде посилатися відповідь. В іншому ж випадку, значення повинно бути рівним 0. Якщо хостом-джерелом є клієнт, то номер порту буде, швидше за все, ефемерним. Якщо джерелом є сервер, то його порт буде одним з "добре відомих".

Порт одержувача

Це поле обов'язково і містить порт одержувача. Аналогічно порту відправника, якщо клієнт - хост-одержувач, то номер порту ефемерний, інакше (сервер - одержувач) це "добре відомий порт".

Довжина датаграми

Поле, що задає довжину всієї датаграми (заголовка і даних) в байтах. Мінімальна довжина дорівнює довжині заголовка - 8 байт. Теоретично, максимальний розмір поля - 65535 байт для UDP-датаграми (8 байт на заголовок і 65527 на дані). Фактична межа для довжини даних при використанні IPv4 - 65507 (крім 8 байт на UDP-заголовок потрібно ще 20 на IP-заголовок).

У Jumbogram-ах IPv6 пакети UDP можуть мати більший розмір. Максимальне значення становить 4294967295 байт (2 ^ 32 - 1), з яких 8 байт відповідають заголовку, а решта 4294967287 байт - даними.

Контрольна сума

Поле контрольної суми використовується для перевірки заголовка і даних на помилки. Якщо сума не сгенерирована передавачем, то поле заповнюється нулями. Поле не є обов'язковим для IPv4.


3. Розрахунок контрольної суми

Метод для обчислення контрольної суми визначений в RFC 768.

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

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

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

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


3.1. Приклад розрахунку контрольної суми

Для прикладу розрахуємо контрольну суму декількох 16-бітних слів: 0x398a, 0xf802, 0x14b2, 0xc281. Знаходимо їх суму з порозрядним доповненням. 0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
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. Це і є шукана контрольна сума.

Різниця між IPv4 і IPv6 в даних, використовуваних для обчислення контрольної суми.


4. Псевдозаголовка

4.1. Псевдозаголовок для IPv4

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

Біти 0 - 7 8 - 15 16 - 23 24 - 31
0 Адреса джерела
32 Адреса одержувача
64 Нулі Протокол Довжина UDP
96 Порт джерела Порт одержувача
128 Довжина Контрольна сума
160 +
Дані

Адреси джерела й одержувача беруться з IPv4-заголовка. Значення поля "Протокол" для UDP одно 17 (0x11). Поле "Довжина UDP" відповідає довжині заголовка і даних.

Обчислення контрольної суми для IPv4 необов'язково, якщо вона не використовується, то значення дорівнює 0.


4.2. Псевдозаголовок для IPv6

При роботі UDP над IPv6 контрольна сума обов'язкове. Метод для її обчислення був опублікований в RFC 2460 :

При обчисленні контрольної суми знову використовується псевдозаголовок, що імітує реальний IPv6-заголовок:

Біти 0 - 7 8 - 15 16 - 23 24 - 31
0 Адреса джерела
32
64
96
128 Адреса одержувача
160
192
224
256 Довжина UDP
288 Нулі Наступний заголовок
320 Порт джерела Порт одержувача
352 Довжина Контрольна сума
384 +
Дані

Адреса джерела такий же, як і в IPv6-заголовку. Адреса одержувача - фінальний одержувач; якщо в IPv6-пакеті не міститься заголовка маршрутизації (Routing), то це буде адресу одержувача з IPv6-заголовка, в іншому випадку, на початковому вузлі, це буде адресу останнього елемента заголовка маршрутизації, а на вузлі-одержувачі - адресу одержувача з IPv6-заголовка. Значення "Наступний заголовок" дорівнює значенню протоколу - 17 для UDP. Довжина UDP - довжина UDP-заголовка і даних.


5. Надійність і вирішення проблеми перевантажень

Через нестачу надійності додатка UDP повинні бути готові до деяких втрат, помилок і дублювання. Деякі з них (наприклад, TFTP) можуть при необхідності додати елементарні механізми забезпечення надійності на прикладному рівні.

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

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

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



6. Додатки

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

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


7. Порівняння UDP і TCP

TCP - орієнтований на з'єднання протокол, що означає необхідність "рукостискання" для встановлення з'єднання між двома хостами. Як тільки з'єднання встановлено, користувачі можуть відправляти дані в обох напрямках.

  • Надійність - TCP управляє підтвердженням, повторною передачею і тайм-аутом повідомлень. Виробляються численні спроби доставити повідомлення. Якщо воно загубиться на шляху, сервер знову запросить втрачену частину. В TCP немає ні зниклих даних, ні (у випадку численних тайм-аутів) розірваних з'єднань.
  • Упорядкованість - якщо два повідомлення послідовно відправлені, перше повідомлення досягне додатка-одержувача першим. Якщо ділянки даних прибувають в невірному порядку, TCP відправляє невпорядковані дані в буфер до тих пір, поки всі дані не можуть бути впорядковані і передані додатком.
  • Ваговитість - TCP необхідно три пакети для установки сокет-з'єднання перед тим, як відправити дані. TCP стежить за надійністю і перевантаженнями.
  • Потоковость - дані читаються як потік байтів, не передається ніяких особливих позначень для кордонів повідомлення або сегментів.

UDP - більш простий, заснований на повідомленнях протокол без встановлення з'єднання. Протоколи такого типу не встановлюють виділеного з'єднання між двома хостами. Зв'язок досягається шляхом передачі інформації в одному напрямку від джерела до одержувача без перевірки готовності або стану отримувача. Однак, основною перевагою UDP над TCP є додатки для голосового зв'язку через інтернет-протокол (Voice over IP, VoIP), в якому будь-яке "рукостискання" завадило б гарною голосового зв'язку. У VoIP вважається, що кінцеві користувачі в реальному часі нададуть будь-яку необхідну підтвердження про отримання повідомлення.

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