Poderá detectar um fraco desempenho de Web quando utiliza o Internet Explorer 6 para tentar aceder a um aplicativo da Web hospedado no IIS 6.0

Considere o seguinte cenário:

• Utilize a autenticação integrada do Windows num ambiente de aplicação Web do Microsoft Internet Information Services 6.0 (IIS 6.0).
• Utiliza o Microsoft Internet Explorer 6 para aceder a uma aplicação da Web hospedado no IIS 6.0.

Neste cenário, poderá detectar um fraco desempenho da aplicação Web.

Nota O problema não ocorre se a autenticação anónima for utilizada como o protocolo de autenticação. Este problema também não ocorre se o navegador do cliente for um browser diferente do Internet Explorer 6, como o Mozilla Firefox.

Este problema ocorre porque o cliente do Internet Explorer 6 regularmente repõe as ligações TCP.

Se analisar um rastreio de rede que é capturado durante a comunicação mal efectuar entre o cliente e o servidor, o rastreio de rede mostra que repõe TCP ocorrerá depois do cliente recebe uma resposta para o recurso que o cliente solicitou 200. O cliente efectua os pedidos GET com um cabeçalho ETag HTTP e o valor. Quando o servidor com o IIS 6.0 recebe o pedido, compara o valor de ETag e localiza a que o valor de ETag corresponde ao valor actual ?s o ficheiro pedido, excepto para o número de alteração.

Nota ETag cabeçalhos são apresentados no seguinte formato:

Filetimestamp: ChangeNumber

Por exemplo, o cliente do Internet Explorer envia um pedido com um valor ETag 0222d5bffcbc41:301a e, em seguida, o servidor enviará uma resposta de HTTP 200 com um valor ETag 0222d5bffcbc41:3246.

O número de Filetimestamp no pedido é o número mesmo que o IIS 6.0 considera ser o valor actual para o recurso pedido. Mas uma vez que o número ChangeNumber o pedido é diferente, o IIS 6.0 envia de volta a versão actual do ficheiro em vez de informar o Internet Explorer para servir a sua própria cópia em cache. Existe código específico do Internet Explorer que compara o Filetimestamp numa resposta 200 com o Timestamp da cópia em cache localmente. A ligação é reposta se for o mesmo número. Isto acontece porque o cliente do Internet Explorer espera receber um relatório de 304 estado se o conteúdo é o mesmo.

Por outras palavras, o IIS 6.0 envia uma resposta 200 porque considera os números de alteração diferente para significar que o recurso que é pedido pelo cliente e por versão de pré-existente de ?s cliente deste recurso que reside na cache do browser não são as mesmas versões. No entanto, o Internet Explorer considera que sejam as mesmas versões porque Filetimestamp é o mesmo. Além disso, o Internet Explorer acredita que que está a receber a resposta 200 por engano. Neste cenário, o Internet Explorer repõe a ligação TCP.

Se estiver a utilizar um computador baseado no Microsoft Windows Server 2003

Para contornar este problema, recomendamos que código disco rígido que o número de alteração no servidor da Web e que sincronizar a versão do ficheiro para todos os clientes do Internet Explorer. Todos os clientes do Internet Explorer tem versões de todos os ficheiros diferentes que são necessários para a aplicação. Tem de certificar-se de que o servidor e todos os clientes estão sincronizados.

Nota Se estiver a executar num ambiente de farm de servidores Web do IIS 6.0, terá de código permanentemente o mesmo número de alteração para todos os servidores que executem o IIS 6.0 na farm.

Para sincronizar os valores de números de alteração entre os clientes e o servidor, siga estes passos.

1. código rígido manualmente o valor ETag a metabase do IIS 6.0
   
   A capacidade de modificar o número de alteração ETag no IIS 6.0 está disponível no Windows Server 2003 Service Pack 1 (SP1).
   
   Nota Poderá detectar um problema quando altera o valor de ETag e tem de instalar uma correcção para corrigir este problema. Para obter mais informações sobre a correcção, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:
   900245  (http://support.microsoft.com/kb/900245/ ) O valor no campo ETAG é actualizado quando modifica uma propriedade da metabase no IIS 6.0
   Depois de instalar a correcção, pode manualmente rígido código o ETag alterar número. No entanto, não é apresentada a definição para o número de alteração ETag ao espaço de nomes interfaces de serviço do Active Directory (ADSI). Por este motivo, tem de utilizar a ferramenta Metabase Explorer para definir o valor por ID. de propriedade Para transferir e instalar o Metabase Explorer, visite a seguinte página Web da Microsoft:
   http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36 -5761-448f-889e-9ae58d072c09.mspx (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true)
   Nota Metabase Explorer incluído no resource kit do IIS 6.0.
   
   Código rígido manualmente o ETag alterar número, siga estes passos:
   1. Abra o Explorador da Metabase, expandir LM no painel esquerdo e expanda W3SVC .
   2. Clique duas vezes o registo de ID 2039 no painel da direita. Se o registo de ID 2039 não estiver presente, tem de criá-lo. Para o fazer, siga estes passos:
      1. Clique com o botão direito do rato no nó W3SVC no Explorador de Metabase, aponte para Criar novo e, em seguida, clique em valor DWORD .
      2. Defina o identificador da nova DWORD para 2039 .
      3. Defina o valor da nova DWORD para 0 .
   3. Escreva 0 na caixa valor .
      
      Nota O número que escrever dentro da caixa de valor tem de ser entre 0 e 4294967295. Além disso, todos os servidores do farm tem de ter o número idêntico na caixa valor . Para obter mais informações, visite a seguinte página Web da Microsoft:
      http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58- 2a96-4bd8-8ac1-2a67b43284f1.mspx (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58-2a96-4bd8-8ac1-2a67b43284f1.mspx)
   4. Clique em Aplicar e, em seguida, clique em OK .
   Nota Se estiver a utilizar servidores de IIS 6.0 num ambiente de farm de servidores Web do IIS 6.0, repita os passos 1a através de 1D em todos os servidores IIS 6.0 na farm. Certifique-se que adiciona que o mesmo alterar o valor numérico em todos os servidores.
2. Limpar a cache de browser cliente no Internet Explorer
   
   Se existirem muitos navegadores de cliente para limpar manualmente a cache, pode seleccionar Activar expiração de conteúdo no IIS 6.0 e, em seguida, especificar que o conteúdo expira imediatamente. Neste cenário, tem de deixar Activar expiração de conteúdo activada para apenas enquanto demora para todos os clientes têm conteúdo novo. Em seguida, terá de desactivar a opção Activar expiração de conteúdo para dar a oportunidade de servir conteúdo em cache novamente Internet Explorer. Para activar expiração de conteúdo, siga estes passos:
   1. Abra Serviços de informação Internet (IIS).
   2. Expanda LocalMachine no painel da esquerda e, em seguida, clique em Web Sites .
   3. Clique com o botão direito do rato em Web Sites e, em seguida, clique em Propriedades .
   4. No separador Cabeçalhos de HTTP , clique para seleccionar a caixa de verificação Activar expiração de conteúdo e, em seguida, clique na opção Expirar imediatamente .
   5. Pare e reinicie todos os serviços IIS 6.0.
   Nota Um cliente poderá ter de efectuar dois pedidos para um recurso depois da caixa de verificação Activar expiração de conteúdo é activada para actualizar a cache do Internet Explorer.

Se não estiver a utilizar um computador baseado no Windows Server 2003

Para contornar este problema, Active a opção de Activar a expiração do conteúdo no IIS 6.0 utilizando o procedimento descrito na secção "Limpar cache do browser do cliente no Internet Explorer" e deixá-lo no. Além disso, desactivar colocação em cache no Internet Explorer ou definir cabeçalhos de controlo de cache na aplicação Web. Para obter mais informações sobre como impedir a colocação em cache Web, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Windows Internet Explorer 7 foi modificada para processar correctamente o número de alteração ETag acordo com a RFC 2616. No entanto, se o número de ETag é alterado, Windows Internet Explorer 7 irá transferir o ficheiro completo em vez de cancelar a ligação. Este comportamento pode diminuir o desempenho do Internet Explorer 7 comparado com o Internet Explorer 6.

Se analisar um rastreio do Monitor de rede que é capturado no cliente ou no servidor e este rastreio está envolvido no cenário de desempenho, consulte a seguinte sequência:

1. O cliente envia o pedido GET para o servidor que executa o IIS 6.0 e o pedido inclui um cabeçalho If-None-Match com um Filetimestamp: valor ChangeNumber. Este pedido se assemelhe ao seguinte:

   HTTP: GET Request from Client
   HTTP: Request Method =GET
   HTTP: Uniform Resource Identifier =/MARRS/webService.htc
   HTTP: Protocol Version =HTTP/1.1
   HTTP: Accept = */*
   HTTP: Accept-Encoding =gzip, deflate
   HTTP: If-Modified-Since =Tue, 16 Nov 2004 17:11:48 GMT
   HTTP: If-None-Match ="0222d5bffcbc41:301a" 
   HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET 
   CLR 1
   HTTP: Host =nnoma-wwapp02m
   HTTP: Connection =Keep-Alive
   HTTP: Authorization =Negotiate 
   TlRMTVNTUAADAAAAGAAYAG4AAAAKAQoBhgAAAAoACgBIAAAAEgASA
   HTTP: Cookie =ASP.NET_SessionId=uqnwgpygpf0dh2iwysznat55
   

   NOTA: algumas das variáveis HTTP nestes exemplos poderão ser diferentes no seu ambiente.
2. O servidor recebe o pedido e envia uma resposta 200 juntamente com os dados que são pedidas. Porque o cliente enviar o cabeçalho If-None-Match, IIS 6.0 tem de incluir um cabeçalho de resposta ETag e valor de cabeçalho na respectiva resposta. Esta resposta se assemelhe ao seguinte:

   HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
   HTTP: Protocol Version =HTTP/1.1
   HTTP: Status Code = OK
   HTTP: Reason =OK
   HTTP: Content-Length =51622
   HTTP: Content-Type =text/x-component
   HTTP: Last-Modified =Tue, 16 Nov 2004 17:11:48 GMT
   HTTP: Accept-Ranges =bytes
   HTTP: ETag ="0222d5bffcbc41:3246"
   HTTP: Server =Microsoft-IIS/6.0
   HTTP: X-Powered-By = ASP.NET
   HTTP: Date =Tue, 27 Sep 2005 12:18:27 GMT
   HTTP: Data: Number of data bytes remaining = 1202 (0x04B2)
   

3. O cliente recebe a resposta. A resposta tem um estado de HTTP 200, em vez do estado de HTTP 304 o browser foi esperado. Por conseguinte, o browser envia um RST TCP para restabelecer a ligação. Isto acontece porque o Internet Explorer acredita que o servidor enviou o estado de HTTP 200 por engano. RST TCP se assemelhe ao seguinte:

   TCP: Control Bits: .A.R.., 
   TCP: Source Port = 0x0747
   TCP: Destination Port = World Wide Web HTTP
   TCP: Sequence Number = 3840808344 (0xE4EE1598)
   TCP: Acknowledgement Number = 3150159894 (0xBBC3A016)
   TCP: Data Offset = 20 bytes
   TCP: 0101.... = Data Offset (20 bytes)
   TCP: ....0000 = Reserved bits
   TCP: Flags = 0x14 : .A.R..
   TCP: ..0..... = No urgent data
   TCP: ...1.... = Acknowledgement field significant
   TCP: ....0... = No Push function
   TCP: .....1.. = Reset the connection
   TCP: ......0. = No Synchronize
   TCP: .......0 = Not the end of the data
   TCP: Window = 0 (0x0)
   TCP: Checksum = 0xF26C
   TCP: Urgent Pointer = 0 (0x0)
   

   para obter mais informações sobre TCP (Transmission Control Protocol), visite a seguinte página Web:
   http://www.faqs.org/rfcs/rfc793.html (http://www.faqs.org/rfcs/rfc793.html)