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 сегмент съдържа 8-байтова заглавка и данни с променлива дължина.

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

Първите четири байта от UDP заглавката съхраняват номерата на портовете за източника и за местоназначението.
Едно мрежово устройство може да получава съобщения на различни виртуални портове, подобно на начина, по който едно океанско пристанище може да приема лодки на различни портове. Различните портове помагат за разграничаването на различните видове мрежов трафик.
Ето списък на някои портове, които използва UDP протоколът на моя лаптоп:
Всеки ред започва с името на процеса, който портът използва, и завършва с протокола и номера на порта.
🔍 Какъв вид мрежов трафик обработват тези процеси? Ако потърсиш в мрежата името на процеса плюс номера на порта, вероятно можеш да го разбереш. Можеш дори да опиташ на компютъра, който използваш в момента.

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

Следващите два байта от UDP заглавката съхраняват дължината (в байтове) на сегмента (включително заглавката).
Два байта са 16 бита, така че дължината може да бъде толкова голяма, колкото това двоично число:
1111111111110000
Като десетична стойност, това е (2161), или 65 535. Така максималната дължина на UDP сегмент е 65 535 байта.

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

Последните два байта на заглавката на UDP са контролната сума. Това е поле, което се използва от подателя и получателя за проверка за повреда на данните.
Преди да изпрати сегмента, подателят:
  1. Изчислява контролната сума въз основа на данните в сегмента.
  2. Съхранява изчислената контролна сума в полето.
При получаване на сегмента получателят:
  1. Изчислява контролната сума въз основа на получения сегмент.
  2. Сравнява контролните суми една с друга. Ако контролните суми не са равни, той знае, че данните са повредени.
За да разберем как една контролна сума може да открие повредени данни, нека проследим процеса на изчисляване на контролна сума за много къс низ от данни: "Hola".
Първо, изпращачът ще кодира по някакъв начин "Hola" двоично. Следното кодиране използва ASCII/UTF-8 кодиране:
Hola
01001000011011110110110001100001
Това кодиране дава тези 4 байта:
01001000 01101111 01101100 01100001
След това подателят сегментира байтовете в двоични числа от 2-байта (16-бита):
01001000011011110110110001100001
За да изчисли контролната сума, подателят събира 16-битовите двоични числа:
0100100001101111+01101100011000011011010011010000
Компютърът вече може да изпрати UDP сегмент с кодирания "Hola" като данни и 1011010011010000 като контролна сума.
Целият UDP сегмент може да изглежда така:
ПолеСтойност
Номер на порта на източника00010101 00001001
Номер на порта на местоназначението0001010 100001001
Дължина00000000 00000100
Контролна сума10110100 11010000
Данни01001000 01101111 01101100 01100001
Ами ако данните се повредят и от „Hola“ станат „Mola“ по пътя?
Първо, нека видим как биха изглеждали повредените данни в двоичен вид.
"Mola", кодирано в двоичен вид...
Mola
01001101011011110110110001100001
...и след това сегментирано на 16-битови числа:
01001101011011110110110001100001
Сега нека видим каква контролна сума ще изчисли получателят:
0100110101101111+01101100011000011011100111010000
Получателят вече може програмно да сравни контролната сума, която е получил в UDP сегмента, с контролната сума, която току-що е изчислил:
  • Получено: 1011010011010000
  • Изчислено: 1011100111010000
Забелязваш ли разликата?
Когато получателят открие, че двете контролни суми са различни, той знае, че данните са били повредени по някакъв начин по пътя. За съжаление, получателят може да не може да използва изчислената контролна сума за реконструкция на оригиналните данни, така че вероятно просто ще изхвърли изцяло пакета.
Действителният процес на изчисляване на контролната сума на UDP включва няколко стъпки повече, в сравнение с показаните тук, но това е общият процес за използване на контролни суми за откриване на повредени данни.
🙋🏽🙋🏻‍♀️🙋🏿‍♂️Имаш ли въпроси по тази тема? С радост ще ти отговорим—просто задай въпроса си по-долу!

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

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