Introdução

Neste artigo, discutiremos sobre o Apache e suas novidades para a próxima versão por entender que existe escassez de material sobre o assunto por aqui e pouca divulgação do tema, o que compõe um quadro paradoxal e incompatível com a realidade de sua adoção e envergadura aqui no Brasil e no mundo.

Voltando ainda mais um pouco, para os menos avisados, Apache é o servidor Web (por enquanto somente Web, vem novidades por aí) mais usado no mundo, tem cerca de 60 % do mercado contra 20 % do IIS da Microsoft, o resto esta pulverizado entre outros Sun/Netscape/AOL, etc. Estes são dados do site Netcraft.com, especializado em pesquisas do tipo. De acordo com esta pesquisa, desde de abril de 1996 o Apache é o líder em servidores Web.

O Apache é um projeto de esforço de desenvolvimento colaborativo com objetivo de desenvolver o melhor servidor Web em performance, robustez, flexibilidade e com padrões de excelência e qualidade. Tem em seu grupo de trabalho programadores das Universidades MIT, Berkeley, Stanford, e empresas como IBM, Sun, HP, Compaq, RedHat entre diversas outras.

Entre suas principais características está multiplataforma, robustez, performance, adatpatabilidade, gratuidade e boa documentação. Ele tem vantagens em cima dos outros servidores, como código fonte completo e uma licença irrestrita. É compatível com a especificação HTTP/1.1, permite mudanças em suas características (flexibilidade) mesmo em suas partes mais internas (core) através da utilização de módulos, e tem sua própria API padronizando toda programação interna.

Vou dividir o artigo em algumas partes: considerações gerais, portabilidade, novo modelo de gerenciamento de memória, filtros, logs com pipes, outros protocolos e CGIs. Vou tentar dar independência entre as partes para que fique mais fácil a leitura e caso deseje-se ler uma parte isolada seja possível.

Panorama Geral

Na versão 1.3 o Apache sofre de alguns problemas como todo software. Apesar de ser bastante leve e robusto, em algumas plataformas no quesito escalabilidade ele deixa a desejar, como por exemplo AIX e Windows. No AIX quando você começa a escalar carga na casa de centenas e milhares de requisições por segundo, mesmo evoluindo com a máquina ele não acompanha. Já no Windows, no contexto geral seu desempenho é sofrível. Ou seja, algo deve ser feito para essas plataformas.

Além disso, com a evolução da Web novas funcionalidades se fazem necessárias, como mais confiabilidade, melhor segurança e como sempre, mais performance. Com o Apache não é diferente, e para se manter líder ele também deve evoluir. Com esta versão ele tende a se tornar o mais robusto e rápido servidor Web do mercado.

Citando por alto algumas mudanças:

• Unix Threading: O Apache agora em sistemas com padronização POSIX para Threads pode rodar em modos híbridos Multi-Processos/Multi-Threads. Isso melhora a escalabilidade.
• Novo Sistema de Compilação: O sistema de compilação foi totalmente refeito, do zero, e utilizará libtool/autconf. Isso o torna mais parecido com outros pacotes, ponto para padronização.
• Suporte a múltiplos protocolos: Internamente terá mecanismos para servir outros tipo de protocolos, além do HTTP tradicional. Deixará de ser um servidor Web para ser um servidor de "infra-estrutura".
• Melhor suporte para outra plataformas não-Unix: Nesta versão 2.0 o Apache é mais rápido e estável em versões não-Unix, como no BeOS, OS/2 e Windows. Com a introdução da arquitetura de módulos específicos para plataformas diferenciadas (MPMs ? Multi-Processing Modules). Também temos o APR (Apache Portable Runtime), que possibilita a implementação na API nativa de cada sistema, evitando ter que se usar camadas emuladas para simular padronizações do tipo POSIX.
• Nova API: Muitos dos problemas da API antiga foram solucionadas e muita coisa automatizada. Agora temos mais fases e por chamada podemos fazer nossos módulos, diferente da estrutura rígida da versão 1.3. Não é mais necessário alguns malabarismos ou patches no próprio servidor, está mais flexível. Depois falo de como migrar entre versões e entro em detalhes. Além disso, mais enxuto, menos redundante e menos gastador de memória não necessária.
• Suporte ao IPv6: Em sistemas que tenham IPv6 (pela APR), o Apache automaticamente responde com tal protocolo para todas suas conexões. Todas as características de Hosts Virtuais e derivativas já funcionam com o protocolo.
• Filtros: Módulos para Apache podem ser escritos como filtros, trabalhando direto no fluxo de conteúdo que seria entregue para o usuário. Isso possibilita, por exemplo, a saída de um script CGI ser parseado por algo como mod_SSI (Server Side Include). Uma das principais mudanças desta nova versão.
• Método de configuração: Na versão 1.3 na inicialização cada linha era lida por vez e interpretada. Agora o servidor lê toda configuração e cria uma árvore, depois disso a árvore é percorrida e cada diretiva é executada. Isso permite algumas contextualizações no arquivo de configuração, de módulos que mudem o comportamento de outros que já tenham sido lidos. Flexibiliza o servidor na hora da inicialização, é uma feature bastante focada e menos prática para os usuários.

Portabilidade - MPMs (multi-processing modules)

Essa talvez tenha sido uma das grandes mudanças nessa versão, não desconsiderando as outras nem querendo ser simplista. Basicamente, o servidor 1.3 trabalhava com o modelo de pré-fork, o que seria isso? É inicializado um processo pai que da fork criando n processos filhos. Esses processos filhos são os responsáveis por cuidar e responder as requisições vinda dos clientes. Dependendo do número de requisições, mais cópias de filhos são criadas. O processo pai fica supervisionando o funcionamento dos seus filhos e vendo se tudo corre bem. Ele controla a quantidade de filhos que estão a disposição de forma a regular o número de filhos / requisições, para que na maior quantidade de tempo possível, se tenha filhos disponíveis para atender as requisições. Através de diretivas o administrador configura tais parâmetros, que é proporcional com a quantidade de memória disponível na máquina. Atividades de servir Web é gastadora intensiva de memória, e atividades de swap são onerosas demais e praticamente inviabilizam o funcionamento do servidor de forma desejável. O Apache sempre tenta deixar alguns processos ociosos, esperando por conexões, além dos que estão servindo as requisições atuais. Isso garante que ele tenha sempre uma sobra de processos caso aumente o número de requisições por intervalo de tempo, e não faz com que ele tenha que criar (fork) de outro processo naquele instante, fazendo com que o usuário espere a criação do processo.

Esse modelo trabalho bem na maioria dos Unix, principalmente no Linux. O Linux é o sistema conhecido como o sistema com mais rápidas chamadas de sistemas existentes, criar processos para ele é bastante natural e quase instantâneo. Ele foi desenhado para isso. Já no Windows não, e para sua versão foi utilizado da idéia de através do primeiro processo criado, criar vários threads. O Windows é baseado em threads, que tem compartilhamento de memória, entre outras características.

Junta-se a essa variação, múltiplas plataformas com diferenciações de código até para otimização (o Apache é conhecido como sendo o mais otimizado dos servidores, seus desenvolvedores tiram da última gota de suor, lugar para melhorar e aumentar sua velocidade), obtêm-se um código bastante alargado e poluído, com milhares de #ifdefs espalhados (diretivas de compilação para variação de código na hora da compilação, para o não-programador). Com essas tantas condicionais de compilação, fazer a manutenção no código ficou bastante difícil e mesmo adicionar novas plataformas ou mesmo diferenciação entre versões da mesma plataforma, fica lento e a longo prazo inviável (mais embaixo apr).

Com a evolução das discussões sobre a versão 2.0, um ponto ficou bastante claro: a decisão de rodar o Apache em todas as plataformas com igualdade de preferência e possibilidades. No Windows ele teria que funcionar bem, tão bem quanto nos Unix e adicionar uma nova plataforma teria que ser mais simples, principalmente para o desenvolvedor da plataforma. Como se pode notar pelo relato, o código no mesmo lugar seria inviável e difícil de manter, decidiu-se criar uma nova camada de abstração. O MPM (Multi-Processing Modules). O MPM teria que mapear requisições dentro de primitivas básicas. Atrás destas teria-se o modo como ela seria tratada, se com processo, thread, ou seja lá o que queiram inventar. Ficaria a cargo de cada desenvolvedor decidir como fazer isso na sua plataforma.

Essa abstração dos MPMs criou uma nova possibilidade: a adaptação do servidor a necessidade do Administrador. Temos MPMs conhecidos nos Unix: pré-fork, pthread e dexter. O prefork é exatamente o que acontece com a versão 1.3 e é bastante adequado para sistemas como Linux, como já disse (rápidos com processos). O Pthread é um híbrido entre threads e processos. Ele primeiro cria (fork) vários processos filhos e depois para cada filho cria um certo número de threads por filhos. O número de threads por processos é fixo, ou seja, o número de requisições também é fixo. É ajustável pelo número de filhos. Tal módulo é indicado para plataformas que tem suporte a threads e tem problemas de memória em sua implementação. Já o Dexter cria vários processos (fixos) e um conjunto de threads por processo, mas dependendo da quantidade de requisições que vem por servidor, ele acomoda os números e cria ou destrói threads. É indicado para plataformas mais modernas com bom suporte a threads. Temos também para o Windows NT da Microsoft o WINNT_MPM. Ele é a padrão para o NT e trabalha com um processo pai e vários threads. É muitíssimo melhor que o suporte atual (1.3) para tal plataforma.