Il processo di Segmentazione e il riassemblaggio dei dati

Il processo di Segmentazione e il riassemblaggio dei dati

Nel momento in cui decidi di caricare un video in 4K del peso di svariati Gigabyte sul tuo spazio Cloud, il tuo browser non può prendere quel mastodontico blocco di dati e gettarlo interamente sul cavo di rete. Le infrastrutture fisiche di telecomunicazione (i cavi di rame, la fibra ottica, i circuiti degli switch) possiedono rigidi limiti fisici e architetturali sulla quantità di bit che possono essere iniettati in un singolo "colpo" continuo.

Questo limite tecnico, noto come MTU (Maximum Transmission Unit), impone che il dato originario venga letteralmente affettato in porzioni microscopiche. Il compito gravoso di prendere lo stream continuo di dati dall'applicazione, tagliarlo in pezzi perfetti e ricomporlo a destinazione è affidato interamente al Livello 4 della pila OSI. In questa lezione analizzeremo a fondo il processo di Segmentazione e Riassemblaggio, scoprendo come il protocollo TCP prevenga il disastroso fenomeno della frammentazione IP.

Il limite fisico della rete e la nascita del Segmento

Nelle reti Ethernet standard moderne, l'MTU è storicamente fissato a 1500 byte. Questo significa che l'hardware di rete non accetterà mai di trasportare un pacchetto IP il cui carico (incluso l'header IP stesso) superi i 1500 byte. Se un'applicazione passa al sistema operativo un file da 1 Megabyte in un unico blocco, il Livello 4 deve intervenire proattivamente prima che il dato raggiunga il Livello 3 (Rete).

Il protocollo di Trasporto (nello specifico, il TCP) cattura il flusso di byte (Byte Stream) proveniente dal Livello 7 (Applicazione) e lo "affetta" in blocchi più piccoli. La dimensione massima di ogni singola fetta è definita MSS (Maximum Segment Size). [tooltip]In una tipica connessione IPv4 su Ethernet, l'MSS è di 1460 byte. Questo valore si ottiene prendendo l'MTU di 1500 byte e sottraendo i 20 byte riservati all'header IP e i 20 byte riservati all'header TCP (1500 - 20 - 20 = 1460).[/tooltip]

A ogni singolo blocco da 1460 byte, il protocollo TCP aggancia la propria intestazione (Header di Livello 4, contenente le Porte Sorgente e Destinazione). L'unione di questo blocco di dati e del suo header prende il nome tecnico di Segmento  . Questo segmento è ora perfettamente dimensionato per entrare nel pacchetto IP senza farlo "esplodere" oltre i limiti dell'MTU.

Numeri di Sequenza: mappare l'ordine nel caos di Internet

Una volta affettato il video da 1 Gigabyte in centinaia di migliaia di segmenti, questi vengono passati al Livello 3, che li immette su Internet. Tuttavia, Internet è una rete a commutazione di pacchetto con routing dinamico. Questo significa che il Segmento numero 1 potrebbe passare per Milano e Parigi, mentre il Segmento numero 2, a causa di un cavo tranciato, potrebbe essere instradato via Francoforte, subendo un ritardo.

Il risultato è inevitabile: i segmenti arriveranno al server di destinazione fuori ordine  . Per evitare che il file video risulti illeggibile e corrotto, il protocollo TCP inserisce nell'header di ogni segmento un Numero di Sequenza (Sequence Number) a 32 bit.

A livello ingegneristico, il Numero di Sequenza del TCP non si limita a contare i segmenti ("Segmento 1, Segmento 2, Segmento 3..."), ma conta fisicamente i byte trasmessi. Se il primo segmento trasporta i primi 1460 byte del file, il suo Sequence Number segnerà l'inizio. Il secondo segmento non avrà come sequence number "2", ma avrà un sequence number incrementato di 1460, a indicare l'esatto offset (scostamento) dei byte all'interno del file originale. Questa granularità chirurgica permette al ricevitore di sapere esattamente quale pezzo del puzzle ha in mano.

Il Riassemblaggio: ricostruire il puzzle a destinazione

Spostiamoci ora sul computer destinatario (il server Cloud). La scheda di rete riceve i pacchetti, il Livello 3 rimuove le intestazioni IP e passa i Segmenti al Livello 4 (TCP). Inizia la delicatissima fase di Riassemblaggio (Reassembly).

Il sistema operativo alloca una porzione di memoria RAM chiamata Receive Buffer (Buffer di Ricezione). Man mano che i segmenti arrivano, il TCP analizza i Numeri di Sequenza e posiziona ogni blocco di dati nell'esatto slot di memoria corrispondente. Se il segmento contenente i byte da 3000 a 4000 arriva prima del segmento contenente i byte da 1000 a 2000, il TCP non va nel panico: lo salva temporaneamente nel buffer, lasciando un "buco" vuoto prima di esso, e attende pazientemente l'arrivo del segmento ritardatario.

Solo quando un'intera sequenza contigua di byte è stata ricomposta nel buffer, il TCP strappa via gli header di Trasporto e passa il blocco unificato all'applicazione (es. il demone web), che vedrà solo uno stream fluido e perfetto, completamente ignara del caos che i pacchetti hanno subito su Internet.

Il lato oscuro: UDP e la Frammentazione IP

Cosa accade se invece del TCP usiamo l'UDP (User Datagram Protocol)? L'UDP è stato progettato per essere estremamente leggero e veloce.

Sintesi applicativa e autoverifica

La Segmentazione e il Riassemblaggio sono le due facce della stessa medaglia ingegneristica che permette a Internet di veicolare file immensi attraverso infrastrutture modellate per supportare solo piccoli pacchetti. Il TCP agisce come un meticoloso magazziniere: taglia i colli grandi (MSS) per farli entrare nei furgoni (MTU), li numera in modo progressivo calcolando il peso in byte (Sequence Numbers) e li stocca in un magazzino temporaneo a destinazione (Receive Buffer) per riconsegnarli al cliente perfettamente in ordine.

Per autovalutare la comprensione di queste logiche, eseguiamo un calcolo: una connessione TCP (su IPv4) ha un MSS massimo calcolato a 1460 byte. L'applicazione software generatrice decide di inviare un file delle dimensioni esatte di 3000 byte. Quanti Segmenti TCP verranno generati dal Livello di Trasporto del mittente per poter trasmettere questo file? E quanti byte di payload applicativo (escludendo gli header) conterrà l'ultimo di questi segmenti prima di essere imballato per la spedizione sul cavo?