Estou resolvendo um problema de tempo limite de conexão entre duas caixas Linux, onde parece que o ACK para SYN-ACK foi perdido na pilha do servidor.
O tcpdump é feito no lado do servidor.
O cliente obteve o syn-ack, enviou o ACK e o pacote de dados e reenviou os dados mais 4 vezes. O servidor ressentiu a sincronização 4 segundos depois de ter enviado o syn-ack, indicando que o ACK do cliente foi perdido na pilha do servidor. O cliente responde com um ACK.
Em seguida, cerca de 3 segundos depois, o cliente reenvia dados e recebia o ACK do servidor. O cliente enviou FIN às 10s porque o aplicativo cliente definiu um tempo limite de 10 segundos.
Então a questão é: o tcpdump mostra o ACK para o SYN-ACK que chegou no servidor. Em que casos o servidor poderia reenviar o SYN-ACK? É problema do kernel ou aplicativo no lado do servidor? E como depurar mais?
Aprecie sua ajuda.
20:31:01.159098 IP client.cport > server.sport: S 2848162415:2848162415(0) win 5840 20:31:01.159103 IP server.sport > client.cport: S 901143055:901143055(0) ack 2848162416 win 5792 20:31:01.159192 IP client.cport > server.sport: . ack 1 win 46 20:31:01.159276 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:01.380395 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:01.824367 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:02.712362 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:04.488358 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:05.159038 IP server.sport > client.cport: S 901143055:901143055(0) ack 2848162416 win 5792 20:31:05.159157 IP client.cport > server.sport: . ack 1 win 46 20:31:08.040317 IP client.cport > server.sport: P 1:426(425) ack 1 win 46 20:31:08.040326 IP server.sport > client.cport: . ack 426 win 27 20:31:11.159618 IP client.cport > server.sport: F 426:426(0) ack 1 win 46 20:31:11.199139 IP server.sport > client.cport: . ack 427 win 27 20:31:14.724604 IP server.sport > client.cport: . 1:1449(1448) ack 427 win 27 20:31:14.724612 IP server.sport > client.cport: P 1449:1756(307) ack 427 win 27 20:31:14.724776 IP client.cport > server.sport: R 2848162842:2848162842(0) win 0 20:31:14.724779 IP client.cport > server.sport: R 2848162842:2848162842(0) win 0
Edit: Existem toneladas de estouro. Poderia o aplicativo ter um backlog baixo de listen () levando a esse problema?
$ netstat -s | grep -i list
210473 times the listen queue of a socket overflowed
210473 SYNs to LISTEN sockets ignored
Editar 2: este é o meu primeiro post aqui, por favor fique comigo. :)
Cliente & Kernel do servidor: 2.6.18-92.el5
Aplicativo do servidor: ouve apenas o esporte. Ele processa a solicitação do cliente e a resposta de volta. Usando strace eu descobri que o backlog listen () é 5.
Existem 8 sistemas de clientes, cada um executando uma instância de aplicativo cliente. O aplicativo cliente envia um req para a porta do servidor, recebe resposta do servidor. Um temporizador 10s é definido após o cliente ter êxito em connect (). Cada instância do cliente pode enviar várias solicitações de conexão, cada uma em sua própria porta de cliente.
Poderia haver uma explosão de solicitações simultâneas dos 8 clientes.
Editar 3: o tcpdump é muito semelhante ao do link , mas nenhuma causa raiz / solução.
Eu me perguntaria por que o cliente normal:
Além disso, se você precisar da ajuda da comunidade, é melhor pensar que perdemos nossas habilidades de telepatia há muito tempo e, portanto, não temos nem mesmo uma idéia do que está envolvido nisso (a partir da versão do kernel do Linux ) e como e como deve funcionar.
Seu backlog é muito pequeno para aceitar todas as suas solicitações. O backlog é o tamanho de sua fila de aceitação, quando a fila de aceitação está cheia, o ACK do cliente é ignorado ou a conexão é interrompida de acordo com net.ipv4.tcp_abort_on_overflow. Então, aumente sua carteira de pedidos.