Il ruolo del Web Server Panoramica sulle funzioni del server web, lo strumento che ha il compito di gestire le richieste HTTP: cos'è, cosa fa, a cosa serve.

Il ruolo del Web Server

Dopo gli articoli dedicati al protocollo HTTP e al ciclo HTTP request/response, pubblichiamo un approfondimento dedicato al protagonista principale dell'interazione tra client/browser e il world wide web: il server web (o server HTTP), ovvero l'applicazione applicazione software che ha il compito di ricevere e gestire le richieste HTTP.

In questo articolo ci riferiremo al server web adottando la definizione di Wikipedia, che lo descrive come il servizio o applicativo software in esecuzione su una macchina server fisica o virtuale: tuttavia, il termine viene spesso utilizzato anche per definire la macchina su cui tale applicativo è installato. Le due diverse accezioni del termine sono comunque in buona parte intercambiabili, in quanto sia l'applicazione che (per esteso) la macchina sono chiamate a svolgere le medesime funzioni principali.

Gli argomenti trattati in questo articolo fanno parte del corso di formazione per Web Administrator organizzato da Ryadel per privati e aziende: per maggiori informazioni, consulta questa pagina.

Concetti generali

Come detto in apertura, il web server è un servizio installato su una macchina fisica o virtuale (tipicamente una workstation con un sistema operativo di tipo Windows, Linux o altro) che si occupa di “ascoltare” una o più porte TCP (solitamente la 80 e/o la 443) e gestire le richieste (request) ad esse indirizzate, provenienti dai client/browser. La gestione di queste richieste prevede la negoziazione della chiamata (e del canale crittografato, in caso di HTTPS), lo “spacchettamento” della URL relativa alla request e l’utilizzo delle sue singole parti per svolgere le seguenti attività:

  • Verificare che il protocollo richiesto sia tra quelli gestiti/accettati.
  • Verificare che l’hostname richiesto sia tra quelli configurati come validi.
  • Verificare che la porta TCP utilizzata sia tra quelle configurate come valide.
  • Verificare che il percorso (path) punti a un file fisico avente una estensione valida o sia gestito tramite un handler, uno script CGI o un altro componente server-side opportunamente configurato per gestire quel tipo di request.
  • Gestire la richiesta (request) e trasmettere la risposta (response) al client.

IMPORTANTE: Il Web Server è tipicamente configurato per gestire solo alcune estensioni specifiche (solitamente definite tramite una white-list): tutte le altre vengono rifiutate e gestite tramite uno Status Code 404 - Not Found, anche se il relativo file è presente sul file system.

Pagine statiche e pagine dinamiche

La maggior parte dei siti web sono composti da una pluralità di pagine statiche e/o dinamiche. A dire il vero sarebbe più corretto parlare di risorse, in quanto oltre alle pagine web i siti trasmettono anche una pluralità di contenuti (immagini, file CSS, JavaScript, etc) che possono essere anch'essi statici o dinamici: tuttavia, per semplificare l'argomento, ci limiteremo a mettere a fuoco le pagine web, ovvero i contenuti HTML richiesti dal client/browser e ricevuti tramite il server web. Fatta questa premessa, cerchiamo di comprendere la differenza tra pagine statiche e pagine dinamiche:

  • Le pagine statiche sono quelle che il web server recupera e trasmette da file system: in altre parole, sono pagine immutabili e che risultano identiche tutte le volte che un utente le visualizza e per tutti gli utenti.
  • Le pagine dinamiche sono quelle generate di volta in volta a seconda di una serie di condizioni che cambiano: parametri GET, parametri POST, data e ora, etc, risultando quindi potenzialmente diverse ad ogni chiamata e per ogni utente.

Per inviare al client una pagina statica, il browser svolge le seguenti operazioni:

  • Recupera la pagina dal filesystem (sotto forma di file “contenuto”). Alcuni esempi: hello.html, image1.gif, etc.
  • Determina il content type dall’estensione del file
  • Legge e trasmette il contenuto del file (e relativo content type) al browser

Per inviare al client una pagina dinamica, il browser svolge le seguenti operazioni:

  • Recupera la pagina dal filesystem (sotto forma di file “eseguibile”). Alcuni esempi: index.php, default.asp, etc.
  • Esegue il file utilizzando il relativo framework server-side (PHP, ASP, ASP.NET, Python, etc), recuperando il risultato dell’esecuzione (incluso il content type)
  • Trasmette il risultato dell’esecuzione (e relativo content type) al browser

Web Server e Framework Server-Side

Come fa il web server a “sapere” quale è il framework server-side da utilizzare? Risposta: sempre tramite l’estensione. L’estensione del file "dinamico" determina qual è il framework da utilizzare, o per meglio dire l'applicativo (handler, parser, pre-processor, etc.) a cui trasmettere la HTTP Request e che si occuperà di "generare" la HTTP Response da trasmettere al client. Ovviamente il framework deve essere installato e opportunamente configurato sul web server: ad esempio, per poter “eseguire” pagine con estensione .php, sul server dovrà essere installato l’interprete di comandi PHP, altrimenti quelle pagine restituiranno con tutta probabilità un errore (Status Code 404 - Not Found) in quanto non è presente alcuna associazione per quel determinato content type.

IMPORTANTE: il client non ha alcuna notizia del framework server-side (e/o del relativo linguaggio di programmazione) utilizzato dal server per eseguire le pagine dinamiche, né ha alcuna necessità di saperlo, in quanto tutto ciò che lui riceve è il risultato di tale elaborazione. Questo significa che:

  • Il client non può sapere con certezza se il server web utilizza pagine PHP, ASP, ASP.NET, etc: può soltanto ipotizzare la tecnologia server-side utilizzata, basandosi su quelli che sono i comportamenti standard dei vari framework e/o le “tracce” che possono lasciare nei vari elementi che compongono la HTTP response. Ad esempio, se i link interni dell'applicazione web puntano a pagine con estensione .php, è ragionevole pensare che il sito sia stato realizzato in PHP.
  • Il client non necessita di avere nessun framework server-side installato sul poprio sistema, in quanto si limita a ricevere dal server web il risultato dell'elaborazione delle pagine dinamiche sotto forma di HTTP Response. In altre parole, non è lui a dover "eseguire" quelle pagine: il suo scopo è quello di richiedere al server web (request) il risultato di tale esecuzione, così da poterlo ricevere (response) e mostrare a schermo. Per approfondimenti su questa dinamica HTTP request/response consigliamo di leggere questo articolo.

Conclusione

Per il momento è tutto: ci auguriamo che questa panoramica, sia pure con le inevitabili semplificazioni del caso, possa essere utile a chi si sta avvicinando per la prima volta a questi concetti fondamentali del World Wide Web.

 

 

 

About Ryan

IT Project Manager, Web Interface Architect e Lead Developer di numerosi siti e servizi web ad alto traffico in Italia e in Europa. Dal 2010 si occupa anche della progettazione di App e giochi per dispositivi Android, iOS e Mobile Phone per conto di numerose società italiane. Microsoft MVP for Development Technologies dal 2018.

View all posts by Ryan

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.