Autor Original do texto:
Martin A. Brown
martin@linux-ip.net
http://linux-ip.net
Martin A. Brown
martin@linux-ip.net
http://linux-ip.net
2. Visão Geral dos Conceitos
Essa seção introduzirá o controle de tráfego e examina razões para isso, identifica algumas vantagens e desvantagens e introduz conceitos chaves usados em controle de tráfego.
2.1 O Que é isso?
Controle de Tráfego é o nome dado aos conjuntos de mecanismos e sistemas de enfileiramento pelos quais os pacotes são recebidos e transmitidos sobre um roteador. Isso inclui decidir quais (e se) pacotes aceitar em qual taxa na entrada de uma interface e determinar quais pacotes transmitir em qual ordem e em qual taxa na saída de uma interface.
Na maioria esmagadora das situações, controle de tráfego consiste de uma fila única que coleta pacotes entrantes e os des-enfileira tão rápido quanto o hardware (ou dispositivo subjacente) pode aceitá-los. Esse tipo de fila é uma fila FIFO.
Obs.:
A qdisc padrão sob o Linux é o pfifo_fast, que é ligeiramente mais complexa que o FIFO.
Existem exemplos de filas em toda sorte de software. A fila é uma forma de organizar as tarefas e dados pendentes (veja também Seção 2.5, “Filas”). Como os links de rede tipicamente transportam dados de uma forma serializada, a fila é exigida para gerenciar os pacotes de dados de saída.
No caso de uma máquina desktop e um webserver eficiente compartilhando o mesmo uplink para a Internet, a conseqüente disputada de banda pode acontecer. O webserver pode ser capaz de preencher a fila de saída no roteador mais rápido do que os dados podem ser transmitidos através do link, nesse instante o roteador começa a descartar pacotes (seu buffer fica cheio!). Agora, a máquina desktop (com uma aplicação usuária interativa) pode se deparar com pacotes perdidos e elevada latência. Observe que latência elevada às vezes gera queixas de usuários! Separando as filas internas usadas para servir essas duas diferentes classes de aplicação, pode haver um melhor compartilhamento dos recursos da rede entre as duas aplicações.
O controle de Tráfego é o conjunto de ferramentas que permite ao usuário ter controle granular sobre essas filas e os mecanismos de enfileiramento de um dispositivo colocado na rede. O poder de re-arranjar os fluxos de tráfego e pacotes com essas ferramentas é tremendo e pode ser complicado, mas nada substitui largura de banda adequada.
O termo qualidade de serviço (QoS) é freqüentemente usado como um sinônimo para controle de tráfego.
2.2 O Porquê de usá-lo?
Redes comutadas por pacotes diferem das redes baseadas em circuitos em uma questão muito importante. Rede comutada por pacote por si só não mantém estado. Uma rede baseada em circuito (como um rede legada de telefonia) precisa manter o estado dentro da rede. Por projeto, as Redes IP’s são sem estado e as redes comutadas por pacote; de fato, essa falta de estado é uma das forças fundamentais da rede IP.
O ponto franco dessa falta de estado é a ausência de diferenciação entre os tipos de fluxos. Em termos mais simples, o controle de tráfego permite a um administrador enfileirar pacotes de forma diferente baseado em atributos do pacote. Ele pode simplesmente ser usado para simular o comportamento de uma rede baseada em circuito. Isso introduz a manutenção de estado na rede sem estado.
Existem muitas razões práticas para considerar o controle de tráfego, e muitos cenários em que o uso de controle de tráfego faz sentido. Abaixo estão alguns exemplos de problemas comuns que podem ser resolvidos ou pelo menos melhorados com essas ferramentas.
A lista abaixo não é uma lista exaustiva dos tipos de soluções disponíveis aos usuários de controle de tráfego, mas introduz os tipos de problemas que podem ser resolvidos quando se usa o controle de tráfego para maximizar a usabilidade de uma conexão de rede.
Soluções Comuns de controle de tráfego:
• Limitar largura de banda total a uma taxa conhecida; TBF, HTB com classe(s) filhas;
• Limitar largura de banda de um usuário particular, serviço ou cliente; classes HTB e classificação com um filtro;
• Maximizar taxa de transferência TCP em um link assimétrico; priorizar transmissão de pacotes ACK, wondershaper;
• Reservar largura de banda para uma aplicação particular ou usuário; HTB com classes filhas e classificação;
• Dar preferência a tráfego sensível à latência; PRIO dentro de uma classe HTB;
• Largura de banda gerenciada esgotada; HTB com empréstimo;
• Permitir distribuição eqüitativa de largura de banda não reservada; HTB com empréstimo;
• Assegurar que um tipo particular de tráfego seja descartado; policer associado a um filtro com uma ação drop.
Lembre-se, também que às vezes, é simplesmente melhor adquirir mais banda. Controle de tráfego somente não resolver todos os problemas!
2.3 Vantagens
Quando empregado adequadamente, o controle de tráfego leva ao uso mais previsível dos recursos de rede e menos disputa desses recursos voláteis. A rede então encontra os objetivos da configuração do controle de tráfego. Volume de Tráfego de download pode ser alocado a quantidade razoável de largura de banda mesmo quando o tráfego de mais alta prioridade for servido simultaneamente. Mesmo transferência de dados de baixa prioridade como email pode ter largura de banda alocada sem que afete substancialmente as outras classes de tráfego.
Em uma visão mais ampla, se a configuração de controle de tráfego representa uma gestão que foi comunicada aos outros usuários, então usuários (e, por extensão, aplicações) sabem o que esperar da rede.
2.4 Desvantagens
A complexidade é facilmente uma das desvantagens mais significativa de uso do controle de tráfego. Existem formas de se familiarizar com as ferramentas de controle de tráfego que facilita a curva de aprendizagem sobre o controle de tráfego e seus mecanismos, mas a identificação de uma configuração mal feita de controle de tráfego pode ser um desafio completamente.
O controle de tráfego quando usado de forma adequada pode levar distribuição mais eqüitativa dos recursos de rede. Igualmente pode facilmente ser instalado justamente de uma forma inadequada provoca mais e mais briga na disputa por recursos.
Os recursos computacionais exigem que um roteador suporte a necessidade de um cenário de controle de tráfego que seja capaz de tratar o custo incremental da manutenção das estruturas de controle de tráfego. Felizmente, esse é um custo incremental pequeno, mas pode se tornar mais significativo quando a configuração cresce em tamanho e complexidade.
Para uso pessoal, não existe qualquer custo de treinamento associado ao uso de controle de tráfego, mas uma companhia pode achar que aquisição de mais banda seja uma solução mais simples que implementar controle de tráfego. Treinamento de empregados e assegurar conhecimento profundo podem ser mais custosos que investir em mais banda.
Embora o controle de tráfego em redes comutadas por pacotes cubra uma área conceitual bastante ampla, você pode pensar sobre controle de tráfego como uma forma para fornecer [alguns dos] estados de uma rede baseada em circuito sobre uma rede comutada por pacote.
2.5 Filas
As filas formam o pano de fundo para tudo sobre controle de tráfego e é o conceito integral que está por trás do escalonamento. Uma fila é uma posição (ou buffer) que contém um número finito de itens esperando por uma ação ou serviço. Em implementação de rede, uma fila é o lugar onde os pacotes (nossas unidades) esperam ser transmitidos pelo hardware (o serviço). No modelo mais simples, pacotes são transmitidos em uma base primeiro a entrar primeiro a servir [2]. Na disciplina de implementação de rede de computador (e mais genericamente na ciência da computação), esse tipo de fila é conhecido como fila FIFO.
Sem qualquer outro mecanismo, uma fila não oferece qualquer promessa de controle de tráfego. Existem somente duas ações interessantes em uma fila. Tudo que entra em uma fila é enfileirado na fila. Para remover um item de uma fila é para desenfileirar esse item.
Uma fila se torna mais interessante quando são acoplados outros mecanismos que possa atrasar pacotes, rearranjar, descartar e priorizar pacotes em múltiplas filas. Uma fila pode também usar sub-filas, que permite mais complexidade do comportamento em uma operação de escalonamento.
Da perspectiva da camada superior de software, um pacote é simplesmente enfileirado para transmissão, e o modo e a ordem na qual os pacotes enfileirados são transmitidos é imaterial à camada superior. Assim, à camada superior, o sistema de controle de tráfego inteiro pode aparecer como uma única fila [3]. É somente examinando os internos dessa camada que as estruturas de controle de tráfego ficam expostas e disponíveis.
2.6 Flows (Fluxos)
Um flow é uma conexão ou uma conversação distinta entre dois hosts. Qualquer conjunto único de pacotes entre dois hosts pode ser considerado como um fluxo (flow). Sob o TCP o conceito de uma conexão com um endereço IP e uma porta de origem, e porta e endereço IP destino representa um fluxo. Um fluxo UDP pode ser definido de forma similar.
Os mecanismos de controle de tráfego freqüentemente separam o tráfego em classes de fluxos que podem ser agregados e transmitidos como fluxo agregado (considere o DiffServ). Mecanismos alternativos podem tentar dividir a largura de banda de forma uniforme baseado nos fluxos individuais.
Os fluxos se tornam importantes quando tentando dividir largura de banda de forma uniforme entre um conjunto de fluxos que competem, especialmente quando algumas aplicações deliberadamente constroem um grande número de fluxos.
2.7 Tokens e Buckets
Duas das peças chaves dos mecanismos de shaping são os conceitos inter-relacionados de tokens e buckets.
A fim de controlar a taxa de des-enfileiramento, uma implementação pode contar o número de pacotes ou bytes des-enfileirados quando cada item for des-enfileirados, embora isso exija uso complexo de cronômetros e medidas para limitar a precisão. Em vez de fazer cálculo da ocupação atual e do tempo, um método, usado amplamente no controle de tráfego, é gerar tokens a uma taxa desejada, e somente des-enfileirar pacotes ou bytes se um token estiver disponível.
Considere a analogia de um passeio no parque de entretenimento com uma fila de pessoas esperando a sua vez em algum dos cavalos. Imaginemos uma pista na qual os cavalos galopam a passos fixos. Os cavalos chegam à cabeceira da fila a uma taxa fixada. A fim de curtir o passeio, cada pessoa precisa esperar que um cavalo fique disponível. O cavalo é análogo a um token e a pessoa é análoga a um pacote. Novamente, esse mecanismo é uma limitação na taxa ou um mecanismo de shaping. Somente certo número de pessoas pode experimentar o passeio em um período particular.
Para expandir a analogia, imagine uma linha vazia para o passeio no parque de diversão e um grande número de cavalos de prontidão na pista pronto para transportar pessoas. Se um grande número de pessoas entrar na linha de vez muitas (talvez todas) delas podem experimentar o passeio por causa da disponibilidade dos cavalos que estão esperando. O número de cavalos disponíveis é um conceito análogo ao balde. Um balde contém um número de tokens e pode usar todos os tokens no balde sem considerar a passagem de tempo.
E para completar a analogia, os cavalos no passeio do parque de entretenimento (nossos tokens) chegam a uma taxa fixa e são mantidos somente disponíveis até o tamanho do balde. Assim, o balde é preenchido com tokens de acordo com a taxa, e se os tokens não forem usados, o balde pode ficar cheio. Se os tokens forem usados, então o balde não ficará cheio. Balde é um conceito chave em tráfego que suporta rajada como http.
A qdisc TBF é um exemplo clássico de um shaper (a seção sobre TBF inclui um diagrama que pode ajudar a visualizar os conceitos de token e bucket). O TBF gera taxa (rate) de tokens e somente transmite pacotes quando um token estiver disponível. Os tokens são um conceito genérico de shaping.
No caso de uma fila não precisar de tokens imediatamente, os tokens podem ser coletados até que eles sejam necessários. Coletar tokens indefinidamente negaria qualquer benefício do shaping por isso os tokens são coletados até que certo número de tokens tenha sido alcançado. Agora, a fila possui tokens disponíveis para um grande número de pacotes ou bytes que precisam ser des-enfileirados. Esses tokens intangíveis são armazenados em um balde intangível, e o número de tokens que pode ser armazenado depende do tamanho do balde.
Isso também significa que um balde cheio de tokens pode ficar disponível a qualquer instante. Tráfego regular muito previsível pode ser tratado por baldes pequenos. Baldes mais largos podem ser requeridos para tráfego com comportamento mais caracterizado por rajadas, a não ser que um dos objetivos desejados seja reduzir a rajada dos fluxos.
Em resumo, os tokens são gerados na taxa, e um máximo de valor de tokens de um balde pode ser coletados. Isso permite ao tráfego em rajadas ser manipulado, enquanto aparando e fazendo shape do tráfego transmitido.
Os conceitos de tokens e buckets são intimamente inter-relacionados e é usado tanto no TBF (uma das qdiscs classless) quanto no HTB (uma das qdiscs classful). Dentro da linguagem tcng, o uso de medidores de duas e três cores é indubitavelmente um conceito de token e bucket.
2.8 Pacotes e Frames
Os termos para envio de dados através da rede mudam dependendo da camada que o usuário está examinado. Esse documento vai especialmente sem cerimônia (e incorretamente) descuidar da distinção técnica que existe entre os termos pacotes e frames muito embora eles sejam descritos aqui.
A palavra frame (quadro) é tipicamente usada para descrever uma unidade de dados da camada 2 (enlace de dados) a ser encaminhada ao próximo receptor. Interfaces Ethernet, interfaces PPP, e interfaces T1 são todos nome dados ao frame para as suas unidades de dados na camada 2. O frame realmente é a unidade na qual o controle de tráfego é executado.
Um pacote, por outro lado, é um conceito da camada superior, que representa as unidades da camada 3 (rede). O termo pacote é o termo preferido nessa documentação, embora seja ligeiramente inexato.
________________________________________
[2] Esse modelo de enfileiramento tem sido longamente usado em países civilizados para distribuir alimentos escassos ou equilibradamente provisões. William Faulkner é respeitado por ter andado à frente da linha pra pegar sua parte de gelo, mostrando que nem todos gostam do modelo FIFO, e nos fornecendo um modelo que considera o enfileiramento com prioridade.
[3] De forma similar, o sistema de controle de tráfego inteiro aparece como uma fila ou escalonador para a camada superior que está enfileirando pacotes em sua camada.
Nenhum comentário:
Postar um comentário