Explicación de cómo se accede a los lenguajes de programación del lado del servidor

Entiendo que cualquier lenguaje de programación de propósito general se puede usar para el desarrollo del lado del servidor de un sitio web.

¿Estoy en lo cierto al pensar que un servidor solo necesita algún tipo de interfaz como CGI para 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 (podía hacer canalizaciones con nombre de archivos, y esos se usaron días antes que cgi, pero eso no era práctico en absoluto).

CGI funciona al pegar un montón de información en el entorno del proceso que se bifurca y luego se ejecuta (y posiblemente algo en stdin) y luego toma lo que sale de stdout y lo escupe al solicitante.

Esto no le importa en absoluto 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 un ejecutivo de un proceso. Miles de solicitudes significa miles de procesos. Eso realmente no funciona bien.

La solución a esto es eliminar la bifurcación y la ejecución moviéndola a un hilo en el 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 complemento que mueve perl a apache). Php (finales de los 90) también hizo esto implementando el 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 dominante temprano) y podía superar a Perl CGI. Todavía hay bastante impulso a partir de este período de tiempo a mediados de los 90, antes de que los servidores de aplicaciones más empresariales comenzaran a establecerse con idiomas más formalizados detrás de ellos. Si cavas,

Esto nos lleva a los servidores de aplicaciones donde se generan hilos internos (u otros enfoques, este no es el caso para todo) para manejar solicitudes en lugar de procesos nuevos completos, lo que puede ayudar con la escala. Como proceso externo, esto se pudo ver con FastCGI y luego se hizo 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 funcionar como servidores web, aunque no estaban optimizados para manejar archivos IO estáticos de la misma manera que los servidores web tradicionales.

El servidor de aplicaciones genérico también ha allanado el camino hacia soluciones en las que, en lugar de un servidor de aplicaciones genérico , usted tiene la aplicación en sí misma, ya sea ejecutando un servidor web incorporado o siendo la implementación completa. En tales situaciones, uno no implementa una aplicación web en un servidor de aplicaciones, solo se está ejecutando y manejando las solicitudes. Nuevamente, el objetivo de este modelo es evitar el alto precio de lanzar nuevas instancias de la aplicación y en su lugar manejar las solicitudes dentro de la aplicación con hilos mucho más livianos o enfoques similares.

Sin embargo, aquí está la cosa: todas las soluciones son deficientes en alguna forma o forma. CGI, mientras que fácil tiene serios problemas con la escala. Los complementos en los servidores web se vinculan al servidor web en sí (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, ¿no 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 no son infrecuentes). Otros en una pila de C #. Otros en una pila de JavaScript. Hay bastantes pilas de php por ahí. Mucha pitón. Todavía puede encontrar algunas pilas de Perl (y si mira algunos sitios de bajo volumen, todavía encontrará CGI). Con la computación en la nube, Google también ha promocionado Go como un lenguaje web viable del lado del servidor.

Cada uno tiene sus ventajas, desventajas, sus marcos y sus servidores. La popularidad relativa de estos flujos y reflujos a medida que cambian las tecnologías a su alrededor. Hacen bien las cosas diferentes.

Sí, cualquier lenguaje de programación general puede servir para escribir la parte del servidor de un sitio web.

Sin embargo, las cualidades de un lenguaje de programación, en este tema como en otras cosas, generalmente son solo uno de los muchos factores que contribuyen a su popularidad.

Por ejemplo, creo que PHP se hizo popular para los sitios web porque:

• Es extremadamente fácil actualizar de un sitio web estático a un sitio web dinámico de PHP: simplemente reemplace la extensión de archivo de su archivo HTML, coloque la <?phpetiqueta al principio y, siempre que PHP esté instalado, ¡tiene un sitio web dinámico! El resto del flujo de trabajo es exactamente el mismo que para un sitio web estático;
• Debido a esa facilidad de implementación, los servidores web que buscaban proponer sitios web dinámicos eligieron PHP, por lo que es bastante rápido la plataforma del lado del servidor más ampliamente implementada;
• Entró en ese mercado en el momento adecuado;

Y una vez que PHP se implementó ampliamente, se volvió interesante escribir aplicaciones web más serias en PHP para beneficiarse de esa amplitud de implementación.

Para decirlo de una manera más genérica: la adopción del lenguaje a menudo se trata de las respuestas a estas preguntas:

• ¿Qué tan fácil es hacer lo que quiero hacer?
• ¿Cuán ampliamente soportado es el lenguaje para lo que quiero hacer?

¿Estoy en lo cierto al pensar que un servidor solo necesita algún tipo de interfaz como CGI para que el servidor y el lenguaje de programación trabajen juntos?

Casi. Necesita un servidor web que tenga algún tipo de software que también le permita responder a las solicitudes HTTP.

Piense en cómo se sirve una página estática. El servidor recupera la solicitud HTTP, encuentra el documento solicitado del sistema de archivos basado en la configuración del servidor HTTP y devuelve la página estática.

CGI amplía este concepto al permitirle designar una carpeta cgi-bin en el sistema de archivos donde se pueden almacenar ejecutables o scripts. Cuando accede a un programa a través de CGI, el servidor HTTP ejecuta el proceso o script y pasa 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 escala bien en un gran volumen de solicitudes. Existen diferentes lenguajes de programación y marcos para la web por diferentes razones, y cada uno hace bien las cosas diferentes. PHP es tan popular como lo es por razones históricas, ya que fue una de las primeras soluciones fáciles y económicas para servir páginas dinámicas sin recurrir a CGI y tenía un amplio soporte de alojamiento. 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) facilitó el paso de los desarrolladores de Windows Forms, muchos de los cuales eran codificadores VB, 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 lo que el servidor debe enviar una respuesta similar a 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, utilizando 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 la http.serverbiblioteca 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: 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ía muy 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 apropiada sería usar un servidor web, como Apache HTTPD , IIS o nginx . Un servidor web es solo un programa que escucha en los zócalos TCP relevantes, acepta múltiples solicitudes (posiblemente simultáneamente) y decide cómo generar una respuesta basada en la URL de solicitud, encabezados y otras reglas. Idealmente, muchos de los detalles, como SSL, control de acceso y límites de recursos, se solucionan mediante la configuración en lugar del código. La mayoría de las veces, el servidor web formulará una respuesta que consta solo del 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 un poco 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 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 de los motores de servlet node.js y 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 el "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.

¿Estoy en lo cierto al pensar que un servidor solo necesita algún tipo de interfaz como CGI para 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 alguna biblioteca de servidor HTTP , por ejemplo, libonion , incluso en su programa codificado en C (o C ++, consulte también Wt ). También hay alguna biblioteca de cliente HTTP (por ejemplo, libcurl )

Puede usar otras bibliotecas HTTP, por ejemplo, ocsigen y ocamlnet para OCaml .

Hay varios lenguajes dedicados a la web (fuera de PHP), por ejemplo, Opa , HOP , Kaya , etc. (tanto HOP como Opa pueden mezclar fácilmente los cálculos del lado del servidor y del lado del navegador, pero debe hacerlo de forma dolorosa y manual en PHP, explícitamente usando técnicas AJAX y codificando manualmente algunos Javascript para el navegador. Por el contrario, HOP, Opa, Ocsigen pueden 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 el CGI antiguo 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 se puede configurar para funcionar como una aplicación FASTCGI.

C.Queinnec observó que la navegación web y las continuaciones están significativamente relacionadas.

PD. No me gusta PHP, y creo que su popularidad tiene razones históricas y sociales (no principalmente técnicas). De hecho, PHP se generalizó mucho antes de que AJAX se usara ampliamente, y es más antiguo que HOP u Opa (u Ocsigen).