Główna zawartość

Podstawy informatyki - program rozszerzony

Kurs: Podstawy informatyki - program rozszerzony > Rozdział 2

Lekcja 5: Transportowanie pakietów

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.

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ę:

Proces	ID Procesu	Typ	Port
launchd	1	IPv4	UDP *:137
launchd	1	IPv4	UDP *:138
syslogd	45	IPv4	UDP *:54465
mDNSResponder	186	IPv4	UDP *:5353
mDNSResponder	186	IPv6	UDP *:5353
mDNSResponder	186	IPv4	UDP *:65327
mDNSResponder	186	IPv6	UDP *:65327
mDNSResponder	186	IPv4	UDP *:55657
mDNSResponder	186	IPv6	UDP *:55657
Google	12306	IPv6	UDP *: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:

1 111 111 111 110 000

W systemie dziesiętnym jest to

(2^{16} - 1)

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:

Oblicza sumę kontrolną na podstawie danych zawartych w segmencie.
Zapisuje wyliczoną sumę kontrolną w polu.

Po otrzymaniu segmentu, odbiorca:

Oblicza sumę kontrolną na podstawie odebranego segmentu.
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:

$H$ ‍	$o$ ‍	$l$ ‍	$a$ ‍
$01001000$ ‍	$01101111$ ‍	$01101100$ ‍	$01100001$ ‍

To kodowanie daje te

4

bajty:

01001000 01101111 01101100 01100001

Następnie nadawca dzieli bajty na

2

-bajtowe (

16

-bitowe) liczby binarne:

\begin{aligned} 0100100001101111 \\ 0110110001100001 \end{aligned}

Aby obliczyć sumę kontrolną, nadawca sumuje

16

-bitowe liczby binarne:

\begin{aligned} 0100100001101111 \\ \underset{―}{+ 0110110001100001} \\ 1011010011010000 \end{aligned}

[Jak dodawać liczby dwójkowe?]

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:

Pole	Wartość
Numer portu źródłowego	$00010101 00001001$ ‍
Numer portu docelowego	$0001010 100001001$ ‍
Długość	$00000000 00000100$ ‍
Suma kontrolna	$10110100 11010000$ ‍
Dane	$01001000 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...

$M$ ‍	$o$ ‍	$l$ ‍	$a$ ‍
$01001101$ ‍	$01101111$ ‍	$01101100$ ‍	$01100001$ ‍

...a następnie podzielony na 16-bitowe liczby:

\begin{aligned} 0100110101101111 \\ 0110110001100001 \end{aligned}

Zobaczmy teraz, jaką sumę kontrolną obliczyłby odbiorca:

\begin{aligned} 0100110101101111 \\ \underset{―}{+ 0110110001100001} \\ 1011100111010000 \end{aligned}

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ę?

[Wyjaśnij mi to]

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!

[Gdzie mogę to znaleźć?]

Chcesz dołączyć do dyskusji?

Zaloguj się

Sortuj według

Na razie brak głosów w dyskusji

Rozumiesz angielski? Kliknij tutaj, aby zobaczyć więcej dyskusji na angielskiej wersji strony Khan Academy.