If you're seeing this message, it means we're having trouble loading external resources on our website.

Ако си зад уеб филтър, моля, увери се, че домейните *. kastatic.org и *. kasandbox.org са разрешени.

Основно съдържание

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

Протоколът за потребителска дейтаграма (UDP) е лек протокол за транспортиране на данни, който работи върху IP.
UDP предоставя механизъм за откриване на повредени данни в пакети, но не се опитва да решава други проблеми, които възникват с пакетите, като например загубени или разбъркани пакети. Ето защо UDP понякога е известен като Unreliable Data Protocol (ненадежден протокол за данни).
UDP е прост, но бърз протокол, поне в сравнение с други протоколи, които работят върху IP. Често се използва за чувствителни към времето приложения (като видео стрийминг в реално време), където скоростта е по-важна от точността.

Формат на пакета

При изпращане на пакети чрез UDP върху IP частта от данни на всеки IP пакет се форматира като UDP сегмент.
Диаграма на UDP сегмент в IP пакет. IP пакетът съдържа секции за заглавие и данни. Разделът с IP данни е UDP сегментът, който сам по себе си съдържа секции за заглавие и данни.
Всеки UDP сегмент съдържа 8-байтова заглавка и данни с променлива дължина.

Номера на портове

Първите четири байта от UDP заглавката съхраняват номерата на портовете за източника и за местоназначението.
Едно мрежово устройство може да получава съобщения на различни виртуални портове, подобно на начина, по който едно океанско пристанище може да приема лодки на различни портове. Различните портове помагат за разграничаването на различните видове мрежов трафик.
Ето списък на някои портове, които използва UDP протоколът на моя лаптоп:
Терминал на командния ред с команда "sudo lsof -i -n -P | grep UDP". Командата извежда като резултат следната таблица:
ПроцесID на процесаТипПорт
стартиран1IPv4UDP *:137
стартиран1IPv4UDP *:138
syslogd45IPv4UDP *:54465
mDNSResponder186IPv4UDP *:5353
mDNSResponder186IPv6UDP *:5353
mDNSResponder186IPv4UDP *:65327
mDNSResponder186IPv6UDP *:65327
mDNSResponder186IPv4UDP *:55657
mDNSResponder186IPv6UDP *:55657
Google12306IPv6UDP *:5353
Всеки ред започва с името на процеса, който портът използва, и завършва с протокола и номера на порта.
🔍 Какъв вид мрежов трафик обработват тези процеси? Ако потърсиш в мрежата името на процеса плюс номера на порта, вероятно можеш да го разбереш. Можеш дори да опиташ на компютъра, който използваш в момента.

Дължина на сегмента

Следващите два байта от UDP заглавката съхраняват дължината (в байтове) на сегмента (включително заглавката).
Два байта са 16 бита, така че дължината може да бъде толкова голяма, колкото това двоично число:
1111111111110000
Като десетична стойност, това е left parenthesis, 2, start superscript, 16, end superscript, minus, 1, right parenthesis, или 65, space, 535. Така максималната дължина на UDP сегмент е 65, space, 535 байта.

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

Последните два байта на заглавката на UDP са контролната сума. Това е поле, което се използва от подателя и получателя за проверка за повреда на данните.
Преди да изпрати сегмента, подателят:
  1. Изчислява контролната сума въз основа на данните в сегмента.
  2. Съхранява изчислената контролна сума в полето.
При получаване на сегмента получателят:
  1. Изчислява контролната сума въз основа на получения сегмент.
  2. Сравнява контролните суми една с друга. Ако контролните суми не са равни, той знае, че данните са повредени.
За да разберем как една контролна сума може да открие повредени данни, нека проследим процеса на изчисляване на контролна сума за много къс низ от данни: "Hola".
Първо, изпращачът ще кодира по някакъв начин "Hola" двоично. Следното кодиране използва ASCII/UTF-8 кодиране:
start text, H, end textstart text, o, end textstart text, l, end textstart text, a, end text
01001000011011110110110001100001
Това кодиране дава тези 4 байта:
1001000, space, 1101111, space, 1101100, space, 1100001
След това подателят сегментира байтовете в двоични числа от 2-байта (16-бита):
100100001101000110110001100000100{\,}100{\,}001{\,}101{\,}000\\ 110{\,}110{\,}001{\,}100{\,}000
За да изчисли контролната сума, подателят събира 16-битовите двоични числа:
0100100001101111+01101100011000011011010011010000\large\begin{aligned} 0100100001101111& \\ \underline{+0110110001100001}& \\ 1011010011010000 \end{aligned}
Компютърът вече може да изпрати UDP сегмент с кодирания "Hola" като данни и 1011010011010000 като контролна сума.
Целият UDP сегмент може да изглежда така:
ПолеСтойност
Номер на порта на източника00010101, space, 00001001
Номер на порта на местоназначението0001010, space, 100001001
Дължина00000000, space, 00000100
Контролна сума10110100, space, 11010000
Данни01001000, space, 01101111, space, 01101100, space, 01100001
Ами ако данните се повредят и от „Hola“ станат „Mola“ по пътя?
Първо, нека видим как биха изглеждали повредените данни в двоичен вид.
"Mola", кодирано в двоичен вид...
start text, M, end textstart text, o, end textstart text, l, end textstart text, a, end text
01001101011011110110110001100001
...и след това сегментирано на 16-битови числа:
100110101101000110110001100000100{\,}110{\,}101{\,}101{\,}000\\ 110{\,}110{\,}001{\,}100{\,}000
Сега нека видим каква контролна сума ще изчисли получателят:
0100110101101111+01101100011000011011100111010000\large\begin{aligned} 0100110101101111& \\ \underline{+0110110001100001}& \\ 1011100111010000 \end{aligned}
Получателят вече може програмно да сравни контролната сума, която е получил в UDP сегмента, с контролната сума, която току-що е изчислил:
  • Получено: 1011010011010000
  • Изчислено: 1011100111010000
Забелязваш ли разликата?
Когато получателят открие, че двете контролни суми са различни, той знае, че данните са били повредени по някакъв начин по пътя. За съжаление, получателят може да не може да използва изчислената контролна сума за реконструкция на оригиналните данни, така че вероятно просто ще изхвърли изцяло пакета.
Действителният процес на изчисляване на контролната сума на UDP включва няколко стъпки повече, в сравнение с показаните тук, но това е общият процес за използване на контролни суми за откриване на повредени данни.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️Имаш ли въпроси по тази тема? С радост ще ти отговорим—просто задай въпроса си по-долу!

Искаш ли да се присъединиш към разговора?

Все още няма публикации.
Разбираш ли английски? Натисни тук, за да видиш още дискусии в английския сайт на Кан Академия.