Informacje mogą być podzielone na segmenty lub podzielone na mniejsze fragmenty lub transmisja na
nośniku fizycznym, maksymalna jednostka transmisji lub pusty interfejs wychodzący zależy od nośnika fizycznego.
Jako przykład opróżniają cię z popiołu Ethana Jest to 5400 bajtów.
Jednak TZP teoretycznie może obsługiwać sześćdziesiąt pięć tysięcy czterysta dziewięćdziesiąt pięć bajtów w jednym
pakiecie.
Kiedy jest on wysyłany do niższych warstw modelu ozonowego, który będzie musiał zostać podzielony
na fragmenty w celu transmisji przez fizyczne medium, które na przykład obsługuje tylko 50 lub 100 bajtów.
Dane są podzielone na mniejsze części, a odbiornik wykorzystujący TZP będzie musiał ponownie połączyć
te fragmenty.
Maksymalny rozmiar segmentu lub MSA to największa ilość danych w bajtach, którą TZP chce wysłać w
jednym segmencie, aby uzyskać najlepszą wydajność.
MSA jest na tyle mały, aby uniknąć fragmentacji Arpey, która może prowadzić do nadmiernej
retransmisji, jeśli w pakiecie DCP obsługiwane jest coś o nazwie Maksymalny rozmiar segmentu i pauza.
MT Wykrywanie lub maksymalne odnajdywanie jednostki Porth transmisji z nadajnikiem i odbiorcą może automatycznie określić, jaka
jest maksymalna jednostka transmisji na ścieżce między nimi, a TZP wystarczy umieścić wystarczającą ilość danych w
pojedynczym pakiecie, który pasuje do tego pustego, unikając w ten sposób fragmentacji pakietów i dzięki temu uniknięcie
narzutu związanego z fragmentacją i umieszczenie fragmentów IP w twoim odkryciu jest opcjonalne
w wersji IP 4, która stała się teraz obowiązkowa w wersji IP 6 ze względu na wydajność, jaką
wnosi do transmisji TZP oraz fakt, że IP Wersja 6 nie obsługuje fragmentacji na
routerach wzdłuż ścieżki między dwoma hostami UDP nie obsługuje tego i wymaga protokołów wyższego poziomu do uporządkowania kontroli
przepływu fragmentów GCP używa kontroli przepływu od końca do końca, aby uniknąć sytuacji, w której wysyłający wysyła dane zbyt
szybko dla odbiorcy aby go otrzymać i przetworzyć niezawodnie.
Jeśli ta sama transmisja danych będzie szybsza, niż odbiornik
może obsłużyć odbiornik, usunie dane, które będą wymagały retransmisji, straci czas i
zasoby sieciowe, dlatego większość mechanizmów kontroli przepływu próbuje zmaksymalizować transfer zgubiony, minimalizując wymagania dotyczące retransmisji.
Możesz na przykład mieć komputer z potężnym przesyłu danych do palmtopa, który może przetwarzać dane tylko
przy znacznie niższej stawce.
PDA powinien zatem regulować przepływ danych, aby nie przytłoczony podstawową kontrolą przepływu TZP
został zaimplementowany przez potwierdzenia od odbiorcy przy przesyłaniu danych. EECP używa czegoś, co nazywa
się przesuwaniem okna, aby kontrolować przepływ danych.
Okienkowanie pozwoli komputerowi odbierającemu na anonsowanie, ile danych jest w stanie odebrać przed
przesłaniem potwierdzenia do komputera wysyłającego.
W każdym segmencie TZP odbiorca określi w polu okna odbioru.
Ilość dodatkowych odebranych danych w bajtach, które jest skłonne do buforowania dla połączenia, z
którego wysyłający host może wysłać tylko do tej ilości danych, zanim stanie się Miss White, gdy
potwierdzenie i aktualizacja rozmiaru okna z hosta UDP odbierającego nie implementują kontroli przepływu.
A w środowisku VOIP jako przykład, który wykorzystuje UDP, nawet jeśli nie ma fizycznego
połączenia między dwoma słuchawkami uczestniczącymi w rozmowie telefonicznej, połączenie zostanie zawieszone, a nadawca będzie wesoło kontynuować
przesyłanie ogromnych ilości danych.
Mimo że odbiornik nie może przetwarzać odebranych danych, protokół UDP opiera się na protokołach Hi-Lo w celu
implementacji sterowania przepływem.
Ponownie TZP jest zorientowana na połączenie i UDP jest mniej połączone TZP ustanowi połączenie
i utrzyma połączenie podczas całej transmisji.
Po zakończeniu transmisji sesja zostaje zakończona.
UDP nie tworzy sesji i po prostu wyśle dane w nadziei, że odbiorca je odbierze.
Po raz kolejny TZP wdraża niezawodność tam, gdzie każdy nadawany segment jest potwierdzany,
a jeśli segment zniknął, jest retransmitowany UDP nie realizuje niezawodności.
I znów opiera się na protokołach Hailo, aby wdrożyć dowolną niezawodność, jeśli jest to wymagane w niektórych przypadkach,
takich jak VoIP lub wideo przesyłane przez infrastrukturę IP.
Niezawodność nie jest wymagana.
Nie ma sensu retransmitować ostatnich pakietów głosowych, więc szybkie porównanie pomiędzy UDP i TZP lub niezawodnym protokołem
i najlepszym, lub zawodnym protokołem TZP, po raz kolejny jest ukierunkowane na połączenie.
Żadne dane nie są przesyłane przed ustanowieniem sesji, ale przed przekazaniem danych odbywa się
potrójne uzgadnianie.
Istnieją potwierdzenia otrzymanych danych i numery sekwencji do śledzenia transmisji danych.
Z drugiej strony, UDP jest mniej połączony i nie śledzi danych i nie zapewnia dostarczenia danych.
TCAP to ciąg liczb.
UDP nie używa aplikacji TZP, które zawierają pocztę HGP, a aplikacje FGP, które używają UDP, to aplikacje do przesyłania głosu, takie jak
VoIP i aplikacje do strumieniowego przesyłania wideo ze względu na charakter
VoIP lub wideo.
Nie ma powodu, aby retransmitować w środowisku VoIP, mówiący będzie musiał powtórzyć to, co powiedzieli.
Jeśli słuchacz nie był w stanie odczytać tego, co zostało przekazane.
Jeśli używasz czasami Skype'a, może to brzmieć tak, jakby osoba mówiąca była pod wodą lub brzmi
bardziej jak maszyna niż osoba, którą znasz.
Ale nadal możesz być w stanie zrozumieć, co powiedzieli, a tym samym, pomimo utraty danych,
rozmowa może być kontynuowana.
Lub jeśli zrobi się wystarczająco źle, poprosisz rozmówcę, aby powtórzył to, co powiedzieli w środowisku transmisji wideo.
Możesz zauważyć, że część obrazu nie jest prawidłowo odświeżana, ale nadal możesz śledzić, co dzieje
się w filmie ze względu na wrażliwą na czas naturę głosu i wideo.
Jest to bezcelowe przekazywanie danych i dlatego TZP nie jest używane w tych środowiskach.
UDP jest używany, więc UDP jest protokołem warstwy transportowej.
Znajduje się w warstwie, gdy model zapewnia aplikacjom dostęp do warstwy sieciowej całej
warstwy 3, bez omówionych powyżej mechanizmów odpowiedzialności za odpowiedzialność.
Jest to idealne rozwiązanie dla aplikacji Voice over IP lub wideo.
Jest to połączenie mniej, gdy jeden sposób datagramu centrum miejsce bez powiadomienia z wyprzedzeniem
do urządzenia docelowego.
Nie ma komunikacji przed transmisją danych.
Dane właśnie docierają do odbiornika i oczekuje się, że odbiorca poradzi sobie z tymi danymi.
UDP jest w stanie zapewnić bardzo ograniczone sprawdzanie błędów datagram UDP zawiera opcjonalne sprawdzanie
pewnej wartości, którą urządzenie odbierające może wykorzystać do przetestowania integralności danych, nagłówek UDP zawiera
także numer portu docelowego i jeśli ten datagram jest kierowany do aktywnego kod na urządzeniu
odbierającym wiadomość zwrotną można przesłać, aby wskazać, że kod ten jest nieosiągalny.
Za chwilę omówię bardziej szczegółowo numery portów.
Jest to bardzo ważna koncepcja do zrozumienia.
Protokół UDP zapewnia najlepszą jakość w momencie dostawy.
Nie ma gwarancji, że dane zostaną dostarczone, a pakiety mogą zostać błędnie skierowane do duplikatów lub zagubione w drodze
do miejsca przeznaczenia.
Nie ma gwarancji otrzymania protokołów, które będą musiały wdrożyć niezawodność, jeśli będzie to wymagane.
Nie są one również funkcjami odzyskiwania danych w UDP.
Jeszcze raz protokoły Hilera będą musiały odzyskać od ostatnio uszkodzonych pakietów.
TFT jako przykład ma wbudowany mechanizm do obsługi utraty danych i TFT P przy użyciu UDP ma swój własny szereg
w mechanizmach sekwencjonowania i retransmisji, ponieważ nie może polegać na UDP w celu zapewnienia niezawodności.
Głowica UDP jest bardzo prosta.
Ma 16-bitowy numer portu źródłowego 16, ale numer portu do miejsca docelowego, więc podany numer portu jest
używany przez źródło i numer portu używany przez miejsce docelowe.
Ma 16-bitowe pole długości ETP, które określa długość w bajtach całego datagramu.
Innymi słowy, nagłówek i dane minimalna długość datagramu UDP to 8 bajtów, ponieważ jest
to długość nagłówka.
Teoretycznie maksymalny rozmiar to sześćdziesiąt pięć tysięcy pięćset trzydzieści pięć bajtów.
Ale wersja IP 4 nałoży maksymalny limit na sześćdziesiąt pięć tysięcy pięćset siedem bajtów.
Opcjonalnie do sprawdzania błędów można użyć sumy kontrolnej UDP.
Jest to opcjonalna wersja IP 4, ale nie jest opcjonalna w wersji IP 6.