Contenuti del corso

1. Introduzione alle Reti di Calcolatori

1.1 - Architettura di una rete.
1.2 - Il sistema a livelli nell'architettura di una rete.
1.3 - Servizi e funzionalità dei vari livelli
1.4 - L'architettura del protocollo OSI. I livelli del TCP/IP.
1. 5 - Confronto architetturale tra OSI e TCP/IP.
1.6 - Comunicazioni affidabili e non affidabili.
1.7 - Servizi con connessione e senza connessione
1.8 - Primitive di servizio
1.9 - Reti broadcast, Multicast, punto-punto
1.10 - PAN, LAN, MAN e WAN.
1.11 - Commutazione di circuito e commutazione di pacchetto.
1.12 - Reti a circuito virtuale.
2. Application Layer
2.1 - Comunicazione tra processi
2.2 - Lo schema Client - Server
2.3 - Affidabilità delle comunicazioni e coerenza dei dati end-to end
2.4 - Requisiti temporali e di affidabilità delle applicazioni
2.5 - Indirizzamento dei processi
2.6 - Well Known Ports, Registered Ports e User Ports
2.7 - Il protocollo HTTP
2.8 - Formato dei pacchetti HTTP
2.9 - HTTP 1.0, 1.1, 2.0, 3.0
2.10 - Il protocollo FTP
2.11 - Confronto tra HTTP e FTP
2.12 - Concetti di protocollo stateless e stateful. I cookies
2.13 - Il protocollo SMTP
2.14 - POP e IMAP
2.15 - Il protocollo DNS - I record DNS
2.16 - Cenni sul protocollo SNMP
3. Transport Layer
3.1 - Il modello Client-Server
3.2 - Indirizzamento a livello di trasporto (Mux -demux)
3.3 - I Server multipli
3.4 - Il livello di Trasporto in IP: UDP e TCP.
3.5 - Formato delle frame UDP
3.6 - Protocolli di trasferimento affidabile su canali inaffidabili
3.7 - Velocità di trasferimento dati di un canale
3.8 - Tempo di latenza
3.9 - Velocità di trasferimento end-to-end - Banda disponibile ai livelli superiori
3.10 - Protocolli Stop and wait, Go back N, Ripetizione selettiva
3.11 - Il protocollo TCP. Formato dei pacchetti TCP
3.12 - Tempi di Round Trip. Gestione dei Timer. Fast Retransmit
3.13 - Finestra di ricezione e gestione ACK in TCP
3.14 - Servizi orientati alla connessione.
3.15 - Apertura e chiusura delle connessioni: problemi teorici e soluzioni implementative
3.16 - La congestione nelle reti di comunicazione: aspetti teorici e possibili soluzioni
3.17 - Controllo del Flusso e controllo della Congestione
3.18 - Il controllo della congestione in TCP: varianti Tahoe e Reno.
3.19 - Fairness tra connessioni TCP concorrenti: dimostrazione grafica.
4. Network Layer
4.1 - Introduzione al livello di Rete.
4.2 - Servizi Datagram e servizi con circuito virtuale. Confronto delle caratteristiche
4.3 - Data Plane e Control Plane nei router.
4.4 - Algoritmi di routing: algoritmi centralizzati e distribuiti.
4.5 - Flooding: metodi di controllo del flooding
4.6 - Distance Vectors.
4.7 - Link State Routing
4.8 - Algoritmo di Dijkstra
4.9 - Confronto tra DV e LS.
4.10 - Routing gerarchico.
4.11 - Implementazioni RIP e OSPF.
4.12 - Cenni su BGP.
4.13 - Il protocollo IPv4.
4.14 - Formato dei pacchetti IPv4.
4.15 - Indirizzi IPv4. Le maschere. Le Sottoreti.
4.16 - Tabelle di routing per host e router. Indirizzamento IP su LAN ethernet
4.17 - Indirizzamento intraLAN e interLAN
4.18 - Frammentazione dei pacchetti IPv4
4.19 - Protocolli su IP: ICMP, ARP, RARP, BOOTP, DHCP, NAT.
4.20 - Il protocollo IPv6
4.21 - Indirizzi IPv6: indirizzamento Anycast, Unicast e Multicast.
4.22 - Indirizzi di canale
4.23 - Header opzionali
4.24 - Cenni sui Firewall.
5. Data Link Layer
5.1 - Tecniche di Framing dei dati.
5.2 - Codifica a due livelli, a tre livelli, a cinque livelli
5.3 - Codifica 4B/5B, 8B/10B
5.4 - Aspetti teorici per la rilevazione degli errori.
5.5 - Uso della ridondanza nelle comunicazioni.
5.6 - Il CRC. Calcolo del CRC.
5.7 - Correzione degli errori: aspetti teorici
5.9 - Distanza di Hamming.
5.10 - I codici di Hamming.
5.11 - Il sottolivello MAC
5.12 - Protocolli del Data Link per il MAC
5.13 - FDMA, TDMA, CDMA
5.14 - Aloha puro e slotted.
5.15 - CSMA
5.16 - CSMA/CD
5.17 - Protocolli senza collisioni
5.18 - Cenni sui protocolli a turno (token)
5.19 - Le LAN IEEE 802 (.1 .2).
5.20 - IEEE 802.3.
5.21 - Ethernet, Fast Ethernet, GigabitEthernet.
5.22 - Schemi di Trellis e decodifica di Viterbi.
5.23 - Schemi di interconnessione in Ethernet
5.24 - Repeater, Hub, Bridge, Switch
5.25 - Bridge trasparenti.
5.26 - Schemi di indirizzamento flat.
 5.27 - Confronto tra indirizzamento piatto ed indirizzamento gerarchico: vantaggi e 5.28 -
svantaggi
5.29 - Indirizzi MAC
5.30 - Le VLAN: Untagged e Tagged - IEEE 802.1Q
6. Laboratorio di Reti
6.1 - I sistemi virtualizzati: aspetti teorici e implementazioni
6.2 - Creazione di una VM Linux based
6.3 - Configurazione di una VM e collegamento in una LAN privata
6.4 - Configurazione di una interfaccia di rete con IPv4 e IPv6.
6.5 - Configurazione delle tabelle di routing.
6.6 - Configurazione di una rete con LAN differenti connesse da router.
6.7 - Uso dei socket in C e Python.
6.8 - Socket bloccanti e non bloccanti
6.9 - Esempio di un sistema Client Server con UDP, con IPv4 e IPv6
6.10 - Esempio di un sistema multiserver con TCP, con IPv4 e IPv6

https://github.com/TendTo/Tutorato-Reti-di-Calcolatori?tab=readme-ov-file
Lezione 1: Introduzione alle Reti di Calcolatori
Le reti di calcolatori sono sistemi che collegano vari dispositivi, consentendo loro di comunicare e
scambiare dati. Questi collegamenti permettono di accedere a risorse condivise e di trasmettere
informazioni in modo rapido e coordinato tra diversi dispositivi.

Un sistema di comunicazione si basa su due componenti fondamentali:

Mezzo fisico: È il supporto materiale che trasporta i segnali attraverso la rete, come cavi di rame,
fibra ottica o segnali wireless.
Parte logica (Software): I programmi e i protocolli gestiscono la comunicazione e il
funzionamento della rete.

Due entità possono comunicare se e solo se hanno dei protocolli in comune.

Cos’è un protocollo?
Un protocollo è un insieme di regole che definisce il formato e l'ordine dei messaggi scambiati tra
due o più entità in una rete, così come le azioni intraprese in fase di trasmissione e/o di ricezione di
un messaggio o di un altro evento.
Lezione 2: trasmissione
Tipi di comunicazione in rete
La comunicazione fisica nelle reti può avvenire in tre modalità principali: simplex, half
duplex e full duplex, che descrivono il modo in cui i dati vengono trasmessi tra due dispositivi.
1. Simplex: unidirezionale. Solo un dispositivo può inviare dati e l'altro può solo riceverli,
senza possibilità di risposta. Esempio: Una trasmissione radio, dove il segnale viene inviato
da una stazione radio e può essere ricevuto dagli ascoltatori, ma questi non possono
rispondere attraverso la stessa frequenza.
2. Half Duplex: bidirezionale, ma non simultanea. Entrambi i dispositivi possono inviare e ricevere
dati, ma non nello stesso momento; quando un dispositivo sta trasmettendo, l'altro deve aspettare
che la trasmissione termini prima di inviare una risposta. Esempio: sistema di comunicazione via
walkie-talkie.
3. Full Duplex: bidirezionale e simultanea. Entrambi i dispositivi possono trasmettere e ricevere
dati contemporaneamente, senza dover attendere. Esempio: le conversazioni telefoniche dove
entrambe le persone possono parlare e ascoltare nello stesso momento, o una rete Ethernet. Il full
duplex è ideale per comunicazioni interattive e simultanee.

Comunicazioni affidabili e non affidabili

Le applicazioni in generale hanno bisogno di canali che siano affidabili (reliable) e privi di errori.
Le comunicazioni possono essere:
Connection-Oriented: è un metodo di trasmissione in cui si stabiliscono dei protocolli di
comunicazione in modo da permettere la comunicazione tra le due entità.
Connectionless: è un metodo di trasmissione in cui ogni pacchetto di dati trasporta nell’header
l’indirizzo di destinazione e ciò basta al fine della sua spedizione. Non necessita di Handshaking
(cioè il ricevente riceve il messaggio che gli piaccia o no).
Internet offre due protocolli principali a livello di trasporto: TCP (Transmission Control Protocol)
e UDP (User Datagram Protocol). Ognuno ha caratteristiche specifiche che lo rendono adatto a
diversi tipi di applicazioni.
TCP (Transmission Control Protocol)
TCP è un protocollo di trasporto che offre servizi affidabili e orientati alla connessione:
 Servizio orientato alla connessione: Prima di inviare i dati, TCP richiede che i dispositivi
stabiliscano una connessione tra di loro tramite un processo di handshake a tre fasi. Questa
connessione è di tipo full duplex, il che significa che entrambi i dispositivi possono inviare
e ricevere dati simultaneamente. Una volta stabilita, la connessione viene mantenuta fino al
termine della comunicazione, e questo garantisce che entrambi i dispositivi siano pronti a
scambiare dati in modo ordinato.
 Trasferimento dati affidabile: TCP si occupa di garantire che i pacchetti arrivino
correttamente e nell’ordine giusto. Ogni pacchetto viene numerato, e il destinatario invia
un acknowledgment (ACK) per confermare che il pacchetto è stato ricevuto. Se l’ACK non
viene ricevuto entro un certo time-out, il pacchetto viene ritrasmesso. Questo sistema
permette di gestire eventuali pacchetti persi o danneggiati durante il trasferimento. TCP
include anche un sistema per scartare pacchetti duplicati, evitando che il destinatario
processi due volte lo stesso dato.
 Controllo della congestione: TCP monitora il traffico di rete e riduce la velocità di
trasmissione se rileva congestione, prevenendo il sovraccarico della rete. Questo
meccanismo è essenziale per evitare che troppi pacchetti vengano inviati quando la rete è
occupata, garantendo un utilizzo efficiente delle risorse di rete, ma introducendo qualche
ritardo per mantenere l’affidabilità.
Grazie a questi servizi, TCP è indicato per applicazioni che richiedono affidabilità e ordinamento,
come il trasferimento di file, l’e-mail e la navigazione web. Tuttavia, tutti questi meccanismi
aumentano la latenza, rendendo TCP meno indicato per applicazioni in tempo reale.
UDP (User Datagram Protocol)
UDP è un protocollo più semplice e rapido, che offre una modalità di trasporto non orientata alla
connessione e non affidabile:
 Servizio non orientato alla connessione: UDP non richiede l’instaurazione di una
connessione tra i dispositivi prima di inviare i dati. I pacchetti vengono inviati direttamente
al destinatario senza handshake e senza creare una sessione di comunicazione persistente.
Questo elimina i tempi di attesa per l’inizializzazione della connessione.
 Trasferimento dati non affidabile: UDP non include meccanismi di conferma di ricezione
(ACK) né di ritrasmissione. Non garantisce che i pacchetti arrivino nell’ordine corretto o
che arrivino affatto. Di conseguenza, i dati possono essere persi o ricevuti in modo
disordinato. Non esiste un controllo di congestione, quindi UDP invia i pacchetti alla
massima velocità possibile, senza verificare lo stato della rete.
Questa struttura lo rende adatto per applicazioni che danno priorità alla velocità piuttosto che
all’affidabilità, come lo streaming video, le chiamate vocali in tempo reale e i giochi online. In
queste applicazioni, qualche perdita di pacchetti può essere accettabile, poiché i ritardi per
ritrasmettere i pacchetti sarebbero più dannosi per la qualità dell’esperienza utente.

Caratteristica TCP UDP

Connessione Orientata alla connessione Non orientata alla connessione
Affidabilità Affidabile, con ritrasmissione Non affidabile
Ordinamento dei pacchetti Garantito Non garantito
Controllo di congestione Sì No
Velocità Più lenta (ma affidabile) Più veloce (ma inaffidabile)
Utilizzo ideale Applicazioni che richiedono affidabilità Applicazioni in tempo reale

Architettura a livelli
L’architettura a livelli è una struttura organizzativa delle reti che separa le varie funzioni della rete
in livelli gerarchici. Ogni livello ha responsabilità specifiche e collabora con i livelli adiacenti
(quello immediatamente sopra e quello immediatamente sotto) per offrire servizi agli utenti finali.

Modello teorico: pila ISO/OSI

Il modello OSI (Open Systems Interconnection) è un modello teorico a sette livelli. È considerato
uno standard de iure perché è stato sviluppato e formalizzato dall’ISO (International Organization
for Standardization). Questo modello fornisce una base teorica per descrivere e standardizzare i
processi di comunicazione in rete, anche se non è implementato direttamente nelle reti pratiche.
Ogni livello, rappresenta uno specifico ambito di funzioni di rete e definisce uno strato di astrazione
che dialoga con i livelli adiacenti. Questo approccio stratificato rende il processo più comprensibile,
gestibile e standardizzato.

I Sette Livelli del Modello OSI (a partire dal basso)

1. Livello Fisico: Si occupa della trasmissione effettiva dei bit attraverso il mezzo fisico (come
cavi, onde radio o fibra ottica). Definisce le caratteristiche elettriche, meccaniche e
funzionali dell’hardware, come cavi, connettori, segnalazione e frequenze di trasmissione. È
responsabile della codifica e decodifica dei segnali, ma non ha alcuna intelligenza di rete,
trattando semplicemente l’invio e la ricezione dei bit.
 2. Livello Data Link: Gestisce la trasmissione dei dati end to end (tra dispositivi adiacenti,
come computer o router vicini sulla stessa rete). Include meccanismi di controllo degli
errori e controllo di flusso per garantire la consegna affidabile dei dati tra nodi fisicamente
collegati. Controlla l’accesso al mezzo di comunicazione condiviso (ad esempio, Ethernet) e
indirizza i dati usando indirizzi MAC. Svolge funzioni di segmentazione dei dati in frame e
loro riassemblaggio, per ottimizzare il flusso di dati.
3. Livello di Rete: Si occupa dell’instradamento dei pacchetti (datagrammi) dalla sorgente
alla destinazione. Include protocolli di Routing per determinare il percorso migliore
attraverso la rete tramite supporto di indirizzi IP. Fa uso di tabelle di Routing e algoritmi di
instradamento che consentono ai pacchetti di attraversare più reti per raggiungere
destinazioni remote.
4. Livello di Trasporto: Gestisce la consegna affidabile dei dati tra host di origine e di
destinazione, assicurando che i dati siano consegnati in sequenza e senza errori.
o Utilizza protocolli come TCP e UDP.
o Questo livello gestisce la frammentazione dei dati in segmenti e il loro
riassemblaggio, oltre a garantire il controllo del flusso e la gestione degli errori.
5. Livello di Sessione: Fornisce meccanismi per avviare, mantenere e terminare le sessioni di
comunicazione e gestisce i dialoghi tra applicazioni. È responsabile del mantenimento della
continuità delle sessioni anche in caso di interruzioni.
6. Livello di Presentazione: Si occupa della conversione e formattazione dei dati tra il
livello di applicazione e il livello di sessione, assicurando che i dati siano nel formato
corretto per essere interpretati dall’applicazione di destinazione. Gestisce la crittografia,
compressione e codifica dei dati per consentire la sicurezza e l’ottimizzazione della
trasmissione. Fornisce un’interfaccia che consente di interpretare correttamente le
informazioni indipendentemente dal tipo di dati o dalla loro struttura interna.
7. Livello di Applicazione: È il livello più vicino all’utente finale, fornendo servizi di rete
diretti alle applicazioni, come browser, client di posta elettronica. Definisce i protocolli di
alto livello che le applicazioni utilizzano per interagire con la rete, come HTTP per il web,
SMTP per la posta elettronica e FTP per il trasferimento di file. Consente agli utenti di
utilizzare la rete tramite applicazioni, e traduce i dati in formati comprensibili per l’utente.

Modello pratico: standard de facto

Il modello OSI, pur essendo fondamentale dal punto di vista teorico, non è il modello utilizzato
nella pratica. Lo standard de facto per le reti di comunicazione è l'architettura
TCP/IP (Transmission Control Protocol/Internet Protocol), che è il modello effettivamente adottato
da Internet. Il protocollo TCP/IP, sebbene sia lo standard de facto utilizzato su Internet, non è uno
standard de iure perché è nato come protocollo di implementazione pratica senza essere
formalmente approvato dall’ISO.
Questo modello ha una struttura più semplice e si basa su quattro livelli principali (rispetto ai sette
del modello OSI), che si avvicinano meglio all’implementazione reale delle reti:
1. Livello di Accesso alla Rete (Network Access): Corrisponde approssimativamente ai livelli
Fisico e Data Link del modello OSI. Si occupa delle modalità di accesso e trasmissione dei
dati su vari mezzi fisici, gestendo sia l'instradamento locale che il controllo di accesso al
mezzo.
2. Livello Internet: Corrisponde al livello di Rete nel modello OSI e si occupa
dell'instradamento dei pacchetti, principalmente attraverso il protocollo IP.
3. Livello di Trasporto: Include protocolli come TCP e UDP, simile al livello di Trasporto del
modello OSI.
4. Livello Applicativo: Comprende i livelli superiori del modello OSI: Sessione,
Presentazione e Applicazione. Si occupa di fornire i protocolli e i servizi necessari per la
comunicazione diretta tra le applicazioni di rete.
È bene chiarire che TCP/IP non è realmente suddiviso in livelli, significa che è un modello orientato
alla praticità, dove le suddivisioni sono più funzionali che teoriche e non richiedono una rigida
separazione di compiti, permettendo invece un'integrazione tra i vari protocolli e le loro funzioni.

Differenze tra OSI e TCP/IP

 Numero di livelli: TCP/IP ha solo quattro livelli, mentre OSI ne ha sette. TCP/IP unisce i
livelli di Sessione, Presentazione e Applicazione in un unico livello Applicativo.
 Orientamento: TCP/IP è nato come implementazione pratica e per specifici protocolli usati
in Internet; OSI è un modello teorico progettato per essere universale.
 Semplicità e adozione: La struttura semplificata di TCP/IP ha reso più semplice la sua
implementazione, e quindi è diventato lo standard de facto.

Comunicazione Verticale (interna)

All'interno dello stesso dispositivo, i dati attraversano verticalmente i vari livelli, partendo dal
livello applicativo (in alto) e scendendo fino al livello fisico (in basso).
Ogni livello aggiunge una propria intestazione (header) ai dati, che contiene informazioni specifiche
per quel livello, come gli indirizzi di rete per il livello di rete o le informazioni di porta per il livello
di trasporto.
Quando i dati arrivano al livello fisico, vengono convertiti in segnali elettrici, ottici o radio che
possono viaggiare fisicamente attraverso i cavi o l'aria verso un altro dispositivo.

Comunicazione Orizzontale (tra host differenti)

La comunicazione tra due dispositivi avviene orizzontalmente, tra livelli equivalenti sui due
dispositivi (ad esempio, livello di rete dell'host A con il livello di rete dell'host B).
Ogni livello "crede" di comunicare direttamente con il livello equivalente sull'altro dispositivo,
anche se in realtà il messaggio deve attraversare tutti i livelli dell'host locale, passare attraverso il
livello fisico e poi risalire attraverso i livelli dell'host remoto.
Questa comunicazione orizzontale è quella che comporta più rischi di fallimento, poiché è esposta
ai limiti fisici, agli errori di trasmissione e alle differenze di configurazione tra i dispositivi.
Come funziona?
Ogni livello riceve il messaggio dal livello superiore e aggiunge una propria intestazione specifica
per il protocollo di quel livello, in un processo chiamato incapsulamento.
Il processo di incapsulamento inizia dal livello applicativo, dove il messaggio di livello applicativo
viene suddiviso in segmenti di livello di trasporto, ad esempio utilizzando il protocollo TCP o
UDP. Il segmento di livello di trasporto contiene le informazioni necessarie per instradare
il pacchetto attraverso la rete, come ad esempio i numeri di porta di origine e di destinazione.
Successivamente, il segmento di livello di trasporto viene incapsulato in un datagramma a livello
di rete, che contiene l'indirizzo IP di origine e di destinazione, necessario per instradare il pacchetto
attraverso la rete. Il datagramma a livello di rete viene quindi incapsulato in un frame a livello di
collegamento dati, ad esempio utilizzando il protocollo Ethernet. Il frame a livello di
collegamento dati contiene gli indirizzi MAC di origine e di destinazione, necessari per instradare il
pacchetto attraverso la rete locale. Infine, il frame a livello di collegamento dati viene tradotto in bit
a livello fisico, che vengono trasmessi attraverso il mezzo di trasmissione fisico, come ad esempio
un cavo Ethernet.
Il processo di de-incapsulamento avviene in modo inverso quando il pacchetto raggiunge la
destinazione finale. Il livello fisico riceve i bit e li passa al livello di collegamento dati, che rimuove
l'intestazione del frame a livello di collegamento dati. Successivamente, il livello di rete rimuove
l'intestazione del datagramma e infine il livello applicativo riceve il segmento di livello di trasporto.

Tipologie di trasmissione nelle reti di calcolatori:

1. Point to Point: i dati vengono trasmessi da un singolo mittente a un singolo destinatario; è
diretto e non coinvolge altri nodi sulla rete. Per esempio: Una connessione diretta tra due computer
tramite un cavo seriale o una connessione modem.
2. Multicast: i dati vengono inviati a un gruppo specifico di destinatari che si sono uniti a una
sessione di Multicast. Solo i dispositivi che si sono registrati per ricevere i dati da un certo indirizzo
multicast possono riceverli. Esempio: Streaming video o audio a un numero selezionato di utenti,
come in una conferenza online.
3. Broadcast: implica l'invio di dati a tutti i dispositivi su una rete. Ogni dispositivo riceve il
messaggio, anche se solo uno o alcuni di essi possono essere i destinatari reali. Esempio: annunci
ARP in una rete LAN, dove un dispositivo invia un messaggio a tutti gli altri dispositivi per
scoprire l'indirizzo MAC associato a un indirizzo IP specifico.
4. A Bus Condiviso: tutti i dispositivi sono collegati a un singolo cavo (bus) attraverso il quale
passano i dati. Ogni dispositivo ascolta i messaggi sulla rete e può ricevere informazioni destinate a
lui. La comunicazione avviene in modo condiviso, cioè se A deve mandare un messaggio ad F
questo arriva a tutti, quindi può esserci congestione. Esempio: Reti Ethernet tradizionali, anche se
oggi è meno comune a causa di problemi di affidabilità e scalabilità.
5. Ring (Ad Anello): ogni dispositivo è collegato a due altri dispositivi, formando un anello. I dati
viaggiano in un'unica direzione (o in entrambe le direzioni, a seconda dell'implementazione) e ogni
dispositivo ha la possibilità di trasmettere i dati che passano attraverso di esso (stesso problema del
bus).
6. A Stella: tutti i dispositivi sono collegati a un nodo centrale (hub o switch). Il nodo centrale
gestisce la comunicazione e può indirizzare i dati tra i dispositivi. Questo tipo di topologia è molto
scalabile e facile da gestire, ma la comunicazione dipende dall’hub, per cui se si guasta le macchine
non possono più comunicare. Per risolvere il problema delle collisioni**, basta avere un hub
intelligente in modo da evitarle, ad esempio si può pensare di smistarle in una coda. Esempio: Reti
Ethernet moderne, dove gli switch fungono da hub centrale per la trasmissione dei dati tra i vari
dispositivi.

**Se mandiamo più segnali contemporaneamente, c’è il rischio che questi si vadano a sovrapporre e
dunque andiamo ad avere segnali compromessi. Nel caso in cui il segnale che arriva non è
comprensibile, parleremo di collisione. Quando parleremo di segnali, parleremo chiaramente di
segnali radio.
 Multicast

Tassonomia delle reti (in base all’estensione geografica)

Interprocessor distance: distanza tra i processori (dispositivi di rete: computer, server, router, ecc)
Processors located in same: area in cui sono collocati, o in cui è definita la rete
DMI LAN
UNICTMAN

Commutazione
La commutazione è il processo di stabilire un percorso attraverso il quale i dati possono essere
inviati da un punto a un altro all'interno di una rete. Ci sono 2 principali tipi di
commutazione: commutazione a livello di circuito, commutazione a livello di pacchetto.

1.Commutazione a livello di circuito: stabilisce un percorso fisico dedicato tra il mittente e il

destinatario prima della comunicazione. Durante l'intera durata della comunicazione, questa
connessione rimane attiva e le risorse di rete sono riservate per quel particolare flusso di dati.
Un esempio è la vecchia rete telefonica in cui c’era la persona che chiamava il centralino e diceva
chi chiamare, dopodiché il centralino dava la linea e permetteva la comunicazione.
Come funziona? Prima che i dati possano essere inviati, viene eseguita una fase di setup per creare
un circuito. Questo circuito può includere vari nodi e link, e una volta stabilito, rimane attivo fino
alla fine della comunicazione.
Vantaggio: Fornisce una qualità di servizio garantita, bassa latenza** e un flusso costante di dati.
Svantaggio: Non utilizza efficientemente le risorse di rete, infatti se non ci sono dati da trasmettere,
la linea rimane comunque occupata. Inoltre, se il percorso dedicato risulta congestionato o si
verifica un guasto, la connessione può̀ interrompersi.
Quando si utilizza la commutazione di circuito, esistono due modalità principali per suddividere la
capacità del canale: FDM (Frequency Division Multiplexing) e TDM (Time Division
Multiplexing).
1. FDM: la capacità del canale viene suddivisa in frequenze distinte. Ogni connessione occupa
una diversa banda di frequenze, come se ogni connessione avesse la sua "corsia" all'interno
del canale. Questo metodo è come avere diverse stazioni radio su diverse frequenze, in cui
ciascuna trasmissione viaggia su una banda dedicata, evitando interferenze.
Immagina il canale come una strada a più corsie, dove ogni corsia rappresenta una banda
di frequenza. Ogni connessione (o utente) ha una corsia assegnata e viaggia esclusivamente
su quella, senza interferire con le altre.
2. TDM: la capacità del canale è suddivisa in intervalli di tempo. Ogni connessione occupa
uno specifico intervallo di tempo o "slot" all'interno di una sequenza ripetitiva. Durante il
suo slot, ogni chiamata trasmette i suoi dati, e poi cede il canale a un'altra chiamata, che
utilizzerà il suo slot successivo. È come un carosello, dove ogni chiamata ha un turno per
trasmettere. Anche se ciascun utente trasmette solo in un breve intervallo, il processo è così
veloce che sembra che tutti trasmettano simultaneamente. I dati di ciascun utente sono
"spezzettati" in frame, che vengono inviati nel loro turno, i quali vengono poi ricostruiti
all'arrivo per ricreare il messaggio originale.

2.Commutazione a livello di pacchetto: i dati vengono suddivisi in pacchetti, che sono unità più
piccole di informazioni. L’idea è quella di usare un grafo, così facendo se salta una strada possiamo
usare una strada secondaria per arrivarci.

(a) Commutazione di circuito

(b) Commutazione di pacchetto

I pacchetti vengono instradati in modo indipendente attraverso la rete. Ogni pacchetto contiene le
informazioni necessarie per raggiungere la sua destinazione, cioè mittente, destinazione e payload.
Una volta arrivati, vengono riassemblati per formare il messaggio originale.
Vantaggi: Dato che ogni pacchetto viene instradato singolarmente, la rete può̀ utilizzare più̀
percorsi e risorse di rete in modo efficiente (un arco diverso del grafo). Inoltre, se un percorso
diventa congestionato o si verifica un guasto nella rete, i pacchetti possono essere instradati su
percorsi alternativi per evitare ritardi o perdite di dati.
Svantaggi: dato che i pacchetti possono viaggiare percorsi diversi e arrivare in ordine diverso
rispetto a quello in cui sono stati inviati, può introdurre latenza variabile. Poiché́ i pacchetti sono
elaborati individualmente, la commutazione a livello di pacchetto può̀ richiedere maggiori risorse di
elaborazione. Per gestire il traffico si può pensare a delle code.
ARPANET (Advanced Research Projects Agency Network) è stata la prima rete a commutazione
di pacchetto, realizzata alla fine degli anni ’60 e sviluppata dall'ARPA (oggi DARPA), l'agenzia del
Dipartimento della Difesa degli Stati Uniti dedicata a progetti di ricerca avanzata. Quando
ARPANET fu sviluppata, il metodo dominante di trasmissione dati nelle telecomunicazioni era
la commutazione di circuito (usata, ad esempio, nelle telefonate).
ARPANET rappresenta quindi il precursore di Internet: molti dei protocolli e dei principi di base su
cui si basa oggi Internet (come il protocollo TCP/IP) furono sperimentati e sviluppati proprio su
questa rete.
Reti a commutazione di pacchetto: è il metodo in cui, i dati vengono suddivisi in pacchetti
indipendenti attraverso la rete. È un’idea generale che include sia le reti datagram che quelle a
circuito virtuale.
Reti a circuito virtualei pacchetti seguono un percorso predefinito (circuito logico)
Reti datagramogni pacchetto è trattato indipendentemente.

Commutazione a circuito virtuale: Questo metodo combina elementi della commutazione a

circuito e a pacchetto.
Come funziona? Viene inviato un pacchetto esploratore che esplora il cammino commutatori
(router e switch) una sola volta e dopo di che si sfrutta questo flusso che viene identificato
specificando solo l’host di destinazione. Quando viene avviata una comunicazione, viene creato un
percorso logico tra i nodi, simile alla commutazione a circuito. Tuttavia, i dati vengono inviati in
pacchetti, e questi pacchetti possono seguire percorsi diversi nella rete. Una volta che i pacchetti
raggiungono la destinazione, vengono riassemblati in base all'ordine stabilito dal circuito virtuale.
Vantaggi: garantisce una connessione affidabile e senza interruzioni tra il mittente e il destinatario,
utilizzando risorse di rete dedicate; consente di utilizzare le risorse di rete in modo efficiente, poiché́
i pacchetti possono essere instradati attraverso la rete in base alla destinazione specifica di ogni
pacchetto.
Svantaggi: Può richiedere una configurazione iniziale più complessa rispetto alla commutazione a
pacchetto, poiché deve mantenere lo stato del circuito virtuale. Se un server si rompe nel mezzo
della comunicazione, perderemo tutti i pacchetti e saremo costretti a rimandarli tutti da capo. Alcuni
sistemi decidono di mandare un altro pacchetto esploratore in un’altra strada per vedere se può
continuare la comunicazione da lì.

**latenza = parametro che misura il ritardo nella trasmissione dei dati in una rete.

Reti Datagram: In queste reti, ogni pacchetto è indipendente dagli altri e può seguire percorsi
diversi per arrivare a destinazione. Non c'è un percorso prestabilito per la comunicazione, e i
pacchetti possono arrivare in ordine diverso da quello di invio. Ogni pacchetto contiene le
informazioni necessarie per arrivare alla destinazione. Questo è il modello tipico di Internet, basato
sul protocollo IP.

Cenni sulla sicurezza di rete

Virus: è un tipo di malware che si diffonde all'interno di un sistema infettando programmi o file. Il
suo funzionamento si basa sull'inserimento di un codice dannoso (detto payload) in un file o in un
programma. Quando l'utente esegue o apre il file infetto, il virus viene attivato e può iniziare a
replicarsi, diffondendosi ad altri file o sistemi, per questo sono definiti file infector. I virus spesso
richiedono l'interazione dell'utente per propagarsi, ad esempio aprendo un allegato di posta
elettronica infetto.
Worm: è anch’esso un malware auto-replicante, ma si differenzia in quanto è autonomo
(standalone). Non hanno bisogno dell'intervento umano per replicarsi, ma si diffondono sfruttando
vulnerabilità nel software o nel sistema operativo. Gli sviluppatori di malware scrivono l’exploit
cioè codice che sfrutta specifiche falle di sicurezza (spesso create per errore dagli sviluppatori
durante la scrittura di un programma o lo sviluppo di un sistema operativo) per penetrare in un
sistema e diffondersi automaticamente. I worm possono infettare i sistemi in modo rapido e
silenzioso, senza che l'utente se ne accorga.
Spyware: è un tipo di software progettato per raccogliere informazioni sensibili senza il consenso
dell'utente. Può registrare le sequenze di tasti (keylogging), monitorare la cronologia di
navigazione, raccogliere dati personali come password e numeri di carte di credito, e inviarli a
server remoti. Spesso gli utenti non si accorgono della presenza di spyware nei loro dispositivi.
Botnet: è una rete di computer infetti che vengono controllati da un attaccante, spesso senza che gli
utenti se ne rendano conto. Gli attaccanti utilizzano i dispositivi infetti per lanciare attacchi DDoS
(Distributed Denial of Service), spammare o compromettere ulteriormente altre reti. Le botnet
possono rimanere dormienti fino a quando l'attaccante non decide di attivarli per un attacco.
Un attacco DoS (Denial of Service) mira a rendere un servizio o una risorsa di rete non disponibile
per gli utenti legittimi. Gli aggressori sovraccaricano il sistema o il server con traffico fittizio,
impedendo che le risorse vengano utilizzate correttamente. Nel caso di un attacco DDoS
(Distributed Denial of Service), il traffico proviene da una rete distribuita di dispositivi infetti
(botnet), rendendo l'attacco più difficile da mitigare.
Packet sniffing: è una tecnica utilizzata per intercettare e analizzare i pacchetti di dati che
viaggiano in una rete. In una rete non protetta, come una rete Wi-Fi aperta o una rete Ethernet
condivisa, i pacchetti di dati possono essere facilmente catturati da malintenzionati che usano
strumenti come Wireshark per esaminare il traffico e raccogliere informazioni sensibili, come
password, numeri di carte di credito e dati personali. La protezione contro lo sniffing include l'uso
di crittografia per i dati in transito (come TLS/SSL), l'adozione di reti sicure (ad esempio, reti
private virtuali - VPN) e l'implementazione di reti Wi-Fi sicure con crittografia WPA2 o WPA3.
IP spoofing: è una tecnica in cui un aggressore invia pacchetti di dati con un indirizzo IP di origine
falso, facendo credere al destinatario che il pacchetto provenga da una macchina legittima e sicura.
Questo può essere utilizzato in attacchi DoS, DDoS o per eludere misure di sicurezza, come i filtri
di accesso basati su IP. Per difendersi dall'IP spoofing, è necessario implementare controlli di
autenticazione più robusti, come filtraggio dei pacchetti (ad esempio, con un firewall).
Lezione 3: livello applicativo
Nella progettazione di reti informatiche, i modelli architetturali Client-Server e Peer-to-Peer
(P2P) definiscono due approcci distinti alla gestione dei servizi in rete, con obiettivi e strutture
diverse.

Modello client server

Interagiscono due entità:
Client: è un dispositivo che richiede servizi. Di solito, ha un indirizzo IP dinamico (che può
cambiare ad ogni connessione) e non comunica direttamente con altri client, ma sempre attraverso
un server centrale. Ogni client invia una richiesta al server e riceve una risposta, ma il client stesso
non deve rimanere sempre attivo, consentendo un risparmio di risorse energetiche e computazionali.
Server: è una macchina dedicata che è sempre attiva e ha un indirizzo IP fisso. È spesso ospitata
in data center per garantire prestazioni ottimali e una connessione stabile. Gestisce le richieste dei
client, elaborandole e rispondendo con i dati richiesti.
Il server accetta richieste dai client tramite un’interfaccia di rete nota come "socket di ascolto"
(listening socket), e, una volta ricevuta una richiesta, crea una "socket di connessione" dedicata per
gestire la comunicazione con quel particolare client (la comunicazione sarà stabile fino al termine
della richiesta). Questo consente al server di gestire più richieste contemporaneamente.
Tuttavia, la sua centralizzazione può essere uno svantaggio, poiché un malfunzionamento del server
può interrompere l'intero servizio.

Modello Peer-to-Peer (P2P)

Il modello Peer-to-Peer è decentralizzato, senza un server centrale. Qui, ogni peer (o nodo) agisce
sia come client che come server, il che significa che può richiedere e offrire servizi ad altri peer, in
un modello distribuito. In un sistema P2P, ogni nodo può comunicare direttamente con altri peer,
condividendo risorse, dati e servizi senza passare attraverso un server centrale. Questo modello è
utilizzato per applicazioni come la condivisione di file (es. BitTorrent) o le reti di messaggistica
distribuita, dove è vantaggioso avere nodi autonomi in grado di contribuire e ricevere dati.

Confronto tra Client-Server e Peer-to-Peer

 Client-Server: centralizzato, affidabile e sicuro, ma può essere un collo di bottiglia se il
server è sovraccarico.
 Peer-to-Peer: decentralizzato e scalabile, con il vantaggio di utilizzare la potenza di calcolo
e la capacità di archiviazione dei dispositivi partecipanti, ma più vulnerabile in termini di
controllo e sicurezza.

Quali servizi il protocollo a livello di trasporto può offrire a un’applicazione che li

invoca? I protocolli di trasporto godono delle seguenti proprietà:
1. Trasferimento dati affidabile: i dati arrivano in modo corretto e completo. Garantire
integrità dei dati, non è sempre richiesta
2. Throughput garantito: quantità di pacchetti spediti nell’unità di tempo (diverso dalla banda
che rappresenta invece la capienza massima, la portata del canale).
3. Timing: avere la certezza che i dati arrivino entro un determinato lasso di tempo.
4. Sicurezza: (Autenticazione(chi?), Confidenzialità (Qualcun altro lo legge?), Integrità (sono
stati modificati nel tragitto?) non ripudio (Una volta confermata l’azione, non può negare ciò
che ha fatto))

Comunicazione tra processi

Il processo sappiamo che è un programma in esecuzione su un host. Se due processi si trovano nello
stesso host questi usano la comunicazione inter-processo, mentre se l’host è diverso, questi
comunicano scambiandosi dei messaggi. Lo scambio di messaggi consente la sincronizzazione tra
processi.
Nel primo caso dato che ogni processo è identificato da un process ID, per comunicare devono
semplicemente conoscere il PID rispettivo; nel secondo caso non è sufficiente, entrano in gioco le
porte. Diciamo che una porta è aperta se quando riceve, legge il contenuto; diciamo che è chiusa se
quello che riceve, lo scarta.
La comunicazione tra processi su una rete permette a programmi in esecuzione su host differenti
di scambiare informazioni e di coordinarsi. Per realizzare questa comunicazione, viene utilizzata
un’interfaccia fornita dal sistema operativo che gestisce il trasferimento di messaggi tra client e
server, con il client che avvia sempre la comunicazione e il server che attende richieste in modalità
di "ascolto".
La comunicazione su rete tra processi avviene attraverso le socket. Una socket è un punto di
accesso alla rete che permette a un processo di comunicare con un altro processo, sia su un
computer remoto che sullo stesso computer, rappresenta in altre parole, un endpoint di
comunicazione, composto da una coppia di indirizzo IP e numero di porta (16 bit). Questo
permette ai processi di inviare e ricevere dati tramite una connessione gestita dal sistema operativo.
Ogni host può avere molteplici socket, ognuno identificato da una diversa combinazione di IP e
porta.
Indirizzamento con un Name Server
Abbiamo un processo identificato come Process Server, che è in ascolto su tante porte differenti.
L’utente si connette a questo processo mandando una richiesta. Il processo del server indirizza ad
un servizio che svolge una qualche attività. Per questioni di sicurezza conviene disporre solo un
processo che rimanga in ascolto su tutte le porte. Al momento in cui arriva una richiesta, il
processo identifica il tipo di richiesta che è arrivata lancia un processo separato, un processo figlio
per esempio e gli passa la connessione. Il solo processo ascolta le richieste in arrivo e capisce se le
richieste sono lecite o meno.
Multiplazione (multiplexaggio)

Abbiamo client P1 e P2 (nella stessa macchina) che mandano entrambi delle richieste ai server p3 e
p4. Come facciamo a capire a chi va la risposta se queste si trovano nella stessa macchina e quindi
hanno lo stesso IP?
Multiplexing e del demultiplexing sono due tecniche che vanno effettuate tra i due host per far sì
di capire a chi va quale pacchetto. Infatti, il multiplexing serve a radunare i frammenti di dati da
diverse socket sull’host di origine e incapsulare ognuno con header a livello di trasporto per creare
dei segmenti e passarli a livello di rete. Invece il demultiplexing ha il compito di trasportare i dati
dei segmenti a livello di trasporto verso la giusta socket.
Una cosa molto importante è che il multiplexing, richiede il campo del numero di porta di origine e
il campo del numero di porta di destinazione.
ESEMPIO CONDOMINIO
Anna effettua un’operazione di multiplexing quando raccoglie le lettere dai mittenti e le imbuca.
Nel momento in cui Andrea riceve le lettere dal postino, effettua un’operazione di demultiplexing
leggendo il nome riportato sopra la busta e consegnando ciascuna missiva al rispettivo destinatario.

La multiplazione è un processo che permette di gestire simultaneamente diverse connessioni di rete

sulla stessa macchina, assicurando che i dati inviati e ricevuti siano consegnati alle applicazioni
giuste. Questo è fondamentale poiché il livello applicativo in un dispositivo non è un singolo
programma, ma può includere diverse applicazioni in esecuzione, come browser web, client di posta
elettronica, o programmi terminali. Ogni applicazione necessita di un metodo per ricevere i propri
dati senza interferire con quelli delle altre applicazioni.
Come funziona la multiplazione
Ogni processo che richiede una connessione di rete ha un numero di porta associato, esclusivo per
ciascuna applicazione.
Il server ha un IP e una porta fissi, mentre il client ha un IP che può cambiare e una porta assegnata
dinamicamente dal sistema operativo quando la connessione è stabilita. Il server resta in "ascolto"
su una porta nota, e quando riceve una richiesta dal client, utilizza una socket di connessione per
gestire la comunicazione con quel client specifico.
Ogni messaggio inviato tra client e server deve seguire un protocollo di comunicazione, che è
definito e documentato negli RFC (Request for Comments), che garantiscono che il
comportamento sia standardizzato e compatibile su diversi dispositivi e sistemi.
Connessione TCP e l'uso del Socket
Una connessione è identificata univocamente da quattro elementi:
1. Indirizzo IP del dispositivo sorgente,
2. Numero di porta del processo sorgente,
3. Indirizzo IP del dispositivo di destinazione,
4. Numero di porta del processo di destinazione.
Questa coppia di indirizzo IP e numero di porta per ciascuno dei due dispositivi connessi è la
socket.
La socket permette di differenziare le connessioni, anche quando arrivano da applicazioni che usano
lo stesso protocollo.
In che senso? Immaginiamo di avere due applicazioni aperte sul computer: Un browser web (ad
esempio, Chrome) che sta visitando un sito web e un'applicazione di chat che sta caricando
contenuti da un server. Entrambe le applicazioni usano HTTP, ma il sistema operativo riesce
comunque a gestire queste connessioni separatamente grazie alle socket, in questo modo:
ogni connessione a un server utilizza una porta locale diversa per ogni applicazione o connessione.
Il browser potrebbe aprire una connessione con il server web usando la porta locale 54321.
L'app di chat potrebbe aprire una connessione con un server diverso (o lo stesso) usando la porta
locale 54322. Anche se entrambe stanno usando HTTP (sulla porta 80 o 443 del server remoto),
la porta locale è diversa per ogni connessione. Questo è ciò che rende uniche le socket: ogni
combinazione di IP locale, IP remoto, porta locale e porta remota è diversa per ciascuna
connessione, anche se usano lo stesso protocollo. Il sistema operativo sa quale processo (e quindi
quale applicazione) gestisce ciascuna connessione in base alla socket. Quando il server invia dati di
risposta, il sistema operativo utilizza la socket per instradare i dati all'applicazione corretta. Dato
che la socket è unica, il sistema operativo sa esattamente quale applicazione deve ricevere i dati di
risposta.

Abbiamo visto come i processi di rete comunichino tra loro inviando messaggi tra socket. Ma come
sono strutturati questi messaggi? Qual è il significato dei loro campi? Quando vengono inviati?
Queste domande ci conducono nel campo dei protocolli a livello di applicazione.
Un protocollo per la parte applicativa definisce:
- Tipi di messaggi che si scambiano (richieste, risposte)
- Sintassi dei messaggi
- Semantica dei messaggi
- Regole per come e quando mandare e rispondere
- Il protocollo stesso e a chi appartiene

Le porte di rete sono numeri a 16 bit che identificano le connessioni tra applicazioni su dispositivi
diversi in rete. Classifichiamo le porte:
1. Well-known ports (Porte ben note)
Range: da 0 a 1023: porte sono essenziali per identificare i protocolli standard e i più
comuni usati dai servizi di rete.
- FTP (File Transfer Protocol) - Utilizza le porte 20 e 21. È un protocollo per trasferire file
tra client e server su una rete, molto usato per caricare e scaricare file da server remoti.
- SSH (Secure Shell) - Usa la porta 22. SSH è un protocollo per la connessione remota sicura
a un altro dispositivo, criptando i dati trasmessi per garantire privacy e sicurezza.
- Telnet - Usa la porta 23. È un protocollo di accesso remoto simile a SSH ma senza
crittografia, quindi meno sicuro.
- SMTP (Simple Mail Transfer Protocol) - Usa la porta 25. Viene utilizzato per l’invio di e-
mail dai client ai server di posta e per il trasferimento tra server.
- DNS (Domain Name System) - Usa la porta 53. È un protocollo che trasforma i nomi di
dominio (come example.com) in indirizzi IP comprensibili dalla rete, permettendo ai client
di accedere a risorse Internet.
- HTTP (Hypertext Transfer Protocol) - Usa la porta 80. Protocollo principale per la
trasmissione di pagine web non criptate.
- HTTPS (Hypertext Transfer Protocol Secure) - Usa la porta 443. È la versione sicura e
crittografata di HTTP, utilizzata per la trasmissione di dati sensibili su Internet, come per siti
di e-commerce o banking online.
- POP3 (Post Office Protocol 3) - Usa la porta 110. Protocollo per scaricare e-mail dai server
di posta ai client locali, solitamente rimuovendole dal server.
- IMAP (Internet Message Access Protocol) - Usa la porta 143. Un protocollo per gestire le
e-mail da un server senza rimuoverle, permettendo l’accesso da diversi dispositivi.

2. Registered ports (Porte registrate)

Range: da 1024 a 49151: sono assegnate a protocolli o applicazioni specifiche, ma non sono
riservate come quelle ben note. Sono usate da applicazioni che richiedono porte dedicate,
come i database e i servizi interni.
Esempi di porte registrate:
- 1433 - SQL Server: per la comunicazione tra applicazioni e il database SQL Server.
- 3306 - MySQL: per la comunicazione con il database MySQL.
- 8080 - HTTP alternativo: usato come porta HTTP aggiuntiva, spesso per server di sviluppo
o proxy.
3. Dynamic ports (Porte dinamiche o effimere)
 Range: da 49152 a 65535
Utilizzo: queste porte sono assegnate temporaneamente dal sistema operativo alle
applicazioni durante l’instaurazione di una connessione. Queste porte "effimere" sono
utilizzate solo per la durata della connessione e vengono rilasciate subito dopo.

Analizziamo adesso i protocolli citati:

FTP (File Transfer Protocol) DAL FILE
è usato per trasferire file tra un client e un server su una rete basata su IP, seguendo il modello
Client-Server. Il server FTP è generalmente in ascolto sulla porta 21 TCP e attende connessioni
da parte del client. Una volta connesso, il client invia le credenziali di accesso (username e
password) e, dopo l’autenticazione, può iniziare a inviare comandi e ricevere risposte dal server.
FTP utilizza due connessioni separate per gestire comandi e trasferimenti di dati:
1. Connessione di controllo: Stabilita sulla porta 21, dedicata allo scambio di comandi e
risposte tra client e server. I comandi comuni includono: LIST: elenca i file nella directory
del server. RETR: scarica un file dal server. STOR: carica un file dal client al server.
2. Connessione dati: Questa connessione viene usata per il trasferimento effettivo dei file e si
può stabilire in due modalità operative:
o Modalità Attiva (per il server): Il client comunica al server un numero di porta
locale tramite comandi PORT o EPRT e attende che il server avvii la connessione
dati dalla sua porta 20 verso il client. Questo metodo può creare problemi con i
firewall, poiché è il server ad avviare la connessione dati verso il client.
o Modalità Passiva: Utilizzata per superare le limitazioni dei firewall e del NAT. Il
server comunica al client un numero di porta superiore a 1023 tramite comandi
PASV o EPSV. Il client, quindi, avvia la connessione dati verso quella porta. Questo
approccio facilita la configurazione di rete.
Vulnerabilità di FTP: FTP trasmette le informazioni, incluse le credenziali di accesso, in chiaro.
Questo rende il protocollo vulnerabile agli attacchi di intercettazione. Infatti oggi si preferiscono
versioni sicure come FTPS (FTP over SSL/TLS) e SFTP (SSH File Transfer Protocol)
Esempi di utilizzo di FTP:
 Pubblicazione di siti web: trasferimento di file verso un server web.
 Distribuzione di software: download di file di grandi dimensioni dai server FTP.
 Backup e archiviazione: spostamento di file tra host in ambienti aziendali.

Telnet
è utilizzato per creare una connessione remota con un server o un dispositivo su una rete,
impiegando la porta 23. Esso permette a un client di inviare comandi a un dispositivo remoto e
riceverne le risposte, simulando un'interazione diretta (cioè come se fosse fisicamente di fronte ad
esso). La comunicazione avviene tramite un semplice formato basato su testo, in cui i comandi e le
risposte sono trasmessi come stringhe ASCII.
Uno dei principali problemi di Telnet è la mancanza di crittografia: tutti i dati, incluse le
credenziali (username e password), vengono trasmessi in chiaro. Questo rende Telnet vulnerabile
agli attacchi di tipo man-in-the-middle, in cui un malintenzionato potrebbe intercettare e leggere il
traffico. Per questo motivo, Telnet viene generalmente sostituito da SSH (Secure Shell).
Altro limite: solo con le intestazioni IP (20 byte) e TCP (20 byte), un pacchetto "vuoto" ha già 40
byte di overhead. Questo significa che, se voglio inviare un solo byte di dati (ad esempio, un
singolo carattere), il pacchetto complessivo peserà 41 byte, con 40 byte spesi solo per le
intestazioni. Questo è uno spreco enorme, poiché la maggior parte del pacchetto è occupata da
informazioni di controllo piuttosto che dal contenuto effettivo.
Nonostante i problemi di sicurezza, Telnet è ancora utile in reti chiuse e ambienti controllati per
testare la connettività di rete o per la configurazione di dispositivi su reti locali (come switch e
router) che utilizzano solo Telnet per la gestione e non SSH.

HTTP
HTTP, o Hypertext Transfer Protocol, è un protocollo utilizzato per il trasferimento di pagine web.
Funziona secondo un modello Client-Server, dove il client (solitamente un browser) invia richieste
a un server che ospita le informazioni desiderate. La connessione HTTP è tipicamente stabilita su
una connessione TCP attraverso la porta 80, mentre la versione sicura, HTTPS, usa la porta 443.
Quando un client desidera accedere a una risorsa web, invia una richiesta HTTP al server. Questa
richiesta contiene un metodo, che specifica l'azione da compiere. Una volta ricevuta la richiesta, il
server risponde con una risposta HTTP, che include uno stato (come 200 OK per una richiesta
andata a buon fine) e i dati richiesti.
Un aspetto importante, soprattutto nella sua versione 1.0, è la sua natura stateless**.

Una pagina web è composta da vari oggetti, ciascuno dei quali può risiedere su server diversi. Le
URL forniscono l'indirizzo completo per individuare e accedere a ciascun oggetto. Questo sistema
consente al browser di raccogliere gli elementi da più fonti e visualizzare la pagina in modo
completo per l'utente. La struttura di una URL tipica è simile a questa:
https://www.esempio.com/categoria/immagine.jpg
il server è "www.esempio.com"
/categoria/immagine.jpg: Specifica la posizione esatta dell'oggetto sul server, indicando la
"cartella" e il nome del file tramite percorso

Stateless vs. Stateful **

Stateless (senza stato): ogni richiesta è indipendente e il server non tiene traccia delle interazioni
passate. Ciò significa che ogni volta che il client fa una richiesta, deve fornire tutte le informazioni
necessarie, poiché il server non ha memoria dello stato delle interazioni precedenti.
Ad esempio, se un utente visita una pagina web che richiede di impostare la lingua per una
migliore visualizzazione, il server non ricorda tale preferenza per le richieste successive,
richiedendo all'utente di specificare nuovamente la lingua ogni volta.
Stateful: In un sistema stateful, il server mantiene informazioni sullo stato delle interazioni con i
client. Questo significa che le informazioni delle richieste precedenti possono influenzare come il
server risponde a una nuova richiesta. La comunicazione può avvenire in modo più fluido,
migliorando l'esperienza dell'utente. Alcuni protocolli, come il TCP, (di trasporto) sono considerati
stateful perché mantengono lo stato della connessione durante la comunicazione.

Vediamo le varie differenze tra le versioni di http:

HTTP 1.0: Ogni richiesta e risposta richiede una nuova connessione TCP, cioè chiude la
connessione TCP dopo ogni trasferimento di oggetto, ma una pagina web è composta da molti
oggetti quindi risulta tedioso. Questo può aumentare la latenza, poiché il tempo necessario per
stabilire una nuova connessione si somma al tempo di trasferimento dei dati. Ogni richiesta è
indipendente e il server non mantiene alcuna informazione sullo stato tra le interazioni.
Limitazioni: Mancanza di meccanismi per gestire cache e compressione.

HTTP 1.1: Introduce la persistenza delle connessioni, permettendo di inviare più richieste
attraverso la stessa connessione TCP, riducendo così il tempo di latenza. Rimane stateless, ma
introduce l'uso dei cookies** per mantenere lo stato dell'utente tra le richieste. Supporta il
pipelining (È possibile inviare più richieste in parallelo sulla stessa connessione senza aspettare le
risposte una per una.) e offre migliori meccanismi per la gestione della cache e della compressione
dei dati (come gzip).
Pipelining soffre del "blocco di testa" (head-of-line blocking o HOLblocking): una richiesta lenta
blocca tutte quelle successive.

HTTP 2.0: elimina il problema del blocco del HOLblocking multiplexing.

Supporta la compressione degli header per permettere di aprire delle connessioni parallele. Infatti,
gli oggetti diciamo che vengono divisi in FRAMES e stabiliamo una richiesta per ogni oggetto,
naturalmente quindi quelli che sono più piccoli vengono caricati prima degli altri: riduce la quantità
di dati inviati, migliorando le prestazioni.
Consente la definizione di priorità per le richieste, affinché le risorse più importanti vengano
caricate per prime. Rende la gestione delle connessioni più efficiente e veloce.

HTTP 3.0: HTTP/3 abbandona TCP a favore di QUIC, un protocollo basato su UDP che è più
veloce e resiliente; è un protocollo di trasporto sviluppato da Google e progettato per migliorare la
velocità e l'efficienza della trasmissione dei dati su Internet, specialmente per le applicazioni web.
Elimina il problema del blocco delle richieste di testa e migliora la resilienza alle perdite di
pacchetti, permettendo al protocollo di riprendersi più velocemente. HTTP/3 integra la crittografia
TLS (Transport Layer Security) direttamente nel protocollo, garantendo una connessione più sicura.
QUIC è progettato per essere più resiliente rispetto a TCP, poiché può recuperare più rapidamente
da perdite di pacchetti senza interrompere la connessione, migliorando l'esperienza utente durante il
caricamento delle pagine web.

**COOKIES
I Cookies sono piccoli file di testo che i siti web memorizzano sul dispositivo dell'utente quando
visita una pagina. Servono principalmente a mantenere lo stato della sessione e a personalizzare
l’esperienza di navigazione, rendendo in qualche modo HTTP, che è per natura stateless, un
protocollo parzialmente stateful a livello logico.
Come funzionano? Quando un utente accede a un sito web, il server può assegnargli un ID
unico tramite un cookie. Questo ID viene memorizzato sul dispositivo dell'utente e inviato al server
con ogni richiesta successiva, permettendo al server di identificare l'utente e di mantenere la
continuità della sessione. Ad esempio, se un utente aggiunge articoli al carrello di un negozio
online, i cookie permettono al server di ricordare questi elementi anche quando l'utente naviga tra
diverse pagine del sito.
Il server invia il cookie come parte della risposta HTTP al browser dell'utente. Il browser include il
cookie in ogni richiesta successiva, permettendo al server di identificare l'utente. I cookie sono
memorizzati nel dispositivo dell’utente e sono gestiti dal browser, che li conserva secondo le
impostazioni e le politiche specifiche. Il sito web può conservare le informazioni relative ai cookie
nel proprio database, così da riconoscere e associare correttamente i dati agli utenti.
Classificazione in base alla durata
di sessione: sono temporanei e vengono eliminati quando il browser viene chiuso. Sono usati per
memorizzare informazioni sulla sessione corrente, come gli articoli di un carrello degli acquisti.
persistenti: Rimangono sul dispositivo dell’utente anche dopo la chiusura del browser. Hanno una
data di scadenza e possono essere utilizzati per ricordare informazioni utili nelle visite future,
permettendo ad esempio l’accesso automatico a un sito.
Classificazione in base alla finalità
tecnici: Essenziali per il funzionamento del sito, come la gestione del login o del carrello della
spesa, infatti non chiedono il consenso dell’utente. Se invece di profilazione: Tracciano il
comportamento dell’utente per personalizzare contenuti e pubblicità in base alle preferenze. Ad
esempio, possono registrare le pagine visitate e il tempo trascorso su ciascuna di esse, aiutando gli
inserzionisti a mostrare annunci più mirati.
Sicurezza e Privacy
Poiché i cookie memorizzano informazioni in chiaro, inclusi ID di sessione e preferenze, essi
possono essere utilizzati per tracciare il comportamento degli utenti. Tuttavia, questa caratteristica li
rende vulnerabili a possibili attacchi, come l'intercettazione se la connessione non è sicura. Per
proteggere la privacy, molte versioni aggiornate dei browser richiedono il consenso dell’utente.

HTTP Request e HTTP Response

la richiesta HTTP è un messaggio (stringhe) inviato dal client (browser) al server per ottenere una
risorsa, mentre la risposta HTTP è il messaggio che il server restituisce al client, contenente la
risorsa o un messaggio di errore.
HTTP Request: È composta da: request line, header e body.
Request Line (Riga di richiesta): Questa è la prima riga della richiesta e specifica 3 elementi:
1. Il metodo HTTP utilizzato, come GET, POST, PUT o DELETE, che indica l'azione da
eseguire.
2. L'URL della risorsa richiesta, che può includere query string per fornire parametri
aggiuntivi. (indirizzo dell’oggetto che ci serve)
3. La versione di HTTP utilizzata (ad esempio, HTTP/1.1).
4. Cr e if sono i caratteri che mandano a capo e iniziano una nuova riga.

Un esempio di http request:

Metodi più comuni:

GET: richiede una risorsa dal server. È utilizzato per ottenere dati.
HEAD: richiede solo gli header della risposta senza il body. Serve a ottenere informazioni su una
risorsa senza scaricarne il contenuto.
PUT: aggiorna una risorsa esistente o ne crea una nuova se non è già presente. È idempotent, il che
significa che inviare la stessa richiesta più volte produrrà lo stesso risultato.
POST: invia dati al server, tipicamente per creare o aggiornare una risorsa. I dati vengono inviati
nel body della richiesta. Non è idempotent.
DELETE: richiede la rimozione di una risorsa specificata. È idempotent.
TRACE: permette a un client di inviare una richiesta al server e ricevere indietro esattamente ciò
che ha inviato. È utile per il debug, ma può rappresentare un rischio per la sicurezza.
CONNECT: è utilizzato per creare un tunnel TCP attraverso un proxy, permettendo al client di
comunicare in modo sicuro con un server (di solito per richieste HTTPS). Consente di mantenere la
crittografia durante la trasmissione dei dati.
OPTIONS: utilizzato per descrivere le opzioni di comunicazione per la risorsa di destinazione. Può
essere utilizzato per scoprire quali metodi sono supportati dal server per una specifica risorsa.
HTTP Headers (Header HTTP): Dopo la request line, ci sono vari header che forniscono
informazioni aggiuntive sulla richiesta. Esempi: il tipo di contenuto del body della richiesta, se
presente (ad esempio, application/json per dati JSON).X-Forwarded-For: Utilizzato per
identificare l'indirizzo IP del client, specialmente quando ci sono proxy coinvolti. Accept-
Encoding: Specifica i metodi di compressione supportati dal client, come gzip.

Request Body (Body della richiesta): Questa parte è opzionale e viene utilizzata principalmente
nei metodi che inviano dati al server, come POST o PUT. Ad esempio, in una richiesta di
registrazione, il body potrebbe contenere i dati dell'utente.

HTTP response
Status Line (Riga di stato): La prima riga della risposta che contiene:
1. La versione di HTTP utilizzata.
2. Un codice di stato a tre cifre che indica l'esito della richiesta (ad esempio, 200 per
OK, 404 per Not Found).
3. Un messaggio di stato che descrive il codice (ad esempio, 200 OK).
HTTP Headers (Header HTTP): Questi header forniscono informazioni aggiuntive sulla risposta.
Esempi comuni includono: Content-Type: Indica il tipo di contenuto restituito (text/html per una
pagina web). Date: La data e l'ora in cui è stata generata la risposta. Content-Length: La
dimensione del contenuto restituito in byte.
Response Body (Body della risposta): Questa parte contiene i dati restituiti dal server. Può
includere il contenuto di una pagina web, un file JSON ecc.

Esempio di http response:

I codici di stato HTTP sono divisi in cinque categorie principali:

1. 1xx (Informational): la richiesta è stata ricevuta e che il processo è in corso.
100 Continue: Indica che il client può continuare con la richiesta dopo averlo ricevuto.
2. 2xx (Successful): Indicano che la richiesta è stata ricevuta, compresa e accettata con
successo.
- 200 OK: La richiesta è stata completata con successo e il server restituisce i dati richiesti.
- 203 Non-Authoritative Information: La richiesta è stata elaborata con successo, ma il
contenuto restituito potrebbe non essere completamente affidabile.
- 204 No Content: La richiesta è stata completata con successo, ma non ci sono dati da
restituire.
3. 3xx (Redirection): è necessaria un'ulteriore azione per completare la richiesta.
- 305 Use proxy: la risorsa richiesta deve essere accessibile tramite un proxy specificato.
4. 4xx (Client Error): ci sono stati errori nella richiesta inviata dal client.
- 400 Bad Request: La richiesta non può essere elaborata a causa di una sintassi errata.
- 403 Forbidden: Il server ha rifiutato di elaborare la richiesta a causa di mancanza di
permessi.
- 404 Not Found: La risorsa richiesta non è stata trovata sul server.
 - 405 Method Not Allowed: Il metodo HTTP utilizzato nella richiesta non è supportato per la
risorsa specificata.
5. 5xx (Server Error): il server ha riscontrato un errore o non è in grado di gestire la richiesta.
- 500 Internal Server Error: Si è verificato un errore generico sul server, senza dettagli
specifici.
- 505 HTTP Version not supported: La versione del protocollo HTTP utilizzata nella richiesta
non è supportata dal server.

Lezione 4: livello applicativo - continuo

Proxy server: o web cache è un intermediario che si pone tra i client (browser degli utenti) e i
server (come siti web o risorse online). Il proxy riceve le richieste dei client, le elabora, e le inoltra
ai server principali. Una delle sue principali funzionalità è il web caching: quando un client
richiede una pagina web che non è presente nella cache del proxy, il proxy la inoltra al server
principale come se fosse trasparente, ovvero senza interferire. Il proxy, quindi, scarica la pagina
dal server principale, la consegna al client e la memorizza nella cache. se un altro client (o lo
stesso client in un secondo momento) richiede la stessa pagina, il proxy controlla prima se essa è già
presente nella cache. Se lo è (si verifica un cache hit), il proxy fornisce la pagina direttamente dal
proprio archivio senza richiedere nuovamente il contenuto dal server principale, riducendo così i
tempi di risposta e il carico di rete. Se invece la pagina non è disponibile (cache miss), o se è
scaduta, il proxy deve inviare una nuova richiesta al server per ottenere il contenuto aggiornato.
Per evitare dei dati scaduti nel server proxy usiamo un così detto GET CONDIZIONALE che è un
get che viene mandato dal proxy al server e contiene in pratica la scritta if-modified-since: data.
Così facendo, se il proxy ha una copia scaduta, si fa mandare il file dal server originale.
Vantaggi: il proxy può servire le richieste dei client rapidamente senza dover raggiungere il server
principale ogni volta, alleggerendo il traffico diretto verso i server principali. Minore utilizzo della
larghezza di banda: trasmettendo i dati solo dal proxy, si evita di dover scaricare ripetutamente gli
stessi contenuti, riducendo il traffico complessivo.

Altri usi dei proxy server

Controllo dell'accesso e filtraggio: i proxy possono essere configurati per limitare l'accesso a
determinati contenuti o monitorare le attività degli utenti.
Sicurezza: alcuni proxy migliorano la sicurezza mascherando l’indirizzo IP dei client e fungendo
da barriera contro attacchi esterni.
Annullamento delle restrizioni geografiche: alcuni proxy permettono di accedere a contenuti
bloccati in determinate regioni, inoltrando le richieste da una posizione diversa.

SMTP (Simple Mail Transfer Protocol)  porta 25

Un protocollo di push basato sul modello Client-Server che consente l’invio di Mail da una
macchina all’altra, in modo affidabile, grazie all’uso di TCP.
L'email è un mezzo di comunicazione asincrono, dove mittente e destinatario non devono essere
connessi contemporaneamente. Questo è reso possibile dai mail server intermedi, che
memorizzano i messaggi fino a quando il destinatario li recupera.
Come funziona nel dettaglio:
1. Il mittente usa un user agent per comporre il messaggio e inviarlo (mette indirizzo
del destinatario).
2. Il messaggio viene depositato in una coda sul mail server del mittente.
3. Il mail server mittente (SMTP client) stabilisce una connessione TCP al mail server
del destinatario (SMTP server) e trasferisce il messaggio. SMTP fa uso di
connessioni persistenti: se il mail server di invio ha molti messaggi da inviare allo
stesso mail server in ricezione, può mandarli tutti sulla stessa connessione TCP.
 I due server eseguono un handshaking per identificarsi e autorizzarsi
4.
Il server destinatario deposita il messaggio nella mailbox del destinatario.
5.
Il destinatario può accedere alla sua casella di posta in qualsiasi momento tramite il
6.
suo user agent (tramite protocolli come POP3 o IMAP per leggere i mess).
È importante notare come i mail server comunicano direttamente tra loro senza usare intermedi.
Questo protocollo tratta tutti i messaggi come semplice ASCII a 7 bit, al tempo infatti i messaggi
erano solo testo perché la capacità di trasmissione non era abbastanza forte da trasferire altro.
Come possiamo fare a mandare le immagini per e-mail che manda solo testo (supponiamo solo da
32 a 100 caratteri ASCII)? Supponiamo di avere un’immagine che quindi usa 8 bit, ma noi abbiamo
solo 6 bit. Quello che possiamo fare è leggere solo i primi 6 bit del primo byte e poi leggiamo i
rimanenti 2 insieme ai primi 4 bit del byte successivo e così via. Così facendo se lo diciamo anche
all’altro che legge, riusciamo a mandare un’immagine senza compressione.
Non collochiamo il mail server nel pc dell’utente per varie ragioni, in primis il pc dovrebbe essere
sempre acceso e connesso al server, inoltre non sapremmo come gestire le eccezioni del tipo, cosa
facciamo se mandiamo una mail a qualcosa che non esiste?
Formati dei messaggi di posta
Come facciamo a distinguere l’intestazione dal corpo della mail? Quello che facciamo è introdurre
volontariamente una violazione del protocollo come, ad esempio, un a capo o un punto.
Tutto ciò che appare prima della riga vuota è considerato parte dell'intestazione. Tutto ciò che
appare dopo la riga vuota è considerato corpo del messaggio.
From: [email protected]
To: [email protected]
Subject: Saluti
Date: Mon, 13 Jan 2025 10:30:00 +0000

Ciao Bob,
Come stai? Questo è un messaggio di prova.

SMTP è un protocollo affidabile ma non cifrato. È importante notare che SMTP si occupa solo
dell'invio di e-mail e non della ricezione. Per la ricezione di e-mail, viene invece utilizzato un
protocollo differente, come ad esempio POP3 o IMAP.

POP3 (Post Office Protocol 3) e IMAP (Internet Message Access Protocol) sono entrambi
protocolli utilizzati per la ricezione delle e-mail, ma funzionano in modo diverso.
POP3
è un protocollo di tipo "pull", ovvero il client si connette al server e "tira giù" le e-mail,
scaricandole completamente sul dispositivo locale. Una volta scaricate le e-mail, queste vengono
generalmente rimosse dal server. POP3, quindi, rende il client l’unica posizione in cui i messaggi
restano accessibili. Con POP3, le e-mail scaricate non sono disponibili su altri dispositivi, a meno
che non siano state salvate manualmente su più dispositivi.
In questo modo, POP3 si comporta come un "postino" che raccoglie e consegna le e-mail al
destinatario, rendendo l'accesso alle e-mail disponibile solo sul dispositivo da cui sono state
scaricate.

IMAP
IMAP è un protocollo di posta elettronica basato sul modello Client-Server, che consente ai client di
posta elettronica di selezionare e visualizzare i messaggi di posta elettronica presenti sul server
senza doverli scaricare e archiviare localmente sul dispositivo client.
In sintesi:
POP3 scarica le e-mail e le elimina dal server.
IMAP mantiene le e-mail sul server, sincronizzandole su tutti i dispositivi connessi.
Dominio
Quando ci colleghiamo a un servizio, come la posta elettronica, l’indirizzo e-mail è strutturato come
"nomeutente@dominio". In questa struttura:
 "nomeutente" identifica l’utente specifico.
 "dominio" rappresenta l'insieme di server che gestiscono e forniscono il servizio di posta
per quell’organizzazione.
Questo meccanismo consente di evitare di specificare un server specifico, poiché il dominio
rappresenta un pool di server (macchine equivalenti) che condividono risorse, servizi e regole
comuni, in grado di rispondere a ogni richiesta. Così, se uno dei server ha un guasto, altri server
all'interno del dominio possono subentrare per gestire le richieste, garantendo continuità del servizio
e l’affidabilità dei messaggi.
Blacklist e Sicurezza del Dominio
Le blacklist (liste nere) sono elenchi di mittenti considerati non affidabili o potenzialmente dannosi,
come fonti di spam o contenuti pericolosi. Ogni server può utilizzare una propria blacklist per
filtrare le e-mail indesiderate, evitando che raggiungano gli utenti. L’amministratore di sistema deve
vigilare affinché i propri server non finiscano in queste liste nere, cosa che potrebbe accadere se
venissero usati per inviare spam o altre comunicazioni non sicure.

DNS
Gli host di internet possono essere identificati da un Hostname es www.google.com e da un
Indirizzo IP. Un indirizzo IP consiste in 4 byte e rappresenta una struttura gerarchica
(192.164.54.101). Un DNS ha il compito di trasformare l’Hostname in IP. Il DNS è un database
implementato in una gerarchia di DNS server e un protocollo che gli permette di interrogare il
server. Quello che succede è che la macchina utente esegue il lato client del DNS, il browser estrae
il nome dell’host dall’URL e lo passa al DNS. Il DNS comincia l’interrogazione del DNS server e
prima o poi riceverà una risposta contenente l’indirizzo IP relativo all’hostname. Una volta ottenuto
l’IP possiamo cominciare una connessione TCP con il processo server http relativo all’IP trovato. Il
DNS introduce un ritardo aggiuntivo, talvolta sostanziale, alle applicazioni Internet che lo utilizzano
a causa di questa ricerca ma spesso ciò non accade grazie alla cache del server. Il DNS fornisce
anche:
 Host aliasing: Un host dal nome complicato può avere uno o più alias, ad esempio
relay1.west-coast.enterprise.com potrebbe avere, diciamo, due sinonimi quali enterprise.com
o www.entrprise.com.
 Mail server aliasing: Per ovvi motivi è fortemente auspicabile che gli indirizzi di posta
elettronica siano facili da ricordare. Per esempio, se Bob ha un account Hotmail, il suo
indirizzo di posta elettronica potrebbe essere semplicemente [email protected]. Tuttavia,
l’hostname del server di posta Hotmail è molto più complicato e assai meno facile da
ricordare rispetto a yahoo.com.
 Load distribution: Il DNS viene anche utilizzato per distribuire il carico tra server replicati
in modo da gestire al meglio il carico di utenti e di non avere sovraccarichi del server dato
che spesso un sito ha più server.
Come Funziona il DNS su Internet
Quando un utente inserisce un nome di dominio nel browser, il computer invia una query DNS per
cercare l’indirizzo IP corrispondente a quel nome di dominio. Ecco come funziona il processo:
1. Query iniziale: La richiesta parte dal computer dell'utente e viene inviata a un DNS
Locale (resolver DNS), generalmente gestito dal provider Internet (ISP).
2. DNS Locale (Resolver): Questo server DNS cerca prima nei suoi dati di cache. Se ha già
l'informazione, restituisce subito l’IP. Altrimenti, inoltra la richiesta attraverso la gerarchia
DNS.
 3. DNS Root Server: Se il DNS Locale non trova una risposta, la query arriva ai DNS Root
Server. I Root Server contengono informazioni sui Top-Level Domain
(TLD) come .com, .org, .net, etc. e rispondono indirizzando la query al server DNS che
gestisce il TLD appropriato.
4. Top-Level Domain (TLD) Server: Il server TLD indirizza la query verso il DNS
Autoritativo del dominio richiesto.
5. DNS Autoritativo: Questo server DNS detiene le informazioni ufficiali sui nomi di dominio
specifici. Risponde alla query con l’indirizzo IP associato al dominio, che viene quindi
inviato al resolver DNS e infine al browser dell'utente, permettendo la connessione al sito
web.
La struttura del DNS si può vedere come una gerarchia ad albero che parte dai Root Server e
scende lungo vari livelli, fino a raggiungere i server specifici che contengono i dettagli di un
dominio. Tuttavia, la struttura reale non è un albero perfetto, ma ha anche collegamenti
trasversali che rendono il sistema più simile a un grafo orientato, dove le query possono viaggiare
anche attraverso percorsi alternativi, seguendo cache locali o indirizzamenti veloci, senza risalire
sempre fino ai Root Server.

Ripetiamo come funziona ma con un esempio

Quando si cerca l’indirizzo IP di un dominio completo come www.alfiospoto.unict.it, il processo
avviene leggendo l’indirizzo da destra verso sinistra:
1. Root Server (.): La richiesta parte dal Root Server che gestisce tutti i domini di primo
livello (TLD). La query iniziale identifica .it come TLD, quindi il Root Server risponde
indirizzando il client verso il TLD .it.
2. Top-Level Domain (.it): Il server .it è responsabile di tutti i domini italiani e passa la query
al DNS autoritativo per il dominio unict.it.
3. Dominio Specifico (unict.it): Il server DNS autoritativo di unict.it possiede le informazioni
dettagliate sui sottodomini di unict.it, inclusi www.alfiospoto.unict.it.
4. Sottodominio (www.alfiospoto.unict.it): A questo punto, il server unict.it risponde con
l’indirizzo IP specifico per www.alfiospoto.unict.it, permettendo così al client di stabilire la
connessione diretta.
Per evitare che ogni richiesta parta sempre dal Root Server, DNS locali e intermedi mantengono
una cache temporanea delle risposte. Questo caching crea, di fatto, collegamenti trasversali:
Se un server DNS locale ha già risolto di recente un indirizzo per www.unict.it, può rispondere
immediatamente senza dover attraversare l'intera gerarchia. Se una coppia hostname/indirizzo IP è
nella cache di un DNS server e giunge al server un’altra richiesta con lo stesso hostname, il DNS
server può fornire l’indirizzo IP desiderato, anche se non è autoritativo per tale indirizzo (queste
info scadono ogni 2 giorni).
Un sistema di Server DNS è organizzato per bilanciare il carico di richieste e assicurare una risposta
affidabile e veloce agli utenti.
Struttura del Sistema DNS
1. DNS Primario: È il server principale che contiene i dati ufficiali e completi relativi ai
domini associati. Gestisce tutte le modifiche e aggiornamenti ai dati dei domini, rispondendo
in modo autoritative (cioè con l'autorità di rispondere direttamente alle query sul dominio).
2. DNS Secondari: Sono repliche del DNS primario, e periodicamente aggiornano le loro
informazioni attraverso un processo di sincronizzazione. Consentono di distribuire il traffico
di richieste su più server, riducendo il carico sul DNS primario e fornendo una soluzione di
backup in caso di problemi al primario. Le loro risposte sono anch'esse autoritative, ma
ricevono le informazioni direttamente dal DNS primario.
Quindi questa gerarchia di DNS viene interrogata e si va da uno strato all’altro tramite le
informazioni varie ricevute. Abbiamo due modalità di ricerca che sono le query ricorsive: Il server
DNS locale si occupa di ottenere una risposta completa per l'utente, consultando altri server se
necessario e query Iterative: Il server DNS locale indirizza il client verso altri server DNS per
ottenere la risposta finale, senza cercare la risposta completa da solo.
Tipi di Query DNS
1. Query Autoritative: Derivano direttamente dal DNS primario o secondari. Rispondono con
informazioni accurate e ufficiali sui domini, poiché provengono dai server responsabili del
dominio in questione.
2. Query Non Autoritative: Sono risposte fornite tramite il meccanismo di caching. Un server
DNS locale può salvare temporaneamente le risposte precedenti per rispondere più
velocemente a richieste simili, senza dover consultare il DNS autoritativo ogni volta.

I provider di servizi Internet (ISP) possono modificare dinamicamente l'indirizzo IP dei clienti per
evitare che questi impostino facilmente un server pubblico (pratica spesso non consentita ai privati
senza autorizzazione specifica). Servizi di DNS dinamico permettono agli utenti di aggiornare
automaticamente la coppia client-IP tramite un login. Ad esempio, un dispositivo con IP dinamico
può mantenere l’associazione a un nome di dominio aggiornato in tempo reale. Un’alternativa per
mantenere accesso costante, sebbene con IP dinamico, è l’utilizzo di un dispositivo (come un router
o un firmware) che si colleghi regolarmente a un server web esterno con un IP fisso. Questo server
centrale può ricevere informazioni dal dispositivo e renderle disponibili ad altri utenti, mantenendo
un punto di contatto stabile e fisso.

Un record DNS è strutturato così: RR format (nome, valore, tipo, ttl)

1. Nome: nome del dominio per cui si sta effettuando la registrazione (es. www.example.com).
2. Valore: valore associato al record, che varia in base al tipo di record (es. per un record A
sarà un indirizzo IPv4 tipo 192.168.1.1, per un record MX sarà il nome del server di posta).
3. Tipo: tipo di associazione che il record rappresenta. Tra i più comuni:
- A  associa un dominio ad un indirizzo IPv4
- AAAA  associa un dominio ad un indirizzo IPv6
- CNAME  è un alias che associa un dominio a un altro dominio (utile per ridirigere).
- NS  indica i nameserver autorizzati a gestire il dominio.
- MX  specifica il server di posta per il dominio.
 4. TTL (Time to Live): il tempo, in secondi, che il record sarà memorizzato nella cache dei
server DNS locali. Un valore TTL più alto riduce la frequenza degli aggiornamenti, mentre
un valore basso garantisce aggiornamenti più frequenti.

SNMP
l Simple Network Management Protocol (SNMP) è un protocollo progettato per monitorare e
gestire dispositivi su una rete (come router, switch, server e stampanti) da un'unica postazione
centrale. SNMP consente agli amministratori di rete di raccogliere informazioni sulle prestazioni
della rete, monitorare eventuali problemi e configurare dispositivi in remoto (quindi eventualmente
eseguire dei comandi su di essi).
L’Agente SNMP è un software che gira su ciascun dispositivo di rete gestito e ha i permessi di
amministrazione per accedere a dati specifici del sistema operativo e dell’hardware. L’agente
raccoglie e gestisce i dati riguardanti lo stato e le prestazioni del dispositivo. I dati raccolti sono
organizzati all'interno di una struttura ad albero chiamata Management Information Base (MIB),
che agisce come un database standardizzato per l’organizzazione delle informazioni. Ogni dato nel
MIB è rappresentato da un identificatore univoco chiamato OID (Object Identifier) che ne specifica
la posizione all’interno della struttura ad albero.
Tre Versioni di SNMP: La prima versione, semplice ma con scarsa sicurezza, permette la gestione
di base tramite semplici comandi. SNMPv2: Introdotta con alcune migliorie di performance e
funzionalità, ma ancora limitata in termini di sicurezza. SNMPv3: La versione più recente, che
include miglioramenti significativi sulla sicurezza, come autenticazione e crittografia, per evitare
accessi non autorizzati.
Modalità Operative:
Polling: Il gestore (manager) invia periodicamente query agli agenti per aggiornare i dati. (GET o
SET)
Traps: Gli agenti inviano notifiche al gestore SNMP per segnalare eventi importanti.
Lezione 5: livello di trasporto
Un protocollo a livello di trasporto mette a disposizione una comunicazione logica tra processi
applicativi di host differenti, senza preoccuparsi dei dettagli dell’infrastruttura fisica utilizzata per
trasportarli. Per comunicazione logica si intende, dal punto di vista dell’applicazione, che tutto
proceda come se gli host che eseguono i processi fossero direttamente connessi; in realtà, non deve
essere necessariamente così. Il termine end-to-end indica che i protocolli di trasporto gestiscono la
comunicazione direttamente tra i host finali, senza che dispositivi intermedi (come router)
intervengano nel processo di trasferimento dei dati. Grazie ai suoi meccanismi di controllo del
flusso e di controllo della congestione, TCP garantisce una trasmissione affidabile e ordinata dei
dati su una rete IP. Tuttavia, in alcune situazioni, come quelle in cui è necessaria una bassa latenza,
UDP può essere preferibile per la sua maggiore leggerezza e velocità.

Ruolo del livello di trasporto rispetto ad altri livelli

 Livello data link: si occupa della comunicazione fisica tra dispositivi direttamente collegati
(ad esempio, tra un computer e il router).
 Livello di rete: gestisce la comunicazione logica tra host su una rete (per esempio, tra due
computer in due reti diverse).
 Livello di trasporto: gestisce la comunicazione logica tra processi in esecuzione su host
diversi.

Internet, e più in generale una rete TCP/IP, mette a disposizione del livello di applicazione due
diversi protocolli. Ricordiamo, che la letteratura su Internet definisce segmento un pacchetto a
livello di trasporto per TCP, ma molte volte definisce datagramma un pacchetto per UDP.

Multiplexing e demultiplexing: capitolo precedente

UDP
UDP, o User Datagram Protocol (definito in RFC 768), è un protocollo di trasporto non orientato
alla connessione, il che significa che non stabilisce una connessione formale tra mittente e
destinatario prima di inviare i dati. A differenza di TCP, UDP non utilizza una procedura di
"handshake" per iniziare la comunicazione, quindi non c'è nessuna negoziazione o controllo iniziale
tra gli host comunicanti.
Essendo un protocollo inaffidabile, UDP invia i dati sotto forma di segmenti, che possono essere
trasmessi senza alcuna garanzia di consegna o di ordine. In altre parole, i datagrammi UDP possono
essere persi, duplicati o arrivare fuori sequenza senza che il protocollo intervenga per correggere la
situazione. Inoltre, non essendoci meccanismi di controllo della congestione, UDP può inviare
pacchetti a una velocità elevata rispetto a TCP, senza considerare il carico della rete.
UDP è ideale per applicazioni che per le quali la priorità è mantenere una comunicazione fluida;
quindi, si tollera la perdita di alcuni pacchetti; in generale è ideale per applicazioni loss-tollerant
cioè che riescono ad ammettere inaffidabilità̀ nella trasmissione di dati. (DNS, SNMP, http/3)

Struttura di un segmento UDP (anche detto Datagramma)

Un datagramma UDP è costituito da due sezioni principali: l'header e i dati (payload) da
trasmettere. L’header di UDP contiene solo quattro campi di 2 byte ciascuno, per un totale di 8
byte:
1. Porta di origine: del pacchetto UDP, permettendo al destinatario di rispondere all'indirizzo
corretto.
2. Porta di destinazione: assicura che i dati siano consegnati all'applicazione corretta sul
dispositivo ricevente.
3. Lunghezza: lunghezza totale del datagramma UDP, espressa in byte e includendo sia header
che payload. Serve a delimitare il datagramma e a garantire che venga letto correttamente.
4. Checksum: un valore di controllo di 2 byte, calcolato sull'intero datagramma (header e
payload) per verificare l'integrità dei dati trasmessi.

Checksum: rilevamento degli errori

Prima di tutto ci si potrebbe chiedere perché UDP metta a disposizione un checksum, dato che
anche molti protocolli a livello di collegamento (tra cui Ethernet) prevedono il controllo degli
errori. Il motivo è che non c’è garanzia che tutti i collegamenti tra origine e destinazione controllino
gli errori. Inoltre, anche se i segmenti fossero trasferiti correttamente lungo un collegamento, si
potrebbe verificare un errore mentre il segmento si trova nella memoria di un router.
Tuttavia, il checksum è una verifica relativamente semplice e, in alcuni casi, gli host possono
scegliere di ignorarlo); quindi serve principalmente a filtrare i pacchetti sicuramente corrotti, ma
non assicura l’integrità totale del messaggio.
Come si calcola? Lato mittente UDP effettua il complemento a 1 della somma delle 3 parole da 2
byte (16 bit) nel segmento, e l’eventuale riporto finale viene sommato al primo bit. Tale risultato
viene posto nel campo Checksum del segmento UDP. In ricezione, si sommano le tre parole iniziali
e il checksum. Se non ci sono errori nel pacchetto, l’addizione darà 1111111111111111, altrimenti
se un bit vale 0 sappiamo che è stato introdotto almeno un errore nel pacchetto.
Nonostante questo, UDP può comunque essere utile in certe situazioni:
- Controllo più preciso a livello di applicazione su quali dati sono inviati e quando. Non
appena un processo applicativo passa dei dati a UDP, quest’ultimo li impacchetta in un
segmento che trasferisce immediatamente al livello di rete. Dunque, è comodo per le app
real-time.
- Non è necessario stabilire una connessione. UDP “spara” dati a raffica senza alcun
preliminare formale a differenza di TCP che effettua prima handshake.
- Non è necessario mantenere uno stato della connessione. TCP mantiene lo stato della
connessione nei sistemi periferici. Questo stato include buffer di ricezione e di invio,
parametri per il controllo di congestione e parametri sul numero di sequenza e di ACK.
- Minor spazio usato per l’intestazione del pacchetto. L’intestazione dei pacchetti TCP
aggiunge 20 byte, mentre UDP solo 8.

Principi di trasferimento affidabile dei dati

Il nostro obiettivo nella comunicazione è ottenere una trasmissione perfetta e affidabile, anche se
nella realtà è molto difficile raggiungere questa perfezione. Tuttavia, possiamo gradualmente
costruire un sistema sempre più affidabile. Per farlo, utilizziamo i concetti di sistemi RDT (Reliable
Data Transfer), che, pur non esistendo fisicamente, forniscono un modello utile per comprendere
come si sia arrivati allo sviluppo di TCP.
Il protocollo TCP è in grado di offrire un servizio affidabile alle applicazioni. Tuttavia, TCP si
appoggia a un livello sottostante, l’IP, che di per sé non è affidabile. Questo pone una sfida
interessante: come può un protocollo garantire l'affidabilità se il livello su cui si basa non lo è?

Costruzione di un protocollo di trasferimento dati affidabile

Il protocollo RDT può essere rappresentato tramite automi a stati finiti, in cui ciascuno stato
rappresenta una fase specifica della comunicazione.
Ogni stato è governato da variabili di stato che monitorano il numero di pacchetto corrente, la
presenza di ACK, e altre informazioni. Vediamo come funziona. (in particolare, andiamo a trattare
meccanismi di checksum, ACK, NACK, numero di sequenza, timer, finestra e pipelining).

RDT 1.0 macchina a stati finiti banale

Immaginiamo una macchina a un solo stato (ritorna su sé stessa). Questa prima versione del
protocollo assume che il canale di comunicazione sottostante sia perfetto e affidabile. Dato che
non ci sono errori o perdite di pacchetti, il mittente può semplicemente inviare i dati e il destinatario
può riceverli senza alcuna conferma o meccanismo di controllo. È un caso teorico, adatto a reti
senza possibilità di errori, quindi molto semplice ma irrealistico in contesti reali.

RDT 2.0 errori nel mandare pacchetti dal sender

Ora immaginiamo una macchina con 2 stati differenti. Con RDT 2.0, ci spostiamo in un ambiente in
cui i pacchetti possono arrivare corrotti. Per rilevare errori, il protocollo utilizza un checksum,
un valore calcolato sui dati del pacchetto e incluso nel pacchetto stesso. Il destinatario può
verificare l'integrità dei dati ricevuti confrontando il checksum calcolato con quello inviato.
Il mittente invia i dati e attende un ACK (conferma) o un NAK (notifica di errore) dal destinatario.
Questo meccanismo è noto come stop-and-wait: il mittente invia un pacchetto e aspetta una
risposta prima di inviarne un altro. In caso di NAK, il pacchetto viene ritrasmesso. Il protocollo
sembrerebbe funzionare ma, sfortunatamente, presenta un grave difetto; infatti, non abbiamo tenuto
conto della possibilità che i pacchetti ACK o NAK possano a loro volta essere danneggiati, per cui
il mittente deve trattare l'evento come se il pacchetto fosse stato perso, introducendo il rischio di
duplicazione di pacchetti.

RDT 2.1 errori sia dal sender che dal receiver

In questa versione, per gestire il problema dei pacchetti duplicati, si introduce un numero di
sequenza (con due stati: 0 o 1). Ogni pacchetto viene etichettato con questo numero, e il mittente e
il destinatario verificano se il numero di sequenza corrisponde all'atteso. Questo approccio permette
al destinatario di distinguere un pacchetto nuovo da una ritrasmissione di un pacchetto già ricevuto.

RDT 2.2
RDT 2.2 elimina l’uso del NAK, riducendo la complessità: quando il destinatario rileva un
pacchetto danneggiato o fuori sequenza, invia semplicemente un ACK duplicato riferito all'ultimo
pacchetto valido ricevuto. Il mittente interpreta due ACK identici come segnale che il destinatario
non ha ricevuto correttamente il pacchetto successivo, e provvede a ritrasmetterlo.

RDT 3.0 presenza di packet loss

Supponiamo ora che il canale di trasmissione, oltre a danneggiare i bit, possa anche presentare un
altro problema: la possibilità che i pacchetti vadano persi. Per risolvere questo problema,
introduce un time-out di ritrasmissione (Retransmission Time-out, RTO): se il mittente non
riceve un ACK entro un certo intervallo di tempo, ritrasmette il pacchetto. Implementare un
meccanismo di ritrasmissione basato sul tempo richiede un contatore (countdown timer) in grado di
segnalare al mittente l’avvenuta scadenza di un dato lasso di tempo. Il mittente dovrà quindi
essere in grado (1) di inizializzare il contatore ogni volta che invia un pacchetto (che si tratti del
primo invio o di una ritrasmissione), (2) di rispondere a un interrupt generato dal timer con l’azione
appropriata e (3) di fermare il contatore. Tuttavia, ciò introduce nuovi problemi legati alla gestione
del time-out e dei valori di RTO, poiché impostare un valore di time-out troppo basso o troppo alto
può compromettere le prestazioni.
Per ottimizzare l’RTO, sono state identificate le seguenti problematiche:
1. Il tempo di viaggio dei pacchetti non è costante: i pacchetti possono seguire percorsi
diversi, con tempi di trasmissione variabili, per cui il time-out deve essere adattivo, non
fisso. In caso contrario, un time-out troppo basso causerà ritrasmissioni inutili, mentre uno
troppo alto aumenterà il ritardo nei dati. (figura d)
2. Si necessita di limitare le ritrasmissioni: se un pacchetto viene perso ripetutamente, RDT
deve evitare di ritrasmetterlo in loop. Alcune implementazioni inseriscono un numero
massimo di tentativi di ritrasmissione, dopo il quale si solleva un’eccezione.
3. Si necessita di aumentare i bit usati per l’identificazione del pacchetto: per evitare di
confondere la risposta ad un pacchetto recente con quella di un pacchetto con lo stesso
identificativo ma inviato precedentemente. (figura d)
Guardiamo due esempi di problemi che potrebbero verificarsi:

Figura C: abbiamo la situazione in cui perdiamo un ACK e dunque, scaduto il timer, il sender
reinvia il messaggio e il receiver, notando che è un duplicato lo ignora e reinvia ACK.
Figura D: Qui invece abbiamo ancora un altro problema che è causato dal fatto che i pacchetti non
viaggiano sempre alla stessa velocità e possono dunque succedere che un ACK è riferito ad un
pacchetto diverso da quello a cui si riferisce il programma.

Errore dal canale Errore dal canale del ACK/ NACK Pacchetti persi
del sender reciever
RDT 1.0 no no - no
RDT 2.0 si no ACK/ NACK no
RDT 2.1 si si ACK/ NACK no
RDT 2.2 si si ACK no
RDT 3.0 si si ACK si

Il throughput (cioè la quantità di dati trasmessi per unità di tempo) nello stop-and-wait, è limitato
perché il mittente deve attendere l’ACK di ogni pacchetto prima di inviarne un altro. Questo crea
molti tempi morti, soprattutto per connessioni a lunga distanza, e impedisce di sfruttare appieno la
banda disponibile. Questo processo implica che, per ogni pacchetto trasmesso, ci sia un ritardo
totale definito da vari elementi del viaggio e dell’elaborazione, che possiamo esprimere con la
formula seguente: (indica il tempo totale di trasmissione per un singolo pacchetto)

Tt = Tframe+ RTT + Telaboration + Tack

Vediamo cosa rappresenta ciascun termine:
Tframe: questo è il tempo necessario per trasmettere un frame di dati dal mittente al destinatario.
Dipende dalla dimensione del pacchetto e dalla larghezza di banda del canale. Più è grande il
pacchetto o più lenta la connessione, maggiore sarà il Tframe
RTT (Round Trip Time): Include sia il tempo di andata del pacchetto sia il tempo di ritorno del
segmento di ack, e può variare a causa di vari fattori, come la congestione di rete o la distanza fisica
tra i due nodi.
Telaboration: questo è il tempo impiegato dal destinatario per elaborare il pacchetto. Include attività
come: la decodifica del pacchetto, la verifica della presenza di eventuali errori,
la preparazione di un riscontro (ACK o eventualmente NAK, se si rileva un errore).
Questo tempo può dipendere dalla capacità del destinatario di elaborare rapidamente i pacchetti;
quindi, una macchina più veloce potrebbe avere un Telaboration più basso.
Tack: è il tempo necessario per trasmettere l’ACK dal destinatario al mittente. Questa trasmissione è
generalmente più veloce, perché un ACK è molto più piccolo rispetto a un pacchetto dati.

Per aumentare l’efficienza e migliorare il throughput, si introduce il pipelining, un approccio che

permette al mittente di inviare più pacchetti consecutivi senza attendere un ACK per ciascuno.
Pipelining
Inseriamo nel canale, pacchetti uno di seguito all’altro. Questo è possibile quando il canale è lungo
e la frame è piccola rispetto al canale.
Nel pipelining, il mittente può inviare un certo numero di pacchetti (detti finestra di trasmissione)
senza attendere un riscontro per ciascuno di essi. Questo significa che il mittente può inviare, ad
esempio, 3 pacchetti prima di dover ricevere un ACK. Durante questo periodo, i pacchetti sono in
transito, e il canale è meglio sfruttato, riducendo i tempi morti. L’aumento della finestra di
trasmissione porta a un miglioramento del throughput, dato che più pacchetti occupano il canale
contemporaneamente. Questo approccio però introduce nuove sfide: come gestire i pacchetti persi o
corrotti. È qui che entrano in gioco i protocolli Go-Back-N e Ripetizione Selettiva.

Go-Back-N
Il mittente può trasmettere più pacchetti senza dover attendere gli ACK ma non può aver mandato
più di N pacchetti senza che questi abbiano ricevuto un ACK. Questo numero N viene definito
come finestra di trasmissione.
Ogni pacchetto inviato viene numerato sequenzialmente, e il destinatario invia un ACK cumulativo
che indica l’ultimo pacchetto ricevuto correttamente. Ad esempio, se il mittente invia i pacchetti 0,
1, 2 e 3, ma il pacchetto 2 viene perso, il destinatario invierà un ACK per il pacchetto 1 e scarterà
tutti quelli successivi. Il mittente, scaduto il timer, alla ricezione di questo ACK, sa che deve
riprendere da 2 e ritrasmettere il pacchetto 2 e tutti quelli successivi (3 e oltre). Questo richiede
meno buffer (memoria) sul destinatario, perché gestisce solo i pacchetti in ordine e usa un singolo
timer per tutta la finestra, semplificando il controllo.
Presenta l’inconveniente che tutti i pacchetti dopo il primo perso devono essere ritrasmessi, anche
se alcuni di essi sono stati ricevuti correttamente. Questo può portare a un uso inefficiente della
larghezza di banda, specialmente in caso di perdite frequenti.
Quelli gialli sono i pacchetti mandati e non confermati, quelli verdi sono quelli confermati (quindi
non si considerano) e quelli blu sono quelli che potrei ancora spedire.
Ripetizione Selettiva (Selective Repeat)
Il Selective Repeat è progettato per migliorare l’efficienza rispetto al Go-Back-N, permettendo di
gestire i pacchetti ricevuti fuori ordine e ritrasmettendo solo quelli che sono stati persi o
danneggiati. Il mittente mantiene una finestra di trasmissione che rappresenta i pacchetti che può
trasmettere senza aspettare ACK. Il destinatario ha una finestra di ricezione che rappresenta i
pacchetti che può accettare, anche se non sono nell’ordine giusto. Se un pacchetto arriva
correttamente (anche fuori ordine), il destinatario lo memorizza in un buffer. Se un pacchetto è
perso o danneggiato, il destinatario segnala solo quel pacchetto specifico come mancante (ad
esempio con un NACK o tramite numeri di ACK). Il mittente ritrasmette solo il pacchetto perso o
danneggiato, senza dover ritrasmettere tutti i pacchetti successivi come accade nel Go-Back-N.
Una volta ricevuti tutti i pacchetti mancanti, il destinatario ricostruisce i dati nell’ordine corretto
utilizzando il buffer.

Sintesi
In sintesi, il pipelining, attraverso i protocolli Go-Back-N e Ripetizione Selettiva, consente di
superare le inefficienze del metodo stop-and-wait. Se io perdo tanti pacchetti assieme, go back N
conviene perché si aspetta un solo timer. Mentre la ripetizione selettiva fa perdere molto più tempo.
Dipende dunque tutto da quanti pacchetti perdo e da come li perdo.
In generale per quanto riguarda i pacchetti che arrivano in maniera disordinata, il protocollo lascia
tutto nelle mani di chi l’ha implemento, senza dare particolari indicazioni. Di fatto, abbiamo
principalmente due approcci: il primo consiste nel buttare tutti i pacchetti arrivati in maniera
disordinata, mentre il secondo consiste nel mantenere in un buffer i pacchetti non arrivati in ordine
e quindi reinserirli una volta arrivati i pacchetti che mancano.

Definiamo inoltre come Error rate del canale il numero di bit errati per ogni tot. Per la fibra ottica
è 1 bit errato ogni 10^14.

TCP IPv4
TCP è un protocollo a livello di trasporto che offre alle applicazioni, un servizio di comunicazione
affidabile e orientato alla connessione (perché prima di scambiare dati, TCP stabilisce un
collegamento attraverso un processo noto come handshake a tre vie (three-way handshake)).
Questo processo coinvolge l'invio di pacchetti SYN e ACK per sincronizzare i numeri di sequenza
tra mittente e destinatario, assicurando che entrambi siano pronti a comunicare. La “connessione”
TCP non è un circuito fisico TDM o FDM, come in una rete a commutazione di circuito, in quanto
lo stato della connessione risiede completamente nei due sistemi periferici. Nel modello end-to-end,
la comunicazione avviene esclusivamente tra i due host finali, senza che i router intermedi
partecipino alla gestione della connessione. Ciò significa che TCP si occupa della gestione della
comunicazione, mentre i router si limitano a inoltrare i pacchetti, senza alcuna consapevolezza della
connessione TCP stessa (vedono solo datagrammi non connessioni). TCP offre una connessione di
tipo full-duplex in quanto i dati possono fluire da mittente a destinatario e viceversa. TCP sfrutta
l’architettura peer-to-peer. Una connessione TCP è anche punto a punto, ossia ha luogo tra un
singolo mittente e un singolo destinatario. (il Multicast non è ottenibile)
L’MSS, o Maximum Segment Size, definisce la quantità massima di dati (payload) che può essere
inserita in un segmento TCP. L’Header TCP ha dimensione fissa di 20 byte.
Per garantire che il segmento TCP possa essere trasmesso senza frammentazione, la somma
dell'MSS e della dimensione dell’header deve essere inferiore al Maximum Transmission Unit
(MTU). Se un segmento TCP supera l'MTU, il pacchetto sarà frammentato, il che può comportare
inefficienze e complicazioni nel processo di riassemblaggio dei pacchetti al destinatario.
Struttura di un pacchetto TCP
Un segmento TCP è composto da un header e da un payload.

Struttura dell'Header TCP (20 byte):

1. Porta di origine (2 byte): consente al destinatario di sapere quale applicazione riceverà i
dati.
2. Porta di destinazione (2 byte): specifica l'applicazione sulla quale i dati devono essere
consegnati.
3. Numero di sequenza (4 byte): Contiene il numero di sequenza del primo byte di dati nel
segmento. Permette l’affidabilità.
4. Numero di conferma (ACK)(4 byte): Specifica il numero di sequenza del prossimo byte di
dati che il mittente si aspetta di ricevere dal destinatario. Permette l’affidabilità.
5. Lunghezza dell'header (4 bit): Indica la lunghezza dell'header TCP in parole da 4 byte.
Questo campo permette di determinare dove inizia il payload nel segmento, poiché l'header
può variare in lunghezza se vengono utilizzate opzioni aggiuntive.
6. Window size (2 byte): utilizzata per il controllo del flusso. Rappresenta il numero di byte
che il mittente può accettare dal destinatario senza dover ricevere un ACK.
7. Checksum (2 byte): per rilevare errori nei dati trasmessi. viene calcolato sull'intero
segmento, inclusi sia l'header che il payload.
8. Puntatore di urgente (2 byte): Flag come RST, SYN e FIN che servono per impostare e
chiudere la connessione. I bit CWR e ECE che sono utilizzati nel controllo della congestione
esplicito, il PSH che se ha valore 1 indica che il destinatario dovrebbe inviare subito i dati al
livello superiore e infine URG che indica che nel pacchetto sono presenti dati che sono
ritenuti urgenti.
9. Opzioni (variabile): Permette di includere opzioni aggiuntive nel segmento TCP, come
l’MSS o altre opzioni per la gestione della connessione. Questo campo è facoltativo e la sua
lunghezza varia a seconda delle opzioni utilizzate.

Il numero di sequenza per un segmento è il numero nel flusso di byte del primo byte del segmento.
Per esempio, se A vuole inviare a B in una connessione TCP 500.000 byte con un MSS di 1000
byte, allora troveremo che il numero di sequenza nel primo segmento è 0, poi 1000, poi 2000 ecc.
fino ad arrivare a 500.000.
Invece il numero di conferma corrisponde al numero di sequenze del byte successivo che la
macchina attende dall’altra. Quindi se ad esempio a B è arrivato il primo segmento con numero di
sequenza 1000, questo manderà un ACK con numero 1001 per confermare che ha ricevuto tutti i
pacchetti fino al 1000 e che adesso attende il 1001. Ricordiamo che TCP utilizza ACK
CUMULATIVI, dunque mandare un ACK 1000 conferma tutti i pacchetti con numero precedente.
Questa strategia ha diversi vantaggi: 1. Riduce il numero di pacchetti di ACK inviati sulla rete,
minimizzando il sovraccarico. 2. Facilita la gestione delle ritrasmissioni di pacchetti persi, in quanto
il mittente può determinare facilmente quale pacchetto deve essere inviato nuovamente in base
all'ACK ricevuto.
Piggybacking: inviare ACK insieme ai dati
Nella comunicazione TELNET, spesso succede che un ACK non venga inviato come pacchetto
separato, ma sia "accompagnato" da dati che devono essere trasmessi nella stessa direzione. Questo
processo è chiamato piggybacking, che possiamo tradurre in italiano come "A cavallo di". Quando
una macchina deve inviare un ACK (per confermare la ricezione di un pacchetto), invece di
mandarlo subito, aspetta di avere dei dati da inviare nella stessa direzione.
L’ACK viene "incluso" nel pacchetto con i dati, riducendo il numero totale di pacchetti trasmessi.
Mi serve un modo per capire quanto tempo aspettare prima che l’host B mandi un pacchetto e
questo voglio ritardarlo il più possibile perché voglio che B abbia comunque qualcosa da mandare,
ma non troppo perché altrimenti rischio che scada il timer dell’altra macchina.

Time-out TCP
TCP usa un timer per far fronte alla possibile perdita di pacchetti.
Se il mittente non riceve un ACK entro il tempo di time-out, assume che il pacchetto sia stato perso
e attiva il meccanismo di ritrasmissione. Questo meccanismo è essenziale per mantenere la
comunicazione fluida e garantire che i dati vengano effettivamente consegnati.

La misurazione accurata del RTT (round trip time) è cruciale per determinare un time-out
appropriato. Abbiamo però un problema, noi l’RTT, quindi tempo di andata e ritorno non lo
conosciamo a prescindere e anche se lo conoscessimo, non sarebbe comunque sempre lo stesso
perché non sempre abbiamo lo stesso traffico nella rete. Serve dunque fare una media tramite il
Sample RTT.

Media Ponderata EWMA (Exponentially Weighted Moving Average)

Per calcolare l’RTT, TCP utilizza la tecnica della media mobile ponderata esponenzialmente, che
consente di adattarsi rapidamente alle variazioni nei tempi di risposta. È esponenziale perché più
passa il tempo e più pesiamo i valori ed è mobile perché diciamo che questa finestra di tempo la
andiamo sempre spostando via via che passa il tempo.
La formula per il calcolo dell'RTT utilizzando l'algoritmo EWMA è la seguente:
RTT = (1 −α) ⋅ RTT + α ⋅ SampleRTT

In questa formula:
 RTT è il valore attuale del Round Trip Time calcolato. (è Estimated_RTT che mi servirà
dopo)
 SampleRTT è il tempo effettivo impiegato per ricevere l'ACK del pacchetto più recente.
 α è un fattore di peso, comunemente impostato a 0.125 (o 1/8), che determina quanto peso
assegnare al valore campionato più recente (SampleRTT) rispetto alla media storica (RTT).
Il fattore α consente di dare più peso ai tempi recenti, rendendo il calcolo più sensibile ai
cambiamenti.
L’EMWA non basta da sola però, abbiamo bisogno anche della deviazione standard perché i valori
possono variare molto tra l’uno e l’altro.
DevRTT
La DevRTT misura la variazione del RTT, fornendo una stima della sua instabilità. A differenza
dell'EWMA, che calcola una media del RTT, la DevRTT tiene conto delle fluttuazioni del RTT
stesso. Questo è particolarmente utile in reti con condizioni variabili, dove i tempi di risposta
possono cambiare a causa di congestioni o variazioni nella latenza.
La formula per calcolare la DevRTT utilizzando l'algoritmo EWMA è la seguente:

DevRTT=(1−β) ⋅ DevRTT_precedente + β ⋅ ∣ RTT − Estimated_RTT ∣

In questa formula:
 DevRTT è il valore attuale della deviazione media ponderata del RTT.
 DevRTT_precedente è il valore calcolato di DevRTT al momento precedente.
 β è un parametro di smoothing, solitamente impostato a 0.25 (o 1/4), che determina il peso
relativo dei valori passati rispetto a quelli presenti nel calcolo della media mobile.
 RTT è il valore reale dell’RTT cioè il tempo impiegato per inviare un pacchetto di dati e
ricevere la risposta.
 Estimated_RTT è la stima dell’RTT calcolato precedentemente con la media ponderata.

Una volta che la DevRTT è stata calcolata, viene utilizzata per determinare il valore del RTO
secondo la seguente formula:

RTO = Estimated_RTT + 4 ⋅ DevRTT

In questo contesto:
 RTO rappresenta il tempo massimo di attesa per una risposta prima di considerare un
pacchetto come perso.
 Estimated_RTT è la stima attuale del RTT, calcolata in precedenza con la EWMA.
 DevRTT è la deviazione calcolata, moltiplicata per 4 per fornire un'ampiezza di banda di
sicurezza, riducendo il rischio di ritrasmissioni non necessarie.

In questo modo, RTO viene impostato in modo che la probabilità di perdere un pacchetto sia
inferiore all’1%.
Implicazioni Pratiche
Un RTO troppo breve può portare a ritrasmissioni eccessive, mentre un RTO troppo lungo può
causare ritardi nella correzione degli errori, portando a una scarsa esperienza utente. Pertanto, un
corretto bilanciamento tra i valori di RTT e DevRTT è essenziale per ottimizzare la comunicazione
attraverso la rete.
Fast Retransmit

Come possiamo vedere da questo grafico, spesso andiamo ad esagerare anche di molto l’RTO
(timer) nel TCP; tuttavia, per compensare a questo scompenso andiamo ad utilizzare la
Ritrasmissione rapida. Quando il mittente riceve tre ACK duplicati, considera che il pacchetto a cui
si riferisce l'ACK duplicato sia andato perso e procede a ritrasmetterlo immediatamente, prima della
scadenza del timer di ritrasmissione.
Esempio
Immaginiamo che il pacchetto 4 sia andato perso. Il destinatario riceve i pacchetti 5, 6 e 7 e invia tre
ACK duplicati per il pacchetto 3, indicando che si aspetta ancora il pacchetto 4. Il mittente, alla
ricezione del terzo ACK duplicato, interpreta questo segnale come un'indicazione di perdita e invia
immediatamente il pacchetto 4 senza attendere il timer.
Questo approccio riduce i tempi di attesa per la ritrasmissione e migliora l'efficienza complessiva
della comunicazione TCP.

TCP non usa un timer per ogni pacchetto, ma usa un solo timer per tutti pacchetti e questo timer
viene resettato ogni volta che arriva un ACK di conferma. Per quanto riguarda gli ACK non ci
preoccupiamo molto della loro perdita, dato che sono cumulativi, basta che arrivino quelli dopo
abbiamo la conferma anche per i precedenti.

Controllo di flusso TCP (flow control)

TCP offre un servizio di controllo di flusso alle proprie applicazioni per evitare che il mittente saturi
il buffer del ricevente. Il buffer del ricevente è uno spazio di memoria che raccoglie i dati in arrivo
prima che l'applicazione li legga ed elabori. Se il mittente invia troppi dati troppo velocemente, il
buffer può riempirsi, causando perdita di dati (pacchetti scartati) o spreco di risorse di rete perché i
pacchetti già inviati ma non ricevuti/utilizzati devono essere ritrasmessi.
Si basa sulla finestra di ricezione (o rwnd, "receive window"), una variabile dinamica che indica al
mittente quanto spazio libero c'è nel buffer del ricevente. La formula per calcolarla è:

rwnd = RcvBuffer − [lastbytercvd − lastbyteread]

Dove:
 RcvBuffer: Dimensione totale del buffer del ricevente.
 lastbytercvd: L'ultimo byte dei dati ricevuti dal buffer (ma non necessariamente ancora
elaborato).
 lastbyteread: L'ultimo byte dei dati che l'applicazione del ricevente ha letto ed elaborato.
Il ricevente comunica periodicamente il valore di rwnd al mittente attraverso i pacchetti ACK.
Il mittente, da parte sua, tiene traccia di 2 variabili: lastbytesent cioè 'ultimo byte dei dati inviati dal
mittente e lastbyteacket, cioè l'ultimo byte per cui ha ricevuto un ACK dal ricevente. Per garantire
che non vengano inviati più dati di quanti il buffer del ricevente possa gestire, il mittente deve
rispettare la condizione: lastbytesent – lastbyteacked ≤ rwnd
Se questa condizione non è rispettata, il mittente deve interrompere temporaneamente l'invio dei
dati fino a che non riceve un aggiornamento del valore di rwnd. La finestra di ricezione è dinamica
perché se l'applicazione del ricevente legge ed elabora rapidamente i dati dal buffer, rwnd aumenta,
permettendo al mittente di inviare più dati; se l'applicazione del ricevente non riesce a leggere
velocemente, il buffer si riempie, e rwnd diminuisce, bloccando temporaneamente il mittente.

Algoritmo di Nagle
L'algoritmo di Nagle è una soluzione ideata per migliorare l'efficienza della comunicazione TCP.
TCP utilizza un meccanismo chiamato sliding window: il destinatario gestisce una finestra di
dimensione variabile alla destinazione, che rappresenta la quantità di dati che può ricevere senza
inviare un ACK. Quando questa finestra si chiude, il mittente è costretto a interrompere
temporaneamente l'invio di dati e attendere che la finestra si riapra. Tuttavia, una volta che si apre,
c'è il rischio che i dati vengano inviati immediatamente in piccole quantità, ossia inviando anche la
quantità minima consentita di byte, causando un sovraccarico della rete. Questo comportamento è
noto come silly window syndrome e porta a un aumento del numero di pacchetti trasmessi, con
conseguente spreco di risorse.
L'algoritmo di Nagle affronta questo problema adottando una strategia basata sull'accumulo dei
dati e sull'ottimizzazione dei tempi di invio. Quando un'applicazione genera dati, anziché inviare
immediatamente ogni byte o piccolo gruppo di byte, il mittente accumula i dati fino a raggiungere
una dimensione sufficiente per formare un pacchetto più grande. Questo riduce il numero
complessivo di pacchetti inviati e quindi il traffico sulla rete.
Il funzionamento dell'algoritmo si basa su due scenari principali:
1. Quando arriva un ACK per il pacchetto precedente, il mittente invia immediatamente il
nuovo pacchetto, garantendo che la trasmissione continui senza ritardi significativi.
2. Quando non arriva un ACK per il pacchetto precedente, il mittente aspetta un breve
intervallo di tempo (detto "ritardo di Nagle", solitamente di circa 200 millisecondi) prima di
inviare un nuovo pacchetto. Durante questo intervallo, possono accumularsi ulteriori dati,
aumentando la probabilità che il prossimo pacchetto inviato sia di dimensioni maggiori.
I due passaggi bilanciano il procedimento nel senso che se da un lato riduce il numero di pacchetti
piccoli inviati, dall'altro evita di introdurre ritardi significativi, assicurandosi che i dati siano inviati
quando necessario.
Lezione 6: livello di trasporto – continuo
TCP, essendo un protocollo orientato alla connessione, richiede che i dispositivi coinvolti nella
comunicazione stabiliscano prima una connessione, la quale verrà poi chiusa in modo esplicito una
volta completato lo scambio di dati. Per questo scopo, TCP utilizza procedure specifiche per
l'apertura e la chiusura della connessione.

Concetto di Sfida
Il "concetto di sfida" in TCP serve a verificare che entrambi gli host siano realmente presenti e
intenzionati a stabilire una connessione. Host 1 vuole aprire una connessione con Host 2. E Host 2
risponde. Dato che Host 1 non vede l'Host 2 e Host 2 non vede l'Host 1, ma semplicemente possono
scambiarsi il messaggio; chi c'è dall'altra parte? Ci sono messaggi vecchi provenienti da Host 2 che
si sono persi? Che spuntano improvvisamente senza motivo? Oppure c'è un reale tentativo di aprire
la connessione? Dato che non si vedono, la sfida è "io ti mando un numero, se tu ora sei presente,
sei online, allora mi devi rispondere con un valore legato al numero che ti sto mandando". Poi la
sfida viene invertita. L'Host 2 sfida l'Host 1 a fare la stessa operazione. Qui non è un problema di
sicurezza, è un problema solo per garantire che vecchi messaggi che circolano nella rete per
qualunque motivo, che non ci interessa, non vadano ad aprire connessioni, quindi a occupare risorse
in maniera inutile. Host 2 apre la connessione solamente se la sua sfida, quella che manda verso
Host 1, ha successo.

Perché non è sufficiente un handshake a 2 vie?

Scenario 1: Half open connection
Nel caso di una connessione a due vie, il client invia un segmento SYN al server, e il server
risponde con un SYN-ACK di conferma. Tuttavia, poiché manca un terzo passaggio di ACK dal
client al server, il server non ha modo di verificare se il client è effettivamente pronto e attivo. Se il
client si disconnette subito dopo aver inviato il primo SYN (per esempio, per un problema di rete o
una chiusura improvvisa), il server rimarrà in uno stato di attesa, credendo che la connessione sia
stabilita. Di conseguenza, la connessione rimane in uno stato aperto, consumando risorse
inutilmente fino a che non scatta un timeout o un’altra condizione che forza la chiusura.

Scenario 2: pacchetti duplicati

Pacchetti duplicati possono essere più facilmente accettati, poiché non c'è un controllo preciso sui
numeri di sequenza iniziali. Il client invia un SYN al server. Il server risponde con un SYN-ACK.
Il server non ha un meccanismo robusto per rilevare che si tratta di dati duplicati. In questo scenario
il client manda la richiesta al server (ma questa arriva troppo tardi), non ricevendo alcuna risposta
dal server, il client la reinvia. Adesso il server accetta la richiesta e iniziano a scambiare messaggi,
fino a quando non viene chiusa la connessione. Quello che potrebbe succedere è che la prima
richiesta arrivi in ritardo quindi il server si metterà in ascolto senza che qualcuno voglia
effettivamente comunicare, perché il client ha già chiuso la connessione.

Apertura della Connessione TCP: Handshake a Tre Vie

L'handshake a tre vie è il meccanismo attraverso cui due dispositivi (mittente e destinatario) si
sincronizzano per stabilire una connessione affidabile prima di trasmettere dati. L'idea di un
"handshake a tre vie" è nata per risolvere i limiti di un semplice handshake a due vie, che non
garantiva che le risposte fossero effettivamente correlate alle richieste originali. Vediamo come
funziona in pratica:
1. SYN (Synchronization): L’host che vuole iniziare la connessione (di solito il client) invia
un pacchetto con il flag SYN impostato a 1. Questo pacchetto contiene informazioni sulla
porta di origine e di destinazione, oltre ad un numero di sequenza generato
pseudocasualmente, noto come Initial Sequence Number (ISN), che il client userà come
riferimento per i dati che invierà in seguito.
 2. SYN-ACK (Synchronization + Acknowledgment): Il server riceve il pacchetto SYN e
risponde con un pacchetto che contiene i flag SYN e ACK. Il SYN serve per sincronizzare il
numero di sequenza del server con il client, mentre l’ACK conferma la ricezione del numero
di sequenza iniziale del client e contiene il numero di sequenza del client +1.
3. ACK (Acknowledgment): Il client riceve il pacchetto SYN-ACK dal server e risponde con
un pacchetto ACK che avrà valore numero di sequenza server+1, confermando così la
ricezione del numero di sequenza del server. Questo terzo passaggio completa l’handshake,
e la connessione è ora stabilita.

L'utilizzo di numeri di sequenza iniziali pseudocasuali serve a distinguere le varie connessioni TCP.
Di solito, questi numeri sono calcolati in base all'ora corrente, prendendo le cifre meno significative
della rappresentazione binaria del tempo, in modo da evitare conflitti con connessioni precedenti.
Il bit SYN viene posto a 1 per i primi due pacchetti inviati. Il mittente invia il primo pacchetto ed
avvia un timer. Non avendo campioni su cui basarmi imposto un timer molto grande per essere
sicuro di coprire il tempo di risposta.

Tuttavia, l’approccio di inizializzare un timer lungo per il primo pacchetto SYN può creare un
problema di sicurezza noto come SYN flood attack. In questo attacco, un malintenzionato invia
continuamente pacchetti SYN a un server, simulando richieste di connessione senza mai completare
l’handshake a tre vie. Ogni pacchetto SYN ricevuto induce il server a riservare risorse e avviare un
nuovo timer.
Dato che le risorse sono bloccate per tutta la durata del timer, il server può rapidamente esaurire il
suo buffer di richieste, causando una saturazione della tabella delle connessioni.
Di conseguenza, il server non può più accettare nuove connessioni legittime, bloccando il servizio
per gli utenti reali.
Il SYN Flood è un tipo di attacco DoS/DDoS che usa proprio la tecnica di flooding per bloccare la
connessione. Può essere eseguito da un singolo attaccante e prende il nome di DoS (Denial of
Service), oppure, se viene effettuato da molti dispositivi coordinati, si parla di DDoS (Distributed
Denial of Service).

Chiusura della Connessione TCP

Quando la trasmissione è completata, i dispositivi devono chiudere la connessione per liberare le
risorse. La chiusura avviene attraverso un processo in quattro passi (Four-Way Handshake), che
assicura la terminazione corretta e ordinata di ogni flusso di dati:
1. FIN: il client invia un segmento con il flag FIN per indicare che non ha più dati da
trasmettere. Questo segnala all’altro host che non intende inviare ulteriori dati, ma è ancora
disponibile a riceverne.
2. ACK: Il dispositivo conferma la ricezione del FIN e indica che il primo flusso di dati (dal
mittente al destinatario) è terminato. A questo punto, la connessione è "mezzo chiusa":
l’host che ha inviato il FIN non può più inviare dati, ma deve continuare a ricevere.
3. FIN: Una volta che il dispositivo ricevente ha finito di inviare i propri dati, invia a sua volta
un segmento con il flag FIN, segnalando che la connessione può chiudersi.
 4. ACK finale: Il client invia un ultimo segmento ACK per confermare la ricezione del FIN e
chiude così la connessione definitivamente.

Se un segmento di ACK viene perso, TCP utilizza un meccanismo di time-out per la ritrasmissione,
garantendo che entrambi gli host abbiano conferma della chiusura. Tuttavia, se anche dopo i
ritentativi l'ACK non viene ricevuto, l'host chiuderà la connessione in modo forzato per evitare il
blocco, rilasciando le risorse legate alla connessione.
Questo processo è unidirezionale perché una macchina chiude il flusso di dati da un lato, ma l'altro
lato può ancora essere aperto fino a quando non invia il proprio FIN. Quindi, il flusso di dati viene
fermato prima da una parte, ma la chiusura della connessione avviene in due fasi: una per ogni
direzione del flusso di dati. La chiusura finale di entrambi i flussi avviene solo dopo che entrambe
le macchine hanno inviato il proprio FIN e ricevuto l'ACK finale.

Finestra di Congestione in TCP

Innanzitutto, facciamo una distinzione tra il controllo di congestione e il flow control di cui
abbiamo parlato precedentemente. Il flow control è una tecnica utilizzata per garantire che
il ricevente non venga sopraffatto dalla quantità di dati inviata dal mittente. In altre parole, serve
per evitare che il mittente invii dati troppo velocemente rispetto alla capacità del ricevente di
elaborare o memorizzare quei dati. Il controllo di congestione, invece, si occupa di prevenire che
la rete stessa venga sopraffatta dalla quantità di dati inviati. A differenza del flow control, qui il
problema non riguarda la capacità del ricevente, ma la capacità del canale di
comunicazione. La finestra di congestione è un meccanismo utilizzato da TCP per cercare di
evitare la congestione** nella rete. TCP utilizza una tecnica di controllo della congestione per
adattare dinamicamente la quantità di dati che può essere inviata in un dato momento, in base alla
situazione della rete. La finestra di congestione regola la quantità massima di dati che il mittente
può inviare senza aspettare un ACK) dal destinatario.

**congestione
La congestione di rete si verifica quando il volume di pacchetti che attraversano una rete supera la
capacità di trasmissione della rete stessa. Questo può accadere quando più pacchetti vengono inviati
contemporaneamente, ma la rete (specialmente i router e i dispositivi intermedi) non è in grado di
gestirli tutti. Sebbene i canali di comunicazione abbiano una certa capacità massima, è la gestione
dei pacchetti attraverso la rete, in particolare da parte dei router, che può causare congestionamento.
Andiamo ad esaminare vari scenari che ci mostreranno al meglio i motivi che portano alla
congestione:
SCENARIO 1: Due mittenti, un router con buffer illimitato
Abbiamo un host A e un host B che mandano dati ad una certa frequenza media di in byte/s dove
questi dati sono solo dati originali (niente ritrasmissioni ecc.). Questi dati viaggiano su un canale
condiviso con capacità massima R. Ora, quello che succede è che avremo R/2 per il canale A-
Router e R/2 per il canale Router-B. Supponiamo inoltre che il router che ci sia in mezzo abbia un
buffer illimitato.
Fino a quando inviamo dati con un valore che non supera R/2, naturalmente questi arrivano senza
alcun tipo di problema ma, se il tasso supera R/2, il router non può trasmettere i dati in tempo
reale; quindi, i pacchetti si accumulano nel buffer a un ritmo sempre maggiore, causando ritardi.

Di fatto, più ci avviciniamo a R/2 di throughput, maggiore sarà il ritardo che andrà al limite a
tendere ad infinito. Avere dunque un throughput vicino a R/2, per quanto possa sembrare una cosa
conveniente, porterebbe a maggiori ritardi di accodamento.

SCENARIO 2: Due mittenti, un router con buffer limitato

Come prima modifica a questo schema ci basta renderci conto che un buffer illimitato non esiste e
dunque supponiamo che questo sia limitato. Se arriva un pacchetto ad un buffer già pieno, allora
questo verrà buttato e quindi sarà necessario ritrasmetterlo. Denotiamo quindi con in il tasso di
trasmissione dei dati verso la socket (originali) e con in i dati effettivamente trasmessi (originali e
ritrasmissioni) questa viene spesso chiamata carico offerto.
Primo caso: A sa come per magia quando il buffer è libero e invia solo in quel momento. In questo
caso non avremmo alcuno smarrimento e ci troveremmo nel caso più semplice. Dal punto di vista
del throughput, le prestazioni sono ideali: tutto quanto quello che viene trasmesso è ricevuto e il
throughput non va oltre gli R/2.

Secondo caso: A ritrasmette i messaggi, solo quando è sicuro che un pacchetto si è perso.
Consideriamo che il carico offerto valga R/2. Con questo valore di carico effettivo, abbiamo che i
dati consegnati a destinazione non sono più di R/2, bensì di R/3. Dunque, possiamo anche rilevare
un altro costo legato alla congestione di rete, cioè, che il mittente deve andare a ritrasmette i
pacchetti perduti a causa del buffer.
Terzo caso: sia il pacchetto originale che la ritrasmissione arrivano al destinatario. Ovviamente al
destinatario servirà solo un pacchetto e scarterà quindi i duplicati arrivati inutilmente. Dunque,
abbiamo che il router ha sprecato del tempo a indirizzare i pacchetti copia che alla fine non
servivano, avrebbe potuto infatti utilizzare meglio questo tempo per instradare altri pacchetti nuovi.

SCENARIO 3: Quattro mittenti, router con buffer limitati e percorsi composti da più
collegamenti

Supponiamo che in questo caso i pacchetti trasmessi dai quattro host viaggino su percorsi composti
da due collegamenti sovrapposti tra loro. Inoltre, ciascun Host implementa una connessione
affidabile e tutte le relative conseguenze di ritrasmissioni ecc.
Prendiamo la connessione A-C che passa per i router R1 e R2. Questa connessione condivide il
router R1 con la connessione D-B e stessa cosa fa il Router R2 con la connessione B-D. Per in
molto piccoli, gli overflow dei buffer saranno molto rari e il throughput sarà uguale al traffico di
rete.
Consideriamo invece in più grandi, immaginiamo che A voglia comunicare con C e manda un
pacchetto che passa prima da R1 senza alcun problema, ma che poi su R2 viene scartato a causa del
buffer pieno per i messaggi che ci sono da B verso D. E così via, più aumenta il traffico di dati tra B
e D, maggiore sarà la competizione per accaparrarsi lo spazio nel buffer di R2 creando così
congestione nel canale che potrebbe portare a throughput 0 nella connessione A-C su R2. Notiamo
quindi un grave spreco perché i pacchetti inviati nel primo R1, verranno poi buttati da R2 e quindi
avremo creato traffico inutile sulla rete causando congestione.

Approcci al controllo di congestione

Parliamo di controllo di congestione end to end quando questa deve essere riconosciuta dai
sistemi periferici dato che il livello di rete non fornisce supporto per quanto riguarda la congestione
(salvo alcuni casi che citeremo dopo). Mentre invece parleremo di controllo di congestione
assistito dalla rete quando i router riescono a fornirci dei feedback espliciti per quanto riguarda lo
stato della rete.
Per quanto riguarda il controllo di congestione assistito dalla rete possiamo prendere come esempio
TCP ECN dove abbiamo 2 byte di intestazione TCP che possono essere modificati dal router per
comunicare con i client e avvisarli della congestione. Quindi A manda un segnale a B, B riceve il
segmento con le intestazioni modificate che gli indicano la congestione e dunque B manda ad A un
segnale che gli indica la congestione.
Andiamo ad analizzare il controllo end to end che è quello classico fornito da TCP. Innanzitutto,
l’unico modo che abbiamo di capire quando c’è congestione nella rete sono i feedback che la stessa
ci dà tramite i pacchetti mandati e ricevuti. Un segmento perso implica congestione e quindi le
trasmissioni del mittente dovrebbero diminuire per evitare di creare ulteriore traffico. Un ACK
indica che la rete sta consegnando i pacchetti correttamente e quindi possiamo andare ad aumentare
il throughput. Basandoci su queste informazioni andiamo a parlare dell’algoritmo del controllo di
congestione di TCP. Questo è composto da tre fasi principali: slow start, AIMD e fast recovery.

Politica Tahoe (slow start, AIMD, fast retransmit)

Quando viene rilevata una perdita di pacchetti (tipicamente tramite un time-out o il triplo
duplicato di ACK), si verifica un "evento di congestione". In risposta, il protocollo dimezza la
finestra di congestione e memorizza il nuovo valore di questa finestra nella variabile SSThresh
(Slow Start Threshold).
Dopo un evento di congestione, la finestra di congestione viene reimpostata a un valore molto
basso, 1 MSS cioè un pacchetto alla volta. Questo significa che la velocità di trasmissione dei dati
viene drasticamente ridotta. La trasmissione dei dati riprende con la fase Slow Start, durante la
quale, la finestra di congestione cresce esponenzialmente: ad ogni RTT, la finestra di congestione
raddoppia. La crescita continua finché la finestra di congestione non raggiunge il valore
di SSThresh (la soglia precedentemente determinata, che è metà della finestra di congestione
precedente l'evento di perdita).
Una volta che la finestra di congestione raggiunge il valore di SSThresh, la modalità di crescita
cambia e la finestra cresce linearmente. Questo è il punto in cui il protocollo passa alla fase AIMD
in cui la finestra di congestione aumenta in modo additivo (di una quantità fissa) ogni RTT. Se si
verifica una perdita di pacchetti durante la fase AIMD, la finestra di congestione viene nuovamente
ridotta (decremento moltiplicativo  dimezzata) e il processo riprende dalla fase Slow Start.
La riduzione della finestra di congestione a 1 MSS implica una drastica riduzione della velocità di
trasmissione dei dati, limitando fortemente la banda disponibile per la trasmissione.
Questo ha un effetto positivo in quanto decongestiona la rete, ma negativo per la velocità della
connessione, che diventa molto bassa per un certo periodo di tempo. Pertanto, la crescita
esponenziale fino al livello di soglia consente alla connessione TCP di recuperare prontamente (ma
parzialmente) una parte della banda ormai persa in seguito all'evento di congestione. Una volta
raggiunto il livello di soglia, la crescita avviene lentamente per sondare il livello di banda
effettivamente disponibile in rete e cercare di raggiungere nuovamente il livello di congestione il
più lentamente possibile.
Politica Reno (Slow start, AIMD, fast retransmitt, fast recovery)
La politica TCP Reno migliora la gestione della congestione rispetto alla versione TCP Tahoe, in
particolare Reno distingue lo scadere di un time-out senza aver ricevuto un ACK, dall’evento 3
ACK duplicati: il primo lo considera un forte indicatore di congestione perché significa che la rete
è seriamente congestionata e i pacchetti non riescono ad essere consegnati al destinatario, e il
secondo come indicatore debole, perché indica che un pacchetto potrebbe essere stato perso, ma la
rete è comunque riuscita a consegnare altri pacchetti, evitando un blocco totale.
Nel primo caso, la finestra di congestione viene ristabilita a 1 MSS, la dimensione minima che
TCP può utilizzare per la trasmissione dei dati. Inoltre, la soglia SSThresh viene dimezzata,
riducendo il valore della finestra di congestione che TCP dovrà tentare di riutilizzare.
Dopo il time-out, TCP riprende la trasmissione dalla fase Slow Start. Questo implica che la finestra
di congestione cresce in modo esponenziale fino a raggiungere la soglia SSThresh, dopodiché si
passa alla fase AIMD, che modula la crescita della finestra in modo lineare.

Evento 3 ACK duplicati: la risposta a questa situazione è diversa rispetto a TCP Tahoe:
Applica il Fast Retransmit: Non bisogna aspettare che scada il timer per ritrasmettere il pacchetto
perso. Quando il mittente riceve tre ACK duplicati (cioè, il destinatario ha ricevuto dei pacchetti
ma uno non è stato ancora riconosciuto), TCP considera che il pacchetto indicato è stato perso. A
questo punto, TCP ritrasmette subito il pacchetto senza attendere.
Fast Recovery (è raccomandata ma non obbligatoria): Dopo il Fast Retransmit, non torna a 1 MSS
come avviene con un time-out. Invece, TCP Reno continua la trasmissione con una finestra di
congestione ridotta, ma non riparte dalla fase Slow Start. La finestra di congestione ridotta
permette di recuperare il flusso senza resettare completamente il processo di trasmissione. La
riduzione della finestra avviene linearmente, e si entra nella fase AIMD per controllare la crescita
della finestra.

Come funziona la sequenza:

1. Time-out (evento forte di congestione): Si riduce la finestra di congestione a 1 MSS, si
dimezza la SSThresh e si riavvia la fase Slow Start.
2. Tre ACK duplicati (evento debole di congestione): Si esegue un Fast Retransmit del
pacchetto perso, si riduce la finestra di congestione (ma non a 1 MSS) e si entra nella
fase Fast Recovery. Dopo il Fast Recovery, si passa alla crescita lineare della finestra
tramite AIMD.

Differenza principale tra Tahoe e Reno:

 TCP Tahoe: In caso di time-out o congestione, la finestra di congestione viene sempre
ridotta a 1 MSS, e la connessione ricomincia da Slow Start.
 TCP Reno: In caso di perdita segnalata da tre ACK duplicati, il protocollo non azzera la
finestra di congestione a 1 MSS, ma continua la trasmissione con una finestra più grande e
entra nella fase Fast Recovery.
Se si segue prima lo Slow Start e poi l'AIMD, si ha una distribuzione più equilibrata della banda
in modo che tutte le connessioni possano competere equamente, con una crescita rapida iniziale
(Slow Start) e una crescita controllata successiva (AIMD), senza che una connessione monopolizzi
la banda, infatti possiamo dire che AIMD sia un algoritmo fair.
Quindi, se si invertissero le fasi, la "curva" di crescita della finestra di congestione divergerebbe
rispetto alle altre connessioni e non si avrebbe più una distribuzione equa delle risorse di rete,
compromettendo la fairness.

Perché è importante la fairness?

In un sistema di rete condiviso, molti flussi di dati (ad esempio, connessioni TCP) potrebbero
cercare di inviare pacchetti sulla stessa infrastruttura di rete. Se la rete non gestisce correttamente
come questi flussi competono tra loro per la larghezza di banda, potrebbero verificarsi vari
problemi: Un flusso più aggressivo (ad esempio, che aumenta la sua finestra di congestione più
rapidamente) potrebbe saturare la rete, riducendo la banda disponibile per altri flussi.
Questo potrebbe portare a latenza elevata o a una riduzione della velocità di trasmissione per i
flussi "meno aggressivi".
Il concetto di fairness serve a garantire che tutti i flussi ottengano una quota giusta della larghezza
di banda disponibile, impedendo che un singolo flusso monopolizzi l'intera capacità della rete.
Supponiamo di avere due connessioni TCP, un router centrale che fa da collo di bottiglia e ha una
certa capacità R. L’obiettivo finale è che la banda tra queste due connessioni venga equamente
divisa in questo link. Le due connessioni non sanno che l’altra esiste. Il router non può fare niente:
il suo unico compito è di inoltrare i pacchetti fuori dal suo buffer con la sua politica FIFO e scartare
i pacchetti che arrivano quando il buffer è pieno.
Possiamo dimostrare che la fairness esiste con la seguente dimostrazione grafica:

Commentiamo la prima immagine:

l'asse orizzontale rappresenta il throughput della Connessione 1 (x) e l'asse verticale rappresenta il
throughput della Connessione 2 (y). La larghezza di banda totale disponibile è R.
Punto R1 = (R,0). Questo punto rappresenta il caso in cui tutta la larghezza di banda R viene
utilizzata dalla Connessione 1. Punto R2 = (0, R). Questo punto rappresenta il caso in cui tutta la
larghezza di banda R viene utilizzata dalla Connessione 2.
La linea di completa utilizzazione della banda è il segmento che collega i punti R1=(R,0) e R2=
(0, R). Questo segmento rappresenta tutte le possibili combinazioni di throughput delle due
connessioni in cui la somma totale della banda utilizzata dalle due connessioni è esattamente uguale
a R. La sua equazione è: y = −x+R
Quindi, per ogni punto (x, y) su questo segmento, la somma dei throughput delle due connessioni è
uguale alla larghezza di banda totale R, cioè: x+y=R
Questo segmento rappresenta le situazioni in cui la rete è completamente utilizzata, ma non in modo
equo. In altre parole, una connessione può utilizzare più banda dell'altra, ma la somma complessiva
del throughput rimane R.
La bisettrice del primo e terzo quadrante, che ha l'equazione y=x, rappresenta la situazione in cui
entrambe le connessioni utilizzano la stessa quantità di banda, ossia la situazione di fairness
perfetta. Il punto di coordinate (R/2, R/2) si trova sulla bisettrice e rappresenta il caso ideale in cui
entrambe le connessioni ottengono metà della larghezza di banda disponibile, quindi una divisione
equa. Va da sé dire che all’origine le connessioni sono ferme.

Commentiamo la seconda immagine:

Il punto A rappresenta una situazione iniziale in cui entrambe le connessioni hanno lo stesso
throughput, ma inferiore alla capacità massima (A si trova sotto la retta y=−x+R). In questa
situazione, non ci sono perdite, quindi entrambe le connessioni possono aumentare il proprio
throughput in modo graduale e simmetrico, avanzando di 45 gradi verso il punto B. Questo aumento
è regolato da TCP attraverso il meccanismo della finestra di congestione, che cresce
progressivamente in assenza di perdite. Arrivati al punto B, la somma dei throughput delle due
connessioni raggiunge R. A questo punto, si verifica una congestione nella rete: il buffer del router
intermedio si riempie, e uno o più pacchetti vengono persi. Questo evento innesca il meccanismo di
controllo della congestione di TCP, che reagisce dimezzando la finestra di congestione
(decremento moltiplicativo). Questo porta entrambe le connessioni al punto C. In pratica, i
throughput di entrambe le connessioni vengono ridotti simultaneamente.
Dopo il punto C, le connessioni riprendono ad aumentare il proprio throughput in modo graduale,
avanzando di nuovo verso la linea y=−x+R fino a raggiungere il punto D. Anche qui il ciclo si
ripeterà. Questo comportamento fa sì che il sistema si stabilizzi intorno alla linea di equa
condivisione, dove la banda viene divisa in modo bilanciato tra le due connessioni,
indipendentemente dal punto iniziale.
Questa dinamica è il motivo per cui molte applicazioni preferiscono utilizzare UDP invece di TCP.
UDP non implementa meccanismi di controllo della congestione come TCP, permettendo così un
throughput più costante, anche a costo di perdere pacchetti. Al contrario, TCP cerca di garantire una
condivisione equa della banda, ma introduce una fluttuazione del throughput dovuta al suo
adattamento continuo alla congestione. Per esempio, se due applicazioni utilizzano rispettivamente
quattro connessioni TCP e sei connessioni TCP, la banda verrà suddivisa in modo proporzionale,
con la prima applicazione che utilizzerà 4/10 della banda e la seconda 6/10.

Possiamo avere un throughput maggiore di R quindi? Teoricamente no, ma... invece sì. Come?
Consideriamo il fatto che nei router ci siano dei buffer che possono accumulare pacchetti. Questo
significa che, anche se il link ha una capacità R, il sistema potrebbe inviare pacchetti più
rapidamente per un breve periodo, esaurendo i pacchetti in coda. È questa accumulazione che porta
il throughput oltre R per un istante. Quindi, può capitare di arrivare nella zona oltre il segmento R1
R2. Però arrivare in questa zona del grafico, e quindi di avere un punto in questa zona oltre il max
throughput, vuol dire che i pacchetti si stanno accumulando e quindi le code si riempiono e prima o
poi si arriva alla perdita di qualche pacchetto per time-out o triplo ACK duplicato.
Conclusione: L'accumulo nei buffer è solo un fenomeno temporaneo. Non può sostenere un
throughput maggiore di R per un lungo periodo. Superare R significa che il sistema sta operando in
modo instabile, e prima o poi si verificano perdite di pacchetti o rallentamenti.

Lezione 7: Livello di rete

È il terzo livello della pila ISO/OSI.
Mentre i livelli di applicazione e di trasporto si concentrano sulla comunicazione tra il dispositivo
mittente e quello destinatario (end-to-end), il livello di rete introduce il concetto di dispositivi
intermedi, come router e switch, che facilitano il passaggio dei dati attraverso una serie di nodi per
raggiungere la destinazione.
Il livello di rete ha il compito di prendere i segmenti a livello di trasporto, incapsularli in
datagrammi e trasmetterli al router vicino.
Facciamo innanzitutto una distinzione tra:
Forwarding (Inoltro): è il processo attraverso cui il router prende un datagramma e lo trasferisce
nell’appropriato link di uscita. Ogni router esamina l'intestazione del pacchetto, individua
l’indirizzo del prossimo nodo e lo inoltra. È una procedura locale perché avviene solo tra dispositivi
adiacenti e non richiede una conoscenza completa della rete.

Routing (Instradamento): riguarda la determinazione del percorso ottimale che i pacchetti

devono seguire attraverso la rete per arrivare alla destinazione finale. Per fare questo, il router
analizza la topologia della rete e usa algoritmi di Routing per identificare il percorso migliore,
considerando vari fattori, come: larghezza di banda disponibile, congestione della rete, qualità del
servizio richiesta.
È un’operazione globale perché richiede una visione d’insieme della rete per poter scegliere il
percorso più efficiente.

Il Data Plane, noto anche come piano dati o piano di inoltro, è la parte operativa che si occupa di
leggere i pacchetti, analizzarne l’intestazione e inoltrarli al nodo successivo secondo le indicazioni
contenute nella tabella di routing operando a livello locale, nodo per nodo.
Il Control Plane, noto come piano di controllo o piano di instradamento, gestisce invece la parte
"intelligente" della rete, ossia la configurazione e la scelta dei percorsi migliori per i pacchetti
attraverso la rete.
In questo modo, il Control Plane stabilisce le regole e le configurazioni che il Data Plane segue per
gestire il traffico dati (esegue il lavoro fisico). I due piani collaborano strettamente per garantire il
corretto funzionamento della rete.
Abbiamo due approcci al control plane per la gestione della rete:
1. Approccio Distribuito Tradizionale (Control Plane Distribuito)
Ogni router possiede un control plane integrato. In pratica, ogni router ha un algoritmo di routing
incorporato che gli consente di prendere decisioni di instradamento del traffico in modo autonomo e
decentralizzato. Ogni router adatta le proprie decisioni di routing in tempo reale, aggiornando la
propria tabella di routing basata sulle nuove informazioni ricevute da altri dispositivi.
Vantaggi: se un dispositivo fallisce, la rete si riorganizza autonomamente; buona scalabilità in reti
grandi e complesse.
Svantaggi: Maggiore complessità di configurazione e aggiornamento

2. Approccio SDN (Software-Defined Networking) - Control Plane Centralizzato

L’approccio SDN separa il control plane dal data plane, centralizzando il controllo in un'unica
entità software chiamata controller SDN. Il controller non è altro che un server esterno che
controlla i flussi di dati e distribuisce la tabella più efficiente in quel momento; è responsabile delle
decisioni di instradamento per tutta la rete, mentre i router si occupano solo di inoltrare il traffico
secondo le istruzioni ricevute dal controller.
Vantaggi: Maggiore flessibilità; semplificazione dei dispositivi di rete (non serve che abbiano
algoritmi di routing complessi); maggiore controllo e possibilità di programmare la rete.
Svantaggi: 1. Se il controller centralizzato fallisce, la rete può subire disservizi; 2. Poca scalabilità
per gestire reti estremamente grandi.
Andiamo ad osservare quali sono le principali caratteristiche che potrebbe offrire il servizio a livello
di rete:
- Consegna garantita: ci assicura che il pacchetto arrivi
- Consegna garantita entro un certo ritardo: ci assicura che il pacchetto arrivi entro un
certo tempo
- Consegna ordinata: I pacchetti arrivano nell’ordine in cui sono inviati
- Banda minima garantita: Questo servizio a livello di rete emula il comportamento di un
collegamento trasmissivo con bit rate specificato.
- Servizi di sicurezza: Il livello di rete dell’host sorgente può cifrare tutti i datagrammi
inviati.
Nel contesto della comunicazione dati all'interno di una rete, abbiamo recentemente definito due
approcci: datagram e a circuito virtuale.
Servizio Datagram
È utilizzato nel protocollo IP di Internet. Funziona in modalità best-effort, ossia con il massimo
impegno possibile, ma senza garanzie specifiche di consegna dei pacchetti.
Ogni pacchetto viene inviato autonomamente, senza un percorso fisso tra mittente e destinatario.
Ogni router decide il miglior percorso al momento, basandosi sulle proprie tabelle di Routing. Non
garantisce nessuna delle caratteristiche precedenti. La trasmissione datagram però è facile da
implementare e si adatta bene a reti estese come Internet, dove la probabilità di errore è gestita
principalmente dall’hardware e dal software di alto livello.

Servizio a Circuito Virtuale

Crea invece un percorso logico specifico per la durata di una comunicazione tra mittente e
destinatario.
Prima dell’inizio della trasmissione, si stabilisce un percorso definito (circuito virtuale) lungo i nodi
della rete, e si riserva una porzione di banda su ciascun nodo lungo il percorso. Questo percorso
dedicato garantisce che i pacchetti vengano ricevuti nell’ordine in cui sono stati inviati e offre
garanzie di banda e ritardo end-to-end. Poiché la banda è riservata, la rete può gestire meglio il
traffico evitando sovraccarichi sui percorsi. La configurazione dei circuiti virtuali richiede una
maggiore complessità, poiché ogni percorso richiede un setup iniziale e risorse specifiche che
vengono allocate solo per la durata della comunicazione.

Com’è fatto un Router?

Un router è un dispositivo di rete che gestisce il traffico dati tra diverse reti, permettendo ai
pacchetti di raggiungere la loro destinazione corretta. Questo processo avviene grazie a una tabella
di routing, una sorta di "mappa" che il router utilizza per scegliere il percorso migliore per ogni
pacchetto. Struttura del router:

1. Porte di ingresso
Svolgono le funzioni (a livello fisico) di terminazione di un collegamento in ingresso di un router e
di indirizzamento verso la porta d’uscita (funzione di forwarding= inoltro).
Nelle porte di input di un router, si ha un componente che lavora a livello fisico e che si occupa di
ricevere i pacchetti di dati provenienti dalle diverse interfacce di rete. Successivamente, i dati
ricevuti vengono bufferizzati per consentire una gestione efficiente del traffico, in quanto non è
detto che i pacchetti vengano inoltrati con la stessa velocità con cui vengono ricevuti.
Per assegnare un'uscita a un pacchetto in ingresso, si cerca una voce della tabella di inoltro
con il prefisso di indirizzo più lungo che matcha all'indirizzo di destinazione.
Abbiamo due tipi di inoltro: destination based e generalized. Quello destination based si basa
unicamente sull’indirizzo IP di destinazione ed è quello tipicamente utilizzato mentre quello
generalized si basa su alcuni valori nel campo dell’header.
Una tabella di inoltro contiene dei range degli indirizzi di destinazione alle quali corrispondono
delle interfacce (uscite).

Questi possono anche essere indicati diversamente specificando solo la maschera che consiste nei
primi X bit, questa ci va ad indicare che quei X bit devono essere fissi mentre gli altri possono
essere variabili (quelli indicati con *).
In questo caso possiamo notare che l’interfaccia 1 e la 2 hanno maschere “simili”, nel caso in cui
abbiamo un indirizzo che combacia con entrambe, utilizziamo la regola del prefisso più lungo cioè
lo indirizziamo in base al prefisso più lungo che combacia, in questo caso l’interfaccia 1.
Abbiamo bisogno che la ricerca venga effettuata in nanosecondi, per fare ciò ricorriamo alle
memorie TCAM che per un IP a 32 bit, riescono ad effettuare le ricerca in un tempo costante,
indipendentemente dal numero di voci presenti nelle tabelle.

CAM e TCAM
Le memorie associative CAM e TCAM (Content-Addressable Memory e Ternary Content-
Addressable Memory) rendono estremamente veloce la ricerca nelle tabelle di routing.
La CAM è una memoria che permette di effettuare ricerche basate su corrispondenze esatte. In
altre parole, con la CAM si può cercare un dato specifico (come un indirizzo IP) e ottenere
immediatamente il corrispondente valore associato (come la porta di uscita), se presente.
Utilizza la ricerca esatta, ovvero confronta l'indirizzo del pacchetto con quelli memorizzati e
restituisce il risultato solo se trova una corrispondenza completa. Esegue la ricerca simultaneamente
su tutti gli indirizzi memorizzati, offrendo così un tempo di ricerca molto veloce. La CAM viene
spesso usata per compiti di ricerca come quelli nelle tabelle ARP.
La TCAM è un’evoluzione della CAM, che aggiunge la capacità di effettuare ricerche parziali. A
differenza della CAM, che confronta solo valori binari (0 e 1), la TCAM permette di avere tre
stati: 0, 1 e "don't care" (X). Questo significa che può effettuare ricerche con maschere di bit,
permettendo di identificare in modo flessibile indirizzi parziali o più indirizzi contemporaneamente.
La X rappresenta una posizione in cui il bit può essere ignorato, rendendo la TCAM ideale per
l’utilizzo di maschere di rete e prefissi IP.

2. Struttura di commutazione
È un meccanismo che permette di trasferire i pacchetti di dati dalle porte di ingresso alle porte di
uscita, dove vengono instradati verso la destinazione. Questa struttura può essere implementata con
diverse architetture, ognuna con vantaggi e svantaggi in termini di velocità, complessità e costo.

1. Architettura della Memoria Condivisa: I primi router utilizzavano le porte come dei semplici
dispositivi I/O. Questi ricevevano i pacchetti, li mettevano nella memoria del processore di
instradamento che trovava l’indirizzo di destinazione e copiava il pacchetto nella memoria del
buffer d’uscita. Naturalmente questo approccio era piuttosto semplice e parecchio economico visto
che non richiedeva un particolare tipo di processore personalizzato a questo scopo. Lo svantaggio è
che richiede molti accessi alla memoria, che possono rappresentare un collo di bottiglia; per grandi
volumi di traffico, questa architettura risulta lenta e non scalabile.
2. Architettura del Bus Condiviso: le porte d’ingresso sono collegate a quelle d’uscita tramite un
bus unico e inviano il pacchetto lì, senza l’intervento del processore d’instradamento. Per fare ciò le
porte d’ingresso mettono un flag che indica in quale porta d’uscita deve andare e, una volta arrivato
a destinazione, questo flag viene tolto e il pacchetto spedito. Naturalmente consideriamo che la
larghezza di banda della commutazione è limitata a quella del bus in questo caso. Abbiamo una
maggiore velocità rispetto alla memoria condivisa, poiché elimina l’accesso ripetuto alla memoria
centrale, ma il bus diventa un collo di bottiglia quando il traffico è elevato, poiché può gestire un
solo trasferimento alla volta.
3. Architettura della Rete di Interconnessione
Un modo per superare la limitazione di banda di un singolo bus condiviso è l’utilizzo di una rete di
interconnessione più sofisticata, quale quella usata in passato nelle architetture multicore. Questa
architettura permette di gestire flussi di traffico simultanei da diverse porte di ingresso a diverse
porte di uscita. È usata nei router ad alte prestazioni, dove è fondamentale gestire un alto volume di
traffico in modo efficiente.
In base alle tempistiche del router, potremmo avere degli accodamenti in vari luoghi: in particolare
se il tempo di commutazione è più lento di quello d’arrivo dei pacchetti, allora naturalmente avremo
una coda nelle porte d’ingresso e si creerà un HOL blocking**. Se invece sono lente le porte di
output rispetto al tempo di commutazione allora quei buffer si andranno man mano riempiendo
creando degli accodamenti anche nelle porte d’ingresso.

**L'HOL blocking (Head-of-Line blocking) si verifica quando un pacchetto bloccato in una coda
d'ingresso impedisce il trasferimento di altri pacchetti che si trovano dietro di esso, anche se questi
ultimi potrebbero essere instradati verso destinazioni differenti.

3. Porte di Uscita
Le porte di uscita memorizzano i pacchetti provenienti dalla struttura di commutazione e li
trasmettono sui link di uscita. Oltre alla trasmissione, le porte di uscita svolgono anche operazioni
del livello data-link e del livello fisico, come il controllo degli errori e la codifica/decodifica del
segnale.
Le porte di uscita hanno delle code di uscita che gestiscono i pacchetti in attesa di essere trasmessi.
In caso di congestione, le code possono temporaneamente bufferizzare i pacchetti o, in casi estremi,
scartarli per evitare il sovraccarico.

4. Processore di Instradamento (Routing Processor)

È il componente che si occupa delle operazioni di controllo del router. La sua funzione principale
è gestire le tabelle di routing e le informazioni sui collegamenti attivi.
 Nei router tradizionali: esegue i protocolli di Routing, gestisce le tabelle di inoltro e
aggiorna la tabella di routing per decidere i percorsi migliori.
 Nei router SDN: comunica con un controller remoto che aggiorna e configura
dinamicamente le tabelle di routing.
Teniamo conto del fatto che la maggior parte delle funzioni del data plane è implementato via
hardware visto che sono molto veloci, mentre le funzioni del control plane sono implementate via
software ed eseguite dal processore d’instradamento.

Il buffering nei router è essenziale per gestire in modo efficiente il traffico di rete, evitando la
perdita di pacchetti in condizioni di congestione. Tuttavia, la quantità di memoria da allocare per il
buffering deve essere calcolata attentamente per bilanciare tra la capacità di gestire picchi di traffico
e la necessità di evitare ritardi eccessivi, soprattutto per le applicazioni in tempo reale.
La formula per determinare la capacità di buffering ottimale in un router è:
Dove:
 RTT (Round Trip Time) è il tempo di andata e ritorno, cioè il tempo necessario perché un
pacchetto viaggi dalla sorgente alla destinazione e ritorni alla sorgente.
 C è la capacità del link di rete, ossia la massima quantità di dati che il link può trasferire in
un’unità di tempo (ad esempio, in bit per secondo).
 N è il numero di flussi di dati presenti nella rete.
Interpretazione della Formula
 Prodotto RTT e C: Il buffering necessario aumenta proporzionalmente all’aumento del
RTT e della capacità del link. Questo significa che se il tempo di viaggio dei pacchetti o la
velocità del link sono alti, il router avrà bisogno di un buffer maggiore per contenere i
pacchetti in attesa di essere instradati.
 Radice quadrata del numero di flussi N: Aumentando il numero di flussi di dati nella rete,
il buffering necessario diminuisce in proporzione alla radice quadrata di N. L'idea è che
aumentando il numero di flussi di dati (N), il traffico diventa più equilibrato. Questo accade
perché avere più flussi distribuisce meglio i pacchetti, riducendo la probabilità di
congestione concentrata sul singolo flusso.
Considerazioni sul Buffering
Un buffering eccessivo può aumentare il tempo di attesa per i pacchetti, con il rischio di ritardi
elevati, soprattutto per le applicazioni in tempo reale. Quando il buffer è troppo grande, i pacchetti
si accumulano e possono subire ritardi significativi, generando fenomeni di bufferbloat (eccessivo
ritardo a causa del buffering).
Per le applicazioni che non sono sensibili alla latenza, come il trasferimento di file, un buffer più
grande potrebbe non causare problemi significativi. Tuttavia, per applicazioni interattive, un
buffering eccessivo può degradare l’esperienza dell’utente.
La quantità di buffering deve essere determinata in base alle caratteristiche del traffico di rete e al
carico previsto. Se la rete ha molte connessioni (alto valore di N), il buffer può essere ridotto.
Viceversa, per reti con pochi flussi di dati e tempi di andata e ritorno elevati, il buffering deve
essere maggiore per evitare perdite di pacchetti.

Smaltimento dei buffer

Dato che la porta di uscita può trasmettere un solo pacchetto in un intervallo prestabilito (tempo di
trasmissione del pacchetto), i pacchetti in arrivo dovranno mettersi in coda per la trasmissione sul
collegamento in uscita. In assenza di sufficiente memoria per inserire nel buffer il nuovo pacchetto
in ingresso occorrerà stabilire se scartarlo o se rimuoverne uno o più, fra quelli già in coda, per far
posto al nuovo arrivato.
Algoritmi per prendere la scelta sul pacchetto da scartare:
FCFS (First-Come, First-Served) gestisce i pacchetti in ordine di arrivo, ovvero il primo pacchetto
che arriva viene trasmesso per primo.
L'algoritmo FCFS è molto semplice ed efficiente, poiché non richiede alcun tipo di ordinamento dei
pacchetti. Tuttavia, questa politica di gestione dei pacchetti può portare a problemi di congestione di
rete in situazioni di traffico intenso.
RED (Random Early Detection) prevede la gestione delle code di I/O sui router con un modello
FIFO. Quando il buffer di una coda raggiunge il 75% della sua capienza, alcuni pacchetti vengono
eliminati in modo "casuale" per prevenire la saturazione del buffer e i pacchetti vengono quindi
trasmessi nello stesso ordine con cui sono arrivati in coda.
In questo modo, si evita che TCP saturi i buffer e rallenti l'invio dei pacchetti, utilizzando strategie
di controllo congestione messe in atto da TCP Tahoe o Reno. La politica RED è particolarmente
utile per evitare la congestione di rete in situazioni di traffico intenso.
RR (Round Robin), invece, gestisce le code di bufferizzazione tutte in parallelo, inviando un
pacchetto per ciascuna coda. Questa politica permette di prevenire la congestione di rete,
garantendo una distribuzione equa del traffico su tutte le code di bufferizzazione. Tuttavia, la
politica RR richiede una maggiore complessità nell'implementazione rispetto alla politica RED.

Formato del datagramma IPv4

IPv4 (Internet Protocol versione 4) è uno dei protocolli principali usati per il trasporto di dati su
Internet, responsabile dell'indirizzamento e dell'instradamento dei pacchetti di dati. Il formato del
pacchetto IPv4 a livello di rete è noto come datagramma.
Struttura
Un indirizzo IPv4 è costituito da 32 bit organizzati in quattro gruppi di 8 bit ciascuno, detti ottetti.
Ogni ottetto è separato da un punto (ad esempio: 192.168.1.1). Questo tipo di indirizzamento
permette fino a circa 2^32, cioè 4,3 miliardi di combinazioni uniche, corrispondenti ad altrettanti
indirizzi IP.
Classi di Indirizzi IPv4
Per gestire l’allocazione degli indirizzi IPv4, questi sono stati suddivisi in classi, identificate come
A, B, C, D ed E. Ogni classe è pensata per un diverso scopo e ha una diversa configurazione
di parte di rete che identifica la rete principale e parte di host che identifica i singoli dispositivi
all'interno di quella rete.
- La classe A è utilizzata per reti molto grandi; Il primo ottetto (8 bit) identifica la rete,
mentre i successivi tre ottetti (24 bit) sono utilizzati per identificare gli host. Circa 16
milioni di host per rete.

- Classe B è destinata a reti di medie dimensioni, come reti aziendali; i primi due ottetti (16
bit) identificano la rete, e i successivi due (16 bit) identificano l'host, permettendo circa
65.000 host per rete.
- Classe C: 24 bit (3 byte) per la rete e lasciava solo 8 bit per gli host, permettendo fino a 254
host per rete. La classe C è usata per reti di piccole dimensioni, come reti domestiche o
piccoli uffici.
La classe D Utilizzata per il Multicast, ovvero per inviare pacchetti a un gruppo di dispositivi
piuttosto che a uno specifico destinatario; Non ha una suddivisione tra parte di rete e parte di host.
La classe E è riservata per scopi sperimentali o di ricerca; anche questa non ha una suddivisione
tra parte di rete e parte di host e generalmente non è utilizzata in reti pubbliche.

All'interno delle classi A, B e C, ci sono anche indirizzi riservati per uso privato (non instradabili
su Internet), come:
 Classe A: 10.0.0.0 – 10.255.255.255
 Classe B: 172.16.0.0 – 172.31.255.255
 Classe C: 192.168.0.0 – 192.168.255.255
Questi indirizzi sono utilizzati in reti locali e permettono di risparmiare indirizzi pubblici, grazie
all'uso di tecniche come il NAT (Network Address Translation).
Header IPv4

Un datagramma IPv4 è composto da un’header, solitamente di 20 byte, e dal carico utile

(payload). L'header contiene informazioni fondamentali che permettono ai router e agli altri
dispositivi di rete di instradare il pacchetto IPv4 attraverso Internet fino alla destinazione.
Campi dell’header:
1. Versione: È un campo di 4 bit che specifica la versione del protocollo. Per IPv4, il valore è
"4".
2. IHL Lunghezza dell'header: Normalmente è di 5 (che corrisponde a 20 byte), ma può
essere maggiore se sono presenti campi opzionali.
3. Tipo di servizio (ToS): Fornisce informazioni sul tipo di servizio richiesto per il pacchetto.
Può contenere informazioni sulla priorità e sulla qualità del servizio (QoS), utili per
gestire il traffico in base alla sua importanza o urgenza.
4. Lunghezza totale: Indica la lunghezza totale del pacchetto (intestazione + payload) in byte.
(al massimo è di 65.535 byte ma raramente supera i 1500)
5. ID, Flag e Offset di Frammentazione: (solo nel caso in cui si debba frammentare)
o ID: Identifica in modo univoco il pacchetto. È usato in caso di frammentazione per
ricomporre i pacchetti originali.
o Flag: Specifica se il pacchetto può essere frammentato e se ci sono altri frammenti.
(dopo è spiegato meglio)
o Offset di Frammentazione: Indica la posizione dei dati nel datagramma originale,
per aiutare nella ricostruzione.
6. Tempo di Vita (TTL - Time to Live): Questo campo limita il numero massimo di salti che
il pacchetto può effettuare nella rete. Ogni nodo riduce il TTL di 1; se raggiunge zero, il
pacchetto viene scartato, prevenendo cicli infiniti.
7. Protocollo: Indica il protocollo del livello superiore che deve elaborare il payload. Alcuni
esempi comuni sono TCP (valore 6) e UDP (valore 17).
8. Checksum dell’Intestazione: Campo di controllo per verificare l'integrità dell’intestazione.
Se il valore non corrisponde, il pacchetto è scartato.
 9. Indirizzo IP di Origine e di Destinazione: Indicano rispettivamente l’indirizzo IP del
mittente e del destinatario. Questi campi sono usati dai router per determinare il percorso.

I pacchetti IPv4 vengono trasmessi attraverso la rete in modo indipendente, ovvero ogni pacchetto
può seguire percorsi diversi fino alla destinazione. I router utilizzano le informazioni
nell'intestazione, come l’indirizzo di destinazione, per determinare la rotta migliore per il pacchetto.
Basandosi sul campo "lunghezza dell'intestazione" e sugli indirizzi IP contenuti nell’intestazione, la
TCAM consente di confrontare l’indirizzo di destinazione con gli indirizzi presenti nelle tabelle di
routing in modo molto rapido e parallelo.

Frammentazione dei pacchetti

La frammentazione è un processo necessario per trasmettere pacchetti di dati su Internet quando la
loro dimensione supera il limite imposto dall’MTU del collegamento.
Un pacchetto viene suddiviso in unità più piccole che possono passare attraverso il link. Ogni
frammento mantiene:
1. Lo stesso ID del pacchetto originale: Questo campo consente di associare tutti i frammenti
allo stesso pacchetto originale, in modo che possano essere riconosciuti e ricostruiti dal
destinatario.
2. Flag More Fragments (MF): Questo flag indica se ci sono altri frammenti dopo il
frammento corrente. Se è impostato su 1, significa che esistono altri frammenti; se è
impostato su 0, indica che si tratta dell’ultimo frammento. Il campo DF indica se quel
frammento può essere o meno frammentato. Se proprio non può essere frammentato e non
riesce a mandarlo o cambia strada o manda un messaggio di errore.
3. Offset di Frammentazione: Indica la posizione del frammento all’interno del pacchetto
originale. L’offset rappresenta la distanza, in byte, dal primo byte del pacchetto originale e
permette di ricomporre i frammenti nell’ordine corretto.

Indirizzamenti
l’interfaccia è il punto di contatto tra un dispositivo e il collegamento fisico a una rete.
Un host ha in genere un solo collegamento fisico alla rete, quindi una sola interfaccia, che
rappresenta il punto di connessione tra il dispositivo e la rete. Quando l'host deve inviare o ricevere
dati, lo fa tramite questa interfaccia. I router devono avere almeno due collegamenti per ricevere
dati da una rete e inoltrarli su un'altra. Ogni collegamento a una rete, come per l'host, è
un'interfaccia.
Ogni interfaccia deve avere un indirizzo IP univoco (escluso nel caso di NAT), che permette di
identificare la connessione del dispositivo su una determinata rete.
L'indirizzo IP è, quindi, associato all'interfaccia, non all'host o al router in sé. Questo perché ogni
interfaccia può essere considerata come una "uscita" o "entrata" della rete e deve avere un proprio
identificativo.

Indirizzi gerarchici (geografici)

Gli indirizzi IP vengono assegnati seguendo una gerarchia, spesso basata su una struttura geografica
o amministrativa. Per esempio: Un Provider (ISP) può assegnare un blocco di indirizzi a una
regione geografica specifica. All'interno della regione, i singoli indirizzi sono assegnati agli utenti
finali o alle reti locali.
L'instradamento dei pacchetti in Internet è reso più efficiente grazie alla gerarchia, poiché gli
indirizzi IP forniscono informazioni utili per "indirizzare" i pacchetti verso il loro percorso
geografico. I router lungo il percorso leggono solo la parte di rete dell'indirizzo e decidono di
conseguenza il percorso successivo.

Indirizzi flat
Gli indirizzi flat non seguono una struttura gerarchica; non includono informazioni su reti o
posizioni geografiche. Ogni indirizzo è univoco ma autonomo, senza alcun indizio su una possibile
gerarchia. Gli indirizzi flat sono comuni nelle reti locali, dove la necessità di instradare pacchetti su
vaste aree geografiche non è rilevante. Ad esempio: Gli indirizzi MAC (Media Access Control),
usati per identificare le schede di rete in reti locali, sono flat. Ogni scheda di rete ha un indirizzo
MAC unico, ma non fornisce informazioni geografiche o di rete.

Assegnamento degli indirizzi

In origine, gli indirizzi IP erano organizzati secondo una struttura fissa di classi, chiamata Classful
Addressing. Utilizzava le Classi di rete (A, B, C):
Il problema del Classful Addressing era che le reti di Classe C (che permettevano solo 254 host)
erano troppo piccole per molte aziende, mentre le reti di Classe A e B (con milioni o migliaia di
host) erano troppo grandi. Molti indirizzi IP risultavano sprecati perché le reti disponibili non
rispondevano ai bisogni intermedi di molte organizzazioni.
Per risolvere i limiti del Classful Addressing, è stato introdotto il CIDR (classless interdomain
resolution), che permette un’allocazione più flessibile degli indirizzi IP tramite una maschera di
sottorete variabile (subnet mask): Con CIDR, l’idea di classi fisse è stata abbandonata. Invece di
limitarsi a parti di rete da 8, 16 o 24 bit, in CIDR si può definire la lunghezza della parte di rete
utilizzando un numero di bit variabile, indicato nella notazione “slash” (ad esempio /24 o /25).
Questo numero dopo lo “/” indica quanti bit dell’indirizzo IP fanno parte della rete, e il resto è
riservato per gli host.
Vantaggio: flessibilità e si evitano sprechi di assegnazione.

Subnetting
Il Subnetting è una tecnica utilizzata per suddividere una rete IP in sottoreti più piccole, che
permette una gestione più efficiente degli indirizzi IP e facilita il controllo del traffico di rete.

Esempio di subnetting
Consideriamo l'indirizzo 192.168.1.7/24:
Indirizzo IP: 192.168.1.7 → in binario 11000000.10101000.00000001.00000111
Subnet Mask: /24, che corrisponde a 255.255.255.0 in decimale e
11111111.11111111.11111111.00000000 in binario.
Parte di rete: I primi 24 bit
dell’indirizzo 192.168.1.7 sono 11000000.10101000.00000001 (ovvero 192.168.1 in decimale).
Questa parte identifica la rete di appartenenza.
Parte di host: Gli ultimi 8 bit 00000111 (ovvero 7 in decimale) identificano il dispositivo specifico
(host) all’interno di quella rete.
In questo esempio, la rete 192.168.1.0/24 può contenere fino a 254 host
(da 192.168.1.1 a 192.168.1.254), poiché i due indirizzi (192.168.1.0 e 192.168.1.255) sono
riservati per la rete e il broadcast, rispettivamente.

Indirizzi speciali
Alcuni indirizzi speciali non possono essere utilizzati per configurare host all’interno di una rete:
L'indirizzo 0.0.0.0 viene utilizzato come indirizzo di default o indirizzo di "tutti gli indirizzi" in
alcune situazioni. Ad esempio, un dispositivo potrebbe utilizzarlo come indirizzo IP sorgente
quando invia pacchetto su un una rete se non ha ancora un indirizzo IP assegnato.
L'indirizzo 255.255.255.255, noto anche come indirizzo di broadcast limitato, viene utilizzato per
inviare pacchetti di broadcast a tutti i dispositivi nella stessa rete locale. Quando un dispositivo
invia un pacchetto a questo indirizzo, il pacchetto viene trasmesso a tutti i dispositivi nella LAN.
La subnet mask con prefisso /31 viene utilizzata quando sono presenti solo due router agli estremi
di un collegamento senza alcuna macchina intermedia. In condizioni normali, per una sottorete con
2 indirizzi IP (come in una subnet /30), uno degli indirizzi sarebbe riservato per la rete e l'altro per il
broadcast, rendendo inutilizzabili entrambi per gli host. Con una subnet /31, invece: Non ci sono
indirizzi per rete e broadcast. Entrambi gli indirizzi sono usati per i due dispositivi del collegamento
punto-punto.

Configurazione delle reti

In una stessa LAN, ogni dispositivo deve avere un indirizzo IP che appartenga alla stessa
subnet per poter comunicare con gli altri dispositivi. Se si cambia l'indirizzo IP di una macchina in
modo che non rientri più nella subnet della rete, questa non sarà più parte della rete e non potrà
comunicare con gli altri dispositivi.
È possibile configurare più indirizzi IP sulla stessa scheda di rete. Questo processo si chiama IP
aliasing. Questa configurazione è utile per far comunicare reti isolate o per integrare dispositivi di
subnet diverse all'interno della stessa rete fisica, permettendo così la gestione centralizzata o
l’accesso ad altri servizi senza necessità di ulteriori hardware.
Un indirizzo IP è generalmente associato a una sola scheda di rete, il che significa che un IP
identifica un singolo percorso di accesso per la rete.
Una singola scheda di rete, però, può avere più indirizzi IP (grazie all'IP aliasing).

Lezione 8: ARP e RARP livello di rete – continuo

Ethernet è un protocollo di livello DLL che si occupa di trasmissione di dati su LAN cablate
attraverso i cavi Ethernet. Grazie a Ethernet, i dispositivi di rete possono comunicare tra loro modo
efficiente e affidabile, all'interno di una LAN. Un frame Ethernet è il pacchetto di dati che viene
trasmesso attraverso la rete Ethernet.

Il MAC Andress (Media Access Control) è un identificatore unico assegnato a ciascuna scheda di
rete da parte del produttore e rimane generalmente invariato per tutta la vita del dispositivo,
utilizzato per identificare i dispositivi all'interno di una LAN.
È suddiviso in due parti: Organizationally Unique Identifier (OUI): I primi 3 byte identificano il
produttore (es. 00:1A:2B). Gli ultimi 3 byte sono assegnati in modo univoco dal produttore per
distinguere i dispositivi prodotti.

MAC address nella LAN

Il MAC address viene utilizzato dai protocolli di rete come Ethernet per instradare i pacchetti
all'interno della LAN. Quando un dispositivo invia un pacchetto a un altro dispositivo della stessa
LAN, il pacchetto passa dal livello di rete (che utilizza gli indirizzi IP) al livello data link (che
utilizza i MAC address). Essendo un indirizzo flat (senza gerarchia), il MAC address non fornisce
informazioni su dove si trova fisicamente un dispositivo.
ARP (Address Resolution Protocol) è un protocollo utilizzato per tradurre un indirizzo IP in
un indirizzo MAC all'interno della stessa subnet. Questo processo è necessario perché, anche se i
dispositivi comunicano utilizzando gli indirizzi IP a livello di rete locale, la trasmissione effettiva
avviene tramite gli indirizzi MAC.
Come funziona? Quando un dispositivo in una LAN (per esempio, il computer A) deve inviare un
pacchetto IP a un altro dispositivo nella stessa subnet (per esempio, il computer B), conosce
l’indirizzo IP di destinazione ma non il MAC address. Dato che la comunicazione in una LAN
avviene tramite MAC address, il computer A utilizza ARP per ottenere l'indirizzo MAC associato
all'indirizzo IP del computer B. Il computer A invia una ARP request come messaggio di broadcast
nella rete locale; quindi, viene ricevuta da tutti i dispositivi della LAN. Questa richiesta contiene
l'indirizzo IP del destinatario (computer B) e chiede: “Qual è il MAC address associato a questo
IP?”. Essendo un broadcast, la richiesta viene ricevuta da tutti i dispositivi della stessa subnet, ma
solo il dispositivo con l'indirizzo IP specificato (computer B) risponderà. Quando il computer B
riceve la richiesta ARP e riconosce che l’indirizzo IP nella richiesta corrisponde al proprio, invia
una ARP reply direttamente al computer A. Questa risposta contiene il MAC address del
computer B e viene inviata come messaggio unicast (solo al computer A).
Una volta ricevuta la risposta ARP, il computer A memorizza il MAC address del computer B
nella cache ARP, un’area di memoria che conserva temporaneamente le corrispondenze tra
indirizzi IP e MAC per evitare di inviare continuamente richieste ARP. La cache ARP viene
aggiornata periodicamente per rimuovere le associazioni non più valide, ma viene anche aggiornata
in caso di nuove richieste o risposte ARP. La cache riduce il traffico di rete e migliora l'efficienza
della comunicazione all'interno della LAN.
ARP si affida alle cache ARP mantenute localmente sui dispositivi della rete per evitare di ripetere
richieste per lo stesso indirizzo IP. Tuttavia, queste cache sono gestite localmente e non fanno parte
del protocollo stesso. (es. A salva il MAC di B nella sua cache ARP per utilizzarlo nelle
comunicazioni future. Se A o B si riavviano, l'informazione viene persa e sarà necessaria una nuova
richiesta ARP.
ARP non ha un meccanismo di autenticazione, il che significa che qualunque dispositivo in una
rete locale può inviare o ricevere frame ARP senza dover dimostrare la propria identità.
In caso di risposte ARP concorrenti, il dispositivo che effettua l'ARP Request accetta l'ultima
risposta ricevuta, lasciando la rete vulnerabile agli attacchi di spoofing. L'ARP cache è progettata
per essere dinamica. Quando un nuovo ARP Reply viene ricevuto, sostituisce l'entry precedente per
l'IP corrispondente. ARP non ha un meccanismo per determinare quale dispositivo è "giusto".
Accettare l'ultimo pacchetto è semplicemente un risultato del design "stateless" del protocollo.
!!!ARP è Stateless il che significa che non tiene traccia delle comunicazioni precedenti. Di
conseguenza un dispositivo non ha bisogno di inviare una richiesta ARP per poter accettare una
risposta ARP. Il fatto che ARP sia stateless semplifica la sua implementazione ma lo rende
vulnerabile a problemi di sicurezza, poiché un attaccante può semplicemente inviare risposte ARP
non richieste (noti come gratuitous ARP replies) a tutti i dispositivi sulla rete, aggiornando la loro
cache con indirizzi MAC falsi.
In un attacco di ARP spoofing, un attaccante invia frame ARP falsificati per associare il proprio
indirizzo MAC all'indirizzo IP di un altro dispositivo. In questo modo, il traffico destinato al
dispositivo vittima viene dirottato verso l’attaccante, permettendogli di: 1. Intercettare il traffico e
leggere i dati trasmessi. 2. Modificare i dati prima di inoltrarli al destinatario legittimo (attacco
Man-in-the-Middle dove l’attaccante posiziona se stesso tra due dispositivi, facendo sì che entrambi
inviino il traffico tramite l’attaccante, che può quindi leggere e modificare i dati). 3. Bloccare il
traffico, impedendo alla vittima di comunicare con altri dispositivi.
Situazioni di HIJACKING (dirottamento) in cui l’attaccante prende il controllo di un blocco di
indirizzi IP, ad esempio di un’azienda, che non gli appartiene, permettendogli di intercettare,
alterare o bloccare il traffico, causando disservizi o rubando dati.
RARP
RARP (Reverse Address Resolution Protocol) è un protocollo utilizzato per ottenere un indirizzo
IP partendo dall'indirizzo MAC, svolgendo quindi il processo opposto rispetto ad ARP. RARP è
stato ideato per risolvere il problema dei dispositivi diskless (senza disco), come terminali o
workstation senza disco rigido, che non possono memorizzare un indirizzo IP permanente.
Questi dispositivi, al momento dell'avvio, conoscono solo il loro indirizzo MAC (che è fisso e
univoco), ma non hanno un indirizzo IP configurato per comunicare sulla rete. Quando si avvia,
invia una richiesta RARP come messaggio broadcast sulla rete, contenente il proprio indirizzo
MAC. Un server RARP sulla stessa rete riceve la richiesta e, grazie a una tabella di associazione
tra MAC e IP, risponde con un pacchetto RARP reply che fornisce al dispositivo l’indirizzo IP
assegnato. In questo modo, il dispositivo riceve temporaneamente un indirizzo IP che gli permette
di comunicare con altri dispositivi sulla rete. La mappatura degli indirizzi MAC agli indirizzi IP
viene configurata manualmente, cioè l'amministratore di rete assegna a ciascun indirizzo MAC un
indirizzo IP specifico. Questo è un processo che avviene all'inizio, quando la rete viene configurata.
RARP presenta alcune limitazioni e vulnerabilità, che ne hanno limitato l’uso e portato
all’introduzione di protocolli più avanzati per gestire IP dinamici come DHCP:
1. Assenza di Autenticazione: Questo significa che qualsiasi dispositivo potrebbe
teoricamente inviare richieste RARP, lasciando spazio a possibili attacchi di spoofing o
di falsificazione delle risposte.
2. Mancanza di Flessibilità: RARP è un protocollo semplice e statico. Per ogni dispositivo
sulla rete, deve esistere una tabella di associazione MAC-IP predefinita nel server RARP,
limitando l'automazione e la flessibilità della gestione degli indirizzi IP.
3. Incompatibilità con Reti più Complesse: RARP è progettato per funzionare solo
all'interno di una LAN e non supporta le configurazioni più complesse di reti moderne. Per
esempio, !!!non può assegnare altre informazioni di rete, come la subnet mask o l'indirizzo
del gateway (come fa DHCP). Di fatto non viene più utilizzato nelle reti moderne.

BOOTP (bootstrap protocol)

Il BOOTP è un protocollo di rete utilizzato per consentire a un computer di avviarsi e ricevere un
indirizzo IP, in particolare viene utilizzato durante la fase di boot del computer, quando il sistema
deve acquisire un indirizzo IP valido per poter comunicare sulla rete.
Il client BOOTP invia un messaggio di richiesta di boot (BOOTREQUEST) contenente il proprio
indirizzo MAC al server BOOTP, che risponde con un messaggio di offerta di boot (BOOTREPLY)
contenente l'indirizzo IP da assegnare al client.

Requisiti di configurazione di una macchina

Per essere configurata in una rete, una macchina ha bisogno di diverse informazioni tra cui:
1. Indirizzo IP: è l'indirizzo numerico univoco assegnato alla macchina per identificarla sulla rete.
L'indirizzo IP può essere assegnato manualmente o automaticamente da un server DHCP.
2. Subnet mask: è un valore numerico che permette di definire la suddivisione logica della rete in
sottoreti. La subnet mask definisce quali bit dell'indirizzo IP identificano la parte di rete e quali bit
identificano la parte di host.
3. Gateway predefinito: è il dispositivo che prende il traffico di rete destinato a indirizzi IP che
non appartengono alla rete locale e lo instrada verso la rete di destinazione.
4. DNS: è l’indirizzo IP del server DNS (Domain Name System) che consente alla macchina di
risolverei nomi dei domini in indirizzi IP.
5.Nome della macchina: è il nome utilizzato per identificare la macchina sulla rete, che può essere
utilizzato per la risoluzione dei nomi di dominio.
6. Indirizzo MAC: è l’indirizzo univoco assegnato dalla scheda di rete del dispositivo, utilizzato a
livello data link per identificare la macchina all’interno della LAN.
7. Protocolli di rete: la macchina deve essere configurata in modo da supportare i protocolli di rete,
come Ethernet.

Come fa una macchina a capire che la macchina a cui vuole inviare il messaggio non si trova nella
sua rete? Ogni macchina conosce il suo IP e da questo ricava la sua subnet mask. Dopodiché,
trovata la propria subnet, effettua un AND tra la sua maschera e la maschera di destinazione, se
questa corrisponde allora sa che la macchina è nella sua sottorete e dunque la invia nella subnet,
altrimenti invia il frame all’interfaccia del router che si occuperà di inviare il pacchetto.

Comunicazione su reti differenti

Se le macchine si trovano nella stessa rete LAN possono comunicare. Nel caso in cui le macchine si
trovano in reti differenti la situazione si complica: quando un pacchetto viene trasmesso attraverso
una rete, ogni dispositivo di rete che inoltra il pacchetto sostituisce l'indirizzo MAC del mittente
con il proprio indirizzo MAC come sorgente del pacchetto, e l'indirizzo MAC della destinazione
con l'indirizzo MAC del prossimo dispositivo di rete che inoltrerà il pacchetto. In questo modo, il
pacchetto può essere correttamente instradato attraverso la rete.

Tuttavia, è importante sottolineare che l'indirizzo MAC non cambia casualmente, ma viene
sostituito da una macchina intermedia solo durante il passaggio del pacchetto attraverso quella
macchina. L'indirizzo MAC originale del mittente e della destinazione viene preservato all'interno
del pacchetto stesso.
Se la destinazione del pacchetto si trova fuori della LAN, allora il pacchetto deve essere inviato al
router di rete. Il router funge da gateway predefinito per la rete e viene utilizzato per instradare i
pacchetti di dati tra le diverse reti. Il router analizza l’indirizzo IP di destinazione del pacchetto e lo
inoltra alla rete corretta fino a quando non raggiuge la destinazione finale. A livello di Data Link
Layer, il dispositivo sorgente invia il pacchetto al MAC address del router. Un router spesso ha più
interfacce di rete: una per la connessione alla rete locale (LAN) e una per la connessione alla rete
esterna (internet, WAN). Ogni interfaccia avrà un proprio MAC address univoco.
Discussione d’esame
Abbiamo due LAN separate da un Router (Livello 3 quindi) di mezzo. Ha infatti sia indirizzi IP che
MAC per ogni interfaccia. Analizziamo 2 casi: supponiamo che una macchina abbia necessità di
parlare con un’altra macchina, che potrebbe trovarsi sia nella sua stessa LAN che in una LAN
differente, anche attraversando più router.

Stessa LAN:
Il mittente deve solo scoprire che il destinatario appartiene alla stessa LAN; quindi, può preparare
un frame Ethernet (ricordiamo che la comunicazione avviene a livello DLL, non IP, perché il
datagramma IP è incapsulato nella frame Ethernet). Deve solo scoprire il MAC Address del
destinatario, cosa che può fare con ARP mandando in broadcast la richiesta. Questa macchina potrà
rispondere tranquillamente alla richiesta broadcast in quanto si trova sulla stessa LAN.
Questo processo funziona perché entrambe le macchine sono raggiungibili direttamente a livello
di Data Link Layer.
LAN Differenti:
Se il destinatario è fuori dalla sua LAN non può usare ARP per scoprire il MAC address della
destinazione, per due motivi:
a Il router è come una barriera tra le due LAN: ha due interfacce separate per ciascuna LAN
(quella rossa e quella verde); quindi, ciascuna interfaccia lavora su una rete di
collegamento separata. Quando un pacchetto IP deve attraversare il router per andare da
una LAN all'altra, il router “scarta” l’intestazione Ethernet del pacchetto (contenente il
MAC address del mittente e destinatario). Una volta raggiunto il router, quindi, l'indirizzo
MAC originale non serve più, perché il router rielabora il pacchetto, ricreando una nuova
intestazione Ethernet per la LAN di destinazione con il MAC address della sua interfaccia di
uscita verso la rete di destinazione.
b Non esiste solo Ethernet: Ci sono reti DLL che non hanno il MAC Address (per esempio
tante macchine collegate tutte punto a punto), quindi semplicemente dire che il mittente
vuole conoscere il MAC Address della destinazione è inutile, perché potrebbe anche non
esistere.
Soluzione: Quando il mittente vuole inviare un pacchetto a un dispositivo fuori dalla propria LAN,
deve inviare il pacchetto al router. Il router riceve il pacchetto, spacchetta il frame Ethernet
originale (leggendo solo il pacchetto IP), e poi crea un nuovo frame Ethernet per la LAN di
destinazione, che conterrà i MAC address della LAN di destinazione (se Ethernet è supportato su
quella LAN).

Tabella di Routing di ogni host

Ogni macchina all'interno di una rete fa da router ed è dotata di una tabella di routing che serve ad
associare un indirizzo IP di destinazione a un'interfaccia di rete sulla stessa macchina o su un router
di rete.
Ogni riga della tabella contiene informazioni su:

1. Destinazione: l'indirizzo IP (o intervallo di indirizzi) della rete o del dispositivo di

destinazione.
2. Maschera di sottorete: la maschera di sottorete che aiuta a determinare se l'indirizzo di
destinazione appartiene alla stessa rete locale o a una rete remota.
3. Gateway predefinito (next hop): l'indirizzo IP del router o del dispositivo che deve ricevere
il pacchetto se la destinazione non si trova nella stessa rete.
4. Interfaccia: la porta di rete o l'interfaccia su cui inviare il pacchetto per raggiungere la
destinazione.

Es. una voce della tabella

Quando una macchina deve inviare un pacchetto di dati, consulta la tabella di routing per
determinare il percorso migliore per la destinazione. Se la destinazione si trova sulla stessa subnet,
la macchina invia il pacchetto direttamente alla destinazione. In caso contrario, cerca il router di
rete predefinito (gateway predefinito) e invia il pacchetto a questo router per l'instradamento verso
la destinazione.
DHCPv4 (Dynamic Host Configuration Protocol versione 4)
Il protocollo DHCPv4 è un protocollo di rete utilizzato per l'assegnazione dinamica degli indirizzi
IP alle macchine sulla rete, apprendere informazioni sulla propria maschera di sottorete, l’indirizzo
del router per uscire dalla sottorete e in fine l’indirizzo del DNS server locale. DHCPv4 consente
alle macchine di ottenere un indirizzo IP valido in modo automatico, senza la necessità di
assegnarlo manualmente, per questo si dice plug&play.
Supporta sia l’assegnazione di indirizzi statici, ma anche quella di indirizzi IP temporanei (o
dinamici), noti come indirizzi IP "leasing". Nel primo caso, un server DHCP può essere configurato
per assegnare sempre lo stesso indirizzo IP a un dispositivo in base al suo MAC address. Nel
secondo caso, l'indirizzo IP viene assegnato alla macchina solo per un periodo di tempo limitato
(lease time). Prima che il lease scada, il client deve inviare una richiesta di rinnovo al server per
continuare a utilizzare lo stesso indirizzo. Se il client non rinnova il lease, l'indirizzo IP viene
restituito al pool di indirizzi disponibili e può essere assegnato ad altri dispositivi. Questo consente
di gestire in modo più efficiente gli indirizzi IP disponibili sulla rete. Il protocollo DHCPv4 è
Client-Server e prevede quattro fasi principali per l'assegnazione dell'indirizzo IP:
1. Scoperta (DHCP discover): inizia quando il client DHCP si connette alla rete e
invia un messaggio di scoperta in broadcast sulla rete locale alla ricerca di un server
DHCP disponibile. Il messaggio contiene informazioni come l'identificatore del
client, il tipo di hardware utilizzato e le opzioni di configurazione richieste.
2. Offerta (DHCP offer): il server DHCP riceve il messaggio di scoperta e invia un
messaggio di offerta al client. In questo messaggio, il server offre un indirizzo IP
disponibile al client DHCP, la durata della concessione dell’indirizzo e altre
informazioni di configurazione come subnet mask e l'indirizzo del gateway e i server
DNS.
3. Richiesta (DHCP request): il client DHCP riceve il messaggio di offerta dal server
e invia un messaggio di richiesta per confermare l'assegnazione dell'indirizzo IP
offerto dal server. In questo messaggio, il client DHCP richiede l'assegnazione
dell'indirizzo IP offerto dal server. Se il client riceve più offerte da diversi server,
sceglie una e la comunica esplicitamente agli altri server per informare che non
devono assegnare quell'indirizzo IP.
4. Conferma (DHCP Ack): il server DHCP riceve il messaggio di richiesta e invia un
messaggio di ACK al client per confermare l'assegnazione dell'indirizzo IP richiesto
e ora può utilizzarlo. Il messaggio ACK contiene l'indirizzo IP assegnato al client,
insieme alle altre informazioni di configurazione richieste.
Il server DHCP mantiene un registro dello stato delle assegnazioni degli indirizzi IP ai client
(stateful), però non prevede l'autenticazione.
Perché sono necessari 4 passaggi? Per prevenire conflitti di indirizzi IP.
Immaginiamo che più di un server DHCP esista nella rete e che ogni server stia cercando di
assegnare indirizzi IP. Se un client ricevesse un indirizzo IP senza conferma, ci sarebbe il rischio
che un altro server DHCP possa assegnare lo stesso indirizzo IP a un altro dispositivo, creando
un conflitto di indirizzi IP. La sequenza di REQUEST e ACK serve proprio a: Confermare che il
server che ha fatto l'offerta è l'unico responsabile di quel determinato indirizzo IP. Escludere
conflitti nel caso in cui più server DHCP rispondano a una richiesta di un client. In pratica, il client
invia la REQUEST per dichiarare esplicitamente al server quale indirizzo IP vuole. Il server,
quindi, riserva l'indirizzo e lo "blocca" per quel client.

NAT (network acces translation)

Esistono centinaia di migliaia di reti private, molte delle quali usano un unico spazio di
indirizzamento, per scambiare pacchetti fra i loro dispositivi. Ovviamente, quelli inviati sull'Internet
globale non possono utilizzare questi indirizzi come sorgente o destinazione. Sappiamo che un
dispositivo per stare in rete ha bisogno di un IP. Se usassimo sempre questo tipo di connessione,
ogni sottorete (anche quelle di casa) avrebbe bisogno di uno spazio molto ampio di IP da usare e al
crescere della LAN questi dovrebbero ingrandirsi ancora e ancora ma come sappiamo ipv4 permette
circa 4, 3 miliardi di combinazioni univoche.
Ma se gli indirizzi privati hanno significato solo all'interno di una data rete, come viene gestito
l'indirizzamento dei pacchetti relativi all'Internet globale, in cui gli indirizzi sono
necessariamente univoci? La risposta è il NAT. Il NAT risolve il problema della scarsità di indirizzi
IPv4 e migliora la sicurezza della rete privata (dato che IPv6 offre molti più indirizzi IP, in teoria il
NAT non sarebbe necessario in reti IPv6; tuttavia, alcune reti continuano a utilizzarlo).
NAT è una tecnologia di rete che permette di mappare indirizzi IP locali (interni a una LAN) su un
singolo indirizzo IP pubblico (utilizzato per le comunicazioni esterne), e viceversa.
In parole semplici, consente a dispositivi all'interno di una rete privata di comunicare con l'esterno
(come Internet) utilizzando un unico indirizzo IP pubblico.

I router abilitati al NAT non appaiono come router al mondo esterno, ma si comportano come un
unico dispositivo con un unico indirizzo IP.
Quindi per la comunicazione gli utenti della sottorete avranno tutti l’indirizzo IP del router a cui
sono collegati ma saranno anche identificati tra loro con un indirizzo IP privato che avrà senso solo
lì. Tutti i datagrammi arrivati al router, avranno sempre lo stesso IP e dunque, per distinguere i vari
client connessi alla rete utilizziamo una tabella di traduzione NAT.

Esempio: Un client con IP 192.168.56.100 fa richiesta di una pagina server (porta 80) e così manda
la richiesta al suo router partendo con una porta 1234. Il router NAT che riceve il datagramma
cambia la porta sostituendola con un’altra 5580 e sostituisce l’indirizzo IP sorgente con il proprio
indirizzo pubblico. Poi registra questa associazione nella tabella. Quando il datagramma di risposta
arriva all'indirizzo IP pubblico e alla porta pubblica, il NAT consulta la tabella. Trova l'associazione
originale e modifica il pacchetto sostituendo l'indirizzo IP pubblico e la porta pubblica con
l'indirizzo IP privato e la porta privata corrispondenti. Il pacchetto viene quindi inviato al
dispositivo interno. Se una connessione rimane inattiva per troppo tempo, il NAT elimina la voce
corrispondente dalla tabella, liberando risorse.

Abbiamo però delle pecche, infatti il NAT usa le porte per identificare gli host, cosa per cui questi
non erano progettati (ambiguità). Le porte TCP/UDP, progettate originariamente per distinguere
processi di un singolo host, vengono sfruttate dal NAT per identificare gli host stessi nella rete
privata. L'uso intensivo delle porte può portare a esaurimento in scenari con un elevato numero di
connessioni simultanee.

Inoltre, il NAT viola il principio end to end che prevede che i dispositivi di origine e destinazione
possano comunicare direttamente senza modifiche ai pacchetti in transito, dovuto alla netta
separazione tra spazi di indirizzamenti pubblici e privati.
La distinzione netta tra indirizzi pubblici e privati crea uno scenario in cui gli indirizzi privati
possono riutilizzarsi in reti diverse, ma ciò introduce ambiguità nelle connessioni in alcuni scenari
complessi (es., VPN o reti sovrapposte).
Inoltre, protocolli che crittografano l'intestazione IP possono non funzionare correttamente con
NAT, poiché il NAT non può modificare i dati crittografati.
NB. Il server NAT non necessariamente è un router ma potrebbe essere una macchina sulla rete in
grado di gestire pacchetti IP e svolgere traduzioni di indirizzi. Il NAT è stateful per definizione e
funziona registrando una connessione solo quando il primo pacchetto parte dalla rete interna.
Mantiene uno stato attivo per ogni connessione registrata. Questo stato è rappresentato dalla tabella
di traduzione.
Questo impedisce a dispositivi esterni di avviare connessioni con dispositivi interni. Protegge la rete
privata, ma introduce problemi per servizi che richiedono connessioni in ingresso non previste.

Gestione di più dispositivi

Diciamo che ogni connessione è unica perché la socket lo è, cioè ogni tupla di connessione.
Nel caso in cui più dispositivi interni comunichino contemporaneamente: Il NAT usa le porte
pubbliche per distinguere le connessioni. Anche se tutti i dispositivi usano la stessa porta privata
(es. 12345), il NAT assegna porte pubbliche diverse a ciascuna connessione, garantendo unicità.
Esempio di tabella di traduzione con più dispositivi:

Lezione 9: IPv6 livello di rete – continuo

Ad un certo punto gli indirizzi IP a 32 bit a disposizione cominciarono a scarseggiare; dunque, si
cominciò a pensare ad un nuovo modo di indirizzamento che avrebbe sostituito e migliorato IPv4. I
cambiamenti furono:
Tabelle di Routing: Dentro i router sono presenti delle tabelle che indicano le porte di uscita in
base alla destinazione che il pacchetto in ingresso deve raggiungere. Le tabelle di Routing iniziano a
diventare parecchio complicate a causa del vecchio standard IP che assegnava in modo disordinato
le locazioni geografiche. Dato che gli indirizzi IPv4 sono gerarchici, bisogna distribuirli secondo un
certo criterio, ma purtroppo i gruppi di indirizzi sono stati assegnati in maniera disordinata.

Sicurezza: Il livello di sicurezza di IPv4, posto dopo il livello di trasporto, tiene in chiaro tutti i dati
successivi, inclusi gli indirizzi IP e le porte.
Questi dati sensibili vengono trasmessi in chiaro, rendendoli vulnerabili agli attacchi di spoofing
degli indirizzi IP. IPv6 invece supporta la crittografia e la sicurezza dei pacchetti attraverso
l'utilizzo di IPsec, un insieme di protocolli di sicurezza che forniscono autenticazione, integrità dei
dati e crittografia per i pacchetti IP.

Autoconfigurazione: in IPv4, la configurazione degli indirizzi IP e delle impostazioni di rete di un

dispositivo deve essere effettuata manualmente o automaticamente mediante l'utilizzo di protocolli
come DHCP. L'autoconfigurazione plug and play è una funzionalità di IPv6 che consente ai
dispositivi di configurare automaticamente la propria interfaccia di rete, senza la necessità di un
amministratore di rete o di un server DHCP.
Tuttavia, rimane essenziale DHCPv6 perché plug&play non fornisce gateway predefinito e
server DNS.

Gestione della qualità del servizio (QoS): consente di garantire determinati livelli di servizio per
le applicazioni. In IPv4, la QoS è gestita mediante il campo Type of Service (ToS) nell'header IP
ma non viene mai sfruttato.
IPv6 il bit Flow Label (etichetta di flusso) consente di fornire un livello di servizio differenziato per
flussi di traffico specifici sulla rete.

Indirizzamento Multicast: in IPv4, l'indirizzamento multicast è limitato ai soli indirizzi di classe

D, che consentono la trasmissione di dati a un gruppo di destinatari. Lo spazio di indirizzamento
multicast in IPv4 è limitato e non è sufficiente per supportare un gran numero di gruppi multicast.
Gli indirizzi multicast IPv6 sono un sottoinsieme degli indirizzi IPv6 e hanno una struttura specifica
per supportare l'invio di pacchetti a più host contemporaneamente. Gli indirizzi multicast
IPv6 iniziano con il prefisso `ff`, seguito da altri campi che consentono una maggiore flessibilità
nella definizione di gruppi multicast.

Indirizzamento host mobili: consente a un dispositivo di mantenere la stessa configurazione di

rete IPv6 mentre si sposta da una rete a un'altra. Un dispositivo mobile possiede un indirizzo IPv6
permanente, noto come "indirizzo di casa", che è associato alla sua interfaccia di rete. Quando il
dispositivo si sposta in una nuova rete, ottiene un nuovo indirizzo IPv6 temporaneo, noto come
"indirizzo di cura", sulla nuova rete. Il dispositivo continua a utilizzare l'indirizzo di casa come il
suo indirizzo permanente, ma utilizza l'indirizzo di cura come l'indirizzo sorgente per tutte le
comunicazioni in uscita sulla nuova rete. In questo modo, le comunicazioni in uscita sembrano
provenire dalla nuova rete, anche se il dispositivo conserva il suo indirizzo permanente.

Datagramma IPv4 e IPv6 a confronto

La dimensione del datagramma IPv4 è variabile a seguito di campi opzionali che fanno passare la
dimensione dell'header da 20 fino a 60 byte, questo rende complicata la ricerca attraverso le
memorie associative. L'header in IPv6 ha infatti una lunghezza fissa di 40 byte, il che permette di
rimuovere il campo che specifica la lunghezza dell'header. Vediamo i vari campi:
In quanto non veniva utilizzato è stato rimosso anche il controllo dell'integrità dell'header tramite
l'header checksum.
Versione: versione di IP che stiamo usando quindi 6.
Classe di traffico: Può essere utilizzato per attribuire delle priorità a dei datagrammi in un flusso.

Etichetta di flusso: Campo a 20 bit utilizzato per identificare specifici datagrammi

Lunghezza del payload: Intero senza segno che indica il numero di byte nel datagramma IPv6
dopo i 40 byte fissi.
Intestazione successiva: Indica da quale protocollo verrà preso il datagramma (UDP/TCP).
TTL: non rappresentava un tempo ma un numero di nodi nel caso di IPv4, con IPv6 questo campo
identifica invece un tempo reale massimo, entro il quale il pacchetto deve arrivare a destinazione o
viene scartato.
In IPv6 viene meno il campo protocol e viene sostituito con next header, ovvero delle liste linkate
nelle quali ogni nodo è un servizio o header opzionale che viene aggiunto al servizio già esistente.
Un header opzionale contiene come primo campo un parametro "next header" che contiene il link al
prossimo campo, messo all'inizio in quanto più veloce da trovare perché ogni campo ha lunghezza
variabile. Un secondo campo specifica appunto la lunghezza dell'header opzionale. Sono stati tolti i
vari flag, offset ecc. e sono stati inseriti tutti come header opzionali.
Non è possibile riassemblare la lista linkata inserendo dei nodi in mezzo e quindi il solo router
mittente può eseguire la frammentazione del pacchetto ed è stato inoltre specificato un MTU
minimo di 1280 byte per supportare un trasferimento tramite IPv6. In IPv4 se si perde un
frammento si necessita di ritrasmettere l'intero pacchetto, IPv6 quindi obbliga a non poter
frammentare. Viene previsto un header anche per la sicurezza "authentication header" che codifica
tutto il resto del pacchetto.
In pratica con IPv6, il campo di offset del frammento è stato rimosso dall'intestazione del pacchetto,
e quindi i router intermedi non possono frammentare il pacchetto. Se un router intermedio riceve un
datagramma IPv6 troppo grande, lo elimina e invia al mittente un messaggio d’errore ICMP.
Invece, la frammentazione deve essere gestita dai dispositivi sorgente, che devono suddividere i dati
in pacchetti con una dimensione inferiore al payload massimo definito da IPv6.

Passaggio da IPv4 a IPv6

Il passaggio da IPv4 a IPv6 non è stato semplicissimo data la vastità di macchine connesse a
Internet. Il metodo più diffuso è quello del Tunneling. Supponiamo che due nodi IPv6 vogliano
comunicare ma di mezzo, hanno dei router intermedi IPv4 che chiameremo Tunnel.
I router IPv6 notando che devono passare un pacchetto ad un router IPv4, prendono il datagramma
IPv6 e lo incapsulano in uno IPv4 in modo che sia possibile il trasporto di questo datagramma.
Appena questo datagramma arriva ad un nodo IPv6 questo si accorgerà che questo contiene un
datagramma di tipo IPv6 grazie al flag che contiene il numero di protocollo impostato a 41.

Struttura indirizzo IPv6

Un indirizzo IPv6 ha una struttura di 16 byte, ovvero 128 bit, divisi in 8 gruppi di 16 bit (ovvero 8
gruppi da 4 nibble) ciascuno, separati da due punti (:).
Un indirizzo IPv6 è scritto in notazione esadecimale, che rappresenta ogni gruppo di 16 bit con un
numero esadecimale da 0 a F. Per facilitare la scrittura degli indirizzi IPv6, è possibile omettere gli
zeri iniziali di ogni gruppo di 16 bit e comprimere i gruppi di zeri consecutivi in un singolo
gruppo di zeri, indicato con i due punti (::). Tuttavia, questa compressione può essere utilizzata solo
una volta in ogni indirizzo IPv6.
Un esempio di indirizzo IPv6 scritto in notazione esadecimale è:
2001 : 0db8 : 85a3 : 0000 : 0000 : 8a2e : 0370 : 7334
Questo stesso indirizzo potrebbe essere scritto con la compressione dei gruppi di zeri consecutivi:
2001 : db8 : 85a3 :: 8a2e : 370 : 7334

Subnet mask in IPv6

La subnetting in IPv6 è analoga a quella in IPv4, ma con l'utilizzo di indirizzi a 128 bit anziché a 32
bit. Ciò significa che il numero di subnet disponibili è molto più elevato rispetto ad IPv4.
Per indicare la maschera di sottorete in IPv6, si utilizza il prefisso di sottorete, che specifica quanti
bit dell'indirizzo IPv6 sono riservati alla sottorete. Il prefisso di sottorete viene solitamente
specificato come un multiplo di 16 bit, ovvero un blocco di 4 nibble. Ad esempio, se si utilizza un
prefisso di sottorete di /64, i primi 64 bit dell'indirizzo IPv6 sono riservati alla sottorete, mentre i
restanti 64 bit sono riservati all'identificatore dell'interfaccia.

Indirizzi riservati (globali, locali e di sito)

- Indirizzi globali iniziano con 2000::/3. Indirizzi univoci utilizzati per la comunicazione su
Internet e reti globali assegnati da enti ufficiali (IANA, RIR). Equivalenti agli indirizzi IPv4
pubblici.
- Indirizzi locali (Unique Local Addresses – ULA) iniziano con FE80::/64 Indirizzi utilizzati
per la comunicazione all'interno di reti private (non instradabili su Internet).
Questi indirizzi vengono utilizzati per la comunicazione tra nodi della stessa rete locale, ad
esempio tra due computer collegati alla stessa LAN e non possono essere assegnati a
dispositivi su reti differenti. Gli indirizzi local link IPv6 sono simili agli indirizzi privati
 IPv4 in quanto entrambi sono utilizzati all'interno di una rete privata e non sono accessibili
direttamente dall'esterno della rete.
- Gli indirizzi di sito (Site-Local Addresses - Obsoleti) iniziano con FEC0::/10 Indirizzi
originariamente progettati per comunicazioni all'interno di un sito specifico, ma
ora deprecati. Erano simili agli indirizzi locali ma con un ambito più ampio, limitato a un
"sito". Erano pensati per reti di grandi organizzazioni o campus.

EUI-64 (extended unique identifier-64)

Gli indirizzi IPv6 globali, ovvero quelli che è possibile utilizzare per navigare in rete, vengono
autogenerati a partire dal MAC address della scheda di rete del dispositivo stesso.
L'EUI-64 è un metodo utilizzato in IPv6 per generare automaticamente la parte finale dell'indirizzo
IP (l'identificatore dell'interfaccia) a partire dall'indirizzo MAC del dispositivo. EUI-64 usa
l'indirizzo MAC della scheda di rete, composto da 6 byte (48 bit) e lo modifica inserendo un blocco
FF:FE da 2 byte (16 bit) in mezzo tra i primi e gli ultimi tre byte del MAC, ottenendo i 64 bit che
identificano l'interfaccia di rete.

Questo metodo semplifica la configurazione automatica degli indirizzi IPv6 per le interfacce di rete,
garantendo anche l'unicità degli identificatori.
L'indirizzo IPv6 completo viene generato combinando:
 I primi 64 bit dal prefisso della rete (dato dal router).
 I secondi 64 bit calcolati con l'EUI-64.
Un router IPv6 pubblica periodicamente informazioni sulla rete tramite i messaggi ICMPv6 Router
Advertisement, che includono il prefisso della rete (es. 2001:db8::/64). (L'EUI-64 non è
l'autoconfigurazione completa di IPv6, ma è una parte fondamentale del processo.)

Gli indirizzi IPv6 sono suddivisi in quattro tipi principali:

- Unicast: identificano in modo univoco un'interfaccia di rete su una singola macchina. Sono
utilizzati per la comunicazione diretta tra due host.
- Broadcast: in IPv6 non esiste più il concetto di indirizzo broadcast. Viene invece utilizzato il
concetto di indirizzo multicast per la comunicazione a tutti i nodi di una rete.
- Multicast: identificano un gruppo di interfacce di rete che vengono utilizzati per la
comunicazione di gruppo. Sono identificati da un prefisso iniziale "FF" seguito da un
numero identificativo che specifica il gruppo di destinazione. Solo gli interessati ricevono i
pacchetti e riduce il rischio di congestionare la rete inutilmente.
- Anycast: novità di IPv6, identificano un insieme di interfacce di rete, ma solo una di queste
viene selezionata come destinazione del pacchetto. Viene utilizzato il concetto di anycast
per identificare il nodo più vicino in una rete che condivide lo stesso indirizzo anycast.

Comunicazione tra reti con IPv6

Stessa LAN: Quando un dispositivo IPv6 ha bisogno di comunicare con un altro dispositivo sulla
stessa rete, utilizza il protocollo NDP (stessa funzione di ARP) per determinare il suo indirizzo
MAC. In questo modo, il dispositivo che ha iniziato la comunicazione può mappare l'indirizzo IPv6
del destinatario con il suo indirizzo MAC e inviare i pacchetti direttamente a livello di link layer.
LAN differenti: viene utilizzato il protocollo DHCPv6 per assegnare gli indirizzi IPv6 ai client e
per fornire altre informazioni di configurazione come il gateway predefinito e i server DNS (cose
che non da l'autoconfigurazione Plug&Play). Non ha più senso utilizzare NAT in IPv6 poiché lo
spazio degli indirizzi è molto ampio e non esiste più il problema di esaurimento degli indirizzi come
in IPv4.

Protocollo NDP (neighbor discovery protocol)

Opera a livello della rete ed è impiegato da dispositivi che vogliono comunicare all’interno della
stessa LAN, per configurare in maniera automatica gli indirizzi dei nodi, individuare gli altri nodi
sulla rete, recuperare l’indirizzo di accesso alla rete degli altri nodi, rilevare conflitti di indirizzi,
trovare i router della rete e trovare i DNS operativi sulla rete.
NDP è parte integrate del protocollo ICMP.
Per implementare queste funzioni NDP sfrutta 5 diversi tipi di pacchetti ICMPv6:
133 - Router solicitation: L’host richiede di conoscere i router presenti sulla rete che rispondono
con un pacchetto di tipo 134.
134 - Router advertisement: I router avvertono della loro presenza dopo un 133 o dopo la
scadenza di un timer
135 - Neighbor solicitation: Inviato da un host per determinare l'indirizzo link-local (MAC
address) di un altro dispositivo sulla stessa rete. È equivalente all'ARP Request di IPv4.Viene
inviata in multicast (al solicited node) se l'host sorgente vuole scoprire l'indirizzo di un altro host,
oppure in modalità unicast se l'host mittente vuole verificare solo la raggiungibilità dell'host
destinazione.
136 – Neighbor advertisement: Risposta al 135.
137 – Redirect message: usato dai router per informare dell’esistenza di un miglior instradamento
per una data destinazione (cioè il traffico sarà inviato ad un altro router piuttosto che a se).
L'Internet Control Message Protocol (ICMP) è un insieme di regole di comunicazione che i
dispositivi utilizzano per comunicare errori di trasmissione dei dati in una rete. Gli ICMP sono
spesso utilizzati assiemi ai protocolli TCP/UDP.

Lezione 10: Flooding e DV livello di rete – continuo

Firewall
Gli aggressori, conoscendo l’intervallo di indirizzi IP della rete, possono facilmente inviare
datagrammi IP a indirizzi interni a quell’intervallo. Questi datagrammi possono causare qualsiasi
tipo di danno, compresa la rilevazione della struttura della rete, ricerche tramite ping e scansioni
delle porte, mandare in blocco host vulnerabili con pacchetti malformati, inondare i server con una
quantità enorme di pacchetti ICMP e infettare gli host includendo malware nei pacchetti.
Per contrastare questi attacchi utilizziamo dei sistemi che sono i Firewall e i Sistemi di rilevamento
delle intrusioni.
I firewall controllano i datagrammi e i campi dell’intestazione dei segmenti in essi contenuti,
impedendo l’accesso all’interno della rete da parte dei datagrammi sospetti. Per esempio, un
firewall può bloccare tutti i pacchetti ICMP di richiesta di echo, impedendo che tramite ping venga
rilevata la struttura della rete. I firewall possono anche bloccare pacchetti in base agli indirizzi IP e
numeri di porta sorgente e destinazione. Inoltre, possono essere configurati per tener traccia delle
connessioni TCP, garantendo l’accesso solo ai datagrammi appartenenti a connessioni approvate.
• Firewall software
Il filtraggio in ingresso controlla il traffico di pacchetti che entra nella rete, mentre il filtraggio in
uscita controlla il traffico di pacchetti che esce dalla rete.
Il blocco e il passaggio del traffico sono le due operazioni principali eseguite dal firewall software.
Il blocco del traffico impedisce il passaggio di pacchetti di rete non autorizzati o sospetti, mentre il
passaggio del traffico consente il passaggio di pacchetti di rete autorizzati e legittimi. In questo
modo, il firewall software può proteggere la rete da attacchi informatici, malware ecc.
• Firewall hardware
Un application gateway è una macchina non raggiungibile che viene interposta tra due LAN private
per consentire il passaggio dei pacchetti da una rete privata all'altra. A differenza del gateway
predefinito (che mi dice solo come trovare l'uscita da una rete) un application gateway è un
firewall hardware che guarda il contenuto del pacchetto e prende decisioni sul proseguimento o
scarto del pacchetto.
Il costo dei firewall hardware è molto più elevato dei firewall software, questo li rende molto meno
utilizzati. Un firewall software è meno sicuro di uno hardware per il semplice motivo che si trova
già sulla macchina, che può essere a sua volta compromessa.
Il concetto di porta aperta definisce una porta di ascolto dove un processo chiede di ricevere i
pacchetti che il sistema operativo riceve su quella determinata porta, con porta chiusa si intende che
il sistema operativo scarta a priori il pacchetto nonostante dei processi siano in ascolto su quella
porta.

DMZ (zona demilitarizzata)

La zona demilitarizzata (DMZ) è un'area di rete separata che viene creata all'interno di una rete
aziendale o di un'altra rete protetta. La DMZ viene utilizzata per ospitare server e applicazioni che
devono essere accessibili dall'esterno della rete, come server web, server di posta elettronica e
server FTP. La DMZ è separata sia dalla rete interna che da quella esterna ed è protetta solo
parzialmente dal router tramite uno o più firewall, che ne controllano l'accesso da parte degli utenti
esterni e proteggono la rete interna da eventuali attacchi provenienti dalla DMZ. In genere, i
firewall sono configurati per consentire solo il traffico di rete autorizzato tra la DMZ e la rete
interna o esterna.

Algoritmi di Routing
Gli algoritmi di Routing sono algoritmi utilizzati dai router per determinare il percorso ottimale per
instradare i pacchetti attraverso una rete. Quando si parla di Routing distribuito si fa riferimento ad
un approccio nel quale l'algoritmo di Routing è in esecuzione in ogni nodo della rete in modo
distribuito ed indipendente dagli altri nodi. Ogni nodo utilizza le informazioni locali per
determinare il percorso migliore per instradare i pacchetti. In un approccio distribuito, bisogna che
risulti chiaro quando l'algoritmo inizia la propria esecuzione e quando l'algoritmo si conclude.
Gli algoritmi di instradamento hanno lo scopo di determinare i percorsi o cammini tra le sorgenti e i
destinatari attraverso i router. Il percorso migliore è quello che ha costo minimo. Per dimostrare gli
algoritmi di instradamento faremo utilizzo di un grafo che è un insieme di N nodi e un insieme di E
di archi. Un percorso è una sequenza di nodi.
Distinguiamo gli algoritmi di Routing in statici/dinamici e globali/locali. Un algoritmo di Routing
si definisce statico se non implementa una tecnica adattiva alle congestioni o i vari guasti, un
algoritmo dinamico è invece responsivo ai rallentamenti e ai problemi della rete. Inoltre, gli
algoritmi globali (link-state) per funzionare necessitano di conoscere tutta la topologia della rete
mentre in quelli locali nessun nodo possiede informazioni complete sul costo di tutti i collegamenti
se non quelli adiacenti. Tramite un processo iterativo ottiene le informazioni sulla rete dai nodi
adiacenti.
Flooding: è un algoritmo di Routing distribuito locale. Come funziona? ogni nodo inoltra il
pacchetto ricevuto (detto di Hello) a tutti i nodi ad esso adiacenti, che a loro volta lo inoltrano ai
propri vicini, e così via, fino a quando il pacchetto raggiunge la destinazione finale. L'algoritmo di
flooding è molto semplice da implementare e non richiede conoscenza della topologia della rete. In
tali reti, l'algoritmo di flooding può garantire una maggiore resilienza alla rete, poiché ogni nodo ha
la possibilità di inoltrare il pacchetto a tutti i nodi vicini, indipendentemente dalla loro posizione o
dal loro stato di connessione.
Questo algoritmo non viene utilizzato in Internet perché può causare una congestione di rete e
perché non fornisce un percorso ottimale per il pacchetto.
Si necessita di un modo per bloccare il flooding in quanto la ritrasmissione continua di pacchetti su
tutti i link provoca una congestione dovuta al fatto che molti pacchetti vengono rispediti molte
volte sugli stessi link. A tal proposito sono state proposte diverse soluzioni:
• Usare un ID per i pacchetti: così da poter tenere conto di tutti i pacchetti di cui si fa forwarding,
in modo da non ritrasmettere duplicati.
Questo approccio risolve la congestione ma sorge il problema della dimensione della tabella che
tiene conto di tutti i pacchetti inoltrati e diventa difficoltoso memorizzarla a meno che il passaggio
di un pacchetto per un link non sia sporadico.
• TTL limite: Se si possono fare assunzioni sulla rete si può invece pensare di stabilire un TTL
limite pari al diametro del grafo, ovvero la distanza massima tra una coppia di nodi del grafo.
(diametro: massimo valore tra tutti i percorsi minimi che coinvolgono tutte le coppie di nodi)
Il valore limite di TTL viene utilizzato come meccanismo di sicurezza per prevenire il loop infinito
dei pacchetti in una rete. Ogni volta che il pacchetto viene inoltrato a un nodo, il valore di TTL
viene decrementato di uno. Se il valore di TTL raggiunge lo zero, il pacchetto viene scartato. Il
problema è che spesso non è possibile fare assunzioni sulla rete.
• Spanning tree protocol: L'obiettivo è creare un albero di copertura minimo, (cioè tagliamo i rami
del grafo) ovvero un sottografo dell'intera topologia di rete che contiene tutti i nodi e che non ha
cicli ed elimina gli archi che portano a nodi già raggiungibili.
Si elegge un nodo radice sulla base dei confronti tra i vari MAC address dei nodi, in particolare la
radice è costituita dal dispositivo che ha il MAC address minore e si effettua una visita in
ampiezza (BFS) a partire da quel nodo.
Tuttavia, il protocollo STP riscontra problemi di applicabilità in quanto richiede la conoscenza
completa della topologia di rete e può causare ritardi nella convergenza della rete in caso di
cambiamenti nella topologia di rete.

Distance Vector (DV)

È uno dei due principali metodi di Routing dinamico (l’altro è il Link State Routing).
Cos'è un Distance Vector?
Un Distance Vector è una “tabella di distanza” che ogni router mantiene per sapere quanto
“lontano” (in termini di costi o "distanza") si trovano le varie destinazioni e quale è il “vettore”
(cioè il prossimo router) che deve usare per raggiungerle. Ogni router conosce solo:
- La distanza verso ogni destinazione nella rete
Qual è il prossimo router (il next hop) a cui inviare i pacchetti per raggiungere quella destinazione?
Sfruttiamo l’algoritmo Bellman-Ford.
Prima di tutto, ogni nodo crea una tabella a doppia entrata dove ha nelle righe le destinazioni e nelle
colonne il primo passo da fare. Questa tabella all’inizio sarà riempita solo con le informazioni a
diposizione sui nodi vicini mentre tutto il resto che non si conosce sarà impostato a infinito.

Passo1: Inizialmente, ogni nodo conosce solo i costi per raggiungere i suoi vicini diretti:
X conosce che raggiungere Y costa 2 e Z costa 7.
Y conosce che raggiungere X costa 2 e Z costa 1.
Z conosce che raggiungere X costa 7 e Y costa 1.
Tutti gli altri valori sono impostati a infinito (∞), perché il nodo non conosce ancora un percorso per
quelle destinazioni.

Passo 2: Condivisione dei Vettori di Distanza

Dopo aver inizializzato la tabella, ogni nodo invia il proprio vettore di distanza (cioè la sua tabella)
ai suoi vicini. Questo scambio permette ai nodi di conoscere i costi minimi per raggiungere i nodi
adiacenti dei propri vicini.
Ad esempio:
X invia il proprio vettore a Y e Z.
Y invia il proprio vettore a X e Z.
Z invia il proprio vettore a X e Y.

Passo 3: Aggiornamento dei Costi Minimi

Ogni nodo, una volta ricevuti i vettori di distanza dai vicini, aggiorna la propria tabella di Routing
calcolando nuovi costi minimi per ogni destinazione.
Per esempio:
X calcola che per raggiungere Z, può passare attraverso Y. Il costo per raggiungere Y è 2 e il costo
per raggiungere Z da Y è 1, quindi il costo totale è 2+1=3. Questo valore è inferiore a quello che X
conosceva prima (7), quindi aggiorna la sua tabella indicando che per raggiungere Z il costo
minimo è 3 passando per Y.
Y può fare un calcolo simile per raggiungere X tramite Z, e aggiorna la sua tabella se trova percorsi
più economici.

Passo 4: Convergenza
Questo processo di scambio e aggiornamento continua finché tutte le tabelle di Routing si
stabilizzano, cioè non ci sono ulteriori aggiornamenti perché tutti i percorsi minimi sono stati
trovati. A questo punto, ogni nodo ha una visione "ottimale" dei percorsi minimi verso ogni altro
nodo.
Supponiamo che adesso all’improvviso abbiamo un miglioramento in un canale passando da 10 a 1.

Prima di tutto ad accorgersi di questo cambiamento sono i vicini X e Y che cambieranno il loro
valore da 10 a 1. Avvenuto questo cambiamento quello che succederà è che Z andrà così ad
aggiornare la sua tabella una volta ottenuta l’informazione di cambio da parte di X e Y. E così via
ottenuto il cambio da parte di Z, a loro volta X e Y aggiorneranno la loro tabella.

Questo sistema dunque sembra funzionare correttamente, ma troviamo in realtà una falla nel
momento in cui abbiamo dei peggioramenti nella rete. Distance vector risponde male al
peggioramento delle condizioni di rete.
Se ritornassimo ad avere 10 al posto di 1 tra X e Y, questi aggiorneranno la loro tabella e, una volta
spediti i loro vettori ci troveremmo nella situazione in cui X e Y avranno segnato il peggioramento
della rete ma Z, non sapendo nulla del cambiamento, continuerà a dire di avere un percorso con
costo inferiore a quello degli altri due senza però specificare che questo percorso passi proprio dal
canale che ha subito il peggioramento, di fatto mandando avanti una fake news all’inizio (il nodo
avrà una stima fittizia). Il router non riesce a raggiungere la destinazione con quella stima e ritorna
al mittente la propria tabella d'inoltro ed il pacchetto rimbalzerà continuamente creando un grosso
ritardo.

La situazione può essere risolta in 3 modi:

1. Resettare tutte le tabelle appena c’è un peggioramento (poco fattibile)
2. Split Horizon
3. Mandare un infinito al nodo per il quale noi passiamo per arrivare ad un altro nodo. Esempio Z
dice a Y che la sua distanza per arrivare a X è infinita se il percorso da Z a X passa per Y.
(Poisoned Reverse)

La tabella di inoltro dice quale è il prossimo passo da seguire nel cammino, quella di Routing
fornisce il quadro generale della rete. L'output dell'algoritmo distance vector è la tabella di inoltro.
Si nota che questo algoritmo non implica la conoscenza a priori del grafo; quindi, ogni nodo si
affida alle informazioni ricevute dai nodi ad esso adiacenti.
Questo implica un forte problema di sicurezza dovuto al fatto che un nodo malevolo potrebbe
dirottare il traffico destinato ad altri nodi. Non c'è soluzione a questo problema e si necessita di
fidarsi. La terminazione dell'algoritmo avviene anch'essa in modo distribuito. Questo è stato il
primo algoritmo ad essere utilizzato su Internet seppur con delle precisazioni da stabilire, come il
concetto di infinito uguale a 15, peso unitario dei link ecc...

Split Horizon e Poisoned Reverse

Lo split Horizon è una tecnica utilizzata in Distance Vector per prevenire i loop di rete dovuti al
peggioramento di una stima. In pratica, prevede che un nodo non invii informazioni sul cammino
minimo per raggiungere una destinazione a un altro nodo facente parte di tale cammino, al fine di
evitare che i pacchetti vadano a ciclare indefinitamente nella rete.
Questo perché se il nodo ricevente utilizza il percorso ricevuto dal nodo mittente per migliorare la
propria stima, essa terrà conto del peso fittizio dell'arco che ha peggiorato la propria stima,
causando un loop di rete.
La tecnica del poisoned reverse (Inversione avvelenata) viene usata insieme allo split Horizon.
Quando c'è un peggioramento del peso di un arco, tutti i nodi che utilizzavano quell'arco per il
calcolo del cammino minimo pongono la propria stima ad infinito, in modo da evitare che il
pacchetto vada a ciclare nella rete.

Considerazioni sull'approccio distribuito

Un sistema distribuito garantisce affidabilità ed alta efficienza e resistenza ai guasti. Si necessita di
una sincronizzazione continua tra i dispositivi per mantenerli aggiornati e di uno scambio limitato di
informazioni per garantire alti livelli di sicurezza; infatti, se non si conosce l'informazione si
rimanda a chi la conosce.
L'algoritmo inoltre deve arrivare velocemente a convergenza, per cui devono essere ben note le
condizioni di inizio e fine di cui si tiene conto nell'esecuzione.

Lezione 11: LSR

RIP (Routing information protocol) — [Distance Vector] —

Il Routing Information Protocol (RIP) è un protocollo di Routing che fornisce l'implementazione di
distance vector:
RIPv1

RIP v1: ogni router mantiene una tabella di Routing che indica il numero di hop necessari per
raggiungere ogni nodo nella rete. Si fissa il numero massimo di salti a 15 per prevenire ritardi nella
convergenza dell'algoritmo dovuti ad eccessive distanze tra nodi. Un router sceglierà il percorso più
breve in termini di numero di hop per raggiungere la destinazione.
Con RIP ogni router in una rete, trasmette periodicamente (ogni 30 secondi) le proprie informazioni
di Routing agli altri router tramite messaggi di aggiornamento e se un percorso per un router non
viene aggiornato per 180 secondi, la sua distanza viene impostata a infinito.
Il protocollo RIP sfrutta un garbage-collection timer (120 secondi) per rimuovere dalla tabella di
Routing, i router che non sono più raggiungibili.
Nel pacchetto RIPvl non è specificata una maschera in quanto opera utilizzando le classi di
indirizzi.

Una tabella di Routing contiene i seguenti campi:

- Indirizzo di destinazione
 - Distanza dalla destinazione in hop (massimo 15)
- Next hop: router adiacente a cui inviare i pacchetti
- Timeout (ogni 30 secondi)
- Garbage-collection timer (120 secondi)

RIP V2

RIPv2 aggiunge diverse caratteristiche rispetto a RIPvl: supporta l'indirizzamento CIDR e il

subnetting con maschere di sottorete variabili.
Questa versione supporta l'autenticazione dei messaggi, che consente ai router di autenticare
l'origine dei messaggi di aggiornamento della tabella di Routing e di evitare l'inserimento di
informazioni di Routing fittizie.
Consente ai router di specificare il prossimo hop per raggiungere una determinata destinazione. Ciò
significa che i router possono scegliere il prossimo hop per un percorso di Routing in base a fattori
come il costo del percorso.
RIPv2 utilizza "split Horizon" per prevenire i loop di Routing tra i router. Questo significa che un
router non annuncerà una destinazione a un altro router se ha appreso quella destinazione da quel
router stesso. Inoltre, RIPv2 supporta anche la tecnica del "poisoned reverse", che prevede che un
router annuncerà una destinazione con una metrica di distanza infinita (di solito 16) a un altro router
dal quale ha appreso che quella destinazione non è raggiungibile. Questo aiuta a prevenire loop di
Routing rimuovendo immediatamente la destinazione dalla tabella di Routing del router che ha
appreso l'informazione.
RIP ng (new generation) è una versione aggiornata di RIP che usa indirizzi IPv6.

Link State Routing (LSR)

Link State Routing è un algoritmo che nasce per sopperire ad alcune carenze di Distance Vector,
come il fatto che non tiene conto dello stato dei link ma attribuisce banalmente un peso unitario a
tutti i collegamenti.
Questo è un algoritmo globale (tutti i nodi sincronizzati sulle stesse informazioni) basato su
Dijkstra, ipotesi applicabile in pratica dato che nessun arco ha peso negativo. L'output
dell'algoritmo è l'albero dei cammini minimi, ovvero un minimum spanning tree che può non
essere unico se esistono diversi cammini che portano alla stessa destinazione con uguale peso.
L'algoritmo tiene conto dello stato del link e la condizione di partenza dell'algoritmo è a tempo;
infatti, periodicamente ogni nodo informa quelli ad esso adiacenti delle condizioni dei link. Le
condizioni di terminazione riguardano il raggiungimento di una situazione stabile nel grafo, ovvero
quando tutti i nodi hanno calcolato il proprio cammino minimo verso ogni altro nodo nel grafo, ma
come si può conoscere la topologia del grafo?
Ogni nodo sa solo chi sono i propri vicini e che nessun arco ha peso negativo o nullo. Ogni nodo
sfrutta il Flooding per inviare a tutti i vicini la propria tabella di nodi adiacenti, contenente il peso
dell'arco che permette di raggiungerli.
L'approccio possibile per fermare il Flooding è tenere conto dell'ID ma la soluzione è applicabile
solo se il messaggio da inviare è sporadico, ovvero se l'introduzione di altri nodi non fa cambiare le
tabelle degli adiacenti molto frequentemente.
La conseguenza di questo comportamento è che ogni router applica Dijkstra.
LSR è robusto agli attacchi, in quanto ogni nodo non può fornire informazioni fittizie dei link ai
nodi adiacenti perché verrebbero immediatamente contrariate dall'altro nodo, in quanto si
riferiscono allo stato di un link che è uguale in entrambe le direzioni.

Problemi con LSR

- oscillazioni, nel caso in cui abbiamo due strade con lo stesso costo minimo, ne
utilizzeremmo solo una anziché tutte e due e quello che succederebbe è che, una volta che si
satura una, si passa all’altra.

- dimensione del grafo, infatti il flooding causa una forte congestione all'aumentare del
numero di nodi. Inoltre, considerare porzioni troppo grandi del grafo comporta ricoprire AS
differenti, il che non interessa i link considerati.

Algoritmo Dijkstra
Percorsi minimi a partire da un Nodo. Prende in considerazione il nodo con costo più basso. Da B
conosce C E ed F e di questi blocca nuovamente il più piccolo e prende C. Da C conosce di nuovo E
F D ecc. Piano piano blocca i pesi per ogni nodo e ne scopre anche i percorsi. Si può dimostrare che
vengono trovati i percorsi minimi. E abbiamo trovato un albero di copertura minima. Se ci sono dei
nodi con lo stesso peso minimo, potremmo avere più alberi di copertura minima.
Dopo questo passo, visto che C è il minore dopo B, si prende in considerazione C e si continua.

Per applicare Dijkstra dobbiamo già conoscere il grafo. Per farlo A manda un pacchetto Hello ai
vicini e così, in base ai tempi di risposta mappa i costi (tutti fanno la stessa cosa). Le tabelle fatte da
ogni nodo vanno a comporre un grafo sottoforma di matrice. Per mandare le tabelle utilizziamo il
flooding, una volta ogni tanto in modo da non intasare la rete. Da queste tabelle abbiamo un double
check dove A dice di conoscere B ad un certo peso ma anche B dovrebbe dire lo stesso.
Fatto ciò, possiamo paragonare i due algoritmi:

OSPF - (Open shortest path first)

L’algoritmo LSR viene implementato da OSPF che consiste in tre parti:
HELLO: Scoperta dei vicini
EXCHANGE: Sincronizzazione del database
FLOODING: Aggiornamento del database (tipicamente fatto ogni 30 minuti)

L'implementazione di LSR è OSPF: è un protocollo di Routing a stato di link che determina il

percorso migliore tra due punti di una rete, basandosi sulla topologia di rete e sulla metrica di costo,
che tiene conto di fattori come la larghezza di banda, il ritardo e il traffico.
L'implementazione utilizza i messaggi che sono scambiati tra i router che partecipano al protocollo
OSPF, al fine di costruire un database di stato dei collegamenti che rappresenta la topologia della
rete. Una volta che il database di stato dei collegamenti è stato costruito, OSPF utilizza l'algoritmo
Dijkstra per determinare il percorso più breve tra due punti della rete. Questo percorso viene
quindi utilizzato per instradare il traffico da una sorgente a una destinazione.
OSPF è un protocollo di Routing dinamico, il che significa che è in grado di adattarsi
automaticamente ai cambiamenti nella topologia della rete, come l'aggiunta o la rimozione di router
o sottoreti. In OSPF lo stato del link viene valutato tramite l'invio di pacchetti di tipo "hello" tra i
router che partecipano al protocollo.
OSPF è ampiamente utilizzato nelle reti di grandi dimensioni, come quelle delle aziende o dei
provider di servizi Internet (ISP). In generale, OSPF è considerato un protocollo di Routing robusto
e affidabile, che fornisce una buona scalabilità, flessibilità e sicurezza.

Per quanto riguarda Internet, questo è organizzato in autonomous system AS, che hanno il compito
di gestire le politiche di Routing in una singola rete o gruppi di reti.

Internet Routing
Un Autonomous System (AS) è un insieme di reti interconnesse gestite da un unico amministratore
che utilizza un protocollo di Routing comune. In altre parole, un AS è un sistema autonomo e
indipendente che si occupa di instradare il traffico Internet all'interno della propria rete e verso altre
reti.
Distinguiamo due tipologie di protocolli di Routing
- Interior gateways protocol (IGP): consente ai router all'interno dello stesso AS di scambiare
informazioni sulle rotte disponibili e di selezionare il percorso migliore per instradare i
pacchetti all'interno dell'AS. Alcuni esempi di protocolli IGP includono RIP e OSPF.
- Exterior gateways protocol (EGP): sono utilizzati per il Routing tra diverse AS e
consentono ai router di scambiare informazioni sulle rotte disponibili tra AS differenti e di
condividere informazioni sulla raggiungibilità delle destinazioni. BGP (Border Gateway
Protocol) è un esempio di protocollo EGP.

BGP-4 ad esempio, ha il compito di fare Routing solo su dei router scelti magari dal gestore
(esempio TIM fa passare la sua rete solo tramite router TIM e “salta” i router VODAFONE)

Lezione 12: Data link layer

Il livello DLL o livello di collegamento, è responsabile di incapsulare i datagrammi in un frame a
livello di collegamento e trasmetterlo nel collegamento stesso. Fornisce anche servizi come:
1.Accesso al collegamento: gestisce l’accesso al canale di trasmissione, questo può rivelarsi utile
nel momento in cui abbiamo un canale half-duplex o quando ad esempio abbiamo più host connessi
allo stesso collegamento.
2.Consegna affidabile: Questo viene fatto perché, innanzitutto non sempre il livello di trasporto si
occupa della consegna affidabile (vedi UDP) ma anche perché se riusciamo ad accorgerci di aver
perso un pacchetto è meglio ritrasmetterlo direttamente a metà strada piuttosto che aspettare che sia
il livello di trasporto ad accorgersene. (Spesso la consegna affidabile viene implementata dove ci
sono grandi probabilità di errore nella consegna come il WIFI)
3.Rilevazione e correzione degli errori: Gestisce gli errori (non volontari) dovuti al canale di
trasmissione dovuti al fatto che il livello fisico “rovina” il messaggio. Si possono rilevare e
correggere gli errori, solo che mentre la rilevazione si può fare abbastanza bene, per la correzione si
può al massimo garantire una qualità elevata del servizio ma non sempre è possibile. Questo può
avvenire a causa di segnali di disturbo di vario genere e può avvenire più o meno frequentemente.
Se ciò avviene, è chiaramente inutile mandare un datagramma corrotto, dunque possiamo tramite
degli algoritmi trovare degli errori ed eventualmente correggerli.
Il protocollo di collegamento e tutti i suoi servizi sono spesso implementati nella scheda di rete
stessa. Dalla parte del sender il datagramma viene incapsulato in un frame e aggiunge il bit per il
check degli errori. Il receiver controlla gli errori e implementa il trasferimento affidabile e
dopodiché apre il datagramma e lo manda al livello successivo.

Data Frame e Stati

Immaginiamo un sistema che utilizza un data frame per trasmettere informazioni, dove ogni
elemento del frame può assumere solo due stati:
 0: assenza di trasmissione (ad esempio, luce spenta);
 1: trasmissione di luce.
Il problema principale con questa configurazione è l'ambiguità: una lunga sequenza di "0"
potrebbe essere interpretata sia come un'assenza di trasmissione sia come una trasmissione valida.
Questo rende difficile distinguere i dati dal rumore o dalle interruzioni nella comunicazione.

Canali a 3 Stati
Se invece il canale avesse 3 stati distinti (ad esempio: basso, medio, alto), possiamo:
 Utilizzare i due stati estremi (basso e alto) per trasmettere dati.
 Riservare il livello medio per indicare assenza di comunicazione.
Questa soluzione elimina l'ambiguità, ma introduce un problema: uno dei tre stati è ridondante cioè
viene lasciato inutilizzato per la trasmissione di dati; quindi, il sistema non è ottimale in termini di
utilizzo delle risorse disponibili.

Canali a 5 Stati e Baud Rate

Con un canale a 5 stati (ad esempio: L = basso, M = medio, H = alto, e due livelli intermedi),
possiamo:
 Utilizzare uno stato per l'assenza di comunicazione.
 Usare gli altri quattro per la trasmissione di dati.
Ogni variazione nello stato del canale è chiamata baud, ed è un'unità di misura che rappresenta
i simboli trasmessi per secondo.
Se un simbolo può assumere 5 stati, possiamo codificarlo con più bit:
 Ogni simbolo rappresenta log2(5) bit (circa 2.32 bit per simbolo). Arrotondando, possiamo
trasmettere 2 bit per simbolo.
Questo aumenta il bit rate (dati trasmessi al secondo) rispetto al baud rate, sfruttando la codifica
dei simboli.

Codifica 4B5B
La codifica 4B5B serve per trasmettere dati in modo più sicuro su un canale che supporta solo 2
stati (0 e 1). Funziona così:
1. Ogni sequenza di 4 bit di dati viene codificata in 5 bit di trasmissione.
2. Sono possibili 25=32 combinazioni di bit:
o 16 combinazioni vengono mappate direttamente sui dati (4 bit).
o Le altre 16 combinazioni sono riservate per il controllo e per evitare errori.
Questa codifica introduce una ridondanza, aumentando la probabilità di rilevare errori:
 Se riceviamo una combinazione non valida, sappiamo che c'è stato un errore.
 Però non possiamo rilevare errori se una combinazione valida viene trasformata in un'altra
valida.
Lo svantaggio è che per ogni 5 bit trasmessi, solo 4 contengono dati utili. C'è quindi uno "spreco"
del 20% della capacità.

Codifica 8B10B
La codifica 8B10B è un'estensione della 4B5B e viene usata in sistemi come HDMI:
1. Ogni 8 bit di dati viene codificato in 10 bit di trasmissione.
2. Questa tecnica garantisce:
 o Bilanciamento energetico: il numero di 0 e 1 trasmessi è uguale, eliminando problemi
di polarizzazione del segnale.
o Rilevamento degli errori: grazie a combinazioni riservate.

Supponiamo di avere un canale con 3 stati (L = basso, M = medio, H = alto) e un baud rate di 12
simboli al secondo. Se codifichiamo più stati in un singolo simbolo:
 Due simboli alla volta: 32=9 combinazioni. Questo corrisponde a circa log2(9) =3.17 bit
per simbolo, arrotondati a 3.
 Tre simboli alla volta: 33=27 combinazioni. Questo corrisponde a log2(27) =4.75 bit,
arrotondati a 4.
Bit rate massimo: aumentando il numero di stati utilizzati per simbolo, possiamo trasmettere più
bit senza aumentare il baud rate. Ad esempio, con 3 simboli si hanno alto-alto-alto, alto-alto-medio,
ecc. Non c’è una reale corrispondenza biunivoca tra i simboli a livello fisico e i simboli a livello
DLL; infatti, con strategie software si possono raggruppare i simboli al fine di ottenere una
maggiore velocità di trasmissione in bps

La rilevazione degli errori consente di individuare la presenza di un errore di trasmissione in un

frame, ma non di correggerlo direttamente. Invece, la correzione degli errori consente sia di rilevare
che di correggere gli errori di trasmissione.
Entrambi i metodi sono basati sulla presenza di ridondanza nella comunicazione, ovvero dati che
non aggiungono informazioni che non si hanno già.
La rilevazione degli errori utilizza tecniche come la checksum o il controllo di parità per aggiungere
informazioni ridondanti ai dati trasmessi. Queste informazioni ridondanti permettono al destinatario
di confrontare i dati ricevuti con la somma di controllo o il valore di parità e individuare eventuali
errori di trasmissione. La correzione degli errori è più complessa e richiede più risorse di
elaborazione rispetto alla rilevazione degli errori.

Controllo degli errori

Per fare un controllo degli errori dobbiamo introdurre logicamente una ridondanza. Per fare un
esempio prendiamo il codice fiscale che contiene le ultime cifre di controllo che ci permettono di
verificare che il codice fiscale sia valido che è ben diverso dall’essere vero. Infatti, il codice fiscale
potrebbe non corrispondere a qualche persona realmente esistente.
Nel nostro caso i bit errati potrebbero essere o nella ridondanza o nei dati o in entrambi. In ogni
caso butteremo il pacchetto.

- Si trasmettono i dati insieme a un codice di controllo (ridondanza), cioè EDC (error

detection code).
- I dati e il codice di controllo vengono trasmessi attraverso un canale (rappresentato dal
rettangolo blu “bit-error prone link”), cioè una connessione in cui potrebbero verificarsi
errori.
- Una volta ricevuti, i dati e il codice di controllo vengono chiamati rispettivamente D
′ ed EDC′.
- Il ricevente ricalcola il codice di controllo sui dati ricevuti D′ e lo confronta con EDC′. Se
c’è un errore, il pacchetto viene scartato (o potrebbe essere richiesta una ritrasmissione in
altri sistemi).

Controllo di parità
La forma più semplice di controllo degli errori è il bit di parità. Supponiamo di avere D
informazioni da inviare con d bit. In uno schema di parità pari il mittente aggiunge ai d bit un bit in
più per far sì che i bit a 1 siano una quantità pari, cosicché il ricevente non deve far altro che contare
quanti bit a 1 ci sono e se sono un numero pari allora è tutto okay, se sono dispari c’è stato un
errore. Questo sistema funziona dal momento in cui siamo sicuri che c’è stato un solo errore o
comunque un numero dispari di errori, se invece vengono cambiati un numero pari di bit questo non
funziona.

Presupponendo che ci sia un solo errore è stato ideato un sistema chiamato parità (a due
dimensioni) che permette anche la risoluzione degli errori.
In questo caso, i d bit del dato D sono suddivisi in i righe e j colonne per ognuna delle quali è stato
calcolato un valore di parità. I risultanti i + j + 1 bit di parità contengono bit per la rilevazione
dell’errore nei frame a livello di collegamento.
La capacità del ricevente sia di rilevare sia di correggere gli errori è conosciuta come forward
error correction.
Ricorda: il numero di 1 per la riga (e colonna) deve essere pari quindi aggiungo come bit 0 o 1 per
mantenere la parità.
Tuttavia, la correzione degli errori si basa sulla probabilità che l'errore sia solo uno, pertanto si
necessita di massimizzare la probabilità che ci sia un solo errore.

Controllo a ridondanza ciclica (CRC)

L’obiettivo è cercare una funzione HASH efficiente che ci permette di effettuare il controllo e che
sia anche efficace. Ricordiamoci di essere in un anello che è una struttura ciclica che quindi ci
permette di avere delle operazioni commutative e che nel campo dei binari ci permette di
considerare le somme e le differenze allo stesso modo. Dunque, avremo queste operazioni.

Consideriamo ora l’invio di dati D con d bit. Questi bit li vediamo come se fossero un polinomio e
dove abbiamo 1 mettiamo x^posizione in cui si trova.

La tecnica CRC prevede la generazione di un polinomio di grado n+1, dove n è il numero di bit di
controllo da aggiungere. Si prende il polinomio M(x) ottenuto dalla sequenza m da trasmettere che
presenta una ridondanza di r bit. Si prende il resto della divisione tra il polinomio M(x) ed un
generatore G(x) di grado r+1, noto a mittente e destinatario.
Il generatore G(x) deve avere alcune caratteristiche, ovvero deve avere il primo e l'ultimo bit posti
ad 1 e non deve essere ottenibile come prodotto di altri polinomi.
Durante la trasmissione, il generatore del CRC viene trasmesso insieme ai dati. Il destinatario riceve
i dati e il valore di controllo CRC e utilizza lo stesso polinomio generato dal mittente per calcolare
il valore di controllo CRC sui dati ricevuti. Se il valore di controllo CRC calcolato dal destinatario
(applicando M(x) mod G(x)) corrisponde al valore trasmesso dal mittente, allora i dati sono stati
trasmessi correttamente. In caso contrario, significa che si è verificato un errore di trasmissione.
Il CRC è un controllo semplice da implementare ed efficace dal punto di vista della rilevazione.
Aggiunti r bit, inizialmente li impostiamo a 0 e poi facciamo la divisione. Dopodiché una volta
raggiunto il massimo che possiamo fare ci basta sostituire R al posto di quei bit prima a 0.
Ci basta quindi implementare una specie di finestra a scorrimento che effettua il controllo XOR.

Hamming
Cominciamo innanzitutto definendo la distanza di hamming su due codewords come il numero di
bit che sono differenti tra loro.

Definiamo inoltre un vocabolario come un set di codewords e diciamo che questo è completo se
contiene 2n codewords dove n sono il numero di bit che ci sono nelle parole del vocabolario. Infatti,
in un vocabolario le codewords hanno una lunghezza e una distanza fissa.
Prendiamo un vocabolario di 3 di 6 bit con distanza 3 e con solo 4 codewords.

Supponendo di avere queste codewords come sorta di controllo, ci accorgeremmo subito se

abbiamo un bit cambiato e “probabilisticamente” potremmo anche riuscire a correggerlo.
Immaginiamo di ricevere 101000:
Quando riceviamo una cosa del genere, è chiaro che è molto più probabile che abbiamo ricevuto un
errore e che quello che in realtà volevamo mandare fosse 111000 che è la parola la cui distanza è
minore rispetto alle altre. Infatti, è molto più probabile che abbiamo un solo errore rispetto che due
o tre. Il mittente stesso corregge l’errore sulla base della sequenza più vicina.
Dunque, una codeword errata può essere controllata misurando la distanza con le 4
codewords del vocabolario e spesso correggeremo l’errore, supponendo che il mittente volesse
mandare la codeword con distanza minore.
Per rilevare e errori è necessario un vocabolario con distanza e + 1.Per correggere e errori è
necessario un vocabolario a distanza 2e + 1.

Guardando questo vocabolario con 10 bit, ci rendiamo facilmente conto che buttare 1020
combinazioni sia un po’ uno spreco e dunque ci domandiamo, come possiamo fare di meglio?

Grazie a queste 8 codewords potremmo avere 3 bit che possiamo utilizzare per mandare i dati e 7
bit che controllano questi 3. Ma la domanda è dunque, quanta ridondanza r dobbiamo aggiunge
se vogliamo mandare m bit di dati? Una volta ottenuto questo valore, come costruiamo il
vocabolario adatto a correggere gli errori?

Codici Validati e Ridondanza

Consideriamo un vocabolario con m bit di dati e r di controlli. Possiamo dire che avremo un totale
di n bit. In totale di questi n bit avremo 2^n combinazioni di cui però vogliamo siano valide solo
2^m (cioè le combinazioni dei bit di dati con in mezzo bit di controllo).
Intorno a questo codice (a distanza 1) ci sono altre combinazioni (00001, 11001, 10101, ecc.) che
differiscono per un solo bit. Queste combinazioni sono considerate parole di codice non valide.
Queste parole di codice non valide servono per migliorare la capacità di rilevamento e correzione,
poiché possiamo identificare e correggere errori confrontando con i codici validi.

In questo grafico, le palline verdi sono le codeword del nostro vocabolario mentre le rosse sono
tutte le altre codeword non valide.
Ricordiamoci che se vogliamo correggere 1 bit errato, abbiamo bisogno di un vocabolario con
distanza 3.
Possiamo dire inoltre che se tutti i gruppi sono separati. L’unico modo per ottenere tutti i gruppi
separati è proprio quello di scegliere dei vocabolari con distanza dispari. Altrimenti quando
andremmo a effettuare il controllo, rischieremmo di avere che le distanze più basse sono due e
quindi non riusciremmo a correggere l’errore.
Questo scenario può infatti accadere solo se abbiamo delle codewords che hanno una distanza pari.

Guardiamo quindi usando questa formula:

Ci rendiamo subito conto che in n non troviamo mai le potenze di 2 e di base questa cosa ci piace.
Infatti, andremo a posizionare i bit di controllo nelle posizioni delle potenze di 2, così facendo
riusciamo a costruire il codice così:

Andiamo a posizionare i bit di controllo nelle posizioni delle potenze di 2 perché così facendo
riusciamo a identificare in maniera univoca quali bit controllano quale posizione. Il bit 9 verrà
controllato dal bit 1+8 e così via…
Nel caso di un errore notiamo subito che

Potremmo per esempio prima di inviare i dati insieme alle codewords, anziché mandarle per riga,
mandarle per colonne in modo da avere tutti i bit di controllo vicini. Può tornare comodo, ad
esempio, se abbiamo un canale che sbaglia poco ma quando lo fa genera molti errori.
Qui il bit alla posizione 10 è stato alterato (da 0 a 1).
Ora, ricontrollando i bit di controllo: b1, b2 e b4 risultano 1. b8 risulta 0.
La combinazione dei bit di controllo b1=1, b2=1, b4=1, e b8=0 ci fornisce il numero
binario 1010, che è il numero 10 in decimale. Questo ci indica che l'errore si trova alla
posizione 10. Ora che abbiamo identificato la posizione dell'errore (posizione 10), possiamo
correggerlo invertendo il bit in quella posizione (da 1 a 0 in questo caso).
Questo algoritmo viene utilizzato nelle ECC RAM (error connection code RAM)

Collegamenti Broadcast
Il collegamento broadcast può avere nodi sia trasmittenti che riceventi, connessi allo stesso canale
broadcast condiviso. In questo tipo di collegamenti, quando un nodo trasmette un frame, quello che
succede è che il canale lo diffonde a tutti gli altri nodi. Il problema di questi tipi di canali è che se
due frame si incrociano per strada, abbiamo delle collisioni che fanno perdere i frame inviati,
dunque abbiamo il problema dell’accesso multiplo. I nodi naturalmente nei canali broadcast
possono sia trasmettere che ricevere. Abbiamo diversi tipi di protocolli di accesso multiplo:
FDMA (divisione delle frequenze), TDMA (divisione del tempo), CDMA (divisione a code).
Inoltre, possiamo fare una suddivisione tra protocolli a suddivisione del canale (FDMA e TDMA),
accesso casuale (Aloha) e a rotazione (ticket).
In genere da un canale broadcast ci aspettiamo che:
- Quando un solo nodo deve inviare dati, questo dispone di un throughput pari a R.
- Quando M nodi devono inviare dati, questi dispongono di un throughput pari a R/M.
- Il protocollo è decentralizzato; non ci sono nodi principali che se smettessero di funzionare
potrebbero bloccare il sistema
- Il protocollo deve essere semplice

Protocolli ad accesso multiplo

TDMA suddivide il tempo in intervalli e ciascun intervallo di tempo in N slot temporali. Ogni slot è
quindi assegnato a uno degli N nodi e ogni qualvolta un nodo ha un pacchetto da inviare, trasmette i
bit del pacchetto durante lo slot di tempo assegnatogli. Tendenzialmente gli slot di tempo sono
stabiliti in modo da consentire la trasmissione di un singolo pacchetto.
TDM viene utilizzato in quanto riesce a evitare le collisioni ed è perfettamente imparziale: ciascun
nodo ottiene, durante ciascun intervallo di tempo, un tasso trasmissivo di R/N bps. Però, quando
qualcuno degli N nodi sta in silenzio, il nodo che deve trasmettere deve comunque attendere il suo
turno nella sequenza di trasmissione e a non superare il limite di R/N bps.
FDMA invece divide il canale in frequenze differenti. Da un canale da R bps, otteniamo N canali
da R/N bps. FDM evita le collisioni e divide equamente la larghezza di banda tra gli N nodi.
Tuttavia, anche qui abbiamo che la banda è limitata a R/N.

Un terzo protocollo di suddivisione del canale è l’accesso multiplo a divisione di codice. CDMA
assegna un codice a ogni nodo e quando questo deve inviare dati, utilizza il proprio codice univoco
per codificarli. Se i codici sono scelti in maniera corretta, CDMA consentirà a nodi differenti di
trasmettere simultaneamente e ai rispettivi destinatari di ricevere correttamente i bit dei dati
codificati (assumendo che il ricevente conosca il codice) nonostante le interferenze derivanti dalle
trasmissioni degli altri nodi.
Protocolli ad accesso casuale
Ogni nodo è indipendente dagli altri e tenta di trasmettere i propri dati non appena ne ha bisogno,
senza accordarsi preventivamente con gli altri nodi. Se due o più nodi trasmettono nello stesso
momento, si verifica una collisione: i dati si sovrappongono e risultano incomprensibili. Quando
avviene una collisione, i nodi coinvolti aspettano un intervallo di tempo casuale (random delay)
prima di ritrasmettere. Questo aiuta a ridurre la probabilità che le collisioni si ripetano.
Utilizza un metodo semplice, decentralizzato e adatto a reti con nodi che trasmettono dati in modo
sporadico. La particolarità di questi protocolli è che non ci sono regole rigide che decidono quale
nodo può trasmettere in un dato momento.

Slotted Aloha
Assumiamo che tutti i frame consistano in L bit, il tempo sia diviso in slot di L/R secondi (uno slot
= una trasmissione di un pacchetto), i nodi comincino la trasmissione dei frame solo all’inizio degli
slot, i nodi sono tutti sincronizzati con gli slot e se due frame collidono tutti i nodi rilevano l’evento
prima del termine dello slot.
Con Aloha abbiamo che:
• Quando un nodo ha un nuovo frame da spedire, attende fino all’inizio dello slot successivo e poi
trasmette l’intero frame.
• Se non si verifica una collisione, l’operazione ha avuto successo; quindi, non occorre effettuare
una ritrasmissione e il nodo può predisporre l’invio di un nuovo frame.
• Se si verifica una collisione, il nodo la rileva prima del termine dello slot e ritrasmette con
probabilità p il suo frame durante gli slot successivi, fino a quando l’operazione non ha successo.
La ritrasmissione con probabilità p indica che il nodo lancia una moneta dove testa indica la
ritrasmissione e croce indica il rilancio della moneta nello slot successivo. Questo metodo ci
permette di usare a pieno il canale ed inoltre è decentralizzato. Tuttavia, se abbiamo più nodi che
devono agire contemporaneamente cominciano ad accadere due particolari problemi. In primo
luogo, in alcuni slot troveremo delle collisioni e quindi avremo di fatto sprecato tempo. In secondo
luogo, molti slot rimarranno vuoti a causa del tipo di politica applicata da Aloha. Uno slot in cui un
solo nodo riesce a trasmettere è detto slot riuscito.
In genere con questo approccio il canale sarà utilizzato per circa il 18.4% della sua potenzialità a
causa delle varie collisioni e slot inutilizzati.
Non si può evitare la collisione quindi si sfrutta il fatto che statisticamente pochi utenti hanno
necessità di iniziare la trasmissione contemporaneamente e quindi si ha bassa probabilità di
sovrapposizione di slot. Più si richiede al canale e più si abbassa il throughput ottenibile.
Pure Aloha
Il primo protocollo Aloha era privo di slot e non era sincronizzato. Appena arriva un frame, questo
viene trasmesso immediatamente. Se un frame va in collisione, allora questo verrà ritrasmesso
immediatamente con probabilità p. Inoltre, visto che gli slot non sono sincronizzati, abbiamo molta
più probabilità di avere delle collisioni. Le collisioni possono avvenire in due modi:
Sovrapposizione Totale: Un nodo trasmette mentre un altro sta già trasmettendo.
Sovrapposizione Parziale: Anche se le trasmissioni iniziano in momenti diversi, una trasmissione
in corso può essere "tagliata" dall'inizio di un'altra trasmissione.
Nodo A inizia a trasmettere al tempo t0 e termina al tempo t0+1 (dove 1 è il tempo di trasmissione
del frame). Qualsiasi nodo che inizia a trasmettere tra t0−1 e t0+1 causerà una collisione, perché i
frame si sovrapporranno in parte o totalmente.

CSMA
In generale esistono due regole importanti per quanto riguarda questi tipi di protocolli:
- Ascolta prima di parlare. Se qualcuno sta parlando, si aspetta che abbia finito. Questa è
chiamata rilevamento della portante.
- Se qualcuno comincia a parlare insieme a te, smetti di parlare. Questo è conosciuto in reti
come rilevamento della collisione.
Da qui leggi quello di alfio
Queste due regole sono alla base del CSMA e del CSMA/CD (aggiunta del rilevamento della
collisione).
Capiamo innanzitutto perché si verificano lo stesso le collisioni. In teoria se un nodo si accorge che
c’è qualcuno che sta parlando, allora non dovrebbe mandare nulla. Il problema sta proprio nel
quando si accorge che un altro nodo sta parlando. Infatti, quando un nodo B supponiamo trasmette
qualcosa, ci metterà un certo tempo (ritardo di propagazione) prima di arrivare a D il segnale.
Dunque, se D si accorge del segnale solo dopo che ha già trasmesso qualcosa, avviene comunque
una collisione.

Per quanto riguarda però CSMA base, B e D continuano a trasmettere i loro pacchetti anche se c’è
una collisione.
In CSMA/CD quando un nodo rileva la collisione, cessa immediatamente la trasmissione. Evitiamo
quindi l’inutile trasmissione dell’intero frame danneggiato. CSMA/CD dunque opera così:
1. La scheda ottiene direttamente un datagramma dal livello di rete, prepara un frame a livello
di collegamento e lo sistema in un suo buffer.
2. Quando riscontra che il canale è libero (cioè, non vi è energia di segnale che entri nella
scheda dal canale), inizia la trasmissione del frame. Se il canale risulta occupato, resta in
attesa sino al momento in cui non rileva più il segnale e solo allora inizia l’invio del frame.
3. Durante la trasmissione verifica la presenza di eventuali segnali provenienti da altre schede
di rete sul canale broadcast.
4. La scheda di rete, se trasmette l’intero frame senza rilevare energia di segnale proveniente
da altre schede, ha finito il suo lavoro; altrimenti, se riscontra energia di segnale durante la
trasmissione, interrompe immediatamente la trasmissione del frame.
5. Dopo aver annullato la trasmissione, la scheda di rete aspetta per un tempo casuale e poi
ritorna al passo 2
Chiaramente non potremmo mai aspettare un tempo fissato, se facessimo così, quando due frame
sono inviate allo stesso istante, allora avremo che i due nodi si bloccheranno ogni volta dato che
rimanderanno contemporaneamente il pacchetto. Quanto deve essere l’intervallo di scelta del tempo
casuale (tempo di backoff)? Se l’intervallo è grande e il numero di nodi che collidono è piccolo, i
nodi probabilmente aspetteranno per un lungo intervallo di tempo prima di riprovare. Se l’intervallo
è piccolo e il numero di nodi che collidono è grande, sarà probabile che valori scelti casualmente
siano simili e che quindi i nodi trasmittenti tornino a collidere.
Vogliamo un tempo piccolo con poche collisioni e un tempo grande con tante collisioni.
L’algoritmo di binary exponential backoff, quando il trasmettitore riscontra l’n-esima collisione
durante la trasmissione di un dato frame, stabilisce casualmente un valore K nell’insieme {0, 1,
2, ..., 2^n – 1} (attesa binaria esponenziale). Quindi più alto è il numero di collisioni, più grande
sarà l’intervallo da cui K.
Protocolli a rotazione
Da un protocollo di accesso multiplo ci aspettiamo che quando un solo nodo è attivo il suo
throughput debba essere di R bps mentre quando ci sono M nodi attivi ci dobbiamo avvicinare a
R/M bps. I protocolli precedenti hanno la prima caratteristica ma non la seconda. Per questo ci sono
i protocolli a rotazione.
Primo tra tutti abbiamo il protocollo di polling nel quale uno dei nodi designato come master
interpella a turno tutti gli altri dicendogli quanto possono inviare sul canale. Dopo il nodo 1 verrà
interpellato il 2 e così via.
Questo protocollo dispone delle caratteristiche elencate precedentemente ma è fortemente
centralizzato, il che lo rende facilmente suscettibile ai guasti e immettiamo una sorta di ritardo sul
canale dovuto al polling.
Il secondo protocollo di questo genere è il protocollo token-passing dove abbiamo un token che
viene passato tra i vari nodi seguendo un certo ordine prefissato. Quando un nodo ha un token può
parlare. Questo non è centralizzato ed è fortemente efficiente, tuttavia un guasto ad un nodo può
bloccare tutto il canale.

Ethernet
Ethernet domina per quanto riguarda il mercato delle reti globali, soprattutto per quanto riguarda le
tecnologie LAN. Ethernet è stata la prima LAN ad alta velocità con vasta diffusione. Quindi, gli
amministratori di rete, dopo aver acquisito familiarità con Ethernet, si dimostrarono riluttanti al
cambiamento quando apparvero sulla scena altre tecnologie. Inoltre, se Ethernet continua ad essere
utilizzato il motivo è proprio perché riesce a fornire versioni sempre più veloci.
Il meccanismo Ethernet utilizza quello che è l’algoritmo CSMA/CD. Riceve un datagramma dal
livello network e con questo ne crea un frame, dopodiché si mette in ascolto: se il canale è libero
allora trasmetta il frame, altrimenti aspetta che il canale si liberi. Se la trasmissione del frame
avviene senza collisione, allora il gioco è fatto, altrimenti se rileva una collisione smette di
trasmettere e aspetta un numero randomico di tempo definito nell’intervallo {0,1, 2, …, (2^m) - 1}
dove m rappresenta il numero di collisioni già avvenute. Come dicevamo già prima, questo è
definito come binary exponential backoff.
All’inizio di Ethernet veniva utilizzato un cablaggio di tipo 10base5. Innanzitutto, definiamo cosa
vogliono dire questi nomi. La prima parte fa riferimento alla velocità standard (10,100,1000 o 10G),
Base si riferisce a Ethernet in banda base cioè che quel cavo trasferisce solo Ethernet e in fine
l’ultima parte si riferisce al “mezzo fisico” cioè al tipo di cavo che si utilizza.

Le prime tipologie di Ethernet utilizzavano dei cavi di tipo coassiali che, nella loro versione
“Thick” erano molto spessi e potevano raggiungere all’incirca 500 metri. Questo metraggio poteva
essere allungato tramite un particolare ripetitore che al tempo veniva chiamato vampiro. Quello che
faceva questo vampiro era bucare in un certo punto i due cavi da sopra di fatto ricevendo un segnale
in entrate e trasmettendolo in uscita. Oltre che a ritrasmettere il segnale, il vampiro aveva anche la
funzione di uditore per evitare le collisioni. Questo genere di cavo si preferisce non tagliarlo perché
causerebbe una perdita di segnale. Nella versione “Thin”, questi tipi di cavi erano molto più
morbidi e flessibili e potevano essere tagliati, tuttavia alla fine trovavamo un connettore. A causa di
ciò però la portata di questi cavi è di molto diminuita. Naturalmente questi cavi sono schermati in
modo che nessun segnale da fuori li possa disturbare.
Ethernet fu successivamente migliorato con 100Mbps utilizzando cavi in rame 100Base -T e in fibra
ottica 100 Base FX/SX/BX.
La maggior parte delle strutture odierne utilizza una struttura con uno switch e con segmenti punto a
punto.

Questo è il tipico frame Ethernet. Ricordiamo che a livello ethernet lavoriamo solo con indirizzi
MAC. Dunque, troviamo gli indirizzi di destinazione e il sorgente a cui siamo già abituati, il tipo
che sta ad indicare quale protocollo di rete utilizziamo, il campo di dati contiene il datagramma IP.
Dato che l’unità massima di trasmissione per Ethernet è di 1500 byte, se questi vengono superati
dobbiamo frammentare il frame. Altrimenti se non rappresenta il minimo di 46 byte, abbiamo la
necessità di riempirlo. Infine, troviamo il CRC e il preambolo che è un campo di 8 byte i cui i sette
hanno i bit 10101010 e l’ultimo è 10101011. I primi servono a far sì che i due host si sincronizzino
e l’ultimo serve ad indicare che sta per arrivare a tutti gli effetti il carico.

Codifica Manchester
Avevamo all’inizio il problema di identificare gli 1 e gli 0, per fare ciò utilizziamo la codifica
Manchester. Qui utilizziamo il clock in modo da identificare il segnale correttamente, leggendo i
dati la codifica di Manchester utilizza il cambio di segnale verso l’alto per identificare i bit 1 e il
cambio verso il basso per i bit a 0.

Fast Ethernet
Fast ethernet è una evoluzione di ethernet implementata utilizzando i doppini (filo di rame) o fibra
ottica.
Gigabit Ethernet
Questa versione rimuove 4B5B e usa 4 coppie di fili UTP assieme. Implementa inoltre un canale
full duplex e usa 5 livelli per simbolo anziché 3. Implementa inoltre FEC che gli permette di
correggere molti errori.
Quello che facciamo è utilizzare una macchina a stati finiti costruita così.
In base allo stato in cui ci troviamo, mandiamo dei segnali diversi per mandare o 0 o 1. Questa
macchina a stati finiti è fatta in modo tale che ogni destinazione possa essere raggiunta in due step.
Inoltre, la distanza di hamming tra i bit mandati sarà sempre massima (es da 2 per mandare 0
abbiamo 10 mentre per mandare 1 abbiamo 01.

Cosa succede se abbiamo un errore? Innanzitutto, se abbiamo un solo errore su 4 bit riusciamo ad
identificarlo e correggerlo (su base statistica) senza problemi, se sono due non riusciamo.

In questo caso, come per CRC, prendiamo la d minima.

Un hub è un dispositivo che agisce sui singoli bit e non fa altro che prendere il segnale e rigenerare
il bit ritrasmettendolo su tutte le altre interfacce (tranne quella da cui è arrivato il segnale).

Quello che succede è che se abbiamo una collisione, questa verrà replicata a tutta la rete. Dunque,
l’hub è diciamo un qualcosa di “stupido”.
Il bridge Ethernet sfrutta invece gli switch al posto degli hub che riescono quindi a eliminare le
collisioni.

Se A vuole comunicare con H, manda un frame a B1 e B1 si segna che da quel lato ha visto A,
dopodiché ritrasmette a tutte le uscite il segnale. Allo stesso modo di B1 agiscono B2 e B3. B3
riuscirà a raggiungere H e H per rispondere ripercorrerà la strada per arrivare ad A all’indietro.
Queste informazioni che i router si salvano vengono eliminate dopo un tot. In questi grafi non ci
sono solitamente cicli, tuttavia se ci sono dobbiamo dichiararli e potrebbero essere usati in vari
modi.
Ciò che facciamo per evitare i cicli è utilizzare lo Spanning tree protocol che mantiene inattive
alcune interfacce in modo da garantire che la rete rimanga connessa, ma priva di loop.

VLAN
Le VLAN separano a livello logico le LAN che sono costruite a livello fisico. Può capitare di dover
separare due settori di LAN esempio il settore economico dalla LAN degli studenti e questo viene
fatto attraverso le Virtual LAN.
Gli obbiettivi delle VLAN sono:
- Risparmio: Evitiamo di dover creare altre LAN fisiche
- Flessibilità: I movimenti fisici dell’utente sono facilitati
- Miglioramento delle performance: Il traffico Broadcast è confinato
- Sicurezza: Gli utenti di due VLAN diverse non vedono gli uni le frame degli altri

Port Based VLAN (untagged)

Questo tipo di VLAN partiziona lo switch in diversi parti alla quale ognuna viene assegnata ad una
VLAN diversa.

Assegniamo quindi una porta ad una VLAN. Ma come facciamo a far comunicare due switch tra di
loro? Un modo sarebbe quello di connettere una porta dello switch VLAN a un router esterno e
configurarla in modo che appartenga a entrambe le VLAN. Un altro approccio potrebbe essere
quello di far in modo che una porta faccia parte di entrambe le VLAN; tuttavia, in questo caso se ci
fossero N LAN, avremmo bisogno di N porte e questo è poco fattibile. Un approccio più comodo
può essere quello di utilizzare la tagged VLAN. Nel pratico assegniamo una porta speciale di
trunking che percorre i due switch VLAN e appartiene a tutte le VLAN. In pratica utilizziamo delle
etichette VLAN di 4 byte che contengono i campi TPID di due byte e un campo tag control di
altrettanti 2 byte.