O que se segue é uma descrição do problema de rede mais estranho que encontrei.
A história
Estou trabalhando com um cliente que relatou ser incapaz de verificar seu e-mail, a partir desta manhã. Duas semanas atrás, eles concluíram uma grande atualização que substituiu todos os PCs e um novo servidor SBS foi adicionado ao domínio do Windows.
O cliente obtém emails por POP3 usando o Outlook 2010 no Windows 7, mas as mensagens não estão sendo recebidas. A janela de andamento Enviar / Receber indica que o download está parado em cerca de 1% de conclusão.
Eu tentei conectar-me ao servidor POP3 usando um cliente telnet e observei um comportamento semelhante. Depois de emitir o comando RETR 1 , vi pequenos pedaços de dados (cerca de 1K) chegando, com pausas cada vez maiores entre eles. Entre pedaços de dados, as pausas parecem dobrar de tamanho - observei pausas que duraram 1, 3, 7, 14 e 28 segundos. Eu parei de contar depois disso.
Executar o mesmo teste de download de uma mensagem POP3 executando telnet em um Terminal Server (Svr 2008 Std) no mesmo domínio gerou os mesmos resultados.
Em seguida, carregou um pequeno script PHP que retornaria uma página de tamanho arbitrário para um servidor na Internet e tentaria acessá-lo a partir do Terminal Server na LAN. Eu testei vários tamanhos de 1K a 1MB, e não foram observadas baias. HTTP parece não ser afetado.
Por fim, conectei meu laptop pessoal (não um membro do domínio) à rede e testei novamente o POP3 - a mensagem inteira foi baixada imediatamente.
Atualização (2011-03-10)
Eu usei o Wireshark para obter uma clara captura de pacotes da conversa POP3 hoje. A conversa inicial (USER, PASS, LIST) funciona como esperado com o servidor respondendo imediatamente. (Os resultados da LIST se encaixam em um único pacote.) Depois que o comando RETR é emitido e a mensagem começa a ser transmitida, os atrasos começam. Minha estimativa anterior estava um pouco fora, e os atrasos são realmente da duração esperada: 1, 2, 4, 8, 16 segundos, etc. O cliente está enviando ACKS imediatamente, dentro de 200 ms de cada pacote recebido.
Além disso, tentamos conectar uma das estações de trabalho afetadas diretamente à Internet e conseguimos fazer o download de mensagens a toda velocidade. Neste ponto, eu suspeito strongmente que o roteador (um Cisco 1711) está com defeito, mas eu não sei o suficiente sobre o IOS para conduzir diagnósticos adicionais.
O que eu sei
O que eu não sei
Como administrador, execute o seguinte na linha de comando do cliente:
netsh interface tcp set global autotuninglevel=disabled
Isso desabilita o dimensionamento da janela TCP? O problema persiste? Caso contrário, o problema está em algum lugar entre o cliente e o servidor no equipamento de rede, incluindo cabos, interfaces de rede e seus drivers, switches e roteadores.
Existe algum tipo de software de firewall ou software antivírus instalado? Ele pode interceptar todo o tráfego da porta 110 para executá-lo em seu banco de dados de vírus. Isso pode estar causando lentidão. A forma como ele mostra 1kb sugere que, se for um AV, ele pode estar atrelando a CPU / disco IO / etc.
Tente inicializar o Monitor de Recursos (Iniciar Gerenciador de Tarefas (Ctrl + Shift + Esc), Desempenho, Monitor de Recursos) e observar a lista de processos da CPU e do Disco para ver se há algum processo específico ocorrendo durante o download de uma mensagem. (Eu sugiro testar com telnet ainda só para evitar poluir os dados com o Outlook / etc).
Você também pode querer dar uma olhada no tráfego com um sniffer de pacotes para mais dicas. Eu estou querendo saber se talvez o cliente (devido a AV, ou qualquer motivo) é realmente lento em retornar os ACKs para os pacotes do servidor, e isso está causando o TCP congestion avoidance para continuar a aumentar o backoff e, assim, atrasar entre cada pacote. Para o melhor da minha memória, um pouco mais de 1KB teria você sentado em torno do tamanho máximo do segmento (tamanho de um pacote individual), o que faria sentido por que você está recebendo apenas tantos dados por "burst". (Aviso: Meu conhecimento nesta área é antigo e desbotado. Não confie muito nele.)
Se for o backoff do TCP, também pode ser devido a pacotes descartados, mas duvido que todas as novas máquinas tenham um cabo defeituoso ou algo assim. Parece mais provável que seja um problema de software, já que imagino que eles são todos da mesma forma.
EDITAR: Com base nas informações fornecidas e na outra resposta da adamo, encontrei um artigo da Base de Dados de Conhecimento da Microsoft que parece abordar diretamente o seu problema:
Especificamente, diz que o problema é:
"This problem occurs if a network hardware device, such as a router, does not support TCP Window Scaling. TCP Window Scaling is a new Windows Vista feature."
A execução do comando fornecido pelo adamo é uma correção. Parece que você também pode atualizar o roteador. Observando o navegador de recursos no site da Cisco, parece que o TCP Window Scaling é suportado nas versões mais recentes do IOS para o seu site. hardware. Se você obtiver uma nova imagem do seu roteador e exibi-la, deverá resolver o problema sem perder os benefícios do escalonamento da janela TCP.