Ajude a entender os scripts do lado do servidor

Até onde eu entendi, existem basicamente três opções para a criação de scripts no servidor atualmente:

1. Usando linguagens de script que podem ser interpretadas / executadas diretamente pelo servidor da Web (por exemplo, PHP e ASP), onde os scripts são interpretados / executados em tempo real (ou seja, conforme as solicitações HTTP), a saída é incorporada às páginas HTML. enviado de volta para o cliente.

2. Usando qualquer linguagem (por exemplo, C, C ++, PERL, Python), o sistema operacional do servidor é capaz de executar (usando um intérprete ou o arquivo executável já compilado) e, em seguida, usar CGI para se comunicar entre o servidor da Web e o SO . A saída dos scripts vem via CGI para o servidor na forma de páginas HTML completas e é enviada de volta ao cliente.

3. Usando Java em um servidor que pode manipular servlets / JSPs, que é praticamente a mesma idéia da opção 1 acima, exceto usando Java em vez de PHP / ASP.

Perguntas :

1. O meu entendimento está até agora no caminho certo ou eu entendi algo errado?

2. ASP e PHP são os únicos idiomas que podem ser interpretados e executados diretamente por um servidor web?

3. Onde Ruby se enquadra na classificação acima? Pode ser interpretado / executado por servidores como PHP? Ou ele se comunica via CGI?

4. O script do lado do servidor via CGI está se tornando obsoleto ou não existe?

Seu entendimento está correto, se você é do passado. Você é bastante descrito como parecia nos anos 90.

Sim, muitos idiomas podem ser executados diretamente por um plug-in de servidor da web. No PHP, o mod_php para Apache ainda é a maneira mais popular de hospedá-lo. No entanto, sites de alto tráfego usam uma abordagem mais moderna, usando apenas um servidor Web como proxy para FastCGI (no caso de PHP, é PHP-FPM )

a saída é incorporada às páginas HTML e é enviada de volta ao cliente.

Eu acho que você está se referindo ao chamado código espaguete do início dos anos 90, no entanto, a abordagem moderna é usar uma das muitas estruturas MVC. No caso do PHP, isso significaria, por exemplo, o Zend Framework (existem inúmeras alternativas).

Quanto ao ASP, você provavelmente está se referindo ao chamado "ASP clássico", que é obsoleto. Atualmente, é o ASP.NET, que pode usar qualquer uma das linguagens .NET (sendo C # a mais popular) e, claro, a estrutura .NET.

C e C ++ normalmente não são usados ​​para aplicativos da web. Nesse caso, esses serviços são implementados como servidores independentes, como módulo para servidor da web ou como FastCGI .

O Perl pode ser executado diretamente do módulo de serviço da web usando mod_perl . Há também o PSGI , que é basicamente o clone do WSGI do Python .

Python é uma linguagem muito popular para aplicativos da web. Ele pode ser executado diretamente no servidor da web Apache via mod_python, no entanto, isso é obsoleto e não é recomendado. Atualmente, o caminho a seguir com o Python é via módulo do servidor WSGI . Servidor WSGI implementado em Python (por exemplo, CherryPy, WebPy) ou usando a pilha da Web independente do Python (o Tornado e o módulo da Web do Twisted são bons exemplos). E, claro, novamente, você provavelmente usará o framework MVC compatível com WSGI , o Django é o mais popular (novamente, várias alternativas disponíveis).

Ruby, novamente linguagem muito popular para aplicativos da web. Mais conhecido pelo framework Web Ruby on Rails, que novamente é MVC. Você pode executar o Ruby diretamente do módulo do servidor via mod_ruby ou via FastCGI .

Servlets / JSP são executados em servidores de aplicativos J2EE independentes, como JBoss ou Tomcat. É mais comumente usado para adicionar interface da web ao sistema comercial, em vez de criar aplicativos da web independentes.

O CGI clássico (ou seja, processo de desova em cada solicitação) tornou-se obsoleto há muitos anos. Ele foi substituído pelo FastCGI (onde o processo é demorado, e não gerado a cada solicitação), módulos de servidor, interfaces como WSGI e clones e soluções independentes.

Também o paradigma do processamento de solicitações evoluiu, com o CGI foi processado por solicitação. Em seguida, havia um pool de processos (ou pool de threads), cada processo (thread) manipulando uma solicitação por vez. No entanto, agora, a abordagem mais moderna é para servidores da Web e estruturas independentes usarem programação orientada a eventos.

Permitam-me que anteceda isso dizendo que essa é uma visão extremamente genérica e simplificada do que acontece.

O software de servidor da Web (como Apache ou IIS) não interpreta nenhum código; não sabe como. Tudo o que sabe fazer é aceitar uma solicitação, procurar em algum local no sistema de arquivos e enviar o item solicitado de volta ao navegador. É tudo o que faz - em um nível muito simples. É por isso que quando você instala o Apache e adiciona algum arquivo php ao arquivo DocumentRoot, você não obtém o resultado do PHP executado; apenas o arquivo de volta.

A primeira etapa para conseguir que o servidor faça algo diferente de servir arquivos é adicionar código que o instrua a fazer outra coisa quando um arquivo específico for solicitado; caso contrário, tudo o que fará é tentar servir o arquivo de acordo com seu tipo mime padrão (que geralmente é texto / sem formatação). É por isso que, quando você tem um servidor configurado incorretamente e solicita index.php, vê o código-fonte do arquivo em vez do resultado pretendido.

Portanto, para que um servidor da Web "entenda" o PHP, é necessário dizer o que fazer quando uma solicitação de arquivo com a .phpextensão chegar. É aqui que mod_phpentra. Este módulo transfere a solicitação para um intérprete PHP (como isso pode ser configurado), que depois lê o arquivo, executa o código, compila os resultados; e envia os resultados de volta ao servidor, que, por sua vez, entrega os resultados ao cliente. Em seguida, você configura o servidor da web para que todos os arquivos que possuem .php no final sejam manipulados por mod_php.

Esse fluxo de trabalho básico também é aplicado com outros idiomas; a única diferença é para o que o servidor 'descarrega' a solicitação.

O caso de PHP é explicado acima, não é semelhante mod_python, e fastcgi, wsgie outros protocolos estabelecidos sobre os pedidos de descarregamento que um servidor web não é projetado para lidar.

As implementações mais comuns têm um processo de execução longa que aguarda uma solicitação em uma porta (ou soquete) específica. O servidor da Web é então configurado como um proxy , para que transmita quaisquer solicitações que correspondam a um padrão específico para esse processo de longa execução e, em seguida, leia os resultados novamente.

É assim que o ruby ​​on rails (rack), scripts python (com wsgi) funcionam.

É também por isso que servidores da Web simples como proxy, como o nginx, são muito populares. Eles executam apenas as tarefas básicas de um servidor da Web tradicional - servem os arquivos "estáticos" e são muito bons em descarregar solicitações para outros servidores proxy para lidar com coisas como PHP, Python, ASP, et. al.

Então, no final, você tem o servidor da Web - que cuida dos arquivos estáticos, qualquer coisa que não precise de processamento.

Você tem outro processo, que sabe lidar com seu código (por exemplo, um processo que executa o intérprete PHP ou um servidor uWSGI). Isso fica e aguarda solicitações do servidor da web.

Por fim, você tem sistemas como upstart e supervisor que gerenciam esses processos para você.

Espero que isso esclareça o assunto.

Existe uma quarta opção, que é usada da forma mais 'séria'; sites como bancos ou outros serviços financeiros: a abordagem de n camadas que se parece um pouco com CGI, exceto que o processo de CGI é executado em um servidor diferente, o código do servidor da Web é muito pequeno (apenas o suficiente para reformatar os dados em html) e chama o ' serviços da cgi por meio de protocolos de rede como RPC ou SOAP.

Ainda é a mesma abordagem básica que usa um servidor da Web como um gateway entre a solicitação http feita pelo navegador do cliente e um 'mecanismo de código' que hospeda a lógica de negócios. Observe que, nesse caso, o servidor da Web passará a solicitação para um mecanismo de script em um idioma (por exemplo, PHP ou XSLT) que, por sua vez, chama outro serviço que fornece dados brutos, o script da Web é usado apenas para formatar esses dados no html página entregue ao navegador.