Livello 4 - Trasporto

Questo livello fornisce il trasferimento di dati tra gli host ed è responsabile per il recupero degli errori e il controllo di flusso, ossia il processo per cui si aggiusta il flusso di dati dal mittente per assicurarsi che il ricevente li possa gestire tutti.
A questo livello viene supportato anche il "Session Multiplexing": il processo attraverso il quale un host può gestire contemporaneamente più sessioni e gestire i vari flussi di traffico su di un collegamento singolo.

Nell'immagine possiamo vedere che il mittente manda del traffico mail, attraverso il protocollo SMTP, al Destinatario 1 e manda al Destinatario 2 sia del traffico web (HTTP) sia del traffico mail.
Come fa il Destinatario 2 a riconoscere quale traffico mandare all'applicazione web e quale mandare all'applicazione mail?
Ci riesce grazie ad un'altra importante informazione contenuta nel livello 4: il numero della porta.
Possiamo vedere che il traffico mail utilizza la porta 25, mentre il traffico web utilizza la porta 80.
Il mittente include nell'header di livello 4 anche il numero della porta da cui viene originato il traffico, e la combinazione della porta sorgente con la porta di destinazione viene utilizzata per tenere traccia delle sessioni.

Possiamo vedere che il Mittente invia del traffico web con porta di destinazione 80 ed usa una porta casuale sopra alla 1024 come porta sorgente, nel nostro caso viene usata la porta 1500.
Quando il destinatario manda del traffico di ritorno in quella sessione, semplicemente inverte il numero delle porte: la porta 80 diventa la porta sorgente e la porta 1500 diventa la porta di destinazione.
Nell'header di livello 4 è anche incluso il protocollo utilizzato: che può essere TCP o UDP.

TCP

Il TCP (Transport Control Protocol) è un comune protocollo di livello 4.
Viene definito come protocollo "stateful connection", perché quando viene stabilita la connessione, i dati possono essere mandati in entrambe le direzioni.
Il TCP numera in ordine sequenziale i segmenti inviati, per assicurarsi che vengano processati nell'ordine corretto che non ne venga perso nessuno.
Questo protocollo è affidabile perché il ricevente manda pacchetti ACKs (acknowledgments) al mittente, in modo che questi possa reinviare i pacchetti eventualmente persi per strada.
Questo protocollo si occupa anche del controllo del flusso, quindi se il mittente sta mandando troppi dati senza che il destinatario sia in grado di gestirli, questo può segnalare al mittente di rallentare.

Handshake TCP

Le connessioni TCP vengono iniziate tramite quello che viene definito un "three-way handshake": vediamo meglio come funziona.

Abbiamo il nostro Mittente che inizializza la connessione mandando un SYN (Synchronized Message) al Destinatario sulla destra. Quando il SYN viene ricevuto, il destinatario manda un pacchetto SYN-ACK (Synchronized Acknowledgment) ed infine, per completare la connessione, il Mittente invia un ACK che indica al dispositivo sulla destra che ha ricevuto il messaggio precedente (SYN-ACK).
Ora la connessione è stata creata e i due dispositivi possono inviarsi del traffico.
Ricordandoci che quando un dispositivo invia del traffico, segue il modello OSI partendo dal livello Applicazione, incapsulando ogni header nell'header del livello precedente.
Vediamo ora come è composto l'header TCP di livello 4.

Possiamo vedere che i bit dal 0 al 15 servono ad identificare la porta sorgente, i bit dal 16 al 31 servono invece ad indicare la porta di destinazione.
Abbiamo anche altre informazioni, vediamo alcune:
Il numero sequenziale (Sequence number) indica il primo byte utile del carico, o viene usato per la creazione e la fine della connessione. Serve anche a rendere validi e riordinare (dopo il trasferimento) i segmenti.
Il campo riservato (reserved) non è ancora utilizzato e deve sempre avere il valore 0, viene riservato per usi futuri.
Le flags vengono utilizzate per attivare diverse azioni TCP (o per creare pacchetti malformati utili nei programmi di Bug Bounty, che vedremo successivamente). Le flag che vengono attivate o meno sono sei: URG, ACK, PSH, RST, SYN e FIN.
Checksum viene utilizzato per individuare gli errori di trasmissione.
Il campo Options viene utilizzato se bisogna attivare funzioni non comprese nell'header generale.
Infine, abbiamo il nostro payload effettivo, ossia i dati.

UDP

Il protocollo UDP (User Datagram Protocol) viene definito protocollo a "stateless connection".
Ciò significa che, a differenza di quanto accade col protocollo TCP, non c'è nessun handshake tra gli host e il traffico viene mandato, sostanzialmente, con la speranza che arrivi tutto (traffic best effort).
Quindi l'UDP non numera i segmenti mandati e ciò rende questo protocollo non affidabile, perché il destinatario non manda pacchetti ACKs al mittente.
UDP non si occupa del controllo del flusso e se si ha bisogno del rilevamento e correzione degli errori, queste funzioni devono avvenire nei livelli superiori.
Vediamo come è fatto un header UDP.

Possiamo vedere subito che l'header UDP contiene molti meno campi della controparte TCP.

TCP vs UDP

Abbiamo visto le differenze dei due protocolli, notando come il TCP sia più affidabile dell'UDP, quindi perché possono essere utilizzati entrambi se uno è "migliore" dell'altro?
I dati inviati tramite TCP impiegano più tempo, quindi la scelta del protocollo utilizzato dipende dal tipo di traffico dell'applicazione: se gli sviluppatori hanno bisogno di un traffico affidabile allora scelgono TCP, ma le applicazioni in tempo reale (come gli streaming, il VoIP o i videogiochi multiplayer) hanno bisogno di connessioni più veloci e quindi usano UDP.
Il traffico "real-time" è sensibile al ritardo.
Alcune applicazioni, però, possono usare entrambi i protocolli.
Le applicazioni comuni, e la loro porta di destinazione, che usano TCP sono:
-FTP (File Transfer Protocol), porta 21
-SSH (Secure Shell), porta 22
-Telnet, porta 23
-HTTP, porta 80
-HTTPS (versione criptata dell'HTTP), porta 443

Le applicazioni, con la loro porta di destinazione, che usano UDP sono:
-TFTP (Trivial File Transfer Protocol), porta 69
-SNMP (Simple Network Manager Protocol), porta 161

Ed infine, l'applicazione più conosciuta che usa sia TCP sia UDP è il DNS (Domain Name System),con porta 53.