web-dev-qa-db-fra.com

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 côté serveur d'un site Web.

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

programming-languagesweb-developmentweb
45
Chris Dance

Au début du Web, CGI était en effet le seul moyen (pratique) d'avoir du contenu dynamique (vous pouviez créer des canaux de fichiers nommés - et ceux-ci étaient utilisés quelques jours avant cgi, mais ce n'était pas du tout pratique).

CGI fonctionne en collant un tas d'informations dans l'environnement du processus qui est bifurqué puis exécuté (et peut-être certaines dans stdin), puis prend ce qui sort de stdout et le rejette au demandeur.

Cela ne se soucie pas du tout du 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 douloureux.

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

La solution à cela consiste à supprimer le forking et l'exécution en le déplaçant dans un thread dans le serveur Web lui-même, ou en répartissant la demande vers un autre processus qui gère la demande sans avoir à effectuer de fork et exec. mod_Perl est un de ces outils pour ce faire (un plugin déplaçant Perl dans Apache). Php (fin des années 90) a également fait cela en implémentant le langage en tant que plugin dans le serveur Web lui-même plutôt que quelque chose qui a été bifurqué et dépassé. Cela est devenu très populaire car il ressemblait à Perl (qui était le premier langage de programmation Web dominant) et pouvait surpasser Perg cgis. Il y a encore un peu de dynamisme à partir de cette période au milieu des années 90 - avant que les serveurs d'applications plus professionnels ne commencent à s'installer avec des langages plus formalisés derrière eux. Si vous creusez, vous pouvez également trouver beaucoup de tentatives infructueuses de la fin des années 90 au début des années 2000 - des langages et des cadres qui ne collaient tout simplement pas.

Cela nous amène aux serveurs d'applications où les threads internes sont générés (ou d'autres approches - ce n'est pas le cas pour tout) pour gérer les demandes plutôt que de nouveaux processus entiers - ce qui peut aider à l'échelle. En tant que processus externe, cela a pu être vu avec FastCGI, puis est devenu plus fréquent avec d'autres serveurs d'applications. Notez qu'avec cela, la ligne entre le serveur d'applications et le serveur Web est devenue un peu floue - de nombreux serveurs d'applications pourraient servir de serveurs Web, bien qu'ils ne soient pas optimisés pour gérer le fichier statique IO de la manière les serveurs Web traditionnels le sont.

Le serveur d'applications générique a également ouvert la voie à des solutions où, au lieu d'un serveur d'applications générique, vous avez l'application elle-même exécutant un serveur Web intégré ou constituant le déploiement entier. Dans de telles situations, on ne déploie pas d'application Web sur un serveur d'applications - il s'exécute simplement et gère les demandes. Encore une fois, l'objectif de ce modèle est d'éviter le prix élevé du lancement de nouvelles instances de l'application et de gérer les demandes à 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, bien que facile, a de sérieux problèmes d'échelle. Les plugins 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 Et si vous connaissez une langue, ne préférez-vous pas continuer à la programmer plutôt que d'avoir des langues différentes dans différentes parties de la pile (javascript dans le client et Node.js)?

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

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 changent. Ils font bien des choses différentes.

75
user40980

Oui, tout langage de programmation général peut servir à écrire la partie côté 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 parce que:

  • Il est extrêmement facile de passer d'un site Web statique à un PHP - remplacez simplement l'extension de fichier de votre fichier HTML, placez le <?php tag au début, et, à condition que PHP soit installé, vous avez un site web dynamique! Le reste du workflow est exactement le même que pour un site web statique;
  • En raison de cette facilité de déploiement, les hébergeurs qui cherchaient à proposer des sites Web dynamiques ont choisi PHP, ce qui en fait assez 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 bénéficier de cette ampleur de déploiement).

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

  • Est-il facile de faire ce que je veux faire?
  • Dans quelle mesure la langue de ce que je veux faire est-elle largement prise en charge?
19
jhominal

Ai-je raison de penser qu'un serveur a juste 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'une sorte de logiciel lui permettant de répondre également aux requêtes HTTP.

Pensez à la façon dont une page statique est diffusée. 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 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 transmet 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 n'évolue pas bien sur un grand volume de demandes. Différents langages de programmation et frameworks pour le Web existent pour différentes raisons, et chacun fait bien des choses différentes. PHP est aussi populaire que pour des raisons historiques, car il a été l'une des premières solutions faciles et bon marché pour servir des pages dynamiques sans recourir à CGI et avait un support d'hébergement généralisé. ASP était populaire parmi les cercles Microsoft car il permettait aux développeurs de VB de transférer leurs compétences sur le Web. ASP.NET (Web Forms) facilitait grandement la tâche des développeurs Windows Forms, dont beaucoup qui étaient VB codeurs, pour basculer sur le web.

7
ravibhagw

Lorsqu'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 le Une réponse stupide consiste simplement à cracher une réponse standardisée à toute personne qui se connecte à TCP port 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 sûr, cette technique semble à peine conforme au protocole HTTP .

Un pas de plus par rapport à cette réponse standardisée est ce simple programme Python, qui utilise le http.server bibliothèque dans 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()

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 demande - 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 en fonction de la demande, mais le code deviendrait alors très complexe. En outre, les programmeurs préfèrent se concentrer sur l'écriture de l'application Web, sans avoir à se soucier des détails sur la façon de gérer une demande HTTP.

Une solution plus appropriée consisterait à utiliser un serveur Web, tel que Apache HTTPD , IIS , ou nginx . Un serveur Web n'est qu'un programme qui écoute les sockets TCP pertinentes, 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 pris en charge via la configuration plutôt que le code. La plupart du temps, le serveur Web formule une réponse qui se compose uniquement de contenu provenant de fichiers du système de fichiers. .

Pour le contenu dynamique, cependant, le serveur Web peut être configuré pour exécuter du code pour générer la réponse. Un mécanisme pour le faire est avec CGI - 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 serait de avoir un module qui ajoute la prise en charge au 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 le même langage que l'application Web, en auquel cas, l'envoi de la demande n'est qu'un appel de fonction. C'est le cas avec node.js et Java moteurs de servlet 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 populaire et des modes passagères. CGI, par exemple, n'a pas été favorisé récemment, car la nécessité de lancer des programmes externes limite l'évolutivité.

3
200_success

Un serveur Web est un programme écrit dans n'importe quel langage de programmation qui gère le "trafic Web" via des sockets respectant les normes/protocoles de niveau application (HTTP, etc.). La plupart des langages de programmation vous proposent de créer une socket.

Ai-je raison de penser qu'un serveur a juste 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 les mêmes (sans tenir compte des problèmes liés aux performances).

1
mucaho

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 ). Il y a 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 ex. Opa , HOP , Kaya , etc ... (les deux HOP et Opa peuvent facilement mélanger le serveur et côté navigateur, mais vous devez le faire péniblement et manuellement en PHP, explicitement en utilisant AJAX techniques et codage manuel de Javascript pour le navigateur. En revanche, HOP, Opa, Ocsigen sont capables de générer ce Javascript).

Vous pouvez également utiliser la technologie FASTCGI pour ajouter un service dynamique à un serveur Web ... FASTCGI est meilleur que l'ancien CGI qui démarre un nouveau processus pour chaque requête HTTP entrante, tandis qu'une application FASTCGI peut servir de nombreuses requêtes HTTP dans le même processus. BTW, PHP peut être configuré pour fonctionner comme une application FASTCGI.

C.Queinnec a observé que la navigation sur le Web et suite sont significativement liés.

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

0
Basile Starynkevitch