🔬 NetLab — ISO/OSI & TCP/IP Simulator
Incapsulamento · ARP · ICMP/Traceroute · Frammentazione IP · Quiz interattivo
📚 Una risorsa di LearningObjects.org
💻 Client
🔀 Router-A
📟 DCE
🔀 Router-B
🖥 Server
1️⃣ Due modelli, una sola realtà
Il modello ISO/OSI (7 livelli) è un modello teorico e didattico, definito dall'ISO nel 1984 per descrivere in modo generale qualunque comunicazione di rete. Il modello TCP/IP (4 livelli) è invece quello realmente implementato su Internet: nasce prima dell'OSI e ha una struttura più pratica. Non sono "in competizione": l'OSI è la lente concettuale con cui si studia il TCP/IP, che è quello che gira davvero dentro i router e i sistemi operativi.
| ISO/OSI (7 livelli) | TCP/IP (4 livelli) | Esempio protocolli |
|---|---|---|
| 7. Applicazione | 4. Applicazione | HTTP, DNS, FTP, SMTP |
| 6. Presentazione | TLS/SSL, cifratura, formati | |
| 5. Sessione | Apertura/gestione sessione | |
| 4. Trasporto | 3. Trasporto | TCP, UDP |
| 3. Rete | 2. Internet | IP, ICMP |
| 2. Collegamento Dati | 1. Accesso alla Rete | Ethernet, Wi-Fi, PPP, ARP |
| 1. Fisico | Segnali elettrici/ottici/radio |
2️⃣ L'incapsulamento: una busta dentro un'altra busta
Scendendo dal livello Applicazione al livello Fisico, ogni livello aggiunge un proprio header (a volte anche un trailer) davanti ai dati ricevuti dal livello superiore, senza mai modificarne il contenuto. Il PDU (Protocol Data Unit) cambia nome ad ogni livello:
Alla ricezione avviene il processo inverso, il decapsulamento: ogni livello rimuove il proprio header e passa il resto al livello superiore. Nessun livello "legge" gli header degli altri livelli — è un principio di incapsulamento stretto, non solo una convenzione grafica.
3️⃣ Chi legge cosa: il principio chiave del routing
Il dubbio più comune degli studenti è: "il router legge tutto il pacchetto?" No. Ogni dispositivo di rete elabora i dati solo fino al livello per cui è stato progettato, e ignora tutto quello che sta sopra:
| Dispositivo | Livelli attivi | Cosa "vede" e cosa fa |
|---|---|---|
| Host (Client/Server) | Tutti (L1→L7) | Genera e consuma i dati applicativi. |
| Router | L1 + L2 + L3 | Legge l'IP destinazione, decide il next-hop, decrementa il TTL. Non guarda la porta TCP/UDP né il contenuto applicativo. |
| Switch | L1 + L2 | Inoltra in base al MAC. Non conosce l'IP. |
| DCE (modem/CSU-DSU) | Solo L1 | Converte il segnale digitale↔analogico. Non legge né MAC né IP: è "cieco" a tutto tranne ai bit grezzi. |
4️⃣ Il Router non è trasparente: cambia il frame, mai l'IP
Cosa cambia ad ogni hop:
- Indirizzo MAC sorgente e destinazione — il router costruisce un frame Ethernet completamente nuovo per ogni segmento (LAN o WAN) che attraversa.
- TTL (Time To Live) dell'header IP — decrementato di 1 ad ogni router, per evitare loop infiniti di instradamento.
- Il checksum/FCS del frame, ricalcolato ad ogni nuovo incapsulamento L2.
Cosa NON cambia mai (senza NAT):
- Indirizzo IP sorgente e destinazione — restano quelli originali dal Client al Server, per tutto il tragitto.
- Il payload applicativo (dati HTTP, query DNS…) — nessun router lo tocca.
- Le porte TCP/UDP — impostate una sola volta dall'host mittente.
È l'errore concettuale più frequente: pensare che il MAC "viaggi" fino al server. In realtà il MAC ha significato solo all'interno di un singolo segmento di rete (LAN o link WAN); l'IP invece ha significato end-to-end, dal mittente originale al destinatario finale.
5️⃣ ARP: "chi ha questo indirizzo IP?"
Prima di poter costruire un frame Ethernet, un host deve conoscere il MAC del destinatario del segmento successivo. Lo scopre con ARP (Address Resolution Protocol), un protocollo del livello Accesso Rete che opera tramite frame Ethernet:
- L'host invia una ARP Request in broadcast (FF:FF:FF:FF:FF:FF): "chi ha l'IP X?"
- Solo il proprietario di quell'IP risponde con una ARP Reply in unicast, contenente il proprio MAC.
- Il mittente salva l'associazione IP→MAC nella propria cache ARP, per non ripetere la richiesta ad ogni pacchetto.
6️⃣ TCP: prima ci si stringe la mano, poi si parla
A differenza di UDP (usato ad es. per il DNS), TCP è orientato alla connessione: prima di scambiare dati apre una connessione con un three-way handshake:
- SYN — il Client propone un numero di sequenza iniziale.
- SYN-ACK — il Server conferma e propone a sua volta il proprio numero di sequenza.
- ACK — il Client conferma: la connessione è ora stabilita in entrambe le direzioni.
Serve a sincronizzare i numeri di sequenza (necessari per riordinare e verificare i segmenti) e a verificare che il percorso funzioni in entrambe le direzioni prima di spendere risorse per inviare dati veri.
7️⃣ L'ACK non è un "segnale di ricevuto": è un pacchetto vero
Un errore comune è immaginare l'ACK come una specie di lucina verde istantanea. In realtà è un segmento TCP a tutti gli effetti: viene generato al livello Trasporto del ricevente, incapsulato fino al livello Fisico, attraversa tutta la topologia di rete (Router, DCE, Router) e viene decapsulato dal mittente originale — esattamente come i dati che conferma.
8️⃣ ICMP: il messaggero che non usa le porte
ICMP (usato da Ping e Traceroute) non passa dal livello Trasporto: niente TCP, niente UDP, niente porte. È incapsulato direttamente in IP (Protocol ID = 1).
- Ping: Echo Request → Echo Reply. Verifica la raggiungibilità di un host.
- Traceroute: sfrutta il TTL. Invia pacchetti con TTL crescente (1, 2, 3…): ogni router che decrementa il TTL a 0 scarta il pacchetto e risponde con un ICMP Time Exceeded, rivelando così, un hop alla volta, l'intero percorso fino alla destinazione.
9️⃣ Quando il pacchetto è troppo grande: la frammentazione IP
Ogni collegamento ha un MTU (Maximum Transmission Unit, es. 1500 byte su Ethernet). Se un pacchetto IP supera l'MTU del link successivo, il Router lo spezza in più frammenti (frammentazione IPv4). Punti chiave:
- Il riassemblaggio avviene sempre e solo alla destinazione finale, mai in un router intermedio.
- Con il flag DF=1 ("Don't Fragment") un router che non può inoltrare il pacchetto intero lo scarta e invia un ICMP "Fragmentation Needed" (base della Path MTU Discovery).
- IPv6 non permette la frammentazione nei router intermedi: la responsabilità è solo del mittente, tramite Path MTU Discovery.
| IPv4 | IPv6 | |
|---|---|---|
| Chi può frammentare | Il mittente e ogni router lungo il percorso | Solo il mittente, mai i router |
| Router che riceve un pacchetto > MTU | Lo frammenta e inoltra i pezzi | Lo scarta e invia ICMPv6 "Packet Too Big" |
| Come lo scopre il mittente | Flag DF=1 + ICMP "Fragmentation Needed" (opzionale) | Path MTU Discovery obbligatorio (RFC 8201) |
| Campo frammentazione | Nell'header IP base (Identification, Flags, Fragment Offset) | In un Extension Header separato ("Fragment Header"), solo se serve |
| Perché la scelta di design | Storicamente semplifica i router, ma li rallenta (calcolo extra) | Router più veloci e semplici: nessun lavoro extra sui pacchetti in transito |
🚫 Errori concettuali comuni — verifica cosa hai capito
| ✗ Falso | Il Router legge il contenuto della pagina HTTP che sta instradando. |
| ✓ Vero | Il Router si ferma al livello IP: instrada senza mai aprire il segmento TCP/UDP o il payload applicativo. |
| ✗ Falso | L'indirizzo MAC del Client arriva fino al Server. |
| ✓ Vero | Il MAC cambia ad ogni segmento di rete attraversato; solo l'IP resta invariato end-to-end. |
| ✗ Falso | Il DCE instrada i pacchetti come un router. |
| ✓ Vero | Il DCE opera solo a L1: converte segnali, non legge indirizzi di alcun tipo. |
| ✗ Falso | ARP serve a scoprire il MAC del server finale. |
| ✓ Vero | ARP è locale alla LAN: risolve solo il MAC del prossimo hop (es. il gateway). |
| ✗ Falso | L'ACK è istantaneo e non attraversa la rete. |
| ✓ Vero | L'ACK è un segmento TCP reale che percorre l'intera topologia, in senso inverso. |