Come funziona un sito web

Pubblicato il 12/06/2020

Soggetti

 

Il modello a cui facciamo riferimento è quello Client - Server, dove il Server è il fornitore di servizi, il Client è colui che usufruisce delle informazioni.

Un server è sostanzialmente un computer che fornisce servizi, che spaziano dal Dimmi che ore sono a Stampami questo documento, dal Dammi questo file a Fammi leggere le mail sulla mia casella. In particolare analizzeremo i servizi Web e DNS.

Il client è anch’esso un computer, il quale ha necessità di reperire alcune informazioni in possesso del server.

Il ciclo base di scambio informazioni nasce dal Client che ha una necessità, invia quindi una Richiesta al Server, il quale la valuta, elabora quindi dei dati e ritorna una Risposta.

 

Web

 

Nel mondo del web lo strumento principale con cui un client usufruisce del servizio è il Browser. Dall’altra parte il server addetto alla gestione delle richieste web è detto Web Server.

I browser sono programmi installati nel computer e ne esistono vari e disparati: i più conosciuti al giorno d’oggi sono Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, Microsoft Internet Explorer e Apple Safari.

Anche se ne esistono di tutti i tipi, generalmente hanno tutti una struttura simile costituita da due elementi principali:

• una barra degli indirizzi
• un contenitore dove mostrare la risposta

La barra degli indirizzi contiene la posizione della risorsa a cui stiamo accedendo. Modificandone il valore possiamo istruire il browser a reperire per noi una nuova risorsa.

 

Indirizzo Web

 

Un indirizzo Web o URL è costituito da alcuni elementi principali:

• schema/protocollo
  • indica la tipologia di risorsa a cui vogliamo accedere. Un browser oltre a darci la possibilità di accedere al web, ci permette anche di accedere ad altri servizi e lo schema ci permette di capire a quale ci stiamo riferendo. http/https indicano un documento ipertestuale (costituito cioè da testo, immagini e altri media e collegamenti ad altri documenti), ftp indica il servizio FTP per il trasferimento file, etc. 
• hostname
  • è il nome identificativo del dispositivo in cui la risorsa è disponibile
• percorso
  • indica la posizione all’interno del dispositivo dove si trova la risorsa

Facendo un esempio reale si potrebbe considerare lo schema come la tipologia di risorsa a cui vogliamo accedere (banca, posta, fruttivendolo, negozio di scarpe), l’hostname come l’edificio e il percorso come l’armadio dove si trova il bene a cui vogliamo accedere.

 

Hostname e Domini

 

All’interno dell’hostname abbiamo una componente detta dominio, che è un nome registrato a una certa entità e di cui tale entità ha il controllo. Gli hostname si leggono da destra verso sinistra, in quanto rappresentano una gerarchia. Partendo da destra abbiamo quindi domini di primo livello (.com), secondo livello (.ueppy.com), terzo livello (.www.ueppy.com) e così via.

Sotto .com sono “registrati” molti domini, ognuno dei quali è controllato da un entità diversa. La procedura di registrazione si effettua presso un Registrar che è la figura predisposta alla gestione di un dominio di primo livello. Il Registrar, dopo aver stipulato un contratto con l’entità che vuole acquistare un dominio, registra un dominio nel registro di primo livello per cui è responsabile.

Esistono molti domini di primo livello o TLD (top-level domain), ognuno dei quali ha registro e regole separate. Agli albori del web c’era una più netta distinzione rispetto ad oggi relativamente ai domini iscritti ai diversi TLD: ad esempio .net era riservato alle entità che offrivano servizi di rete. Al giorno d’oggi, ad esclusione di alcuni (es: .edu), è più facile venire accettati dai registrar per un TLD anche non inizialmente nato con quello scopo: abbiamo quindi TLD generici (.net, .com), TLD nazionali (.it, .de, .fr) e TLD patrocinati (.edu, .mil, .gov).

Ad esempio:

• .com è generalmente un’entità commerciale
• .edu è un entità che offre servizi legati all’istruzione americana
• i TLD nazionali (.it/.de/.fr) richiedono generalmente che l’intestatario risieda in tale nazione

Una volta registrato un dominio, si ha il controllo su tutti i sottodomini collegati. Per differenziare i servizi forniti dalla stessa entità, nel corso del tempo sono nati alcuni sottodomini “standard” che un utente si aspetta di trovare. Sono tutti sottodomini convenzionali, ma nulla vieta di adibirli ad altri scopi. - www è spesso usato per il sito web - mail per il server email e così via.

 

DNS e IP

 

Un hostname è quindi un nome comune che identifica una risorsa. Ma non basta ad un client per identificare la posizione fisica del server, per questo serve un indirizzo IP, che quindi funziona da coordinate per individuare come raggiungere il computer destinatario.

Il processo di trasformazione da hostname a indirizzo IP è detto risoluzione ed è gestito da un altro servizio, denominato DNS (Sistema di gestione dei domini). Anche per questo servizio abbiamo quindi un Client e un Server (denominato Server DNS) e la richiesta è quindi “Mi puoi dare l’IP di questo hostname?”. Il server DNS ha un elenco al suo interno degli IP collegati ai vari hostname e può quindi rispondere alla richiesta indicando le coordinate del server. In realtà il server DNS può rispondere soltanto alle richieste per cui è stato definito autoritativo del dominio, se non lo è si occupa anche di chiedere a un suo superiore di inoltrare la richiesta al server autoritativo e ritorna la risposta al client.

Tornando quindi al ciclo base di una richiesta web, facciamo l’esempio che vogliamo visitare la pagina “https://www.ueppy.com/servizi/” :

• il browser legge https e capisce che vogliamo accedere a una risorsa web in maniera sicura
• legge www.ueppy.com e però non sa quale sia l’indirizzo IP di www.ueppy.com, quindi chiede al server DNS “Dove sta www.ueppy.com?”
• il server DNS risponde “www.ueppy.com sta su 46.28.2.13”
• il browser invia a 46.28.2.13 la richiesta “Vorrei accedere a https://www.ueppy.com/servizi/”
• il server web 46.28.2.13 riceve la richiesta ed elabora una risposta che ritorna al browser
• il browser riceve la risposta e la mostra all’utente

 

Risposta

 

La risposta web è caratterizzata da una moltitudine di informazioni, divise in due sezioni principali:

• Header
  • Contiene informazioni aggiuntive, tra cui:
    • data e ora della risposta
    • lingua della risposta
    • codice di stato
• Body
  • Il contenuto vero e proprio della risposta, composto da:
    • parte testuale e di struttura (HTML)
    • parte stilistica (CSS)
    • parte di interazione (JS)
    • risorse (immagini, audio, video)

Il codice di stato all’interno dell’header riporta se la richiesta è andata a buon fine, se c’è stato un errore, se si può riprovare o se il servizio non è disponibile.

In generale un codice di stato HTTP è un numero di 3 cifre, di cui la prima rappresenta la categoria:

• 2xx
  • Tutto a posto
• 3xx
  • La risorsa richiesta non è più qui, prova da quest’altra parte
• 4xx
  • C’è un problema con la tua richiesta
• 5xx
  • C’è un problema lato server

I codici di stato sono standard e i browser sanno riconoscere cosa fare in ogni situazione. Esiste addirittura un codice di stato 418 il cui significato è Sono una teiera, che indica che il server si rifiuta di servire caffè perchè in realtà è una teiera!

Nasce come pesce di aprile nel 1998, non è mai entrato ufficialmente negli standard, ma molti browser lo hanno comunque implementato (https://httpstat.us/418) .

 

Cookie e gestione dello stato

 

Ogni ciclo di richiesta e risposta vive quindi a se, ma in alcuni casi è necessario sapere cosa è stato richiesto in precedenza per avere una risposta diversa. Si pensi ad esempio quando ci si collega a un sito con username e password, come fa il server successivamente a sapere che sono io? Una prima soluzione è quella di inoltrare username e password ad ogni richiesta, ma questo è attuabile solo in alcune situazioni. Per mantenere informazioni nasce quindi lo strumento dei cookie che sono essenzialmente delle etichette applicate alla richiesta che permettono di aggiungere informazioni di stato alla stessa.

Il server, quindi, ricevendo dei cookie può leggerli e decidere come rispondere in base ad essi.

I cookie quindi nascono come ragione tecnica per mantenere uno stato nel corso del ciclo richiesta-risposta.

I cookie d’altra parte però possono permettere anche di tracciare cosa ha visitato un utente, quali sono i suoi interessi e di comunicare tali informazioni a terzi. Per questo motivo nel 2011 l’EU ha emanato una direttiva a tutela della privacy dell’utente che obbliga chi usa cookie a informare l’utente relativamente agli scopi e le modalità di raccolta e quali sono le entità terze con cui condivide tali informazioni.

 

Questo articolo contiene grosse semplificazioni per rendere più fruibile il contenuto ai non addetti del settore. La sostanza è inalterata, ma alcuni passaggi sono ignorati per semplicità.