Jason: In questa
lezione parleremo dei tipi di protocollo
IP, compresi TCP e UDP, e dei concetti
di metodi senza connessione e metodi
orientati alla connessione.
Che cos'è il TCP?
TCP è un protocollo di controllo della trasmissione.
È un protocollo orientato alla connessione,
il che significa che è un modo affidabile
per trasportare segmenti attraverso la nostra rete.
Ora, se un segmento viene abbandonato,
il protocollo chiederà ogni volta un riconoscimento.
E se non riceve il riconoscimento,
invierà nuovamente l'informazione.
Questo è il motivo per cui lo chiamiamo protocollo a connessione completa,
perché ha un tipo di informazione bidirezionale in cui io ti invio
un'informazione e verifico che
tu l'abbia effettivamente ricevuta, ascoltando
che tu l'abbia ricevuta e che tu mi dia una risposta.
Ora guardiamo un attimo questo piccolo
diagramma qui sullo schermo.
Vedrete che ho un client a sinistra
e un server a destra.
Ora, il client invierà al server il cosiddetto pacchetto
syn, o pacchetto di sincronizzazione.
Quando il server lo
riceve, invia
al client una conferma di sincronizzazione,
nota come syn ack.
Ora, quando il client riceve la conferma di
ricezione, invia la propria conferma al server.
Questo è noto come ack.
Ora, quando facciamo questo syn, syn ack, ack, questo
è ciò che viene definito come un handshake a tre vie.
In sostanza, il client dice: "Ehi
server, sei pronto a ricevere informazioni? E poi il server dice: "Certo.
Perché no?
"Inviatemi delle informazioni. E il cliente dice:
"Ok, ecco che arriva". E poi la trasmissione inizierà perché
abbiamo stabilito la stretta di
mano a tre e sappiamo che entrambe
le parti sono pronte a comunicare.
"Ora, siete pronti? "Sì, lo
sono. "Ecco che
arriva. Ora, ogni volta che questi dati,
che chiamiamo segmento, vengono inviati
attraverso la rete, ci sarà
una conferma di ricezione che ci dirà che
la comunicazione bidirezionale
è avvenuta con successo.
Ora, se il server si aspettava
di ricevere 100 informazioni,
ma ne ha ricevute solo 98, dirà al client:
"Ehi, mi avevi detto
che mi avresti inviato 100 cose, ma me ne hai inviate
solo 98".
"Mandami le due cose che mi mancano. E poi, si verifica una
ritrasmissione.
In questo modo, la comunicazione
può andare a buon fine e possiamo sempre
assicurarci di ricevere
ciò che ci spetta, perché abbiamo
questo reinvio dei pacchetti attraverso la
rete.
Ora, questo viene utilizzato per tutti i dati di rete
che devono essere assicurati per arrivare alla loro destinazione finale.
Mi piace pensare a questo come alla posta certificata.
Se voglio inviare un messaggio all'Agenzia delle Entrate, ad esempio,
voglio essere sicuro che lo riceva
e che non si perda nella posta.
Quindi potrei pagare un po' di più per ottenere
una ricevuta certificata che, quando
arriva, deve essere firmata da loro e che mi
viene rispedita per posta.
In questo modo, quando
ricevo la ricevuta, so
che il fisco ha ricevuto il mio pacco postale.
Il TCP funziona così.
D'altra parte, abbiamo
un altro protocollo noto come UDP.
UDP è quello che si definisce un protocollo senza connessioni,
cioè non deve aspettare le connessioni.
UDP è l'acronimo di User Datagram Protocol.
Il motivo per cui lo chiamiamo
datagramma è che se si usa UDP, si usa
questo tipo di dati.
Si chiama datagramma.
Ora, quando parliamo di UDP, UDP
è inaffidabile e trasmette
segmenti chiamati datagrammi.
E se vengono abbandonati,
il mittente non saprà mai che è successo.
Ora, perché dovrei voler inviare cose di
cui il mittente non è a conoscenza
e non ricevo alcun tipo di ricevuta?
L'UDP è davvero ottimo per lo streaming audio e visivo, perché
si inviano molti dati e l'overhead
è molto minore quando si usa l'UDP, perché non
c'è il costante handshake a tre vie per
stabilirlo e non ci
sono tutti i controlli e gli equilibri
associati all'uso del TCP.
Utilizzando UDP, è possibile
aumentare le prestazioni della rete, perché
le ritrasmissioni sono nulle.
Si finisce solo per perdere informazioni.
Non è una cosa negativa?
Perché dovremmo voler abbandonare le informazioni?
Per alcune applicazioni non
ha molta importanza.
Ad esempio, in questo momento state trasmettendo questo video.
E se mi ritirassi per 1/100 di secondo, ve
ne accorgereste?
Probabilmente non lo fareste,
ed è per questo che UDP è così buono,
perché possiamo perdere 1/100 del tempo e non ve ne
accorgerete nemmeno, e non ci sarà
una ritrasmissione.
Con il TCP, invece, il buffering
sarà molto più lungo, perché dovrete
aspettare e poi farvi rispedire
il file, metterlo nel posto giusto e poi riprodurlo.
Quindi, a causa di questo riconoscimento e di questo overhead,
per ogni singolo secondo di questo video, finirà
per diventare molto più grande e utilizzerà
molta più larghezza di banda.
Questo è uno dei motivi principali
per cui usiamo UDP per lo streaming video e audio.
Ora, facciamo un breve riepilogo di TCP e UDP.
Perché questo è un concetto davvero, davvero importante.
In effetti, se avete i vostri appunti,
vi segnerei questo grafico
che vi illustrerò ora,
mentre parliamo di TCP e UDP.
Perché è davvero così importante.
Innanzitutto, il TCP è affidabile, ha un handshake
a tre vie, mentre l'UDP
non è molto affidabile.
È un protocollo inaffidabile
perché non esiste un handshake a tre vie.
Il TCP è quello che chiamiamo "connection-oriented"
o "connection-full", in quanto prevede
l'handshake a tre vie negli
acknowledgements,
mentre l'UDP è "connectionless".
È un metodo "spara e dimentica".
Io comincio a inviare informazioni
e spero che le riceviate.
Il protocollo TCP utilizza la ritrasmissione dei segmenti e il controllo del flusso
che viene gestito attraverso il windowing.
In UDP, invece,
non c'è ritrasmissione né windowing.
Con il TCP, abbiamo una
segmentazione del nostro sequenziamento di
tutti i nostri diversi segmenti.
Con UDP, non c'è sequenziamento.
Ciò significa che quando spedisco tutto,
lo spedisco nell'ordine corretto,
da uno a cento.
Lo farò sia per TCP che per UDP.
Ora, se si perdono alcuni di questi
pezzi, o se arrivano in un ordine
diverso perché percorrono un percorso diverso
sulla rete, con il TCP
sono in sequenza, quindi
sa che ne avete uno a 1000 e li rimette
nella giusta sequenza.
Con UDP, qualunque
sia il nome con cui arrivano,
è quello che trasmetterà.
Quindi, può essere
uno, 50, due, 500,
tre, quattro, cinque,
sei, 20, in qualsiasi ordine casuale.
Ed è così che lo sentirete.
Nel caso dei video, quindi, è possibile che si senta un po' di saltellamento,
o un po' di cigolii acuti, o qualcosa del genere,
perché uno di quei fotogrammi
potrebbe essere uscito dall'ordine.
Ora, quando torniamo al TCP,
esso riconoscerà ciascuno di questi segmenti.
E così abbiamo un riconoscimento.
Se non la ricevo,
so che non l'ho ricevuta
e posso farmela ritrasmettere e poi riceverla
di nuovo.
Con UDP, non c'è riconoscimento.
Quindi, ancora una volta, UDP ha un overhead molto minore perché
non c'è connessione, non c'è
windowing, non c'è ritrasmissione, non c'è
sequenziamento e non c'è riconoscimento.
Ora, se si deve far arrivare qualcosa
e si vuole essere sicuri che la persona lo riceva,
si deve usare il protocollo TCP come protocollo di scelta.
Ed è per questo che utilizzeremo il TCP per
cose come le banche, i siti web, l'eCommerce
e cose del genere.
Ma se abbiamo qualcosa che contiene molti dati,
come lo streaming audio o video, l'UDP
si comporta davvero bene, perché non abbiamo
bisogno di ricevere
ogni singolo pezzo del file.
Possiamo saltare un po'
qua e là, e va bene così.
-Ora, quando si parla di TCP e UDP, abbiamo
parlato del fatto che si tratta di protocolli
orientati alla connessione e di protocolli
senza connessione.
Vi fornisco quindi un paio di esempi
di protocolli che utilizzano TCP o UDP, in modo che possiate
capire perché usiamo ciascuno di essi.
Per prima cosa, analizziamo
il TCP e i nostri protocolli
orientati alla connessione o a connessione piena.
Questo include cose come SSH e HTTP o HTTPS.
Ora, perché avremmo bisogno di un orientamento alla connessione in questi casi?
Nel caso in cui si utilizzi qualcosa come SSH, si tratta
di una comunicazione bidirezionale e del controllo
di un server remoto o di una workstation remota, e di essere
in grado di farlo sulla porta 22.
Voglio essere sicuro di
farlo in modo orientato o pieno di connessioni.
In questo modo, quando invio un comando e dico: riavvia
il server, so che il comando
è arrivato effettivamente a destinazione
e il riavvio del server avverrà.
Allo stesso modo, quando abbiamo a che fare con HTTPS, vogliamo
assicurarci di avere un protocollo pieno
di connessioni o orientato alle connessioni che utilizza TCP.
Il motivo è che, anche in questo
caso, vogliamo assicurarci che
ciò che inviamo venga effettivamente ricevuto.
E questo può includere cose come l'autenticazione
quando cerchiamo di accedere a un sito web
usando il nostro nome utente e la nostra
password, o forse le informazioni
che riceviamo da quel sito web, come
i saldi dei nostri conti e le nostre informazioni bancarie.
D'altra parte, se
usiamo UDP come protocollo, abbiamo a
che fare con una modalità senza connessioni.
Ho già accennato al fatto
che lo usiamo sempre per
cose come lo streaming audio e video.
Ma oltre a questo,
lo usiamo anche per cose come DHCP e il
Trivial File Transfer Protocol, noto come TFTP.
Ora, se ricordate,
il DHCP è utilizzato come Dynamic Host Control
Protocol e opera sulle porte 67 e 68.
Quando ci si unisce a una rete, il
dispositivo, se è impostato
per l'assegnazione dinamica dell'indirizzo
IP, invia un messaggio di broadcasting su quella rete
alla ricerca di un server DHCP.
Ecco perché lo usiamo come protocollo senza connessione.
Perché se le informazioni vengono inviate e nessuno risponde, il cliente
non farà altro che inviarle di nuovo nella speranza
che ci sia qualcun altro.
È così che funziona il DHCP.
Consentirà l'invio di un messaggio di trasmissione
e attenderà la risposta.
Se non riceve una risposta
entro un certo lasso di
tempo, il messaggio viene semplicemente ritrasmesso,
cercando di nuovo un nuovo server DHCP.
Allo stesso modo, il protocollo TFTP
o Trivial File Transfer Protocol,
che opera sulla porta 69, funzionerà
in modo privo di connessioni utilizzando
UDP come trasporto.
Il motivo è che TFTP
è il Trivial File Transfer Protocol e quindi non è necessario
avere la certezza che ogni singolo pacchetto
sia stato inviato e ricevuto con le relative
conferme, il che crea
molto più overhead se si usa TCP.
Quindi, usando UDP, possiamo
avere un trasferimento di file più veloce
quando usiamo qualcosa come TFTP, invece
di usare un protocollo più pieno di connessioni, come FTP.