Controle de banda no cliente

Segue abaixo o texto que encontrei e gostaria de colocar para os comentários dos companheiros com mais experiencia.
É uma realidade o que diz o texto?

Normalmente o controle de banda em um provedor de acesso Wireless é feito no servidor que usa regras estáticas para descartar os pacotes até que se atinja a velocidade pretendida. Isso acarreta um sério problema já que os pacotes saem do cliente, via equipamento de rádio, passam pelo POP principal (AP) e chegam ao provedor para só então fazer o controle de banda com descarte de pacotes. Note que os pacotes continuam a passar pelo POP principal, fazendo com ele trabalhe mais, e sem necessidade, já que os pacotes serão descartados somente no Servidor. Se a máquina do cliente estiver contaminada com certos vírus ou softwares P2P (Emule, Edonkey, Kazaa, Torrent, etc), que enviam grandes requisições de pacotes UDP ou TCP, o problema será maior ainda, chegando ao ponto de um só cliente derrubar o POP como um todo. Sniffers de rede, como o Iptraf e o tdpdump, também não serão de grande valia, já que o POP estará tão congestionado que as informações chegarão (se chegarem) totalmente truncadas dificultando a descoberta do problema.
Com isso os técnicos tentarão trocar equipamentos, cabos, conectores, antenas, gastarão muito dinheiro, sendo o problema ocasionado, muitas vezes, por um só cliente. Assim é IMPRESCINDÍVEL que o controle seja feito no cliente, antes que os pacotes subam para o POP, fazendo com que o AP principal trabalhe muito mais solto, já que ele repassará somente o tráfego necessário. Controlando, também, a banda de upload evita que grandes requisições de pacotes, comprometam o desempenho do POP.
Fazendo NAT também no cliente, teremos a certeza que eles não se enxergarão e possibilitando fazer regras de firewall protegendo a sua rede e tornando o serviço mais profissional.

olá amigo. Antigamente aqui no provedor controlavamos a banda no radio do cliente. Dai acontecia o que o cara disse se ele usa-se p2p o radinho fazendo nat e com aprouter não segurava mais a banda. Segurava so navegação, mas trafego p2p não. Não entendi a parte que ele disse sobre os POP, aqui no provedor os pop´s funcionam em bridge (ap-bridge) eles so repassam o trafego correto? como fazendo controle de banda no cliente isto vai melhorar? (me atrapalhei nesta hora)

até mais...

bom post!....

Citação:

Postado originalmente por byosni

olá amigo. Antigamente aqui no provedor controlavamos a banda no radio do cliente. Dai acontecia o que o cara disse se ele usa-se p2p o radinho fazendo nat e com aprouter não segurava mais a banda. Segurava so navegação, mas trafego p2p não. Não entendi a parte que ele disse sobre os POP, aqui no provedor os pop´s funcionam em bridge (ap-bridge) eles so repassam o trafego correto? como fazendo controle de banda no cliente isto vai melhorar? (me atrapalhei nesta hora)

até mais...

bom post!....

Pois é isso que me chamou a atençao. O normal é o que todo mundo faz, controle de banda no servidor.
Estes APs cliente normalmente não são bons para controle de P2P. Você chegou a limitar no layer7 do aprouter o p2p?

Ou só se usar no cliente algum ap mais confiável para isso. Mas aí extrapola os custos para o assinante.

controle deve ser feito em TODO percurso..

cliente <--> AP <--> gateway

:)

Citação:

Postado originalmente por alexandrecorrea

controle deve ser feito em TODO percurso..

cliente <--> AP <--> gateway

:)

Então, em parte o que eu li é verdadeiro.
Agora uma pergunta Alexandre. Se colocar controle em todo o caminho isto não poderá sobrecarregar a rede? E se o AP, destes com firmware embarcado, estiver em bridge, aí o controle não vai funcionar, né?
Mas eu vou fazer um teste como voce disse para ver o que acontece.

bom .. sobrecarregar acredito que vai depender do hardware que estiver.. mas sobrecarregar a REDE.. nao vai nao..

ap no cliente nunca deve ficar em BRIDGE.. sempre em modo WISP .. isolando a(s) maquina(s) do cliente da sua rede... fazendo NAT

no ap.. em bridge, funciona QOS .. o ideal eh que este ap seja roteado.. autenticando o cliente (no caso de pppoe ou hotspot) .. pra frente do ap nao precisa de controle de qos pois o ap ja estaria controlando..

em modo bridge.. vc precisa criar as regras para cada usuario... se for pppoe .. nao tem como controlar no 'meio do caminho' ... mas pppoe a performance da rede melhora bastante. so pelo fato de nao existir broadcasts.. arps requests, etc etc.. sem falar no isolamento intra-cliente

Controle de upload no cliente

Na minha opiniao, o controle de trafego ideal acontece da seguinte forma:

Upload: Cliente
Download: Server/GW

Ou seja, Upload controlado na interface do cliente e download na interface do GW.

Me ocorre agora somente 2 formas de fazer com elegancia e simplicidade:

1 - Usando Aps + Vlan pra canalizar o trafego.
2 - Usando HC Gateway.

Aqui controlo tb em todo o percurso, ou seja, no cliente e no pop tb, só que uso um detalhe, por exemplo se o cliente tem banda 256 k uso no cliente 400 k e no pop 256 k isso dá um gas a mais do cliente até o pop pra prevenir eventual perdas e garantir sempre a bando ao cliente, claro se o cliente é daqueles que fica 24 h baixando....dai deixo 256 k no pop e 256 k no cliente....

A grande vantegem de controlar todo percurso é justamente os virus...pois como ja foi dito 1 só maquina infectada mata toda a rede.

OBS: quem usa cache full não dá pra fazer controle no cliente....

Abraços

Jodrix

Olha 1929, eu acho que o alexandre falou basicamente tudo.

vou tentar explicar o que acontece, suponho que vc saiba como funciona os pacotes, entao nao vou falar muitos detalhes, so alguns pra quem e mais leigo que vc.

toda a informacao e transformada em pacotes, estes pacotes sao pedaços da informaçao, e um cabeçalho neste cabeçalho tem as informaçoes de onde veio o pacote e pra onde ele vai e onde ele pasou, isso gera processamento, seu servidor tem que pensar a respeito disso e escrever no pacote tambem.

do outro lado a maquina que recebeu o pacote manda uma resposta de ok falando que o pacote chegou e foi lido.

no controle de banda o pacote que nao e repasado ele consome menos do roteador que e a funçao que o servidor que ta controlando a veloidade faz

um exemplo quando vc manda 5 pacotes mais a sua velocidade não permite isso permite so 3, o roteador vai pegar os primeiros 3 e passar os outros 2 vão morrer ali, assim sua maquina vai esperar a resposta dos cinco pacotes que ela mandou, mais so vai receber a resposta dos 3, então quando o tempo de esperar pela resposta passar ela vai mandar os outros 2 pacotes. Assim a velocidade e controlada, com o tempo de espera dos próprios pacotes, a coisa foi pensada assim justamente por causa das sobrecargas.

o roteador trabalha em todos os pacotes deste jeito para poder entregalos sempre mesmo que o caminho mude

Correto, então agora me vem a questão que o Jodrix levantou.
Fazer controles diferentes. Será que eu entendi bem?

O cliente faz a solicitação, em velocidade maior, pois ele limitou uma velocidade maior no cliente,
Mas ao chegar ao servidor ele vai limitar em velocidade menor, descartar o excedente e repassar para a net.
Na volta da informação ele vai receber na velocidade que está acertada para ele, mas como o servidor vai mandar mais pacotes para o cliente se na volta a informação que o servidor vai enviar está limitada pela velocidade menor e não maior?

No caso do proxy eu entendo que aí sim ele vai mandar na velocidade que o proxy permitir, mas se no cliente estiver controlado ele não vai conseguir entregar.

É isso mesmo?

Quando coloca o AP em Bridge ele funciona como uma ponte, talvez até sobrecarregue por alguns segundos, mas o descarte de pacote e a negociação são rápidos. Gastasse ms. Para se fazer um controle real da forma que vcs querem, o controle deveria estar efetivamente instalado na maquina do cliente, salvo o cliente que possui ap. O único softwear que conheço com essa função se chama HOSTCERT. Pareceu-me muito bom, mas confesso que não usei na prática. Achei-o quando estava tentando bloquear um cliente que sempre inventava algo para navegar de graça. Se alguém já usou gostaria da opinião.

Completando...

vou dar exemplo do QOS usando modo RED .. (Random Early Detection)

o router via fazendo repasse dos pacotes até o limite da velocidade suportada (ou configurada) pela fila.. quando excedido, ele começa a dropar pacotes randomicamente... forçando assim o "SENDER" re-enviar o pacote em menor velocidade...

Citação:

Postado originalmente por 1929

Segue abaixo o texto que encontrei e gostaria de colocar para os comentários dos companheiros com mais experiencia.
É uma realidade o que diz o texto?

Normalmente o controle de banda em um provedor de acesso Wireless é feito no servidor que usa regras estáticas para descartar os pacotes até que se atinja a velocidade pretendida. Isso acarreta um sério problema .......
.....Assim é IMPRESCINDÍVEL que o controle seja feito no cliente, antes que os pacotes subam para o POP, fazendo com que o AP principal trabalhe muito mais solto, já que ele repassará somente o tráfego necessário.
Controlando, também, a banda de upload evita que grandes requisições de pacotes, comprometam o desempenho do POP.
Fazendo NAT também no cliente, teremos a certeza que eles não se enxergarão e possibilitando fazer regras de firewall protegendo a sua rede e tornando o serviço mais profissional.

SE eu entendi então esta parte final do texto, é importante controloar o UP no cliente para não sobrecarregar desnecessariamente a rede

Citação:

Postado originalmente por alexandrecorrea

Completando...

vou dar exemplo do QOS usando modo RED .. (Random Early Detection)

o router via fazendo repasse dos pacotes até o limite da velocidade suportada (ou configurada) pela fila.. quando excedido, ele começa a dropar pacotes randomicamente... forçando assim o "SENDER" re-enviar o pacote em menor velocidade...

Assim então Alexandre, aquilo que o Jodrix citou sobre dar mais banda no cliente e menos banda para ele no servidor, não tem muito sentido?
Ou eu não entendi nada então?

Se entendi bem, o router percebe quando chega ao limite ele começa a dropar os pacotes, e esses pacotes dropados são reenviados em velocidade mais lenta (a que está configurada).

Se eu entendi bem, quando o cliente faz a requisição, por exemplo a 400k, ele envia pacotes a 400k, mas ao chegar ao pop este repassa a 256k para o servidor (dropando os pacotes excedentes e retransmitindo em menor velocidade). Daí o servidor responde a 256k e ao chegar ao cliente (que tem 400k) ele recebe os pacotes a 400k.

É isso?

Citação:

Postado originalmente por interhome

Quando coloca o AP em Bridge ele funciona como uma ponte, talvez até sobrecarregue por alguns segundos, mas o descarte de pacote e a negociação são rápidos. Gastasse ms. Para se fazer um controle real da forma que vcs querem, o controle deveria estar efetivamente instalado na maquina do cliente, salvo o cliente que possui ap. O único softwear que conheço com essa função se chama HOSTCERT. Pareceu-me muito bom, mas confesso que não usei na prática. Achei-o quando estava tentando bloquear um cliente que sempre inventava algo para navegar de graça. Se alguém já usou gostaria da opinião.

Não é só fazer controle de MAC no servidor pra impedir o acesso de graça?

Citação:

Postado originalmente por Xororo

Não é só fazer controle de MAC no servidor pra impedir o acesso de graça?

Não. Existe um tópico só falando disso.

Xororo na verdade quando vc manda a informaçao nao tem nada marcando a velocidade do trafego, quando passa pelo servidor que ta controlando a velocidae o servidor ve que ta indo mais do que deve entao ele joga seus pacates que estao pasando do limite fora, com isso seu computador nao recebe a confirmaçao destes pacotes que foram jogados fora, assim depois que passa o tempo de limite de espera de resposta ele manda denovo o que nao chegou do outro lado, o servidor sabe que seu pc vai esperar um pouco, e usa este compartamento pra fazer passar menos informaçoes e controlar o trafego.

nos nao estamos falando de controle por mac estamos flando de controle de banda, que pode ser feito por mac ou por outras informaçoesdo cliente... mais o topico e controle de velocidade

Galera então como podemos resumir a opera??

O modo correto é Controlar a banda no Servidor e no Cliente? controlar a banda no servidor para o caso do engraçadinho burlar o controle do ap cliente?

Sobre alguns aps e firmwares que não controlam a banda, sabemos que é uma distro linux embarcada alguem sabe alguma forma de saber qual distro é? e qual versão do cqb, htb está disponivel no firmware?

Estou com um radio kod770 com firma da appro ele tem controle de banda disponivel nas configurações mas quando configuro ele não guarda as configurações. Alguem sabe um macete?

Abraço

Citação:

Postado originalmente por UlissesCampos

Xororo na verdade quando vc manda a informaçao nao tem nada marcando a velocidade do trafego, quando passa pelo servidor que ta controlando a velocidae o servidor ve que ta indo mais do que deve entao ele joga seus pacates que estao pasando do limite fora, com isso seu computador nao recebe a confirmaçao destes pacotes que foram jogados fora, assim depois que passa o tempo de limite de espera de resposta ele manda denovo o que nao chegou do outro lado, o servidor sabe que seu pc vai esperar um pouco, e usa este compartamento pra fazer passar menos informaçoes e controlar o trafego.

nos nao estamos falando de controle por mac estamos flando de controle de banda, que pode ser feito por mac ou por outras informaçoesdo cliente... mais o topico e controle de velocidade

Quer dizer então que vai haver perda de pacotes caso no pop esteja configurada uma velocidade menor do que no cliente? Dessa forma nem adianta setar velocidade maior pro cliente, vai haver perda e ligeira lentidão depois...

Sim, eu sei, estava apenas apontando uma suposição para o amigo interhome.

Abraços!