O Windows Server demora muito para enviar o SYN-ACK

Question

Temos um Windows Server 2012 R2 que hospeda nossos sites no IIS. Também temos um servidor Ubuntu 16.04 que executa o Nginx 1.10.3 para fazer proxy de solicitações recebidas para nosso servidor Windows backend. Esses dois servidores são executados como VMs no ESXi.

Notamos que o nosso Windows Server às vezes demora muito para enviar o SYN-ACK em resposta aos SYNs recebidos.

Veja como é a saída do windfall no servidor Windows (como você pode ver, somente após 63 segundos e 7 SYNs o Windows enviou o SYN-ACK correspondente):

11:26:59.080471 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60011765 ecr 0,nop,wscale 7], length 0
11:27:00.075553 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60012015 ecr 0,nop,wscale 7], length 0
11:27:02.078881 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60012516 ecr 0,nop,wscale 7], length 0
11:27:06.086875 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60013518 ecr 0,nop,wscale 7], length 0
11:27:14.094838 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60015520 ecr 0,nop,wscale 7], length 0
11:27:30.126966 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60019528 ecr 0,nop,wscale 7], length 0
11:28:02.224731 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [S], seq 3338047317, win 29200, options [mss 1460,sackOK,TS val 60027552 ecr 0,nop,wscale 7], length 0
11:28:02.224789 IP 192.168.20.2.80 > 192.168.20.129.41784: Flags [S.], seq 2819099122, ack 3338047318, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 215763098 ecr 60027552], length 0
11:28:02.225363 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 60027552 ecr 215763098], length 0
11:28:02.225900 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [P.], seq 1:76, ack 1, win 229, options [nop,nop,TS val 60027552 ecr 215763098], length 75: HTTP: GET /ping?id=141 HTTP/1.1[!http]
11:28:02.248577 IP 192.168.20.2.80 > 192.168.20.129.41784: Flags [FP.], seq 1:224, ack 76, win 260, options [nop,nop,TS val 215763100 ecr 60027552], length 223: HTTP: HTTP/1.1 200 OK
11:28:02.253096 IP 192.168.20.129.41784 > 192.168.20.2.80: Flags [F.], seq 76, ack 225, win 237, options [nop,nop,TS val 60027559 ecr 215763100], length 0
11:28:02.253144 IP 192.168.20.2.80 > 192.168.20.129.41784: Flags [.], ack 77, win 260, options [nop,nop,TS val 215763101 ecr 60027559], length 0

O mais estranho é que, se alterarmos o IP de origem (via proxy_bind do Nginx) ou a porta de destino (no IIS), os tempos de resposta serão bastante aprimorados.

Como podemos descobrir o que está causando esse comportamento?

Atualização 1: Alteramos o parâmetro TcpTimedWaitDelay para 30 segundos e a situação está muito melhor agora, mas ainda temos o problema.

Atualização 2: Esta é a soma dos estados de conexão relatados pelo netstats:

  64 CLOSE_WAIT
1371 ESTABLISHED
   1 FIN_WAIT_1
  51 LISTENING
3188 TIME_WAIT

    

Answer 1

Até onde sei, é possível que o bom e velho Nagle seja colocando suas bolas aqui . Eu recomendaria que você teste desligasse e também reduzisse o contador interno de ticks-to-reply.

Isso é feito no registro:

• Em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{YOUR-NIC}
  • Crie um DWORD TCPNoDelay com o valor de '1'
  • Crie um DWORD TcpAckFrequency com o valor de '1'
  • Crie um DWORD TcpDelAckTicks com o valor de '0' ( mais )

Uma reinicialização é necessária para ativá-los. Você pode verificar suas configurações com Get-NetTCPSetting .