Lentidão ou travamento ao utilizar o Isa Server como proxy
Por: Renie Aloisi Mansur / Technical Reviewer: Diana Hernandez
Introdução
Ultimamente, recebemos um número relevante de casos sobre "lentidão" ou "travamento" ao acessar páginas web, tendo o Isa Server como a solução de proxy ou firewall.
Neste caso em particular, o cliente identificara que este comportamento somente acontecia na utilização do Isa Server como proxy. Logo, a queixa recebida era que o Isa Server não funcionava corretamente. Ao redirecionar o tráfego de rede diretamente para o firewall, o acesso era feito conforme esperado.
Após alguns minutos definindo o escopo do caso e entendendo o ambiente, eis nosso cenário:
Considerações
O Isa Server possuía apenas uma placa de rede (demandando o modo proxy. Maiores detalhes aqui).
O workaround utilizado pelo cliente era remover as informações de proxy, desta maneira, o acesso à Internet era feito diretamente pelo firewall de borda em questão (CheckPoint). Esta tese corroborava (até o momento) com a hipótese do cliente, que o Isa não tratava as solicitações proxy corretamente.
Após uma clara idéia do problema e da expectativa de resolução, iniciamos nosso t-shooting tomando uma página como base e, a partir de uma estação fizemos simulações para entender o comportamento do Internet Explorer na utilização do Proxy Server.
Ações iniciais
Tomaremos como exemplo o site www.microsoft.com.br para preservar o site e informações do cliente. Acessando o link, o navegador iniciou a carga da página e, cerca de 15 segundos depois, o status do Internet Explorer era "not responding". Outros sintomas incluíam o não carregamento de figuras e erros.
Procedimentos comuns como remoção de cache do cliente, desabilitar add-nos, filtro de compressão do Isa etc, foram realizados para entender qual seria o comportamento, entretanto, o mesmo sintoma persistia.
Identificamos então que a maioria das páginas causadoras do problema tinham conteúdo shockwave ou Java o que nos deu uma pista, entretanto, se tal plug-in tivesse relação direta com o problema, inicialmente, teríamos o mesmo sintoma com ou sem o proxy. Talvez, a causa estivesse na maneira que a informação era solicitada ou recebida pelo cliente e não no servidor em si...
Com o escopo de caso claro e definido, partimos para a coleta de informações. Nada melhor que um trace de rede para analisarmos o que o cliente "conversava" com o site:
Http request:
- HTTP: Request, GET /
Command: GET
URI: / Location: /
ProtocolVersion: HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.microsoft.com
Connection: Keep-Alive
Http response
- HTTP: Response, HTTP/1.1, Status Code = 302
ProtocolVersion: HTTP/1.1
StatusCode: 302, Moved temporarily
Reason: Found
Cache-Control: private
ContentType: text/html; charset=utf-8
Location: /en/us/default.aspx
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Tue, 23 Sep 2008 13:43:25 GMT
ContentLength: 142
HeaderEnd: CRLF
+ HTTPPayload: <html><head><title>Object moved</title></head><body><h2>Object moved to <a href="%2fen%2fus%2fdefault.aspx">here</a>.</h2>
</body></html>
OBS: O status code 302 não representa um problema necessariamente e é muito comum em traces. Este status, basicamente diz ao browser buscar a informação novamente ou em outro servidor. Maiores informações aqui.
Entendendo o trace convertendo-o em ações
A primeira idéia que chegará à sua mente deve ser “Bom..não há nada demais neste trace, pois trata-se de uma seqüência comum de acesso web (http request seguido de http response)”.
Em primeira instância, sim....contudo, um olhar mais analítico, comparando o ambiente, junto com o trace, extraímos as seguintes informações:
a. A solicitação (request) e resposta (response) eram feitas com http 1.1.
b. O Isa Server, por padrão, utilizará e tratará o protocolo http 1.1.
Até este momento, inicialmente, o Isa Server tratava as informações como esperado. Restava saber se o cliente que originou a solicitação estava preparado para isto.
O Internet Explorer tem uma opção customizável de usar ou não http 1.1 através de conexões proxy.
No ambiente deste cliente, a opção não estava habilitada fazendo com que o I.E. não tratasse a resposta do site da maneira mais adequada. Esta era a causa do problema.
Tela de configuração para do Internet Explorer
Conclusão
Habilitamos “Usar HTTP 1.1 através de conexões Proxy” e o problema foi resolvido.
Isto explica o motivo pelo qual a utilização do firewall provia o acesso correto, pois a opção “Usar http 1.1” já estava marcada, entretanto “Usar http 1.1 através de conexões Proxy” não!
Não utilizar http 1.1 por conexões proxy não significa que o acesso aos sites serão ou não prejudicados.
Entretanto, a utilização de http 1.1 otimiza as conexões de inúmeras maneiras (leia “informações adicionais”).
Informações adicionais
- O uso de HTTP 1.1 através de conexões Proxy, permite o Internet Explorer enviar/receber respostas não disponíveis no modo 1.0 (por exemplo, melhor compressão de dados, menor latência etc), conseqüentemente o desempenho será melhor.
Para uma completa descrição e entendimento, podemos beber diretamente na fonte, para isto, leia a RFC 2616 (HTTP/1.1) e a RFC 1945 (HTTP/1.0).
- Como havia um grande número de estações com o mesmo sintoma, fornecemos alguns passos para melhor ajudar nosso cliente, configurando a opção com uma gpo:
-
- Abra o GPMC, crie uma GPO e associe-a na OU respectiva.
- Acesse a GPO em User Configuration \ Windows Settings \ Internet Explorer Maintenance.
- Clique com botão direito em Internet Explorer Maintenance e habilite o Preference Mode.
Clique duas vezes em Advanced -> Internet Settings -> Advanced Settings.
Liste as opções até localizar Use HTTP 1.1 through proxy connections, marque-a e confirme a alteração. - Feche o editor de policies e aguarde a replicação dos domain controllers. No próximo ciclo de atualização da gpo, as configurações serão efetivadas.
- Artigos relacionados:
Até o próximo artigo!