Jason: W tej lekcji
omówimy typy protokołów IP, w tym TCP,
UDP oraz koncepcje metod bezpołączeniowych
i zorientowanych na połączenia.
Czym jest TCP?
TCP to protokół kontroli transmisji.
Jest to protokół zorientowany na połączenia,
co oznacza, że jest to niezawodny
sposób na transport segmentów w naszej sieci.
Teraz, jeśli segment zostanie porzucony,
protokół będzie faktycznie prosił o potwierdzenie za
każdym razem.
A jeśli nie otrzyma tego potwierdzenia,
ponownie wyśle tę informację.
Dlatego nazywamy to protokołem pełnym połączenia, ponieważ
ma on dwukierunkowy typ informacji, w którym wysyłam
ci informacje i weryfikuję,
czy faktycznie je otrzymałeś, nasłuchując,
czy je otrzymałeś, a ty dajesz mi odpowiedź.
Spójrzmy teraz na ten mały
diagram na ekranie.
Zobaczysz, że po lewej stronie mam klienta,
a po prawej serwer.
Teraz klient wyśle do serwera tak
zwany pakiet synchronizacji.
Teraz, gdy serwer to
otrzyma, wyśle
klientowi potwierdzenie synchronizacji,
znane jako syn ack.
Teraz, gdy klient otrzyma to potwierdzenie,
odeśle własne potwierdzenie do serwera.
Jest to znane jako ack.
Teraz, kiedy wykonujemy ten syn, syn ack, ack, to jest
to, co nazywamy trójstronnym uściskiem dłoni.
Zasadniczo klient mówi: "Hej serwerze,
czy jesteś gotowy, aby uzyskać jakieś informacje? A wtedy serwer mówi: "Jasne.
Dlaczego nie?
"Wyślij mi jakieś informacje. A klient mówi:
"Okej, nadchodzi. Następnie rozpocznie się transmisja,
ponieważ ustaliliśmy trójstronny
uścisk dłoni i wiemy, że obie strony
są gotowe do komunikacji.
"Gotowy? "Tak, jestem.
"Nadchodzi.
Za każdym razem, gdy te dane,
które nazywamy segmentem, są wysyłane
przez sieć, otrzymujemy
potwierdzenie, które mówi nam, że nastąpiła
udana dwukierunkowa komunikacja.
Teraz, jeśli ten serwer spodziewa
się otrzymać 100 informacji,
ale otrzymał tylko 98 z nich, powie klientowi: "Hej, powiedziałeś
mi, że wyślesz mi 100 rzeczy", ale wysłałeś mi tylko
98.
"Wyślij mi te dwie rzeczy, których mi brakuje. Następnie następuje
retransmisja.
W ten sposób komunikacja
może przebiegać dla nas i zawsze możemy
upewnić się, że otrzymujemy
to, co powinniśmy, ponieważ
mamy możliwość ponownego wysyłania pakietów
przez sieć.
Teraz jest to używane dla wszystkich danych sieciowych,
które muszą być zapewnione, aby dotrzeć do miejsca docelowego.
Lubię myśleć o tym jak o przesyłce poleconej.
Jeśli na przykład chcę wysłać wiadomość do Urzędu Skarbowego,
chcę mieć pewność, że ją otrzymają
i nie zaginie ona w poczcie.
Mogę więc zapłacić trochę więcej, aby uzyskać
poświadczone pokwitowanie, które
po dotarciu na miejsce musi zostać podpisane
i odesłane do mnie pocztą.
W ten sposób, gdy otrzymam
pokwitowanie z powrotem,
wiem, że IRS otrzymał moją paczkę pocztową.
Tak właśnie działa TCP.
Z drugiej strony
mamy inny protokół znany jako UDP.
UDP jest tak zwanym protokołem bezpołączeniowym, co
oznacza, że nie musi czekać na połączenia.
UDP to skrót od User Datagram Protocol.
A powodem, dla którego nazywamy
to datagramem, jest to, że jeśli używasz
UDP, używasz tego typu danych.
Nazywa się to datagramem.
Teraz, gdy mówimy o UDP, UDP
jest zawodny i przesyła
segmenty zwane datagramami.
A jeśli zostaną porzucone,
nadawca nigdy się o tym nie dowie.
Dlaczego miałbym wysyłać rzeczy, o
których nadawca nie wie i nie
otrzymuję żadnego potwierdzenia?
Cóż, UDP jest naprawdę dobry do przesyłania strumieniowego audio i wizualnego,
ponieważ wysyłasz dużo danych i jest o wiele
mniej narzutu, gdy używasz UDP, ponieważ nie mamy tego
ciągłego trójstronnego uzgadniania, aby go ustanowić i nie mamy
wszystkich kontroli i równowagi, które
są związane z używaniem TCP.
Korzystając z protokołu UDP,
można naprawdę zwiększyć wydajność sieci, ponieważ
nie będzie żadnych retransmisji.
Skończy się to po prostu porzuceniem informacji.
Czy to nie jest zła rzecz?
Dlaczego mielibyśmy porzucać informacje?
W przypadku niektórych zastosowań
nie ma to znaczenia.
Na przykład, właśnie przesyłasz strumieniowo ten film.
A gdybym wypadł na 1/100 sekundy, czy w ogóle
byś to zauważył?
Cóż, prawdopodobnie nie i
właśnie dlatego UDP jest tak dobry,
ponieważ możemy tutaj upuścić 1/100 czasu i tak naprawdę
nigdy tego nie zauważysz i nie będzie
retransmisji.
Ale w przypadku TCP doprowadzi to do znacznie
większego buforowania, ponieważ trzeba
czekać, a następnie ponownie
wysłać, a następnie umieścić
we właściwym miejscu, a następnie
odtworzyć.
Tak więc, z powodu tego potwierdzenia i tego narzutu,
każda sekunda tego filmu sprawi, że będzie
on znacznie większy i zużyje znacznie
więcej przepustowości.
Jest to jeden z głównych powodów,
dla których używamy protokołu UDP do strumieniowego przesyłania wideo i audio.
Zróbmy teraz krótkie podsumowanie TCP kontra UDP.
Ponieważ jest to naprawdę ważna koncepcja.
W rzeczywistości, jeśli masz teraz swoje notatki,
zapisałbym ten wykres, który zamierzam
ci teraz powiedzieć, gdy
mówimy o TCP kontra UDP.
Bo to naprawdę jest takie ważne.
Po pierwsze, TCP jest niezawodny, ma trójstronny
handshake, podczas gdy
UDP nie jest zbyt niezawodny.
Jest to niewiarygodny protokół,
ponieważ nie ma trójstronnego uzgadniania.
TCP jest tym, co nazywamy protokołem zorientowanym
na połączenie lub protokołem pełnym połączeń,
ponieważ mamy ten trójstronny
uścisk dłoni w potwierdzeniach,
ale UDP jest bezpołączeniowy.
To metoda "odpal i zapomnij".
Po prostu zaczynam wysyłać informacje
i mam nadzieję, że je otrzymasz.
TCP wykorzystuje retransmisję segmentów i kontrolę przepływu, która jest
obsługiwana przez okienkowanie.
Z drugiej strony UDP
nie ma retransmisji ani okienkowania.
Dzięki TCP mamy segmentację
sekwencjonowania wszystkich naszych
różnych segmentów.
W przypadku UDP nie ma sekwencjonowania.
Oznacza to, że wysyłając wszystko, będę
wysyłał je w odpowiedniej kolejności,
od jednego do 100.
Zrobię to zarówno dla TCP, jak i UDP.
Teraz, jeśli przegapisz niektóre z tych
elementów lub dotrą one w innej kolejności,
ponieważ pokonują inną drogę przez sieć, dzięki
TCP są one sekwencjonowane, więc wie, że masz od
jednego do 1000 i umieszcza je z powrotem
we właściwej kolejności.
W przypadku UDP, bez względu
na to, w jakiej formie przychodzą,
tak właśnie będą transmitowane.
I tak, może to być
jeden, 50, dwa,
500, trzy, cztery, pięć,
sześć, 20, w dowolnej losowej kolejności.
I tak właśnie to usłyszysz.
Tak więc w przypadku wideo możesz usłyszeć trochę przeskoków,
trochę wysokich pisków lub coś w tym rodzaju, ponieważ jedna
z tych klatek mogła być nie w porządku.
Teraz, gdy wrócimy do
TCP, potwierdzi on każdy z tych segmentów.
Mamy więc potwierdzenie.
Jeśli go nie otrzymam,
wiem, że go nie otrzymałem
i mogę go ponownie przesłać, a następnie otrzymać
go ponownie.
W przypadku UDP nie ma potwierdzenia.
Ponownie, UDP ma znacznie mniejszy narzut, ponieważ
nie ma połączenia, nie ma
okienkowania, nie ma retransmisji, nie
ma sekwencjonowania i nie ma potwierdzenia.
Teraz, jeśli musisz coś tam przesłać
i chcesz mieć pewność, że dana osoba to otrzymała,
naprawdę musisz użyć TCP jako wybranego protokołu.
Dlatego właśnie zamierzamy używać TCP do takich
rzeczy jak bankowość, strony internetowe, eCommerce
i tym podobne.
Ale jeśli mamy coś, co zawiera dużo danych, takich
jak strumieniowanie audio lub wideo, UDP
naprawdę dobrze sobie z tym radzi, ponieważ nie
musimy pobierać każdego
pojedynczego elementu tego pliku.
Możemy pominąć trochę tu i
tam, i to jest w porządku.
-Teraz, jeśli chodzi o TCP i UDP, rozmawialiśmy
o tym, że są to protokoły zorientowane
na połączenia i protokoły bezpołączeniowe.
Podam więc kilka przykładów protokołów,
które używają TCP lub UDP, abyś mógł zrozumieć, dlaczego
używamy każdego z nich.
Najpierw przyjrzyjmy
się protokołowi TCP i
naszym protokołom zorientowanym na połączenia lub pełnym połączeń.
Obejmuje to takie rzeczy jak SSH i HTTP lub HTTPS.
Dlaczego mielibyśmy potrzebować połączenia zorientowanego w tych przypadkach?
Cóż, w przypadku korzystania z czegoś takiego jak
SSH, prowadzę dwukierunkową komunikację
i kontroluję zdalny serwer lub zdalną stację roboczą
i mogę to zrobić przez port 22.
Chcę się upewnić, że robię to
w sposób zorientowany na połączenia lub pełen połączeń.
W ten sposób, gdy wyślę polecenie i powiem,
zrestartuj serwer,
wiem, że polecenie faktycznie tam dotarło
i nastąpi restart serwera.
Podobnie, gdy mamy do czynienia z HTTPS, chcemy mieć
pewność, że mamy protokół typu connection-full
lub connection-oriented wykorzystujący TCP.
Powodem tego jest to, że
chcemy mieć pewność, że to,
co wysyłamy, jest tam faktycznie odbierane.
Może to obejmować takie rzeczy, jak uwierzytelnianie,
gdy próbujemy zalogować się do witryny internetowej
przy użyciu naszej nazwy użytkownika i
hasła, lub może to być informacja,
którą otrzymujemy z powrotem z tej witryny,
taka jak salda naszych kont i informacje bankowe.
Z drugiej strony, jeśli
używamy UDP jako naszego protokołu, mamy do
czynienia z połączeniem bezpołączeniowym.
Wspomniałem już, że używamy
tego cały czas do takich rzeczy
jak strumieniowanie audio i wideo.
Ale oprócz tego używamy
go również do takich rzeczy jak DHCP i Trivial
File Transfer Protocol, znany jako TFTP.
Jeśli pamiętasz,
DHCP jest używany jako Dynamic Host Control Protocol
i działa na portach 67 i 68.
Teraz, po dołączeniu do sieci, urządzenie,
jeśli jest skonfigurowane
do dynamicznego przypisywania adresu IP,
wyśle wiadomość rozgłoszeniową w tej sieci w poszukiwaniu
serwera DHCP.
I właśnie dlatego używamy go jako protokołu bezpołączeniowego.
Jeśli informacja zostanie wysłana i nikt nie odpowie,
klient po prostu wyśle ją ponownie w nadziei,
że pojawi się ktoś inny.
Tak właśnie działa DHCP.
Pozwoli to na wysłanie wiadomości, a następnie
będzie czekać na odpowiedź.
Jeśli nie otrzyma odpowiedzi
w określonym czasie,
po prostu ponownie roześle swoją wiadomość
i ponownie wyszuka nowy serwer DHCP.
Podobnie, gdy mamy TFTP lub Trivial File
Transfer Protocol, który działa
na porcie 69, będzie działał w sposób
bezpołączeniowy, wykorzystując
UDP jako swój transport.
Powodem tego jest to,
że TFTP jest trywialnym protokołem transferu plików, a zatem nie
musimy mieć pewności, że każdy pojedynczy pakiet
został wysłany i odebrany z tymi potwierdzeniami,
a to powoduje znacznie większy
narzut, jeśli używamy TCP.
Korzystając z protokołu UDP,
możemy szybciej przesyłać pliki, gdy
używamy czegoś takiego jak TFTP, zamiast używać
protokołu wymagającego większej liczby połączeń, takiego jak FTP.