No meu roteador Linux, estou usando a configuração a seguir para limitar a taxa de tráfego para a porta 44444 de um cliente na LAN (o endereço do cliente é 192.168.10.2, conectado por meio da if1 do roteador):
tc qdisc add dev eth1 root handle 1: htb default 2
tc class add dev eth1 parent 1: classid 1:1 htb rate $RATE
tc class add dev eth1 parent 1: classid 1:2 htb rate 100mbit
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dst 192.168.10.2 dport 44444 0xffff flowid 1:1
O que eu espero desta configuração é que o tráfego para 192.168.10.2:44444 será configurado de acordo com o parâmetro $ RATE, enquanto que todo o tráfego restante será basicamente intocado (já que a LAN é de 100Mbit / s).
Para testar esta configuração estou enviando pacotes UDP para 192.168.10.2:44444 em várias taxas, mantendo o controle do número de pacotes perdidos e as variações de atraso unidirecional. O que eu observei durante meus testes é que os pacotes que excedem a taxa nunca são descartados. Em vez disso, os pacotes são enfileirados em um buffer que continua crescendo sem (aparentemente) atingir o limite de tamanho.
Por exemplo:
Usando RATE = 30kbit e enviando pacotes a uma velocidade de aproximadamente 2Mbit / s (carga de pacote 1400 bytes, pacote espaçado por 5ms) por 10 segundos, recebo as seguintes estatísticas do tc:
qdisc htb 1: root refcnt 2 r2q 10 default 2 direct_packets_stat 0 ver 3.17
Sent 104901 bytes 85 pkt (dropped 0, overlimits 185 requeues 0)
backlog 0b 0p requeues 0
(Estatísticas mostradas em tc -s -d qdisc show dev eth1 )
Na verdade, os pacotes são recebidos por 192.168.10.2 por mais de 26 segundos (ou seja, 16 segundos após o remetente terminar).
Usando RATE = 5mbit e enviando pacotes a 20mbit, recebo as seguintes estatísticas:
qdisc htb 1: root refcnt 2 r2q 10 default 2 direct_packets_stat 0 ver 3.17
Sent 6310526 bytes 4331 pkt (dropped 0, overlimits 8667 requeues 0)
backlog 0b 0p requeues 0
embora o atraso unidirecional não ultrapasse 160ms.
Também obtive resultados semelhantes especificando um burst size, mas não observei nenhuma alteração significativa, não importa o quão baixo eu configurei (diminuí para 1kbit).
Infelizmente, não consigo encontrar uma explicação razoável para esses resultados, apesar de ter lido vários manuais e referências sobre o Linux tc e o htb. Eu ficaria feliz se alguém pudesse me ajudar a descobrir isso.
obrigado
Atualizar. Eu encontrei uma descrição muito útil e clara dos componentes internos do controlador de tráfego Linux. Você pode encontrá-lo aqui . Outro recurso útil é o Wiki OpenWRT . Na verdade, eu já sabia sobre o artigo anterior, mas aparentemente senti falta dos bits importantes.
Longa história curta, o buffer onde meus pacotes ficam enfileirados é, obviamente, a fila de saída da interface de rede. Os pacotes na fila de saída são selecionados para transmissão de acordo com a disciplina de enfileiramento definida pelo comando tc . Curiosamente, a fila de saída não é medida em bytes, mas em pacotes (não importa o tamanho dos pacotes). Essa é, em parte, a razão pela qual, em meus experimentos, nunca consegui atingir o limite de tamanho da fila.
O tamanho da fila de saída é mostrado através do comando ifconfig ( txqueue field). Na minha caixa de Linux, o tamanho de saída padrão é de 1000 pacotes, mas você pode alterá-lo facilmente através de ifconfig DEV txqueuelen SIZE . Diminuindo o tamanho da fila para 1 pacote, finalmente consegui forçar os pacotes formados a serem descartados (nunca atingindo o cliente). Então eu acho que é basicamente isso.
Um último fato interessante que notei é que o filtro do token bucket ( tbf ) como oposto ao filtro de bucket hierárquico faz fornecer um buffer extra onde os pacotes são enfileirados antes de serem transmitidos. Eu acho que usando esse filtro com uma fila pequena o suficiente, você pode forçar os pacotes a serem descartados, não importando o tamanho da fila de saída. Eu não experimentei isso.
Espero que isso ajude.