TCP Initial Handshake Incomplete (ACK ausente)

Question

Estou irritado com o seguinte cenário:

Estou executando um aplicativo MVC em um IIS 10 Webserver . Ao chamar o URI, leva cerca de 10 segundos até o aplicativo começar a ser chamado (tempo IDLE). Não tendo nenhuma explicação real para o ocioso, comecei a cavar mais fundo usando wireshark e tropeçar no seguinte fenômeno:

O handshake TCP inicial está incompleto (ACK ausente)

1. Client -> Server (SYN)
2. Server -> Client (SYN, ACK)
3. Client -> Server (ACK never reaches the server)

Note: The topology is as described below. The client gets redirected to Server2 after the first request. Client -> Gateway -> Router -> Server1 -> Server2

Eu usei wireshark no lado do cliente, assim como no lado do servidor. O servidor reenvia a tupla SYN, ACK duas vezes, após cerca de 10s de tempo IDLE, a conexão é estabelecida mesmo assim. Observando o RFC apropriado, esse comportamento é normal (o ACK é enviado pelo cliente indiretamente durante o envio dos dados). O ACK nunca alcança o roteador, então onde ele poderia se perder? E por que se perder cada vez? Poderia ser alguma configuração de roteador ( Mikrotik ), como No-ACK ? A falta do ACK é o motivo do atraso dos 10s no IDLE?

EDITAR:

Eu editei a topologia acima. Você encontra os traços do wireshark abaixo:

• Client_Trace
• Router_Trace
• Server1_Trace
• Server2_Trace

Devido ao processo de anonimização no TraceWrangler, os endereços IP variam de rastreamento para rastreamento da seguinte maneira:

Client IP: 192.168.248.249 <=> 172.23.147.181 <=> 192.168.201.209 <=> 10.206.108.221
Router IP: 10.194.30.227 <=> 172.17.84.111
Server1 IP: 172.31.124.208 <=> 10.100.24.4
Server2 IP: 172.20.78.56 <=> 192.168.204.149

Você pode usar os filtros a seguir para ter uma ideia clara do handshake inicial:

Filter Client: (((ip.dst ==192.168.248.249) && (ip.src ==10.194.30.227)) || ((ip.dst ==10.194.30.227) && (ip.src ==192.168.248.249))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Router: (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Server1: (((ip.dst ==172.31.124.208) && (ip.src ==192.168.201.209)) || ((ip.dst ==192.168.201.209) && (ip.src ==172.31.124.208)) || ((ip.dst ==172.31.124.208) && (ip.src ==172.20.78.56)) || ((ip.dst ==172.20.78.56) && (ip.src ==172.31.124.208))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Server2: (((ip.dst ==10.100.24.4) && (ip.src ==10.206.108.221)) || ((ip.dst ==10.206.108.221) && (ip.src ==10.100.24.4)) || ((ip.dst ==10.100.24.4) && (ip.src ==192.168.204.149)) || ((ip.dst ==192.168.204.149) &&(ip.src ==10.100.24.4))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

    

Answer 1

Você não vai acreditar, mas o problema foi resolvido enquanto isso, eu realmente não entendo, porque a seguinte mudança no RouterOS garante que o ACK não seja mais perdido, e o aplicativo é carregado com pressa, mas estou realmente aliviado com isso: dentro das listas Route do RouterOS, o IP do Gateway foi inserido como um endereço IP em vez de um nome de interface / nome DNS.

Você tem alguma explicação para esse problema? A tradução / pesquisa leva tantos segundos e o ACK é ignorado nesse meio tempo? Eu sempre tive a sensação de que isso tem que ser um problema no RouterOS, mas eu não tinha ideia de como rastreá-lo. Que coincidência de sorte que o nosso administrador estava jogando com as tabelas do roteador, e me pediu para verificar o tempo de carga novamente. Essa pode realmente ser a única mudança? Consegui confirmar em wireshark, que o ACK não se perdeu mais.

EDITAR:

Eu exportei as configurações de rota ip abaixo para ver as diferenças na rota:

• Trabalhando: adicionar distância = 1 dst-address = 33.2.1.0 / 24 gateway = 33.2.4.1 pref-src = 33.2.4.211
• Estado antigo: adicionar distância = 1 endereço-dst = 33.2.1.0 / 24 gateway = ETH2 pref-src = 33.2.4.211

O gateway não está explicitamente definido na lista de endereços, apenas no roteador:

• Endereço: 33.2.4.211/24 | Rede: 33.2.4.0 | Interface: ETH2

Então, o que acontece tecnicamente e de onde vem o atraso e a falta de ACK?