Precisa de ajuda para solucionar problemas de rede (Conexões TCP do cliente bloqueadas em FIN_WAIT_2)

0

(Nota: eu originalmente fiz esta pergunta no lado "Engenharia de Rede", mas um moderador rejeitou-a como "off topic" e me disse para perguntar aqui).

Estou executando um servidor de vigilância por vídeo chamado ZoneMinder (versão 1.26.5) em uma caixa Linux do Fedora 18. O ZoneMinder tem uma interface de usuário baseada na web e usa um executável CGI chamado "zms" para transmitir um fluxo de vídeo MJPEG para um navegador da Web sobre TCP. O problema é que, às vezes, a conexão de fluxo de vídeo não termina corretamente; se eu estiver visualizando um fluxo de vídeo e fechar a janela do navegador, a conexão TCP subjacente permanecerá aberta e o processo zms no servidor continuará enviando quadros de vídeo pela rede. Isso ocorre mesmo se eu terminar TODAS as instâncias do navegador na máquina Windows (verificada usando o Gerenciador de Tarefas). Minha expectativa é que o Windows desligue imediatamente a conexão TCP quando o processo do navegador terminar, mas por alguma razão desconhecida isso nem sempre acontece, e o Windows continua aceitando pacotes na conexão indefinidamente. Quando esse problema ocorre, o processo zms no servidor ainda vê a conexão como aberta e continuará transmitindo vídeo até que a máquina Windows seja desligada ou o processo zms seja eliminado (manualmente, a partir do shell de comando). Ao rever os eventos de vigilância, não é incomum acumular uma dúzia ou mais desses processos zms "zumbis"; se eu não fizer logon na máquina do servidor ZoneMinder via SSH e eliminar esses processos manualmente, eles continuarão a ser executados indefinidamente, consumindo largura de banda de E / S de disco e rede e sobrecarregando o restante do sistema.

Uma vez no estado com falha, a execução do netstat na máquina Windows mostra que a conexão TCP está no estado FIN_WAIT_2. Uma captura do Wireshark mostra que a máquina Windows ainda está reconhecendo segmentos na conexão, mesmo que não haja mais um processo em execução recebendo esses dados.

Eu tenho 3 máquinas Windows: uma área de trabalho com o Windows 7 Pro SP1, uma área de trabalho com o Win 7 Home Premium SP1 e um laptop com o Win 7 Home Premium SP1. Destes três, as duas máquinas desktop exibem o problema de forma intermitente, enquanto o laptop nunca exibe o problema.

Eu normalmente uso o navegador Firefox, mas também experimentei o Chrome. Ambos funcionam 100% no laptop e falham intermitentemente nos desktops. Usando o Firefox e o Chrome em outras plataformas que eu tentei, como Linux e Android, nunca exibo o problema.

Uma das máquinas com Windows que falha está conectada ao mesmo comutador gigabit que a caixa do servidor ZoneMinder; o laptop Windows que sempre funciona está conectado a um ponto de acesso WiFi e chega ao servidor ZoneMinder por meio de um segundo switch GigE. Os dispositivos Android conectam tanto de dentro quanto de fora do firewall sem problemas.

Para eliminar a possibilidade de um problema de driver de rede, em uma das máquinas desktop eu tentei trocar a placa de rede Realtek por uma placa de rede Intel, mas a falha ainda ocorre.

Eu agora estou sem ideias; Como posso resolver isso mais? Eu posso fornecer capturas Wireshark se isso for útil (elas são grandes - ~ 100MB - então eu as deixei por enquanto).

Obrigado pela sua ajuda!

    
por dvarapala 16.06.2014 / 21:20

1 resposta

1

O estado do TCP FIN_WAIT_2 significa que o aplicativo foi fechado e o cliente enviou um FIN para o servidor. O servidor envia um ACK e deve informar ao servidor de aplicativos para iniciar o desligamento. Então deve enviar um FIN para o cliente. Seu cliente está esperando no servidor para enviar seu FIN.

Suas máquinas Windows exibindo o comportamento talvez usando TCP Descarregamento de chaminés , que transfere algumas tarefas domésticas de TCP para a NIC, por exemplo ACKING dados e fechamento de conexões. Quando o aplicativo é fechado, a NIC assume o controle do fechamento final da conexão. Pode ser por isso que a sua máquina continua a aceitar os dados do ACK, mesmo que o navegador esteja fechado.

Você pode tentar atenuar o problema desabilitando o TCP Chimney no Windows. As instruções são aqui .

No entanto, isso não resolve a causa raiz do motivo pelo qual o servidor não envia um FIN. Com as capturas de tráfego no cliente e no servidor, você pode:

  1. Verifique se o cliente envia um FIN
  2. Verifique se o servidor recebe o FIN
  3. Verifique se o servidor envia uma FIN
  4. Verifique se o cliente recebe o FIN

Provavelmente, há uma lacuna em um desses passos. Se todas as etapas forem concluídas, o problema estará no cliente e poderá ser o TCP Chimney Offloading.

    
por 18.06.2014 / 01:20

Tags