Architettura Client/Server

Questo articolo è piuttosto banale, ma vale la pena tenere traccia di pochi e semplici concetti che gli alunni tendono a sottovalutare senza capire in realtà come funziona il mondo di internet dal punto di vista logico al di là della mera paginetta web che sfrutta tale architettura.

 Abbiamo già trattato in altro articolo alcuni dettagli delle pagine HTML che potete leggere qui. Ora vogliamo semplicemente dare qualche riferimento che potete ampiamente trovare sia sui libri di testo che su svariate pagine web e che vogliamo sintetizzare e semplificare.

L’architettura client/server è piuttosto semplice come  idea base. Un pc o dispositivo funge da client, cliente in italiano, ovvero che richiede un certo servizio o risorsa, che sia un file particolare o una pagina web.  In generale, il client da browser chiede attraverso un URI/URL, Uniform Resource Identifier e Locator. La richiesta arriva ad un altro dispositivo che siamo soliti identificare con server, che fornisce, serve a tale richiesta con una risposta. Se siamo di fronte ad una pagina web richiesta, il server fornisce un file di testo contenente codice html, css, javascript e tutti gli elementi multimediali di tale pagina che verranno inviati indietro al browser che ne ha fatto richiesta. Il browser leggera il file di testo, che altro non è che il codice html e prova a fare il rendering di tale codice con tutti i contenuti grafici e multimediali aggiuntivi. Da questo momento il ruolo del server si conclude a meno di ricevere ulteriori richieste sempre nella medesima modalità. Il client che scarica la pagina web può usare e visualizzare tale pagina. Se è presenta codice javascript, l’utente può interagire con tale codice che viene eseguito sul browser, senza dover affidarsi al server (eccezion fatta di richieste AJAX, ma richiede altro articolo per la trattazione).   

 Un caso interessante, oltre al JS, sono le form. Le form, trattate anche queste dal punto di vista pratico in queste pagine, sono delle semplici interfacce di immissione dati che consentono all’utente di interagire con le pagine web. Come qualsiasi scipt HTML, le form sono contenute nei file di testo delle pagine web e si comportano analogamente: possono avere uno stile grafico impostato col CSS e possono avere dei frammenti di codice JS che ne alterano il comportamento sempre sul browser del client. Nel momento in cui si fa invio/submit, le form vanno ad interagire col server e gli inviano i dati in due modalità possibili: POST o GET. Il primo manda i dati in modo criptato, il secondo in chiaro. Li inviano allo script dichiarato nella action della form. Solitamente questo è uno script PHP, una pagina con codice decisamente più intelligente della pagina HTML e che è capace di interagire, elaborare ed immagazzinare i dati che provengono dalla form. Attività analoga di trattamento dei dati può essere fatta anche col JavaScript che gira sul browser, che può leggere i campi della form e i loro valori ma che poi non può registrare tali dati da nessuna parte “in locale”, quindi diventa utile per interagire con l’utente, correggere errori di immissione e prevenire errori in generale nella compilazione ed immissione dei dati nella form. Puoi approfondire leggendo il funzionamento del protocollo HTTP.

La logica client/server in realtà può essere intesa anche a livello microscopico e macroscopico. Mi spiego meglio. All’interno di un rete, prima che il pc client arrivi al server della pagina web, possono sicuramente esserci altri dispositivi che interagiscono con i due punti estremi. In realtà, ogni nodo funge un po’ da client e server nel loro piccolo, fornendo un piccolo elemento di informazione e di servizio per completare la richiesta totale. Ad esempio i dns, che forniscono la traduzione ip/url, ma gli stessi router che trasportano i pacchetti collaborano tra di loro diventando client e server a loro volta in ogni singolo step. Anche sullo stesso pc client, molti dei software che ci girano sopra, porzioni del sistema operativo o altro, si comportano come client e server cambiando ruolo a seconda della necessità richiesta e collaborando con altri elementi, nodi.

 

Il concetto di multi-tier

In generale l’architettura client/server prevede due nodi che vengono indicati come 2-tier, due unità che collaborano. Può capitare che il server che restituisce la pagina web collabori con un sistema database che archivia in modo separato i dati richiedibili dal server web stesso. In questo caso siamo di fronte ad una architettura 3-tier. Va da se, se ci sono più elementi che collaborino, come accennato, ci troviamo di fronte ad una vera e propria architettura multi-tier. Alcuni manuali la indicano anche con ovvero tiern-tier, a n livelli.

Ultima modifica 12 Novembre 2023