Spiegazione di come si accede ai linguaggi di programmazione lato server

Nei primi giorni del web, CGI era davvero l'unico (pratico) metodo per avere contenuti dinamici (si potevano fare named pipe di file - e quelli erano usati in pochi giorni prima di cgi, ma non era pratico in tutto).

CGI funziona inserendo un mucchio di informazioni nell'ambiente del processo che è biforcato e poi eseguito (e possibilmente un po 'in stdin) e poi prende ciò che esce da stdout e sputa di nuovo al richiedente.

Questo non interessa un po 'di cosa sia il linguaggio di implementazione. In effetti, ho scritto i miei primi CGI di nuovo in quel giorno in C o C ++. E 'stato un po' doloroso. In seguito ho imparato alcuni perl nei primi anni '90 e questo è stato molto meno doloroso.

Funziona, fino a un certo punto. Il problema è la scala. Ogni richiesta CGI è un fork e un exec di un processo. Migliaia di richieste significano migliaia di processi. Quel veramente non funziona bene.

La soluzione a questo è di rimuovere il biforcarsi e l'esecuzione spostandolo in un thread nel server Web stesso o inviando la richiesta a un altro processo che gestisce la richiesta senza bisogno di fork e exec. mod_perl è uno di questi strumenti per farlo (un plugin che si muove in perl in apache). Php (fine anni '90) lo ha fatto anche implementando il linguaggio come plugin nel server web stesso piuttosto che qualcosa che è stato biforcato e superato. Questo è diventato piuttosto popolare in quanto perl-like (che era il primo linguaggio di programmazione web dominante) e poteva sovraperformare il perl cgis. C'è ancora un po 'di slancio da questo periodo di tempo a metà degli anni '90 - prima che i server applicativi di livello enterprise iniziassero a prendere piede con linguaggi più formalizzati dietro di loro. Se scorri in giro, puoi trovare molti tentativi falliti tra la fine degli anni '90 e gli inizi degli anni 2000 - linguaggi e framework che non si sono limitati.

Questo ci porta ai server delle applicazioni in cui vengono generati i thread interni (o altri approcci - questo non è il caso per tutto) per gestire le richieste piuttosto che interi nuovi processi - il che può essere d'aiuto con le dimensioni. Come processo esterno, questo potrebbe essere visto con FastCGI e successivamente è diventato prevalente con altri server di applicazioni. Si noti che con questo la linea tra application server e web server è diventata un po 'sfocata - molti server di applicazioni potrebbero raddoppiare come server Web, sebbene non fossero ottimizzati per la gestione di file I / O statici nel modo in cui i server web tradizionali sono.

Il server delle applicazioni generico ha aperto la strada a soluzioni in cui invece di un server di applicazioni generico , l'applicazione stessa esegue un server Web incorporato o rappresenta l'intera implementazione. In tali situazioni non si distribuisce un'applicazione Web su un server delle applicazioni, ma si sta eseguendo da sola e gestisce le richieste. Anche in questo caso, l'obiettivo di questo modello è evitare il pesante prezzo di lancio di nuove istanze dell'applicazione e gestire invece le richieste all'interno dell'applicazione con thread molto più leggeri o approcci simili.

Ecco la cosa però - tutte le soluzioni sono carenti in qualche modo, forma o forma. CGI, mentre facile ha seri problemi di scala. I plug-in dei 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 al suo interno piuttosto che avere lingue diverse in diverse parti dello stack (javascript nel client e Node.js)?

E così, oggi hai. Alcune persone lavorano in uno stack Java (con scala e clojure che diventano non comuni). Altri in una pila C #. Altri in uno stack JavaScript. C'è un bel po 'di stack di PHP là fuori. Un sacco di pitone. Puoi ancora trovare alcuni stack perl (e se guardi alcuni siti a basso volume, troverai comunque CGI). Con il cloud computing, Google ha anche promosso Go come linguaggio web server lato vitale.

Ognuno ha i suoi vantaggi, svantaggi, i suoi quadri e i suoi server. La relativa popolarità di questi flussi e riflussi mentre le tecnologie attorno a loro cambiano. Fanno cose diverse bene.

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 questo argomento come in altre cose, sono solitamente 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 di PHP: basta sostituire l'estensione del file HTML, inserire il tag <?php all'inizio e, se PHP è installato, si dispone di una dinamica sito web! Il resto del flusso di lavoro è esattamente lo stesso di un sito web statico;
• Grazie a questa facilità di implementazione, gli host Web che stavano cercando di proporre siti Web dinamici hanno scelto PHP, rendendo abbastanza rapidamente la piattaforma lato server più diffusa;
• È entrato nel mercato al momento giusto;

E una volta che PHP è stato ampiamente implementato, è diventato interessante scrivere in PHP applicazioni Web più serie per trarre vantaggio da questa vastità di implementazione.

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

• Quanto è facile fare ciò che voglio fare?
• Quanto è ampiamente supportato il linguaggio per ciò che voglio fare?

Am I right in thinking that a server just needs some kind of interface such as CGI to make the server and the programming language work together?

Quasi. È necessario un server Web con qualche tipo di software per consentirgli di rispondere anche alle richieste HTTP.

Pensa a come viene pubblicata una pagina statica. Il server recupera la richiesta HTTP, trova il documento richiesto dal file system 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 gli eseguibili o gli 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 piuttosto che semplicemente servendo 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 ampio volume di richieste. Esistono diversi linguaggi di programmazione e framework per il web per diversi motivi, e ciascuno fa cose diverse bene. PHP è popolare tanto quanto lo è per ragioni storiche, in quanto è stata una delle prime soluzioni facili ed economiche per servire pagine dinamiche senza ricorrere al CGI e aveva un supporto di hosting diffuso. ASP era popolare tra i circoli Microsoft perché consentiva agli sviluppatori di VB di trasferire le loro competenze sul web. ASP.NET (Web Forms) ha reso molto facile per gli sviluppatori di Windows Form, molti dei quali erano codificatori VB, passare al web.

Quando un browser effettua una richiesta HTTP, appare come segue:

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

... a cui il server dovrebbe inviare una risposta simile a questa:

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 le risposte con la risposta appropriata sono sufficienti. Un modo stupido è solo per sputare una risposta in scatola a chiunque si connetta alla porta TCP 80, usando uno script di 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 appare a malapena conforme al protocollo HTTP .

Un passo avanti rispetto a questa risposta predefinita è questo semplice programma Python, che usa il http.server 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 preferirebbero 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 che ascolta i socket TCP rilevanti, accetta richieste multiple (possibilmente contemporaneamente) e decide come generare una risposta basata sull'URL, le intestazioni e altre regole della richiesta. Idealmente, molti dei dettagli, come SSL, controllo degli accessi e limiti delle risorse vengono gestiti tramite la configurazione anziché il codice. Per la maggior parte del tempo, il server Web formulerà una risposta costituita solo dal contenuto dei file nel filesystem.

Per i contenuti dinamici, tuttavia, il server Web può essere configurato per eseguire codice per generare la risposta. Un meccanismo per farlo è con CGI: il server imposta alcune variabili d'ambiente in base alla richiesta, esegue un programma e ne copia l'output sul socket TCP. Una soluzione leggermente più sofisticata sarebbe quella di avere un modulo che aggiunge supporto al server Web per chiamare il codice in un altro linguaggio di programmazione (ad esempio 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. È il caso di node.js e di motori servlet Java come Apache Tomcat .

La scelta della tecnologia dipende solo da te, e dipende dal linguaggio di programmazione che preferisci utilizzare, dall'ambiente di hosting a tua disposizione, dai requisiti di rendimento, dall'opinione pubblica e dalle mode passeggere. CGI, ad esempio, non è stato favorito ultimamente, 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 (s) aderenti ai protocolli standard / application level (HTTP, ecc.). La maggior parte dei linguaggi di programmazione ti offre la possibilità di creare un socket.

Am I right in thinking that a server just needs some kind of interface such as CGI to make the server and the programming language work together?

Non è necessario avere un programma server dedicato e il tuo programma applicativo - possono essere uguali (ignorando eventuali problemi relativi alle prestazioni).

Puoi utilizzare una libreria HTTP , ad es. libonion , anche nel tuo programma codificato in C (o C ++, vedi anche wt ). C'è anche una libreria client HTTP (ad es. libcurl )

Puoi usare altre librerie HTTP, ad es. ocsigen & ocamlnet per OCaml .

Esistono diversi linguaggi Web dedicati (al di fuori di PHP), ad es. Opa , HOP , Kaya , ecc ... (sia HOP che Opa possono facilmente combinare calcoli lato server e lato browser, ma devi farlo in modo doloroso e manuale in PHP, < em> esplicitamente usando tecniche AJAX e codificando manualmente alcuni Javascript per il browser. , HOP, Opa, Ocsigen sono in grado di generare quel Javascript).

Puoi anche utilizzare la tecnologia FASTCGI per aggiungere alcuni servizi dinamici 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 . BTW, PHP può essere configurato per funzionare come applicazione FASTCGI.

C.Queinnec ha osservato che la navigazione sul 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). Infatti PHP è stato diffuso molto prima che AJAX diventasse ampiamente utilizzato, ed è più vecchio di HOP o Opa (o Ocsigen).