Ver Feed RSS

m4d3

Aceleração individual de conteúdo em cache por: M4D3

Avalie este Post de Blog
Documento: MikroTik de a–Z para todos os níveis
Série: SuperN!MOC Cache - v. 0.6.1
Escrito por: Luciano Rampanelli – M4D3

O documento é um pouco extenso vou tentar publicar aqui as principais partes relativas a aceleração individual do serviço de cache, o material é de fácil entendimento e qualquer usuário com conhecimentos medianos será capaz de implantar. Ao final colocarei um link com o download do material completo incluindo as imagens que não consegui exportar para cá.

“Como bons administradores da multiforme graça de Deus, cada um coloque à disposição dos outros o dom que recebeu” (1 Pedro 4, 10)
Fonte: cancaonova

Chegamos a um ponto importante, tanto se ouve falar em CacheFull que a definição propriamente dita se torna confusa, seria um cache cheio ?

CacheFull na definição dos usuários que o utilizam significa enviar o conteúdo web normalmente do tipo multimídia e armazenado em proxy cache local para os usuários/clientes da rede furando o controle de banda convencional da “Queue Simple” utilizando para isso a marcação de pacotes e a “Queue Three” que comumente é utilizada para controle em sistemas de QoS.

O mais comum encontrado em dezenas de paginas web é baseado na marcação de pacotes contendo o parâmetro o que pode ser feito pela tabela “Mangle” na “Chain” postrouting, em seguida na aba “Advanced” em “Content” digite ‘X-Cache: HIT’ e siga para aba “Action” em campo de mesmo nome selecione ‘mark packet’ e em “New Packet Mark” digite cachefull. Sequer darei um exemplo utilizando a “Queue Three” por considerar que este método possui uma série de erros graves.

No entanto existe outro método possível que pode ser aplicado o qual relaciono abaixo alguns dos tópicos que considero mais importantes.

1 – Marcar os pacotes pelo “DSCP/TOS” e não pela “Content”, isso porque este segundo método além de inseguro é ineficaz e exige maior processamento.

2 – Informar por onde o trafego adentra ao MikroTik e/ou para onde segue, isso ajuda a diminuir a carga e evita que a marcação seja utilizada para enviar algum outro conteúdo forjado com a mesma marcação.

3 – Criar uma “Queue Type” que vai fazer o controle individual de uso do conteúdo previamente marcado.

4 – Criar uma “Simple Queue” que será responsável por limitar o tráfego que será enviado para determinada classe de IP’s. E inserir nela o controle individual como veremos a seguir.


1.1 - Comecemos marcando os pacotes, para isso acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General” selecione a “Chain” prerouting, “Protocol” tcp, “In. Interface” EthCache, na aba “Advanced” em “DSCP(TOS)” informe o valor 18 que corresponde a marcação 72 no exemplo. Ainda na mesma regra na aba “Action”, campo de mesmo nome selecione a opção ‘mark connection’ e logo abaixo no campo “New Connection Mark” digite ‘conn_nimoc’. Clique em OK e esta pronta esta primeira regra, o que ela faz é identificar as conexões oriundas do servidor de cache e que contém a marca desejável recebida via “DSCP/TOS”, ainda falta marcar os pacotes dessas conexões o que faremos na segunda regra.

Dica: para saber como funciona a relação entre valores basta saber que 0 = 0, 1 = 4, 2 = 8, 3 = 12 e finalmente 18 = 72, portanto multiplique a marcação informada no MikroTik por 4 e vai obter o valor a ser configurado no parâmetro DSCP/TOS quando suportado pelo sistema de cache. NiMOC Power tem suporte a DSCP/TOS em diversos níveis.

1.2 – Adicione uma nova regra e na abra “General” selecione a “Chain” prerouting, e logo abaixo no campo “Connection Mark” selecione a marcação criada na regra anterior chamada ‘conn_nimoc’, vá até a aba “Action” no campo de mesmo nome selecione ‘mark packet’ e logo abaixo em “New Packet Mark” vamos colocar a identificação dos pacotes como ‘pack_nimoc’, tomando o cuidado de desmarcar “Passthrough” pois não queremos que o mesmo pacote esteja sujeito a receber outra marca depois dessa o que faria com que a marca anterior fosse sobrescrita inutilizando nossa primeira marcação.

3.1 – Em “Queue Type” adicione uma nova a qual daremos o nome de ‘nimoc_conecta’ levando o nome do servidor de cache mais o plano de acesso onde será utilizada. No campo “kind” selecione o tipo ‘pcq’ se não sabe como funciona cada controle de filas recomendo que busque no manual, o pcq é um dos mais práticos e faz muito bem o trabalho neste caso. No campo “Rate” podemos definir duas formas distintas de se trabalhar no caso do pcq, deixando o campo com valor 0 significa sem limite ou seja, o que for definido no queue pai será o limite e os casos que se enquadrarem neste queue type dividirão o valor do limite entre si, pode ser desejável em muitos casos, no nosso exemplo vamos definir o valor de 256k pois queremos forçar este limite individual, logo abaixo nos campos “Limit” e “Total Limit” vamos manter os valores padrões que são adequados para o que já configuramos anteriormente neste exemplo, é interessante que busquem estas informações nos manuais pois elas podem fazer a diferença entre um serviço congestionado e uma internet navegando solta. Na seqüência temos quatro possíveis opções de classificadores ou “Classifier”, vamos marcar apenas uma delas que é a “Dst. Address” ou seja do ponto de vista do servidor “por” endereço de destino.

3.2 – O próximo passo é criar o controle que irá utilizar a “Queue Type” recém criada, acesse “Queue List” e na aba “Simple Queue” criemos uma nova a qual iremos chamar de NIMOC-Conecta, em “Target Address” identifique os IP’s que serão de certa forma favorecidos por ela, no nosso caso os do plano “PC.Conecta” representados pela classe 10.0.0.0/24, nos campos “Max Limit” devemos nos preocupar apenas com o “Target Download”, explicarei logo mais, para este campo vamos utilizar o valor de 2M ou seja 2 Megas.

Seguimos para a próxima aba “Advanced” e nela selecionamos a “Queue Type” de nome ‘nimoc_conecta’ criada no passo anterior.

Chegamos no pulo do gato, temos agora um controle que restringe o consumo em 2 Megas para toda a classe de IP’s 10.0.0.0/24 que atende os clientes do plano de 128k sendo que o controle individual quem faz é a “Queue Type” a qual chamamos de ‘nimoc_conecta’, neste estágio você deve estar se perguntando como identificar os pacotes oriundos do cache para que tal controle seja somente para o conteúdo vindo do cache com a marcação que fizemos, para tanto ali mesmo na aba “Advanced” selecione em “Packet Marks” a marcação criada sobre os pacotes vindos do cache que chamamos de ‘pack_nimoc’. O último passo é fazer com que este controle seja sempre o primeiro na lista “Queue Simple” e para isso basta arrastar para a primeira possição da lista, caso vc utilize HOTSPOT irá precisar de um script para que cada vez que alguém logue no sistema ele redefina a ordem da lista jogando este controle pra primeira posição, como não é o caso do nosso exemplo vou tomar a liberdade e pular esta etapa.

Naturalmente como não marcamos tráfego de upload mesmo que tivéssemos colocado valores nos controles de upload eles não seriam utilizados, por este motivo não temos com que se preocupar.

Com a solução proposta espero liquidar de vez o chamado CacheFull que só traz dores de cabeça e deteriora completamente as conexões wireless, não que o que propomos aqui se implementado erroneamente também não o faça mas a proporção é de 100/1 quando comparado.

O resultado dessa implementação é que o cliente ainda terá os 128k de download quando o tráfego for oriundo da internet porém ele terá mais 256k quando o conteúdo já estiver em cache totalizando uma banda de navegação de 384k fazendo o cliente muito mais satisfeito e o provedor muito mais econômico e competitivo com a banda disponível, como resultado temos uma melhora significativa em serviços com consumo de streaming, o cliente ainda consegue navegar pelos sites mais visitados e falar ao skype ou utilizar tecnologias similares gastando o mínimo de banda do seu link.

Espero que este e outros materiais que tenho disponibilizado em maior ou menor escala, abertamente ou a um grupo de seletos amigos tenha alcance e amplitude que o Pai me permitir.

Se você chegou até aqui parabéns, já consegui o que buscava ao escrever este material.

Os finalmentes:
E não esqueça de quando usar ou citar material de terceiro de incluir as fontes, isso não é vergonha pelo contrário é sinal de respeito e reconhecimento e também nos qualifica. Fórum é lugar de compartilhar, de ajudar, estou de volta após mais de 8 meses afastado dos fóruns e o que mais senti falta foi dos amigos do under-linux que é sem sombra de dúvida o melhor fórum da América Latina voltado ao público Geek.

Luciano Rampanelli / M4D3

Encontrou erros ? Quer fazer um comentário ? Dar sua sugestão ? Poste neste tópico e providenciarei a correção.

http://under-linux.org/f211/supern-m...r-m4d3-150210/
Categorias
Artigos , Dicas , Tutoriais

Comentários

Página 1 de 2 12 ÚltimoÚltimo
  1. Avatar de netxtreme
    Parabéns pelo excelente post. Porém tenho algumas dúvidas.

    1. Suponhamos um cenário em que temos nessa rede, 20 clientes conectados e trafegando simultaneamente, visto que cada 1 com banda de 128k, vc restringiu o trafégo do cache nos 2MB, fazendo as contas a grosso modo teriamos uma banda do cache de 102.4K para cada cliente ( Isto vindo do cache claro ) o que ficaria abaixo do plano normal do cliente. Mesmo com o PCQ isso seria mesmo vantagem ? Não seria melhor fazer um controle criando uma simple queue para cada cliente ?

    2. O nimoc permite trabalhar com resumo de download. Onde possa carregar parcialmente o arquivo do cliente? Caso sim, como ficaria a marcação no mangle do mikrotik ?

    3. O nimoc permite trabalhar em bridge com TProxy?

    Abrs é sucesso pra todos.
  2. Avatar de m4d3
    netxtreme,

    Acho que você não pegou a idéia geral, se você dimensionar errado vai fazer como mandou é claro, oque impede de aumentar pra 4MB ? Outra coisa é que a banda do cache é complementer a do cliente então ele nunca vai ter menos do que contratou.

    O N!MOC não entrega nada parcial, ou esta em cache ou não está, se tiver interesse em testar entre em contato conosco.

    N!MOC trabalha com as mais diversas topologias, inclusive bridge e TPROXY em todas elas.

    Aos demais, postem perguntas relacionadas ao N!MOC no tópico > http://under-linux.org/f273/apresent...e-alta-150352/ assim contribuimos para manter o fórum organizado.

    Ao netxtreme, obrigado por sua participação, espero atendê-lo em breve.

    Abraço
  3. Avatar de AndrioPJ
    bacana.
    podemos ir alem
    dividir os Planos de Internet, cada qual com uma faixa de IP
    e assim, dar velocidade de cache diferentes para cada Plano de acesso.
    por exemplo:
    plano 300k, tem 600k do cache
    plano de 600k, tem 1200k do cache.
  4. Avatar de 1929
    O Nimoc está muito bom aqui. Nunca travou.

    Mas relendo tuas explicações Luciano, fiquei numa dúvida. Quando tenho planos de 512k e 750k por exemplo, automaticamente o sistema irá calcular este adicional de banda e acrescentará ao queus do cliente?

    Os clientes de 750k por ex. navegam dentro disso. Não consegui "flagar" ninguém que fosse além.
  5. Avatar de AndrioPJ
    Citação Postado originalmente por 1929
    O Nimoc está muito bom aqui. Nunca travou.

    Mas relendo tuas explicações Luciano, fiquei numa dúvida. Quando tenho planos de 512k e 750k por exemplo, automaticamente o sistema irá calcular este adicional de banda e acrescentará ao queus do cliente?

    Os clientes de 750k por ex. navegam dentro disso. Não consegui "flagar" ninguém que fosse além.
    O sistema, senao me engano, nao faz o calculo adicional de banda.

    Esse tem que ser configurado no mikrotik para ser feito... é o famoso Cache full, mas sendo usado com o pcq, dessa forma, podemos entregar um adicional para cada cliente.
    Diferente do cache full antigo, onde todos dividiam o mesmo Cache full.

    Outra coisa que da para fazer, é configurar o adicional por Planos de acesso.
    Para tal, precisamos dividir a faixa de IP
    Uma faixa de ip para cada Plano de acesso.
    Ai com o pcq (e cache full) conseguimos dar um adicional de banda para cada cliente, sendo esse adicional diferente em cada plano de acesso.
  6. Avatar de netxtreme
    Eu estou testando algo um pouco diferente, criei uma simple queue pra cada cliente, sendo q ele possui agora 2 queues pra cada cliente, onde uma controla a banda da internet e a outra controla o q vem do cache. Dai pra frente nem precisa explicar pois o funcionamento vai ficar semelhante a qualquer queue.
  7. Avatar de 1929
    Luciano, você alterou alguma coisa na configuração aqui do Proxy? O que era bom, ficou ótimo.

    Agora está acontecendo aquilo que voce falou. Dá para ver perfeitamente um adicional de tráfego em cima do perfil da banda.
    NO plano de 750kbps tenho visto vários usuários com 900 e até mais. E isto sem sobrecarregar o link.
    Ou é o tempo de cacheamento que vai aumentando e assim fica mais conteúdo disponível.?
  8. Avatar de netxtreme
    Acho que cache é igual vinho.

    "Quanto mais velho melhor"

    kkkkkkk
  9. Avatar de 1929
    Até pode Netxtreme. Pensei nisso.

    Mas foi de ontem para hoje.
    E como o suporte do Luciano é bem personalizado, creio que ele fez alguma coisa que ficou excelente.
    Ele tinha me dito que a configuração seria ajustada com o decorrer dos dias.
  10. Avatar de netxtreme
    Brincadeiras à parte, bom provavelmente deve ser mesmo, não conheço o Luciano, muito menos o nimoc, mais esta se apresentando um excelente cache com excelente suporte. Atualmente estou usando o tc 6, esta me atendendo bem não tenho do que reclamar, agora vc esta usando o esquema de controle de banda com pcq, como o Luciano propos no artigo.
Página 1 de 2 12 ÚltimoÚltimo

+ Enviar Comentário