sexta-feira, 27 de setembro de 2013

Habilitando e configurando Cache no Apache (mod_expires)

Olá a todos, no nosso último post, ensinamos como configurar a compressão da resposta do servidor aos usuários, diminuindo bastante o conteúdo de textos, como html, css e javascript. Desta vez o post será para ensinarmos o melhor jeito de se implementar o gerenciamento de cache, fazendo com que os navegadores guardem certos arquivos por uma data especificada pelo servidor, evitando assim um enorme tráfego de rede desnecessário e aumentando muito a velocidade de carregamento da página.

Aproveitar a funcionalidade de cache dos navegadores consiste em definir uma data de validade nos cabeçalhos HTTP para recursos estáticos, instruindo o navegador a carregar os recursos baixados anteriormente a partir do disco local, não através da rede.

Todo administrador de redes, sabe que a tendência é que os sites sejam cada vez mais dinâmicos e ricos em conteúdo, mas toda essa interatividade e riqueza de conteúdo tem um preço, alto tráfego de rede. Quando alguém acessa o seu site, diversos arquivos são baixados, como textos, imagens, css, javascripts. Para impedir todos esses downloads novamente é que surge a necessidade de se gerenciar o cache dos usuários.

Indice

  • O que é cache de navegador?
  • Formas erradas de se implementar o cache de navegador
  • Forma correta de se implementar o cache de navegador
  • Habilitando mod_expires e mod_headers no Apache
  • Testando a Configuração
  • Conclusão

O que é cache de navegador?

Antes de falarmos sobre as configurações do apache, devemos entender bem o que é e como funciona o cache de arquivos pelo navegador. Pois bem, sempre que um usuário acessa o seu site, todo o conteúdo disponível na página acessada pelo usuário, tais como imagens, arquivos css, arquivos javascript, arquivos xml e etc é baixado para o seu computador, permanecendo em uma pasta no seu disco rígido. Assim, quando o usuário entrar no seu site novamente, ele poderá ou não baixar todo o conteúdo novamente, vai depender das configurações de cache do navegador dele, e do seu servidor http.

Então cache é o ato de salvar os dados em um local para rápido acesso, não precisando ir buscá-lo na fonte original (servidor http). Assim sendo, a partir do primeiro acesso podemos instruir o navegador a guardar estes arquivos no disco rígido do usuário, e também podemos definir o tempo que este arquivo ficará armazenado. Assim, quando o usuário acessar o seu site novamente ou navegar por outras páginas, ao invés de precisar baixar toda a página novamente, o navegador será instruído a buscar os conteúdos diretamente do Cache. Caso ele não tenha algo no Cache ou o tempo de permanência tenha expirado, é solicitado o arquivo em questão ao servidor do site.

Note que é imensamente mais rápido buscar conteúdo do cache, do que em servidores http, que geralmente se encontram em outros países e podem inclusive estar ocupados.

Formas erradas de se implementar o cache de navegador

Uma forma bem comum de tentar fazer isso, porém extremamente inconsistente, é usar as Meta Tags Expires, Pragma e Cache-control no cabeçalho do documento, na tentativa de determinar a data e a hora em que a página expira e que os dados desta devem ser armazenados.

 <!doctype html>  
 <html dir="ltr" lang="pt-BR">  
 <head>  
 <title>Lorindo.com</title>  
 <meta http-equiv="expires" content="Tue, 05 Jan 2013 12:12:12 GMT">  
 <meta http-equiv="cache-control" content="public" /> <!-- reconhecida pelo HTTP 1.1 -->  
 <meta http-equiv="Pragma" content="public"> <!-- reconhecida por todas as versões do HTTP -->  

Ou então gerar cabeçalhos HTTP apartir de linguagens server-side, como o PHP ou Java.

 <?php  
 header("Cache-Control: private, max-age=10800, pre-check=10800");  
 header("Pragma: private");  
 header("Expires: " . date(DATE_RFC822,strtotime("30 day")));  
 ?>  

Esses métodos podem até ser muito simples de serem implementados, talvez por isso sejam tão usados, porém já estão obsoletos. Até mesmo, porque é muito mais simples configurar apenas um arquivo no servidor, do que configurar cada página separada.

Forma correta de se implementar o cache de navegador

A forma correta de se implementar e configurar o cache do navegador, é adicionando configurações no arquivo httpd.conf do apache, desta forma é possível especificar uma data de expiração para arquivos de imagem, javascript, css, mídias, pdf, flash e demais arquivos servidos pelo site.

Fazendo uma simples configuração, você consegue diminuir muito o tempo de carregamento da sua página web, garantindo uma melhor performance e experiência para os seus usuários.

Existem duas formas de se realizar Cache de navegador pelo servidor http:

  1. Cabeçalho Expires: Com o cabeçalho expires é possível determinar a expiração de um arquivo, colocando-o assim em Cache. Ele deve ser utilizado para navegadores que utilizam o protocolo HTTP 1.0 para a comunicação com o servidor.
  2. Cabeçalho Cache-Control: Com o cabeçalho Cache-Control é possível determinar a expiração de um arquivo, colocando-o assim em Cache. Além disso é possível determinar vários parâmetros adicionais, como tornar o Cache público ou privado. Ele deve ser utilizado para navegadores que utilizam o protocolo HTTP 1.1 para a comunicação com o servidor.

Após essa explicação das duas formas de controlar o cache, a dúvida geralmente é sobre qual modo deve ser usado. Pois saibam que o correto é usar os dois, definidos com os mesmos tempos de expiração, pois o navegador que trabalhar com o protocolo HTTP 1.0 utilizará o Expires, já os navegadores modernos que trabalharem com o HTTP 1.1, utilizarão o Cache-Control.

Habilitando mod_expires e mod_headers no Apache

A primeira coisa a ser feita para que o mod_expires e o mod_headers possam ser configurados, é habilitá-los no arquivo httpd.conf, conforme figura 1 abaixo.

apache-windows-hablitando-mod-headers-mod-expires-httpd.conf
Figura 1 - Habilitando o mod_expires e mod_headers no arquivo httpd.conf

Após habilitar o mod_expires e o mod_headers, podemos começar enfim a configurá-los para que nossos clientes armazenem em cache o conteúdo estático do nosso site.


Configurando o mod_expires no Apache

O mod_expires possui três diretivas principais, e são elas:

  • ExpiresActive: Setando o valor desta diretiva para "on", permitimos que o apache faça o controle de cache nos cabeçalhos http.
  • ExpiresDefault: Esta diferiva configura o tempo padrão de expiração para todos os tipos de arquivos, no exemplo abaixo está configurado para 1 dia.
  • ExpiresByType: Esta diretiva permite definir o tipo de arquivo que receberá determinado tempo de expiração. O tempo de expiração pode ser informado em segundos, minutos, horas, dias, semanas, meses e anos, sempre respeitando as regras de sintaxe corretas.

Segue abaixo um exemplo de configuração para os principais tipos de arquivos servidos em um site.

<IfModule mod_expires.c>
    ExpiresActive on
    ExpiresDefault "access plus 1 day"
    ExpiresByType text/cache-manifest "access plus 0 seconds"
    # Html
    ExpiresByType text/html "access plus 0 seconds"
    # Dados
    ExpiresByType text/xml "access plus 0 seconds"
    ExpiresByType application/xml "access plus 0 seconds"
    ExpiresByType application/json "access plus 0 seconds"
    # Feed
    ExpiresByType application/rss+xml "access plus 1 hour"
    ExpiresByType application/atom+xml "access plus 1 hour"
    # Favicon
    ExpiresByType image/x-icon "access plus 1 week"
    # Midia: images, video, audio
    ExpiresByType image/gif "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/jpg "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"
    ExpiresByType video/ogg "access plus 1 month"
    ExpiresByType audio/ogg "access plus 1 month"
    ExpiresByType video/mp4 "access plus 1 month"
    ExpiresByType video/webm "access plus 1 month"
    # Arquivos htc
    ExpiresByType text/x-component "access plus 1 month"
    # fonts
    ExpiresByType application/x-font-ttf "access plus 1 month"
    ExpiresByType font/opentype "access plus 1 month"
    ExpiresByType application/x-font-woff "access plus 1 month"
    ExpiresByType image/svg+xml "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
    # css / javascript
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType application/x-javascript  "access plus 1 year"

    # Desativar cache para o arquivo index.php
    <FilesMatch "index\.php$">
        ExpiresActive Off
    </FilesMatch>

</IfModule>

Configurando o mod_headers no Apache

o mod_headers permite entre outras coisas a configurar o cache-control. A função do Cache-Control (mod_headers) é exatamente a mesma do Expires, determinar o tempo de expiração para qualquer tipo de arquivo porém definindo o tempo em segundos, e ainda determinar o tipo do cache, se ele será público, privado e etc. Apenas navegadores modernos reconhecem o cabeçalho Cache-Control.

O Cache-Control pode receber até 7 informações (separadas por vírgula):

  • max-age: A informação mais importante. Com ela definimos em segundos o tempo de expiração.
  • tipo de cache: "public" ou "private". A diferença entre eles é a seguinte: vamos imaginar que o seu ISP tenha um proxy invisível entre você e a Internet, que esteja fazendo cache de páginas web para reduzir o tráfego necessário e consequentemente os custos operacionais. Usando "cache-control: private", você está especificando que o ISP não deveria realizar o cache da página, mas permitindo que o cliente o faça. Se você setar o "cache-control: public", você está informando que qualquer um poderá fazer o cache da página servida, inclusive seu ISP.
  • no-cache: Apesar desta diretiva parecer que está instruindo o navegador que não faça cache da página, há uma diferença sutil. A diretiva "no-cache", de acordo com o RFC, diz ao navegador que ele deveria revalidar com o servidor antes de servir a página a partir do cache. Revalidar é a técnica que deixa a aplicação conserver tráfego de rede. Se a página que o navegador tem em cache não mudou, o servidor apenas sinaliza que o navegador pode servir a página do cache. Assim na teoria pelo menos, o navegador deveria armazenar a página em cache, mas exibí-la a partir do cache somente com revalidação do servidor. Porém alguns navegadores ignoram essa indicação e implementaram para esta diretiva, o mesmo comportamento da diretiva "no-store" explicada abaixo.
  • no-store: Esta é a diretiva "cache-control" mais segura. Ela diz ao navegador para não realiar o cache da página. Sempre que estiver servindo uma página com informações confidenciais, esta diretiva deverá ser usada. Perceba que a diretiva "cache-control: no-cache" também tenha passado a se comportar dessa forma, é mais seguro usar ambas as diretivas, "no-cache" e "no-store".
  • must-revalidate: Esta diretiva insiste que o navegador deve revalidar a página contra o servidor antes de serví-la a partir do cache. Note que implicitamente ela deixa o navegador realizar o cache da página. A diretiva "no-store" é uma opção mais segura se você quiser servir uma página com informações sensíeis sem que ela fique salva em cache.
  • proxy-revalidate: Esta diretiva é similar à "must-revalidate", exceto que ela objetiva servidores proxy. Ela diz que servidores proxy devem revalidar com o servidor quando servindo esta requisição, enquanto o navegador do usuário não necessita revalidar. Esta diretiva é útil quando cache de uma página autenticada está sendo feito pelo navegador. Você não quer que o servidor proxy tenha uma cópia em cache das suas informações confidenciais.

Abaixo segue alguns exemplos de como configurar o mod_headers

<IfModule mod_headers.c>
    # Cache-Control de 4 horas (14400 segundos) de tipo público
    <FilesMatch "\.(jpg|jpeg|png|gif|ico|css|js)$">
        Header set Cache-Control "max-age=14400, public"
    </FilesMatch>

    # Desativar cache para o arquivo index.php
    # O cabeçalho "pragma" é para compatibilidade com o IE
    <FilesMatch "index\.php$">
        Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
        Header set Pragma "no-cache"
    </FilesMatch>
</IfModule>

Por fim ainda temos as Entity tags (ETags) que são um tipo de mecanismo feito para checar se existe uma nova versão do arquivo em cache. Com esse mecanismo desabilitado, nós impedimos que o cache ou o browser fiquem tentando fazer a validação. Para desabilitar o ETag, apenas acrescente no mod_headers o seguinte: Header unset ETag, FileETag None e Header unset Last-Modified.

O mod_headers ficará conforme abaixo:

<IfModule mod_headers.c>
    # Cache-Control de 4 horas (14400 segundos) de tipo público
    <FilesMatch "\.(jpg|jpeg|png|gif|ico|css|js)$">
        Header set Cache-Control "max-age=14400, public"
    </FilesMatch>

    # Desativar cache para o arquivo index.php
    # O cabeçalho "pragma" é para compatibilidade com o IE
    <FilesMatch "index\.php$">
        Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
        Header set Pragma "no-cache"
    </FilesMatch>
    Header unset Etag
    FileETag None
    Header unset Last-Modified
</IfModule>

Lembrando que todas essas configurações devem ficar no arquivo httpd.conf ou dentro de algum bloco virtualhost.

Testando a configuração

Para testar a configuração, e comparar os cabeçalhos enviados pelo servidor, disponibilizo aqui, o conteúdo do meu arquivo hosts, e aqui o coteúdo do meu arquivo httpd-vhosts.conf. Com essa configuração vai ficar bem simples de podermos testar as nossas configurações.

A configuração disponibilizada serve no caso de algum de vocês desejarem realizar os testes e verificarem os resultados. Pois bem, vamos aos passos necessários para testar:

  • Passo 1: Colocar a configuração do servidor de acordo com a já disponibilizada.
  • Passo 2: Iniciar o serviço do Apache.
  • Passo 3: Acessar o domínio: http://www.exemplo.com. Em seguida abrir o painel de ferramentas do desenvolvedor no chrome ou firefox (F12). Abrir a aba "Network", clicar no item que aparecer na listagem, conforme figura 3 abaixo. Observar o conteúdo do response header.
  • Passo 4: Acessar o domínio: http://www.outroexemplo.com. Em seguida abrir o painel de ferramentas do desenvolvedor no chrome ou firefox (F12). Abrir a aba "Network", clicar no item que aparecer na listagem, conforme figura 4 abaixo. Observar o conteúdo do response header.

apache-windows-habilitando-cache-navegador-resultado-com-cache.png
Figura 3 - Resultado do cabeçalho de resposta com o cache habilitado

apache-windows-habilitando-cache-navegador-resultado-sem-cache.png
Figura 4 - Resultado do cabeçalho de resposta sem o cache habilitado

Conclusão

Habilitar o cache de navegador pelo servidor é muito importante, pois evita download desnecessários, diminuindo tráfego de rede e melhorando em muito a experiência do usuário ao acessar o seu site.

quinta-feira, 26 de setembro de 2013

Configurando compactação de conteúdo no Apache (mod_deflate)

No nosso último post falamos sobre as configurações de servidores virtuais no Apache. Nesta postagem, vamos falar sobre algo muito importante que é a compactação de conteúdo do servidor para que seja então enviado aos clientes.

Durante a navegação na internet todos nós já nos deparamos com páginas pesadas, que demoram bastante tempo para carregar. É certo que nem sempre a culpa é do código html da página, podendo ser da infraestrutura. O importante a ser notado é que lentidão na internet é muito estressante, e caso seu site esteja lento, saiba que seus visitantes tendem a não retornar mais a ele. Outro ponto a ser considerado é o tráfego de rede, podendo ser muito intenso, no caso de sites ou aplicações web com número grande de usuários simultâneos. Com tráfego de rede intenso, é provável que os clientes esperarão mais tempo para que uma resposta do servidor chegue a eles. Um outro ponto a ser considerado é que para respostas grandes do servidor, a fila de espera pode ficar ainda pior para os usuários, por isso a compactação de conteúdo no lado servidor é muito importante.

A compactação, nada mais é do que executar algum algoritmo de compactação nos dados enviados do servidor para o cliente. No servidor Apache, essa configuração é feita habilitando o módulo mod_deflate. Em versões antigas usava-se o mod_gzip, porém devido à falhas de segurança encontradas no mod_gzip, o indicado agora é o uso do mod_deflate.

Indice

  • Descrição do mod_deflate
  • Fluxo de uma requisição HTTP
  • Configurações
  • Testando a Configuração
  • Conclusão

Descrição do mod_deflate

O mod_deflate permite comprimir de forma automática o conteúdo enviado aos clientes, de forma a economizar banda e a reduzir o tempo de carregamento das páginas. Se os sites hospedados no servidor utilizam páginas com grandes volumes de texto, a redução pode ser bastante significativa.

O uso de compressão é negociado entre o servidor e o cliente no momento em que ele requisita a página, de forma que você não precisa se preocupar em excluir navegadores móveis ou clientes com browsers antigos. Ao perceber que o cliente não suporta o recurso, o servidor simplesmente envia a página sem compressão.

O uso do deflate aumenta sutilmente o uso de processamento no servidor, já que ele terá o trabalho de comprimir cada página solicitada antes de enviá-la ao cliente, mas isso é compensado pelo fato de o cliente demorar menos tempo para carregar cada página, o que permite que o servidor mantenha um número menor de instâncias do Apache carregadas na memória.

Do ponto de vista do cliente, o deflate é bastante benéfico, pois o texto das páginas carrega mais rápido. Uma página html comprimida pelo deflate fica com, tipicamente, um quarto do tamanho original. Com isso, uma página de 100 KB, que demoraria até 15 segundos para ser carregada por um cliente acessando via modem, passaria a ser carregada em apenas 3 ou 4 segundos. Depois disso, ainda teríamos o tempo de carregamento das imagens e de outros elementos da página, como de praxe, mas com o html carregado o cliente pode já ir adiantando a leitura.

Note que, as "páginas em html" que citei no parágrafo anterior, incluem também páginas dinâmicas em php e em outras linguagens, pois, de qualquer forma, depois de serem processadas pelo servidor, elas são enviadas ao cliente como uma página html.

Fluxo de uma requisição HTTP

Para entendermos melhor como esse módulo do Apache funciona, precisamos entender como uma requisição HTTP funciona. Pois bem, quando um site é acessado, o navegador realiza diversos pedidos de arquivos ao servidor, e este por sua vez, envia para o cliente, uma resposta para cada pedido do navegador. Nestes pedidos são enviados informações referente ao tipo de conteúdo, linguagem esperada, e etc. Isto é conhecido como Request Header ou Cabeçalho de Requisição. Após este pedido, o servidor retorna a resposta, com as imagens, textos, estilos e etc. Este é o Response Header ou Cabeçalho de Resposta. Para um site comum são enviados em média 80 Requests Headers e recebidos consequentemente 80 Responses Headers. Para cada pedido uma resposta. Para acessar uma página como a do http://www.terra.com.br o navegador realiza cerca de 400 requests iniciais, daí podemos começar a perceber a importância de compactação de conteúdo do response header.

  • 1. navegador solicita algum arquivo ao servidor
  • 2. servidor encontra o arquivo e lê
  • 3. servidor retorna o arquivo com código 200 (OK)
  • 4. navegador exibe o resultado da página aplicada com o estilo CSS

Configurações

Para ativar o mod_deflate, basta que seja descomentada a linha responsável por seu carregamento no arquivo "httpd.conf", a linha exata pode ser visualizada na figura 1 abaixo.

apache-windows-hablitando-deflate-httpd.conf
Figura 1 - Habilitando o mod_deflate no arquivo httpd.conf

A tarefa de configurar o mod_deflate pode ser feita de duas formas a depender de como está configurado o seu servidor. Caso seu servidor esteja preparado para servir apenas um domínio e utilizando as configurações globais, que é o padrão já configurado durante a instalação do Apache, abaixo temos a figura 2 que exibe o conteúdo a ser adicionado ao arquivo httpd.conf para habilitar a compressão de conteúdo, lidar com browsers não compatíveis e realizar log da compactação

apache-windows-configurando-deflate-httpd.confFigura 2 - Configurando o mod_deflate no arquivo httpd.conf

Abaixo temos o conteúdo na forma de texto que deve ser adicionado ao httpd.conf, reparem que é o mesmo texto da imagem.

#verifica se o mod_deflate está carregado 
<IfModule mod_deflate.c>
 #habilita o deflate
 SetOutputFilter DEFLATE
 #define o nível de compressão
 DeflateCompressionLevel 9
 
 #corrige imcompatibilidade com browsers que não suportam o mod_deflate
 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html 
 
 # Exclui as seguintes extensões: gif,jpg,png,mp3,mp4,avi,rar,zip,pdf,swf 
 # essas extensões já apresentam conteúdo compactado.
 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|mp3|mp4|avi|rar|zip|pdf|swf)$ no-gzip dont-vary
 
 #Criando deflate_log
 DeflateFilterNote Input instream
 DeflateFilterNote Output outstream
 DeflateFilterNote Ratio ratio
 LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
 CustomLog logs/deflate_log deflate 
</IfModule>

Se você utiliza o Apache de forma mais profissional e deseja aprender a configurar a compactação de conteúdo para domínios específicos definidos em blocos <virtualhost>, apesar de um pouco diferente, a configuração também é simples, conforme pode ser visto abaixo na figura 3.

apache-windows-configurando-deflate-httpd-vhosts.confFigura 3 - Configurando o mod_deflate no arquivo httpd-vhosts.conf

Repare que é o mesmo conteúdo da configuração global já exibida em texto logo acima, porém sem a verificação de carregamento do módulo. Com isso já podemos configurar o mod_deflate para atender à todos os domínios do servidor, ou apenas à domínios específicos. Na próxima seção serão mostrados testes simples, para podermos visualizar o poder da compressão e a economia de tráfego de rede.

Testando a Configuração

Para os testes, vamos utilizar a configuração exibida para servidores virtuais exibida neste post. Esta decisão foi tomada para podermos mostrar de forma rápida e clara a diferença no consumo de tráfego de rede utilizando o mod_deflate.

Nas configurações do servidor virtual www.exemplo.com foram adicionadas as configurações do mod_deflate exibidas acima, de forma que o servidor virtual está como na figura 3. Após configurar o apache com os servidores virtuais e o mod_deflate, deve ser criada uma página com um texto muito grande, como esta. Copie esta página para os seus servidores virtuais www.exemplo.com e www.outroexemplo.com.

Após a cópia dos arquivos, basta iniciar o serviço do apache e testarmos em um navegador. No nosso caso, testamos utilizando o google chrome, devido às ferramentas para desenvolvedores.

Basta abrirmos o navegador e digitarmos o endereço do nosso site com mod_deflate configurado que é o www.exemplo.com. Logo após o carregamento da página, abra o painel para desenvolvedores que geralmente é a tecla f12 e clique na aba network. Abaixo segue a figura 4, exibindo o tamanho original da página e o tamanho do arquivo enviado ao usuário.

apache-windows-resultado-compressao-mod-deflate-google-chromeFigura 4 - Exibição do resultado de compressão do mod_deflate no google chrome.

Na figura 5 abaixo, podemos ver o domínio www.outroexemplo.com servindo a mesma página sem compressão de dados.

apache-windows-resultado-sem-compressao-mod-deflate-google-chromeFigura 5 - Exibição do resultado sem compressão do mod_deflate no google chrome.

Conclusão

Reparando nas figuras 4 e 5, podemos ver que o nível de compressão para arquivos html e texto é muito bom. Na nosso domínio de teste com mod_deflate ativado, o tamanho do arquivo enviado ao cliente foi de apenas 160kb, contra 433kb do domínio sem o mod_deflate ativado.

Mas nem tudo são flores, podemos perceber também que o mod_deflate, torna o servidor um pouco mais pesado, pois o apache tem que comprimir o response ao cliente, demandando tempo de processamento e memória. Nos testes em localhost, é melhor deixar o mod_deflate desativado, pois não temos que fazer nenhum download, porém em um domínio muito acessado, a economiza de banda utilizada vale muito a pena.

sexta-feira, 20 de setembro de 2013

Configurando Servidores Virtuais no Apache

No nosso último post ensinamos a instalar o apache no windows e a configurá-lo minimamente para que páginas html possam ser servidas via localhost. Inclusive foram mostradas as diretivas de endereço e-mail do administrador do servidor, nome pelo qual o servidor se identificará e o diretório de documentos padrão do servidor.

Agora vamos ensinar a configurar o serviço do Apache para que ele possa ser configurado de forma mais profissional e produtiva. Nesta etapa de postagens sobre o Apache aprenderemos a configurar os "virtual hosts" ou "servidores virtuais" baseados em Nomes.

O termo servidor virtual refere-se à prática de executar mais de um site (como por exemplo site1.exemplo.com e site2.exemplo.com) em uma única máquina servidora. Servidores virtuais podem ser baseados em endereços IP, significando que você terá um endereço IP diferente para cada site, ou baseado em Nomes, significando que você terá múltiplos nomes sendo executados em cada endereço IP. O fato de que eles estão sendo executados no mesmo servidor físico ficará transparente, significando que não será perceptível.

Índice

  • Pré-requisitos
  • Servidor Virtual baseado em Nome
  • Configurações
  • Testando a Configuração
  • Conclusão

Pré-requisitos

O único pré-requisito é que o servidor Apache esteja instalado na máquina e que você tenha permissão para visualizar e criar arquivos no diretório de instalação do apache.

Servidor Virtual Baseado em Nome

Servidores Virtuais, como já dito, podem ser baseados em IP e utilizarem o endereço ip da conexão para determinar o servidor virtual correto que será o responsável. Portanto, você precisará de mais de um endereço IP na máquina. Há também os servidores virtuais baseados em Nomes, sendo estes, o assunto da postagem. Nesse tipo de servidor virtual, o servidor conta com o cliente para reportar o nome do servidor como parte do cabeçalho HTTP. Utilizando esta técnica, vários hosts virtuais podem compartilhar o mesmo endereço IP.

Servidores Virtuais baseados em nome geralmente são mais simples, pois é preciso apenas configurar o servidor DNS para mapear cada nome para o endereço IP correto e então conigurar o Apache para reconhecer os diferentes nomes. Além de toda a simplicidade esse modelo de servidor virtual também resolve um outro problema que é a demanda por enderelos IP, que estão cada dia mais escassos.

Configurações

Para configurar os servidores virtuais é preciso apenas criar um bloco <VirtualHost> para cada servidor virtual diferente que você queira servir. Dentro de cada bloco <VirtualHost>, você precisará de no mínimo uma diretiva "ServerName" para designar qual servidor virtual será servido e uma direvita "DocumentRoot" para mostrar onde se encontra no sistema de arquivos o conteúdo para o servidor virtual.

No entanto, para que o servidor seja configurado da forma mais profissional possível, o ideal é que algumas diretivas globais do servidor sejam sobrescritas dentro de cada servidor virtual, e um servidor virtual seja criado para sobrescrever as configurações globais.

As diretivas como ServerAdmin, DocumentRoot, ServerName, ServerAlias, DirectoryIndex, ErrorLog, CustomLog e <Directory> caso sejam sobrescritas, permitem um melhor controle do servidor.

Vamos exemplificar para facilitar o entendimento, suponha que esteja servindo o domínio www.exemplo.com e você queira adicionar o servidor virtual www.outroexemplo.com o qual aponta para o mesmo endereço IP.

Neste exemplo, devemos criar um servidor virtual para o domínio www.exemplo.com e colocá-lo em primeiro lugar na listagem de servidores virtuais, e devemos criar um servidor virtual para o domínio www.outroexemplo.com. Assim, o servidor virtual do domínio www.exemplo.com será o servidor virtual padrão do servidor http.

Para configurar os servidores virtuais, você simplesmente deve adicionar o seguinte conteúdo para o arquivo httpd.conf: "Include conf/httpd-vhosts.conf". Coloque o conteúdo em negrito, sem aspas, como sendo a última linha no seu arquivo httpd.conf, conforme figura 1 abaixo.

apache-windows-servidor-virtual-nome-arquivo-httpd_conf

Navegue até a pasta /conf dentro do diretório do Apache e crie o arquivo "httpd-vhosts.conf", conforme visto na figura 2 abaixo. Em seguida, abra o arquivo e crie um bloco <VirtualHost>. Neste bloco, preencha as diretivas ServerAdmin, DocumentRoot, ServerName, ServerAlias, DirectoryIndex, ErrorLog, CustomLog e <Directory>.

apache-windows-servidor-virtual-nome-arquivo-httpd-vhosts-confFigura 2 - Arquivo httpd-vhosts.conf

Para fins de exemplo, nosso arquivo httpd-vhosts.conf ficaria:

#bloco de servidor virtual para o domínio www.exemplo.com

<VirtualHost 127.0.0.1:80>
 ServerAdmin webmaster@exemplo.com
 DocumentRoot c:/Apache24/htdocs/exemplo
 ServerName www.exemplo.com
 ServerAlias exemplo.com *.exemplo.com
 DirectoryIndex index.html
 ErrorLog logs/exemplo.com-error.log
 CustomLog logs/exemplo.com-access.log common
 <Directory "c:/Apache24/htdocs/exemplo">
  AllowOverride All
  Order Allow,Deny
  Allow from all
  Require all granted
 </Directory>
</VirtualHost>

#bloco de servidor virtual para o domínio www.outroexemplo.com

<VirtualHost 127.0.0.1:80>
 ServerAdmin webmaster@exemplo.com
 DocumentRoot c:/Apache24/htdocs/outroexemplo
 ServerName www.outroexemplo.com
 ServerAlias outroexemplo.com *.outroexemplo.com
 DirectoryIndex index.html
 ErrorLog logs/outroexemplo.com-error.log
 CustomLog logs/outroexemplo.com-access.log common
 <Directory "c:/Apache24/htdocs/outroexemplo">
  AllowOverride All
  Order Allow,Deny
  Allow from all
  Require all granted
 </Directory>
</VirtualHost>

Abaixo temos uma breve explicação do que significa cada diretiva.

ServerAdmin: Endereço de e-mail do administrador do servidor virtual, utilizado em exibição de páginas geradas pelo próprio servidor http em caso de erro.

DocumentRoot: Endereço do diretório que contém os arquivos do site.

ServerName: Nome pelo qual o servidor atenderá requisições à este servidor virtual.

ServerAlias: Nomes pelos quais além do nome indicado no ServerName, o servidor virtual atenderá as requisições. Útil para permitir ao servidor virtual atender à requisições com ou sem o www.

DirectoryIndex: Arquivo a ser exibido em caso de a url não conter nenhum arquivo, apenas o nome do domínio. O arquivo configurado nesta diretiva deve estar contido no diretório especificado pela diretiva DocumentRoot.

ErrorLog: arquivo de log gerado para exibir erros durante a execução do servidor. O padrão é deixar que o caminho do arquivo comece pelo diretório log na pasta raiz do Apache.

CustomLog: arquivo geral de log do servidor. O padrão é deixar que o caminho do arquivo comece pelo diretório log na pasta raiz do Apache.

<Directory></Directory>: define regras de permissões de acessos à pastas do servidor virtual, deve ser configurado com o mesmo caminho da diretiva DocumentRoot.

Lembrando que cada nome de domínio especificado na diretiva VirtualHost, deve estar contido no arquivo hosts de cada máquina que requisitará o domínio ou estar cadastrado no servidor de DNS. Com isso, todas as requisições para o domínio exemplo.com serão servidas pelo servidor virtual www.exemplo.com, desde que o DNS esteja configurado corretamente, ou o arquivo hosts que fica em "C:/windows/system32/drivers/ect/" esteja configurado de acordo, conforme figura 3 abaixo.

apache-windows-servidor-virtual-nome-arquivo-hosts-dnsFigura 3 - Arquivo hosts configurado

A partir deste ponto, quando uma requisição chegar, o servidor http primeiro fará a checagem se a requisição casa com algum endereço definido em algum servidor virtual. Se casar, o servidor http então irá procurar em cada <VirtualHost> e tentará encontrar algum onde as diretivas ServerName ou ServerAlias casem com o nome de servidor requisitado. Caso algum servidor virtual seja encontrado, o servidor http, servirá a requisição utilizando a configuração definida no primeiro bloco <VirtualHost> encontrado. Caso nenhum servidor virtual contenha as diretivas ServerName ou ServerAlias que casem com o nome procurado na requisição, o servidor http, servirá a requisição com o primeiro servidor virtual que casar com o IP procurado. Por isso, o primeiro servidor virtual listado se torna o servidor virtual padrão do servidor http.

Testando a Configuração

Para testar as configurações realizadas, vamos criar dois sites, um para cada domínio (exemplo.com e outroexemplo.com). Isto pode ser feito criando duas pastas para condizer com as diretivas "DocumentRoot" e "Directory" de cada servidor virtual de exemplo, conforme figura 4 abaixo.

apache-windows-servidor-virtual-nome-uma-pasta-cada-siteFigura 4 - Nomes das pastas criadas

Em cada uma destas pastas que hospedarão os nossos sites, crie um arquivo html chamado "index.html". Na pasta exemplo, deve ser criado um arquivo html contendo o seguinte conteúdo: <html><body><h1>It works: Exemplo!</h1></body></html>.

Na pasta outroexemplo, deve ser criado um arquivo html contendo o seguinte conteúdo: <html><body><h1>It works: Outro Exemplo!</h1></body></html>.

A figura 5 abaixo exibe as duas pastas criadas e os arquivos index.html dentro de cada pasta.

apache-windows-servidor-virtual-nome-conteudo-duas-pastasFigura 5 - exibição do conteúdo das pastas exemplo e outroexemplo

Agora, basta colocar o servidor apache para ser executado, o que pode ser feito de duas formas. Ou dando dois cliques no arquivo "httpd.exe" ou digitando "cd:/apache24/bin/httpd.exe" no prompt de comandos do windows. Após startar o serviço do apache, basta digitar os endereços configurados no DNS ou no arquivo hosts para verificarmos que o servidor apache está servindo as requisições corretamente. No nosso caso basta digitarmos exemplo.com ou www.exemplo.com para o servidor servir o domínio www.exemplo.com, conforme pode ser visto na figura 7 abaixo, já a figura 8 mostra que o mesmo vale para o domínio www.outroexemplo.com.

apache-windows-servidor-virtual-nome-dois-nomes-mesmo-dominio-aliasFigura 6 - Domínio www.exemplo.com funcionando com o alias exemplo.com

apache-windows-servidor-virtual-nome-dois-nomes-mesmo-dominio-alias2Figura 7 - Domínio www.outroexemplo.com funcionando com o alias outroexemplo.com

Conclusão

Conforme podemos ver nesta postagem, o conceito de servidores virtuais do apache é muito útil quando temos que usar um único servidor para servir mais de um domínio. Podemos perceber também que o apache oferece uma configuração bem robusta permitindo que os administradores deixem os domínios configurados de forma bastante separada, para que uma configuração não interfira com a outra. Um ponto muito importante a ser notado é que a configuração de nomes de domínios a serem servidos devem obrigatoriamente estar configurados no DNS ou no arquivo hosts de cada máquina cliente que fará requisições ao servidor.

Até a próxima, onde falaremos de compactação de output de requisições do apache, melhorando em muito o tráfego de rede.

Instalando servidor Apache no Windows

O Apache é um servidor HTTP de código fonte livre para sistemas operacionais modernos incluindo Unix, Microsoft Windows e Mac OS/X. O principal objetivo do projeto é fornecer um servidor seguro, eficiente e extensível que provê serviços HTTP observando os padrões HTTP atuais. Lançado em abril de 1996, o Apache tem sido o servidor web mais popular na Internet.

O intuito deste post é criar um manual de instalação para o Apache, permitindo que seja possível a publicação de páginas HTML e o redirecionamento para módulos como PHP ou Java, dentre outras linguagens.

Índice

  • Pré-requisitos
  • Instalação do Apache
  • Configurações do Apache
  • Validando a Configuração

Pré-requisitos

A Apache Software Foundation não costuma igualar as versões do Apache para os sistemas operacionais Windows e Linux, por isso a versão para Microsoft Windows geralmente tem o lançamento atrasado. E além do mais, as versões windows precisam  que se tenha instalado o pacote Visual C++ Redistributable do Microsoft Visual Studio.

A versão do pacote Visual C++, chamado de VC, depende da versão que se queira instalar do Apache.

Portanto,  devemos ir ao site http://www.apachelounge.com/download/ e baixar a última versão disponível. No próprio site é informado qual a versão do VC deve ser usada com a versão desejada do Apache.

Instalação do Apache

Após o download, descompacte os arquivos um diretório de sua preferência, apenas lembre-se do lugar exato, pois precisaremos no momento da configuração. Como exemplo será exibido a instalação no diretório raiz  (barra) do disco C em C:\Apache24, conforme Figura 1 abaixo.

apache-windows-descompactacaoFigura 1 - Local de descompactação do arquivo zip do Apache

Configurações do Apache

Após descompactar os arquivos do Apache, vamos agora realizar a configuração do nosso servidor, acesse a pasta recém criada ( no meu caso é: C:\Apache24) e encontre e abra o arquivo httpd.conf (esse é o arquivo responsável pelas configurações do Apache), o qual está localizado dentro da pasta conf, conforme pode ser visto na Figura 2 abaixo.

apache-windows-descompactacaoFigura 2 - Localização do arquivo httpd.conf

Abaixo será mostrado parte do que é possível configurar no Apache:
  • Diretório raiz do Apache:
  • Bind de ip e porta:
  • Diretório de Documentos(Sites)

Diretório raiz do Apache: É a diretiva de nome "ServerRoot", é o diretório no qual os arquivos de configuração, erros, e log são guardados. No nosso caso é c:/Apache24, você de alterar o valor para onde foi descompactado os arquivos do apache conforme na Figura 1.

Bind de IP e Porta: É a diretiva de nome "Listen", permite amarrar o serviço do apache à um IP e/ou à uma porta específicos, o valor padrão é amarrar o serviço à porta 80. Quando o valor da porta é alterado para diferente de 80, o valor da porta deve aparecer explicitamente na URL da barra de endereços do navegador, ex: http:site:<porta>.com

Em nosso caso deixamos o valor padrão que é escutar a porta 80, porém no nosso caso tivemos que alterar, pois a diretiva Listen só continha a porta, portanto, precisamos alterar o a diretiva Listen para: "127.0.0.1:80".

Diretórios de Documentos (Sites): É a diretiva de nome "DocumentRoot". Por padrão é o diretório htdocs, então se quiser começar a servir páginas, basta adicioná-las nesse diretório. Ao se alterar o valor desta diretiva, a tag <Directory></Directory> deverá ter o endereço alterado para condizer com o novo valor da diretiva DocumentRoot. Caso o endereço das duas chaves não seja o mesmo, o servidor não irá funcionar.

Endereço de e-mail do administrador: É a diretiva de nome "ServerAdmin" é um endereço de e-mail que aparecerá em algumas páginas de erros geradas pelo servidor caso algum problema apareça, para que as pessoas possam entrar em contato com o administrador.

Validando a Configuração

Para verificar se está tudo funcionando, vamos testar a configuração do Apache seguindo os seguintes passos:

  1. Abra oprompt de comando do Windows
  2. Digite "cd <caminho_apache>" e tecle enter(no nosso caso foi "cd c:/Apache24", mas você deve digitar o endereço de descompactação, vide seção de instação).
  3. Agora digite "cd /bin" e aperte enter
  4. O comando que testa a sintaxe do arquivo httpd é: "httpd -t"

Se o arquivo httpd.conf estiver correto, o resultado deverá ser "Syntax ok".
Não feche o prompt de comando do Windows.

Após a confirmação da sintaxe, vamos iniciar o serviço do apache. Para isso, basta que se digite "httpd.exe". Com o servidor sendo executado, basta digitar o endereço do servidor no browser: http://localhost ou http://127.0.0.1, conforme Figura 3 abaixo.

apache-windows-rodandoFigura 3 - Serviço HTTP do Apache sendo executado

Conclusão

Claro que essa página não contém toda a documentação do Apache, porém com as informações passadas, já é possível  começar a servir páginas html. Ensinamos também a configurar o diretório padrão de documentos, o nome pelo qual o servidor se identificará e o e-mail do administrador do Apache. Mas note que essas informações como e-mail do administrador, diretório de documentos e nome do servidor, são configurações globais que podem ser sobrescritas com um conceito muito útil do Apache que é o conceito de servidores virtuais, assunto do próximo post.

Até a próxima.