Eu corri para um problema de rede que não consigo resolver. em alguns computadores que executam o windows 8.1 e se comunicam com conexões linux http server tcp pendurados no lado do Windows, em vez de serem fechados corretamente.
após a resposta [fragmentada em poucos, reconhecida pelo windows, tcp packets] linux server - 10.14.11.59 - envia um pacote tcp contendo FIN e ACK flags set.
istoéreconhecidopelamáquinawindows-10.14.10.195-comopacotetendoapenasosinalizadorACKdefinido.
O linux reenvia os pacotes com sinalizadores FIN e ACK algumas vezes enquanto a máquina Windows - por algum motivo, ainda mantém a conexão aberta; Pacotes com o sinalizador RST nunca são enviados pela máquina Windows.
seissoacontecer,oaplicativodoWindowsaguardae,eventualmente,expira.issoacontecealeatoriamenteemalgumlugarentre10-50%dastentativas.
otráfegoentreasduasmáquinasnãoéfiltrado;Firewallsbaseadosemhostforamdesativados.paraevitarpossíveisproblemaseudesabiliteiodescarregamentodetcpnolinuxenowindows.Alémdisso,noWindows,foramexecutadososseguintesprocedimentoseamáquinafoireinicializada:
netshinttcpsetglobalchimney=disablednetshinttcpsetglobalautotuninglevel=disablednetshinttcpsetglobalrss=disabledcapturadepacotes:
qualquer pensamento será apreciado!
descobrimos que a segurança do ponto de extremidade eset em execução nas máquinas clientes foi o culpado.
desativar a funcionalidade do firewall não foi suficiente; mas a desinstalação resolveu completamente o problema.
meus colegas encontraram a descrição de um problema semelhante aqui ; aparentemente, atualizar para a versão mais recente do eset resolveu o problema também.
Eu assumo que o primeiro segmento no seu tcpdump é precedido por um FIN do cliente.
Acredito que este é o comportamento correto do cliente, como ilustrado por este diagrama ASCII da RFC original
Um cliente de fechamento, ao receber um FIN,ACK do servidor, o soquete transita de FIN-WAIT1 para TIME-WAIT e permanece nesse estado por 2 vezes a Duração máxima do segmento na rede, quando envia um FIN de volta, para fechar a conexão.
O Windows substitui a duração TIME-WAIT por um nome de valor de registro TcpTimedWaitDelay , implementado originalmente com um valor padrão de 240 segundos (o padrão MSL é de 120 segundos). No Windows XP / Server 2003 e superior, o valor padrão é reduzido para 120 segundos.
Acredito que você possa resolver isso fechando o soquete subjacente no servidor quando tiver atendido a resposta, mas não se esqueça de ler esta resposta também , para aproximadamente a mesma pergunta, mas a partir de uma perspectiva de servidor