1 00:00:00,240 --> 00:00:07,590 Informacje mogą być podzielone na segmenty lub podzielone na mniejsze fragmenty lub transmisja na 2 00:00:08,010 --> 00:00:15,040 nośniku fizycznym, maksymalna jednostka transmisji lub pusty interfejs wychodzący zależy od nośnika fizycznego. 3 00:00:15,090 --> 00:00:20,640 Jako przykład opróżniają cię z popiołu Ethana Jest to 5400 bajtów. 4 00:00:20,850 --> 00:00:28,650 Jednak TZP teoretycznie może obsługiwać sześćdziesiąt pięć tysięcy czterysta dziewięćdziesiąt pięć bajtów w jednym 5 00:00:28,650 --> 00:00:29,380 pakiecie. 6 00:00:29,460 --> 00:00:35,370 Kiedy jest on wysyłany do niższych warstw modelu ozonowego, który będzie musiał zostać podzielony 7 00:00:35,560 --> 00:00:42,330 na fragmenty w celu transmisji przez fizyczne medium, które na przykład obsługuje tylko 50 lub 100 bajtów. 8 00:00:42,330 --> 00:00:49,890 Dane są podzielone na mniejsze części, a odbiornik wykorzystujący TZP będzie musiał ponownie połączyć 9 00:00:49,890 --> 00:00:51,180 te fragmenty. 10 00:00:51,510 --> 00:00:58,950 Maksymalny rozmiar segmentu lub MSA to największa ilość danych w bajtach, którą TZP chce wysłać w 11 00:00:58,950 --> 00:01:02,010 jednym segmencie, aby uzyskać najlepszą wydajność. 12 00:01:02,010 --> 00:01:08,700 MSA jest na tyle mały, aby uniknąć fragmentacji Arpey, która może prowadzić do nadmiernej 13 00:01:08,700 --> 00:01:15,550 retransmisji, jeśli w pakiecie DCP obsługiwane jest coś o nazwie Maksymalny rozmiar segmentu i pauza. 14 00:01:15,600 --> 00:01:23,400 MT Wykrywanie lub maksymalne odnajdywanie jednostki Porth transmisji z nadajnikiem i odbiorcą może automatycznie określić, jaka 15 00:01:23,400 --> 00:01:31,260 jest maksymalna jednostka transmisji na ścieżce między nimi, a TZP wystarczy umieścić wystarczającą ilość danych w 16 00:01:31,260 --> 00:01:39,840 pojedynczym pakiecie, który pasuje do tego pustego, unikając w ten sposób fragmentacji pakietów i dzięki temu uniknięcie 17 00:01:39,840 --> 00:01:46,620 narzutu związanego z fragmentacją i umieszczenie fragmentów IP w twoim odkryciu jest opcjonalne 18 00:01:46,620 --> 00:01:55,440 w wersji IP 4, która stała się teraz obowiązkowa w wersji IP 6 ze względu na wydajność, jaką 19 00:01:55,860 --> 00:02:02,820 wnosi do transmisji TZP oraz fakt, że IP Wersja 6 nie obsługuje fragmentacji na 20 00:02:03,420 --> 00:02:12,190 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 21 00:02:12,550 --> 00:02:22,000 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 22 00:02:22,000 --> 00:02:27,370 szybko dla odbiorcy aby go otrzymać i przetworzyć niezawodnie. 23 00:02:27,580 --> 00:02:33,700 Jeśli ta sama transmisja danych będzie szybsza, niż odbiornik 24 00:02:33,700 --> 00:02:40,780 może obsłużyć odbiornik, usunie dane, które będą wymagały retransmisji, straci czas i 25 00:02:40,780 --> 00:02:49,410 zasoby sieciowe, dlatego większość mechanizmów kontroli przepływu próbuje zmaksymalizować transfer zgubiony, minimalizując wymagania dotyczące retransmisji. 26 00:02:49,470 --> 00:02:57,930 Możesz na przykład mieć komputer z potężnym przesyłu danych do palmtopa, który może przetwarzać dane tylko 27 00:02:57,930 --> 00:03:00,400 przy znacznie niższej stawce. 28 00:03:00,420 --> 00:03:07,710 PDA powinien zatem regulować przepływ danych, aby nie przytłoczony podstawową kontrolą przepływu TZP 29 00:03:07,710 --> 00:03:15,400 został zaimplementowany przez potwierdzenia od odbiorcy przy przesyłaniu danych. EECP używa czegoś, co nazywa 30 00:03:15,400 --> 00:03:19,440 się przesuwaniem okna, aby kontrolować przepływ danych. 31 00:03:19,530 --> 00:03:25,810 Okienkowanie pozwoli komputerowi odbierającemu na anonsowanie, ile danych jest w stanie odebrać przed 32 00:03:25,810 --> 00:03:28,330 przesłaniem potwierdzenia do komputera wysyłającego. 33 00:03:28,780 --> 00:03:34,720 W każdym segmencie TZP odbiorca określi w polu okna odbioru. 34 00:03:34,870 --> 00:03:41,200 Ilość dodatkowych odebranych danych w bajtach, które jest skłonne do buforowania dla połączenia, z 35 00:03:41,200 --> 00:03:48,400 którego wysyłający host może wysłać tylko do tej ilości danych, zanim stanie się Miss White, gdy 36 00:03:48,400 --> 00:03:54,610 potwierdzenie i aktualizacja rozmiaru okna z hosta UDP odbierającego nie implementują kontroli przepływu. 37 00:03:55,520 --> 00:04:02,090 A w środowisku VOIP jako przykład, który wykorzystuje UDP, nawet jeśli nie ma fizycznego 38 00:04:02,090 --> 00:04:08,990 połączenia między dwoma słuchawkami uczestniczącymi w rozmowie telefonicznej, połączenie zostanie zawieszone, a nadawca będzie wesoło kontynuować 39 00:04:08,990 --> 00:04:11,010 przesyłanie ogromnych ilości danych. 40 00:04:11,180 --> 00:04:18,770 Mimo że odbiornik nie może przetwarzać odebranych danych, protokół UDP opiera się na protokołach Hi-Lo w celu 41 00:04:18,770 --> 00:04:20,280 implementacji sterowania przepływem. 42 00:04:20,480 --> 00:04:28,850 Ponownie TZP jest zorientowana na połączenie i UDP jest mniej połączone TZP ustanowi połączenie 43 00:04:29,300 --> 00:04:33,080 i utrzyma połączenie podczas całej transmisji. 44 00:04:33,080 --> 00:04:37,220 Po zakończeniu transmisji sesja zostaje zakończona. 45 00:04:37,280 --> 00:04:43,980 UDP nie tworzy sesji i po prostu wyśle dane w nadziei, że odbiorca je odbierze. 46 00:04:45,180 --> 00:04:52,770 Po raz kolejny TZP wdraża niezawodność tam, gdzie każdy nadawany segment jest potwierdzany, 47 00:04:52,770 --> 00:04:59,070 a jeśli segment zniknął, jest retransmitowany UDP nie realizuje niezawodności. 48 00:04:59,220 --> 00:05:07,890 I znów opiera się na protokołach Hailo, aby wdrożyć dowolną niezawodność, jeśli jest to wymagane w niektórych przypadkach, 49 00:05:07,890 --> 00:05:12,940 takich jak VoIP lub wideo przesyłane przez infrastrukturę IP. 50 00:05:13,140 --> 00:05:15,550 Niezawodność nie jest wymagana. 51 00:05:15,600 --> 00:05:25,910 Nie ma sensu retransmitować ostatnich pakietów głosowych, więc szybkie porównanie pomiędzy UDP i TZP lub niezawodnym protokołem 52 00:05:25,910 --> 00:05:33,870 i najlepszym, lub zawodnym protokołem TZP, po raz kolejny jest ukierunkowane na połączenie. 53 00:05:34,120 --> 00:05:41,440 Żadne dane nie są przesyłane przed ustanowieniem sesji, ale przed przekazaniem danych odbywa się 54 00:05:41,440 --> 00:05:42,930 potrójne uzgadnianie. 55 00:05:42,940 --> 00:05:49,130 Istnieją potwierdzenia otrzymanych danych i numery sekwencji do śledzenia transmisji danych. 56 00:05:49,510 --> 00:05:56,850 Z drugiej strony, UDP jest mniej połączony i nie śledzi danych i nie zapewnia dostarczenia danych. 57 00:05:57,850 --> 00:06:00,080 TCAP to ciąg liczb. 58 00:06:00,190 --> 00:06:12,190 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 59 00:06:12,190 --> 00:06:18,370 VoIP i aplikacje do strumieniowego przesyłania wideo ze względu na charakter 60 00:06:18,370 --> 00:06:20,400 VoIP lub wideo. 61 00:06:20,530 --> 00:06:28,820 Nie ma powodu, aby retransmitować w środowisku VoIP, mówiący będzie musiał powtórzyć to, co powiedzieli. 62 00:06:28,840 --> 00:06:33,960 Jeśli słuchacz nie był w stanie odczytać tego, co zostało przekazane. 63 00:06:34,450 --> 00:06:41,890 Jeśli używasz czasami Skype'a, może to brzmieć tak, jakby osoba mówiąca była pod wodą lub brzmi 64 00:06:41,890 --> 00:06:45,570 bardziej jak maszyna niż osoba, którą znasz. 65 00:06:46,300 --> 00:06:52,240 Ale nadal możesz być w stanie zrozumieć, co powiedzieli, a tym samym, pomimo utraty danych, 66 00:06:52,240 --> 00:06:54,080 rozmowa może być kontynuowana. 67 00:06:54,190 --> 00:07:01,580 Lub jeśli zrobi się wystarczająco źle, poprosisz rozmówcę, aby powtórzył to, co powiedzieli w środowisku transmisji wideo. 68 00:07:01,600 --> 00:07:08,020 Możesz zauważyć, że część obrazu nie jest prawidłowo odświeżana, ale nadal możesz śledzić, co dzieje 69 00:07:08,020 --> 00:07:13,990 się w filmie ze względu na wrażliwą na czas naturę głosu i wideo. 70 00:07:14,050 --> 00:07:19,350 Jest to bezcelowe przekazywanie danych i dlatego TZP nie jest używane w tych środowiskach. 71 00:07:19,360 --> 00:07:24,780 UDP jest używany, więc UDP jest protokołem warstwy transportowej. 72 00:07:24,810 --> 00:07:32,430 Znajduje się w warstwie, gdy model zapewnia aplikacjom dostęp do warstwy sieciowej całej 73 00:07:32,440 --> 00:07:38,390 warstwy 3, bez omówionych powyżej mechanizmów odpowiedzialności za odpowiedzialność. 74 00:07:38,390 --> 00:07:42,380 Jest to idealne rozwiązanie dla aplikacji Voice over IP lub wideo. 75 00:07:42,530 --> 00:07:49,730 Jest to połączenie mniej, gdy jeden sposób datagramu centrum miejsce bez powiadomienia z wyprzedzeniem 76 00:07:49,730 --> 00:07:51,430 do urządzenia docelowego. 77 00:07:51,500 --> 00:07:55,440 Nie ma komunikacji przed transmisją danych. 78 00:07:55,820 --> 00:08:01,690 Dane właśnie docierają do odbiornika i oczekuje się, że odbiorca poradzi sobie z tymi danymi. 79 00:08:02,030 --> 00:08:08,940 UDP jest w stanie zapewnić bardzo ograniczone sprawdzanie błędów datagram UDP zawiera opcjonalne sprawdzanie 80 00:08:08,940 --> 00:08:16,080 pewnej wartości, którą urządzenie odbierające może wykorzystać do przetestowania integralności danych, nagłówek UDP zawiera 81 00:08:16,080 --> 00:08:23,490 także numer portu docelowego i jeśli ten datagram jest kierowany do aktywnego kod na urządzeniu 82 00:08:23,490 --> 00:08:29,900 odbierającym wiadomość zwrotną można przesłać, aby wskazać, że kod ten jest nieosiągalny. 83 00:08:29,910 --> 00:08:32,830 Za chwilę omówię bardziej szczegółowo numery portów. 84 00:08:33,090 --> 00:08:36,100 Jest to bardzo ważna koncepcja do zrozumienia. 85 00:08:36,150 --> 00:08:39,170 Protokół UDP zapewnia najlepszą jakość w momencie dostawy. 86 00:08:39,180 --> 00:08:47,160 Nie ma gwarancji, że dane zostaną dostarczone, a pakiety mogą zostać błędnie skierowane do duplikatów lub zagubione w drodze 87 00:08:47,160 --> 00:08:48,840 do miejsca przeznaczenia. 88 00:08:48,870 --> 00:08:57,970 Nie ma gwarancji otrzymania protokołów, które będą musiały wdrożyć niezawodność, jeśli będzie to wymagane. 89 00:08:58,030 --> 00:09:01,600 Nie są one również funkcjami odzyskiwania danych w UDP. 90 00:09:01,600 --> 00:09:07,800 Jeszcze raz protokoły Hilera będą musiały odzyskać od ostatnio uszkodzonych pakietów. 91 00:09:07,960 --> 00:09:17,440 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 92 00:09:17,530 --> 00:09:25,480 w mechanizmach sekwencjonowania i retransmisji, ponieważ nie może polegać na UDP w celu zapewnienia niezawodności. 93 00:09:25,480 --> 00:09:27,650 Głowica UDP jest bardzo prosta. 94 00:09:27,820 --> 00:09:35,810 Ma 16-bitowy numer portu źródłowego 16, ale numer portu do miejsca docelowego, więc podany numer portu jest 95 00:09:35,810 --> 00:09:40,780 używany przez źródło i numer portu używany przez miejsce docelowe. 96 00:09:41,000 --> 00:09:47,500 Ma 16-bitowe pole długości ETP, które określa długość w bajtach całego datagramu. 97 00:09:47,510 --> 00:09:54,020 Innymi słowy, nagłówek i dane minimalna długość datagramu UDP to 8 bajtów, ponieważ jest 98 00:09:54,020 --> 00:09:55,990 to długość nagłówka. 99 00:09:56,030 --> 00:10:01,550 Teoretycznie maksymalny rozmiar to sześćdziesiąt pięć tysięcy pięćset trzydzieści pięć bajtów. 100 00:10:01,740 --> 00:10:08,940 Ale wersja IP 4 nałoży maksymalny limit na sześćdziesiąt pięć tysięcy pięćset siedem bajtów. 101 00:10:09,080 --> 00:10:13,970 Opcjonalnie do sprawdzania błędów można użyć sumy kontrolnej UDP. 102 00:10:13,970 --> 00:10:19,150 Jest to opcjonalna wersja IP 4, ale nie jest opcjonalna w wersji IP 6.