Por que o TCP envia mais de 1 ack por pacote?

Question

Minha origem envia pacotes de 4794 bytes (pelo menos de acordo com a captura, parece 1 pacote cada), no entanto, a máquina de destino envia 2 acks para cada pacote enviado da fonte.
Eu tentei alterar o tamanho da pilha de leitura da máquina de destino ( /proc/sys/net/ipv4/tcp_rmem ) para um valor superior a 4906 (que é o padrão mínimo), mas não vi nenhuma alteração. Ambos os sistemas rodando linux (centos).
Eu uso tcpdump e 'wireshark' para analisar as capturas.

Aqui está uma captura de tela do wireshark:

O src é 172.16.33.237, dst é 172.16.34.111.
Observe cada pacote 4794 recebe 2 acks.
Os pacotes de 194 bytes são resposta da aplicação do destino (e acredito que não sejam relevantes para esta discussão)

    

Answer 1

Muitos NICs usam Large Segment Offload , onde o driver NIC é responsável por cortar os dados TCP em pacotes menores para transmissão, em vez da CPU do sistema. O tcpdump / Wireshark captura o tráfego antes que ele tenha sido cortado pela NIC, e é por isso que às vezes é possível ver pacotes maiores que o MTU da interface na captura.

Supondo que um MTU padrão de 1500 Bytes está sendo usado, isso exigiria que 4 pacotes fossem enviados. TCP Confirmação atrasada é outro recurso de desempenho que tipicamente resultará em um ACK sendo enviado para cada segundo pacote.

    

Answer 2

Leia o artigo completo aqui .

Você pode ajustar o tamanho do Buffer TCP. Primeiro, digite os seguintes comandos para verificar os valores configurados:

$ cat /proc/sys/net/ipv4/tcp_mem

Encontre o valor máximo para receber a memória do soquete:

$ cat /proc/sys/net/core/rmem_default

$ cat /proc/sys/net/core/rmem_max

Para a memória do socket de envio:

$ cat /proc/sys/net/core/wmem_default

$ cat /proc/sys/net/core/wmem_max

e quantidade máxima de buffers de memória:

$ cat /proc/sys/net/core/optmem_max

Ajustar valores (wmem e rmem):

Você precisa definir o máximo de envio de wmem e receber o tamanho do buffer de rmem para 12 MB em todos os protocolos. Por favor, siga os comandos:

# echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf

# echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf

Defina o tamanho mínimo, inicial e máximo (especifique em bytes):

# echo 'net.ipv4.tcp_rmem= 10240 87380 12582912' >> /etc/sysctl.conf

# echo 'net.ipv4.tcp_wmem= 10240 87380 12582912' >> /etc/sysctl.conf

Aumentar a janela de transferências:

# echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf

Ativar registros de data e hora, conforme definido no RFC1323:

# echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf

Ativar confirmações:

# echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf

Se as métricas de conexão para o cache raiz forem definidas ao fechar a conexão, então:

# echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf

Defina o número máximo de pacotes para o lado da entrada:

# echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

Atualize as alterações:

# sysctl -p

Veja as alterações:

# tcpdump -ni eth0

    

Answer 3

O MarkoPolo está correto. Mas ele não mencionou que, se você usar um tap de rede, irá capturar os pacotes reais à medida que forem enviados pela rede e isso faria mais sentido. O que você está vendo são 3 pacotes combinados em um. O TCP receptor está utilizando o ACK atrasado e reconhecendo cada um ou dois pacotes.

A resposta do aplicativo de 194 bytes é relevante devido ao comportamento de parada e espera do dispositivo de envio. Esse padrão é o que desencadeou sua pergunta. Se isso fosse simplesmente uma transferência em massa unidirecional sem resposta do servidor, um padrão muito diferente se desenvolveria.

Além disso, configure seu MTU para 9000 em uma rede com uma rota padrão, ruim. Isso levará a problemas e não conseguirá nada