Você pode enfrentar desempenho ruim da Web ao usar o Internet Explorer 6 para tentar acessar um aplicativo Web que está hospedado no Internet Information Services 6.0

Traduções deste artigo Traduções deste artigo
ID do artigo: 922703 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Sintomas

Considere o seguinte cenário:
  • Você usar a autenticação integrada do Windows em um ambiente de aplicativo Web do Internet Information Services 6.0 (IIS 6.0).
  • Você usar o Microsoft Internet Explorer 6 para acessar um aplicativo Web que está hospedado no IIS 6.0.
Nesse cenário, talvez haja fraco desempenho do aplicativo da Web.

Observação O problema não ocorre se a autenticação anônima é usada como o protocolo de autenticação. Esse problema também não ocorre se o navegador do cliente for um navegador diferente do Internet Explorer 6, como o Mozilla Firefox.

Causa

Esse problema ocorre porque o cliente do Internet Explorer 6 regularmente redefine as conexões TCP.

Se você analisar um rastreamento de rede que é capturado durante a comunicação mal execução entre o cliente e o servidor, o rastreamento de rede mostra que o TCP redefine ocorrerá após o cliente recebe uma resposta 200 para o recurso que o cliente solicitou. O cliente faz as solicitações GET com um cabeçalho ETag HTTP e valor. Quando o servidor que esteja executando o IIS 6.0 recebe a solicitação, ele compara o valor de ETag e localiza o valor de ETag corresponde ao valor atual de ?s o arquivo solicitado, exceto para o número de alteração.

Observação Cabeçalhos de ETag aparecem no seguinte formato:

Filetimestamp: ChangeNumber

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

O número de Filetimestamp na solicitação é o mesmo número que o IIS 6.0 considera o valor atual para o recurso de solicitação. Mas porque o número ChangeNumber na solicitação é diferente, o IIS 6.0 envia de volta a versão atual do arquivo em vez de indicar para servir sua própria cópia em cache. Há um código específico no Internet Explorer que compara o Filetimestamp em uma resposta 200 com o Timestamp da cópia em cache local. A conexão será redefinida se eles forem o mesmo número. Isso ocorre porque o cliente do Internet Explorer espera receber um relatório de 304 status se o conteúdo é o mesmo.

Em outras palavras, o IIS 6.0 envia uma resposta 200 porque ele considera os números de alteração diferente para significa que o recurso é solicitado pelo cliente e por versão de pré-existente ?s cliente deste recurso que reside no cache do navegador não são as mesmas versões. No entanto, o Internet Explorer considera sejam as mesmas versões porque Filetimestamp é o mesmo. Além disso, o Internet Explorer acredita que ele está recebendo a resposta 200 em erro. Nesse cenário, o Internet Explorer redefine a conexão TCP.

Como Contornar

Se você estiver usando um computador baseado no Microsoft Windows Server 2003

Para contornar esse problema, recomendamos que você rígido código o número de alteração no servidor Web e que você sincronizar a versão do arquivo para todos os clientes do Internet Explorer. Todos os clientes do Internet Explorer terá versões de todos os arquivos diferentes que são necessários para o aplicativo. Você deve certificar-se que o servidor e todos os clientes estão sincronizados.

Observação Se você estiver executando em um ambiente de farm da Web do IIS 6.0, você precisará código rígido o mesmo número de alteração para todos os servidores que estejam executando o IIS 6.0 no farm..

Para sincronizar os valores de números de alteração entre os clientes e o servidor, siga estas etapas.
  1. código rígido manualmente o valor de ETag na 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).

    Observação Talvez haja um problema quando você altera o valor de ETag e você deve instalar um hotfix para corrigir esse problema. Para obter mais informações sobre o hotfix, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    900245O valor no campo ETAG é atualizado quando você modifica uma propriedade da metabase no IIS 6.0
    Depois de instalar o hotfix, você pode manualmente código rígido o ETag alterar número. No entanto, a configuração para o número de alteração de ETag não é exposta ao namespace do Active Directory Service Interfaces (ADSI). Portanto, você deve usar a ferramenta Metabase Explorer para definir o valor por identificação de propriedade. Para baixar e instalar o Metabase Explorer, visite o seguinte site:
    http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36 -5761-448f-889e-9ae58d072c09.mspx
    Observação Metabase Explorer está incluída no IIS 6.0 resource kit.

    Para código rígido manualmente o ETag alterar número, execute estas etapas:
    1. Abra o Metabase Explorer, expanda LM no painel esquerdo e, em seguida, expanda W3SVC .
    2. Clique duas vezes o registro de identificação 2039 no painel à direita. Se o registro de identificação 2039 não estiver presente, você deve criá-la. Para fazer isso, execute as seguintes etapas:
      1. Clique com o botão direito do mouse o nó W3SVC no Gerenciador de Metabase, aponte para Criar novo e, em seguida, clique em valor DWORD .
      2. Defina o identificador do novo DWORD como 2039 .
      3. Defina o valor do novo DWORD para 0 .
    3. Digite 0 na caixa valor .

      Observação O número que você digite dentro da caixa de valor deve ser de 0 a 4294967295. Além disso, todos os servidores do farm devem ter o número idêntico na caixa valor . Para obter mais informações, visite o seguinte site:
      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 .
    Observação Se você estiver executando servidores IIS 6.0 em um ambiente de farm da Web do IIS 6.0, repita etapas 1a através de d 1 em todos os servidores IIS 6.0 no farm. Certifique-se de que você adicionar que o mesmo alterar o valor de número em todos os servidores.
  2. Limpar o cache do navegador cliente no Internet Explorer

    Se houver muitos navegadores de cliente para limpar o cache manualmente, selecione Ativar expiração de conteúdo no IIS 6.0 e, em seguida, especificar que o conteúdo expire imediatamente. Nesse cenário, você precisa deixar Ativar expiração de conteúdo ativado para somente, contanto que leva para todos os clientes possuem conteúdo atualizado. Em seguida, você precisará desativar Ativar expiração de conteúdo para dar o Internet Explorer a oportunidade de servir conteúdo armazenado em cache novamente. Para Ativar expiração de conteúdo, siga estas etapas:
    1. Abra o Internet Information Services.
    2. Expanda LocalMachine no painel esquerdo e, em seguida, clique em Sites .
    3. Clique com o botão direito do mouse Sites e, em seguida, clique em Propriedades .
    4. Na guia Cabeçalhos HTTP , clique para selecionar a caixa de seleção Ativar 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.
    Observação Um cliente talvez tenha de fazer duas solicitações para um recurso depois que a caixa de seleção Ativar expiração de conteúdo é habilitada para atualizar o cache do Internet Explorer.

Se você não estiver usando um computador baseado no Windows Server 2003

Para contornar esse problema, habilite a opção Ativar expiração de conteúdo no IIS 6.0 usando o procedimento descrito na seção "Limpar o cache de navegador do cliente no Internet Explorer" e deixá-lo no. Além disso, desativar o cache no Internet Explorer ou definir cabeçalhos de controle de cache no aplicativo da Web. Para obter mais informações sobre como impedir que o cache de Web, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
311006Como impedir o cache de Web no Windows 2000

Situação

Windows Internet Explorer 7 foi modificada para tratar corretamente o número de alteração ETag de acordo com RFC 2616. No entanto, se o número de ETag for alterado, Windows Internet Explorer 7 baixará o arquivo completo em vez de cancelar a conexão. Esse comportamento pode diminuir o desempenho do Internet Explorer 7 em comparação com o Internet Explorer 6.

Mais Informações

Se você analisar um rastreamento do Monitor de rede que é capturado no cliente ou no servidor e esse rastreamento está envolvido no cenário de desempenho, você verá a seguinte seqüência:
  1. O cliente envia a solicitação GET para o servidor que está executando o IIS 6.0 e a solicitação inclui um cabeçalho If-None-Match com um Filetimestamp: valor ChangeNumber. Essa solicitação semelhante à 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
    
    Observação algumas das variáveis HTTP nesses exemplos podem ser diferentes em seu ambiente.
  2. O servidor recebe a solicitação e enviará uma resposta 200 juntamente com os dados que são solicitados. Como o cliente enviou o cabeçalho If-None-Match, IIS 6.0 tem que incluir um cabeçalho de resposta ETag e valor de cabeçalho na sua resposta. Essa resposta semelhante à 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 status de HTTP 200, em vez do status de HTTP 304 que o navegador estava esperando. Portanto, o navegador envia um RST TCP para redefinir a conexão. Ele faz isso porque o Internet Explorer acredita que o servidor enviou o status de HTTP 200 em erro. O RST TCP semelhante à 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 o seguinte site:
    http://www.faqs.org/rfcs/rfc793.html

Propriedades

ID do artigo: 922703 - Última revisão: quinta-feira, 7 de junho de 2007 - Revisão: 3.2
A informação contida neste artigo aplica-se a:
  • Microsoft Internet Explorer 6.0
  • Microsoft Internet Information Services 6.0
Palavras-chave: 
kbmt kbtshoot kbprb KB922703 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 922703

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com