Livello Transport: ruolo, servizi e multiplexing
Perché esiste il livello Transport, cosa aggiunge rispetto a IP e come fa a far convivere browser, email, SSH e DNS sullo stesso host grazie alle porte e al multiplexing/demultiplexing.
1. Perché il livello Transport esiste
IP consegna datagrammi tra host, ma non sa nulla di quale processo su quell'host debba ricevere i dati. Se sul tuo computer stai usando un browser, un client email e una sessione SSH contemporaneamente, come fa il sistema operativo a smistare i pacchetti in arrivo al processo giusto? La risposta è il livello Transport.
Il livello Transport fornisce la comunicazione end-to-end tra processi applicativi, operando esclusivamente negli host terminali. Estende il servizio di consegna host-to-host offerto da IP aggiungendo la consegna processo-to-processo, tramite l'identificazione dei processi attraverso il numero di porta.
Una distinzione cruciale: IP lavora tra host, il Transport lavora tra processi. I router non implementano il livello Transport — elaborano solo fino al livello Network. Questo è un principio fondamentale dell'architettura Internet: la complessità è concentrata ai bordi della rete (end-to-end principle, Saltzer et al., 1984).
Hai Chrome aperto su 5 tab, Outlook che scarica posta e una chat su Discord. Tutti usano lo stesso indirizzo IP, ma tre processi diversi. Senza porte, il sistema operativo non saprebbe a chi dare ogni pacchetto in arrivo. La porta è l'etichetta che risolve il conflitto.
2. I compiti principali
Segmentazione
Il livello applicativo passa blocchi arbitrariamente grandi. Il Transport li taglia in segmenti (TCP) o datagrammi (UDP) incapsulabili in IP e li riassembla al ricevitore.
Indirizzamento ai processi
Ogni segmento contiene porta sorgente e destinazione. La porta destinazione identifica il processo che deve ricevere i dati.
Controllo degli errori
Checksum su header e payload. TCP aggiunge affidabilità completa: ritrasmissione, ordine, ACK. UDP solo checksum best-effort.
Flusso e congestione
Controllo del flusso (non sovraccaricare il ricevitore) e controllo della congestione (non sovraccaricare la rete). In UDP è compito dell'applicazione.
TCP aggiunge tutte le garanzie, UDP sceglie di non aggiungerne per restare leggero e veloce. La scelta dipende dall'applicazione: vuoi affidabilità o latenza minima?
3. Il concetto di SAP — Service Access Point
Ogni livello del modello a strati offre servizi al livello superiore tramite un SAP (Service Access Point). A livello Transport, il SAP è il numero di porta: è il punto di accesso al servizio Transport per i processi applicativi.
Pensa all'IP come al numero civico di un palazzo e alla porta come al numero dell'appartamento. IP porta il pacco al palazzo giusto, la porta dice al portinaio a quale inquilino consegnarlo. Domanda da interrogazione: "Cos'è il SAP a livello Transport?" Risposta secca: "Il numero di porta".
4. Multiplexing e Demultiplexing
Il concetto di multiplexing/demultiplexing è il cuore del livello Transport. Permette a più processi applicativi di condividere lo stesso stack IP.
Multiplexing — lato mittente
Sul mittente, più processi generano dati contemporaneamente. Il livello Transport raccoglie i segmenti da tutti i processi, aggiunge le porte sorgente e destinazione, e li passa al livello IP come flusso unificato. IP non vede i singoli processi, vede solo pacchetti.
Demultiplexing — lato ricevitore
Sul ricevitore, arriva un flusso di pacchetti IP. Il livello Transport legge il campo dst_port di ogni segmento e consegna i dati al processo corretto. Il meccanismo preciso dipende dal protocollo:
| Tipo demux | Chiave di smistamento | Protocollo | Caratteristica |
|---|---|---|---|
| Connection-oriented | (src_ip, src_port, dst_ip, dst_port) — 4-tupla | TCP | Ogni connessione è univoca: stessa dst_port ma src diverso → socket TCP diverso |
| Connectionless | (dst_ip, dst_port) — 2-tupla | UDP | Più mittenti diversi → stesso socket UDP. Discriminazione a livello applicativo |
Un server web ascolta sulla porta 80. Tre client si connettono contemporaneamente. TCP usa la 4-tupla (IP_client, porta_client, IP_server, 80) per distinguere le tre connessioni. Se il server usasse solo la porta 80, non potrebbe smistare le risposte ai tre client separatamente. Con UDP invece, un server DNS sulla porta 53 riceve query da mille client sullo stesso socket: chi ha inviato la richiesta lo capisce l'applicazione.
Confondere multiplexing con "più host". Il multiplexing è sullo stesso host: più processi → un solo IP. E attenzione: TCP demux usa 4 campi, non solo la porta destinazione! Se rispondi "TCP smista solo per dst_port" perdi punti: la chiave è la 4-tupla.
5. TCP e UDP — la scelta al livello Transport
TCP/IP definisce due protocolli principali a livello Transport, progettati per esigenze opposte. Conoscerli è fondamentale per la prossima lezione sulle porte e i socket.
| Protocollo | RFC | Connessione | Affidabilità | Overhead | Uso tipico |
|---|---|---|---|---|---|
| TCP | RFC 793 (1981) | Connection-oriented | Completa (ACK, ordine, ritrasmissione) | Alto (≥20 byte header) | HTTP, HTTPS, SSH, FTP, SMTP |
| UDP | RFC 768 (1980) | Connectionless | Best-effort (solo checksum) | Minimo (8 byte header) | DNS, VoIP, streaming, gaming |
L'affidabilità implementata a livello Transport (TCP) non è duplicata nei livelli inferiori. I router IP non ritrasmettono pacchetti persi. Questa separazione è intenzionale: mantiene la rete semplice e sposta la complessità negli end-host, dove può essere aggiornata indipendentemente.
Affidabile ma pesante
20 byte minimo, handshake, ACK, finestre. Ideale quando non puoi perdere dati: web, email, file transfer.
Leggero ma inaffidabile
Solo 8 byte, nessun controllo. Ideale quando la latenza conta più della perfezione: VoIP, giochi online, DNS.
Dipende dall'app
Streaming live? UDP + buffer applicativo. Transazione bancaria su HTTPS? TCP obbligatorio. DNS perché UDP? Query piccola, risposta rapida.
6. Verifica / Esercizio
🔬 Attività di laboratorio concettuale
Apri Wireshark e cattura 2 minuti di traffico mentre navighi e fai una query DNS con nslookup. Rispondi:
- Quante porte effimere diverse vedi lato client? Perché cambiano?
- Osserva un flusso TCP verso porta 443: identifica la 4-tupla. Se apri un secondo tab sullo stesso sito, cambia dst_port o src_port?
- Trova un pacchetto UDP verso porta 53: che 2-tupla usa il demux? Quanti client diversi potrebbero usare lo stesso socket server?
- Perché il checksum UDP è opzionale in IPv4 ma obbligatorio in IPv6?
1) Ogni connessione TCP client usa una porta effimera diversa (49152-65535) per distinguere i socket, anche se la destinazione è la stessa. 2) La 4-tupla è (IP_tuo, porta_effimera, IP_server, 443). Il secondo tab apre una nuova src_port, dst resta 443. 3) Demux UDP = (IP_server, 53). Infiniti client → stesso socket, l'applicazione DNS usa Transaction ID per distinguere. 4) IPv4 ha già checksum IP (solo header), IPv6 lo ha rimosso per velocizzare i router, quindi il checksum Transport diventa l'unica verifica d'integrità end-to-end.
7. Riepilogo e concetti chiave
📚 Prossimo passo - Indirizzamento, porte logiche, socket e connessioni
Nella prossima lezione entriamo nel dettaglio delle porte: well-known vs ephemeral, come si apre un socket TCP e cosa succede durante il 3-way handshake. Porta il diagramma 4-tupla di oggi: ti servirà.