Página 3 de 8 PrimeiroPrimeiro 1234567 ... ÚltimoÚltimo
+ Responder ao Tópico



  1. Citação Postado originalmente por JorgeAldo Ver Post
    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!

  2. Citação Postado originalmente por JorgeAldo Ver Post
    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?



  3. Citação Postado originalmente por JorgeAldo Ver Post
    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.

  4. 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.



  5. Citação Postado originalmente por JorgeAldo Ver Post
    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!






Tópicos Similares

  1. Respostas: 2
    Último Post: 14-04-2014, 16:52
  2. cache full com hotspot
    Por pedrovigia no fórum Redes
    Respostas: 4
    Último Post: 07-11-2008, 19:56
  3. (Cache Full) com (Hotspot + RADIUS)
    Por e-eduardo no fórum Redes
    Respostas: 13
    Último Post: 05-04-2008, 10:07
  4. Respostas: 7
    Último Post: 30-06-2007, 12:20
  5. Respostas: 2
    Último Post: 14-01-2007, 11:48

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L