TCP SYN, ACK Retransmissões

Question

O seguinte rastreio de rede foi gravado em um PI Raspberry que executa o Debian Linux. Parece que o Raspberry não está vendo o pacote de dados # 36995 por algum motivo; está apenas estupidamente repetindo seu SYN, ACK até que o limite de tcp_synack_retries seja atingido.

Você tem alguma idéia do que poderia dar errado? Este é um padrão que observamos na maioria das transferências de dados entre esses dois dispositivos.

Já tentamos atualizar o kernel de 3.18.11 para 4.1.20+. O serviço por trás da porta 44269 é um programa Java (trecho abaixo) em execução no Oracle JRE 1.8.0-b132.

Veja no CloudShark: link

No.     Time           Source                Destination           Protocol Length Info
  36988 0.000000000    192.168.1.150         192.168.1.200         TCP      66     62935 > 44269 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1
  36989 0.000302000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  36991 0.001051000    192.168.1.150         192.168.1.200         TCP      60     62935 > 44269 [ACK] Seq=1 Ack=1 Win=65700 Len=0
  36995 0.046655000    192.168.1.150         192.168.1.200         TCP      425    62935 > 44269 [PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  37051 0.942187000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  37052 0.001155000    192.168.1.150         192.168.1.200         TCP      60     [TCP Dup ACK 36995#1] 62935 > 44269 [ACK] Seq=372 Ack=1 Win=65700 Len=0
  37183 1.998841000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  37184 0.001005000    192.168.1.150         192.168.1.200         TCP      60     [TCP Dup ACK 36995#2] 62935 > 44269 [ACK] Seq=372 Ack=1 Win=65700 Len=0
  37188 0.054728000    192.168.1.150         192.168.1.200         TCP      425    [TCP Retransmission] 62935 > 44269 [PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  37299 1.756498000    192.168.1.150         192.168.1.200         TCP      60     62935 > 44269 [FIN, ACK] Seq=372 Ack=1 Win=65700 Len=0
  37429 2.187771000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  37430 0.001090000    192.168.1.150         192.168.1.200         TCP      60     [TCP Dup ACK 37299#1] 62935 > 44269 [ACK] Seq=373 Ack=1 Win=65700 Len=0
  37579 2.062723000    192.168.1.150         192.168.1.200         TCP      425    [TCP Retransmission] 62935 > 44269 [FIN, PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  37964 5.936190000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  37965 0.001178000    192.168.1.150         192.168.1.200         TCP      60     [TCP Dup ACK 37579#1] 62935 > 44269 [ACK] Seq=373 Ack=1 Win=65700 Len=0
  38357 6.184544000    192.168.1.150         192.168.1.200         TCP      425    [TCP Retransmission] 62935 > 44269 [FIN, PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  39002 9.814283000    192.168.1.200         192.168.1.150         TCP      66     44269 > 62935 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=64
  39003 0.001056000    192.168.1.150         192.168.1.200         TCP      60     [TCP Dup ACK 38357#1] 62935 > 44269 [ACK] Seq=373 Ack=1 Win=65700 Len=0
  39935 14.424503000   192.168.1.150         192.168.1.200         TCP      425    [TCP Retransmission] 62935 > 44269 [FIN, PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  43097 48.376598000   192.168.1.150         192.168.1.200         TCP      425    [TCP Retransmission] 62935 > 44269 [FIN, PSH, ACK] Seq=1 Ack=1 Win=65700 Len=371
  43098 0.000295000    192.168.1.200         192.168.1.150         TCP      54     44269 > 62935 [RST] Seq=1 Win=0 Len=0

Servidor Java:

@Override
public void run()
{
    LOG.info("Opening listen socket on port " + port);
    try (ServerSocket serverSocket = new ServerSocket(port))
    {
        while (true)
        {
            Socket socket;
            try
            {
                LOG.debug("Listening on port {} for a client to connect...", port);
                socket = serverSocket.accept();
                LOG.debug("Client connected! Creating worker-thread for " + socket.getInetAddress().getHostName() + ":"
                        + socket.getPort());
                new WorkerThread(socket).start();
            }
            catch (IOException e)
            {
                LOG.error("Failed to listen for a connection", e);
                continue;
            }
        }
    }
    catch (IOException e)
    {
        LOG.error("Failed to open listen socket", e);
        LOG.info("----------SOFTWARE TERMINATED----------");
        System.exit(1);
    }
}

Editar 1: Percebi que netstat -s está mostrando um número muito alto de transbordamentos da fila de escuta:

netstat -s | grep -i list
    226094 times the listen queue of a socket overflowed
    226094 SYNs to LISTEN sockets dropped

Isso me levou a verificar o tamanho do backlog, que era 128 ( cat /proc/sys/net/ipv4/tcp_max_syn_backlog ). Eu aumentei para 2048, mas isso não resolveu o problema.

Eu encontrei outro post (# 646604 no serverfault, não posso vinculá-lo devido à pouca reputação aqui) que descreve um problema um pouco diferente, mas ajudou-me a localizar a seção responsável no kernel do Linux: lxr.free- electrons.com/source/net/ipv4/tcp_ipv4.c#L1274

1274         if (sk_acceptq_is_full(sk))
1275                 goto exit_overflow;

1346 exit_overflow:
1347         NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
1348 exit_nonewsk:
1349         dst_release(dst);
1350 exit:
1351         NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
1352         return NULL;

Vejo aqui que os dois contadores serão contabilizados simultaneamente quando a fila de aceitação do aplicativo estourar. Então, agora vou voltar meu foco para o aplicativo Java para ver se há limites / gargalos.

Editar 2: Investigações posteriores trouxeram-me a este post que explica muito bem este fenómeno: link

Em suma, o Linux tem duas filas que mantêm novas conexões antes que o aplicativo as use via accept ():

• a fila SYN, com seu comprimento definido por net.ipv4.tcp_max_syn_backlog
• a fila de aceitação, cujo comprimento é determinado pelo argumento do backlog na chamada listen ()

O último está transbordando no meu caso. Java encapsula a chamada listen () em sua implementação ServerSocket () e configura o backlog para um tamanho fixo de 50. Isso pode ser visto com ss -l :

State      Recv-Q Send-Q      Local Address:Port          Peer Address:Port
LISTEN     51     50                     :::44269                   :::*

A questão é agora, por que o Java não está esvaziando a fila de aceitação rápido o suficiente?