Quando o mecanismo TCP decide enviar um ACK?

Question

Na minha LAN, eu tenho um roteador que executa um servidor Samba e meu PC se conecta ao roteador.

Eu carreguei durante um upload para o servidor e um download do servidor.

Os resultados do wireshar mostram que:

• Durante o upload, o servidor envia um ACK a cada 0,6 ms médio
• Durante o download, meu PC envia um ACK a cada 0,025 ms médio

Como conseqüência, o download gera cerca de 120000 quadros, enquanto o upload só gera 70000 quadros. E a taxa de download é de cerca de 12.7Mbytes / s, enquanto a taxa de upload é de 20Mbyte / s.

Então, quero descobrir a possível razão para isso.

    

Answer 1

Existem basicamente dois mecanismos para reduzir a quantidade de pacotes ACK retornados - o algoritmo Nagle e os ACKs atrasados - ambos descritos em RFC 1122 . Ambos são opcionais, portanto, haverá hosts configurados para não usá-los ou ter a implementação apropriada ausente. Especialmente o Samba pode ser instruído a desabilitar o algoritmo Nagle usando socket options = TCP_NODELAY em a configuração .

Sua diferença nas taxas de dados upstream / downstream para cópias de arquivos SMB provavelmente terá outros motivos além da abundância de pacotes TCP ACK.

    

Answer 2

A implementação TCP ACKs todos os outros pacotes de dados. Então, você deve ver, tipicamente, dois pacotes de dados recebidos e, em seguida, um ACK enviado. O remetente, claro, não está esperando pelo ACK. Ele continuará a transmitir até que a janela esteja cheia, mesmo na ausência de um ACK.

Existem outros fatores potencialmente em jogo aqui, como Nagle e ACK atrasado. Mas não parece que você está vendo os efeitos deles.