Eu quero limitar a velocidade de entrada (download) para a caixa Linux.
Ambos, a caixa, que está configurada, e a fonte de tráfego (servidor HTTP) estão conectados ao mesmo switch, se a configuração não estiver configurada, a velocidade de download é de 30MBps
Eu uso o tc de acordo com o link
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
/sbin/tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Mas, a velocidade de download efetiva é muito menor que a configurada. Aqui estão os resultados dos meus experimentos
taxa definida, KBps : taxa real, KBps
Para a pequena formatação de largura de banda funciona muito bem, mas em 1024 KBit a taxa de bits efetiva é 75% menor que a esperada.
É possível limitar efetivamente a largura de banda de entrada?
bw is lower than expected
Eu acho que você tem que aumentar burst também.
Is is possible to effectively limit incoming bandwidth?
Eu diria que você certamente pode conseguir um efeito similar ao eliminar pacotes, em vez de recapturá-los. Para protos como o TCP, que possuem mecanismos de auto-ajuste de largura de banda, ele funcionaria efetivamente. Dê uma olhada no link
Is is possible to effectively limit incoming bandwidth?
Tentar limitar a largura de banda de entrada é basicamente tentar limitar o fluxo de uma mangueira de incêndio segurando uma placa com um furo: você reduzirá a quantidade de água que bate em você, mas você ainda está sendo atingido firehose.
Continuando a analogia firehose, se você precisar de 100 galões de água, mas limitar a velocidade com que está chegando até você (segurando a placa com o buraco nela), você ainda está suportando o peso da força do firehose (tráfego vindo pelo seu cano), mas não obtendo a maior parte da água (porque somente o que acontece para passar pelo buraco chega até você - o resto é jogado no chão pela sua firewall board).
O efeito de bloquear toda essa água é que leva mais tempo para encher o seu balde de 100 galões.
O efeito de bloquear pacotes TCP com um firewall é um pouco pior, porque você aciona o algoritmo de controle de conecção do host remoto que em um mundo ideal, diminui a pressão sobre a mangueira, às vezes substancialmente menor do que você gostaria.
Eu ouvi resultados mistos sobre a limitação da largura de banda de entrada, mas isso deve ser possível com o dispositivo ifb no kernel. Enquanto uma verdade é o que @ voretaq7 disse, você pode "limitar" pacotes de entrada se aceitar todos os pacotes de entrada e redirecioná-los com redirecionamento ou espelhamento em um dos dispositivos "I_ntermediate F_unctional B_lock". Para esses, você pode anexar qualquer filtro normalmente limitado a filtragem 'egress'.
Isso pode não parecer "útil", já que você tem que aceitar todo o tráfego, no ifb - mas então você decide qual tráfego sai dessa fila de espera "IN" para o resto do seu sistema.
Isso tem o benefício de não descartar pacotes a menos que sejam pacotes de menor prioridade. Certamente, se você está sendo DoS'd, o principal problema é que o tráfego total de entrada é maior do que a sua linha pode sustentar, então tentar afetá-lo com esse método é fútil. Este método só funcionaria em fluxos legítimos sobre qualquer protocolo desejado (TCP, UDP, ICMP, etc ...). Ou seja se eu quiser priorizar o DNS sobre downloads em massa, eu posso fazer isso, não importa o algoritmo de tráfego, se você tem 30Mb /, então com uma interrupção de clock normal mais rápida de 1000Hz, você ainda tem que lidar com 30Kb de tráfego / clock e isso é presumir que você seja chamado em tempo hábil. Essa é a principal razão pela qual você tem que ter uma alta taxa de burst, porque é difícil lidar com isso apenas com a limitação de taxa.
Seria útil , se sua placa de rede tiver várias filas de E / S. Muitos cartões têm 6-12 filas / direção que podem fornecer algumas classificações "automáticas" em filas separadas com base nas opções de filtragem, geralmente mais limitadas, na placa ethernet.
O que pode ser mais útil - se você pode dividir seu tráfego nessas várias filas, é possível definir a afinidade do processador com as filas. Se você está se encontrando limitado nos pacotes de processamento da CPU, com os multiQs, isso pode ajudar a espalhar o tráfego de entrada para processamento em Core's diferentes (não use Hyperthreading - ele provavelmente causará um problema de desempenho já que os threads não estão operando em dados compartilhados, mas em fluxos de dados separados.O tratamento desses será melhor com cpu usando caches L1 & L2 separadas (L3 ainda será compartilhado, normalmente, entre vários núcleos), mas você pode pelo menos dedicar os caches L1 & L2 a seus próprios "fluxos").
Devido a problemas na taxa de transferência, eu tive com filas únicas e policiamento, desisti do controle de ingresso - e eu só tinha uma entrada de 5Mb na época (7Mb agora), então eu não tentei ver o quão eficiente usando multiq e ifb estão em modelagem de ingresso. Como é, geralmente uso moldagem em nível de aplicativo & controles - não ideal, mas bastante confiável.
Uma questão que surge de vez em quando, é que devido a problemas de linha ou congestionamento de ISP, não recebo meu BW máximo, então minhas predefinições de filtro fixo não se adaptam ... essa é outra razão pela qual trabalhei muito nessa questão, pois não tenho certeza de quanto trabalho seria necessário para que a limitação da taxa fosse dinâmica e percebesse tais problemas ou problemas, e agora tenho muitos outros projetos de prioridade mais alta na minha fila. (e minha taxa de E / S está bem abaixo da porta da minha ethernet) ...; -)
Tags linux traffic-shaping iproute2