Explication de l'accès aux langages de programmation côté serveur

Je crois comprendre que tout langage de programmation à usage général peut être utilisé pour le développement d’un site Web côté serveur.

Ai-je raison de penser qu'un serveur a simplement besoin d'une sorte d'interface, telle que CGI, pour que le serveur et le langage de programmation fonctionnent ensemble? Si tel est le cas, pourquoi certains langages de programmation (tels que php) sont-ils plus populaires que d’autres?

À ses débuts sur le Web, CGI était en effet le seul moyen (pratique) d’avoir un contenu dynamique (vous pouviez créer des canaux de fichiers nommés - et ceux-ci étaient utilisés jadis, mais ce n’était pas du tout pratique).

CGI fonctionne en collant un tas d'informations dans l'environnement du processus qui est créé, puis exécuté (et éventuellement dans stdin), puis extrait ce qui sort de stdout et le renvoie au demandeur.

Cela n’a aucune importance pour le langage d’implémentation. En effet, j’ai écrit mes premiers CGI à l’époque en C ou C ++. C'était un peu douloureux. J'ai appris plus tard du perl au début des années 90 et c'était beaucoup moins pénible.

Cela fonctionne, jusqu'à un certain point. Le problème est l'échelle. Chaque demande CGI est un fork et un exec d'un processus. Des milliers de demandes signifient des milliers de processus. Cela ne fonctionne vraiment pas bien.

La solution à ce problème consiste à supprimer le forking et l’exécution en le déplaçant dans un thread du serveur Web lui-même ou en envoyant la demande à un autre processus qui gère la demande sans avoir besoin de fork et d’exec. mod_perl est un de ces outils (un plugin déplaçant perl dans apache). Php (fin des années 90) l'a également fait avec la mise en œuvre de la langue en tant que plug-in dans le serveur Web lui-même plutôt que quelque chose de fourré et de dépassé. Cela est devenu assez populaire car il ressemblait à Perl (qui était le premier langage de programmation Web dominant) et pouvait surperformer perg cgis. Depuis le milieu des années 90, le moment est encore bien choisi pour que les serveurs d’applications de niveau entreprise commencent à s’implanter avec des langages plus formalisés. Si vous creusez,

Cela nous amène aux serveurs d'applications où des threads internes sont générés (ou d'autres approches - ce n'est pas le cas pour tout le monde) pour gérer les demandes plutôt que de nouveaux processus entiers - ce qui peut aider à l'échelle. En tant que processus externe, cela pouvait être vu avec FastCGI puis est devenu répandu plus tard avec d'autres serveurs d'applications. Notez que la démarcation entre serveur d'applications et serveur Web est un peu floue: de nombreux serveurs d'applications peuvent faire office de serveurs Web, bien qu'ils ne soient pas optimisés pour gérer les E / S de fichiers statiques comme le sont les serveurs Web traditionnels.

Le serveur d'applications génériques a également ouvert la voie à des solutions où, au lieu d'un serveur d'applications génériques , l'application elle-même exécute un serveur Web intégré ou constitue le déploiement complet. Dans de telles situations, une application Web n'est pas déployée sur un serveur d'applications, elle s'exécute simplement et traite les demandes. Là encore, l’objectif de ce modèle est d’éviter le lourd tribut du lancement de nouvelles instances de l’application et de gérer les requêtes à l’intérieur de l’application avec des threads beaucoup plus légers ou des approches similaires.

Voici la chose cependant - toutes les solutions sont déficientes d'une manière ou d'une autre. CGI, tandis que facile a de sérieux problèmes d’échelle. Les plug-in des serveurs Web sont liés au serveur Web lui-même (apache vs nginx vs IIS vs ...) et perdent les fonctionnalités communes du langage. Microsoft a son propre défilé de technologies qu’il aimerait promouvoir. Et si vous connaissez une langue, ne préféreriez-vous pas continuer à y programmer plutôt que d’avoir différentes langues dans différentes parties de la pile (javascript dans le client et Node.js)?

Et oui, vous avez aujourd'hui. Certaines personnes travaillent dans une pile Java (la scala et le clojure devenant une pratique courante). D'autres dans une pile C #. D'autres dans une pile JavaScript. Il y a pas mal de piles php là-bas. Beaucoup de python. Vous pouvez toujours trouver des piles de Perl (et si vous regardez des sites à faible volume, vous trouverez toujours des CGI). Avec le cloud computing, Google a également promu Go en tant que langage Web viable côté serveur.

Chacun a ses avantages, ses inconvénients, ses frameworks et ses serveurs. La popularité relative de ces flux et reflux à mesure que les technologies qui les entourent change. Ils font bien des choses différentes.

Oui, tout langage de programmation général peut servir à écrire la partie serveur d’un site Web.

Cependant, les qualités d'un langage de programmation, dans ce sujet comme dans d'autres choses, ne sont généralement qu'un des nombreux facteurs qui contribuent à sa popularité.

Par exemple, je pense que PHP est devenu populaire pour les sites Web pour les raisons suivantes:

• Il est extrêmement facile de passer d'un site Web statique à un site Web dynamique PHP: il vous suffit de remplacer l'extension de fichier de votre fichier HTML, de placer le <?phptag au début et, à condition que PHP soit installé, vous avez un site Web dynamique! Le reste du flux de travail est exactement le même que pour un site Web statique;
• En raison de cette facilité de déploiement, les hôtes Web qui cherchaient à proposer des sites Web dynamiques ont choisi PHP, ce qui en fait rapidement la plate-forme côté serveur la plus largement déployée.
• Il est entré sur ce marché au bon moment;

Et une fois que PHP a été largement déployé, il est devenu intéressant d’écrire des applications Web plus sérieuses en PHP afin de tirer parti de cette étendue de déploiement.

Pour le dire d'une manière plus générique: l'adoption de la langue est souvent une question de réponses à ces questions:

• Est-ce facile de faire ce que je veux faire?
• Dans quelle mesure le langage de ce que je veux faire est-il largement pris en charge?

Ai-je raison de penser qu'un serveur a simplement besoin d'une sorte d'interface, telle que CGI, pour que le serveur et le langage de programmation fonctionnent ensemble?

Presque. Vous avez besoin d’un serveur Web doté d’un type de logiciel lui permettant de répondre également aux requêtes HTTP.

Pensez à la manière dont une page statique est servie. Le serveur récupère la requête HTTP, trouve le document demandé dans le système de fichiers en fonction de la configuration du serveur HTTP et renvoie la page statique.

CGI étend ce concept en vous permettant de désigner un dossier cgi-bin sur le système de fichiers où les fichiers exécutables ou les scripts peuvent être stockés. Lorsque vous accédez à un programme via CGI, le serveur HTTP exécute le processus ou le script et renvoie la sortie standard au client plutôt que de simplement servir le document statique.

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

L'ancienne structure CGI ne permet pas de traiter un grand nombre de demandes. Différents langages de programmation et cadres pour le Web existent pour différentes raisons et chacun fait des choses bien différentes. PHP est aussi populaire qu'historique, car il s'agissait de l'une des premières solutions faciles et peu coûteuses permettant de servir des pages dynamiques sans recourir à CGI et bénéficiant d'un support d'hébergement étendu. ASP était populaire parmi les cercles Microsoft car il permettait aux développeurs de VB de transférer leurs compétences au Web. ASP.NET (Web Forms) a rendu très facile le basculement vers le Web pour les développeurs Windows Forms, dont beaucoup étaient des codeurs VB.

Quand un navigateur fait une requête HTTP, cela ressemble à ceci:

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

… À laquelle le serveur doit envoyer une réponse qui ressemble à ceci:

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>

Tout code exécuté sur le serveur qui écoute les demandes sur un socket TCP, lit la demande et répond avec la réponse appropriée suffira. Une méthode idiote consiste simplement à envoyer une réponse prédéfinie à quiconque se connecte au port TCP 80 à l'aide d'un 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

Bien entendu, cette technique semble à peine conforme au protocole HTTP .

Ce programme Python simple, qui utilise la http.serverbibliothèque de Python 3, constitue une avancée supplémentaire à partir de cette réponse prédéfinie.

#!/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()

Le serveur HTTP peut être écrit dans n'importe quelle langue. ce n'est qu'un exemple. Évidemment, cet exemple est très rudimentaire. La charge utile est codée en dur - le programme ignore complètement le contenu de la requête - l'URL, la chaîne de requête, l'en-tête Accept-Language, etc. Vous pouvez ajouter du code pour générer des réponses significatives basées sur la requête, complexe. En outre, les programmeurs préfèrent se concentrer sur l'écriture de l'application Web sans avoir à s'inquiéter des détails de la gestion d'une requête HTTP.

Une solution plus appropriée consisterait à utiliser un serveur Web, tel que Apache HTTPD , IIS ou nginx . Un serveur Web est simplement un programme qui écoute sur les sockets TCP appropriés, accepte plusieurs demandes (éventuellement simultanément) et décide comment générer une réponse en fonction de l'URL de la demande, des en-têtes et d'autres règles. Idéalement, de nombreux détails, tels que SSL, le contrôle d'accès et les limites de ressources, sont gérés via la configuration plutôt que par le code. La plupart du temps, le serveur Web formulera une réponse composée uniquement du contenu des fichiers du système de fichiers.

Pour le contenu dynamique, cependant, le serveur Web peut être configuré pour exécuter du code afin de générer la réponse. CGI est l’un des mécanismes permettant de le faire: le serveur définit certaines variables d’environnement en fonction de la demande, exécute un programme et copie sa sortie dans le socket TCP. Une solution légèrement plus sophistiquée consisterait à avoir un module qui ajoute la prise en charge du serveur Web pour appeler du code dans un autre langage de programmation (par exemple, mod_php pour Apache ). Une autre option consiste à écrire le serveur Web dans la même langue que l'application Web, auquel cas l'envoi de la demande est simplement un appel de fonction. C'est le cas des serveurs node.js et Java tels que Apache Tomcat .

Le choix de la technologie dépend vraiment de vous et dépend du langage de programmation que vous préférez utiliser, de l’environnement d’hébergement à votre disposition, des exigences de performances, de l’opinion publique et des modes à la mode. CGI, par exemple, n’a pas été privilégié ces derniers temps, car la nécessité de lancer des programmes externes limite l’évolutivité.

Un serveur Web est un programme écrit dans n’importe quel langage de programmation qui gère le "trafic Web" sur des sockets conformes aux protocoles standard / au niveau de l’application (HTTP, etc.). La plupart des langages de programmation vous proposent de créer un socket.

Ai-je raison de penser qu'un serveur a simplement besoin d'une sorte d'interface, telle que CGI, pour que le serveur et le langage de programmation fonctionnent ensemble?

Il n’est pas nécessaire d’avoir un programme serveur dédié et votre programme d’application. Ils peuvent être identiques (indépendamment des problèmes de performances).

Vous pouvez utiliser une bibliothèque de serveur HTTP , par exemple, libonion , même dans votre programme codé en C (ou C ++, voir aussi Wt ). Là aussi une bibliothèque client HTTP (par exemple, libcurl )

Vous pouvez utiliser d'autres bibliothèques HTTP, par exemple ocsigen & ocamlnet pour OCaml .

Il existe plusieurs langages dédiés au Web (en dehors de PHP), par exemple Opa , HOP , Kaya , etc ... (HOP et Opa peuvent facilement mélanger des calculs côté serveur et côté navigateur, mais vous devez le faire manuellement et péniblement. PHP, utilisant explicitement les techniques AJAX et codant à la main du code Javascript pour le navigateur (au contraire, HOP, Opa, Ocsigen sont capables de générer ce code Javascript).

Vous pouvez également utiliser la technologie FASTCGI pour ajouter un service dynamique à un serveur Web ... FASTCGI est meilleur qu'un simple ancien CGI qui lance un nouveau processus pour chaque requête HTTP entrante, alors qu'une application FASTCGI peut traiter plusieurs requêtes HTTP dans le même processus. En passant, PHP peut être configuré pour fonctionner comme une application FASTCGI.

C.Queinnec a observé que la navigation sur le Web et les activités en continu étaient étroitement liées.

PS Je n'aime pas le PHP et je pense que sa popularité a des raisons historiques et sociales (pas principalement techniques). En effet, PHP était largement répandu bien avant que AJAX ne soit largement utilisé et est plus ancien que HOP ou Opa (ou Ocsigen).