Aiuta a comprendere lo scripting lato server

La tua comprensione è corretta, se vieni dal passato. Sei praticamente descritto come sembrava negli anni '90.

Sì, molte lingue possono essere eseguite direttamente da un plug-in del server web. Giusto per PHP, mod_php per Apache è ancora il modo più popolare per ospitarla. Tuttavia, i siti ad alto traffico utilizzano un approccio più moderno, utilizzando il web server solo come proxy per FastCGI (in caso di PHP è PHP-FPM )

the output is embed into HTML pages is then sent back to the client.

Penso che ti stia riferendo ai cosiddetti spaghetti code degli anni '90, tuttavia l'approccio moderno è quello di utilizzare uno dei tanti framework MVC. Nel caso di PHP che significherebbe per esempio Zend Framework (ci sono numerose alternative).

Per quanto riguarda l'ASP, ti stai probabilmente riferendo al cosiddetto "ASP classico", che è obsoleto. Attualmente è ASP.NET, che può utilizzare qualsiasi linguaggio .NET (il C # è il più popolare) e, naturalmente, il framework .NET.

C e C ++ non sono in genere utilizzati per l'applicazione web. In tal caso, tali servizi vengono implementati come server standalone, come modulo per server Web o come FastCGI .

Perl può essere eseguito direttamente dal modulo web service usando mod_perl . C'è anche PSGI , che è fondamentalmente clone di WSGI .

Python è un linguaggio molto diffuso per le app Web. Può essere eseguito direttamente dal server web Apache tramite mod_python, tuttavia è obsoleto e non consigliato. Attualmente la via da percorrere con Python è tramite il modulo server WSGI . WSGI server implementato in Python (ad esempio CherryPy, WebPy) o usando lo stack web Python standalone (il modulo Web di Tornado e Twisted è ottimi esempi). E ovviamente, molto probabilmente userete WSGI framework MVC compatibile, Django è il più popolare (di nuovo, sono disponibili più alternative).

Ruby, ancora un linguaggio molto popolare per le applicazioni web. Meglio conosciuto per il framework web Ruby on Rails, che di nuovo è MVC. Puoi eseguire Ruby direttamente dal modulo server tramite mod_ruby o tramite FastCGI .

Servlet / JSP vengono eseguiti in server di applicazioni J2EE standalone, come JBoss o Tomcat. È più comunemente usato per aggiungere l'interfaccia web al sistema aziendale piuttosto che per creare app web indipendenti.

Il classico CGI (cioè il processo di generazione di uova su ogni richiesta) è diventato obsoleto molti anni fa. È stato sostituito da FastCGI (dove processo è di lunga durata, piuttosto che generato su ogni richiesta), moduli server, interfacce come WSGI e cloni e soluzioni stand-alone.

Anche il paradigma dell'elaborazione della richiesta si è evoluto, con CGI è stato elaborato per richiesta. Quindi era pool di processi (o pool di thread), ogni processo (thread) gestiva una richiesta alla volta. Tuttavia ora, l'approccio più moderno è che i server Web e i framework stand-alone utilizzino la programmazione basata sugli eventi.

Consentitemi di prefigurarlo affermando che questa è una visione estremamente generica e semplificata di ciò che accade.

Il software del server Web (come Apache o IIS) non interpreta alcun codice; non sa come. Tutto ciò che sa fare è prendere una richiesta, cercarla in qualche posizione sul filesystem e quindi inviare l'elemento richiesto al browser. Questo è tutto ciò che fa - ad un livello molto semplice. Questo è il motivo per cui quando installi Apache e aggiungi del file php al DocumentRoot , non ottieni il risultato PHP eseguito; solo il file.

Il primo passo per fare in modo che il server faccia qualcosa di diverso dai file di servizio è aggiungere codice che gli dica di fare qualcos'altro quando è richiesto un file specifico ; altrimenti tutto ciò che farà è provare a servire il file in base al suo tipo mime predefinito (che di solito è testo / semplice). Questo è il motivo per cui quando si dispone di un server configurato in modo errato e si richiede index.php , viene visualizzato il codice sorgente per il file anziché il risultato desiderato.

Quindi per ottenere un server web per "capire" PHP, devi dirgli cosa fare quando arriva una richiesta per un file con l'estensione .php . Questo è dove arriva mod_php . Questo modulo scarica la richiesta a un interprete PHP (come può essere configurato), che legge il file, esegue il codice, compila i risultati; e invia i risultati al server, che a sua volta consegna i risultati al client. Quindi configuri il webserver in modo che tutti i file con .php alla fine vengano gestiti da mod_php.

Questo flusso di lavoro di base viene applicato anche con altre lingue; l'unica differenza è ciò che il server "scarica" la richiesta.

Il caso per PHP è spiegato sopra, c'è similarmente mod_python e fastcgi , wsgi e altri protocolli stabiliti per le richieste di offload che un server web non è progettato per gestire.

Le implementazioni più comuni hanno un lungo processo in esecuzione che attende una richiesta su una porta specifica (o socket). Il server Web viene quindi configurato come proxy , in modo tale da trasmettere qualsiasi richiesta che corrisponda a un modello specifico a questo processo di lunga durata e quindi leggere i risultati.

Ecco come ruby on rails (rack), script python (con wsgi) funzionano.

Questo è anche il motivo per cui semplici server proxy come Nginx sono molto popolari. Fanno solo i compiti di base di un server web tradizionale - servono i file "statici" e sono molto bravi a scaricare le richieste ad altri server proxy per gestire cose come PHP, Python, ASP, et. al.

Quindi alla fine hai il server web, che si prende cura dei file statici, di tutto ciò che non ha bisogno di elaborazione.

Hai un altro processo, che sa come gestire il tuo codice (ad esempio, un processo che esegue l'interprete PHP o un server uWSGI). Questo si siede e attende richieste dal server web.

Infine, hai sistemi come Upstart e Supervisor che gestiscono questi processi per te.

Spero che questo chiarisca la questione.

C'è una quarta opzione, che è usata nel modo più "serio"; siti web come banche o altri servizi finanziari: l'approccio a più livelli che è un po 'come CGI, ad eccezione del processo CGI eseguito su un server diverso, il codice del server web è molto sottile (quanto basta per riformattare i dati in html) e chiama il' servizi di cgi tramite protocolli di rete come RPC o SOAP.

È ancora lo stesso approccio di base che utilizza un server web come gateway tra la richiesta http fatta dal browser client e un 'motore di codice' che ospita la logica di business. Nota che in questo caso il server web passerà la richiesta a un motore di scripting in una lingua (es. PHP o XSLT) che a sua volta chiama un altro servizio che fornisce dati grezzi, lo script web è usato esclusivamente per formattare i dati nell'html pagina che viene consegnata al browser.