O Carlos Virgílio Beltrão Lessa (lessacarlos@ig.com.br) mandou um excelente artigo sobre o controle de banda usando o recurso HTB do kernel do Linux, e seu utilitário associado "tc". Uma versão resumida e condensada deste mesmo artigo dele foi publicada recentemente pela revista PC Master.
Com as técnicas expostas pelo Carlos, é possível atribuir prioridades no uso da conexão de rede para determinados serviços, impedindo que o tráfego web se sobreponha ao do banco de dados, ou que o BitTorrent se sobreponha à web, por exemplo.
Controle de Banda com HTB
por Carlos Virgílio Beltrão Lessa (lessacarlos@ig.com.br)
Sendo você um administrador de rede, pode estar vivendo a situação onde no mesmo link estão trafegando dados vitais para empresa, lazer dos funcionários e até mesmo pacotes enviados por vírus de rede, e quando alguém resolve fazer download de um filme ou sintoniza uma rádio on-line as aplicações de missão crítica são seriamente prejudicadas. Uma das maneiras de resolver o problema é através do controle de banda, onde você pode definir uma hierarquia do uso de rede, privilegiando algumas portas TCP e UDP e/ou endereços de hosts e de redes, fornecendo a estes maior largura de banda em detrimento do tráfego menos importante. Para fazer este controle existem equipamentos dedicados a este serviço. Uma outra alternativa, de baixo custo e de grande flexibilidade, é através do Linux. É desta opção que irei falar neste artigo.
Quando o kernel do linux tem de enviar para a rede vários pacotes através de um dispositivo de rede qualquer, ele precisa decidir quais enviará primeiro, quais retardará e quais descartará. Utilizando diversos algoritmos o escalonador de pacotes do kernel procura executar esta tarefa da maneira mais equilibrada possível. A regra padrão para o escalonador de pacotes é a FIFO (Firs In, First Out) - o primeiro a chegar é o primeiro a ser enviado. Você pode alterar este comportamento padrão fazendo com que o escalonador envie pacotes da maneira que lhe for mais útil.
O kernel do linux oferece diversos recursos que permitem o total controle no envio de pacotes. Este conjunto de recursos é denominado Queueing Discipline (qdisc) - algo como regras de enfileiramento. Dentre estas regras existe uma denominada Hierarchical Token Bucket - HTB. O objetivo deste artigo é passar para você o funcionamento básico do HTB e como este pode lhe ajudar no controle do tráfego na rede.
O HTB fornece meios para você controlar o tráfego de saída em um link. Através dele você pode simular vários links lentos em um único link físico e estabelecer quais tipos de tráfegos vão transitar em cada um destes links virtuais. O que você precisa fazer é definir a divisão em links e decidir como os pacotes neles trafegarão.
Para utilizar o HTB você vai precisar de:
1. Kernel com o módulo HTB packet scheduler ativado. A partir da versão 2.4.20 o suporte ao HTB foi incluído ao kernel. Para versões anteriores é preciso aplicar um patch.
2. Ferramenta tc (Traffic Control) atualizada para manipular qdiscs HTB. A ferramenta tc faz parte do pacote iproute2. Ela é utilzada para instruir ao kernel como tratar tráfego de rede.
Você pode está se perguntando se o kernel de seu linux tem suporte para HTB. Para assegurar-se disto vá para /lib/modules/versao_do_kernel/kernel/net/sched e verifique a existência dos arquivos sch_htb.o, sch_sfq.o e cls_u32.o. Se você localizar TODOS os arquivos citados seu sistema suporta o HTB.
Nos testes que fiz utilizei as versões 7, 8 e 9 do Conectiva Linux. Esta última versão tem suporte para HTB. Se você é usuário das versões anteriores da Conectiva e não quer baixar os fontes mais atuais do kernel e compilá-lo, você pode instalar o kernel 2.4.21 disponível nos CDs do Conectiva Linux 9, inclusos na edição 77 da PCMaster, neste caso tenha cuidado para não substituir o kernel do seu sistema e sim instalar um novo kernel - se for instalar via linha de comando execute rpm -ivh e não rpm -Uvh - a não ser que seja exatamente isto que você quer. Independente da forma de atualização escolhida, configure seu carregador de boot e reinicie o sistema no novo kernel.
É importante dizer que o HTB funciona com qualquer Linux. Você pode usá-lo na distribuição de sua preferência. Mencionei algumas vezes o Conectiva Linux porque é este que utilizo e foi nele onde executei os testes.
Só falta obter a ferramenta tc atualizada para suportar HTB. Baixe o arquivo http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz, descompacte-o com tar zxvf htb3.6-020525.tgz e copie o tc para /sbin.
Imagine o cenário onde você tem um link de 512kbit/s entre a matriz e a filial de uma empresa. A matriz tem conexão com a Internet de 2Mbit/s e compartilha este link com a filial, ou seja, todo acesso a Internet feito pela filial trafega também pelo link de 512kbit/s. Todos os servidores estão na matriz e as aplicações vitais para a empresa estão nestes servidores. Entre estas aplicações existe também uma ordem de importância, onde as de missão crítica atendem nas portas tcp 8800 e 22, logo abaixo a que atende na porta 8080, em seguida a que atende na porta 8008 e por último a que atende na porta 8000. Todos os demais tráfegos são irrelevantes. Como você pode observar o tráfego entre a Internet e a filial concorre com o tráfego entre a filial e a matriz e o problema é agravado pela superioridade de banda da Internet em relação a conexão matiz/filial. Esta situação torna a comunicação da filial com as aplicações vitais bastante vunerável a um tráfego mais intenso com a Internet.
Para que o tráfego entre a matriz (rede 192.168.0.0/24) e a filial (rede 192.168.1.0/24) fique adequada as necessidades da empresa configurei o HTB para garantir 272kbit/s nas portas 22 e 8800, 128kbit/s na porta 8080, 64kbit/s na porta 8008 e 32kbit/s na porta 8000. Os 16kbit/s restantes são destinados para assegurar uma largura de banda mínima para todo tráfego restante. Qualquer excedente de banda poderá ser utilizado por qualquer tráfego até o limite de 512kbit/s.
Vamos agora examinar o script com os comandos necessários para fazer esta configuração. Os comentários estão sempre após os comandos.
#!/bin/bash
tc qdisc del dev eth0 root
# Remove qualquer qdisc associado a interface eth0.
tc qdisc add dev eth0 root handle 1: htb default 50
# Associa uma regra de enfileiramento (qdisc) HTB a interface eth0 e vincula a
# esta o manipulador "1:". Este manipulador será referenciado por comandos
# abaixo para ajudar a criar a estrutura hierárquica. O "default 50" diz que
# todo tráfego que não estiver associado a uma classe específica será feito
# pela classe 50.
tc class add dev eth0 parent 1: classid 1:1 htb rate 512kbit
# Cria uma classe htb raiz identificando-a como "1:1" abaixo do qdisc "1:" com
# a taxa de 512kbit/s.
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 272kbit ceil 512kbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 128kbit ceil 512kbit
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 64kbit ceil 512kbit
tc class add dev eth0 parent 1:1 classid 1:40 htb rate 32kbit ceil 512kbit
tc class add dev eth0 parent 1:1 classid 1:50 htb rate 16kbit ceil 512kbit
# Cria cinco classes filhas da classe raiz "1:1" identificando-as como "1:10",
# "1:20", "1:30", "1:40" e "1:50" e atribui a elas as taxas de 272kbit/s,
# 128kbit/s, 64kbit/s, 32kbit/s e 16kbit/s respectivamente. Instrui ao HTB que
# o tráfego de qualquer uma das classes poderá chegar ao limite de 512kbit/s
# (ceil). Se ceil não for especificado ele será igual a taxa (rate).
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
tc qdisc add dev eth0 parent 1:40 handle 40: sfq perturb 10
tc qdisc add dev eth0 parent 1:50 handle 50: sfq perturb 10
# Cria manipuladores sfq "10:" a "50:" sob as classes "1:10" a "1:50". O qdisc
# sfq objetiva fornecer uma distribuição justa entre os diversos tráfegos de
# uma mesma classe, fazendo com que as várias conexões sob uma mesma classe
# dividam de forma equilibrada entre si. O uso deste qdisc evita que uma
# conexão de uma classe "roube" os recursos das demais na mesma classe. O
# parâmetro "perturb 10" é o tempo em segundos onde será verificado a
# solicitação de uso de banda por conexão.
U32="tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 "
U32=$U32"match ip src 192.168.0.0/24 match ip dst 192.168.1.0/24"
# A variável "U32" foi criada para tornar as linhas de comando a seguir mais
# curtas. O filtro u32 é aplicado para indentificar endereços ip e/ou portas
# tcp/udp. O parâmetro prio diz qual é prioridade que os pacotes terão. Este
# parâmetro varia de 0 a 15. Quanto menor o valor de prio maior a prioridade.
$U32 match ip sport 22 0xffff flowid 1:10
$U32 match ip sport 8800 0xffff flowid 1:10
$U32 match ip sport 8080 0xffff flowid 1:20
$U32 match ip sport 8008 0xffff flowid 1:30
$U32 match ip sport 8000 0xffff flowid 1:40
# Define como o tráfego será direcionado para cada classe com base nos
# endereços e portas de origem e endereços de destino através dos parâmetros
# src, sport e dst respectivamente. A associação destes com suas classes é
# estabelecida através do parâmetro flowid. Lembre-se que todo tráfego não
# incluso em um destes filtros será através da classe 50. O número hexadecimal
# após a porta pode ser utilizado para identificar uma faixa de portas
# consecutivas. Para referenciar uma única porta coloque sempre "0xffff".
Após executar o script, para assegurar que o ajuste no tráfego de rede reflita realmente aquilo que você deseja é interessante proceder alguns testes antes de colocá-lo em ambiente de produção. Sugiro que você habilite o apache, na mesma máquina onde o HTB está configurado, para aceitar conexões nas portas acima referenciadas. Isto pode ser feito acrescentando quatro linhas no arquivo httpd.conf (normalmente em /etc/httpd/conf) com as seguintes instruções: Listen 8800, Listen 8080, Listen 8008 e Listen 8000. Não esqueça de reiniciar o apache com o comando /etc/init.d/httpd restart. Coloque também no diretório onde ficam as páginas do apache (DocumentRoot) arquivos com tamanhos de 512 kbytes, 1024 kbytes, 2048 kbytes, 4096 kbytes e 8192 kbytes. Agora o seu ambiente de testes está pronto.
Para executar os testes você vai precisar de dois computadores. O endereço ip da máquina servidora tem de estar conforme o parâmetro src do script e a máquina cliente tem de estar conforme o parâmetro dst. Caso sua rede não se assemelhe aos endereços constantes no script faça as alterações antes de testar. No cliente você pode usar qualquer programa que faça download de um servidor web, onde você possa definir a porta que o servidor está ouvindo e que mostre a taxa de transferência final dos dados. Por atender a todas a estas características utilizei o wget.
O primeiro teste consiste em fazer downloads simultâneos nas portas 80 - submetida a classe 1:50 por conta do parâmetro default, 8000 - classe 1:40, 8008 - classe 1:30, 8080 - classe 1:20 e 8800 - classe 1:10.
# wget http://192.168.0.252:80/teste/512.gz; rm -f 512.gz
--21:38:43-- http://192.168.0.252/teste/512.gz
21:42:45 (2.07 KB/s) - '512.gz' recebido [512100/512100]
# wget http://192.168.0.252:8000/teste/1024.gz; rm -f 1024.gz
--21:38:44-- http://192.168.0.252:8000/teste/1024.gz
21:43:10 (3.76 KB/s) - '1024.gz' recebido [1023785/1023785]
# wget http://192.168.0.252:8008/teste/2048.gz; rm -f 2048.gz
--21:38:45-- http://192.168.0.252:8008/teste/2048.gz
21:43:03 (7.76 KB/s) - '2048.gz' recebido [2047192/2047192]
# wget http://192.168.0.252:8080/teste/4096.gz; rm -f 4096.gz
--21:38:46-- http://192.168.0.252:8080/teste/4096.gz
21:43:06 (15.35 KB/s) - '4096.gz' recebido [4093945/4093945]
# wget http://192.168.0.252:8800/teste/8192.gz; rm -f 8192.gz
--21:38:47-- http://192.168.0.252:8800/teste/8192.gz
21:42:53 (32.46 KB/s) - '8192.gz' recebido [8187493/8187493]
Como você pode observar as taxas de transferência foram bastante aproximadas ao que foi configurado no script. Repare que elas estão demonstradas em Kbytes/s, para transformar em kbits/s multiplique por oito. Verifique também a hora de início e de término de cada download e o tamanho dos arquivos transferidos.
Para verificar a distribuição eqüitativa dentro de uma classe baixei duas vezes o mesmo arquivo simultaneamente na porta 8800:
# wget http://192.168.0.252:8800/teste/1024.gz; rm -f 1024.gz
--22:10:09-- http://192.168.0.252:8800/teste/1024.gz
22:10:43 (29.74 KB/s) - '1024.gz' recebido [1023785/1023785]
# wget http://192.168.0.252:8800/teste/1024.gz; rm -f 1024.gz
--22:10:11-- http://192.168.0.252:8800/teste/1024.gz
22:10:44 (29.88 KB/s) - '1024.gz' recebido [1023785/1023785]
Atente para a taxa de ambos downloads que é praticamente idêntica.
O que você viu é apenas uma demonstração do potencial do HTB. Configurações muito mais complexas podem ser feitas para atender inúmeras situações. Você pode criar uma estrutura de classes HTB com diversos níveis hierárquicos ou ainda ter mais de uma classe raiz vinculada a mesma interface de rede. Como você pode comprovar o HTB é uma ferramenta poderosa e bastante flexível para controle de tráfego de rede.
Dicas:
O controle de banda no Linux é sempre no tráfego de saída. Se você quer controlar o fluxo de dados da filial para a matriz, por exemplo o envio de email ou upload de ftp, você precisa colocar outro computador com linux também na filial para controlar a saída dos dados de lá.
Caso você ache a sintaxe do comando tc complexa - particularmente não a acho nada amigável - talvez queira utilizar o script htb.ini. Este script pode ser encontrado em http://freshmeat.net/projects/htb.ini e realmente simplifica bastante o uso do HTB, embora simplicidade e flexibilidade nem sempre andem juntas. Toda a documentação e exemplos de utilização estão no corpo do script.
Se você optar por compilar o kernel, verifique a existência de arquivos com o nome parecido com "kernel-versao_do_kernel-perfil_de_hardware.config" no diretório /usr/src/linux-versao_do_kernel_original/configs/ de seu linux. Algumas distribuições disponibilizam estes arquivos que espelham o kernel original e basta copiar um deles para o diretório dos fontes do kernel que você quer compilar com o nome .config. Escolha o arquivo que mais se assemelhe ao perfil de hardware de seu computador - número de processadores, família de processadores e quantidade de memória RAM. Desta forma é muito mais fácil e rápido do que selecionar dezenas de opções, pois quase tudo que você precisa já está no arquivo .config, afinal de contas você está partindo de um kernel que já está rodando no seu computador. Depois é só fazer as modificações que você desejar com make menuconfig ou make xconfig, não esquecendo de selecionar as opçoes de QoS pois o suporte a HTB é uma delas e em seguida executar make dep, make clean, make, make bzImage, make modules, make modules_install e finalmente make install. Lembre-se de atualizar o seu carregador de boot para poder reiniciar seu sistema com o novo kernel.
Para saber mais:
Sobre controle de banda com o Linux: Capitulo 9 do Linux Advanced Routing and Traffic Control HOWTO em http://lartc.org/howto/
Sobre HTB: Na home page do HTB em http://luxik.cdi.cz/~devik/qos/htb/
Traduzi o Manual HTB - guia do usuário. A tradução está em boa parte aceitável. Contribuições para melhorar a tradução são bem vindas. Falta um site para publicar.
Sobre como compilar o kernel: Guia do Hardware de Carlos E. Morimoto em http://www.guiadohardware.info/tutoriais/065/
Sobre como compilar as ferramentas do iproute2, inclusive tc com suporte HTB: Iproute2 and traffic shaping em http://www.linuxfromscratch.org/hints/downloads/files/iproute2.txt
(autor: Carlos Virgílio Beltrão Lessa - lessacarlos@ig.com.br)
Postado por brain em janeiro 13, 2004 01:32 PM
» Postado por: asfd em janeiro 13, 2004 03:31 PM, 200.103.220:
"O controle de banda no Linux é sempre no tráfego de saída."
Besteira, voce pode fazer o math do pacote também no INPUT, isso é obvil ... só lamento uma pessoa se dispor a fazer tutoriais e ensinar besteiras neles.
» Postado por: alguem em janeiro 13, 2004 04:17 PM, 200.198.42.:
Como tem nego ignorante na parada, pq vc nao fala aonde está errado para a pessoa que escreveu possa arrumar?
prescisa postar um comentário desses aki?
» Postado por: verdade em janeiro 13, 2004 04:23 PM, 200.158.229:
Só lamento que alguém se dispoe a ajudar e venha gente criticar ao inves de fazer um melhor.
» Postado por: marcio hugo em janeiro 13, 2004 04:27 PM, 200.165.230:
O cara que escreve reclamando de um tuto livre só pode ser um ignorante!!!! Se ele é o SABE-TUDO pq não escreve então um tutorial melhor. Invés de reclamar.
» Postado por: edu lima em janeiro 13, 2004 06:36 PM, 200.232.192:
Antes de comentar...
- Preserve a qualidade desta discussão
- Este formulário deve ser usado para comentários sobre a notícia. Se você tem dúvidas ou precisa de ajuda, use o Fórum.
- Mantenha o foco nos argumentos e no assunto
- Não faça ataques pessoais.
- Pense 5 vezes antes de entrar em discussões inúteis, como "qual é a melhor distribuição/ambiente gráfico/linguagem de programação/etc.", mesmo se alguém já tiver provocado - um erro não justifica o outro
- Não seja um e-mala ;-)
» Postado por: ddd em janeiro 14, 2004 01:49 AM, 200.211.53.:
quem critica, eh pq tem inveja das pessoas q sabem e compartilham as informacoes com os outros...
acho q esse palhaco gostaria de saber tanto qto o carlos, e nem chega aos pehs dele.
» Postado por: Carlos J. Vaz em janeiro 14, 2004 08:57 AM, 200.203.54.:
Parabéns Carlos!
Muito bom seu artigo, graças a ele me esclareceu dúvidas sobre controle de banda no linux. Pessoas como você só tendem a crescer profissionalmente e pessoalmente. Só fico sentido que existem pessoas que além de não contribuírem com nada ficam postando comentários desagradáveis.
» Postado por: x-arnie em janeiro 14, 2004 09:18 AM, 200.210.46.:
seguinte.., o que ele disse sobre a limitação da banda ser efetiva somente na saida e nao na entrada esta realmente incorreto. Mas observe que a limitacao sera executada, mas a garantia de banda nao, pois uma vez que dependemos da outra ponta para enviar pacotes. Em resumo: podemos fazer a limitacao de pacotes de saida e de entrada, mas somente na saida podemos garantir a utilizacao correta da banda. Como ele disse, se quisermos a garantia de banda do outro lado precisaremos de um outro linux na outra ponta.
[]'s
x-arnie
» Postado por: Marco Máximo em janeiro 14, 2004 09:47 AM, 200.184.174:
Parabéns Carlos pelo seu tutorial.
Sem dúvida, será muito útil para bastante gente.
Um Abraço.
» Postado por: risky77 em janeiro 15, 2004 09:01 AM, 200.138.220:
Tb pode ser feito com CBQ, tanto inbound como outbound.
» Postado por: CarlosLessa em janeiro 15, 2004 02:19 PM, 200.199.64.:
Agradeço as críticas e os elogios.
» Postado por: alberto em janeiro 15, 2004 02:29 PM, 200.101.63.:
A questão do controle de entrada, como alguns outros já comentaram (alguns de forma irada), é possível, contudo desaconselhada principalmente pela caraterística do TCP de reenviar tudo o que foi perdido. Então, quando o autor diz que não se faz controle de entrada, ele talvez tenha querido dizer isso.
» Postado por: linuxman em janeiro 15, 2004 06:12 PM, 200.206.25.:
otimo artigo .. ja tinha ouvido falar sobre o htb e estava procurando fontes para a sua implementacao, so encontrei alguns sites em ingles, mas com muita informacao! sem duvida o htb é melhor q o cbq .. tem um controle melhor e mais estavel.
» Postado por: Marcelo em janeiro 16, 2004 01:14 AM, 201.2.229.4:
Normalmente o controle de banda é feito em um roteador, ou seja, em uma interface temos a rede que queremos controlar a banda e na outra(s) a Internet ou outra rede qualquer. Hora, se aplicarmos o controle nas duas interfaces estaremos controlando a banda tanto na entrada quanto na saída, e o que é melhor, sem controvérsias :-)
» Postado por: Tiago em janeiro 16, 2004 12:27 PM, 200.150.64.:
Muito bom o tutorial. Utilizo o htb aqui na empresa onde trabalho e se comporta muito bem, melhor do que o cbq, diga-se de passagem. Utilizei o cbq.init para configurar o cbq, mas não sei por qual motivo ele não mantia o rate estável e alguns ip's "passavam batidos" pelo controle de banda. Com o htb foi mais tranquilo, fiz até um script para automatizar o processo.
Parabéns ao redator do artigo, pois este é um assunto pouco desenvolvido em lingua portuguesa e muito útil para todos. Muitas vezes o lartc é confuso para os iniciantes.
"Enquanto os linuxers não respeitarem os próprios linuxers, não poderemos crescer nem como pessoas nem em conhecimento. Portanto se você acha que tem mais conhecimento que alguém, compartilhe sua ideia em vez de ridicularizar pessoas. Lembre-se que sua idéia está errada até que se prove o contrário."
» Postado por: CarlosLessa em janeiro 16, 2004 12:55 PM, 200.199.64.:
Por conta da polêmica levantada sobre a afirmação que o controle de banda no linux é sempre na saída:
1. Abaixo trecho da documentação oficial do kernel - atentem para a primeira linha "When the kernel has several packets to send out over a network device"
/usr/src/linux_versao/Documentation/Configure.help
QoS and/or fair queueing
CONFIG_NET_SCHED
When the kernel has several packets to send out over a network
device, it has to decide which ones to send first, which ones to
delay, and which ones to drop. This is the job of the packet
scheduler, and several different algorithms for how to do this
"fairly" have been proposed.
If you say N here, you will get the standard packet scheduler, which
is a FIFO (first come, first served). If you say Y here, you will be
able to choose from among several alternative algorithms which can
then be attached to different network devices. This is useful for
example if some of your network devices are real time devices that
need a certain minimum data flow rate, or if you need to limit the
maximum data flow rate for traffic which matches specified criteria.
This code is considered to be experimental.
To administer these schedulers, you'll need the user-level utilities
from the package iproute2+tc at .
That package also contains some documentation; for more, check out
.
This Quality of Service (QoS) support will enable you to use
Differentiated Services (diffserv) and Resource Reservation Protocol
(RSVP) on your Linux router if you also say Y to "QoS support",
"Packet classifier API" and to some classifiers below. Documentation
and software is at .
If you say Y here and to "/proc file system" below, you will be able
to read status information about packet schedulers from the file
/proc/net/psched.
The available schedulers are listed in the following questions; you
can say Y to as many as you like. If unsure, say N now.
2. Abaixo script bastante simples, no meu entendimento afeta TODOS os pacotes que transitam por "eth0":
#!/bin/bash
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 512kbit burst 15k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 32kbit ceil 32kbit burst 15k
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
3. Testes de envio e recepção do mesmo arquivo, observem a diferença gritante do tempo entre o envio (saida) e a recepção (entrada):
root@carloslessa teste]# time scp 256.gz 192.168.1.1:/root/temp/8800/
root@192.168.1.1's password:
256.gz 100% |***********************************************************| 250 KB 00:00
real 1m14.214s
user 0m0.000s
sys 0m0.010s
[root@carloslessa teste]
[root@carloslessa teste]
[root@carloslessa teste]# time scp 192.168.1.1:/root/temp/8800/256.gz .
root@192.168.1.1's password:
256.gz 100% |***********************************************************| 250 KB 00:00
real 0m4.320s
user 0m0.000s
sys 0m0.010s
4. Tirem suas próprias conclusões. Comentários são bem vindos.
» Postado por: Otavio Augusto em janeiro 16, 2004 02:37 PM, 200.202.250:
O controle de input pode ser feito na mesma maquina com igual qualidade se a maquina posuir duas interfaces de rede (ex.: eth0 e eth1) e criando uma qdisc para cada placa de rede.
So minha sugestao . uso aqui desta forma com CBQ e pelo qe li no artigo acima nao eh diferente
» Postado por: CarlosLessa em janeiro 16, 2004 03:03 PM, 200.199.64.:
Concordo completamente com os comentários de Marcelo em janeiro 16, 2004 01:14 AM e de Otavio Augusto em janeiro 16, 2004 02:37 PM.
Acescento duas observações:
1. Sob a perspectiva da REDE o controle será exercido na entrada e na saída, porém, em relação a MÁQUINA o controle é sempre na saída.
2. Quando controlamos a entrada na rede os pacotes já trafegaram na WAN e então serão descartados e conseqüentemente retransmitidos (TCP). Pergunto: Conseguiremos controlar o tráfego de entrada sem piorar a situação do link? A pilha de protocolos TCP/IP, de onde os pacotes estão vindo, se ajustará automaticamente e enviará pacotes conforme a capacidade do receptor?
» Postado por: Marcelo em janeiro 16, 2004 03:41 PM, 200.247.140:
Carlos Lessa, não entendi exatamente o que vc quis dizer, porém, com relação ao TCP/IP a resposta é sim. O protocolo (TCP) sempre tenta enviar os pacotes o mais rápido possível, se a perda dos pacotes for muito alta ele diminui a velocidade até encontrar um bom termo entre a velocidade e a perda dos pacotes.
» Postado por: gmlinux em janeiro 17, 2004 04:33 PM, 200.157.165:
Observe que o controle ocorre em um buffer (fila), os pacotes sao ordenados conforme a politica adotada, ja os pacotes que entram para aplicações locais nas máquinas são repassados a buffers relativos a cada socket (se não me engano), assim a afirmação do autor parece correta, no entanto, é lógico, que do ponto de vista do pacote que sofre forward, se eu controlo a saida do mesmo na outra interface, é possível controlar o tráfego que "entra na rede", lembrem-se que se o fluxo de uma conexão for controlada desta maneira, na outra interface, no qual o fluxo entrou, o TCP vai controlar a sua window, evitando descarte de pacotes.
Pesso, sinceramente, que se eu estiver incorreto, me comuniquem. Obrigado
» Postado por: alvaro em janeiro 17, 2004 09:49 PM, 200.167.250:
Se tem varias coisas em que o kernel linux esta anos atras dos sistemas BSD, uma delas ainda é controle e simulacao de link. Essas variacoes mal implementadas ou amputadas do ALTQ da Sony ou meramente inspiradas estao aquem do que se consegue hoje com as implementacoes ALTQ do netbsd, openbsd (junto com pf), freebsd (ALTQ) ou ainda as implementacoes nao inspiradas no ALTQ e provavelmente a ferramenta mais simples -- e uma das mais poderosas -- para realizar esse tipo de servico, o dummynet do freebsd.
» Postado por: Fábio Brancati em janeiro 21, 2004 09:14 AM, 200.231.0.6:
Carlos seu artigo é exelente, muito bom mesmo.
So pra galera não se perder no link do HTB.INI, aqui esta o link certo.
http://freshmeat.net/projects/htbini
Esse é o correto sem o "." .
Mas do mais está tudo exelente, valeu mesmo.
» Postado por: Júlio César Arraes em março 23, 2004 11:27 AM, 200.146.155:
Gostaria de saber onde encontro uma documentação a nivel de usuário iniciante sobre como delimitar uma certa quantidade de banda usando um servidor de comptartilhamento em linux mandraqke 8.2
» Postado por: Nitronet em maio 5, 2004 08:50 AM, 200.162.7.2:
Ola linuxmaniacos....
Podemos usar tambem o CBQ pra fazer controle de banda aconselho vc´s usarempor servico assim ele limita o tipo de servico tipo deixa:
100k --> squid
200 --> HTTP
como cbq e simples fazer isto existem bonsdocumento na internet visitem o raut-u da unicamp uq eexistem milhoes de exemplos
www.rau-tu.unicamp.br/linux
» Postado por: CRASH2k em junho 17, 2004 09:49 PM, 200.96.129.:
Achei o artigo bom. Errar é humano, e o autor se "equivocou" apenas em relação a necessidade de um Linux na outra ponta (não é necessário), mas a limitação no tc é feita na saída sim.
Imagine um fw com duas placas de rede.
- eth0 para internet
- eth1 para rede local
a) Como é que se limitaria os downloads!?
Definindo um controle de banda na eth1, quando o firewall entregar os pacotes aos clientes. Ou seja, na "saída".
Se a outra ponta enviar mais rápido que o esperado, alguns pacotes poderão ser bloqueados silenciosamente e liberados mais adiante conforme os critérios adotados pelo algoritmo em questão (CBQ, HTB e etc). Se não me engano, o controle nos dois sentidos só é possível se trabalharmos com o IMQ.
b) Como é que se limita os uploads!?
Definindo um controle de banda na eth0, quando o firewall entregar pacotes ao roteador de Internet. Ou seja, na "saída".
Isso vale mesmo para esses scripts prontos como cbq.init e htb.init.
Nessa vc consegue limitar a banda independente da outra ponta implementar um controle de banda.
A utilização do math no iptables é outro esquema, totalmente diferente do que foi demonstrado no artigo - não tem NADA a ver com tc. Com o math o que ocorre é um DROP silencioso para pacotes de INPUT (se escolher assim), mas ai a resposta vai na paulada e vc apenas retarda um pouco (em termos de controle não dá nem p comparar). Isso ai é praticamente a mesma coisa que um controle primário com o módulo limit. Só que isto é MUITO diferente do que foi tratado.
» Postado por: Flyer em julho 21, 2004 08:43 AM, 200.206.167:
Pessoal, eu gostaria de fazer o controle de banda bara usuários de internet, ou seja, tamanhos de banda diferentes para cada ip e upload igual para todos... Alguém poderia me ajudar, por favor??
Obrigado pela atenção!!
Abraços
» Postado por: online poker em agosto 15, 2004 05:05 PM, 211.138.91.:
7855 Get your online poker fix at http://www.onlinepoker-dot.com
» Postado por: play blackjack em agosto 16, 2004 08:32 PM, 24.248.106.:
1577 black jack is hot hot hot! get your blackjack at http://www.blackjack-dot.com
» Postado por: Roberto em setembro 2, 2004 05:27 PM, 200.146.155:
Amigo parabens pelo comentário.
Tenho uma dúvida e gostaria q me ajudasse, estou montando uma rede sem fio e pretendo usar o servidor linux, gostaria de saber se com o Linux Kurumimm eu posso ter o controle da banda ou qual linux é recomendado, e como isso é feito.
Obrigado!!
» Postado por: Leandro em setembro 30, 2004 08:46 PM, 200.150.15.:
Recomendo uma lida no:
http://www.underlinux.com.br/bandlimit.php
Lá tem um tutorial para:
- Patch no Kernel para CONNMARK e CLASSIFY
- Atualização do IPTABLES
- Instalação do modulo IPP2P -> Perfeito para o controle de P2P
Ja para a parte do TC, é só diversão... e muita pesquisa...
---------------------------------------
Sobre o controle de UP e DOWN...
Sim, é possivel. Se vc tiver 2 interfaces e adicionar a regras do TC para as duas...
Devemos lembrar que, o TCP/IP inicia as suas conexões de "baixo para cima"... assim que ele "perceber" que pacotes esão sendo perdidos, ou a resposta está demorando muito (derrubados ou atrazados pelo HTB/CBQ), a conexão irá estabilizar numa certa taxa...
-------------------------------------
Estou precisando aprender a alterar o comando do U32:
ip dport NN 0xffff.
Essa regra filtra somente a porta especificada NN... eu preciso de um RANGE DE PORTAS.
Sei que o 0xffff é uma máscara de 32 bits, mas não sei como altera-la para abranger o meu RANGE....
Ajudas serão MUITO bem vindas...
OBS: Desisti de utilizar o IPTABLES/MARK com o TC/FW... não esta funcionando por algum erro que eu não sei.
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.