WEBVTT

00:00.090 --> 00:01.020
Jason: In questa

00:01.020 --> 00:03.480
lezione parleremo dei tipi di protocollo

00:03.480 --> 00:05.637
IP, compresi TCP e UDP, e dei concetti

00:05.637 --> 00:07.650
di metodi senza connessione e metodi

00:07.650 --> 00:10.020
orientati alla connessione.

00:10.020 --> 00:12.300
Che cos'è il TCP?

00:12.300 --> 00:15.270
TCP è un protocollo di controllo della trasmissione.

00:15.270 --> 00:17.340
È un protocollo orientato alla connessione,

00:17.340 --> 00:18.990
il che significa che è un modo affidabile

00:18.990 --> 00:22.080
per trasportare segmenti attraverso la nostra rete.

00:22.080 --> 00:23.580
Ora, se un segmento viene abbandonato,

00:23.580 --> 00:26.603
il protocollo chiederà ogni volta un riconoscimento.

00:26.603 --> 00:28.890
E se non riceve il riconoscimento,

00:28.890 --> 00:31.530
invierà nuovamente l'informazione.

00:31.530 --> 00:34.410
Questo è il motivo per cui lo chiamiamo protocollo a connessione completa,

00:34.410 --> 00:36.960
perché ha un tipo di informazione bidirezionale in cui io ti invio

00:36.960 --> 00:38.280
un'informazione e verifico che

00:38.280 --> 00:40.200
tu l'abbia effettivamente ricevuta, ascoltando

00:40.200 --> 00:43.170
che tu l'abbia ricevuta e che tu mi dia una risposta.

00:43.170 --> 00:44.640
Ora guardiamo un attimo questo piccolo

00:44.640 --> 00:46.230
diagramma qui sullo schermo.

00:46.230 --> 00:48.210
Vedrete che ho un client a sinistra

00:48.210 --> 00:49.800
e un server a destra.

00:49.800 --> 00:52.860
Ora, il client invierà al server il cosiddetto pacchetto

00:52.860 --> 00:55.950
syn, o pacchetto di sincronizzazione.

00:55.950 --> 00:57.240
Quando il server lo

00:57.240 --> 00:58.170
riceve, invia

00:58.170 --> 01:00.720
al client una conferma di sincronizzazione,

01:00.720 --> 01:02.580
nota come syn ack.

01:02.580 --> 01:04.740
Ora, quando il client riceve la conferma di

01:04.740 --> 01:07.380
ricezione, invia la propria conferma al server.

01:07.380 --> 01:09.060
Questo è noto come ack.

01:09.060 --> 01:11.940
Ora, quando facciamo questo syn, syn ack, ack, questo

01:11.940 --> 01:15.030
è ciò che viene definito come un handshake a tre vie.

01:15.030 --> 01:16.807
In sostanza, il client dice: "Ehi

01:16.807 --> 01:21.367
server, sei pronto a ricevere informazioni? E poi il server dice: "Certo.

01:21.367 --> 01:21.367
Perché no?

01:21.367 --> 01:22.920
"Inviatemi delle informazioni. E il cliente dice:

01:22.920 --> 01:25.440
"Ok, ecco che arriva". E poi la trasmissione inizierà perché

01:25.440 --> 01:27.630
abbiamo stabilito la stretta di

01:27.630 --> 01:29.940
mano a tre e sappiamo che entrambe

01:29.940 --> 01:32.737
le parti sono pronte a comunicare.

01:32.737 --> 01:33.937
"Ora, siete pronti? "Sì, lo

01:33.937 --> 01:35.107
sono. "Ecco che

01:35.107 --> 01:36.810
arriva. Ora, ogni volta che questi dati,

01:36.810 --> 01:39.150
che chiamiamo segmento, vengono inviati

01:39.150 --> 01:40.710
attraverso la rete, ci sarà

01:40.710 --> 01:43.080
una conferma di ricezione che ci dirà che

01:43.080 --> 01:45.030
la comunicazione bidirezionale

01:45.030 --> 01:46.980
è avvenuta con successo.

01:46.980 --> 01:48.600
Ora, se il server si aspettava

01:48.600 --> 01:50.370
di ricevere 100 informazioni,

01:50.370 --> 01:52.500
ma ne ha ricevute solo 98, dirà al client:

01:52.500 --> 01:53.587
"Ehi, mi avevi detto

01:53.587 --> 01:56.347
che mi avresti inviato 100 cose, ma me ne hai inviate

01:56.347 --> 01:58.177
solo 98".

01:58.177 --> 02:00.450
"Mandami le due cose che mi mancano. E poi, si verifica una

02:00.450 --> 02:02.730
ritrasmissione.

02:02.730 --> 02:03.563
In questo modo, la comunicazione

02:03.563 --> 02:05.310
può andare a buon fine e possiamo sempre

02:05.310 --> 02:06.240
assicurarci di ricevere

02:06.240 --> 02:07.470
ciò che ci spetta, perché abbiamo

02:07.470 --> 02:09.450
questo reinvio dei pacchetti attraverso la

02:09.450 --> 02:10.920
rete.

02:10.920 --> 02:13.170
Ora, questo viene utilizzato per tutti i dati di rete

02:13.170 --> 02:16.830
che devono essere assicurati per arrivare alla loro destinazione finale.

02:16.830 --> 02:19.470
Mi piace pensare a questo come alla posta certificata.

02:19.470 --> 02:22.440
Se voglio inviare un messaggio all'Agenzia delle Entrate, ad esempio,

02:22.440 --> 02:23.970
voglio essere sicuro che lo riceva

02:23.970 --> 02:25.620
e che non si perda nella posta.

02:25.620 --> 02:27.630
Quindi potrei pagare un po' di più per ottenere

02:27.630 --> 02:29.160
una ricevuta certificata che, quando

02:29.160 --> 02:31.080
arriva, deve essere firmata da loro e che mi

02:31.080 --> 02:32.820
viene rispedita per posta.

02:32.820 --> 02:33.653
In questo modo, quando

02:33.653 --> 02:34.740
ricevo la ricevuta, so

02:34.740 --> 02:37.500
che il fisco ha ricevuto il mio pacco postale.

02:37.500 --> 02:39.960
Il TCP funziona così.

02:39.960 --> 02:41.220
D'altra parte, abbiamo

02:41.220 --> 02:44.250
un altro protocollo noto come UDP.

02:44.250 --> 02:47.250
UDP è quello che si definisce un protocollo senza connessioni,

02:47.250 --> 02:49.770
cioè non deve aspettare le connessioni.

02:49.770 --> 02:52.830
UDP è l'acronimo di User Datagram Protocol.

02:52.830 --> 02:54.270
Il motivo per cui lo chiamiamo

02:54.270 --> 02:56.160
datagramma è che se si usa UDP, si usa

02:56.160 --> 02:57.750
questo tipo di dati.

02:57.750 --> 02:59.220
Si chiama datagramma.

02:59.220 --> 03:01.317
Ora, quando parliamo di UDP, UDP

03:01.317 --> 03:03.060
è inaffidabile e trasmette

03:03.060 --> 03:05.490
segmenti chiamati datagrammi.

03:05.490 --> 03:06.510
E se vengono abbandonati,

03:06.510 --> 03:09.000
il mittente non saprà mai che è successo.

03:09.000 --> 03:10.830
Ora, perché dovrei voler inviare cose di

03:10.830 --> 03:12.300
cui il mittente non è a conoscenza

03:12.300 --> 03:14.220
e non ricevo alcun tipo di ricevuta?

03:14.220 --> 03:17.850
L'UDP è davvero ottimo per lo streaming audio e visivo, perché

03:17.850 --> 03:19.920
si inviano molti dati e l'overhead

03:19.920 --> 03:22.620
è molto minore quando si usa l'UDP, perché non

03:22.620 --> 03:24.810
c'è il costante handshake a tre vie per

03:24.810 --> 03:25.950
stabilirlo e non ci

03:25.950 --> 03:27.840
sono tutti i controlli e gli equilibri

03:27.840 --> 03:30.840
associati all'uso del TCP.

03:30.840 --> 03:32.520
Utilizzando UDP, è possibile

03:32.520 --> 03:35.190
aumentare le prestazioni della rete, perché

03:35.190 --> 03:37.800
le ritrasmissioni sono nulle.

03:37.800 --> 03:39.870
Si finisce solo per perdere informazioni.

03:39.870 --> 03:41.490
Non è una cosa negativa?

03:41.490 --> 03:43.530
Perché dovremmo voler abbandonare le informazioni?

03:43.530 --> 03:45.300
Per alcune applicazioni non

03:45.300 --> 03:46.740
ha molta importanza.

03:46.740 --> 03:49.440
Ad esempio, in questo momento state trasmettendo questo video.

03:49.440 --> 03:52.110
E se mi ritirassi per 1/100 di secondo, ve

03:52.110 --> 03:53.520
ne accorgereste?

03:53.520 --> 03:54.960
Probabilmente non lo fareste,

03:54.960 --> 03:56.820
ed è per questo che UDP è così buono,

03:56.820 --> 03:59.520
perché possiamo perdere 1/100 del tempo e non ve ne

03:59.520 --> 04:01.320
accorgerete nemmeno, e non ci sarà

04:01.320 --> 04:03.120
una ritrasmissione.

04:03.120 --> 04:04.740
Con il TCP, invece, il buffering

04:04.740 --> 04:06.300
sarà molto più lungo, perché dovrete

04:06.300 --> 04:07.440
aspettare e poi farvi rispedire

04:07.440 --> 04:11.250
il file, metterlo nel posto giusto e poi riprodurlo.

04:11.250 --> 04:13.770
Quindi, a causa di questo riconoscimento e di questo overhead,

04:13.770 --> 04:15.870
per ogni singolo secondo di questo video, finirà

04:15.870 --> 04:17.880
per diventare molto più grande e utilizzerà

04:17.880 --> 04:19.830
molta più larghezza di banda.

04:19.830 --> 04:21.150
Questo è uno dei motivi principali

04:21.150 --> 04:24.660
per cui usiamo UDP per lo streaming video e audio.

04:24.660 --> 04:28.740
Ora, facciamo un breve riepilogo di TCP e UDP.

04:28.740 --> 04:31.410
Perché questo è un concetto davvero, davvero importante.

04:31.410 --> 04:33.600
In effetti, se avete i vostri appunti,

04:33.600 --> 04:35.160
vi segnerei questo grafico

04:35.160 --> 04:36.420
che vi illustrerò ora,

04:36.420 --> 04:38.520
mentre parliamo di TCP e UDP.

04:38.520 --> 04:40.770
Perché è davvero così importante.

04:40.770 --> 04:43.380
Innanzitutto, il TCP è affidabile, ha un handshake

04:43.380 --> 04:44.820
a tre vie, mentre l'UDP

04:44.820 --> 04:47.040
non è molto affidabile.

04:47.040 --> 04:48.540
È un protocollo inaffidabile

04:48.540 --> 04:51.180
perché non esiste un handshake a tre vie.

04:51.180 --> 04:53.490
Il TCP è quello che chiamiamo "connection-oriented"

04:53.490 --> 04:55.560
o "connection-full", in quanto prevede

04:55.560 --> 04:56.880
l'handshake a tre vie negli

04:56.880 --> 04:57.960
acknowledgements,

04:57.960 --> 05:00.660
mentre l'UDP è "connectionless".

05:00.660 --> 05:02.550
È un metodo "spara e dimentica".

05:02.550 --> 05:04.200
Io comincio a inviare informazioni

05:04.200 --> 05:06.660
e spero che le riceviate.

05:06.660 --> 05:10.170
Il protocollo TCP utilizza la ritrasmissione dei segmenti e il controllo del flusso

05:10.170 --> 05:12.030
che viene gestito attraverso il windowing.

05:12.030 --> 05:13.230
In UDP, invece,

05:13.230 --> 05:16.230
non c'è ritrasmissione né windowing.

05:16.230 --> 05:17.160
Con il TCP, abbiamo una

05:17.160 --> 05:19.140
segmentazione del nostro sequenziamento di

05:19.140 --> 05:20.820
tutti i nostri diversi segmenti.

05:20.820 --> 05:23.370
Con UDP, non c'è sequenziamento.

05:23.370 --> 05:25.530
Ciò significa che quando spedisco tutto,

05:25.530 --> 05:27.570
lo spedisco nell'ordine corretto,

05:27.570 --> 05:28.710
da uno a cento.

05:28.710 --> 05:31.260
Lo farò sia per TCP che per UDP.

05:31.260 --> 05:32.910
Ora, se si perdono alcuni di questi

05:32.910 --> 05:34.350
pezzi, o se arrivano in un ordine

05:34.350 --> 05:36.480
diverso perché percorrono un percorso diverso

05:36.480 --> 05:37.500
sulla rete, con il TCP

05:37.500 --> 05:38.520
sono in sequenza, quindi

05:38.520 --> 05:40.137
sa che ne avete uno a 1000 e li rimette

05:40.137 --> 05:42.420
nella giusta sequenza.

05:42.420 --> 05:43.440
Con UDP, qualunque

05:43.440 --> 05:44.850
sia il nome con cui arrivano,

05:44.850 --> 05:46.650
è quello che trasmetterà.

05:46.650 --> 05:48.030
Quindi, può essere

05:48.030 --> 05:49.230
uno, 50, due, 500,

05:49.230 --> 05:50.910
tre, quattro, cinque,

05:50.910 --> 05:55.230
sei, 20, in qualsiasi ordine casuale.

05:55.230 --> 05:56.580
Ed è così che lo sentirete.

05:56.580 --> 05:59.010
Nel caso dei video, quindi, è possibile che si senta un po' di saltellamento,

05:59.010 --> 06:00.780
o un po' di cigolii acuti, o qualcosa del genere,

06:00.780 --> 06:01.740
perché uno di quei fotogrammi

06:01.740 --> 06:04.320
potrebbe essere uscito dall'ordine.

06:04.320 --> 06:05.550
Ora, quando torniamo al TCP,

06:05.550 --> 06:08.010
esso riconoscerà ciascuno di questi segmenti.

06:08.010 --> 06:09.780
E così abbiamo un riconoscimento.

06:09.780 --> 06:10.680
Se non la ricevo,

06:10.680 --> 06:11.513
so che non l'ho ricevuta

06:11.513 --> 06:13.650
e posso farmela ritrasmettere e poi riceverla

06:13.650 --> 06:15.000
di nuovo.

06:15.000 --> 06:17.190
Con UDP, non c'è riconoscimento.

06:17.190 --> 06:20.220
Quindi, ancora una volta, UDP ha un overhead molto minore perché

06:20.220 --> 06:21.540
non c'è connessione, non c'è

06:21.540 --> 06:23.790
windowing, non c'è ritrasmissione, non c'è

06:23.790 --> 06:26.610
sequenziamento e non c'è riconoscimento.

06:26.610 --> 06:28.620
Ora, se si deve far arrivare qualcosa

06:28.620 --> 06:30.870
e si vuole essere sicuri che la persona lo riceva,

06:30.870 --> 06:34.590
si deve usare il protocollo TCP come protocollo di scelta.

06:34.590 --> 06:36.930
Ed è per questo che utilizzeremo il TCP per

06:36.930 --> 06:39.510
cose come le banche, i siti web, l'eCommerce

06:39.510 --> 06:40.770
e cose del genere.

06:40.770 --> 06:42.900
Ma se abbiamo qualcosa che contiene molti dati,

06:42.900 --> 06:44.550
come lo streaming audio o video, l'UDP

06:44.550 --> 06:46.560
si comporta davvero bene, perché non abbiamo

06:46.560 --> 06:47.490
bisogno di ricevere

06:47.490 --> 06:49.320
ogni singolo pezzo del file.

06:49.320 --> 06:50.880
Possiamo saltare un po'

06:50.880 --> 06:52.510
qua e là, e va bene così.

06:52.510 --> 06:54.570
-Ora, quando si parla di TCP e UDP, abbiamo

06:54.570 --> 06:56.820
parlato del fatto che si tratta di protocolli

06:56.820 --> 06:58.560
orientati alla connessione e di protocolli

06:58.560 --> 07:00.510
senza connessione.

07:00.510 --> 07:02.190
Vi fornisco quindi un paio di esempi

07:02.190 --> 07:05.340
di protocolli che utilizzano TCP o UDP, in modo che possiate

07:05.340 --> 07:07.680
capire perché usiamo ciascuno di essi.

07:07.680 --> 07:08.513
Per prima cosa, analizziamo

07:08.513 --> 07:09.420
il TCP e i nostri protocolli

07:09.420 --> 07:12.750
orientati alla connessione o a connessione piena.

07:12.750 --> 07:17.520
Questo include cose come SSH e HTTP o HTTPS.

07:17.520 --> 07:20.940
Ora, perché avremmo bisogno di un orientamento alla connessione in questi casi?

07:20.940 --> 07:23.490
Nel caso in cui si utilizzi qualcosa come SSH, si tratta

07:23.490 --> 07:25.710
di una comunicazione bidirezionale e del controllo

07:25.710 --> 07:28.320
di un server remoto o di una workstation remota, e di essere

07:28.320 --> 07:30.390
in grado di farlo sulla porta 22.

07:30.390 --> 07:31.830
Voglio essere sicuro di

07:31.830 --> 07:34.920
farlo in modo orientato o pieno di connessioni.

07:34.920 --> 07:37.110
In questo modo, quando invio un comando e dico: riavvia

07:37.110 --> 07:38.190
il server, so che il comando

07:38.190 --> 07:40.080
è arrivato effettivamente a destinazione

07:40.080 --> 07:42.060
e il riavvio del server avverrà.

07:42.060 --> 07:44.820
Allo stesso modo, quando abbiamo a che fare con HTTPS, vogliamo

07:44.820 --> 07:46.680
assicurarci di avere un protocollo pieno

07:46.680 --> 07:50.040
di connessioni o orientato alle connessioni che utilizza TCP.

07:50.040 --> 07:51.120
Il motivo è che, anche in questo

07:51.120 --> 07:52.440
caso, vogliamo assicurarci che

07:52.440 --> 07:54.690
ciò che inviamo venga effettivamente ricevuto.

07:54.690 --> 07:56.790
E questo può includere cose come l'autenticazione

07:56.790 --> 07:58.500
quando cerchiamo di accedere a un sito web

07:58.500 --> 08:00.090
usando il nostro nome utente e la nostra

08:00.090 --> 08:01.500
password, o forse le informazioni

08:01.500 --> 08:03.030
che riceviamo da quel sito web, come

08:03.030 --> 08:06.180
i saldi dei nostri conti e le nostre informazioni bancarie.

08:06.180 --> 08:07.013
D'altra parte, se

08:07.013 --> 08:08.970
usiamo UDP come protocollo, abbiamo a

08:08.970 --> 08:11.400
che fare con una modalità senza connessioni.

08:11.400 --> 08:12.390
Ho già accennato al fatto

08:12.390 --> 08:13.470
che lo usiamo sempre per

08:13.470 --> 08:15.600
cose come lo streaming audio e video.

08:15.600 --> 08:16.680
Ma oltre a questo,

08:16.680 --> 08:19.230
lo usiamo anche per cose come DHCP e il

08:19.230 --> 08:23.130
Trivial File Transfer Protocol, noto come TFTP.

08:23.130 --> 08:24.030
Ora, se ricordate,

08:24.030 --> 08:27.480
il DHCP è utilizzato come Dynamic Host Control

08:27.480 --> 08:30.660
Protocol e opera sulle porte 67 e 68.

08:30.660 --> 08:32.310
Quando ci si unisce a una rete, il

08:32.310 --> 08:33.690
dispositivo, se è impostato

08:33.690 --> 08:35.850
per l'assegnazione dinamica dell'indirizzo

08:35.850 --> 08:38.520
IP, invia un messaggio di broadcasting su quella rete

08:38.520 --> 08:40.650
alla ricerca di un server DHCP.

08:40.650 --> 08:43.860
Ecco perché lo usiamo come protocollo senza connessione.

08:43.860 --> 08:47.220
Perché se le informazioni vengono inviate e nessuno risponde, il cliente

08:47.220 --> 08:49.530
non farà altro che inviarle di nuovo nella speranza

08:49.530 --> 08:51.510
che ci sia qualcun altro.

08:51.510 --> 08:53.070
È così che funziona il DHCP.

08:53.070 --> 08:55.080
Consentirà l'invio di un messaggio di trasmissione

08:55.080 --> 08:57.090
e attenderà la risposta.

08:57.090 --> 08:58.170
Se non riceve una risposta

08:58.170 --> 08:59.340
entro un certo lasso di

08:59.340 --> 09:01.560
tempo, il messaggio viene semplicemente ritrasmesso,

09:01.560 --> 09:04.590
cercando di nuovo un nuovo server DHCP.

09:04.590 --> 09:06.960
Allo stesso modo, il protocollo TFTP

09:06.960 --> 09:09.060
o Trivial File Transfer Protocol,

09:09.060 --> 09:11.250
che opera sulla porta 69, funzionerà

09:11.250 --> 09:13.380
in modo privo di connessioni utilizzando

09:13.380 --> 09:15.690
UDP come trasporto.

09:15.690 --> 09:16.680
Il motivo è che TFTP

09:16.680 --> 09:20.250
è il Trivial File Transfer Protocol e quindi non è necessario

09:20.250 --> 09:22.740
avere la certezza che ogni singolo pacchetto

09:22.740 --> 09:24.960
sia stato inviato e ricevuto con le relative

09:24.960 --> 09:26.250
conferme, il che crea

09:26.250 --> 09:29.190
molto più overhead se si usa TCP.

09:29.190 --> 09:30.600
Quindi, usando UDP, possiamo

09:30.600 --> 09:32.430
avere un trasferimento di file più veloce

09:32.430 --> 09:34.500
quando usiamo qualcosa come TFTP, invece

09:34.500 --> 09:38.163
di usare un protocollo più pieno di connessioni, come FTP.