Le Web Application e il Modello Client-Server
Come funzionano Gmail, Instagram e Google Docs dietro le quinte? Partiamo dal modello che ha rivoluzionato Internet.
1. Introduzione
Negli ultimi decenni, le applicazioni Web hanno profondamente trasformato il modo in cui interagiamo con i servizi digitali. Dall’istruzione al lavoro, dall’intrattenimento al commercio elettronico, gran parte delle attività quotidiane passa ormai attraverso il Web. Per comprenderne il funzionamento, è fondamentale analizzare il modello architetturale su cui si basano: il modello client-server.
Ragazzi, questa è la lezione più importante di tutto il Modulo 2. Se capite bene client-server, capite il 90% di Internet. Ogni volta che aprite Instagram, fate una richiesta a un server che sta a migliaia di km da voi e quel server vi risponde. Sembra magia, ma è un modello preciso che studieremo riga per riga. Segnatevi questa frase per l'orale: "Il client chiede, il server risponde, il protocollo regola come".
2. Cos’è una Web Application
Una Web Application è un’applicazione software accessibile tramite un browser Web e ospitata su uno o più server remoti. A differenza delle applicazioni tradizionali, non richiede l’installazione locale sul dispositivo dell’utente, ma utilizza la rete Internet per fornire servizi e funzionalità.
Esempi di Web Application sono:
- Servizi di posta elettronica come Gmail
- Suite di produttività come Google Docs
- Piattaforme di e-learning
- Social network come Instagram o Facebook
Questi servizi sono accessibili da qualsiasi dispositivo con connessione a Internet e un browser moderno, senza necessità di software aggiuntivo.
Pensate a cosa succedeva 15 anni fa: per usare Word dovevate comprare il CD, installarlo, attivare la licenza, aggiornarlo. Con Google Docs aprite Chrome e scrivete. Zero installazioni, zero aggiornamenti, zero virus. Per un'azienda è un risparmio enorme: sviluppa una sola volta e funziona su PC, Mac, tablet, smartphone. Ecco perché oggi il 95% dei nuovi software nasce come Web App.
3. Il Modello Client-Server
Il funzionamento delle Web Application si basa sul modello client-server, che prevede la collaborazione tra due entità distinte:
- Client: dispositivo o programma che invia richieste di servizio. Può essere un computer, uno smartphone o un browser Web.
- Server: sistema remoto che riceve le richieste, le elabora e invia le risposte al client.
Questa separazione dei ruoli consente di realizzare sistemi scalabili, modulari e facilmente manutenibili. Ogni client può inviare richieste multiple, e il server è in grado di gestirle tramite meccanismi di concorrenza.
Io spiego client-server così: voi siete al ristorante (client), il cameriere è il protocollo HTTP, la cucina è il server. Voi ordinate (richiesta), la cucina prepara (elabora), il cameriere vi porta il piatto (risposta). Se ci sono 100 clienti, la cucina non prepara un piatto alla volta, ma ha più cuochi (thread) che lavorano in parallelo. È esattamente quello che fa un server Web con Apache o Nginx.
4. Tipi di comunicazione tra client e server
All’interno del modello client-server, la comunicazione può avvenire secondo modalità differenti:
- Unicast: il server comunica con un singolo client alla volta. La richiesta viene accettata solo se il server non sta già servendo altri client.
- Connessioni concorrenti: per servire più client simultaneamente, il server può creare un thread dedicato per ogni richiesta. In questo modo, le connessioni parallele non interferiscono tra loro, e il server rimane disponibile per nuovi client.
Nota: il termine “multicast” viene talvolta usato impropriamente in testi didattici. In realtà, HTTP standard non utilizza multicast; la gestione di più client avviene attraverso connessioni parallele e multithreading. Se all'esame vi chiedono di multicast in HTTP, rispondete che è un errore: HTTP è unicast con gestione concorrente.
Esempio pratico
Un browser che richiede una pagina Web al server HTTP. Il server rimane in ascolto sulla porta 80 e, per ogni nuova richiesta, crea un thread o una connessione dedicata per servire l’utente. Così può servire più utenti contemporaneamente.
Un server come quello di Instagram gestisce 100.000 richieste al secondo. Non lo fa con un singolo processo, ma con migliaia di thread e decine di server dietro un load balancer. Quando voi fate swipe, il vostro client manda una richiesta, il load balancer la smista al server meno carico, quel server crea un thread, prende la foto dal database e ve la restituisce. Tutto in 80 millisecondi.
5. Tecnologie delle applicazioni Web
Le Web Application si basano su tecnologie che possono essere eseguite sia lato client sia lato server.
Tecnologie client-side
Le tecnologie client-side vengono eseguite direttamente nel browser dell’utente. Gestiscono principalmente l’interfaccia e l’interazione con l’utente.
Il flusso tipico di una richiesta client-side è:
- Il client invia una richiesta HTTP al server
- Il server restituisce una risposta contenente i dati richiesti
- Il browser interpreta e visualizza i contenuti
Esempi di tecnologie client-side includono HTML, CSS e JavaScript. Il codice sorgente è visibile all’utente e viene eseguito localmente, consentendo un’interazione immediata senza ulteriori elaborazioni server.
Fate click destro -> Ispeziona su questa pagina. Quello che vedete è tutto client-side: HTML, CSS, JavaScript. Potete copiarlo tutto. È per questo che non si mettono mai password o chiavi segrete nel JavaScript lato client: chiunque le vedrebbe. La sicurezza vera sta sempre lato server.
Tecnologie server-side
Le tecnologie server-side eseguono l’elaborazione sul server remoto. Il client riceve soltanto il risultato finale e non ha accesso al codice sorgente.
Questo approccio è utilizzato per:
- Accesso e gestione di database
- Elaborazioni complesse
- Autenticazione e gestione della sicurezza
Esempi di linguaggi server-side comuni sono PHP, Java, Python e ASP.NET. Le elaborazioni server-side consentono di centralizzare logiche complesse, ridurre il carico sui client e proteggere dati sensibili.
| Caratteristica | Client-Side | Server-Side |
|---|---|---|
| Dove gira | Nel browser | Nel server |
| Codice visibile? | Sì, ispezionabile | No, solo risultato |
| Linguaggi | HTML, CSS, JS | PHP, Java, Python, C# |
| A cosa serve | Interfaccia, animazioni | DB, login, sicurezza |
| Prestazioni | Dipende dal device | Dipende dal server |
6. Architettura a livelli (Tier e Layer)
Le applicazioni Web moderne sono organizzate secondo un’architettura a livelli (tier) e strati (layer). Questa separazione consente di assegnare compiti specifici a ciascun livello, migliorando scalabilità, sicurezza e manutenibilità.
Concetti fondamentali:
- 1 Tier: tutto sullo stesso livello (es. app desktop con DB locale) - ormai obsoleto per il Web
- 2 Tier: client e server DB diretto - semplice ma poco scalabile
Immaginate di avere tutto il codice in un unico file: HTML, logica di calcolo dello sconto, query al database. Se domani cambiate database da MySQL a PostgreSQL dovete riscrivere tutto. Se invece avete 3 livelli separati, cambiate solo il Data Tier. È come avere in cucina antipasti, primi e dolci preparati da 3 chef diversi: se uno è assente, gli altri continuano a lavorare.
7. Modello Three-Tier e N-Tier
Modello Three-Tier
Il modello three-tier distingue tre livelli principali:
- Presentation Tier (Front-End): interfaccia utente, gestione dell’input e visualizzazione dei dati (es. pagine HTML, moduli, interfaccia grafica)
- Business Logic Tier (Middle Tier): logica applicativa e algoritmi di elaborazione dei dati (es. calcoli, gestione di transazioni, processi aziendali)
- Data Tier (Back-End): gestione dei dati persistenti e accesso al database (Data Access Layer, DAL)
Architetture N-Tier
Le architetture N-Tier generalizzano il modello three-tier, aggiungendo livelli intermedi per:
- Migliorare la modularità
- Suddividere compiti complessi
- Scalabilità superiore, utile per applicazioni distribuite o enterprise
Il multi-tier è ampiamente utilizzato nei sistemi distribuiti che devono gestire grandi quantità di utenti e dati, garantendo resilienza e flessibilità, pur aumentando la complessità complessiva.
Se vi chiedono: "Perché oggi si usa N-Tier e non 2-Tier?" Rispondete: perché con N-Tier posso scalare ogni livello in modo indipendente. Se ho 1 milione di utenti che guardano le pagine ma pochi che scrivono sul DB, metto 10 server per il Presentation Tier e 2 per il Data Tier. Con 2-Tier dovrei duplicare tutto, anche il DB, sprecando soldi. È una risposta da 10 e lode.
8. Il livello applicazione e i protocolli di rete
Nel modello ISO/OSI e nel modello TCP/IP, il livello applicazione fornisce i protocolli che permettono alle applicazioni di comunicare in rete senza preoccuparsi dei dettagli dei livelli inferiori.
Tra i protocolli più utilizzati:
- HTTP: per la navigazione Web
- FTP: per il trasferimento di file
- SMTP / POP3: per l’invio e ricezione di email
- DNS: per la risoluzione dei nomi di dominio
Questi protocolli permettono lo sviluppo di applicazioni di rete comuni come posta elettronica, chat, videoconferenze e streaming audio/video.
9. Socket e comunicazione tra processi
Per consentire la comunicazione tra processi su host differenti, ogni servizio è identificato da:
- Indirizzo IP: identifica l’host
- Numero di porta: identifica il servizio specifico
La coppia IP:porta prende il nome di socket, che rappresenta il punto di accesso al servizio. Grazie a questa identificazione, un server può offrire più servizi contemporaneamente, ciascuno su una porta diversa, e il client sa esattamente come raggiungere il servizio desiderato.
L'indirizzo IP è l'indirizzo dell'hotel (Via Roma 10), la porta è il numero della camera (Camera 80, Camera 443). Se volete andare nella camera 80 (sito web), il portiere vi manda lì. Se volete la 22 (SSH), vi manda in un'altra camera. Stesso hotel, camere diverse. Senza porte, il server non saprebbe quale servizio volete.
10. Architetture di rete
Client-Server
Nel modello client-server, il server rappresenta il punto centrale del sistema:
- Deve rimanere attivo e in ascolto per offrire servizi ai client
- Possiede generalmente un indirizzo IP statico, mentre i client possono avere IP dinamici
Per gestire grandi volumi di traffico si ricorre a server farm e tecniche di bilanciamento del carico.
Peer-to-Peer (P2P)
Nel modello P2P, gli host comunicano direttamente tra loro, senza un server centrale. Ogni nodo può fungere da client e server, favorendo la decentralizzazione e una distribuzione più equilibrata delle risorse.
Tipi di architetture P2P:
- Decentralizzato: tutti i nodi sono equivalenti e collaborano senza un server centrale
- Centralizzato: un server tiene traccia delle risorse disponibili e facilita la connessione tra peer (es. Napster)
- Ibrido: combina decentralizzazione e server di indicizzazione per bilanciare controllo e scalabilità
Architetture ibride
Le architetture ibride combinano i vantaggi di client-server e P2P, fornendo sistemi flessibili, scalabili e affidabili. Spesso sono utilizzate per applicazioni complesse che richiedono sia un punto centrale di controllo sia una distribuzione efficiente del carico.
| Modello | Pro | Contro | Esempi |
|---|---|---|---|
| Client-Server | Controllo centrale, sicurezza | Single point of failure | Gmail, Facebook, YouTube |
| P2P Puro | Decentralizzato, resistente | Difficile da gestire | BitTorrent, Blockchain |
| Ibrido | Scalabile, flessibile | Complesso | Skype, Spotify (inizio) |
11. Servizi dello strato di trasporto
Lo strato di trasporto fornisce servizi essenziali alle applicazioni, come:
- Affidabilità: garantisce che i dati arrivino correttamente
- Controllo del flusso: gestisce il ritmo di trasmissione tra mittente e destinatario
- Gestione della congestione: evita sovraccarichi della rete
- Sicurezza: cifratura e integrità dei dati
I protocolli principali sono:
- TCP (Transmission Control Protocol): orientato alla connessione, garantisce trasferimento affidabile e controllo di congestione. Ideale per posta elettronica, FTP e altre applicazioni che non tollerano perdite di dati.
- UDP (User Datagram Protocol): senza connessione e non affidabile, più veloce e leggero, adatto per streaming multimediale o giochi online.
- RTP (Real-Time Protocol): utilizzato per applicazioni in tempo reale, come VoIP e videoconferenze, combinando velocità e controllo dei ritardi di rete.
TCP è come una raccomandata: arriva sicuro, con ricevuta di ritorno, ma ci mette di più. UDP è come una cartolina: la lanci e speri arrivi, velocissima ma senza garanzie. Per un bonifico bancario usi TCP (non puoi perdere un euro), per una chiamata su Discord usi UDP (se perdi 10ms di audio non muore nessuno, ma se aspetti la ritrasmissione la chiamata lagga).
12. Conclusioni
La progettazione di un’applicazione Web o di rete richiede una scelta accurata dell’architettura, dei linguaggi e dei protocolli più adatti alle esigenze funzionali e prestazionali. Comprendere il modello client-server, le architetture a livelli e i servizi di rete è fondamentale per sviluppare applicazioni moderne, scalabili, sicure e affidabili.
📚 Compito per casa - Osserva il mondo intorno a te
Apri Chrome -> Tasto destro -> Ispeziona -> Scheda Network e ricarica questa pagina. Vedrai decine di richieste client-server in tempo reale: HTML, CSS, immagini. Ogni riga è una richiesta HTTP con il suo socket. Conta quante sono. Nella prossima lezione vedremo come queste richieste viaggiano dentro il protocollo HTTP.