WEBVTT 00:00.090 --> 00:01.020 Jason: W tej lekcji 00:01.020 --> 00:03.480 omówimy typy protokołów IP, w tym TCP, 00:03.480 --> 00:05.637 UDP oraz koncepcje metod bezpołączeniowych 00:05.637 --> 00:10.020 i zorientowanych na połączenia. 00:10.020 --> 00:12.300 Czym jest TCP? 00:12.300 --> 00:15.270 TCP to protokół kontroli transmisji. 00:15.270 --> 00:17.340 Jest to protokół zorientowany na połączenia, 00:17.340 --> 00:18.990 co oznacza, że jest to niezawodny 00:18.990 --> 00:22.080 sposób na transport segmentów w naszej sieci. 00:22.080 --> 00:23.580 Teraz, jeśli segment zostanie porzucony, 00:23.580 --> 00:25.770 protokół będzie faktycznie prosił o potwierdzenie za 00:25.770 --> 00:26.603 każdym razem. 00:26.603 --> 00:28.890 A jeśli nie otrzyma tego potwierdzenia, 00:28.890 --> 00:31.530 ponownie wyśle tę informację. 00:31.530 --> 00:34.410 Dlatego nazywamy to protokołem pełnym połączenia, ponieważ 00:34.410 --> 00:36.960 ma on dwukierunkowy typ informacji, w którym wysyłam 00:36.960 --> 00:38.280 ci informacje i weryfikuję, 00:38.280 --> 00:40.200 czy faktycznie je otrzymałeś, nasłuchując, 00:40.200 --> 00:43.170 czy je otrzymałeś, a ty dajesz mi odpowiedź. 00:43.170 --> 00:44.640 Spójrzmy teraz na ten mały 00:44.640 --> 00:46.230 diagram na ekranie. 00:46.230 --> 00:48.210 Zobaczysz, że po lewej stronie mam klienta, 00:48.210 --> 00:49.800 a po prawej serwer. 00:49.800 --> 00:52.860 Teraz klient wyśle do serwera tak 00:52.860 --> 00:55.950 zwany pakiet synchronizacji. 00:55.950 --> 00:57.240 Teraz, gdy serwer to 00:57.240 --> 00:58.170 otrzyma, wyśle 00:58.170 --> 01:00.720 klientowi potwierdzenie synchronizacji, 01:00.720 --> 01:02.580 znane jako syn ack. 01:02.580 --> 01:04.740 Teraz, gdy klient otrzyma to potwierdzenie, 01:04.740 --> 01:07.380 odeśle własne potwierdzenie do serwera. 01:07.380 --> 01:09.060 Jest to znane jako ack. 01:09.060 --> 01:11.940 Teraz, kiedy wykonujemy ten syn, syn ack, ack, to jest 01:11.940 --> 01:15.030 to, co nazywamy trójstronnym uściskiem dłoni. 01:15.030 --> 01:16.807 Zasadniczo klient mówi: "Hej serwerze, 01:16.807 --> 01:21.367 czy jesteś gotowy, aby uzyskać jakieś informacje? A wtedy serwer mówi: "Jasne. 01:21.367 --> 01:21.367 Dlaczego nie? 01:21.367 --> 01:22.920 "Wyślij mi jakieś informacje. A klient mówi: 01:22.920 --> 01:25.440 "Okej, nadchodzi. Następnie rozpocznie się transmisja, 01:25.440 --> 01:27.630 ponieważ ustaliliśmy trójstronny 01:27.630 --> 01:29.940 uścisk dłoni i wiemy, że obie strony 01:29.940 --> 01:32.737 są gotowe do komunikacji. 01:32.737 --> 01:35.107 "Gotowy? "Tak, jestem. 01:35.107 --> 01:35.107 "Nadchodzi. 01:35.107 --> 01:36.810 Za każdym razem, gdy te dane, 01:36.810 --> 01:39.150 które nazywamy segmentem, są wysyłane 01:39.150 --> 01:40.710 przez sieć, otrzymujemy 01:40.710 --> 01:43.080 potwierdzenie, które mówi nam, że nastąpiła 01:43.080 --> 01:46.980 udana dwukierunkowa komunikacja. 01:46.980 --> 01:48.600 Teraz, jeśli ten serwer spodziewa 01:48.600 --> 01:50.370 się otrzymać 100 informacji, 01:50.370 --> 01:53.587 ale otrzymał tylko 98 z nich, powie klientowi: "Hej, powiedziałeś 01:53.587 --> 01:56.347 mi, że wyślesz mi 100 rzeczy", ale wysłałeś mi tylko 01:56.347 --> 01:58.177 98. 01:58.177 --> 02:00.450 "Wyślij mi te dwie rzeczy, których mi brakuje. Następnie następuje 02:00.450 --> 02:02.730 retransmisja. 02:02.730 --> 02:03.563 W ten sposób komunikacja 02:03.563 --> 02:05.310 może przebiegać dla nas i zawsze możemy 02:05.310 --> 02:06.240 upewnić się, że otrzymujemy 02:06.240 --> 02:07.470 to, co powinniśmy, ponieważ 02:07.470 --> 02:09.450 mamy możliwość ponownego wysyłania pakietów 02:09.450 --> 02:10.920 przez sieć. 02:10.920 --> 02:13.170 Teraz jest to używane dla wszystkich danych sieciowych, 02:13.170 --> 02:16.830 które muszą być zapewnione, aby dotrzeć do miejsca docelowego. 02:16.830 --> 02:19.470 Lubię myśleć o tym jak o przesyłce poleconej. 02:19.470 --> 02:22.440 Jeśli na przykład chcę wysłać wiadomość do Urzędu Skarbowego, 02:22.440 --> 02:23.970 chcę mieć pewność, że ją otrzymają 02:23.970 --> 02:25.620 i nie zaginie ona w poczcie. 02:25.620 --> 02:27.630 Mogę więc zapłacić trochę więcej, aby uzyskać 02:27.630 --> 02:29.160 poświadczone pokwitowanie, które 02:29.160 --> 02:31.080 po dotarciu na miejsce musi zostać podpisane 02:31.080 --> 02:32.820 i odesłane do mnie pocztą. 02:32.820 --> 02:33.653 W ten sposób, gdy otrzymam 02:33.653 --> 02:34.740 pokwitowanie z powrotem, 02:34.740 --> 02:37.500 wiem, że IRS otrzymał moją paczkę pocztową. 02:37.500 --> 02:39.960 Tak właśnie działa TCP. 02:39.960 --> 02:41.220 Z drugiej strony 02:41.220 --> 02:44.250 mamy inny protokół znany jako UDP. 02:44.250 --> 02:47.250 UDP jest tak zwanym protokołem bezpołączeniowym, co 02:47.250 --> 02:49.770 oznacza, że nie musi czekać na połączenia. 02:49.770 --> 02:52.830 UDP to skrót od User Datagram Protocol. 02:52.830 --> 02:54.270 A powodem, dla którego nazywamy 02:54.270 --> 02:56.160 to datagramem, jest to, że jeśli używasz 02:56.160 --> 02:57.750 UDP, używasz tego typu danych. 02:57.750 --> 02:59.220 Nazywa się to datagramem. 02:59.220 --> 03:01.317 Teraz, gdy mówimy o UDP, UDP 03:01.317 --> 03:03.060 jest zawodny i przesyła 03:03.060 --> 03:05.490 segmenty zwane datagramami. 03:05.490 --> 03:06.510 A jeśli zostaną porzucone, 03:06.510 --> 03:09.000 nadawca nigdy się o tym nie dowie. 03:09.000 --> 03:10.830 Dlaczego miałbym wysyłać rzeczy, o 03:10.830 --> 03:12.300 których nadawca nie wie i nie 03:12.300 --> 03:14.220 otrzymuję żadnego potwierdzenia? 03:14.220 --> 03:17.850 Cóż, UDP jest naprawdę dobry do przesyłania strumieniowego audio i wizualnego, 03:17.850 --> 03:19.920 ponieważ wysyłasz dużo danych i jest o wiele 03:19.920 --> 03:22.620 mniej narzutu, gdy używasz UDP, ponieważ nie mamy tego 03:22.620 --> 03:25.950 ciągłego trójstronnego uzgadniania, aby go ustanowić i nie mamy 03:25.950 --> 03:27.840 wszystkich kontroli i równowagi, które 03:27.840 --> 03:30.840 są związane z używaniem TCP. 03:30.840 --> 03:32.520 Korzystając z protokołu UDP, 03:32.520 --> 03:35.190 można naprawdę zwiększyć wydajność sieci, ponieważ 03:35.190 --> 03:37.800 nie będzie żadnych retransmisji. 03:37.800 --> 03:39.870 Skończy się to po prostu porzuceniem informacji. 03:39.870 --> 03:41.490 Czy to nie jest zła rzecz? 03:41.490 --> 03:43.530 Dlaczego mielibyśmy porzucać informacje? 03:43.530 --> 03:45.300 W przypadku niektórych zastosowań 03:45.300 --> 03:46.740 nie ma to znaczenia. 03:46.740 --> 03:49.440 Na przykład, właśnie przesyłasz strumieniowo ten film. 03:49.440 --> 03:52.110 A gdybym wypadł na 1/100 sekundy, czy w ogóle 03:52.110 --> 03:53.520 byś to zauważył? 03:53.520 --> 03:54.960 Cóż, prawdopodobnie nie i 03:54.960 --> 03:56.820 właśnie dlatego UDP jest tak dobry, 03:56.820 --> 03:59.520 ponieważ możemy tutaj upuścić 1/100 czasu i tak naprawdę 03:59.520 --> 04:01.320 nigdy tego nie zauważysz i nie będzie 04:01.320 --> 04:03.120 retransmisji. 04:03.120 --> 04:04.740 Ale w przypadku TCP doprowadzi to do znacznie 04:04.740 --> 04:06.300 większego buforowania, ponieważ trzeba 04:06.300 --> 04:07.440 czekać, a następnie ponownie 04:07.440 --> 04:08.670 wysłać, a następnie umieścić 04:08.670 --> 04:09.810 we właściwym miejscu, a następnie 04:09.810 --> 04:11.250 odtworzyć. 04:11.250 --> 04:13.770 Tak więc, z powodu tego potwierdzenia i tego narzutu, 04:13.770 --> 04:15.870 każda sekunda tego filmu sprawi, że będzie 04:15.870 --> 04:17.880 on znacznie większy i zużyje znacznie 04:17.880 --> 04:19.830 więcej przepustowości. 04:19.830 --> 04:21.150 Jest to jeden z głównych powodów, 04:21.150 --> 04:24.660 dla których używamy protokołu UDP do strumieniowego przesyłania wideo i audio. 04:24.660 --> 04:28.740 Zróbmy teraz krótkie podsumowanie TCP kontra UDP. 04:28.740 --> 04:31.410 Ponieważ jest to naprawdę ważna koncepcja. 04:31.410 --> 04:33.600 W rzeczywistości, jeśli masz teraz swoje notatki, 04:33.600 --> 04:35.160 zapisałbym ten wykres, który zamierzam 04:35.160 --> 04:36.420 ci teraz powiedzieć, gdy 04:36.420 --> 04:38.520 mówimy o TCP kontra UDP. 04:38.520 --> 04:40.770 Bo to naprawdę jest takie ważne. 04:40.770 --> 04:43.380 Po pierwsze, TCP jest niezawodny, ma trójstronny 04:43.380 --> 04:44.820 handshake, podczas gdy 04:44.820 --> 04:47.040 UDP nie jest zbyt niezawodny. 04:47.040 --> 04:48.540 Jest to niewiarygodny protokół, 04:48.540 --> 04:51.180 ponieważ nie ma trójstronnego uzgadniania. 04:51.180 --> 04:53.490 TCP jest tym, co nazywamy protokołem zorientowanym 04:53.490 --> 04:55.560 na połączenie lub protokołem pełnym połączeń, 04:55.560 --> 04:56.880 ponieważ mamy ten trójstronny 04:56.880 --> 04:57.960 uścisk dłoni w potwierdzeniach, 04:57.960 --> 05:00.660 ale UDP jest bezpołączeniowy. 05:00.660 --> 05:02.550 To metoda "odpal i zapomnij". 05:02.550 --> 05:04.200 Po prostu zaczynam wysyłać informacje 05:04.200 --> 05:06.660 i mam nadzieję, że je otrzymasz. 05:06.660 --> 05:10.170 TCP wykorzystuje retransmisję segmentów i kontrolę przepływu, która jest 05:10.170 --> 05:12.030 obsługiwana przez okienkowanie. 05:12.030 --> 05:13.230 Z drugiej strony UDP 05:13.230 --> 05:16.230 nie ma retransmisji ani okienkowania. 05:16.230 --> 05:17.160 Dzięki TCP mamy segmentację 05:17.160 --> 05:19.140 sekwencjonowania wszystkich naszych 05:19.140 --> 05:20.820 różnych segmentów. 05:20.820 --> 05:23.370 W przypadku UDP nie ma sekwencjonowania. 05:23.370 --> 05:25.530 Oznacza to, że wysyłając wszystko, będę 05:25.530 --> 05:27.570 wysyłał je w odpowiedniej kolejności, 05:27.570 --> 05:28.710 od jednego do 100. 05:28.710 --> 05:31.260 Zrobię to zarówno dla TCP, jak i UDP. 05:31.260 --> 05:32.910 Teraz, jeśli przegapisz niektóre z tych 05:32.910 --> 05:34.350 elementów lub dotrą one w innej kolejności, 05:34.350 --> 05:36.480 ponieważ pokonują inną drogę przez sieć, dzięki 05:36.480 --> 05:38.520 TCP są one sekwencjonowane, więc wie, że masz od 05:38.520 --> 05:40.137 jednego do 1000 i umieszcza je z powrotem 05:40.137 --> 05:42.420 we właściwej kolejności. 05:42.420 --> 05:43.440 W przypadku UDP, bez względu 05:43.440 --> 05:44.850 na to, w jakiej formie przychodzą, 05:44.850 --> 05:46.650 tak właśnie będą transmitowane. 05:46.650 --> 05:48.030 I tak, może to być 05:48.030 --> 05:49.230 jeden, 50, dwa, 05:49.230 --> 05:50.910 500, trzy, cztery, pięć, 05:50.910 --> 05:55.230 sześć, 20, w dowolnej losowej kolejności. 05:55.230 --> 05:56.580 I tak właśnie to usłyszysz. 05:56.580 --> 05:59.010 Tak więc w przypadku wideo możesz usłyszeć trochę przeskoków, 05:59.010 --> 06:01.740 trochę wysokich pisków lub coś w tym rodzaju, ponieważ jedna 06:01.740 --> 06:04.320 z tych klatek mogła być nie w porządku. 06:04.320 --> 06:05.550 Teraz, gdy wrócimy do 06:05.550 --> 06:08.010 TCP, potwierdzi on każdy z tych segmentów. 06:08.010 --> 06:09.780 Mamy więc potwierdzenie. 06:09.780 --> 06:10.680 Jeśli go nie otrzymam, 06:10.680 --> 06:11.513 wiem, że go nie otrzymałem 06:11.513 --> 06:13.650 i mogę go ponownie przesłać, a następnie otrzymać 06:13.650 --> 06:15.000 go ponownie. 06:15.000 --> 06:17.190 W przypadku UDP nie ma potwierdzenia. 06:17.190 --> 06:20.220 Ponownie, UDP ma znacznie mniejszy narzut, ponieważ 06:20.220 --> 06:21.540 nie ma połączenia, nie ma 06:21.540 --> 06:23.790 okienkowania, nie ma retransmisji, nie 06:23.790 --> 06:26.610 ma sekwencjonowania i nie ma potwierdzenia. 06:26.610 --> 06:28.620 Teraz, jeśli musisz coś tam przesłać 06:28.620 --> 06:30.870 i chcesz mieć pewność, że dana osoba to otrzymała, 06:30.870 --> 06:34.590 naprawdę musisz użyć TCP jako wybranego protokołu. 06:34.590 --> 06:36.930 Dlatego właśnie zamierzamy używać TCP do takich 06:36.930 --> 06:39.510 rzeczy jak bankowość, strony internetowe, eCommerce 06:39.510 --> 06:40.770 i tym podobne. 06:40.770 --> 06:42.900 Ale jeśli mamy coś, co zawiera dużo danych, takich 06:42.900 --> 06:44.550 jak strumieniowanie audio lub wideo, UDP 06:44.550 --> 06:46.560 naprawdę dobrze sobie z tym radzi, ponieważ nie 06:46.560 --> 06:47.490 musimy pobierać każdego 06:47.490 --> 06:49.320 pojedynczego elementu tego pliku. 06:49.320 --> 06:50.880 Możemy pominąć trochę tu i 06:50.880 --> 06:52.510 tam, i to jest w porządku. 06:52.510 --> 06:54.570 -Teraz, jeśli chodzi o TCP i UDP, rozmawialiśmy 06:54.570 --> 06:56.820 o tym, że są to protokoły zorientowane 06:56.820 --> 07:00.510 na połączenia i protokoły bezpołączeniowe. 07:00.510 --> 07:02.190 Podam więc kilka przykładów protokołów, 07:02.190 --> 07:05.340 które używają TCP lub UDP, abyś mógł zrozumieć, dlaczego 07:05.340 --> 07:07.680 używamy każdego z nich. 07:07.680 --> 07:08.513 Najpierw przyjrzyjmy 07:08.513 --> 07:09.420 się protokołowi TCP i 07:09.420 --> 07:12.750 naszym protokołom zorientowanym na połączenia lub pełnym połączeń. 07:12.750 --> 07:17.520 Obejmuje to takie rzeczy jak SSH i HTTP lub HTTPS. 07:17.520 --> 07:20.940 Dlaczego mielibyśmy potrzebować połączenia zorientowanego w tych przypadkach? 07:20.940 --> 07:23.490 Cóż, w przypadku korzystania z czegoś takiego jak 07:23.490 --> 07:25.710 SSH, prowadzę dwukierunkową komunikację 07:25.710 --> 07:28.320 i kontroluję zdalny serwer lub zdalną stację roboczą 07:28.320 --> 07:30.390 i mogę to zrobić przez port 22. 07:30.390 --> 07:31.830 Chcę się upewnić, że robię to 07:31.830 --> 07:34.920 w sposób zorientowany na połączenia lub pełen połączeń. 07:34.920 --> 07:37.110 W ten sposób, gdy wyślę polecenie i powiem, 07:37.110 --> 07:38.190 zrestartuj serwer, 07:38.190 --> 07:40.080 wiem, że polecenie faktycznie tam dotarło 07:40.080 --> 07:42.060 i nastąpi restart serwera. 07:42.060 --> 07:44.820 Podobnie, gdy mamy do czynienia z HTTPS, chcemy mieć 07:44.820 --> 07:46.680 pewność, że mamy protokół typu connection-full 07:46.680 --> 07:50.040 lub connection-oriented wykorzystujący TCP. 07:50.040 --> 07:51.120 Powodem tego jest to, że 07:51.120 --> 07:52.440 chcemy mieć pewność, że to, 07:52.440 --> 07:54.690 co wysyłamy, jest tam faktycznie odbierane. 07:54.690 --> 07:56.790 Może to obejmować takie rzeczy, jak uwierzytelnianie, 07:56.790 --> 07:58.500 gdy próbujemy zalogować się do witryny internetowej 07:58.500 --> 08:00.090 przy użyciu naszej nazwy użytkownika i 08:00.090 --> 08:01.500 hasła, lub może to być informacja, 08:01.500 --> 08:03.030 którą otrzymujemy z powrotem z tej witryny, 08:03.030 --> 08:06.180 taka jak salda naszych kont i informacje bankowe. 08:06.180 --> 08:07.013 Z drugiej strony, jeśli 08:07.013 --> 08:08.970 używamy UDP jako naszego protokołu, mamy do 08:08.970 --> 08:11.400 czynienia z połączeniem bezpołączeniowym. 08:11.400 --> 08:12.390 Wspomniałem już, że używamy 08:12.390 --> 08:13.470 tego cały czas do takich rzeczy 08:13.470 --> 08:15.600 jak strumieniowanie audio i wideo. 08:15.600 --> 08:16.680 Ale oprócz tego używamy 08:16.680 --> 08:19.230 go również do takich rzeczy jak DHCP i Trivial 08:19.230 --> 08:23.130 File Transfer Protocol, znany jako TFTP. 08:23.130 --> 08:24.030 Jeśli pamiętasz, 08:24.030 --> 08:27.480 DHCP jest używany jako Dynamic Host Control Protocol 08:27.480 --> 08:30.660 i działa na portach 67 i 68. 08:30.660 --> 08:32.310 Teraz, po dołączeniu do sieci, urządzenie, 08:32.310 --> 08:33.690 jeśli jest skonfigurowane 08:33.690 --> 08:35.850 do dynamicznego przypisywania adresu IP, 08:35.850 --> 08:38.520 wyśle wiadomość rozgłoszeniową w tej sieci w poszukiwaniu 08:38.520 --> 08:40.650 serwera DHCP. 08:40.650 --> 08:43.860 I właśnie dlatego używamy go jako protokołu bezpołączeniowego. 08:43.860 --> 08:47.220 Jeśli informacja zostanie wysłana i nikt nie odpowie, 08:47.220 --> 08:49.530 klient po prostu wyśle ją ponownie w nadziei, 08:49.530 --> 08:51.510 że pojawi się ktoś inny. 08:51.510 --> 08:53.070 Tak właśnie działa DHCP. 08:53.070 --> 08:55.080 Pozwoli to na wysłanie wiadomości, a następnie 08:55.080 --> 08:57.090 będzie czekać na odpowiedź. 08:57.090 --> 08:58.170 Jeśli nie otrzyma odpowiedzi 08:58.170 --> 08:59.340 w określonym czasie, 08:59.340 --> 09:01.560 po prostu ponownie roześle swoją wiadomość 09:01.560 --> 09:04.590 i ponownie wyszuka nowy serwer DHCP. 09:04.590 --> 09:06.960 Podobnie, gdy mamy TFTP lub Trivial File 09:06.960 --> 09:09.060 Transfer Protocol, który działa 09:09.060 --> 09:11.250 na porcie 69, będzie działał w sposób 09:11.250 --> 09:13.380 bezpołączeniowy, wykorzystując 09:13.380 --> 09:15.690 UDP jako swój transport. 09:15.690 --> 09:16.680 Powodem tego jest to, 09:16.680 --> 09:20.250 że TFTP jest trywialnym protokołem transferu plików, a zatem nie 09:20.250 --> 09:22.740 musimy mieć pewności, że każdy pojedynczy pakiet 09:22.740 --> 09:24.960 został wysłany i odebrany z tymi potwierdzeniami, 09:24.960 --> 09:26.250 a to powoduje znacznie większy 09:26.250 --> 09:29.190 narzut, jeśli używamy TCP. 09:29.190 --> 09:30.600 Korzystając z protokołu UDP, 09:30.600 --> 09:32.430 możemy szybciej przesyłać pliki, gdy 09:32.430 --> 09:34.500 używamy czegoś takiego jak TFTP, zamiast używać 09:34.500 --> 09:38.163 protokołu wymagającego większej liczby połączeń, takiego jak FTP.