Guida completa all'architettura client-server e ai sistemi distribuiti per la maturità: dai modelli 2-tier e 3-tier al cloud computing, passando per middleware e microservizi. Esempi pratici, schemi mnemonici e collegamenti interdisciplinari per affrontare l'orale di Sistemi e Reti come un professio
Introduzione: quando il computer è ovunque e da nessuna parte
Apri Instagram per postare una foto. Scatti, applichi il filtro, premi "Condividi". Sembra istantaneo, vero? Dietro questa azione apparentemente banale si nasconde una rivoluzione architetturale che ha cambiato il mondo: il modello client-server e l'evoluzione verso i sistemi distribuiti. Se stai preparando Appunti Maturità per Sistemi e Reti, questo è l'argomento che più di ogni altro ti farà brillare agli esami — ma attenzione alle insidie. Molti studenti confondono i livelli architetturali o sottovalutano l'importanza del middleware. In questa guida vedremo 06 6. Modello clientserver e sistemi distribuiti riassunto maturità in modo approfondito, con esempi che puoi usare all'orale per dimostrare competenze reali.
Prima del 1980 dominavano i mainframe: enormi calcolatori centrali con terminali stupidi. Poi è arrivata l'architettura client-server, che ha distribuito l'intelligenza. Oggi siamo nell'era dei sistemi distribuiti globali, dove il tuo smartphone è solo la punta di un iceberg di data center, load balancer e microservizi. Pronto a capire come funziona davvero internet?
L'architettura Client-Server: il cuore della rete moderna
Il modello client-server è un paradigma architetturale in cui le funzionalità di un sistema informativo sono suddivise tra due attori: il client (chi richiede il servizio) e il server (chi lo eroga). Semplice? Apparentemente sì, ma la profondità sta nei dettagli.
Caratteristiche fondamentali
Per riconoscere un sistema client-server autentico, cerca queste quattro caratteristiche:
- Servizio: il server offre un servizio specifico (web, email, database) e il client lo consuma
- Condivisione delle risorse: il server gestisce risorse comuni (file, stampanti, dati) accessibili da multipli client
- Asimmetria: client e server hanno ruoli distinti; non sono intercambiabili (a differenza del peer-to-peer)
- Trasparenza: l'utente finale non dovrebbe preoccuparsi di dove risiede fisicamente il servizio
Thin Client vs Fat Client (Thick Client)
Qui casca l'asino in molte interrogazioni. La distinzione riguarda dove viene elaborata l'informazione:
- Thin Client (client magro): il terminale si limita a mostrare i dati. L'elaborazione avviene quasi interamente sul server. Esempio: un terminale che accede a un software gestionale via browser (Chromebook che usa Google Docs).
- Fat Client (client grasso): il dispositivo locale esegue elaborazioni significative. Esempio: un PC con installato Photoshop che elabora l'immagine localmente prima di salvarla sul cloud.
Trucco mnemonico: "Thin come una foglia — fa poco, serve il server. Fat come un hamburger — ha tutto dentro, pesante ma autonomo."
I livelli architetturali: dal 2-tier al Cloud
Mai dire all'esaminatore "client-server" senza specificare quanti livelli (tier) hai in mente. Questa distinzione dimostra competenza tecnica avanzata.
Architettura 2-Tier (Two-Tier)
Il client comunica direttamente con il server database. È il modello delle applicazioni client-server tradizionali (anni '90).
- Vantaggio: semplicità implementativa
- Svantaggio: scarsa scalabilità. Se cento client richiedono dati contemporaneamente, il database collassa. Inoltre, la logica di business è spesso spalmata sul client (fat client), rendendo difficili aggiornamenti.
Architettura 3-Tier (Three-Tier) — Lo standard moderno
Qui inseriamo un intermediario: il server applicazione (application server). I tre livelli sono:
- Presentation Layer (Client): interfaccia utente, browser o app
- Application Layer (Server Applicazione): logica di business, elaborazione dati, regole del gioco
- Data Layer (Server Database): memorizzazione persistente, query SQL
Esempio pratico: Prenoti un volo su un sito di viaggi. Il browser mostra il form (presentation). Quando clicchi "Cerca", il server applicazione calcola le rotte disponibili, verifica i prezzi, applica sconti (business logic). Solo alla fine interroga il database per recuperare i posti liberi (data).
Vantaggio cruciale: se il traffico aumento, aggiungo altri server applicazione (scalabilità orizzontale) senza toccare il database.
Architetture N-Tier e Cloud-Native
Nelle applicazioni moderne (Netflix, Spotify), abbiamo microservizi distribuiti su decine di livelli: autenticazione, pagamenti, raccomandazioni, cdn per i video. Questo ci porta ai sistemi distribuiti veri e propri.
Sistemi Distribuiti: quando il computer diventa "invisibile"
Un sistema distribuito è un insieme di computer indipendenti collegati in rete che appaiono all'utente come un unico sistema coerente. La complessità è nascosta: tu vedi "Instagram", ma dietro ci sono migliaia di server a Londra, Virginia e Singapore.
Le tre caratteristiche distintive (da memorizzare!)
Secondo Andrew Tanenbaum, guru dei sistemi operativi, un sistema distribuito vero deve avere:
- Concorrenza: i componenti operano simultaneamente, gestendo richieste parallele
- Mancanza di clock globale: ogni computer ha il proprio orologio interno; sincronizzarli è un problema complesso (algoritmi di Lamport)
- Indipendenza dai guasti: se un server muore, il sistema continua a funzionare (fault tolerance)
Il ruolo del Middleware
Il middleware è lo strato software che fa parlare tra loro componenti eterogenei. È come un interprete universale. Esempi: CORBA (storico), SOAP, REST API, gRPC, message broker come RabbitMQ o Kafka.
Senza middleware, ogni client dovrebbe conoscere il linguaggio specifico di ogni server. Con il middleware, richiedi un servizio in modo standardizzato e lui traduce.
Dal Monolite ai Microservizi: l'evoluzione che devi conoscere
Se vuoi impressionare la commissione, parla di SOA vs Microservizi.
SOA (Service Oriented Architecture)
Approccio degli anni 2000: applicazione divisa in grandi blocchi funzionali (servizi) che comunicano tramite bus centrale (ESB). Rigida, ma meglio del monolite.
Microservizi (Architettura attuale)
L'applicazione è un insieme di piccoli servizi indipendenti, ognuno con il proprio database. Il team del servizio "Pagamenti" può usare Java, quello "Notifiche" Python, senza problemi.
Vantaggio: se il servizio "Ricerca" è sovraccarico, ne lancio 10 istanze in cloud. Il servizio "Fatturazione" resta con una sola istanza. Ottimizzazione dei costi.
Cloud Computing: IaaS, PaaS, SaaS
I sistemi distribuiti moderni vivono nel cloud. Devi sapere la differenza:
- IaaS (Infrastructure as a Service): noleggi macchine virtuali (AWS EC2, Azure VMs). Tu gestisci SO, middleware, applicazioni.
- PaaS (Platform as a Service): noleggi la piattaforma (Google App Engine, Heroku). Tu carichi solo il codice, loro gestiscono l'infrastruttura.
- SaaS (Software as a Service): usi il software via web (Gmail, Salesforce, Dropbox). Zero gestione tecnica.
Esempio per l'orale: "Pensate a una pizzeria. IaaS è noleggiare la cucina e il forno. PaaS è avere gli ingredienti pronti e tu fai solo la pizza. SaaS è ordinare la pizza a domicilio e mangiarla."
Sicurezza e Sfide nei sistemi distribuiti
Non tutto è rose e fiori. La distribuzione introduce problemi seri:
Sicurezza
- Autenticazione: verificare chi sei (password, token JWT, OAuth2)
- Autorizzazione: verificare cosa puoi fare (ruoli: admin vs utente)
- Crittografia: TLS/SSL per dati in transito, AES per dati a riposo
- Single Point of Failure: evitare che un unico componente blocchi tutto (usa replicazione, ridondanza)
Consistenza dei dati
Se hai copie del database a Milano e Roma, e aggiorni Milano, quanto tempo serve per aggiornare Roma? Questo è il problema della consistenza eventualmente consistente (teorema CAP). Spiega brevemente: "Non possiamo avere contemporaneamente consistenza perfetta, disponibilità totale e tolleranza alle partizioni di rete. Dobbiamo scegliere due su tre."
Schema riassuntivo: la "tavola periodica" da memorizzare
Riassumiamo con uno schema mnemonico per non dimenticare nulla all'orale:
| Concetto | Definizione chiave | Esempio pratico |
|---|---|---|
| Client-Server | Divisione ruoli: richiesta vs erogazione | Browser che chiede pagina web |
| 2-Tier | Client ↔ Database diretto | Software gestionale anni '90 |
| 3-Tier | Client ↔ App Server ↔ Database | Sito ecommerce moderno |
| Thin Client | Elaborazione sul server | Chromebook + Google Docs |
| Fat Client | Elaborazione locale | Photoshop installato |
| Sistema Distribuito | Computer indipendenti che sembrano uno solo | Netflix, Spotify |
| Middleware | Glue software tra componenti | API REST, RabbitMQ |
| Cloud IaaS/PaaS/SaaS | Noleggio infrastruttura/piattaforma/software | AWS / Heroku / Gmail |
Trucco per l'orale: quando ti chiedono "Che cos'è un sistema distribuito?", rispondi citando le tre caratteristiche di Tanenbaum (concorrenza, no clock globale, tolleranza guasti) e un esempio immediato. Questo mostra preparazione universitaria, non solo liceale.
Collegamenti interdisciplinari per l'orale
Per un colloquio efficace, collega questo argomento ad altre materie:
- Fisica: Le leggi di Ohm e Kirchhoff governano fisicamente i bit che viaggiano nei cavi tra client e server. La velocità della luce limita la latenza nei sistemi distribuiti globali (non puoi avere un server in Australia con latenza zero per un utente italiano).
- Informatica/Programmazione: I pattern di progettazione MVC (Model-View-Controller) e MVVM si mappano perfettamente sulle architetture 3-tier. Discuti di thread, processi e race condition nella concorrenza dei sistemi distribuiti.
- Diritto e Cittadinanza: Il GDPR impatta l'architettura: se i dati personali sono distribuiti su server globali, dove risiedono fisicamente? Problema della data sovereignty. Inoltre, la responsabilità in caso di breach: è del provider cloud (SaaS) o del cliente?
- Inglese: Usa correttamente i termini tecnici: latency (latenza), throughput (throughput/banda), scalability (scalabilità), redundancy (ridondanza).
- Storia: L'evoluzione dal mainframe al client-server coincide con la nascita di Internet (ARPANET, 1969) e la liberalizzazione delle telecomunicazioni anni '90.
Vuoi metterti alla prova? Prova i nostri Quiz Maturità AI su Sistemi e Reti o fai una Simulazione Orale AI per esercitarti su questi collegamenti.
FAQ: Domande frequenti all'orale
Qual è la differenza fondamentale tra architettura client-server e peer-to-peer (P2P)?
Nel client-server c'è asimmetria: il server è sempre acceso, con indirizzo fisso, eroga servizi. I client sono intermittenti. Nel P2P (es. BitTorrent, blockchain) ogni nodo è sia client che server: scarichi un file mentre lo condividi. Non c'è un punto centrale, ma è più difficile da coordinare.
Perché si è passati dai sistemi centralizzati ai sistemi distribuiti?
Per tre ragioni: scalabilità (gestire milioni di utenti aggiungendo server), affidabilità (eliminare il single point of failure) e performance (mettere i dati vicino all'utente geograficamente, riducendo la latenza).
Cosa rischia un'azienda che usa solo un'architettura 2-tier nel 2025?
Rischia il collasso sotto carico: il database centrale diventa un collo di bottiglia. Inoltre, aggiornare la logica di business richiede reinstallare il software su ogni client (fat client), costo operativo enorme. È una scelta obsoleta per applicazioni enterprise.
Che relazione c'è tra Cloud Computing e sistemi distribuiti?
Il Cloud è l'implementazione commerciale dei sistemi distribuiti. Usa virtualizzazione per rendere "trasparente" la distribuzione fisica dei server. Tu noleggi risorse che in realtà sono sparse nel mondo, ma appaiono come un unico sistema coerente.
Cos'è il problema della consistenza nei database distribuiti?
Se ho due copie dello stesso database a Milano e Roma, e aggiorno il saldo bancario su Milano, esiste un istante in cui Roma ha dati vecchi. Questa inconsistenza temporanea è accettabile in molti casi (social media) ma inaccettabile in altri (transazioni bancarie). Il progettista deve bilanciare disponibilità e consistenza (teorema CAP).
