Como ver o tamanho real dos buffers de envio e recebimento de tcp?

Question

estamos em um sistema Debian e estamos tentando ajustar a pilha tcp / ip para as nossas necessidades. Nós todos sabemos que você pode definir o tamanho máximo do buffer tcp com alguns parâmetros do kernel como este:

  net.ipv4.tcp_wmem = 4096  16384   4194304
  net.ipv4.udp_wmem_min = 4096
  net.core.wmem_max = 261071

Para calcular o tamanho máximo do buffer para as suas necessidades, você "apenas" precisa calculá-lo. (veja link )

Mas como não sabemos o tempo de ida e volta de nossos usuários, é muito difícil. Pode ser ok para assumir algo entre 20 e 60 ms. Mas para uma rede móvel é algo como 100-300 ms (testado com o meu telefone). Por isso, é muito difícil saber quantos dados podem estar "na linha".

Gostaríamos de ver o tamanho real do buffer e a utilização dele.

Alguém sabe como sneek nos buffers tcp reais de gravação e recebimento?

    

Answer 1

But as we do not know the round-trip-time of our users

Então, qual é o objetivo de tentar medir outra parte da equação?

(leia as man pages para lsof (-T flag) também netstat).

Mas confie em mim, o sistema TCP é bastante inteligente - e os caras que o escreveram são mais espertos do que você e eu - e sabemos muito mais sobre essas coisas. A única coisa com que se preocupar é o dimensionamento de janelas (esses dias devem ser desativados por padrão), a menos que você esteja transferindo arquivos muito grandes em uma WAN de velocidade muito alta, você provavelmente não precisará deles - se os arquivos não forem grandes ou a largura de banda for baixa, não haverá vantagem em usar a escala padrão.

    

Answer 2

Como eles disseram, é inútil fazer algo assim. Pode ser útil se você tiver uma rede com fio com tráfego constante , mas mesmo assim não é sugerido. O que você poderia fazer é definir outra implementação TCP (Vegas, Tahoe, Reno, etc.).

Cada um deles está focado em melhorar alguns aspectos do tcp. Por exemplo, um está tentando melhorar o atraso, outro tenta importar o jitter etc.