O Windows 7 pára de responder à solicitação TCP após o horário aleatório

0

Bem-vindo a todos

Estou procurando algumas dicas (perfeitamente uma solução :)) para um problema que enfrentamos há muito tempo.

Basicamente: temos um aplicativo cliente que fica em um Windows Server 2012 e um aplicativo de servidor que fica em um Windows 7.

O cenário é assim:

  1. O cliente se conecta ao servidor via TCP
  2. O servidor aceita conexão e envia uma mensagem de boas-vindas
  3. O cliente envia uma mensagem com alguns dados
  4. O servidor envia uma resposta (uma confirmação de que recebeu a mensagem)
  5. O cliente fecha a conexão

Aviso:

  1. O cliente abre uma conexão para cada nova mensagem. Eu verifiquei os logs do Wireshark, bem como os logs do cliente / servidor, e todas as conexões foram fechadas corretamente.
  2. Mesmo que meu aplicativo não esteja lidando com a conexão de maneira correta, o Windows não deve sempre responder a solicitações de conexão com algum tipo de ACK / RST?

Problema: Depois de algum tempo aleatório (pode levar 30 minutos ou até uma semana ou duas), o aplicativo do servidor para de enviar respostas. Investigações posteriores (registros Wireshark) mostram que em algum momento:

  1. O aplicativo do servidor não responde com a mensagem "confirmação" (# 4 no "cenário").
  2. O aplicativo do servidor não responde ao FIN do cliente (provavelmente porque o aplicativo do servidor não fecha ativamente a conexão)
  3. O cliente envia o RST após 2 minutos (FIN expirou)
  4. O servidor pára de responder a qualquer solicitação TCP nessa porta (não há ACKs / RSTs, nada ...)

Veja a imagem abaixo: link

    
por jak tek 04.09.2017 / 14:23

1 resposta

0

Não está claro onde o problema realmente está. É a rede? É o aplicativo do servidor? É o computador / hardware / firewall do servidor, etc.? É o computador cliente?

Algumas soluções de problemas precisam ser feitas para saber onde procurar.

Aqui está o que eu faria. Quando o aplicativo está funcionando corretamente, no servidor, abra um prompt de comando administrativo (clique com o botão direito do mouse, execute como administrador). Use o comando netstat -abn | more e revise o conteúdo. Você receberá uma lista de conexões de rede ativas e auditivas, classificadas por protocolo e número de porta. Você deve ser capaz de identificar seu aplicativo de servidor escutando na porta em questão e deve mostrar o nome do executável. Se alguma conexão ativa for estabelecida, você também verá as conexões "estabelecidas" listadas. Agora você sabe o que parece quando está funcionando corretamente.

Agora, eu também adicionaria o cliente Telnet para testes simples. O cliente Telnet é um recurso do Windows que você pode adicionar. É ótimo para testar conexões TCP simples. Quando tudo estiver funcionando, abra um prompt de comando no servidor e use o comando telnet localhost <port> - substitua pelo número da porta em que seu aplicativo atende. Você deve obter pelo menos uma tela em branco indicando que a conexão foi bem-sucedida. Se não for bem sucedido, você obterá um tempo limite após um pouco. Obviamente, não deve tempo limite ou você definitivamente tem algo bloqueando conexões (mesmo que os clientes pareçam estar trabalhando agora).

Agora, quando o problema ocorrer, você poderá usar o comando netstat e o comando telnet para ajudar a determinar onde está o problema. Primeiro, use o netstat para confirmar que o aplicativo ainda está escutando na porta que ele deveria estar ouvindo. Se não for, o problema está no seu aplicativo ou como ele interage com o sistema operacional.

Se o aplicativo estiver escutando corretamente, você poderá usar o telnet a partir do host local e de computadores Windows remotos para ver onde a conexão está bloqueada. Ou seja, se você puder fazer telnet para o host local no servidor com sucesso, você sabe que o aplicativo ea pilha de rede estão funcionando bem e que alguma coisa no servidor ou na rede está bloqueando a conexão (firewall, software de segurança, etc.). Você também pode tentar telnet <local ip> <port> em vez de usar localhost . Se um funciona e o outro não, este é outro indicador de algo bloqueando a conexão no servidor, ou o ouvinte pode estar configurado incorretamente.

Eu estaria à procura de software de segurança instalado no servidor ou no cliente. Especialmente os "pesados" como McAfee ou Norton. Esses produtos são a causa de muitas esperanças e sonhos frustrados. Não basta desativá-los e excluí-los da lista. Desinstalá-los - essa é a única maneira de ter certeza, e mesmo assim, às vezes, eles quebram as coisas e precisam de mais trabalho de limpeza.

Sem mais detalhes aprofundados sobre sua infraestrutura de rede e servidor / aplicativo, não há mais respostas a serem fornecidas. É tudo sobre solução de problemas e eliminar onde está o problema.

    
por 05.09.2017 / 18:35