Explicação de como as linguagens de programação do lado do servidor são acessadas

Entendo que qualquer linguagem de programação de uso geral possa ser usada para o desenvolvimento de um site no servidor.

Estou certo ao pensar que um servidor só precisa de algum tipo de interface, como CGI, para fazer o servidor e a linguagem de programação funcionarem juntos? Se sim, por que algumas linguagens de programação (como php) são mais populares que outras?

Nos primeiros dias da web, o CGI era de fato a única maneira (prática) de ter conteúdo dinâmico (você podia fazer pipes nomeados de arquivos - e esses eram usados ​​dias antes do cgi, mas isso não era prático).

O CGI trabalha colando um monte de informações no ambiente do processo que é bifurcado e depois executado (e possivelmente alguns no stdin) e, em seguida, pega o que sai do stdout e cospe de volta para o solicitante.

Isso não se importa nem um pouco com o que é a linguagem de implementação. Na verdade, escrevi meus primeiros CGIs no dia em C ou C ++. Foi meio doloroso. Mais tarde, aprendi alguns perl no início dos anos 90 e isso foi muito menos doloroso.

Isso funciona, até certo ponto. O problema é escala. Cada solicitação CGI é uma bifurcação e exec de um processo. Milhares de solicitações significam milhares de processos. Isso realmente não funciona bem.

A solução é remover o bifurcação e a execução, movendo-o para um encadeamento no próprio servidor da Web ou enviando a solicitação para outro processo que lide com a solicitação sem a necessidade de bifurcar e executar. O mod_perl é uma dessas ferramentas para fazer isso (um plugin movendo perl para o apache). O Php (final dos anos 90) também fez isso implementando a linguagem como um plug-in no próprio servidor da Web, em vez de algo que foi bifurcado e excedido. Isso se tornou bastante popular, pois era parecido com perl (que era a linguagem de programação da Web dominante no início) e poderia superar o perl cgis. Ainda existe bastante impulso nesse período em meados da década de 90 - antes que os servidores de aplicativos de nível empresarial começassem a se apossar de linguagens mais formalizadas por trás deles. Se você cavar,

Isso nos leva aos servidores de aplicativos onde os encadeamentos internos são gerados (ou outras abordagens - esse não é o caso de tudo) para lidar com solicitações, e não com novos processos inteiros - o que pode ajudar na expansão. Como um processo externo, isso pôde ser visto com o FastCGI e, posteriormente, tornou-se predominante em outros servidores de aplicativos. Observe que, com isso, a linha entre o servidor de aplicativos e o servidor da Web ficou um pouco embaçada - muitos servidores de aplicativos podem dobrar como servidores da Web, embora não tenham sido otimizados para lidar com E / S de arquivo estático da maneira que os servidores da Web tradicionais.

O servidor de aplicativos genérico também abriu o caminho para soluções em que, em vez de um servidor de aplicativos genérico , você possui o próprio aplicativo executando um servidor da Web incorporado ou sendo a implementação inteira. Nessas situações, não é possível implantar um aplicativo Web em um servidor de aplicativos - ele apenas está executando e processando solicitações. Novamente, o objetivo desse modelo é evitar o alto preço do lançamento de novas instâncias do aplicativo e, em vez disso, manipular os pedidos dentro do aplicativo com threads de peso muito mais leves ou abordagens semelhantes.

Mas aqui está a questão: todas as soluções são deficientes de alguma forma, forma ou formato. CGI, embora fácil, tenha sérios problemas de escala. Os plug-ins nos servidores da Web são vinculados ao próprio servidor da Web (apache vs nginx vs IIS vs ...) e perdem a funcionalidade comum do idioma. A Microsoft tem seu próprio desfile de tecnologias que gostaria de promover. E se você conhece um idioma, prefere não continuar programando nele, em vez de ter idiomas diferentes em diferentes partes da pilha (javascript no cliente e Node.js)?

E então, você tem hoje. Algumas pessoas trabalham em uma pilha Java (com scala e clojure se tornando incomum). Outros em uma pilha C #. Outros em uma pilha JavaScript. Há um monte de pilhas php por aí. Muitos python. Você ainda pode encontrar algumas pilhas de perl por aí (e se você olhar em alguns sites de baixo volume, ainda encontrará CGIs). Com a computação em nuvem, o Google também promoveu o Go como uma linguagem da web viável do lado do servidor.

Cada um tem suas vantagens, desvantagens, estruturas e servidores. A popularidade relativa desses fluxos e refluxos à medida que as tecnologias ao seu redor mudam. Eles fazem coisas diferentes bem.

Sim, qualquer linguagem de programação geral pode servir para escrever a parte do servidor de um site.

No entanto, as qualidades de uma linguagem de programação, neste assunto e em outras coisas, geralmente são apenas um dos muitos fatores que contribuem para sua popularidade.

Por exemplo, eu acho que o PHP se tornou popular nos sites porque:

• É extremamente fácil atualizar de um site estático para um site dinâmico em PHP - basta substituir a extensão do arquivo HTML, colocar a <?phptag no início e, desde que o PHP esteja instalado, você tem um site dinâmico! O restante do fluxo de trabalho é exatamente igual ao de um site estático;
• Devido a essa facilidade de implantação, os hosts da web que procuravam propor sites dinâmicos escolheram o PHP, tornando-o rapidamente a plataforma do servidor mais amplamente implantada;
• Entrou nesse mercado na hora certa;

E uma vez que o PHP foi amplamente implementado, tornou-se interessante escrever aplicativos da Web mais sérios no PHP para se beneficiar dessa amplitude de implantação.

Para dizer de uma maneira mais genérica: a adoção de idiomas geralmente envolve as respostas a estas perguntas:

• Quão fácil é fazer o que eu quero?
• Qual é o nível de suporte do idioma para o que eu quero fazer?

Estou certo ao pensar que um servidor só precisa de algum tipo de interface, como CGI, para fazer o servidor e a linguagem de programação funcionarem juntos?

Quase. Você precisa de um servidor da Web que possua algum tipo de software para permitir que ele também responda às solicitações HTTP.

Pense em como uma página estática é veiculada. O servidor recupera a solicitação HTTP, localiza o documento solicitado do sistema de arquivos com base na configuração do servidor HTTP e retorna a página estática.

O CGI estende esse conceito, permitindo que você designe uma pasta cgi-bin no sistema de arquivos onde arquivos executáveis ​​ou scripts podem ser armazenados. Quando você acessa um programa via CGI, o servidor HTTP executa o processo ou script e passa a saída padrão de volta ao cliente, em vez de simplesmente fornecer o documento estático.

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

A estrutura CGI antiga não se adapta bem a um grande volume de solicitações. Diferentes linguagens de programação e estruturas para a web existem por diferentes razões, e cada uma faz coisas diferentes. O PHP é tão popular quanto por razões históricas, pois foi uma das primeiras soluções fáceis e baratas para servir páginas dinâmicas sem recorrer ao CGI e tinha amplo suporte de hospedagem. O ASP era popular entre os círculos da Microsoft porque permitia que os desenvolvedores de VB mudassem suas habilidades para a Web. O ASP.NET (Web Forms) tornou muito fácil para os desenvolvedores do Windows Forms, muitos dos quais codificadores VB, mudarem para a Web.

Quando um navegador faz uma solicitação HTTP, fica assim:

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

… Para o qual o servidor deve enviar uma resposta parecida com 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>

Qualquer código em execução no servidor que escute solicitações em um soquete TCP, leia a solicitação e responda com a resposta apropriada será suficiente. Uma maneira idiota é apenas cuspir uma resposta enlatada para quem se conecta à porta TCP 80, usando um 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

Obviamente, essa técnica mal parece estar em conformidade com o protocolo HTTP .

Um passo adiante dessa resposta em lata é esse simples programa Python, que usa a http.serverbiblioteca no 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()

O servidor HTTP pode ser escrito em qualquer idioma; isso é apenas um exemplo. Obviamente, este exemplo é muito rudimentar. A carga útil é codificada - o programa desconsidera completamente o conteúdo da solicitação - a URL, a string de consulta, o cabeçalho Accept-Language etc. Você pode adicionar código para gerar respostas significativas com base na solicitação, mas o código ficará muito complexo. Além disso, os programadores preferem se concentrar em escrever o aplicativo da Web, sem ter que se preocupar com os detalhes de como lidar com uma solicitação HTTP.

Uma solução mais apropriada seria usar um servidor da Web, como Apache HTTPD , IIS ou nginx . Um servidor da web é apenas um programa que escuta nos soquetes TCP relevantes, aceita várias solicitações (possivelmente simultaneamente) e decide como gerar uma resposta com base na URL da solicitação, nos cabeçalhos e em outras regras. Idealmente, muitos dos detalhes, como SSL, controle de acesso e limites de recursos, são resolvidos via configuração, e não por código. Na maioria das vezes, o servidor da Web formulará uma resposta que consiste apenas no conteúdo dos arquivos no sistema de arquivos.

No entanto, para conteúdo dinâmico, o servidor da web pode ser configurado para executar algum código para gerar a resposta. Um mecanismo para fazer isso é com CGI - o servidor define algumas variáveis ​​de ambiente com base na solicitação, executa um programa e copia sua saída no soquete TCP. Uma solução um pouco mais sofisticada seria ter um módulo que adiciona suporte ao servidor da Web para chamar código em outra linguagem de programação (por exemplo, mod_php para Apache ). Ainda outra opção é escrever o servidor da web no mesmo idioma que o aplicativo da web; nesse caso, o despacho da solicitação é apenas uma chamada de função. É o caso dos mecanismos de servlet node.js e Java, como o Apache Tomcat .

A escolha da tecnologia depende de você e depende da linguagem de programação que você preferir usar, do ambiente de hospedagem disponível, requisitos de desempenho, opinião popular e modismos passageiros. O CGI, por exemplo, não tem sido favorecido ultimamente, uma vez que a necessidade de iniciar programas externos limita a escalabilidade.

Um servidor web é um programa escrito em qualquer linguagem de programação que lida com "tráfego da web" em soquete (s) aderente (s) a padrões / protocolos de nível de aplicativo (HTTP, etc). A maioria das linguagens de programação oferece a criação de um soquete.

Estou certo ao pensar que um servidor só precisa de algum tipo de interface, como CGI, para fazer o servidor e a linguagem de programação funcionarem juntos?

Não é necessário ter um programa de servidor dedicado e seu programa de aplicativo - eles podem ser os mesmos (desconsiderando quaisquer problemas relacionados ao desempenho).

Você pode usar alguma biblioteca de servidores HTTP , por exemplo, libonion , mesmo em seu programa codificado em C (ou C ++, consulte também Wt ). Há também alguma biblioteca cliente HTTP (por exemplo, libcurl )

Você pode usar outras bibliotecas HTTP, por exemplo, ocsigen e ocamlnet para OCaml .

Existem várias linguagens dedicadas à Web (fora do PHP), por exemplo, Opa , HOP , Kaya , etc ... (tanto o HOP quanto o Opa podem facilmente misturar cálculos do lado do servidor e do navegador, mas você deve fazer isso de maneira dolorosa e manual em PHP, explicitamente usando técnicas AJAX e codificando manualmente algum Javascript para o navegador.Por outro lado, HOP, Opa, Ocsigen são capazes de gerar esse Javascript).

Você também pode usar a tecnologia FASTCGI para adicionar algum serviço dinâmico a algum servidor Web ... O FASTCGI é melhor que o CGI antigo comum, que inicia um novo processo para cada solicitação HTTP recebida, enquanto um aplicativo FASTCGI pode atender a muitas solicitações HTTP no mesmo processo. BTW, o PHP pode ser configurado para funcionar como um aplicativo FASTCGI.

C.Queinnec observou que a navegação na web e as continuações estão significativamente relacionadas.

PS. Não gosto de PHP e acredito que sua popularidade tenha razões históricas e sociais (não principalmente técnicas). De fato, o PHP foi difundido muito antes do AJAX se tornar amplamente utilizado e é mais antigo que o HOP ou Opa (ou Ocsigen).