Análise TCP Nagle e ACK PCAP atrasado: latência de pacotes pequenos, paralisações de 40 ms e aplicativos de solicitação/resposta lenta

Alguns aplicativos TCP parecem lentos mesmo sem perda de pacotes, com baixa CPU e largura de banda saudável. A causa pode ser a interação entre o algoritmo de Nagle e o comportamento atrasado do ACK. Os usuários procuram por "TCP Nagle atrasou ACK pcap", "atraso TCP de 40ms", "latência de pacotes pequenos", "captura de pacotes TCP_NODELAY", "TCP de resposta de solicitação lenta" e "por que o TCP espera antes de enviar pacotes pequenos" quando um protocolo interativo para em pequenas gravações.

A cirurgia PCAP é útil porque esse problema é inteiramente baseado no tempo. Você precisa preservar os carimbos de data e hora dos pacotes, os tamanhos da carga útil, o tempo do ACK, a direção e os limites das mensagens do aplicativo.

O que Nagle faz

O algoritmo de Nagle reduz a sobrecarga de pequenos pacotes, retendo pequenas gravações quando já existem dados não reconhecidos em trânsito. Para transferência em massa, isso pode ser eficiente. Para protocolos interativos de solicitação/resposta que enviam muitas mensagens pequenas, pode introduzir latência visível.

O padrão típico:

1. O aplicativo envia um pequeno segmento.
2. Outra pequena gravação está pronta.
3. O remetente espera por ACK antes de enviar mais.
4. O receptor atrasa o ACK na esperança de aproveitá-lo.
5. Ambos os lados esperam brevemente.

Esse atraso pode parecer uma pausa misteriosa no aplicativo.

O que o ACK atrasado faz

O ACK atrasado permite que o receptor espere antes de confirmar os dados, geralmente para reduzir o tráfego de ACK ou adicionar ACKs nos dados de resposta. Este é normalmente um comportamento válido do TCP.

O problema aparece quando:

• O remetente espera por causa de Nagle.
• O receptor espera por causa do ACK atrasado.
• O aplicativo aguarda o segundo segmento pequeno.
• Nenhum lado envia dados suficientes para interromper a espera imediatamente.

A captura de pacotes mostra uma lacuna repetida, muitas vezes em torno de um pequeno atraso fixo.

Sintomas comuns

Os pesquisadores geralmente descrevem:

• "TCP não tem perda de pacotes, mas o aplicativo é lento."
• "Cada solicitação tem um atraso de 40 ms."
• "Escritas pequenas são lentas."
• "Desativando latência fixa TCP_NODELAY."
• "Protocolo de banco de dados lento em VPN."
• "UI remota lenta com muitos pacotes pequenos."
• "As chamadas RPC têm lacunas estranhas."
• "A latência só acontece do Linux para o Windows."

A causa raiz pode ser opções de soquete, padrões de gravação de aplicativos ou política de ACK do receptor.

Evidência de pacote

Procurar:

• Pequenas cargas TCP.
• Um lado envia menos que MSS.
• A segunda mensagem do aplicativo está atrasada.
• O ACK chega após um intervalo fixo semelhante a um temporizador.
• Nenhuma retransmissão ocorre.
• A janela não está cheia.
• O RTT é inferior ao estol observado.
• A taxa de transferência não é o principal gargalo.

Isso diferencia o ACK Nagle/atrasado de perda, congestionamento, atraso de DNS, negociação TLS e tempo de processamento do servidor.

Protocolos de solicitação/resposta

Os protocolos interativos são especialmente sensíveis:

• Consultas de banco de dados.
• Enquadramento RPC.
• Protocolos do tipo Telnet.
• Protocolos de controle industrial personalizados.
• Canais de controle de área de trabalho remota.
• Gateways de negociação financeira.
• Bibliotecas de clientes HTTP Chatty.
• Protocolos de comando orientados a linha.

Se um aplicativo enviar cabeçalhos, campos de comprimento e fragmentos de corpo como pequenas gravações separadas, o rastreamento de pacotes poderá revelar latência evitável.

TCP_NODELAY e lote de aplicativos

Desabilitar o Nagle com TCP_NODELAY pode reduzir a latência para alguns aplicativos interativos. Mas nem sempre é a melhor solução.

As opções incluem:

• Habilite TCP_NODELAY para pequenas mensagens sensíveis à latência.
• Gravações pequenas em lote em uma gravação de aplicativo.
• Libere apenas quadros de protocolo completos.
• Evite padrões de gravação-gravação-leitura com segmentos minúsculos.
• Ajuste o comportamento do ACK atrasado se a plataforma permitir.
• Mantenha o Nagle ativado para transferências em massa.

O pcap deve orientar a decisão.

Diagnósticos falsos

Este problema é frequentemente diagnosticado erroneamente como:

• Perda de pacotes.
• CPU do servidor lenta.
• Sobrecarga de TLS.
• Latência do Wi-Fi.
• Congestionamento de VPN.
• Atraso de DNS.
• Problema de MTU.

Isso pode ser real em outros casos, mas se o rastreamento mostrar lacunas consistentes em pequenos pacotes sem retransmissões, a interação TCP send/ACK merece atenção.

Requisitos de captura

Para uma análise útil, preserve:

• Aperto de mão TCP.
• Primeira solicitação lenta.
• Tamanhos de carga útil.
• Carimbos de data e hora do pacote com alta resolução.
• Pacotes somente ACK.
• Direção de cada segmento.
• Carimbos de data e hora do log do aplicativo, se disponíveis.
• Conhecimento da opção de soquete, se disponível.

Não apare as pequenas lacunas ociosas. Eles são a evidência.

Lista de verificação de depuração

Use este fluxo de trabalho:

1. Identifique lacunas de latência repetidas.
2. Meça a duração do intervalo.
3. Verifique se as cargas úteis são pequenas.
4. Verifique se o remetente possui dados não confirmados.
5. Verifique o tempo do ACK.
6. Confirme que nenhuma retransmissão explica a lacuna.
7. Compare com RTT.
8. Teste o lote de gravação do aplicativo.
9. Teste TCP_NODELAY se apropriado.
10. Preservar antes/depois dos pcaps.

Diagnóstico final

Problemas de TCP Nagle e ACK atrasado são problemas de temporização e gravação pequena, não problemas de largura de banda. A evidência importante são segmentos minúsculos, atraso de ACK, comportamento de espera do remetente e repetidas lacunas de latência fixa.

A cirurgia PCAP ajuda a preservar e comparar o tempo de pacote necessário para provar se um aplicativo lento de solicitação/resposta está bloqueado pelo comportamento de pacotes pequenos do TCP.