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

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

O CGI trabalha coletando um monte de informações no ambiente do processo que é bifurcado e, em seguida, executado (e possivelmente algum em stdin) e então pega o que sai do stdout e retorna ao solicitante.

Isso não importa nem um pouco sobre o que é a linguagem de implementação. De fato, escrevi meus primeiros CGIs no passado em C ou C ++. Foi meio doloroso. Mais tarde eu aprendi um pouco de 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 é um fork e exec de um processo. Milhares de solicitações significam milhares de processos. Isso realmente não funciona bem.

A solução para isso é remover bifurcações e execuções movendo-as para um encadeamento no próprio servidor da Web ou despachando a solicitação para outro processo que lide com a solicitação sem precisar bifurcar-se e exec. O mod_perl é uma dessas ferramentas para fazer isso (um plugin que move o perl para o apache). Php (final dos anos 90) também fez isso com a implementação da linguagem como um plugin no próprio servidor web, em vez de algo que foi bifurcado e excedido. Isso se tornou bastante popular, já que era perl-like (que era a linguagem dominante de programação web dominante) e poderia superar perl cgis. Ainda há um bom momento nesse período em meados dos anos 90 - antes que os servidores de aplicativos mais corporativos começassem a se apropriar de linguagens mais formais por trás deles. Se você pesquisar, pode encontrar muitas tentativas fracassadas no final dos anos 90 até o início dos anos 2000 também - linguagens e frameworks que simplesmente não funcionavam.

Isso nos leva aos servidores de aplicativos em que os encadeamentos internos são gerados (ou outras abordagens - não é o caso de tudo) para lidar com solicitações em vez de novos processos inteiros - o que pode ajudar com a escala. Como um processo externo, isso pode ser visto com o FastCGI e depois se tornou predominante com outros servidores de aplicativos. Observe que, com isso, a linha entre o servidor de aplicativos e o servidor da Web ficou um pouco borrada - muitos servidores de aplicativos podem funcionar como servidores da Web, embora não tenham sido otimizados para lidar com E / S de arquivos estáticos.

O servidor de aplicativos genéricos também abriu o caminho para as soluções em que, em vez de um servidor de aplicativos genérico , você tem o próprio aplicativo executando um servidor da Web incorporado ou sendo a implantação inteira. Em tais situações, não é implantado um aplicativo da Web em um servidor de aplicativos - ele apenas está sendo executado e manipulando solicitações. Novamente, o objetivo desse modelo é evitar o alto preço de lançar novas instâncias do aplicativo e, em vez disso, manipular as solicitações dentro do aplicativo com threads muito mais leves ou abordagens semelhantes.

Aqui está a questão - todas as soluções são deficientes de alguma forma ou forma. CGI, enquanto fácil tem sérios problemas com 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, não prefere continuar programando em vez de ter diferentes idiomas em diferentes partes da pilha (javascript no cliente e Node.js)?

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

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

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

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

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

• É extremamente fácil fazer upgrade de um site estático para um site dinâmico do PHP - basta substituir a extensão de arquivo do arquivo HTML, colocar a tag <?php no início e, desde que o PHP esteja instalado, você tenha uma dinâmica local na rede Internet! O restante do fluxo de trabalho é exatamente o mesmo de um site estático;
• Devido a essa facilidade de implantação, os hosts da Web que buscavam propor sites dinâmicos escolheram o PHP, tornando-o rapidamente a plataforma do servidor mais amplamente implantada;
• Entrou nesse mercado no momento certo;

E uma vez que o PHP foi amplamente implementado, tornou-se interessante escrever aplicativos web mais sérios no PHP, a fim de se beneficiar dessa amplitude de implementação.

Para dizer de uma forma mais genérica: a adoção de idiomas geralmente é sobre as respostas a essas perguntas:

• Quão fácil é fazer o que eu quero fazer?
• Qual o grau de suporte da linguagem para o que eu quero fazer?

Am I right in thinking that a server just needs some kind of interface such as CGI to make the server and the programming language work together?

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

Pense em como uma página estática é veiculada. O servidor recupera a solicitação HTTP, localiza o documento solicitado a partir 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 os 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 para o cliente, em vez de simplesmente entregar o documento estático.

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

A antiga estrutura CGI não se adapta bem a um grande volume de solicitações. Diferentes linguagens de programação e frameworks para a web existem por diferentes razões, e cada um faz coisas diferentes também. O PHP é tão popular quanto é por razões históricas, já que 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 eram codificadores de VB, mudar para a web.

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

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

… para o qual o servidor deve enviar uma resposta assim:

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 ouça solicitações em um soquete TCP, leia a solicitação e responda com a resposta apropriada. Uma maneira estúpida é simplesmente cuspir uma resposta enlatada para qualquer um que se conecte à 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

É claro que essa técnica mal parece estar de acordo com o protocolo HTTP .

Um passo acima dessa resposta enlatada é esse programa Python simples, que usa o http.server em 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ê poderia adicionar código para gerar respostas significativas com base na solicitação, mas o código ficaria muito complexo. Além disso, os programadores prefeririam se concentrar em escrever o aplicativo da Web, não precisando 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 o Apache HTTPD , IIS ou nginx . Um servidor da Web é apenas um programa que escuta os 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. O ideal é que muitos dos detalhes, como SSL, controle de acesso e limites de recursos, sejam atendidos por meio de configuração em vez de código. Na maioria das vezes, o servidor web formulará uma resposta que consiste apenas em conteúdo de arquivos no sistema de arquivos.

Para conteúdo dinâmico, no entanto, 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 para o soquete TCP. Uma solução um pouco mais sofisticada seria ter um módulo que adiciona suporte ao servidor web para chamar o código em outra linguagem de programação (por exemplo, mod_php para o Apache ). Outra opção é escrever o servidor da Web no mesmo idioma que o aplicativo da Web. Nesse caso, o despacho de solicitação é apenas uma chamada de função. Esse é o caso dos node.js e dos mecanismos de servlet Java, como 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, dos requisitos de desempenho, da opinião popular e das modas passageiras. O CGI, por exemplo, não tem sido preferido ultimamente, já que a necessidade de lançar programas externos limita a escalabilidade.

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

Am I right in thinking that a server just needs some kind of interface such as CGI to make the server and the programming language work together?

Não há necessidade de ter um programa de servidor dedicado e seu programa de aplicativo - eles podem ser o mesmo (desconsiderando qualquer problema relacionado ao desempenho).

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

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

Existem várias linguagens dedicadas à Web (fora do PHP), por ex. Opa , HOP , Kaya , etc ... (tanto o HOP quanto o Opa podem facilmente misturar cálculos no lado do servidor e do lado do navegador, mas você tem que fazer isso de maneira dolorosa e manual em PHP, < em> explicitamente usando AJAX técnicas e codificação manual de algumas Javascript para o navegador. Em contraste , 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 ... FASTCGI é melhor que simples antiga CGI 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 uma aplicação FASTCGI.

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

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