Spiegazione di come si accede ai linguaggi di programmazione lato server

Comprendo che qualsiasi linguaggio di programmazione generico può essere utilizzato per lo sviluppo lato server di un sito Web.

Ho ragione nel pensare che un server abbia solo bisogno di una sorta di interfaccia come CGI per far funzionare insieme il server e il linguaggio di programmazione? Se è così, allora perché alcuni linguaggi di programmazione (come php) sono più popolari di altri?

All'inizio del web, CGI era davvero l'unico modo (pratico) per avere contenuti dinamici (si potevano fare pipe di file con nome - e quelli erano usati in passato prima di cgi, ma non era affatto pratico).

CGI funziona attaccando un mucchio di informazioni nell'ambiente del processo che viene biforcato e quindi eseguito (e forse un po 'nello stdin) e quindi prende ciò che esce dallo stdout e lo restituisce al richiedente.

A questo non importa un po 'qual è il linguaggio di implementazione. In effetti, ho scritto i miei primi CGI in passato in C o C ++. È stato un po 'doloroso. Più tardi ho imparato un po 'di perl nei primi anni '90 e questo è stato molto meno doloroso.

Questo funziona, fino a un certo punto. Il problema è in scala. Ogni richiesta CGI è un fork e un exec di un processo. Migliaia di richieste significano migliaia di processi. Non funziona davvero bene.

La soluzione a questo è rimuovere il fork e l'esecuzione spostandolo in un thread nel server Web stesso o inviando la richiesta a un altro processo che gestisce la richiesta senza necessità di fork e exec. mod_perl è uno di questi strumenti per farlo (un plugin che sposta perl in apache). Php (fine anni '90) lo ha fatto anche implementando la lingua come plug-in nel web server stesso piuttosto che qualcosa che è stato biforcato e superato. Questo è diventato piuttosto popolare in quanto era simile al perl (che era il primo linguaggio di programmazione web dominante) e poteva superare le prestazioni del pergigi. C'è ancora un po 'di slancio da questo periodo di tempo a metà degli anni '90, prima che i server delle applicazioni più di livello enterprise iniziassero a prendere piede con linguaggi più formalizzati dietro di loro. Se scavi in ​​giro,

Questo ci porta ai server delle applicazioni in cui vengono generati thread interni (o altri approcci - questo non è il caso di tutto) per gestire le richieste piuttosto che interi nuovi processi - che possono aiutare con la scala. Come processo esterno, questo potrebbe essere visto con FastCGI e in seguito divenne prevalente con altri server applicazioni. Si noti che con questo la linea tra il server delle applicazioni e il server Web è diventata un po 'sfocata: molti server delle applicazioni potrebbero raddoppiare come server Web, anche se non sono stati ottimizzati per gestire l'IO dei file statici come i server Web tradizionali.

Il server di applicazioni generico ha anche spianato la strada a soluzioni in cui invece di un server di applicazioni generico , l'applicazione stessa esegue un server Web incorporato o è l'intera distribuzione. In tali situazioni, non si distribuisce un'applicazione Web su un server delle applicazioni, ma si esegue e gestisce le richieste. Ancora una volta, l'obiettivo di questo modello è quello di evitare il prezzo pesante del lancio di nuove istanze dell'applicazione e di gestire invece le richieste all'interno dell'applicazione con thread di peso molto più leggero o approcci simili.

Ecco la cosa però: tutte le soluzioni sono carenti in qualche modo, forma o forma. CGI, sebbene facile abbia seri problemi di scala. I plug-in nei server Web vengono associati al server Web stesso (apache vs nginx vs IIS vs ...) e perdono la funzionalità comune della lingua. Microsoft ha la sua parata di tecnologie che vorrebbe promuovere. E se conosci una lingua, non preferiresti continuare a programmare in essa piuttosto che avere lingue diverse in diverse parti dello stack (javascript nel client e Node.js)?

E così, hai oggi. Alcune persone lavorano in uno stack Java (con scala e clojure che non sono insoliti). Altri in uno stack C #. Altri in uno stack JavaScript. Ci sono un sacco di pile php là fuori. Un sacco di pitone. Puoi ancora trovare alcune pile di perl là fuori (e se guardi alcuni siti a basso volume, troverai comunque CGI). Con il cloud computing, Google ha anche promosso Go come linguaggio web lato server praticabile.

Ognuno ha i suoi vantaggi, svantaggi, i suoi framework e i suoi server. La relativa popolarità di questi flussi e riflussi mentre le tecnologie che li circondano cambiano. Fanno bene cose diverse.

Sì, qualsiasi linguaggio di programmazione generale può servire per scrivere la parte lato server di un sito web.

Tuttavia, le qualità di un linguaggio di programmazione, in questa materia come in altre cose, sono di solito solo uno dei molti fattori che contribuiscono alla sua popolarità.

Ad esempio, ritengo che PHP sia diventato popolare per i siti Web perché:

• È estremamente facile eseguire l'aggiornamento da un sito Web statico a un sito Web dinamico PHP: basta sostituire l'estensione del file HTML, posizionare il <?phptag all'inizio e, a condizione che PHP sia installato, si dispone di un sito Web dinamico! Il resto del flusso di lavoro è esattamente lo stesso di un sito Web statico;
• A causa di quella facilità di distribuzione, gli host web che stavano cercando di proporre siti Web dinamici hanno scelto PHP, rendendolo abbastanza rapidamente la piattaforma lato server più diffusa;
• È entrato in quel mercato al momento giusto;

E una volta che PHP è stato ampiamente distribuito, è diventato interessante scrivere applicazioni Web più serie in PHP al fine di beneficiare di tale ampiezza di distribuzione.

Per dirlo in un modo più generico: l'adozione della lingua spesso riguarda le risposte a queste domande:

• Quanto è facile fare quello che voglio fare?
• Quanto è ampiamente supportata la lingua per ciò che voglio fare?

Ho ragione nel pensare che un server abbia solo bisogno di una sorta di interfaccia come CGI per far funzionare insieme il server e il linguaggio di programmazione?

Quasi. È necessario un server Web che disponga di un tipo di software che gli consenta di rispondere anche alle richieste HTTP.

Pensa a come viene servita una pagina statica. Il server recupera la richiesta HTTP, trova il documento richiesto dal filesystem in base alla configurazione del server HTTP e restituisce la pagina statica.

CGI estende questo concetto consentendo di designare una cartella cgi-bin sul filesystem in cui è possibile archiviare eseguibili o script. Quando si accede a un programma tramite CGI, il server HTTP esegue il processo o lo script e restituisce l'output standard al client anziché semplicemente servire il documento statico.

 If so then why are some programming languages (such as php) more popular than others?

La vecchia struttura CGI non si adatta bene a un grande volume di richieste. Diversi linguaggi di programmazione e framework per il web esistono per diversi motivi e ognuno fa bene cose diverse. PHP è popolare quanto lo è per ragioni storiche, in quanto è stata una delle prime soluzioni facili ed economiche per servire pagine dinamiche senza ricorrere a CGI e aveva un ampio supporto di hosting. ASP era popolare tra le cerchie Microsoft perché consentiva agli sviluppatori VB di spostare le proprie competenze sul Web. ASP.NET (Web Forms) ha reso molto semplice per gli sviluppatori di Windows Form, molti dei quali erano programmatori VB, passare al Web.

Quando un browser effettua una richiesta HTTP, si presenta così:

GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close

... a cui il server dovrebbe inviare una risposta simile alla seguente:

HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>

Qualsiasi codice in esecuzione sul server che ascolta le richieste su un socket TCP, legge la richiesta e risponde con la risposta appropriata sarà sufficiente. Un modo stupido è solo quello di sputare una risposta predefinita a chiunque si connetta alla porta TCP 80, usando uno script shell:

$ nc -l 8000 <<'RESPONSE'
HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>
RESPONSE

Naturalmente, questa tecnica sembra a malapena conforme al protocollo HTTP .

Un passo avanti rispetto a questa risposta predefinita è questo semplice programma Python, che utilizza la http.serverlibreria in Python 3.

#!/usr/bin/python3

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        payload = '<!DOCTYPE html>... insert cats here ...'.encode('UTF-8')
        self.send_response(200)
        self.send_header('Content-Type', 'text/html; charset=UTF-8')
        self.send_header('Content-Length', len(payload))
        self.end_headers()
        self.wfile.write(payload)

http.server.HTTPServer(('', 80), Handler).serve_forever()

Il server HTTP può essere scritto in qualsiasi lingua; questo è solo un esempio. Ovviamente, questo esempio è molto rudimentale. Il payload è hardcoded - il programma ignora completamente il contenuto della richiesta - l'URL, la stringa di query, l'intestazione Accept-Language, ecc. È possibile aggiungere codice per generare risposte significative in base alla richiesta, ma il codice otterrebbe molto complesso. Inoltre, i programmatori preferiscono concentrarsi sulla scrittura dell'applicazione Web, senza doversi preoccupare dei dettagli su come gestire una richiesta HTTP.

Una soluzione più appropriata sarebbe quella di utilizzare un server Web, come Apache HTTPD , IIS o nginx . Un server Web è solo un programma in ascolto sui socket TCP pertinenti, accetta più richieste (possibilmente contemporaneamente) e decide come generare una risposta in base all'URL della richiesta, alle intestazioni e ad altre regole. Idealmente, molti dettagli, come SSL, controllo degli accessi e limiti delle risorse, vengono gestiti tramite la configurazione anziché tramite il codice. La maggior parte delle volte, il server Web formulerà una risposta che consiste solo nel contenuto dei file nel filesystem.

Per i contenuti dinamici, tuttavia, il server Web può essere configurato per eseguire del codice per generare la risposta. Un meccanismo per farlo è con CGI: il server imposta alcune variabili di ambiente in base alla richiesta, esegue un programma e copia il suo output nel socket TCP. Una soluzione leggermente più sofisticata sarebbe quella di avere un modulo che aggiunga supporto al web server per chiamare il codice in un altro linguaggio di programmazione (es. Mod_php per Apache ). Un'altra opzione è scrivere il server Web nella stessa lingua dell'applicazione Web, nel qual caso l'invio della richiesta è solo una chiamata di funzione. Questo è il caso di node.js e dei motori servlet Java come Apache Tomcat .

La scelta della tecnologia dipende davvero da te e dipende dal linguaggio di programmazione che preferisci utilizzare, dall'ambiente di hosting a tua disposizione, dai requisiti di prestazione, dall'opinione popolare e dalle mode di passaggio. Il CGI, ad esempio, non è stato favorito di recente, poiché la necessità di avviare programmi esterni limita la scalabilità.

Un web server è un programma scritto in qualsiasi linguaggio di programmazione che gestisce il "traffico web" su socket aderendo a standard / protocolli a livello di applicazione (HTTP, ecc.). La maggior parte dei linguaggi di programmazione ti offre di creare un socket.

Ho ragione nel pensare che un server abbia solo bisogno di una sorta di interfaccia come CGI per far funzionare insieme il server e il linguaggio di programmazione?

Non è necessario disporre di un programma server dedicato e del programma applicativo: possono essere uguali (indipendentemente da eventuali problemi relativi alle prestazioni).

Puoi usare una libreria di server HTTP , ad esempio libonion , anche nel tuo programma codificato in C (o C ++, vedi anche Wt ). C'è anche una libreria client HTTP (ad esempio libcurl )

È possibile utilizzare altre librerie HTTP, ad esempio ocsigen e ocamlnet per OCaml .

Esistono diversi linguaggi dedicati al Web (al di fuori di PHP), ad esempio Opa , HOP , Kaya , ecc ... (sia HOP che Opa possono facilmente combinare calcoli sul lato server e sul lato browser, ma devi farlo dolorosamente e manualmente in PHP, usando esplicitamente le tecniche AJAX e codificando manualmente alcuni Javascript per il browser. Al contrario, HOP, Opa, Ocsigen sono in grado di generare quel Javascript).

Puoi anche usare la tecnologia FASTCGI per aggiungere un servizio dinamico ad alcuni server web ... FASTCGI è meglio del semplice vecchio CGI che avvia un nuovo processo per ogni richiesta HTTP in arrivo, mentre un'applicazione FASTCGI può servire molte richieste HTTP nello stesso processo. A proposito, PHP può essere configurato per funzionare come un'applicazione FASTCGI.

C.Queinnec ha osservato che la navigazione web e le continuazioni sono significativamente correlate.

PS. Non mi piace il PHP e credo che la sua popolarità abbia ragioni storiche e sociali (non principalmente tecniche). In effetti il ​​PHP era molto diffuso molto prima che AJAX diventasse ampiamente usato ed è più vecchio di HOP o Opa (o Ocsigen).