servidores php sem pilha apache / nginx / cgi

Question

Em muitos idiomas, você constrói frameworks web a partir do zero (ou seja, a partir de soquetes unix) e sobre abstrações. Se eu quiser construir um framework web do zero no OCaml ou C, eu primeiro construo um servidor de socket que escuta na porta 80.

Achei que o PHP - como qualquer outra linguagem de nível superior - provavelmente envolve de alguma forma os soquetes unix. Agora eu sei que é o caso que nunca foi assim que o PHP foi projetado. No entanto, não vejo por que nunca foi usado dessa maneira. Ao longo dessas mesmas linhas, o interpretador PHP nunca é usado dessa maneira, assim como o interpretador Python.

Por exemplo, quando eu construo um servidor web Python a partir do zero e o implanto, eu faço o seguinte: attacg um soquete unix em alguma porta (digamos 8000), daemonize meu script como python server.py 8000 e tenha nginx reverse proxy porta 80 e encaminhar para o meu servidor interno, local na porta 8000. Eu nunca vi isso feito em PHP, mesmo que seja possível.

Admito que você tem outras opções em Python além de usar o interpretador autônomo (ou seja, tornado, uwsgi, etc). No entanto, é feito nos dois sentidos.

A minha pergunta é, quais são os aspectos do PHP na linguagem, intérprete ou comunidade que impediram que os frameworks web PHP fossem construídos de raiz a partir de chamadas de socket unix, daemonizados numa porta local, e sendo reverse proxied em vez de usar um invólucro cgi / fastcgi?

    

Answer 1

Em uma palavra, história. Este é um resumo muito abreviado de mais de 15 anos de história (você pode encontrar mais informações na Internet, se estiver realmente interessado):

Primeiro, enquanto o PHP tem todos os recursos de uma linguagem de programação, isso nem sempre foi assim. Começou como um "pré-processador de hipertexto" cujo propósito era ser incorporado em páginas HTML e analisado por um programa CGI ou pelo servidor web em si. Era para ser executado por um servidor web existente, não para ser um servidor web. Em suas primeiras iterações, era uma linguagem muito simples (e alguns diriam que ainda é).

O PHP data do final dos anos 90, e a única maneira de um servidor web rodar conteúdo dinâmico era através do CGI . O grande problema do CGI, porém, era que ele era bastante lento, porque ele criava um novo processo para cada solicitação. Não é um grande negócio nos primeiros dias, mas quando o boom das pontocom atingiu, tornou-se algo de um problema. O PHP tornou-se popular o suficiente para ser incorporado ao Apache como um módulo carregável, que dava melhor desempenho que o CGI e oferecia outros benefícios .

Durante muito tempo, o PHP só era executável em uma dessas duas formas, mas desde que se tornou a linguagem com a maior parte do mercado, ninguém se importava muito. Embora, eventualmente, algumas pessoas quisessem usar servidores diferentes do Apache, e por algum tempo a CGI era a única maneira de fazer isso, até um FastCGI php-fpm (FastCGI Process Manager) foi eventualmente contribuída para o PHP. Ao contrário do CGI, o FastCGI mantém um conjunto de processos sempre em execução e pronto para atender a solicitações de entrada.

Nos anos 2000 surgiram outras linguagens, que fazem as coisas de maneira diferente. Por exemplo, em Ruby, as bibliotecas de aplicativos são enviadas em gems, e um programa pode ser facilmente criado simplesmente colando algumas gems existentes com a lógica de negócios. Rack é uma jóia Ruby que fornece uma API Ruby para construir servidores web, e servidores como mestiço, unicórnio, thin, etc., e frameworks como Rails e Sinatra, são construídos sobre ele.

Outros idiomas, como Python e Java, têm servidores da Web e estruturas de servidor da Web semelhantes. Como você pode ver, esta é uma abordagem completamente diferente da usada pelo PHP, que geralmente não usa HTTP para atender requisições.

No entanto, versões recentes do PHP agora têm um " construído em um servidor web ", mas é relativamente novo e só pode manipular uma conexão por vez, tornando-a inadequada para uso em produção. É explicitamente projetado para uso do desenvolvedor.

Em última análise, tudo se resume a isto: o PHP foi projetado para funcionar no contexto de um documento HTML existente, enquanto outras linguagens como Python, Ruby, Java, etc., são de propósito geral. A única outra linguagem da web que eu conheço que funciona como PHP a esse respeito é o ASP "clássico" da Microsoft , que tem um similar design.

    

Answer 2

Nada. Você pode usar qualquer idioma para escutar em qualquer porta e responder de volta dentro das regras de um protocolo (neste caso, HTTP ). Não há nada que diga que isso não é possível com PHP . Você poderia ligá-lo a soquetes, ou simplesmente ler e escrever em STDIN , STDOUT e ser iniciado a partir de xinet , ou até mesmo trabalhar com outro aplicativo como apache ou nginx que saiba um pouco mais sobre HTTP do que a maioria das pessoas deseja implementar por conta própria.