Tengo entendido que cualquier lenguaje de programación de propósito general puede usarse para el desarrollo del lado del servidor de un sitio web.
¿Tengo razón al pensar que un servidor solo necesita algún tipo de interfaz como CGI para hacer que el servidor y el lenguaje de programación trabajen juntos? Si es así, ¿por qué algunos lenguajes de programación (como php) son más populares que otros?
En los primeros días de la web, CGI era, de hecho, la única forma (práctica) de tener contenido dinámico (se podían hacer tuberías de archivos con nombre, y se usaban en días anteriores a cgi, pero eso no era práctico en todos).
CGI funciona pegando una gran cantidad de información en el entorno del proceso que se bifurca y luego se ejecuta (y posiblemente algo en estándar) y luego toma lo que sale de la salida estándar y lo escupe al solicitante.
Esto no importa un poco acerca de lo que es el lenguaje de implementación. De hecho, escribí mis primeros CGI en el día en C o C ++. Fue un poco doloroso. Más tarde aprendí algo de perl a principios de los 90 y eso fue mucho menos doloroso.
Esto funciona, hasta cierto punto. El problema es la escala. Cada solicitud CGI es una bifurcación y ejecución de un proceso. Miles de peticiones significan miles de procesos. Que realmente no funciona bien.
La solución a esto es eliminar la bifurcación y la ejecución, ya sea moviéndola a un subproceso en el propio servidor web, o enviando la solicitud a otro proceso que maneje la solicitud sin necesidad de bifurcar y ejecutar. mod_perl es una de esas herramientas para hacer esto (un plugin que mueve perl a apache). Php (finales de los 90) también hizo esto con la implementación del lenguaje como un complemento en el servidor web en lugar de algo que se bifurcó y superó. Esto se hizo bastante popular, ya que era similar a Perl (que era el lenguaje de programación web temprano y dominante) y podía superar a perl cgis. Todavía hay bastante impulso en este período de tiempo a mediados de los años 90, antes de que los servidores de aplicaciones de nivel empresarial comenzaran a afianzarse con idiomas más formalizados detrás de ellos. Si investigas, puedes encontrar muchos intentos fallidos desde finales de los 90 hasta principios de los 2000, idiomas y marcos que simplemente no se mantuvieron.
Esto nos lleva a los servidores de aplicaciones donde se generan subprocesos internos (u otros enfoques, no es el caso de todo) para manejar solicitudes en lugar de procesos completamente nuevos, lo que puede ayudar con la escala. Como un proceso externo, esto se pudo ver con FastCGI y luego se volvió frecuente con otros servidores de aplicaciones. Tenga en cuenta que con esto, la línea entre el servidor de aplicaciones y el servidor web se volvió un poco borrosa: muchos servidores de aplicaciones podrían duplicarse como servidores web, aunque no estaban optimizados para manejar la E / S de archivos estáticos de la forma en que lo están los servidores web tradicionales.
El servidor de aplicaciones genérico también ha allanado el camino a soluciones donde, en lugar de un servidor de aplicaciones genérico , tiene la aplicación ejecutando un servidor web incorporado o de otra manera siendo la implementación completa. En tales situaciones, uno no implementa una aplicación web en un servidor de aplicaciones, simplemente se ejecuta y maneja las solicitudes. Una vez más, el objetivo de este modelo es evitar el alto precio del lanzamiento de nuevas instancias de la aplicación y, en cambio, manejar las solicitudes dentro de la aplicación con subprocesos mucho más ligeros o enfoques similares.
Aquí está la cosa, sin embargo, todas las soluciones son deficientes de alguna manera, forma o forma. CGI, aunque fácil tiene serios problemas con la escala. Los complementos en los servidores web se unen al servidor web (apache vs nginx vs IIS vs ...) y pierden la funcionalidad común del lenguaje. Microsoft tiene su propio desfile de tecnologías que le gustaría promover. Y si conoce un idioma, ¿preferiría seguir programando en él en lugar de tener diferentes idiomas en diferentes partes de la pila (javascript en el cliente y Node.js)?
Y así, tienes hoy. Algunas personas trabajan en una pila de Java (con scala y clojure que no son infrecuentes). Otros en una pila de C #. Otros en una pila de JavaScript. Hay un montón de pilas php por ahí. Un montón de python. Todavía puedes encontrar algunas pilas de perl por ahí (y si miras algunos sitios de bajo volumen, aún encontrarás CGI). Con la computación en la nube, Google también ha promovido Go como un lenguaje web del lado del servidor viable.
Cada uno tiene sus ventajas, desventajas, sus marcos y sus servidores. La relativa popularidad de estos flujos y reflujos a medida que cambian las tecnologías a su alrededor. Hacen diferentes cosas bien.
Sí, cualquier lenguaje de programación general puede servir para escribir la parte del lado del servidor de un sitio web.
Sin embargo, las cualidades de un lenguaje de programación, en este tema y en otras cosas, suelen ser solo uno de los muchos factores que contribuyen a su popularidad.
Por ejemplo, creo que PHP se hizo popular para los sitios web porque:
<?php al principio y, siempre que PHP esté instalado, tiene una dinámica sitio web! El resto del flujo de trabajo es exactamente el mismo que para un sitio web estático; Y una vez que PHP se implementó ampliamente, se volvió interesante escribir aplicaciones web más serias en PHP para beneficiarse de la amplitud de la implementación.
Para decirlo de una manera más genérica: la adopción del idioma a menudo se trata de las respuestas a estas preguntas:
Tengo razón al pensar que un servidor solo necesita algún tipo de interfaz como CGI para hacer que el servidor y el lenguaje de programación funcionen juntos?
Casi. Necesita un servidor web que tenga algún tipo de software que le permita responder a las solicitudes HTTP también.
Piensa en cómo se sirve una página estática. El servidor recupera la solicitud HTTP, encuentra el documento solicitado del sistema de archivos según la configuración del servidor HTTP y devuelve la página estática.
CGI extiende este concepto al permitirle designar una carpeta cgi-bin en el sistema de archivos donde se pueden almacenar los ejecutables o los scripts. Cuando accede a un programa a través de CGI, el servidor HTTP ejecuta el proceso o el script y transfiere la salida estándar al cliente en lugar de simplemente entregar el documento estático.
If so then why are some programming languages (such as php) more popular than others?
La antigua estructura CGI no se adapta bien a un gran volumen de solicitudes. Existen diferentes lenguajes de programación y marcos para la web por diferentes motivos, y cada uno hace bien las cosas. PHP es tan popular como lo es por razones históricas, ya que fue una de las primeras soluciones fáciles y baratas para servir páginas dinámicas sin tener que recurrir a CGI y tenía un amplio soporte de hosting. ASP era popular entre los círculos de Microsoft porque permitía a los desarrolladores de VB cambiar sus habilidades a la web. ASP.NET (Web Forms) hizo muy fácil para los desarrolladores de Windows Forms, muchos de los cuales eran programadores VB, cambiar a la web.
Cuando un navegador realiza una solicitud HTTP, se ve así:
GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close
... a la que el servidor debe enviar una respuesta como esta:
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>
Cualquier código que se ejecute en el servidor que escuche las solicitudes en un socket TCP, lea la solicitud y responda con la respuesta adecuada será suficiente. Una forma tonta es simplemente escupir una respuesta enlatada a cualquiera que se conecte al puerto TCP 80, usando un script de 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
Por supuesto, esa técnica apenas parece cumplir con el protocolo HTTP .
Un paso adelante de esa respuesta enlatada es este sencillo programa de Python, que utiliza el http.server biblioteca en 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()
El servidor HTTP se puede escribir en cualquier idioma; Eso es solo un ejemplo. Obviamente, este ejemplo es muy rudimentario. La carga útil está codificada de forma rígida: el programa ignora por completo el contenido de la solicitud: la URL, la cadena de consulta, el encabezado Accept-Language, etc. Puede agregar código para generar respuestas significativas basadas en la solicitud, pero luego el código se volverá muy complejo. complejo. Además, los programadores prefieren centrarse en escribir la aplicación web, sin tener que preocuparse por los detalles de cómo manejar una solicitud HTTP.
Una solución más adecuada sería utilizar un servidor web, como Apache HTTPD , IIS , o nginx . Un servidor web es solo un programa que escucha en los sockets TCP relevantes, acepta múltiples solicitudes (posiblemente de manera simultánea) y decide cómo generar una respuesta basada en la URL de solicitud, los encabezados y otras reglas. Idealmente, muchos de los detalles, como SSL, control de acceso y límites de recursos, se cuidan a través de la configuración en lugar del código. La mayor parte del tiempo, el servidor web formulará una respuesta que consiste solo en el contenido de los archivos en el sistema de archivos.
Sin embargo, para el contenido dinámico, el servidor web puede configurarse para ejecutar algún código para generar la respuesta. Un mecanismo para hacerlo es con CGI: el servidor establece algunas variables de entorno basadas en la solicitud, ejecuta un programa y copia su salida al socket TCP. Una solución ligeramente más sofisticada sería tener un módulo que agregue soporte al servidor web para llamar al código en otro lenguaje de programación (por ejemplo, mod_php para Apache ). Otra opción más es escribir el servidor web en el mismo idioma que la aplicación web, en cuyo caso el envío de la solicitud es solo una llamada de función. Ese es el caso con node.js y motores de servlet de Java como Apache Tomcat .
La elección de la tecnología depende realmente de usted, y depende del lenguaje de programación que prefiera usar, el entorno de alojamiento que está disponible para usted, los requisitos de rendimiento, la opinión popular y las modas pasajeras. CGI, por ejemplo, no se ha visto favorecido últimamente, ya que la necesidad de lanzar programas externos limita la escalabilidad.
Un servidor web es un programa escrito en cualquier lenguaje de programación que maneja "tráfico web" a través de sockets que se adhieren a los estándares / protocolos de nivel de aplicación (HTTP, etc.). La mayoría de los lenguajes de programación le ofrecen crear un socket.
¿Tengo razón al pensar que un servidor solo necesita algún tipo de interfaz como CGI para hacer que el servidor y el lenguaje de programación trabajen juntos?
No es necesario tener un programa de servidor dedicado y su programa de aplicación; pueden ser los mismos (sin tener en cuenta los problemas relacionados con el rendimiento).
Puede usar la biblioteca del servidor HTTP , por ejemplo. libonion , incluso en su programa codificado en C (o C ++, consulte también Wt ). También hay algunas bibliotecas de clientes HTTP (por ejemplo, libcurl )
Puedes usar otras bibliotecas HTTP, por ejemplo, ocsigen & ocamlnet para OCaml .
Hay varios idiomas dedicados a la Web (fuera de PHP), por ejemplo, Opa , HOP , Kaya , etc ... (tanto HOP como Amp; Opa pueden combinar fácilmente los cálculos del lado del servidor y del navegador, pero debe hacerlo de forma dolorosa y manual en PHP, < em> explícitamente usando las técnicas AJAX y codificando a mano algunos Javascript para el navegador. En contraste , HOP, Opa, Ocsigen son capaces de generar ese Javascript).
También puede usar la tecnología FASTCGI para agregar algún servicio dinámico a algún servidor web ... FASTCGI es mejor que simple CGI que inicia un nuevo proceso para cada solicitud HTTP entrante, mientras que una aplicación FASTCGI puede atender muchas solicitudes HTTP en el mismo proceso . Por cierto, PHP puede configurarse para funcionar como una aplicación FASTCGI.
C.Queinnec observó que la navegación web y las continuations están significativamente relacionadas.
PS. No me gusta PHP, y creo que su popularidad tiene razones históricas y sociales (no principalmente técnicas). De hecho, PHP se extendió mucho antes de que AJAX se usara ampliamente, y es más antiguo que HOP u Opa (u Ocsigen).
Lea otras preguntas en las etiquetas programming-languages web-development web