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

Jeżeli jesteś za filtrem sieci web, prosimy, upewnij się, że domeny *.kastatic.org i *.kasandbox.org są odblokowane.

Główna zawartość

Protokół UDP (ang. User Datagram Protocol)

Protokół danych użytkownika (ang. User Datagram Protocol, UDP) jest lekkim protokołem transportu danych, który działa na wierzchu protokołu IP.
UDP dostarcza mechanizm wykrywania uszkodzonych danych w pakietach, ale nie próbuje rozwiązywać innych problemów, które pojawiają się z pakietami, takich jak zagubione lub nieuporządkowane pakiety. Z tego powodu UDP jest czasami znany jako Niewiarygodny Protokół Danych (ang. Unreliable Data Protocol).
UDP jest prosty, ale szybki, przynajmniej w porównaniu z innymi protokołami wykorzystującymi IP. Jest często używany w aplikacjach czułych na czas (takich jak strumieniowanie wideo w czasie rzeczywistym), gdzie szybkość jest ważniejsza niż dokładność.

Format pakietu

Podczas przesyłania pakietów za pomocą protokołu UDP poprzez IP, część danych w każdym pakiecie IP jest formatowana jako segment UDP.
Schemat segmentu UDP w pakiecie IP. Pakiet IP zawiera sekcje nagłówka i danych. Sekcja danych IP jest segmentem UDP, który sam zawiera sekcje nagłówka i danych.
Każdy segment UDP zawiera 8-bajtowy nagłówek i dane o zmiennej długości.

Numery portu

Pierwsze cztery bajty nagłówka UDP przechowują numery portów dla miejsca źródłowego i docelowego.
Urządzenie sieciowe może odbierać wiadomości na różnych wirtualnych portach, podobnie jak przystań na oceanie może przyjmować łodzie w różnych portach. Poszczególne porty pomagają rozróżnić różne rodzaje ruchu sieciowego.
Oto lista niektórych portów używanych przez UDP na moim laptopie:
Terminal wiersza poleceń z poleceniem "sudo lsof -i -n -P | grep UDP". Polecenie wypisuje następującą tabelę:
ProcesID ProcesuTypPort
launchd1IPv4UDP *:137
launchd1IPv4UDP *:138
syslogd45IPv4UDP *:54465
mDNSResponder186IPv4UDP *:5353
mDNSResponder186IPv6UDP *:5353
mDNSResponder186IPv4UDP *:65327
mDNSResponder186IPv6UDP *:65327
mDNSResponder186IPv4UDP *:55657
mDNSResponder186IPv6UDP *:55657
Google12306IPv6UDP *:5353
Każdy wiersz zaczyna się od nazwy procesu, który używa portu, a kończy na protokole i numerze portu.
🔍 Jaki rodzaj ruchu sieciowego obsługują te procesy? Jeśli poszukasz w sieci nazwy procesu i numeru portu, prawdopodobnie uda Ci się to ustalić. Możesz nawet spróbować tego na komputerze, którego używasz teraz.

Długość segmentu

Następne dwa bajty nagłówka UDP przechowują długość segmentu (w bajtach) (łącznie z nagłówkiem).
Dwa bajty to 16 bitów, więc długość może być tak duża jak ta liczba binarna:
1111111111110000
W systemie dziesiętnym jest to (2161) lub 65,535. Zatem maksymalna długość segmentu UDP wynosi 65,535 bajtów.

Suma kontrolna

Ostatnie dwa bajty nagłówka UDP to suma kontrolna, pole, które jest używane przez nadawcę i odbiorcę do sprawdzenia, czy dane nie są uszkodzone.
Przed wysłaniem segmentu, nadawca:
  1. Oblicza sumę kontrolną na podstawie danych zawartych w segmencie.
  2. Zapisuje wyliczoną sumę kontrolną w polu.
Po otrzymaniu segmentu, odbiorca:
  1. Oblicza sumę kontrolną na podstawie odebranego segmentu.
  2. Porównuje sumy kontrolne ze sobą. Jeśli sumy kontrolne nie są identyczne, wiadomo, że dane zostały uszkodzone.
Aby zrozumieć, w jaki sposób suma kontrolna może wykryć uszkodzone dane, prześledźmy proces obliczania sumy kontrolnej dla bardzo krótkiego ciągu danych: "Hola".
Po pierwsze, nadawca zakodowałby "Hola" w jakiś sposób binarnie. Poniższe kodowanie używa kodowania ASCII/UTF-8:
Hola
01001000011011110110110001100001
To kodowanie daje te 4 bajty:
01001000 01101111 01101100 01100001
Następnie nadawca dzieli bajty na 2-bajtowe (16-bitowe) liczby binarne:
01001000011011110110110001100001
Aby obliczyć sumę kontrolną, nadawca sumuje 16-bitowe liczby binarne:
0100100001101111+01101100011000011011010011010000
Komputer może teraz wysłać segment UDP z zakodowanym napisem "Hola" jako dane i 1011010011010000 jako sumę kontrolną.
Cały segment UDP może wyglądać tak:
PoleWartość
Numer portu źródłowego00010101 00001001
Numer portu docelowego0001010 100001001
Długość00000000 00000100
Suma kontrolna10110100 11010000
Dane01001000 01101111 01101100 01100001
Co by się stało, gdyby po drodze dane zostały uszkodzone z "Hola" na "Mola"?
Najpierw zobaczmy, jak uszkodzone dane wyglądałyby w postaci binarnej.
"Mola" zakodowana binarnie...
Mola
01001101011011110110110001100001
...a następnie podzielony na 16-bitowe liczby:
01001101011011110110110001100001
Zobaczmy teraz, jaką sumę kontrolną obliczyłby odbiorca:
0100110101101111+01101100011000011011100111010000
Odbiorca może teraz programowo porównać sumę kontrolną, którą otrzymał w segmencie UDP z sumą kontrolną, którą właśnie obliczył:
  • Otrzymał: 1011010011010000
  • Obliczył: 1011100111010000
Czy widzisz różnicę?
Gdy odbiorca odkryje, że obie sumy kontrolne są różne, wie, że dane zostały uszkodzone w jakiś sposób po drodze. Niestety, odbiorca nie może użyć wyliczonej sumy kontrolnej do odtworzenia oryginalnych danych, więc prawdopodobnie po prostu odrzuci pakiet.
Rzeczywisty proces obliczania sumy kontrolnej UDP obejmuje kilka kroków więcej niż przedstawiono tutaj, ale jest to ogólny proces, w jaki sposób możemy używać sum kontrolnych do wykrywania uszkodzonych danych.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️Masz pytania związane z tym zagadnieniem? Możesz zadać swoje pytanie poniżej!

Chcesz dołączyć do dyskusji?

Na razie brak głosów w dyskusji
Rozumiesz angielski? Kliknij tutaj, aby zobaczyć więcej dyskusji na angielskiej wersji strony Khan Academy.