A sua compreensão do problema é geralmente correta, mas o tipo de solução que você propõe é MUITO complicado de implementar. As perguntas de "O que é um cliente?" e "O que é uma conexão?" surgir, e pode ser difícil responder bem.
A estratégia mais típica de limitação de largura de banda é algo assim:
- Defina o limite da largura de banda a montante (digamos 1Mbit / s)
- Opcionalmente, Reserve alguma quantidade dessa largura de banda para "administração do sistema" (por exemplo, 64 KB / s)
- Opcionalmente, "garanta" uma certa quantidade de largura de banda para um propósito específico (digamos 192Kb / seg para VOIP)
- Permite que todos usem a largura de banda restante (768 kbit / s).
O VOIP pode usar mais de 192 Kbit / seg, portanto podemos permitir que ele seja emprestado do pool "everyone" (ou vice-versa). Quando o pool de "todos" estiver saturado, comece a eliminar pacotes como faríamos se o link upstream estivesse realmente saturado (usando, por exemplo, Random Early Detection para escolher suas vítimas de queda.
Geralmente isso é feito no tráfego UPSTREAM. O tráfego a jusante pode ser limitado da mesma maneira, mas você não pode evitar a saturação de link do tráfego downstream (os pacotes ainda precisam vir ao seu firewall antes que as decisões de queda possam ser tomadas, então eles ainda estão viajando pelo fio. é uma onda de tráfego seguida por um decaimento natural, já que o protocolo TCP detecta congestionamento "saturação de link" e o lado remoto retrocede sua taxa de envio até que a perda de pacotes pare.
Observe também que isso não garante "justiça" às máquinas clientes, exceto na medida em que a Detecção Antecipada Aleatória derrubará os pacotes "aleatoriamente" (aleatoriamente o suficiente para que nem sempre o cliente A receba pacotes descartados quando o link está saturado). O que você está contando é que as quedas "aleatórias" naturalmente moldarão o tráfego de uma forma que você não terá que se preocupar com o fato de um cliente morrer de fome enquanto outro adora toda a largura de banda.
Uma solução pronta para uso em seu caso particular pode ser limitar a largura de banda disponível para atualizações (presumivelmente estas vêm de sub-redes conhecidas, limitando-as), mas isso ainda está sujeito às advertências que mencionei acima.
Alternativamente, se você tiver hardware disponível, você pode distribuir suas atualizações de um servidor local (WSUS, Local apt mirror, etc.) - Isso permitiria que você agendasse essas atualizações para serem feitas localmente fora do horário normal, quando ninguém é usando sua rede e, finalmente, pouparia muita largura de banda transferindo atualizações individuais para cada máquina.
Uma vez que as atualizações já são locais, não importa quando as máquinas individuais dos clientes as pegam - elas não estão saindo para a internet, então contanto que você não esteja saturando sua rede local (muito difícil!) Você ganhou t sofrem problemas significativos de desempenho. A desvantagem, claro, é que você precisa investir tempo e hardware na configuração do servidor de atualização.