Como fazer com que o Windows honre uma mensagem ICMP Connection Refused após uma tentativa de conexão TCP

Question

Temos uma ferramenta que é usada para gerenciar um processo do servidor remotamente por TCP. Um dos recursos de ferramentas é verificar se o servidor está em execução, tentando conectar-se ao servidor em um loop por um determinado período de tempo.

Quando usamos a ferramenta para verificar se um servidor não estava sendo executado, percebemos que a precisão dos tempos estava muito baixa no Windows, por exemplo, tentar conexões de 2s para um servidor morto resultaria na execução da ferramenta por 7s em vez dos 2s esperados, enquanto no Linux os tempos são precisos em alguns milissegundos. O problema aqui é que usamos a ferramenta em scripts de inicialização que o atraso em declarar o servidor como morto aumenta o tempo de execução dos scripts de inicialização.

Acontece que o culpado parece ser a pilha TCP / IP do Windows: uma tentativa de conexão com falha para uma porta local no Windows leva 2-5s para terminar, dependendo da máquina, enquanto no Linux é quase instantânea. A teoria é que a pilha do Windows não respeita / não está interessada na mensagem ICMP Connection Refused retornada pelo servidor e continua com outra tentativa de conexão.

Portanto, há duas partes na minha pergunta: i) a teoria acima parece plausível, e ii) como posso dizer ao Windows para honrar a resposta do ICMP?

- Lauri

    

Answer 1

Alguém respondeu que a resposta real do servidor é uma mensagem TCP RST em vez de uma mensagem ICMP, mas essa resposta foi excluída desde então.

De qualquer forma, explorei mais um pouco e observei alguns traços de falha nas tentativas de conexão do Wireshark:

i) a resposta é de fato um TCP RST, ACK em vez de uma mensagem ICMP como eu pensava que seria

ii) a pilha TCP / IP do Windows é implementada para repetir a tentativa de conexão após um RST, com o ACK esperando que o servidor possa ter magicamente reaparecido dentro do tempo limite de conexão [1]

iii) o administrador pode definir o registro TcpMaxConnectRetransmissions em HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters para um valor menor que o padrão 3 (WinNT) ou 2 (Win2k).

Assim, a resposta é ajustar o registro e reduzir TcpMaxConnectRetransmissions para 0 ou 1. Meu único problema com essa 'solução' é que o AFAICT também afetará as tentativas de conexão em que o SYN inicial é descartado na rede. o valor para 0 é uma má idéia, e defini-lo como 1 ainda resultará em um tempo de execução maior que o necessário para meus scripts.

[1] Para obter mais informações: link

- Lauri