Cache Full com controle individual por cliente

Bom dia Pessoal,

Depois de muito pesquisar sem resultados, resolvi postar o meu problema aqui.

Já esta rodando na minha rede um Servidor WebCache belezinha, fazendo o cache 100% e tudo mais, mas o grande problema é que quero fazer um controle de banda individual por cliente quando o mesmo estiver usando os arquivos do cache. Por exemplo:

1 cliente de 600k esta vendo um video do youtube que esta no cache, a banda dele vai automaticamente para 1M mas esse 1M seja restrito a ele e não compartilhado se uma 2ª pessoa estiver pegando arquivos do cache.

OBS: as marcações dos pacotes do cache com regras de mangle ja estão prontas, preciso apenas da logica do controle de banda.


Desde já agradeço a Todos!

Abraços!

Otima ideia, acompanhando espero que algum dos Mestres ajudem...

:proud:

esqueci de especificar que esse controle de banda tem que ser feito no mikrotik.

qual equipamento vc usa nos clientes?

Citação:

---

Postado originalmente por conquesttelecom

qual equipamento vc usa nos clientes?

---

Amigo,

Tem todo o tipo de equipamento, desde plaquinhas até NANOLOCO5.

fiz a pergunta pq no meu caso uso nano m5 e air grid nos clientes entao dexei o proxy livre a banda como cache ful e limitei de 5 a 10 megas no proprio nano ou airgrid
assim o cliente contrata 300k entrego 300kbps banda normal e o que ta no cache entrega 6 megas
lembrando que tenho um servidor de cache em cada torre onde faco isso

nao uso banda alta onde e cliente com placa pci, sua base nao vai passar banda suficiente pra eles

Citação:

---

Postado originalmente por conquesttelecom

fiz a pergunta pq no meu caso uso nano m5 e air grid nos clientes entao dexei o proxy livre a banda como cache ful e limitei de 5 a 10 megas no proprio nano ou airgrid
assim o cliente contrata 300k entrego 300kbps banda normal e o que ta no cache entrega 6 megas
lembrando que tenho um servidor de cache em cada torre onde faco isso

---

Isso realmente é uma boa, mas como eu comprei o provedor de outra pessoa, aqui tem MUUUIIITAAA plaquinha ainda e não vale a pena trocar,

Mas obrigado por enquanto.

Os meus enlaces de PtP para as repetidoras são todos com ROCKETM5, tenho banda pra aguentar bastante coisa, mas o que limitaria seria o 2.4Ghz, mas não pretendo liberar os 5 - 10 Megas que vc libera ai, apenas dobrar a velocidade, por exemplo de 400k -> 800k, 200k -> 400k e assim por diante.

procure sobre regras pcq...

Citação:

---

Postado originalmente por JorgeAldo

poiseh, eu lancei uma vez um produto desses.

controlador de banda duplo, se sair do cache sai com up1/down1 se não sair do cache sai com up2/down2.

Ainda tenho os códigos fonte de projeto aqui. Mas o povo ficou tão bitolado em mikrotik que não aceitam que não funcione em mikrotik.

A solução é baseada no FreeBSD + Squid.

DUVIDO (eu não vou dizer que é impossível por que quase tudo tem um jeito) MUITO que alguem consiga fazer isso no mikrotik ou no linux.

Alias, no linux tem como, mas é mais simples no BSD.

A questão toda gira em torno do seguinte :

O controle de banda do Linux (e até mesmo do FreeBSD se for usado o PF) só faz controle de subida, do que é transmitido pela placa.

O DOWN do cliente é o UP da placa LAN e aqui se faz o controle de download do cliente.
Como o UP do cliente é DOWN da placa LAN, nessa placa o cliente sobe livre.

Para compensar, o UP do cliente do ponto de vista da placa WAN é seu UP, o que permite fazer controle de banda aqui, já o DOWN da WAN é o DOWN do cliente e não se faz controle de banda, o que é compensado na LAN.

A filosofia disso é que teoricamente não adianta jogar fora pacotes que já trafegaram pelo link de internet.

Qual o efeito disso ? Uma conexão saindo do cliente e interceptada pelo SQUID não tem controle de banda up. O cliente manda como quiser (Pois só é vista pela placa LAN). [PS.: como de todo jeito o squid vai ter que mandar os dados - um form POST grande, ou um upload de arquivo, por exemplo - para cima, esse acaba sofrendo controle de banda, mas não sem sobressaltos]

Já a conexão que o SQUID gera com o mundo exterior não sofre controle de banda (Pois só é vista pela placa WAN). [PS.: Do mesmo jeito que o anterior, com sobressaltos]

Dá pra resolver ? Parcialmente, mas nunca é a melhor solução.

Por que não concordo com essa filosofia ? Por que o protocolo TCP tem o chamado sliding window, que é diminuido (consequentemente diminuindo a velocidade) se algum pacote é perdido. Logo fazer controle de banda tanto no UP quanto no DOWN da placa de rede tem efeito nos clientes/servidores envolvidos, além do que a maior parte dos sistemas operacionais (Mesmo o windows) suporta o bit ECN, que pode explicitamente avisar aos envolvidos na comunicação de que algum roteador no meio do caminho quer que eles diminuam a velocidade pois em algum ponto da rede há um congestionamento.

*PS : Normalmente essa tranferencia do servidor remoto para o cache e do cache para o cliente é feito por buffers de tamanho fixo, por exemplo, de 2k em 2k. Dependendo de como o aplicativo (não apenas o squid) trasfere esses buffers e de seu tamanho em relação ao MTU, pode gerar picos intermitentes na rede, que se vistos num gráfico formariam uma imagem de dente de serra.

---

Obrigado primeiramente pelo post amigo, creio que o seu código seria de grande valor se eu não trabalhasse com Mikrotik.

Mas também não acho que seja impossível de implementar algo do tipo, pois o meu mikrotik ja sabe o que é INTERNET e o que é CACHE, na pior das hipótese uma regra de firewall para cada cliente do Hotspot pode ser funcione, mas vamos aguardar alguma solução em MK e enquanto isso vou dar uma estudada na DICA do AMIGO : pcq.

Obrigado a todos!

Citação:

---

Postado originalmente por JorgeAldo

Vou tentar explicar melhor :

Quando um pacote vai ser transmitido por uma placa de rede, no linux, ele entra num queue.

Por default, esse queue apenas faz o pacote esperar até poder ser transmitido pelo hardware.

Se você ativar os mecanismos de TC (traffic control) do linux, tais mecanismos irão tirar vantagem desse queue, controlando a maneira como ele é usado (derrubando pacotes de conexões que estejam acima da velocidade permitida, por exemplo). É possível criar sub-queues etc.

Por outro lado um proxy HTTP funciona da seguinte maneira : Quando uma requisição é enviada para o proxy (Seja explícitamente ou por interceptação) ela é processada pelo proxy, e, baseado numa consulta interna (Se o pedido já está no cache, etc) ela pode dar origem a uma segunda requisição (espelho) gerada pelo próprio proxy. O problema é que, se o proxy gera uma conexão TCP nova, essa conexão sairá com o IP do squid e não com o IP do cliente que a provocou.

Existem algums macetes com TOS que permitem fazer alguma coisa a respeito, mas no geral o resultado da soma proxy + controle de banda baseado em queue não é favorável a essa função qeu você quer.

É possível solucionar isso no linux/mikrotik usando pcq. Mas não chega nem perto da solução que eu bolei com o FreeBSD.

---

T

Tudo bem amigo, então como seria essa solução de mikrotik com PCP?

Citação:

---

Postado originalmente por JorgeAldo

Pronto, seguinte :

/ip proxy
set cache-hit-dscp=4

; isso significa que um cache hit passa a ter TOS=4

/ip firewall mangle add action=mark-packet chain=output comment="CACHE HIT" disabled=no dscp=4 new-packet-mark=cache-packets place-before=0 passthrough=no

; isso faz os pacotes com TOS=4 serem marcados
/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=1M name=from-proxy packet-mark=cache-packets parent=global-out priority=8 queue=default

Testa ai e me diz, enquanto eu penso em alguma solução que não envolva tirar o controle de banda do hotspot

---

JorgeAldo,

Esse controle funciona sim, testei aqui tambem, mas ele limita todo o trafego do cache, seria praticamente um cache FULL não?

Se tivesse a opção de fazer esse controle dos pacotes marcados por IP de cliente ja resolveria tudo.

hehehehehehe, adoro isso ninguém capaz de ler um manual e dizer algo diferente incrível.....
Aqui mesmo no forum já foi postado material que daria conceito suficiente para qualquer um fazer isso. O que ocorre é que o povo não lê e quando lê não entende por falta de conhecimento (conceito técnico) e sabem porque, porque a maioria só sabe pedir, ver copiar e colar e a minoria e capaz de fazer algo em geral os mais antigos no forum.
Porque a moçada nova não se salva nem 5%, mas apesar do meu desabafo aos crtl+c e ctrl+v vamos ao que interessa na minha próximo aqui.

Citação:

---

Postado originalmente por JorgeAldo

O problema consiste no seguinte :

1 - O hotspot cria seus próprios queues para os clientes logados.

2 - Isso ai precisa de um queue por cliente para limitar a banda.

O resultado é que você :

1 - Vai ter que fazer ao contrário (Marcar tudo QUE NÃO SEJA CACHE HIT).

2 - Cadastrar os clientes, não com a banda que eles deveriam ter, e sim com a banda máxima no caso de cache hit.

3 - Dar um jeito de criar um queue por cliente com a banda real (sem cache hit).

Esse segundo queue deve ser filho do primeiro.

4 - Fazer com que todos os pacotes atravessem o primeiro queue.

5 - Fazer com que os pacotes que NÃO FOREM CACHE HIT ou que não forem relacionados à HTTP passarem também pelo segundo queue.

Dai funciona.

Mas o que atrapalha ? O hotspot cria um queue por cliente.

Voce vai ter que fazer os queues por fora, sem interferencia do hotspot, o hotspot só vai servir para autenticar, não para determinar a banda.

Serve ?

---

Show de bola Jorge Aldo, Funcionou belezinha, desativando o controle de velocidade do Hotspot e fazendo o que vc disse. Abraço!

Citação:

---

Postado originalmente por minelli

hehehehehehe, adoro isso ninguém capaz de ler um manual e dizer algo diferente incrível.....
Aqui mesmo no forum já foi postado material que daria conceito suficiente para qualquer um fazer isso. O que ocorre é que o povo não lê e quando lê não entende por falta de conhecimento (conceito técnico) e sabem porque, porque a maioria só sabe pedir, ver copiar e colar e a minoria e capaz de fazer algo em geral os mais antigos no forum.
Porque a moçada nova não se salva nem 5%, mas apesar do meu desabafo aos crtl+c e ctrl+v vamos ao que interessa na minha próximo aqui.

---

Esse é o mal do ser humano, se achar superior, provavelmente você é o sabidão e "O CARA" de redes, por que, tomara Deus que quando você tiver alguma dificuldade, UM ZÉ MANÉ lhe dê uma dica BOA como esta.

Passar bem.

Citação:

---

Postado originalmente por rodrigoMK

Esse é o mal do ser humano, se achar superior, provavelmente você é o sabidão e "O CARA" de redes, por que, tomara Deus que quando você tiver alguma dificuldade, UM ZÉ MANÉ lhe dê uma dica BOA como esta.

Passar bem.

---

Não, não me acho superior, não sou o sabidão, não sou "O CARA" não sou melhor do que ninguém aqui no forum.
Aprenda a ser educado e já começará melhorando muito.
Se tivesse prestado atenção no que escrevi viria que:
"vamos ao que interessa na minha próximo aqui..."
Sendo assim se pelo menos interpreta-se o texto entenderia que estou fazendo algo que não costumo fazer que é arrumando um ctrl+c e ctrl_v para ajudar a quem ler esse poste, já que a maioria tem preguiça de ler ou até traduzir o manual ou documentação disponível no wiki da mikrotik.

Pessoal tento aqui resumir em regras o que o titulo do tópico diz.
Claro que terão de adaptar as regras a rede na qual forem utilizar, de acordo com cada rede as regras podem sofrer e muito alterações para seu funcionamento correto.

Segue explicações básicas:
Clientes = Aqui deve conter a classe de IP dos clientes que deverão passar pelo proxy.
Sem_Proxy = Aqui deve conter os IPs ou classes de IPs que não terá o cache feito geralmente usado para sites governamentais.

Código :

---

/ip firewall address-list
add address=10.10.10.0/24 comment="" disabled=no list=Clientes
add address=200.157.0.0/16 comment=ReceitaNet disabled=no list=Sem_Proxy

---

Marcação das conexões vindas do Proxy.
Marcação dos pacotes vindos do Proxy.

Código :

---

/ip firewall mangle
add action=mark-connection chain=postrouting comment="InstallAPP_Cache" content="X-Cache: HIT from InstallAPP" disabled=no new-connection-mark=LinuxInstallAPP_Cache-Conn-HIT passthrough=yes protocol=tcp
add action=mark-packet chain=postrouting comment="" connection-mark=LinuxInstallAPP_Cache-Conn-HIT disabled=no new-packet-mark=LinuxInstallAPP_Cache-Packet-HIT passthrough=yes

---

Nat para o IP do Proxy
Redirecionamento para clientes IP+Mac e PPPoe.
Redirecionamento para clientes HotSpot.

Código :

---

/ip firewall nat
add action=masquerade chain=srcnat comment="NAT InstallAPP_Cache" disabled=no src-address=192.168.10.0/24
add action=dst-nat chain=dstnat comment="Redirect - InstallAPP_Cache" disabled=yes dst-address=!192.168.10.2 dst-address-list=!Sem_Proxy dst-port=80 protocol=tcp src-address-list=Clientes to-addresses=192.168.10.2 to-ports=5128
add action=dst-nat chain=pre-hotspot comment="Redirect HotSpot - InstallAPP_Cache" disabled=yes dst-address=!192.168.10.2 dst-address-list=!Sem_Proxy dst-port=80 hotspot=auth protocol=tcp src-address-list=Clientes to-addresses=192.168.10.2 to-ports=5128

---

Aceitar trafego do Proxy
Bloquear acesso externo ao Proxy

Código :

---

/ip firewall filter
add action=accept chain=forward comment="Aceita InstallAPP_Cache" disabled=no src-address=192.168.10.0/24
add action=accept chain=forward comment="" disabled=no dst-address=192.168.10.0/24
add action=drop chain=input comment="Bloqueio InstallAPP_Cache" disabled=no dst-port=3128 in-interface="Router" protocol=tcp
add action=drop chain=input comment="" disabled=no dst-port=8080 in-interface="Router" protocol=tcp

---

Queue Type responsável pelo titulo do tópico. (Deve-se tomar cuidado com este tipo de Queue Type - Para cada rede deve-se aplicar de uma forma)

Código :

---

/queue type
add kind=pcq name=InstallAPP_Cache pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000

---

Controle da Banda do que foi marcado vindo do Proxy.

Código :

---

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=10240 name="2 - InstallAPP_Cache_Full" packet-mark=LinuxInstallAPP_Cache-Packet-HIT parent=global-out priority=2 queue=InstallAPP_Cache

---

Observem que esta Queue Tree tem sua "queue" selecionada para a Queue Type adicionado anteriormente "InstallAPP_Cache" e não para a "queue" padrão "default".
Na Queue Type anterior vocês devem ter reparado que foi setado pcq-total-limit=2000, logo tudo que vier do Proxy terá seu máximo de trafego na rede de 10MiB, como configurado na Queue Tree e cada cliente 2MiB como configurado no Queue type.
Recomendo o estudo do manual do Mikrotik e também de documentação sobre PCQ no Mikrotik, pois só a aplicação das regras não serão suficiente para o perfeito funcionamento.

Link´s para consulta:
http://wiki.mikrotik.com
http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ
https://under-linux.org/blogs/m4d3/p...-por-m4d3-852/

Caro leitor se foi útil, então agradeça.

Obrigado pelas dicas, irei fazer os testes com calma e retorno os resultados.

Abraço

Citação:

---

Postado originalmente por minelli

Pessoal tento aqui resumir em regras o que o titulo do tópico diz.<br>
Claro que terão de adaptar as regras a rede na qual forem utilizar, de acordo com cada rede as regras podem sofrer e muito alterações para seu funcionamento correto.<br>
<br>
<font color="#0000ff"> Segue explicações básicas:</font><br>
.....

---

Boa tarde a todos, caro Minelli e companheiros, pergunto: seria possivel criar uma queue tree (setando a respectiva interface em parent)para cada interface de entrada? por ex. wlan1 (2,4ghz) total cache 2MB, eth1 (5,8ghz) total cache 10MB, etc, para não estourar a capacidade de cada interface nem sacrificar o cache full em detrimento das 2,4ghz???

Se entendi direito o que você quer acredito que seja possível sim. Não diretamente mas creio ser possível.
Só não tenho ambiente para esse tipo de teste aqui.

Citação:

---

Postado originalmente por minelli

Se entendi direito o que você quer acredito que seja possível sim. Não diretamente mas creio ser possível.
Só não tenho ambiente para esse tipo de teste aqui.

---

Então Minelli, obrigado por responder, a idéia é liberar cache "full" de acordo com a capacidade de cada interface...
tive pensando nisso, criar uma queue tree para cada interface e setar o total de download conforme a capacidade da interface, será q mais alguem já tentou isso? assim que testar posto o resultado..

Creio que ninguém tenha tentado já que é algo não politicamente correto.

Buscando um pedadinho do céu.

https://under-linux.org/f211/supern-...r-m4d3-150210/

Se não conseguiu ainda por aqui eu consegui fazer:

Cache Full com ThunderCache 7

Realmente, informação de qualidade tem feito pouca diferença pra maioria, talvez menos de 5% consiga ler um texto com mais de duas linhas e depois implementar com sucesso tendo ajuda do fórum.

Muito triste...

Citação:

---

Postado originalmente por JorgeAldo

minelli, uma coisa que nunca entendi.

É para usar o TOS ou procurar pacotes com conteudo X-Cache: Hit ?

Lembrando que essa solução não resolve o seguinte problema (que pode dar galho para quem tem link pequeno) : O squid, na hora de fazer download, vai buscar sem controle de banda nenhum.

A banda é controlada na hora que o squid manda dele para o cliente, não na hora que o servidor remoto manda para o squid. O que é amenizado pelo fato do squid transferir pedacos do arquivo de cada vez e não o arquivo inteiro.

Mesmo assim a minha solução no FreeBSD acredito ser superior, pois controla a banda do próprio squid.

internet <-> controle da banda 1 (com up/down) <-> squid <-> controle de banda 2 (up/down) <-> cliente

Podendo cadastrar duas bandas de up/down por cliente (por exemplo, 64/128 depois do squid e 256/1024 antes do squid). A banda é controlada MESMO que quem esteja fazendo download seja o squid, e é controlada POR CLIENTE, de tal forma que nunca o squid satura o link.

Nunca vi isso no mikrotik.

Mata essa charada minelli.

---

As regras são um exemplo que devem ser adaptadas de acordo com a rede, logo em alguns casos (dependendo do proxy usado) ele poderá marcar com DSCP(TOS) ou por Comment.

As regras aqui apresentadas são referencia ao titulo do tópico logo a "limitação do proxy para o cliente" e não a velocidade que o proxy baixa da internet.
Mas para informa-lo é possível sim ter o controle do proxy para a net e do proxy para o cliente e fazer como você quer. Tenho isso em alguns clientes em pleno funcionamento e rodando 100% a alguns anos já.

Agora sou claro se pensa que vou postar aqui qualquer coisa sobre isso esqueça pois chamais o farei.

Citação:

---

Postado originalmente por JorgeAldo

minelli, tem alguma coisa errada no teu exemplo.

O cliente vai ter por exemplo 1024kb da assinatura, MAIS 10mb/sec do que vier do cache, confere ? Fazendo o cliente ficar com 11mb/sec.

Por que o exemplo que eu dei vai limitar a 10mb/sec combinado (tanto não cache hit, quanto cache hit) e no máximo 1mbit/sec se não for cache hit. Justamente por isso um queue deve ser filho do outro...

---

Opá vamos reanalisa-lo então....
O que eu publiquei aqui foi:
Independente do que o cliente tem de banda setada no queue simple (Esquecendo isso pois não é o foco).
Tudo que esta como HIT vindo do cache terá limite a 10MiB (total) sendo que cada cliente não buscará mais do que 2MiB do total setado no queue tree.
Logo o que postei está de acordo com o titulo do post "Cache Full com controle individual por cliente", aparentemente sua interpretação está equivocada.

Citação:

---

Postado originalmente por minelli

Se entendi direito o que você quer acredito que seja possível sim. Não diretamente mas creio ser possível.
Só não tenho ambiente para esse tipo de teste aqui.

---

Tanto é possível e já existe que publiquei em detalhes o metodo de como implantar o recurso. Fico me perguntando como pode o dono do tópico (rodrigoMK) fazer e pergunta e não ler a resposta, como pode ?

Entendam como uma critica construtiva, copiar e colar é pra iniciantes, até quando?

Citação:

---

Postado originalmente por JorgeAldo

Copiar e colar e explicar as vezes é bem diferente do que só copiar e colar.

Não é preciso adaptar o exemplo para o caso específico dele (Isso é trabalho para quem pede). Mas ao menos expliquei o conceito da solução, pelo menos do jeito que eu entendo que deve ser feito (Queue controla banda máxima, queue filho impede que não-cache-hit e trafego não-http ultrapasse a banda normal).

O resto é script.

---

Então JorgeAldo, obrigado por ajudar no fórum, vejo seus posts, de minelli e tantos outros com relativa frequencia, tem bastante gente tentando ajudar no tópico com exemplos relacionados porém limitados. Achei a pergunta bem feita pelo rodrigoMK e até escrevi uma resposta detalhando o procedimento de como implementar.

Resposta aqui!

Eu pergunto se leram a resposta ?
Entenderam o procedimento ? Ficou alguma dúvida ?
Não era exatamente o que o tópico estava solicitando ?

Acho que é isso.

Fala Luciano você andava sumido hein......

Eu vi e li sim o seu poste e também sabia que era possível, mas algumas coisas prefiro reservar para clientes de contrato. Agora garanto que poucos sequer leram e muito menos ainda entenderam isso você pode ter certeza, rssssss....., tudo por que a minoria lê algo com mais de 10 linhas como você mesmo disse, rs....
Bom como sei que vai ao MUM te espero lá.

também utilizo isso em meus clientes a algum tempo...me baseei num post do Luciano a um tempo atra sobre regras pcq,criei um Qos próprio para cache,aumentou muito a eficiência do cache.
bom ter vc de volta amigo sucesso.

Citação:

---

Postado originalmente por sostenes

também utilizo isso em meus clientes a algum tempo...me baseei num post do Luciano a um tempo atra sobre regras pcq,criei um Qos próprio para cache,aumentou muito a eficiência do cache.
bom ter vc de volta amigo sucesso.

---

É de pessoas como você que o fórum precisa, parabéns por ter implantado por conta própria é prova de que busca o conhecimento.

sostenes, falando em cache se quiser testar o N!MOC posta no tópico onde dei as explicações que te passo as coordenadas.

Abraço a todos.

No squid vc pode colocar pools com TOS que deseja

acl banda_512k src 10.0.1.0/255.255.255.0
tcp_outgoing_tos 0×20 banda_512k

acl banda_256k src 10.0.2.0/255.255.255.0
tcp_outgoing_tos 0×22 banda_256k

acl banda_128k src 10.0.3.0/255.255.255.0
tcp_outgoing_tos 0×24 banda_128k

Agora é só brincar com as mangles e queues da vida conforme a sua imaginação.

Preciso fazer funcionar o web proxy dentro do mk 5.1. Como proceder?

Luciano Rampanelli

Desculpa não ter respondido antes, mas consegui fazer o PCQ funcionar sim e ja estou melhorando ele baseado no seu post, estou fazendo o CACHE FULL por plano do cliente, Estou com o seguinte cenário:

Estou vendendo plano de 1M, 2M e 3M, para o plano de 1M libero 1200k de cache e faço um BURST descendo a banda que não seja do cache pra 700k, no de 2M libero 2200k de cache e BURST para 1400k e assim proporcionalmente nos outros planos. Assim que conseguir funcionar perfeitamente posto os resultados aqui.

Abraços!