Se ti interessa l’argomento reti, sicuramente hai incontrato almeno una volta il termine TCP/IP, insieme ad almeno uni di questi altri:

• Stack protocollare;
• Suite di protocolli;
• TCP, UDP, IP;
• Modello TCP/IP;
• Modello ISO/OSI.

Volendo possiamo aggiungerne altri.

Ciò che li accomuna è questo: tutti hanno a che fare con l’argomento di questo articolo, ovvero la suite di protocolli Internet TCP/IP.

Prima di entrare nello specifico, cominciamo con lo spiegare cosa caspita sia una suite di protocolli Internet.

Innanzitutto, stack (in italiano pila) di protocolli e suite di protocolli sono, di fatto, sinonimi.

Una suite di protocolli non è nient’altro che un insieme di protocolli di rete. Fine.
Se proprio vogliamo essere più precisi (e corretti), possiamo dire che questi protocolli devono essere specificati con un certo ordine.

Il motivo risulterà ovvio tra qualche paragrafo.

Sappiamo tutti cos’è un protocollo? Cioè un insieme di regole che degli interlocutori devono rispettare per riuscire a comunicare?

Bene, ora entriamo nel vivo.

Layering di Protocolli

Oh che parolona. Dall’inglese layer, tiriamo fuori l’italiano strato, o livello se vogliamo.
Infatti per comunicazioni complesse, si devono usare più protocolli.

Da qui deriva l’introduzione di una suite di protocolli, in un certo ordine.

Tra poco vedremo quali protocolli, e in quale ordine.

Ti anticipo che la stratificazione dei protocolli serve a garantire:

• Modularizzazione;
• Suddivisione di compiti complessi in sotto-compiti più semplici;
• Astrazione del problema.

Insomma i soliti principi fondamentali-ricorrenti che piacciono molto a noi informatici.

Inoltre tra due interlocutori, ogni livello dello stack TCP/IP forma un collegamento logico tra le due parti.

Lo Stack TCP/IP

Ora che abbiamo ben chiare le proprietà della stratificazione dei protocolli di rete, parliamo di qualcosa di concreto.

La suite TCP/IP infatti, realizza proprio quel layering di cui abbiamo parlato poco fa.
Il nome deriva da due protocolli importanti che la possono caratterizzare, ovvero:

• TCP a livello di trasporto;
• IP a livello di rete.

Ora daremo un senso a ciò che hai appena letto.

Un altro modo per definire uno stack protocollare, è come famiglia di protocolli.

Ed ora puoi dare il benvenuto alla famiglia di protocolli TCP/IP.

Due parole su questo schema:

La voce routing è tra parentesi graffe perché non è banalmente un esempio di protocollo, ma un insieme di protocolli che si occupano dell’instradamento dei pacchetti.
Vedremo tutto meglio a tempo debito.

La pila TCP/IP completa è implementata in ogni end-system, ovvero gli host interlocutori.
Più in là vedremo che gli intermediate-system, generalmente, non implementano tutti e cinque i livelli:

• I router implementano i primi tre livelli;
• Gli switch (ed altri) si fermano al secondo livello.

In questa immagine vediamo lo stack protocollare TCP/IP implementato tra due host.

Questa immagine ci serve per due motivi:

• Vediamo con un bel disegnino quanto detto fino ad ora;
• Ci porta ad un discorso abbastanza importante, di cui parliamo ora.

Incapsulamento e Decapsulamento

Ho mentito.

Non sull’importanza di questo argomento, ma riguardo la parola discorso.
Infatti c’è veramente poco da dire. Vediamo.

Quando un dispositivo vuole comunicare con un altro dispositivo, deve:

1. Prendere il messaggio da inviare;
2. Ficcarlo in una scatola;
3. Inviarlo al livello inferiore;
4. Il quale lo ficca in un’altra scatola.

Questo giretto termina a livello 1.

La Matrioska appena creata viene inviata lungo il canale (cablato o wireless che sia), fino a raggiungere la destinazione, dove viene:

1. Aperta;
2. Il contenuto passato al livello superiore;
3. Riaperta;
4. Etc…

Fino ad arrivare al livello corretto (ricordi il canale logico?), dove si ritrova il messaggio originale.

I passi che abbiamo descritto sono rispettivamente: incapsulamento e decapsulamento.
Il mittente incapsula; il ricevente decapsula.

Un po' più formalmente, durante l’incapsulamento:

1. Ogni livello riceve un pacchetto dal livello superiore, che comprende un header e dei dati (payload);
2. Il livello crea un nuovo pacchetto con un proprio header;
3. Nel nuovo pacchetto inserisce come payload quello ricevuto prima.
4. Invia questa scatola al livello inferiore.

In fase di decapsulamento, avviene la procedura inversa.

Multiplexing e Demultiplexing

Dato che esistono molti protocolli per livello, ti potrai chiedere se è possibile utilizzarli contemporaneamente; e se sì, come.

La risposta alla prima domanda è YES.
Per la seconda domanda, guarda qui:

Come vedi questo principio è strettamente legato all’incapsulamento.

• Multiplexing (arancione): un protocollo incapsula e recapita pacchetti ottenuti da più protocolli dal livello superiore;
• Demultiplexing (verde): un protocollo decapsula e recapita pacchetti verso più protocolli superiori.

La cosa non scontatissima è che per realizzare tutto questo c’è bisogno di alcune informazioni nell’intestazione (header) dei pacchetti.
Ad esempio, se un pacchetto deve essere ricevuto da UDP, nell’header IP deve essere specificata questa informazione.

Queste cose le vedremo meglio nei prossimi articoli.

Ora andiamo avanti con questa introduzione.

Indirizzamento nello Stack TCP/IP

Fermi tutti. Di che si parla quando diciamo indirizzamento? A quali indirizzi ci riferiamo?

Chi ha un po' di familiarità con le reti, conosce sicuramente questi oggettini: URL ed indirizzi IP.

Anche il tuo fornaio preferito ha una vaga idea di come sia fatto un URL (forse).
Ed il fornaio avanzato ha anche visto un indirizzo IP.

Questi infatti, sono solo due sistemi per indirizzare qualcosa, ad un certo livello dello stack.

Nella tabella dello stack TCP/IP ho elencato anche i tipi di indirizzamento.
In questo momento non è importante entrare nel dettaglio, ma per farti un esempio:

In pratica, ad ogni livello della pila TCP/IP, si usano degli indirizzi di forma diversa, per identificare particolari oggetti di quel livello.

L’indirizzamento serve a garantire che un pacchetto vada nella giusta direzione, fino all’host specifico di destinazione.

Bello eh?

Ora possiamo concludere questa prima parte introduttiva con un mattoncino teorico di scarsa utilità pratica, ma importante perché:

• È una curiosità, ed è scientificamente provato che a volte aiuta a fissare cose più importanti;
• Fa capire come **non **si è evoluto TCP/IP.

Vediamo.

Confronto con il modello ISO/OSI

Questo ISO/OSI (Open Systems Interconnection) è un altro modello di stack protocollare.

Attenzione: perché è solo un modello, e non una vera e propria famiglia di protocolli?

Perché non esiste. Non è mai esistito, e non esisterà mai.

O meglio, esiste solo sulla carta: in teoria.

Infatti viene definito come modello teorico di stack di protocolli di rete, e qualcuno dice addirittura che TCP/IP sia stato costruito in riferimento al modello ISO/OSI.

Cosa non vera. Infatti TCP/IP nacque prima di ISO/OSI.

TCP/IP non ha mai dato problemi, ed è sempre stato efficiente.
Un eventuale cambio con OSI sarebbe stato costoso e rischioso.
Inoltre OSI è anche privo di alcuni requisiti per i livelli 5 e 6, che contribuiva a renderlo una scelta non sicura.

Quindi l'ente ISO decise di imporlo solamente come modello teorico, su cui eventuali futuri stack protocollari dovevano far riferimento.

Sinceramente, non vale la pena di mettersi a spiegare quale livello doveva fare cosa in ISO/OSI.
Se ti interessa, ti lascio l’articolo che ne parla su Wikipedia.

Bene, abbiamo finito la parte introduttiva sullo stack TCP/IP.

Se sei rimasto a leggere fino alla fine, può significare che:

• Ti interessa l’argomento;
• Probabilmente lo devi studiare;
• Sei una bella persona.

Ti avviso che scriverò altri articoli per la serie reti, quindi questo mini-corso andrà avanti.
Puoi iscriverti alle newsletter per essere avvisato sui nuovi articoli, così non lasciamo cose in sospeso.

Non escludere la possibilità di condividere l’articolo con qualcuno a cui può essere utile :)
Per qualsiasi cosa, non esitare a lasciarmi un commento qui sotto.