Modello ISO-OSI, data plane e control plane, architetture client-server e publish-subscribe

Questa nota riprende il modello a livelli con il punto di vista di chi deve programmare una applicazione di rete: dove finisce il nostro programma, dove comincia il sistema operativo, come i dati vengono incapsulati. La descrizione completa dei livelli, uno per uno, è in Modello ISO-OSI e pila TCP-IPUna comunicazione tra due calcolatori è un problema troppo vario (segnali, errori, accesso al mezzo, instradamento, controllo di flusso, rappresentazione dei dati) per un solo protocollo, quindi si divide in strati (layer). Il modello ISO/OSI ha 7 livelli (fisico, collegamento, rete, trasporto, sessione, presentazione, applicazione); la pila TCP/IP riunisce gli ultimi tre in un solo livello applicazione, quindi ne ha 5. Ogni livello offre un servizio a quello sopra e parla solo con il livello pari dell'altro nodo tramite PDU; scendendo si aggiunge un'intestazione (PCI): incapsulamento. Indirizzi: MAC (collegamento, locale), IP (rete, globale).Modello ISO-OSI e pila TCP-IP →; qui si approfondiscono SAP, PDU e SDU, la separazione fra data plane e control plane e i tre modelli di comunicazione (client/server, peer-to-peer, publish/subscribe).

I livelli e la pila TCP/IP

Il modello ISO/OSI (ISO, 1984) è un modello di riferimento, non un protocollo: descrive in sette livelli le funzioni da svolgere per far comunicare due sistemi di produttori diversi. La pila TCP/IP è invece l'architettura reale di Internet e ha quattro livelli.

In pratica i livelli 5, 6 e 7 collassano in un solo livello applicativo: HTTP stesso decide come strutturare i messaggi, come cifrarli (usando TLS sotto di sé) e come riprendere un trasferimento. Le differenze fra i due modelli sono riassunte in Modello ISO-OSI e pila TCP-IPUna comunicazione tra due calcolatori è un problema troppo vario (segnali, errori, accesso al mezzo, instradamento, controllo di flusso, rappresentazione dei dati) per un solo protocollo, quindi si divide in strati (layer). Il modello ISO/OSI ha 7 livelli (fisico, collegamento, rete, trasporto, sessione, presentazione, applicazione); la pila TCP/IP riunisce gli ultimi tre in un solo livello applicazione, quindi ne ha 5. Ogni livello offre un servizio a quello sopra e parla solo con il livello pari dell'altro nodo tramite PDU; scendendo si aggiunge un'intestazione (PCI): incapsulamento. Indirizzi: MAC (collegamento, locale), IP (rete, globale).Modello ISO-OSI e pila TCP-IP →: OSI è concettuale e ha 7 livelli, TCP/IP è basato su protocolli reali e ne ha 4.

Dove sta il nostro programma

Un punto che conta nel corso: quali livelli girano nel nostro programma e quali nel kernel.

 +--------------------------------------+
 |  programma C: client o server HTTP   |   livelli 5-7: scriviamo noi la sintassi dei messaggi
 +--------------------------------------+
 |  API delle socket (system call)      |   <-- confine user space / kernel
 +--------------------------------------+
 |  TCP o UDP                           |   livello 4  |
 |  IP                                  |   livello 3  |  nel kernel
 |  driver della scheda, Ethernet/Wi-Fi |   livelli 1-2|
 +--------------------------------------+

Quando scriviamo un client HTTP in C fabbrichiamo noi stringhe come GET / HTTP/1.1\r\n... e le consegniamo al kernel con write; segmentazione, ritrasmissioni, instradamento e framing sono fatti sotto, e noi li vediamo solo come un flusso di byte affidabile (System call POSIX, file descriptor e API delle socketLe system call sono le funzioni con cui un programma in user space chiede servizi al kernel (open, read, write, close, fork, pipe, dup2, socket, bind, listen, accept, connect); restituiscono -1 e impostano errno in caso di errore; un file descriptor e' un intero che indicizza la tabella dei file aperti del processo (0 stdin, 1 stdout, 2 stderr) e vale per file, pipe e socket; read e write possono trasferire MENO byte del richiesto (e sui socket TCP non c'e' nessun confine fra i messaggi), quindi servono cicli write_all e read_exact; l'API delle socket crea un punto finale di comunicazione (socket), lo lega a indirizzo e porta (bind), lo rende passivo (listen), accetta connessioni (accept) o si connette (connect); getaddrinfo traduce nomi e porte in indirizzi (IPv4 e IPv6); UDP usa sendto e recvfrom e conserva i confini dei datagrammi, TCP e' uno stream affidabile.System call POSIX, file descriptor e API delle socket →). Questo spiega anche perché un read può restituire meno byte di quanti ne servano: il livello 4 ha consegnato quello che era arrivato, non "un messaggio HTTP".

PDU, SDU e incapsulamento

Definizione (PDU e SDU). La PDU (Protocol Data Unit) è l'unità di dati scambiata fra due entità dello stesso livello su sistemi diversi: intestazione del protocollo più dati. La SDU (Service Data Unit) è il blocco di dati che un livello riceve dal livello superiore, da trasportare così com'è. Vale PDU(n) = intestazione(n) + SDU(n) e la PDU del livello n diventa la SDU del livello n-1.

In trasmissione ogni livello aggiunge la propria intestazione (e il livello 2 anche un trailer): è l'incapsulamento. In ricezione ogni livello toglie la sua e passa il resto in su (decapsulamento). Per la terminologia completa (PCI, SDU, PDU) si veda Modello ISO-OSI e pila TCP-IPUna comunicazione tra due calcolatori è un problema troppo vario (segnali, errori, accesso al mezzo, instradamento, controllo di flusso, rappresentazione dei dati) per un solo protocollo, quindi si divide in strati (layer). Il modello ISO/OSI ha 7 livelli (fisico, collegamento, rete, trasporto, sessione, presentazione, applicazione); la pila TCP/IP riunisce gli ultimi tre in un solo livello applicazione, quindi ne ha 5. Ogni livello offre un servizio a quello sopra e parla solo con il livello pari dell'altro nodo tramite PDU; scendendo si aggiunge un'intestazione (PCI): incapsulamento. Indirizzi: MAC (collegamento, locale), IP (rete, globale).Modello ISO-OSI e pila TCP-IP →.

Esempio. Una richiesta HTTP di 51 byte attraversa la pila di un client:

GET /index.html HTTP/1.1
Host: www.example.com

Il rapporto fra dati utili e byte trasmessi è 51 / 109 ≈ 47%: con richieste piccole l'overhead delle intestazioni è alto, ed è uno dei motivi per cui HTTP/1.1 riusa la connessione (HTTP 1.1 - connessioni persistenti, Content-Length e chunked transfer encodingHTTP/1.1 (oggi RFC 9110 e 9112) rende la connessione persistente di default (si chiude solo con "Connection: close"), rende obbligatorio l'header Host (virtual hosting) e introduce i nuovi metodi PUT, DELETE, OPTIONS, TRACE, Expect: 100-continue, richieste di intervalli (206) e Transfer-Encoding: chunked; con la connessione persistente il client deve sapere dove finisce ogni risposta: lunghezza del corpo nell'ordine HEAD/1xx/204/304 senza corpo, Transfer-Encoding chunked, Content-Length, altrimenti fino alla chiusura; il chunked divide il corpo in blocchi preceduti dalla lunghezza in esadecimale, termina con un chunk 0 e un trailer facoltativo, e si decodifica contando i byte dichiarati (non cercando CRLF).HTTP 1.1 - connessioni persistenti, Content-Length e chunked transfer encoding →). Il pacchetto da 91 byte è molto più piccolo della MTU di Ethernet (1500 byte), quindi non c'è frammentazione (Datagramma IP e frammentazioneIPv4 è un servizio senza connessione, non affidabile, best effort: i pacchetti (datagrammi) possono essere persi, corrotti, riordinati o ritardati. L'intestazione ha 20-60 byte (HLen conta parole da 4 byte, da 5 a 15); il campo Total Length (16 bit) dà la lunghezza totale fino a 65 535 byte; TTL limita i salti, Protocol identifica il protocollo trasportato (1 ICMP, 6 TCP, 17 UDP), il checksum copre solo l'intestazione. Se un datagramma è più grande dell'MTU del collegamento viene frammentato: solo il payload si divide, ogni frammento ha un'intestazione propria; l'Offset (13 bit) è in unità di 8 byte, MF=1 in tutti i frammenti tranne l'ultimo, e il riassemblaggio avviene solo a destinazione.Datagramma IP e frammentazione →).

SAP: il punto di accesso al servizio

Definizione (SAP). Un SAP (Service Access Point) è il punto in cui un livello offre i suoi servizi al livello superiore: l'interfaccia logica fra due livelli adiacenti. Ogni SAP ha un indirizzo che dice a quale utente del servizio vanno consegnati i dati.

Lo stesso meccanismo ricorre a ogni livello, con un nome diverso per l'indirizzo del SAP:

Il demultiplexing in ricezione è una catena di SAP: il frame ha EtherType 0x0800, quindi va a IP; il pacchetto ha protocol 6, quindi va a TCP; il segmento ha porta di destinazione 80, quindi va al processo che ha eseguito bind sulla porta 80 (Livello di trasporto - porte e multiplexingIl livello di trasporto (transport layer) offre la comunicazione logica end-to-end tra processi applicativi di host diversi, ed è realizzato solo negli host finali, non nei router. Il livello di rete consegna al computer giusto (indirizzo IP), il trasporto consegna al processo giusto (numero di porta di 16 bit, 0-65535). Una porta più un indirizzo IP formano un socket; la quaterna (IP sorgente, porta sorgente, IP destinazione, porta destinazione) identifica una connessione. I servizi sono: comunicazione processo-processo, indirizzamento, incapsulamento/decapsulamento, multiplexing/demultiplexing e, se il protocollo è affidabile, controllo di errore, di flusso e di congestione. I protocolli sono UDP (senza connessione, inaffidabile), TCP (con connessione, affidabile) e SCTP (combina i due).Livello di trasporto - porte e multiplexing →). Per un programma C il SAP del livello di trasporto è l'API delle socket: l'indirizzo del SAP è la coppia (indirizzo IP, porta), e il descrittore restituito da socket() è il nostro riferimento locale a quel punto di accesso. Un server che chiama bind sulla porta 8080 sta registrando il proprio SAP: da quel momento i segmenti con porta di destinazione 8080 gli vengono consegnati.

Nel modello OSI formale l'interazione attraverso un SAP avviene con quattro primitive di servizio: request (il livello superiore chiede il servizio), indication (il livello inferiore avvisa l'utente remoto), response e confirm. In un programma di rete le si riconosce: connect è una request, il ritorno di accept sul server è la indication corrispondente.

Data plane e control plane

Le funzioni di una rete si dividono in due gruppi.

Definizione (data plane e control plane). Il data plane (piano dati, anche forwarding plane) è la parte che inoltra i pacchetti, uno per uno e alla velocità della linea, applicando regole già decise: consultare la tabella di inoltro, commutare, filtrare, tradurre indirizzi. Il control plane (piano di controllo) è la parte che decide quelle regole: costruire e aggiornare le tabelle di instradamento scambiando messaggi con gli altri nodi, scegliere i percorsi, gestire la QoS.

Un'analogia: il data plane è l'automobilista che segue i cartelli, il control plane è chi disegna la mappa e posa i cartelli. Nelle reti definite dal software (SDN) i due piani si separano anche fisicamente: un controllore centrale calcola le regole e le scrive nei dispositivi, che si limitano a inoltrare. Si veda Instradamento e inoltroL'inoltro (forwarding) mette il pacchetto sulla strada verso la destinazione, un salto alla volta (hop by hop). Se la destinazione è nella stessa rete del mittente l'inoltro è diretto (si usa l'ARP per il MAC del destinatario), altrimenti è indiretto: il pacchetto va al router successivo (next hop) indicato dalla tabella di instradamento, o al default gateway. Con le netmask: l'inoltro è diretto attraverso l'interfaccia $x$ se $\text{IP(dst)}\ \text{AND}\ \text{NM}(x)=\text{IP}(x)\ \text{AND}\ \text{NM}(x)$; altrimenti si scorre la tabella dalla maschera più lunga (longest prefix match) e si usa il primo match. La riga con rete $0.0.0.0$ e maschera $0.0.0.0$ (default route) corrisponde sempre. L'aggregazione di rotte (route aggregation) riduce la tabella, e nell'inoltro con etichette (MPLS) la tabella si consulta per indice.Instradamento e inoltro → per la distinzione fra inoltro (data plane) e instradamento (control plane).

Anche in un'applicazione web si può leggere questa distinzione: il trasferimento del documento (la risposta HTTP) è il piano dati, mentre la risoluzione del nome con il DNS e la costruzione delle regole di instradamento che permettono ai pacchetti di arrivare sono di controllo.

Modelli di comunicazione

Le applicazioni di rete si organizzano in tre modi principali.

Client/server

Due ruoli: il client apre la comunicazione e invia una richiesta, il server è sempre in ascolto, elabora e risponde. Il modello funziona come una chiamata di funzione: il chiamante invia argomenti e attende il risultato. È il modello di HTTP, DNS, SMTP: il server ha un indirizzo noto (nome DNS e porta), il client no.

• Vantaggi: dati e regole centralizzate, controllo e sicurezza più semplici, il client può essere minimale.
• Limiti: il server è un punto singolo di guasto; la scalabilità è limitata dalla sua capacità; se è sovraccarico aumenta la latenza.
• Rimedi: più server dietro un bilanciatore di carico, cache e proxy (DNS, proxy web, HTTP CONNECT e gateway applicativiUn programma risolve i nomi con getaddrinfo (file hosts e poi DNS); un messaggio DNS (RFC 1035) ha un header di 12 byte (ID, flag QR/RD/RA/TC e RCODE, quattro contatori), una domanda (QNAME a etichette con lunghezza, QTYPE, QCLASS) e record di risposta con nomi eventualmente compressi da puntatori, su UDP porta 53 con ripiego su TCP se il bit TC e' acceso; un web proxy e' un intermediario scelto dal client che riceve richieste con URI assoluto, le inoltra al server (togliendo gli header hop-by-hop, aggiungendo Via e X-Forwarded-For) e puo' memorizzare le risposte; le cache si organizzano in gerarchie e con funzioni hash coerenti, le CDN le replicano vicino agli utenti; il metodo CONNECT chiede al proxy un tunnel TCP verso host:porta e dopo la risposta 2xx il proxy inoltra i byte in entrambe le direzioni senza interpretarli (HTTPS, con restrizione delle porte); un gateway o reverse proxy e' un intermediario scelto dal server che traduce o inoltra le richieste ad altri sistemi (bilanciamento, terminazione TLS, FastCGI, API gateway).DNS, proxy web, HTTP CONNECT e gateway applicativi →), replicazione.

I server possono essere iterativi (un client alla volta) o concorrenti (più client insieme, con processi, thread o eventi): si veda Client e server TCP in C - bind, listen, accept e processi concorrentiUn client TCP in C fa getaddrinfo, socket, connect, poi write e read; un server fa socket, setsockopt(SO_REUSEADDR), bind, listen e un ciclo di accept. Un server iterativo serve un client alla volta e un client lento blocca tutti; un server concorrente con fork crea un processo figlio per ogni connessione: il figlio chiude il socket di ascolto e serve la connessione, il padre chiude il socket di connessione e torna ad accept. I figli terminati diventano zombie finche' il padre non li raccoglie con waitpid, di solito in un gestore di SIGCHLD con WNOHANG in un ciclo; i descrittori non chiusi tengono viva la connessione (nessun FIN) o esauriscono EMFILE; uno stato CLOSE_WAIT che si accumula indica una close mancante. Alternative: thread, pre-fork, I/O multiplexing con poll o epoll.Client e server TCP in C - bind, listen, accept e processi concorrenti →.

Peer-to-peer

Tutti i nodi (peer) sono alla pari: ciascuno è client e server insieme e comunica direttamente con gli altri, senza un nodo centrale. Esempi: BitTorrent, le reti blockchain. Vantaggi: scalabilità (ogni nuovo nodo porta anche capacità), resilienza ai guasti, banda distribuita. Svantaggi: ricerca dei peer e gestione dei collegamenti complesse, sicurezza e autenticazione difficili, prestazioni che dipendono dai peer disponibili.

Publish/subscribe/notify

Tre ruoli: il publisher produce i dati, il subscriber si iscrive per riceverli, il broker è l'intermediario che registra le iscrizioni e inoltra ogni evento pubblicato a chi è interessato.

 publisher --- publish(argomento, dati) ---> BROKER --- notify(argomento, dati) ---> subscriber A
                                               ^                                 \-> subscriber B
        subscriber A, B --- subscribe(argomento) ---+

Il modello funziona come un interrupt hardware: il subscriber non chiede ripetutamente (polling), si registra una volta e riceve notifiche asincrone quando l'evento accade. Si dice che publisher e subscriber sono disaccoppiati:

Vantaggi: alta scalabilità, traffico distribuito in modo efficiente, produttori e consumatori indipendenti. Svantaggi: una tappa in più (più latenza), il broker è un punto di dipendenza (se cade, cade il sistema), affidabilità e persistenza degli eventi da garantire.

Esempio. Un sensore pubblica la temperatura sull'argomento meteo/padova/temperatura; un'app si iscrive a meteo/padova/# e riceve ogni misura di Padova, mentre un'altra si iscrive a meteo/+/temperatura e riceve la temperatura di ogni città. (Nei protocolli come MQTT + sostituisce un livello e # tutti i livelli rimanenti.)

HTTP è client/server per costruzione: il server non può "spingere" dati se il client non ha chiesto nulla. Per ottenere notifiche si ricorre a tecniche di polling o di long polling, oppure a WebSocket, che apre un canale bidirezionale persistente sul quale il server può inviare eventi quando vuole (WebSocket, QUIC e HTTP-3HTTP e' richiesta e risposta, quindi poco adatto a notifiche e dati in tempo reale (polling, long polling, SSE); WebSocket (RFC 6455) apre con un handshake HTTP/1.1 Upgrade (Sec-WebSocket-Key a 16 byte casuali in Base64, risposta 101 con Sec-WebSocket-Accept = Base64 di SHA-1 di chiave piu' GUID fisso) un canale bidirezionale persistente sulla stessa connessione TCP, con frame di 2-14 byte di intestazione (FIN, opcode, MASK, lunghezza su 7, 16 o 64 bit, chiave di mascheramento obbligatoria dal client al server) e messaggi di testo, binari, close, ping e pong. QUIC (RFC 9000) e' un protocollo di trasporto sopra UDP con TLS 1.3 integrato, flussi indipendenti (niente head-of-line blocking fra flussi), connection ID che permettono di cambiare rete, handshake in 1 RTT e ripresa in 0 RTT; HTTP/3 (RFC 9114) mappa HTTP su QUIC con un flusso per richiesta e QPACK per gli header, ed e' annunciato con Alt-Svc.WebSocket, QUIC e HTTP-3 →): è il modo con cui molte applicazioni web realizzano di fatto un publish/subscribe.

Dove si colloca il resto del corso

Il percorso del corso segue la pila dall'alto verso il basso e ritorno: prima l'interfaccia fra applicazione e kernel (System call POSIX, file descriptor e API delle socketLe system call sono le funzioni con cui un programma in user space chiede servizi al kernel (open, read, write, close, fork, pipe, dup2, socket, bind, listen, accept, connect); restituiscono -1 e impostano errno in caso di errore; un file descriptor e' un intero che indicizza la tabella dei file aperti del processo (0 stdin, 1 stdout, 2 stderr) e vale per file, pipe e socket; read e write possono trasferire MENO byte del richiesto (e sui socket TCP non c'e' nessun confine fra i messaggi), quindi servono cicli write_all e read_exact; l'API delle socket crea un punto finale di comunicazione (socket), lo lega a indirizzo e porta (bind), lo rende passivo (listen), accetta connessioni (accept) o si connette (connect); getaddrinfo traduce nomi e porte in indirizzi (IPv4 e IPv6); UDP usa sendto e recvfrom e conserva i confini dei datagrammi, TCP e' uno stream affidabile.System call POSIX, file descriptor e API delle socket →), poi i protocolli del livello applicativo costruiti sopra TCP (HTTP 0.9 e 1.0 - struttura dei messaggi, header e parsingHTTP/0.9 (1991) ha una sola riga di richiesta "GET /percorso" e la risposta e' solo il documento HTML, senza codici di stato ne' header, e la connessione si chiude alla fine; HTTP/1.0 (RFC 1945) aggiunge Request-Line con versione, Status-Line con codice, header (generali, di richiesta, di risposta, di entita'), i metodi HEAD e POST, tipi di contenuto diversi dall'HTML; un messaggio e' riga iniziale, header "Nome: valore" a righe CRLF, riga vuota, corpo; in HTTP/1.0 il corpo della risposta finisce quando il server chiude la connessione, mentre per POST serve Content-Length; il parsing legge la prima riga, poi gli header fino alla riga vuota, poi il corpo; i nomi degli header non distinguono maiuscole e minuscole, e un client robusto accetta LF semplice e spazi variabili.HTTP 0.9 e 1.0 - struttura dei messaggi, header e parsing →), poi i servizi di supporto (DNS, proxy) e infine le evoluzioni che cambiano il trasporto (QUIC su UDP). Per le prestazioni dei protocolli si veda Analisi delle prestazioni di reteLe prestazioni di una rete si misurano con tre famiglie di metriche: traffico (bitrate $R_0$ massimo del collegamento, throughput $S\le R_0$ dati consegnati con successo, goodput al livello applicazione), ritardo (end-to-end $d_{tot}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$ con $d_{trans}=L/R$ e $d_{prop}=d/v$; jitter; RTT) e capacità del tubo (BDP $=R\cdot$ ritardo, bit che riempiono il collegamento), più l'affidabilità (PER, PDR, PLR). Il throughput di un percorso è quello del collegamento collo di bottiglia, $\min$ dei bitrate, ricordando che i collegamenti condivisi dividono la capacità.Analisi delle prestazioni di rete →.

Errori tipici

• Confondere PDU e SDU: la SDU del livello n è la PDU del livello n+1, senza l'intestazione del livello n.
• Dire che OSI è "il protocollo usato in Internet": è un modello di riferimento; Internet usa TCP/IP.
• Collocare il livello di trasporto nel programma applicativo: TCP e UDP stanno nel kernel, il programma li usa tramite l'API delle socket.
• Confondere porta e indirizzo IP: l'IP identifica la macchina, la porta identifica il processo (il SAP del trasporto è la coppia).
• Scambiare data plane e control plane: l'inoltro del singolo pacchetto è data plane, il calcolo delle tabelle (RIP, OSPF, BGP) è control plane.
• Dire che client/server e publish/subscribe sono equivalenti: nel primo il client chiede e aspetta, nel secondo il subscriber si iscrive e riceve notifiche asincrone.

Domande d'esame

1. Spiegare il significato di SDU, PDU e SAP, e fare l'esempio di una richiesta HTTP che attraversa la pila fino al frame Ethernet. Traccia. La PDU è l'unità scambiata fra livelli omologhi (intestazione + dati); la SDU è ciò che arriva dal livello superiore; il SAP è l'interfaccia fra due livelli, con un indirizzo (porta per TCP, protocollo per IP, EtherType per Ethernet). Esempio: richiesta di 51 byte, segmento TCP di 71 byte, pacchetto IP di 91, frame Ethernet di 109 byte (14 di intestazione e 4 di CRC); il demultiplexing a destinazione segue EtherType, protocol e porta.

2. Differenza fra data plane e control plane in un router. A quale piano appartiene OSPF? Traccia. Il data plane inoltra ogni pacchetto cercando la porta di uscita nella tabella di inoltro (e decrementando il TTL); il control plane costruisce quella tabella scambiando messaggi con gli altri router. OSPF è un protocollo di instradamento: appartiene al control plane.

3. Confrontare client/server e publish/subscribe indicando quando conviene il secondo. Traccia. Client/server: richiesta e risposta sincrone, come una chiamata di funzione; il server è un punto centrale e noto. Publish/subscribe: broker che inoltra eventi, come un interrupt; produttori e consumatori sono disaccoppiati nello spazio, nel tempo e nella sincronizzazione. Conviene quando molti utenti devono ricevere in modo asincrono eventi di interesse (notifiche, sensori), evitando il polling, accettando una latenza in più e la dipendenza dal broker.