Luiz Gustavo Ender
VisualTC - Uma interface gráfica amigável para
construção de regras de QoS no Linux
São José – SC
Dezembro / 2013
Luiz Gustavo Ender
VisualTC - Uma interface gráfica amigável para
construção de regras de QoS no Linux
Monografia apresentada à Coordenação do
Curso Superior de Tecnologia em Sistemas
de Telecomunicações do Instituto Federal de
Santa Catarina para a obtenção do diploma de
Tecnólogo em Sistemas de Telecomunicações.
Orientador:
Prof. Emerson Ribeiro de Mello, Dr.
C URSO S UPERIOR DE T ECNOLOGIA EM S ISTEMAS DE T ELECOMUNICAÇ ÕES
I NSTITUTO F EDERAL DE S ANTA C ATARINA
São José – SC
Dezembro / 2013
Monografia sob o tı́tulo “VisualTC - Uma interface gráfica amigável para construção de
regras de QoS no Linux”, defendida por Luiz Gustavo Ender e aprovada em 13 de dezembro de
2013, em São José, Santa Catarina, pela banca examinadora assim constituı́da:
Prof. Emerson Ribeiro de Mello, Dr. Eng.
Orientador
Prof. Marcelo Maia Sobral, Dr. Eng.
IFSC
Prof. Tiago Semprebom, Dr. Eng.
IFSC
A melhor maneira de nos prepararmos para o futuro
é concentrar toda a imaginação e entusiasmo na execução
perfeita do trabalho de hoje.
D. Carnegie
Agradecimentos
Agradeço primeiramente a Deus, meu maior protetor, devo a ele tudo que tenho e tudo que
eu sou. Sei que está sempre comigo, em todas as situações propostas, sei que posso confiar, e
que dele vem toda a força e coragem para enfrentar os desafios e dificuldades impostas em meu
caminho.
Dedico meus sinceros agradecimentos à minha famı́lia, que sempre me incentivaram a
traçar meus objetivos e lutar por eles. São exemplos de pessoas para mim. Sou muito grato
pela compreensão, amor, carinho, apoio e paciência que me confortaram durante esse trajeto.
A minha namorada, que esteve sempre me ouvindo, participando e me apoiando em cada
decisão a ser tomada. Foi ela quem esteve comigo sempre, dando-me auxı́lio e compreensão.
Sou grato por sua amizade, parceria, carinho e por ter compartilhado essa experiência com uma
pessoa tão especial.
A todos os professores que fizeram parte dessa caminhada, na busca de adquirir conhecimentos e experiências, sou grato a todos que passaram por essa etapa. Porém, dentre todos,
tenho maior gratidão e carinho pelo professor e orientador Emerson Ribeiro de Mello, que me
mostrou a direção. Além de me orientar, fez-me acreditar que eu seria capaz de atingir meus
objetivos e a finalização desse projeto, e que para isso, eu poderia contar com o seu apoio.
A todos os alunos e ao professor Marcelo Maia Sobral que me ajudaram participando da
avaliação do VisualTC, fornecendo dicas, sugestões para implementações e encontrando “bugs”
no software. Por fim, agradeço aos colegas de classe, os quais estivemos sempre juntos no
decorrer dessa caminhada, compartilhamos muitas risadas, angústias e sempre ajudamos uns
aos outros para alcançarmos um objetivo em comum.
Resumo
A Qualidade de Serviço (QoS) está cada vez mais presente e cada vez mais necessária no
contexto atual das redes. Juntamente com esta demanda, aumentou a utilização do sistema
operacional Linux, por este possuir uma licença gratuita, para implementar polı́ticas de QoS.
Entretanto, a gerência de QoS nos sistemas Linux é complexa e pouco intuitiva do ponto de
vista do usuário, uma vez que as ferramentas disponı́veis para configuração de polı́ticas de QoS
são baseadas em linhas de comando. Este trabalho apresenta o software VisualTC, que tem por
objetivo apresentar uma interface gráfica amigável que facilite a configuração de disciplina de
enfileiramento no Linux. Deste modo, o usuário interage com uma interface gráfica, ao invés
de linhas de comando, que ao final terá um script contendo todas os comandos necessários
para configurar suas disciplinas de filas. Assim, ao utilizar o VisualTC, espera-se que se tenha
um ganho na produtividade. Com este ganho de produtividade, o VisualTC também pode ser
utilizado como uma ferramenta de apoio ao ensino.
Abstract
The Quality of Service (QoS) is increasingly present and necessary in the current context of
networks. Along with this demand, increased the use of the Linux operating system, this has a
free license to implement QoS policies. However, the management of QoS in Linux systems is
extremely complex and unintuitive from the point of view of the user, since the tools available
for configuring QoS policies are based on command lines. This work presents the VisualTC
software, which aims to have a friendly graphical user interface that facilitates the configuration
of queueing disciplines on Linux. In this way, the user interacts with a graphical interface,
instead of command lines, which at the end will have a script containing all the necessary
commands to configure your queueing disciplines. Thus, by using the VisualTC, it is expected
that it has a gain in productivity. With this gain in productivity, VisualTC can also be used as a
tool to support teaching.
Sumário
Lista de Figuras
Lista de Tabelas
1
2
Introdução
p. 12
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 12
1.2
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 13
1.3
Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 13
Fundamentação teórica
p. 14
2.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 14
2.2
Qualidade de serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 17
2.3
Qualidade de serviço no Linux . . . . . . . . . . . . . . . . . . . . . . . . .
p. 19
2.3.1
Disciplinas de enfileiramento . . . . . . . . . . . . . . . . . . . . . .
p. 20
2.3.2
Utilização do TC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 26
Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 27
2.4
3
4
VisualTC
p. 34
3.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 34
3.2
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 35
3.3
Funcionamento do VisualTC . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 38
3.4
Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 43
Avaliação do VisualTC
p. 44
4.1
5
Resultado dos experimentos . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 44
Conclusões
p. 48
5.1
p. 49
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lista de Abreviaturas
p. 50
Referências Bibliográficas
p. 51
Lista de Figuras
2.1
Um modelo de comutação de pacotes [KUROSE J. F.; ROSS 2010]. . . . . .
p. 15
2.2
O funcionamento da Internet. . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 16
2.3
A fila FIFO em operação [KUROSE J. F.; ROSS 2010]. . . . . . . . . . . . .
p. 18
2.4
Um modelo de isolamento dos fluxos das aplicações [KUROSE J. F.; ROSS
2010]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 18
2.5
Um exemplo de disciplina de filas [Brown 2006]. . . . . . . . . . . . . . . .
p. 20
2.6
Modelo de enfileiramento prioritário [KUROSE J. F.; ROSS 2010]. . . . . . .
p. 21
2.7
Operação realizada no enfileiramento prioritário [KUROSE J. F.; ROSS 2010]. p. 22
2.8
Modelo de escalonador SFQ [KUROSE J. F.; ROSS 2010]. . . . . . . . . . .
p. 22
2.9
A operação do escalonador SFQ [KUROSE J. F.; ROSS 2010]. . . . . . . . .
p. 23
2.10 O algoritmo de enfileiramento “balde de fichas” [KUROSE J. F.; ROSS 2010]. p. 24
2.11 Um exemplo da utilização do escalonador HTB. . . . . . . . . . . . . . . . .
p. 25
2.12 Um exemplo da utilização do TC. . . . . . . . . . . . . . . . . . . . . . . .
p. 26
2.13 Modo de visualização tree do phpTCadmin [Carvalho e Abelém 2008]. . . .
p. 28
2.14 Modo de visualização básico do SGSCtrl [Costa 2011]. . . . . . . . . . . . .
p. 29
2.15 Agendamento de tarefas do SGSCtrl [Costa 2011]. . . . . . . . . . . . . . .
p. 30
2.16 Um exemplo da utilização do TCNG . . . . . . . . . . . . . . . . . . . . . .
p. 31
3.1
Diagrama de casos de uso do VisualTC. . . . . . . . . . . . . . . . . . . . .
p. 36
3.2
Diagrama de classe UML do módulo elements. . . . . . . . . . . . . . . . .
p. 36
3.3
Diagrama de pacotes do VisualTC. . . . . . . . . . . . . . . . . . . . . . . .
p. 37
3.4
A interface do VisualTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 38
3.5
Os elementos da paleta lateral. . . . . . . . . . . . . . . . . . . . . . . . . .
p. 39
3.6
A janela de Configurações dos elementos. . . . . . . . . . . . . . . . . . . .
p. 40
3.7
O ambiente Filtros do VisualTC. . . . . . . . . . . . . . . . . . . . . . . . .
p. 41
3.8
Shell script gerado pelo VisualTC. . . . . . . . . . . . . . . . . . . . . . . .
p. 42
4.1
Resultado da avaliação da facilidade de uso. . . . . . . . . . . . . . . . . . .
p. 45
4.2
Resultado da avaliação do script gerado pelo VisualTC. . . . . . . . . . . . .
p. 45
4.3
Resultado da avaliação das instruções do manual. . . . . . . . . . . . . . . .
p. 46
Lista de Tabelas
2.1
Um comparativo entre os trabalhos relacionados . . . . . . . . . . . . . . . .
p. 33
3.1
As caracterı́sticas do VisualTC . . . . . . . . . . . . . . . . . . . . . . . . .
p. 43
12
1
Introdução
Desde a década de 90 foi vislumbrado o uso da Internet para transportar conteúdos multimı́dia, como voz e vı́deo, porém a rede não fora projetada para isto e os mecanismos que garantem a robustez e o funcionamento em ambientes de larga escala são os mesmos que impõem
dificuldade para o transporte de conteúdos multimı́dia [Clark, Braden e Shenker 1994].
Pacotes de aplicações multimı́dia possuem requisitos de entrega diferentes daqueles pacotes de aplicações convencionais. Para uma aplicação multimı́dia é importante que um pacote
chegue dentro de prazos definidos, se chegar atrasado, a informação contida neste não terá mais
validade.
A rede não diferencia pacotes de aplicações convencionais de aplicações multimı́dia e assim
todos os pacotes são tratados da mesma maneira pelos roteadores. Dentro da IETF (Internet Engineering Task Force) surgiram abordagens [Nichols et al. 1998,Clark, Braden e Shenker 1994]
para permitir à rede entender e diferenciar pacotes com diferentes requisitos de entrega. Ou seja,
pacotes de aplicações multimı́dia terão um tratamento diferenciado e, as vezes priorizado, dos
pacotes de aplicações convencionais, princı́pio este culminando no termo Qualidade de Serviço
(QoS).
1.1
Motivação
No sistema operacional Linux é possı́vel aplicar polı́ticas de QoS através da ferramenta
Traffic Control (TC). Trata-se de uma ferramenta cuja interação com o usuário se dá através da
linha de comando. A ferramenta permite ao usuário indicar diferentes tipos de disciplinas de
enfileiramento, construção de classes para agrupar tráfego, polı́tica de descarte, etc.
Apesar de permitir a construção de regras de QoS simples de maneira rápida, a construção
de regras mais elaboradas culmina em uma tarefa árdua para o usuário, uma vez que a sintaxe
é complexa e a ferramenta não apresenta um meio para enxergar o todo. Pode-se dizer que a
construção de regras com o TC se assemelha a escrita de um algoritmo em uma linguagem de
1.2 Objetivo
13
programação, porém sem as facilidades de estruturas de decisão e repetição.
1.2
Objetivo
Este trabalho tem como objetivo desenvolver uma interface gráfica amigável para melhorar
a percepção do usuário na criação de disciplinas de enfileiramento no Linux. Dessa forma, o
usuário criará suas disciplinas de enfileiramento através de uma interface gráfica e o resultado
será um script em TC. Este script conterá todos os comandos do TC necessários para criar as
disciplinas construı́das pelo usuário através de uma interface gráfica. Uma vez executado este
script, o usuário terá configurado suas disciplinas de controle de tráfego no Linux.
1.3
Organização do texto
O texto está organizado da seguinte forma: No Capı́tulo 2 é apresentada a fundamentação
teórica que dá suporte ao desenvolvimento do trabalho. No Capı́tulo 3 é abordado o software
desenvolvido neste trabalho. O Capı́tulo 4 apresenta os experimentos de uso do VisualTC,
bem como os seus resultados. Por último, no Capı́tulo 5 são apresentadas as conclusões deste
trabalho e os trabalhos futuros.
14
2
Fundamentação teórica
Neste capı́tulo serão apresentados os conceitos que servirão de base para o entendimento
deste trabalho. Desta forma, este capı́tulo esta dividido em quatro sub-seções. Na Sub-Seção
2.1 será abordado uma introdução do funcionamento atual dos roteadores na internet. A SubSeção 2.2 apresenta o funcionamento de Qualidade de Serviço. Já a Sub-Seção 2.3 aborda o
funcionamento de Qualidade de Serviço no Linux e a ferramenta utilizada para tal. Por fim, na
Sub-Seção 2.4 são apresentados os trabalhos relacionados.
2.1
Introdução
A concepção da Internet consiste em um conglomerado de redes de computadores em escala
mundial, a qual interconecta milhões de equipamentos de computação e permite a transferência
de dados entre estes através dos protocolos TCP/IP. No jargão da Internet, estes equipamentos
são denominados hospedeiros ou sistemas finais. Os hospedeiros são conectados entre si por
enlaces de comunicação. Por sua vez, os enlaces de comunicação são constituı́dos por diferentes
meios fı́sicos, tais como: fibra, cabo coaxial, ondas de rádio, entre outros. Enlaces diferentes
possuem diferentes taxas de transmissão [KUROSE J. F.; ROSS 2010].
Tradicionalmente os sistemas finais são conectados por diversos enlaces de comunicação.
Para isto, os hospedeiros são interconectados indiretamente por um equipamento intermediário
de comutação. Um comutador de pacotes encaminha um determinado pacote recebido em um
de seus enlaces de comunicação de entrada para um de seus enlaces de saı́da. Existem diversos
tipos de comutadores, sendo os mais utilizados na Internet atual são os roteadores [KUROSE J.
F.; ROSS 2010].
A sequência de comutadores que um pacote percorre partindo de um hospedeiro remetente
para um hospedeiro final é conhecida como rota. Uma rota provê o caminho, com base na analise do cabeçalho deste pacote, pelo qual este pacote irá percorrer. Com o intuito de permitir
que vários hospedeiros compartilhem ao mesmo tempo os caminhos percorridos ou parte deles,
2.1 Introdução
15
a Internet implementar um modelo de transmissão denominado por comutação de pacotes [KUROSE J. F.; ROSS 2010].
Existem diversos roteadores interligados através de enlaces de comunicação, formando assim uma malha de roteadores. Nesta malha de roteadores, existem roteadores que possuem
um grande número de enlaces de entrada e saı́da, estes são conhecidos como núcleo da rede, e
existem os roteadores que interligam hospedeiros com a Internet, estes são denominados roteadores de borda. Para cada enlace de saı́da desses roteadores, existe uma fila de saı́da (também
conhecida como buffer de saı́da). Esta fila de saı́da tem função de armazenar pacotes que estão
prestes a serem transmitidos [KUROSE J. F.; ROSS 2010].
Figura 2.1: Um modelo de comutação de pacotes [KUROSE J. F.; ROSS 2010].
A Figura 2.1 apresenta um modelo de rede onde existem hospedeiros (computadores) e comutadores de pacote (roteadores). Com esta ilustração, podemos supor que os pacotes estão
saindo dos hospedeiros A e B com destino o hospedeiro E. Deste modo, os pacotes serão entregues para o primeiro roteador através do enlace de 10 Mbps. Este roteador irá encaminhar este
pacote para seu enlace de saı́da. Como o enlace saı́da possui um taxa de transmissão inferior ao
enlace de entrada, os pacotes chegam mais rápido no enlace de entrada do que saem pelo enlace
de saı́da. Isto resultará em um congestionamento [KUROSE J. F.; ROSS 2010].
Os roteadores, por serem equipamentos fı́sicos, possuem alguns fatores limitantes para uma
rede. Um destes fatores esta relacionado com a velocidade de suas interfaces de rede e outro
fator limitante é o tamanho máximo de memória, o qual determina a capacidade de armazenamento de pacotes em sua fila de saı́da. Uma vez atingido o limite máximo de armazenamento,
ocorrerá perda de novos pacotes que chegam ao roteador.
16
2.1 Introdução
Na Internet existem tráfegos de diferentes aplicações que exigem diferentes requisitos da
rede. Estas aplicações são classificadas como convencionais, por exemplo File Transfer Protocol (FTP), e aplicações multimı́dia, como por exemplo voz sobre IP. Entretanto, os roteadores
seguem a abordagem de melhor esforço (Best Effort), ou seja, fazem o melhor esforço para encaminhar os pacotes que chegarem em seu enlace de entrada para um de seus enlaces de saı́da.
Neste modelo, essas aplicações são tratadas igualmente [KUROSE J. F.; ROSS 2010]. Tradicionalmente, são atribuı́dos quatro tipos de requisitos a um fluxo: confiabilidade, atraso, variação
de atraso (jitter) e largura de banda [Forouzan 2006].
Figura 2.2: O funcionamento da Internet.
A Figura 2.2 apresenta o funcionamento do modelo melhor esforço. Neste exemplo, há dois
hospedeiros (H1 e H2) e uma malha de roteadores. Vamos supor que H1 queira transmitir um
pacote para H2, o qual entregará este pacote para o R1. O roteador R1, ao receber este pacote,
fará uma analise do mesmo e decidirá por qual enlace de saı́da irá encaminhá-lo. Assim, este
pacote passará pela analise de vários roteadores até chegar ao seu destino. O caminho percorrido
por este pacote é ilustrado, na Figura 2.2, com o tracejado em azul. Agora, vamos supor que H1
queria transmitir um novo pacote para H2, o qual passará pela mesma analise do pacote anterior
pelos roteadores. Entretanto, o caminho percorrido pelo pacote 2 (tracejado em vermelho) foi
diferente do pacote 1. Deste modo, os pacotes chegaram com diferentes valores de atrasos e com
variações de atraso, resultando no funcionamento inadequado para as aplicações multimı́dia.
O motivo pelo problema citado anteriormente resultar em um mau funcionamento das
aplicações multimı́dia é que estas aplicações são sensı́veis a atrasos e variações de atrasos.
Entretanto, estas aplicações toleram perda de pacotes. Em contrapartida, as aplicações multimı́dia funcionaram perfeitamente no modelo mostrado anteriormente pois estas toleram atrasos e variações de atrasos, sendo sensı́veis a perda de pacotes.
Segundo [Forouzan 2006, KUROSE J. F.; ROSS 2010] os requisitos das aplicações podem
ser definidos da seguinte maneira:
2.2 Qualidade de serviço
17
• Confiabilidade: é a medida adotada para determinar se houve pacotes que não chegaram
ao seu destino ou cujas confirmações foram perdidas. A falta de confiabilidade poderá
implicar em uma retransmissão. Entretanto, a sensibilidade das aplicações à confiabilidade não é a mesma. Por exemplo, é mais importante para uma aplicação de acesso a
Internet ter sua transmissão confiável, não ocorrendo perdas de pacotes e retransmissão,
do que para uma aplicação de voz sobre IP;
• Atraso: é a diferença de tempos registrados na origem da transmissão até chegar ao
destino. As aplicações toleram diferentes graus de atraso. Deste modo, uma aplicação de
voz sobre IP necessita de atrasos mı́nimos, enquanto que na transmissão de uma aplicação
FTP esse requisito é menos importante;
• Variação do atraso (jitter): é a variação dos valores de atrasos registrados entre pacotes
de uma mesma aplicação em uma transmissão. Algumas aplicações, como voz sobre IP
por exemplo, necessitam que variações de atraso sejam limitadas;
• Largura de banda: é a vazão de dados máxima para uma aplicação. Aplicações diferentes requerem diferentes valores de largura de banda.
Os requisitos de uma aplicação multimı́dia, por exemplo voz sobre IP, é ter garantias de
uma largura de banda mı́nima de 74kbps, um atraso fim a fim de até 150ms e variação de atraso
(jitter) de até 30ms.
2.2
Qualidade de serviço
Na Seção 2.1 vimos os problemas que a rede atual possui para a transmissão de pacotes
de diferentes aplicações. Estas aplicações possuem diferentes requisitos para o seu funcionamento esperado. Dentro deste contexto, surgiram abordagens para permitir que a rede diferencie tráfegos destas aplicações de tal maneira que atenda ao seus requisitos. Este principio foi
denominado como Qualidade de Serviço.
Entretanto, a Internet não diferencia o fluxo de diferentes aplicações. Isto ocorre pelo fato
de os roteadores utilizarem, por padrão, a disciplina de enfileiramento First-In First-Out (FIFO).
Esta disciplina seleciona pacotes na mesma ordem em que eles chegam à fila de saı́da do roteador [KUROSE J. F.; ROSS 2010]. Pode ser utilizado como um exemplo do funcionamento
da disciplina FIFO, uma fila de banco. Tradicionalmente, a primeira pessoa a entrar na fila é a
primeira pessoa a sair desta [Forouzan 2006].
2.2 Qualidade de serviço
18
Figura 2.3: A fila FIFO em operação [KUROSE J. F.; ROSS 2010].
A Figura 2.3 exemplifica o modelo de funcionamento desta disciplina que encaminha os
pacotes, para o enlace de saı́da, na mesma ordem em que os recebe em sua fila de saı́da. Para
este caso, existe apenas uma fila.
Para prover do princı́pio de diferenciação do tráfego das aplicações, surge a necessidade
de isolamento dos fluxos de tráfego das aplicações que estão na fila de saı́da do roteador. Um
modo de realizar este isolamento de fluxos, é prover da criação de enlaces lógicos, sendo que
para cada enlace será determinado uma porção fixa de largura de banda do enlace fı́sico. Com
esta porção fixa de largura de banda, um fluxo pode usar apenas a quantidade a que lhe foi
alocado [KUROSE J. F.; ROSS 2010].
Figura 2.4: Um modelo de isolamento dos fluxos das aplicações [KUROSE J. F.; ROSS 2010].
A Figura 2.4 apresenta o modelo de isolamento de fluxos de duas aplicações, uma aplicação
de voz sobre IP e uma aplicação FTP. Foram criados dois enlaces lógicos: um enlace de 1 Mbps
2.3 Qualidade de serviço no Linux
19
para o fluxo da aplicação de voz sobre IP e um enlace de 0,5 Mbps para a aplicação FTP. Neste
caso, as aplicações perceberiam um enlace com a capacidade de largura de banda 1 Mbps e 0,5
Mbps, respectivamente [KUROSE J. F.; ROSS 2010].
Com o modelo de isolamento de fluxos, um fluxo pode usar apenas a quantidade de largura
de banda a que lhe foi alocada. Deste modo, ele não pode utilizar a largura de banda total
quando a outra aplicação estiver ociosa. Por exemplo, se o fluxo da aplicação de voz sobre IP
não estiver transmitindo pacotes, o fluxo da aplicação FTP não conseguiria ultrapassar a largura
de banda de 0,5 Mbps. Por conseguinte, pode ser desejável que um fluxo possa utilizar a largura
de banda do outro fluxo quando este estiver ocioso [KUROSE J. F.; ROSS 2010].
O modelo citado anteriormente também não fornece garantias dos requisitos para o fluxo de
uma determinada aplicação (conforme visto na Seção 2.1). Por exemplo, não há garantia de que
não haverá variações de atraso dos pacotes da aplicação de voz sobre IP. Consequentemente, é
desejável que a rede possa fornecer garantias destes requisitos [KUROSE J. F.; ROSS 2010].
2.3
Qualidade de serviço no Linux
O Linux disponibiliza, através da ferramenta de controle de tráfego denominada por TC
(Traffic Control), um vasto conjunto de recursos ligados à provisão de QoS [Santos 2010].
Segundo [Almesberger et al. 1999, Hubert et al. 2003], a ferramenta TC possui quatro
principais componentes:
• Qdisc: as disciplinas de enfileiramento atuam nas filas dos roteadores, são elas que indicam como os pacotes que estão na fila serão tratados, determinando a ordem e o ritmo
que os pacotes são entregues para a interface de saı́da. As disciplinas de enfileiramento
foram divididas em dois grupos distintos, o grupo com classificação (classful) e o grupo
sem classificação (classless). Os escalonadores que possuem classificação são capazes
de receber internamente outros elementos, como classes, filtros e até outras qdiscs. Já os
escalonadores que não possuem classificação somente armazenam pacotes e não contemplam a adição de outros elementos.
• Class: as classes são os componentes responsáveis pelo tratamento diferenciado a um
determinado fluxo de dados. Por sua vez, as classes estão presentes apenas para os escalonadores que possuem classificação. Deste modo, é possı́vel ramificar a qdisc em outras
classes, as quais são denominadas de “classes filhas”. Por exemplo, se a polı́tica de QoS
deseja diferenciar o tratamento das aplicações Voice over Internet Protocol (VoIP) e FTP,
2.3 Qualidade de serviço no Linux
20
seria necessário a criação de uma disciplina de fila do tipo classful e outras duas classes
“filhas” (uma classe para o tratamento de cada aplicação);
• Filter: os filtros são os responsáveis por identificar e direcionar seletivamente os fluxos
de dados das aplicações para as classes ou qdiscs criadas;
• Policing: é utilizado como parte do filtro a fim de retardar ou descartar pacotes na entrada evitando que o tráfego ultrapasse uma largura de banda configurado. No Linux, o
policiamento só pode descartar um pacote e não retardá-lo.
Figura 2.5: Um exemplo de disciplina de filas [Brown 2006].
A Figura 2.5 ilustra o relacionamento entre os componentes do TC para a concepção de
uma polı́tica de QoS. Cada interface de rede que transmite os pacotes para o enlace de saı́da
têm uma qdisc (disciplina de fila) principal associada, a qual todos os pacotes recebidos na
entrada aguardam sua vez de serem enviados para interface de saı́da. Os pacotes que chegarem
na interface de entrada do roteador são encaminhados para os filtros (filter). Este, por sua
vez, irá distinguir os pacotes e encaminhá-los para suas devidas classes (class). Por fim, as
classes irão determinar a ordem e o ritmo que os pacotes serão encaminhados para interface de
saı́da, dependendo da qdisc a que pertencem. Deste modo, os pacotes serão desenfileirados e
transmitidos pela interface de saı́da.
2.3.1
Disciplinas de enfileiramento
As disciplinas de enfileiramento ou escalonadores são os principais componentes do controle de tráfego no Linux, o qual são conhecidos por qdisc (queueing discipline). Estes possuem
algoritmos de escalonamento, o qual seleciona pacotes que estão na fila do roteador e indicam
a ordem e o instante que os pacotes são transmitidos para a interface de saı́da [KUROSE J.
F.; ROSS 2010].
Segundo [Hubert et al. 2003] existem os seguintes tipos de disciplinas de enfileiramento
com classificação: Class Based Queueing (CBQ), Hierarchical Token Bucket (HTB), Prio-
2.3 Qualidade de serviço no Linux
21
rity Queue (PRIO), Generic Random Early Detection (GRED), Differentiated Service Marker (DSMARK). E os seguintes escalonadores que não possuem classificação: First-In FirstOut (FIFO), Packet First-In First-Out (PFIFO), Stochastic Fair Queuing (SFQ), Token Bucket
Flow (TBF), Random Early Detection (RED). Entretanto, nesta monografia, não serão abordados todas esses tipos de disciplinas. Para o enfileiramento sem classes, discutiremos aqui os
tipos: FIFO, SFQ e TBF. Já para o grupo com classificação, serão abordados as disciplinas:
PRIO e HTB.
Como visto na Seção 2.2, a disciplina de enfileiramento FIFO encaminha os pacotes para
a interface de saı́da na mesma ordem que chegam na fila do roteador. Com uma abordagem
diferente da disciplina de enfileiramento FIFO, o escalonador PRIO provê da priorização do
tráfego das aplicações ao enlace de saı́da. Neste mecanismo, os pacotes recebem um nı́vel de
prioridade e cada nı́vel de prioridade tem sua própria fila. Assim, os pacotes na fila de maior
prioridade são processados primeiro. Já os pacotes na fila de menor prioridade são processados
por último. Um detalhe a ser observado é que o sistema não para de atender a uma fila prioritária até que ela esteja totalmente vazia [Forouzan 2006]. Consequentemente, poderá ocorrer
transbordo nas filas de menor prioridade e uma polı́tica de descarte começará a descartar pacotes. Entretanto, isto não geraria nenhum reflexo a fila de maior prioridade. O modelo do
enfileiramento prioritário é apresentado na Figura 2.6.
Figura 2.6: Modelo de enfileiramento prioritário [KUROSE J. F.; ROSS 2010].
Na Figura 2.7 estão apresentados duas filas, sendo a fila com cor escura a de maior prioridade (primeiro nı́vel). No inı́cio, chega apenas o pacote 1 e é processado. Durante o tempo de
processamento e envio chegam dois novos pacotes. O pacote de número 2, que é da classe com
menor nı́vel, e o pacote 3, que é da classe que possui o maior nı́vel. Assim, o pacote 3 é enviado
primeiro. O segundo pacote somente será enviado quando não houver mais pacotes da fila de
maior prioridade para ser enviado.
2.3 Qualidade de serviço no Linux
22
Figura 2.7: Operação realizada no enfileiramento prioritário [KUROSE J. F.; ROSS 2010].
A principal vantagem do enfileiramento prioritário é apresentar uma forma simples de implementar uma diferenciação do fluxo das aplicações. Deste modo, é possı́vel permitir que uma
aplicação tenha maior prioridade sobre as demais. Entretanto, caso o tráfego da rede não seja
bem analisado, pode resultar em um mau funcionamento para os serviços que estiverem alocados na fila de menor prioridade, pois estas filas precisam aguardar que o fluxo das filas de maior
prioridade fiquem ocioso para poderem transmitir.
Na disciplina de enfileiramento justo estocástico (SFQ) todo o tráfego é dividido em filas
do tipo FIFO através do uso de um algoritmo hashing. Cada fila possui sua vez de transmitir um
pacote até o escalonador finalizar seu ciclo, dando acesso justo aos recursos. Deste modo, cada
fluxo possui sua vez de transmitir [KUROSE J. F.; ROSS 2010]. Entretanto, vários fluxos podem
ser enviados para a mesma fila, resultando em uma diminuição da transmissão dos pacotes das
aplicações. Para contornar esta situação, o SFQ permite reconfigurar, de tempos em tempos, o
algoritmo hashing.
Figura 2.8: Modelo de escalonador SFQ [KUROSE J. F.; ROSS 2010].
O modo de funcionamento do escalonador SFQ é apresentado na Figura 2.8. Neste exem-
2.3 Qualidade de serviço no Linux
23
plo, todo o fluxo de dados foi dividido em três filas FIFO. Estas filas, aguardam sua vez de
transmitir seu pacote para o enlace de saı́da, a qual é determinada pelo classificador.
A Figura 2.9 apresenta o funcionamento do escalonador SFQ. Inicialmente, chegam os
pacotes 1 e 2 que pertencem à mesma classe. Deste modo, o primeiro pacote é enviado para a
interface de saı́da. Quando este pacote é enviado, a outra classe recebe o direito de transmitir e
é enviado o pacote 3. Após a transmissão do pacote 3 é concebido o direto da próxima classe
transmitir seu pacote, como existem apenas duas classes neste exemplo, é enviado o pacote 2
que pertence a primeira classe. O escalonador agirá deste modo, transmitindo um pacote de
cada classe por vez, até enviar todos os pacotes que estão em sua fila. [KUROSE J. F.; ROSS
2010].
Figura 2.9: A operação do escalonador SFQ [KUROSE J. F.; ROSS 2010].
Segundo [Hubert et al. 2003], é possı́vel configurar os seguintes parâmetros, para o escalonador SFQ, utilizando a ferramenta TC:
• Quantum: define a quantidade de pacotes transmitidos da fila SFQ. O valor default é 1,
o que significa que é enviado um pacote de cada fila por cada vez que ela for servida;
• Perturb: determina de quanto em quanto tempo o algoritmo hashing é reconfigurado.
Caso não seja definido, a função hashing não será reconfigurada.
Apesar de apresentar uma fácil configuração e ainda garantir acesso justo aos recursos da
rede, o escalonador SFQ não garante requisitos do fluxo de cada aplicação. Deste modo, é
normalmente utilizado em situações que não requerem diferenciação dos fluxos da rede.
O algoritmo de enfileiramento TBF ou “balde de fichas”, permite que um determinado
fluxo, quando ocioso por um certo perı́odo de tempo, possa adquirir fichas. Assim, este fluxo
poderá utilizar uma largura de banda maior a que lhe foi atribuı́do até esgotar as fichas adquiras,
principio este denominado por rajadas. Para tal, o balde possui um tamanho B que é preenchido
2.3 Qualidade de serviço no Linux
24
por fichas a uma taxa constante R. Como pode haver no máximo B fichas no balde, o tamanho
máximo da rajada para um fluxo regulado pelo “balde de fichas” é de B pacotes. Além disso,
como a taxa de geração de fichas é R, o número máximo de pacotes que pode entrar na rede
para qualquer intervalo de tempo t é Rt + B. Assim, a taxa de geração de fichas, R, serve para
limitar a taxa média de longo perı́odo com qual pacotes podem entrar na rede. Deste modo, é
possı́vel limitar a taxa de pico, a taxa média por um perı́odo de tempo e também o tamanho da
rajada para o fluxo de cada aplicação [KUROSE J. F.; ROSS 2010].
Figura 2.10: O algoritmo de enfileiramento “balde de fichas” [KUROSE J. F.; ROSS 2010].
Segundo [Hubert et al. 2003], a disciplina de enfileiramento TBF possui os seguintes
parâmetros:
• Rate: define a taxa de transmissão da fila;
• Burst: determina o tamanho, em bytes, do “balde de fichas”;
• Latency: é o tempo máximo que um pacote pode aguardar na fila. Uma vez ultrapassado
este tempo, o pacote será descartado;
• Peakrate: define a taxa de pico para as rajadas;
• Mtu: especı́fica a taxa máxima para o “balde de fichas”.
A disciplina de escalonamento TBF é utilizada para limitar a taxa de transmissão do fluxo
das aplicações, permitindo que este fluxo, quando ocioso, possa adquirir fichas. Deste modo, é
possı́vel que este fluxo possa exceder o limite de transmissão por um certo perı́odo de tempo.
2.3 Qualidade de serviço no Linux
25
O algoritmo de escalonamento HTB é constituı́do por diversos “baldes de fichas” organizados em uma hierarquia. Este escalonador permite a criação de classes que funcionam como
enlaces lógicos, onde é possı́vel fracionar a banda total do enlace fı́sico disponı́vel. Ainda é
possı́vel fracionar a banda de cada classe, ofertando para outras classes. Deste modo, é criado
uma hierarquia.
Cada classe possui dois principais parâmetros: rate, o qual define a taxa garantida para
esta classe; ceil, o qual define a taxa máxima que esta classe poderá utilizar quando a classe
pai estiver com largura de banda de sobra. Como o escalonador HTB faz uso de um conceito
denominado por borrowing (empréstimo), quando uma classe não estiver utilizando a sua taxa
de transmissão (rate) garantida pela classe pai, poderá emprestar para outras classes. Entretanto,
caso não haja interesse em que as classes efetuem empréstimos, basta definir o parâmetro rate
com o mesmo valor do parâmetro ceil.
Figura 2.11: Um exemplo da utilização do escalonador HTB.
Um exemplo de uma hierarquia que é possı́vel de construir provendo do algoritmo de escalonamento HTB é ilustrado através da Figura 2.11. Neste exemplo, no enlace de saı́da do
roteador é criado uma qdisc principal com uma largura de banda de 100 Kbps. Para dividir
o fluxo das aplicações Hypertext Transfer Protocol (HTTP) e Secure Shell (SSH) das demais
aplicações, foram criadas três classes. Sendo alocada uma largura de banda de 40 Kbps para
as classes HTTP e SSH e 20 Kbps para as demais aplicações. Com esta polı́tica, as duas
aplicações receberam um tratamento diferenciado e ficaram com seus fluxos separados das demais aplicações.
Segungo [Brown 2006], é possı́vel definir outros parâmetros para as classes do algoritmo
HTB, como:
• Burst: determina a quantidade máxima, em bytes, de dados que podem ser transmitidos
na taxa máxima (ceil);
2.3 Qualidade de serviço no Linux
26
• Cburst: determina a quantidade máxima, em bytes, de dados que podem ser envidas na
taxa máxima da interface;
• Prio: define a prioridade das classes, sendo zero (0) a classe de maior prioridade.
Devido ao seu número de funcionalidades, a disciplina de enfileiramento HTB pode ser
utilizada para diversas finalidades. Um exemplo da utilização desta disciplina é visto na Figura
2.11, a qual sua finalidade foi dividir e limitar a largura de banda da rede, a fim de garantir uma
melhor utilização de seus recursos.
2.3.2
Utilização do TC
Com a utilização da ferramenta TC é possı́vel criar polı́ticas de QoS que definem por quais
etapas o tráfego será encaminhado, dependendo de qual disciplina de enfileiramento utilizada,
antes de ser entregue a interface de saı́da. Para prover tal configuração é necessário efetuar uma
sequência de comandos com o TC, na qual cada comando será responsável por um determinado
elemento de controle de tráfego.
1
#!/bin/bash
2
3
4
# adiciona a disciplina de fila raiz na interface eth0
tc qdisc add dev eth0 root handle 1:0 htb default 13
5
6
7
# cria a classe filha, para impor o limite de banda global desta HTB
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbit ceil 100kbit
8
9
10
11
12
# cria as classes para as aplicacoes
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 40kbit ceil 100kbit
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 40kbit ceil 100kbit
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil 100kbit
13
14
15
16
# cria os
tc filter
xffff
tc filter
xffff
filtros para classificar os pacotes em suas determinas classes
add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0
flowid 1:11
add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0
flowid 1:12
Figura 2.12: Um exemplo da utilização do TC.
A Figura 2.12 ilustra o shell script com os comandos necessários para implementar a
polı́tica de QoS exemplificada na Figura 2.11 que usa da disciplina de filas HTB. O comando realizado na quarta linha do shell script apresenta como adicionar um disciplina de fila raiz do tipo
HTB na interface de rede eth0 . Na sétima linha, o comando realizado limita a largura de banda
máxima que estará disponı́vel para a interface eth0. Da décima linha até a décima segunda,
2.4 Trabalhos relacionados
27
ilustra como criar as classes para cada aplicação que desejá-se ter um tratamento diferenciado.
Para tal, cada classe tem um limite de transmissão (rate) e um limite de transmissão máxima
(ceil) quando a rede estiver ociosa. Por último, as duas últimas linhas realizam o serviço dos
filtros, que provêm da porta utilizada nas aplicações HTTP (porta 80) e SSH (porta 22), para
então encaminhar o fluxo destas aplicações para suas respectivas classes.
2.4
Trabalhos relacionados
Nesta seção são apresentados os trabalhos que buscam facilitar a percepção do usuário para
a construção de polı́ticas de QoS através da ferramenta TC do Linux.
Em [Carvalho e Abelém 2008] é apresentado o software phpTCadmin: uma solução para
implementação de qualidade de serviço em redes de computadores baseada em software livre,
cujo foco é criar um ambiente que permite a criação de polı́ticas de QoS remotamente através
de uma interface web.
O phpTCadmin é constituı́do por dois componentes principais: um que interage com a
TCAPI [Olshefski 2001] para configurar as polı́ticas de QoS através da ferramenta TC e um
outro que exibe, de forma intuitiva, as disciplinas de enfileiramento, suas classes e filtros. A
ferramenta apresenta quatro modos de visualização:
• Normal: a exibição ocorre de forma semelhante ao comando “show” do comando TC;
• Tree: ilustra como as regras de controle de tráfego estão acopladas;
• Natural: sua visualização é semelhante a opção “tree”, porém os filtros são exibidos em
uma tabela separada;
• Debug: exibe varias informações adicionadas, como a visualização da taxa de utilização
de cada classes.
A Figura 2.13 apresenta o modo de visualização tree. Como visto, este modo apresenta
como as regras da polı́ticas de QoS estão criadas. Deste modo, é possı́vel visualizar desde a
disciplina de fila principal da interface, suas classes, assim como a disciplina de enfileiramento
de cada classe e seus filtros.
Este software ainda permite a configuração de disciplinas de filas, classes e filtros em tempo
de execução. Assim, não possui à necessidade de reaplicação das regras já configuradas no
2.4 Trabalhos relacionados
28
Figura 2.13: Modo de visualização tree do phpTCadmin [Carvalho e Abelém 2008].
Linux. O phpTCadmin manipula as disciplinas de filas do tipo CBQ, HTB, Hierarchical Fair
Service Curve (HFSC), PRIO, SFQ, TBF e RED.
A ferramenta apresentada por [Carvalho e Abelém 2008] possui como limitação a necessidade de que o usuário possua um alto conhecimento da ferramenta TC, pois é necessário indicar
todos os parâmetros utilizados pela ferramenta para a geração de uma configuração de QoS, não
fornecendo ajuda e dicas para o usuário.
O software SGSCtrl [Costa 2011] facilita a criação e aplicação de polı́ticas de QoS, através
de uma interface web. Esta interface possui como funções a geração de scripts contendo comandos do TC, medição da taxa de transmissão da rede, agendamento de tarefas e ainda permite
a visualização de relatórios com estatı́sticas geradas pelo TC. Este software possui dois modos
de visualização:
• Modo básico: voltado para usuários com pouca experiência de uso do TC, na qual a
ferramenta irá definir e configurar os parâmetros de QoS de acordo com a aplicação que
o usuário escolher;
• Modo avançado: voltado para usuários que possuem conhecimento e experiência na
ferramenta TC, onde é possı́vel configurar as disciplinas de enfileiramento, filtros e definir
em quais hosts será configurada a polı́tica de QoS criada.
A Figura 2.14 ilustra o modo de visualização básico do software SGSCtrl. Podemos observer, que este módulo permite o usuário criar regras de QoS através de configurações pré-criadas,
que são: Dados, Vı́deo/Áudio, Gerência, Controle de Rede, MSN e P2P. Após escolhido a sua
pré-configuração, basta que o usuário defina as taxas de transmissão mı́nima e máxima.
A funcionalidade de medição da taxa de transmissão utilizada pela rede através do SGSCtrl,
permite ao usuário coletar relatórios contendo informações da rede sobre quantidade de dados
2.4 Trabalhos relacionados
29
Figura 2.14: Modo de visualização básico do SGSCtrl [Costa 2011].
transmitida e a velocidade que foi obtida. Esta função é realizada com o uso da ferramenta
iperf 1 . Está ferramenta utiliza o método cliente e servidor. Deste modo, para medir o fluxo da
rede, o SGSCtrl permite o usuário configurar um host como cliente e um outro como servidor.
Assim, o host cliente começará a enviar pacotes para o servidor. Ao final deste fluxo de pacotes,
o software coletará as informações de quantidade de dados transmitida e a velocidade obtida e
as disponibilizará para o usuário através de um relatório.
O SGSCtrl possibilita que o usuário possa fazer agendamento de tipos de tarefas: agendamento de medição da taxa de transmissão e agendamento da aplicação das regras de QoS
criadas. Para tal, o usuário terá que configurar qual a tarefa que deseja agendar, passando algumas informações para o software, tais como: data de inı́cio, hora de inı́cio, data de finalização,
hora de finalização, etc. Um exemplo da utilização desta funcionalidade pode ser visto através
da Figura 2.15
Outra funcionalidade do SGSCtrl é visualização de estatı́sticas, através de relatórios, dos
componentes de QoS configurados. Neste relatório, o usuário poderá visualizar as informações
de vazão, pacotes perdidos e atrasados, quantidade de bytes enviados e pacotes que transborda1 http://iperf.fr/
2.4 Trabalhos relacionados
30
Figura 2.15: Agendamento de tarefas do SGSCtrl [Costa 2011].
ram o limite estipulado pela regra de QoS. Estes dados são obtidos através do uso da ferramenta
TC.
Apesar de todas essas funcionalidades, o modelo proposto por [Costa 2011] apresenta algumas limitações. Primeiramente, a ferramenta limita o usuário a criar até sete disciplinas de
enfileiramento e para cada disciplina até sete filtros. Outra limitação está relacionado a permitir
que o usuário possa configurar apenas a taxa de transmissão mı́nima, máxima e prioridade de
cada regra de QoS. Deste modo, o software proposto está limitando o uso da ferramenta TC.
Por fim, a instalação desta ferramenta é algo muito complexo, na qual é necessário instalação e
criação de um banco de dados e instalar os scripts e módulos.
Em [Golubev e Bulej 2004] é apresentado a ferramenta CBQ.init, cujo objetivo é gerar regras para a ferramenta TC através da criação de scripts de configuração, na qual cada script
fará o papel de uma classe, contendo suas devidas configurações. Entretanto, existem duas
deficiência desta ferramenta. Uma deficiência está relacionado a esta ferramenta limitar-se a
manipular apenas a disciplina de fila do tipo CBQ. Outra deficiência é por não possuir um interface gráfica que facilite a percepção do usuário na utilização da ferramenta. Ainda assim, será
necessário um conhecimento de como gerar cada script de configuração além do conhecimento
exigido do TC para compreensão dos parâmetros que esta ferramenta fornece.
2.4 Trabalhos relacionados
31
No trabalho [Bulej 2004] é proposto uma ferramenta denominada por HTB.init que segue
a mesma abordagem da ferramenta CBQ.init, na qual sua configuração baseá-se na geração
de arquivos de configuração para cada classe. Entretanto, este trabalho visa a manipulação
de disciplinas de filas do tipo HTB. Ainda assim, existe a mesma necessidade, do trabalho
CBQ.init, de um ambiente amigável para o usuário.
O Traffic Control Next Generation (TCNG) [Almesberger 2002] surgiu como uma ferramenta de auxı́lio para a construção de polı́ticas de QoS com o TC. A principal contribuição do
TCNG foi a construção de uma gramática, semelhante a uma linguagem de programação estruturada, para agilizar a construção de regras de QoS. O TCNG provê uma camada de abstração
entre usuário e TC e permite escrever regras de QoS, que uma vez interpretadas geram linhas de
comando especı́ficas para o TC. Outra caracterı́stica do TCNG é permitir que o usuário, através
da ferramenta TCSIM, simular seu script de configuração. Deste modo, o usuário poderá validar as configurações geradas pelo TCNG, testar o desenvolvimento de configurações e ainda
testar os componentes de controle de tráfego.
1
#define IFACE eth0
2
3
4
5
6
7
8
dev IFACE {
egress {
/* Cria
class (
class (
class (
os filtros para classificar os pacotes em suas classes */
<$http> ) if tcp_sport == PORT_HTTP;
<$ssh> ) if tcp_sport == PORT_SSH;
<$outros> ) if 1;
9
/* Configura a disciplina de fila raiz */
htb () {
/* Configura o limite de banda global */
class ( rate 100kbps, ceil 100kbps ) {
/* Cria as classes para as aplicacoes */
$http = class (rate 40kbps, ceil 100kbps ) { htb; };
$ssh = class (rate 40kbps, ceil 100kbps ) { htb; };
$outros = class (rate 20kbps, ceil 100kbps ) { htb; };
}
}
10
11
12
13
14
15
16
17
18
19
20
}
21
22
}
Figura 2.16: Um exemplo da utilização do TCNG
A Figura 2.16 ilustra a sintaxe do TCNG. Neste exemplo, são apresentados os comandos
necessários para prover a mesma polı́tica de QoS configurada pela Figura 2.12. Na primeira
linha define-se a interface de rede, no caso do exemplo é a interface eth0. Da sexta linha à
oitava são configurados os filtros, para as portas do HTTP e de SSH, ambas sobre Transmission
2.4 Trabalhos relacionados
32
Control Protocol (TCP) e caso a porta não seja nenhuma destas o pacote será encaminhado
para a classe “outros” (conforme oitava linha). A décima terceira linha define o limite de banda
máximo para a interface eth0. A partir da décima quinta até a décima sétima, são definidas as
taxas máximas para cada aplicação.
Analisando a diferença entre a Figura 2.12 e a Figura 2.16 é possı́vel notar que provendo do
TCNG para criar as polı́ticas de QoS é menos complicado e mais flexı́vel do que a ferramenta
TC. Entretanto, o usuário ainda está limitado a uma interface em modo texto, na qual precisa
de um conhecimento e estudo sobre a linguagem para conseguir criar regras de QoS. Outra
dificuldade desta ferramenta é a necessidade de o usuário ter uma experiência com o uso do
TC, pois esta ferramenta espera que o usuário tenha conhecimento dos parâmetros que cada
escalonador necessita para sua configuração.
A Tabela 2.1 apresenta um comparativo entre as caracterı́sticas dos trabalhos relacionados.
Nesta tabela, foram abordados as seguintes caracterı́sticas:
• Interface com o usuário: esta caracterı́stica aponta qual o tipo de interface com o usuário
o software utiliza;
• Interação com o TC: indica se software permite o usuário configurar sua polı́tica de QoS
diretamente ou através de geração de scripts contendo os comandos do TC, sendo “Sim”
a caracterı́stica que o software permite interação direta com o TC;
• Simulação: indica se o software possibilita a simulação da polı́tica de QoS criada. Com
esta caracterı́stica, é possı́vel o usuário visualizar suas regras de QoS antes de configurála;
• Importa scripts: esta caracterı́stica aponta se o software possui a possibilidade de importar scripts contendo os comandos do TC e configurá-los de acordo com o padrão adotado
pelo o mesmo;
• Gera filtros: informa se a ferramenta possibilita a geração de filtros;
• Suporte a filtros: esta caracterı́stica informa qual o seletor de filtros é utilizado pelo
software;
• Conhecimento de sintaxe: indica qual o nı́vel de conhecimento do TC que o usuário
necessita, sendo alta uma caracterı́stica na qual o usuário necessita de um alto conhecimento da sintaxe do TC. Por sua vez, baixa indica que o usuário não necessita de um
amplo conhecimento do TC;
33
2.4 Trabalhos relacionados
• Facilidade de instalação: aponta a facilidade de instalação do software, sendo alta uma
nota na qual possui uma alta facilidade de instalação;
• Sistema operacional: informa em qual sistema operacional que o software pode ser
executado.
Trabalhos relacionados
Caracterı́sticas
phpTCadmin SGSCtrl
CBQ.init
HTB.init
TCNG
Interface com usuário
Web
Web
Texto
Texto
Texto
Interação com TC
Sim
Sim
Não
Não
Não
Simulação
Não
Não
Não
Não
Sim
Importa scripts
Não
Não
Não
Não
Não
Gera filtros
Sim
Sim
Sim
Sim
Sim
Suporte a filtros
u32 e fw
u32
u32
u32
u32
Facilidade de uso
Intermediário
Alta
Baixa
Baixa
Baixa
Conhecimento de sintaxe
Alta
Baixa
Alta
Alta
Alta
Facilidade de instalação
Baixa
Baixa Intermediário Intermediário Alta
Sistema operacional
Linux
Linux
Linux
Linux
Linux
Tabela 2.1: Um comparativo entre os trabalhos relacionados
Através da Tabela 2.1, é possı́vel notar as caracterı́sticas que cada ferramenta citada possui.
Com esta tabela, é possı́vel observar que a maioria dos softwares ainda necessitam de um alto
conhecimento de sintaxe do TC e que não possibilitam uma grande facilidade de uso da ferramenta TC para o usuário. Uma caracterı́stica comum entre os trabalhos está relacionado ao
sistema operacional adotado como requisito, no qual todos os trabalhos possuem como requisito ser executado no Linux. Por consequência desta caracterı́stica, a facilidade de instalação
dos softwares variam, alguns possuem uma baixa facilidade de instalação e outros a instalação
é realizada de maneira simples (alta facilidade de instalação).
Outras caracterı́sticas comuns entre as ferramentas proposta nos trabalhos citados são: a
falta de existência da função de importar scritps contendo comandos do TC; a possibilidade de
geração de filtros; suporte a filtros do seletor u32. Por fim, alguns softwares ainda limitam o
usuário a utilizar interface em modo texto. Já outros, permitem ao usuário utilizar uma interface
Web. Entretanto, mesmo os softwares que utilizam uma interface Web, não permitem ao usuário
configurar sua polı́tica de QoS, em outros roteadores, remotamente.
34
3
VisualTC
Este capı́tulo apresenta o VisualTC, o software proposto neste trabalho. Na Seção 3.1 é
apresentado uma introdução sobre o VisualTC, seus requisitos e a motivação para a desenvolvimento deste software. A Seção 3.2 aborda a arquitetura de software utilizada para a construção
do VisualTC. Já a Seção 3.3 apresenta as caracterı́sticas e o funcionamento do VisualTC. Por
fim, na Seção 3.4 é feita uma conclusão sobre a utilização da ferramenta.
3.1
Introdução
A criação de regras de QoS no Linux, conforme visto na Seção 2.3, baseia-se em linhas de
comandos onde cada linha possui uma determinada função. Apesar de permitir a construção de
regras de QoS simples de maneira rápida, a construção de regras mais elaboradas culmina em
uma tarefa árdua para o usuário, uma vez que a sintaxe é complexa e a ferramenta não apresenta
um meio para enxergar o todo.
Os softwares apresentados na Seção 2.4 oferecem algumas facilidades de utilização da ferramenta TC para o usuário. Em contrapartida, estes mesmos softwares possuem caracterı́sticas
que implicam em determinadas dificuldades, tais como: interface com o usuário, facilidade de
uso, conhecimento da sintaxe do TC e facilidade de instalação.
O VisualTC consiste em um software que tem como principal objetivo facilitar a utilização
da ferramenta TC para o usuário. Deste modo, suas caracterı́sticas visam facilitar o usuário
desde a instalação, execução e criação de polı́ticas de QoS. Com isto, o usuário que for utilizar
este software terá uma representação gráfica que possibilita uma melhor visualização de suas
regras de QoS.
Um outro diferencial do VisualTC está relacionado ao sistema operacional onde poderá ser
executado. Como o VisualTC foi desenvolvido através da linguagem de programação Java, este
possui como único requisito de execução de software ter a máquina virtual Java instalada. Sendo
assim, o software poderá ser executado em qualquer sistema operacional (Linux, Windows,
3.2 Arquitetura
35
entre outros). Entretanto, como os scripts gerados pelo VisualTC estão atrelados a ferramenta
TC, para executá-los é necessário estar em um sistema operacional Linux e ter a ferramenta TC
instalada.
3.2
Arquitetura
A arquitetura de software refere-se a análise da estrutura ou organização dos módulos do
software, a maneira como eles interagem e a estrutura de dados que cada um destes componentes utilizam. Com isto, a arquitetura é uma representação que nos permite analisar a eficiência
do software nos requisitos declarados, facilitar as mudanças e futuras implementações na arquitetura do projeto e reduzir os riscos associados à construção do software [Pressman 2011].
A Figura 3.1 contém o digrama de casos de uso do VisualTC, ou seja, contém as principais
ações que um usuário poderá executar através da interface gráfica do software. As ações são:
• Modelar: o usuário abre o VisualTC e seleciona o ambiente de trabalho “Hierarquia”.
Neste ambiente, é possı́vel que o usuário desenhe uma hierarquia de QoS. Para isto, ele
terá que adicionar os elementos da ferramenta TC contidos na paleta lateral do software.
Para adicionar um elemento no ambiente de trabalho, usuário deverá selecionar o elemento desejado e arrastá-lo para o local desejado. Após adicionado os elementos, ele
deverá conectá-los afim de criar a hierarquia desejada. Esta ação é feita selecionando o
objeto de origem e, com o botão Ctrl do teclado pressionado, arrastar até o objeto de destino. Ao final, basta que o usuário configure os parâmetros de cada elemento criado. Para
executar essa função, o usuário terá que abrir o menu de opções do elemento desejado
e selecionar a opção “Propriedades”. Preenchido todos os parâmetros, o usuário deverá
aplicar as configurações através do botão “Salvar”.
• Criar filtros: o usuário seleciona o ambiente de trabalho “Filtros”. Neste ambiente, é
possı́vel que usuário adicione os filtros que encaminharam os pacotes para suas devidas
disciplinas de filas ou classes. Para isto, o usuário terá que preencher os parâmetros que
deseja que seu filtro analise. Após preenchido, é necessário clicar no botão “Adicionar”.
Deste modo, o filtro será adicionado para uma tabela de filtros. Nesta tabela, o usuário
pode trocar a ordem dos filtros, voltar a editar um determinado filtro e ainda removê-los.
Para isto, basta que o usuário selecione o filtro que deseja efetuar uma ação e clicar no
botão correspondente a ação desejada.
A arquitetura concebida no desenvolvimento do VisualTC foi dividida em dois módulos:
36
3.2 Arquitetura
Figura 3.1: Diagrama de casos de uso do VisualTC.
frame e elements. O módulo elements tem a função de implementar as classes para os elementos
de QoS da ferramenta TC. Para tal, os elementos do TC foram divididos em duas classes:
Qdisc e Classe. A classe Qdisc foi segmentada em outras duas classes: ClassFul e ClassLess.
Esta segmentação se da pelo fato da ferramenta TC possuir diferentes configurações para os
escalonadores com classificação e por permitir o uso de filtros (ClassFul) e para os que não
possuem classificação (ClasseLess). Estas classes, para o VisualTC, são objetos e por isto elas
herdam da classe Objeto. Já a classe Filter tem como função implementar os filtros. Entretanto,
como é utilizado a ferramenta iptables, não faz parte da estrutura de classes do TC e, por sua
vez, não é um Objeto.
Figura 3.2: Diagrama de classe UML do módulo elements.
37
3.2 Arquitetura
A Figura 3.2 apresenta uma demonstração da interação entre as classes do módulo elements
incluindo seus atributos, operações e associações com outras classes, através do uso de um
diagrama de classes na forma Unified Modeling Language (UML).
O módulo frame possui como função a interação com o usuário. Portanto, este módulo
é a interface gráfica do software. Neste módulo, foram utilizadas duas principais bibliotecas:
a biblioteca Java Swing
1
que permite a criação dos componentes gráficos do VisualTC, e a
biblioteca Visual Library do ambiente de desenvolvimento NetBeans 2 , para permitir que o
usuário possa adicionar objetos no ambiente de trabalho do software, movimentar, conectar
objetos entre si, entre outras funções (veja Seção 3.3).
Uma demonstração da interação dos módulos do VisualTC pode ser apresentada através
da utilização de um diagrama de pacotes na forma UML. Um diagrama de pacotes descreve
os pacotes ou módulos do sistema que são divididos em classes. A Figura 3.3 apresenta este
diagrama, a qual demonstra a interação entre os módulo do VisualTC.
Figura 3.3: Diagrama de pacotes do VisualTC.
A Figura 3.3 apresenta a interação entre os módulos frame e elements. Como apresentado na
Figura, o módulo frame faz uso do módulo elements para a geração dos scripts de configuração
e para apresentação dos parâmetros que cada elemento, criado no VisualTC, possui.
1 http://docs.oracle.com/javase/tutorial/uiswing/
2 https://platform.netbeans.org/graph/
3.3 Funcionamento do VisualTC
3.3
38
Funcionamento do VisualTC
O VisualTC surgiu com o intuito de facilitar a criação de polı́ticas de QoS no Linux. O
usuário interage com uma interface gráfica amigável, ao invés de linhas de comando, que ao
final terá um script contendo todos os comandos necessários para implementar sua polı́tica de
QoS. Assim, espera-se que se haja um aumento na produtividade. Deste modo, o VisualTC
pode ser utilizado como um ferramenta de apoio ao ensino para construção de polı́ticas QoS no
Linux.
Figura 3.4: A interface do VisualTC.
A Figura 3.4 ilustra a interface principal do VisualTC, juntamente com um exemplo de
hierarquia de uma polı́tica QoS construı́da. Com esta ilustração, é possı́vel notar que o software
possui duas áreas de trabalho:
• Hierarquia: é o ambiente que permite, ao usuário, desenhar a hierarquia de uma polı́tica
de QoS, conforme exemplo construı́do na Figura 3.4;
• Filtros: é o responsável por direcionar os pacotes nas classes e filas que o usuário desejar.
Este ambiente está ilustrado na Figura 3.7.
3.3 Funcionamento do VisualTC
39
No VisualTC, os elementos de QoS utilizados pela ferramenta TC foram divididos em quatro grupos:
• Qdisc raiz: define a disciplina de enfileiramento associada a interface saı́da do roteador,
na qual toda hierarquia começa com a criação deste elemento;
• Qdisc filha: determina os parâmetros, providos da ferramenta TC, para a disciplina de
enfileiramento escolhida pelo usuário;
• Classe raiz: utilizado apenas em qdisc que possuem classificação, serve para indicar as
taxas de transmissão mı́nima e máxima;
• Classe filha: responsável por determinar os parâmetros (taxa de transmissão mı́nima,
máxima, prioridade, etc) que cada classe filha poderá prover de uma classe raiz.
Os quatro grupos de elementos de QoS estão disponı́veis, para o usuário, através de uma paleta lateral. Nesta paleta lateral, cada grupo de elemento possui uma determinada representação
gráfica (veja Figura 3.5). Deste modo, o usuário poderá adicionar estes objetos para o ambiente
de trabalho. Após ter adicionado, é possı́vel que o usuário possa movimentar os objetos, criar
uma conexão entre os objetos adicionados, excluir objetos e suas conexões e ainda é possı́vel
configurar as propriedades que cada elemento possui.
Figura 3.5: Os elementos da paleta lateral.
Com os elementos adicionados, no ambiente de trabalho do VisualTC, é necessário que o
usuário crie conexões entre cada objeto. Desta forma, o usuário estará desenhando sua hierarquia de QoS. Dentro desta hierarquia, cada elemento possui uma identificação. Ao criar uma
conexão de um elemento raiz para um elemento filho, o VisualTC gerará, de forma automática,
a identificação que o elemento receberá. Esta geração automática é feita com base na análise da
identificação na qual o elemento “pai” possui.
A geração automática da identificação de cada elemento faz com que o usuário não necessite de um amplo conhecimento para entender o funcionamento por trás da identificação que
cada elemento receberá utilizada na ferramenta TC, proporcionando ao mesmo maior produtividade em seu desenho da hierarquia de QoS. Esta funcionalidade é feita através da análise
40
3.3 Funcionamento do VisualTC
dos campos major e minor, utilizados pelo TC para identificar os elementos seguindo o modelo
major:minor. Um exemplo desta funcionalidade do VisualTC pode ser observado através da
Figura 3.4, na qual o elemento raiz da hierarquia é o elemento cuja identificação é 1:. Neste
elemento, ficou preenchido apenas o campo major. Por conseguinte, o elemento “filho” deste
elemento possuirá a identificação 1:1, sendo gerado a partir do campo major do elemento “pai”
mais o preenchimento do campo minor com a quantidade de elementos neste mesmo nı́vel. Por
sua vez, os elementos abaixo deste último serão gerados suas identificações com base na análise
do campo minor do elemento “pai” mais a quantidade de elementos neste mesmo nı́vel. Por fim,
os elementos 10:, 11: e 12: foram gerados através do campo minor de seu elemento “pai”. A
sequencia da identificação dos elementos abaixo destes é dada seguindo esta mesma analogia.
Uma vez criadas as conexões entre os elementos, o usuário poderá configurar os parâmetros
de cada elemento. Estes parâmetros permitem ao usuário limitar, por exemplo, taxa de transmissão mı́nima (rate) e taxa de transmissão máxima (ceil) de cada fluxo. No VisualTC, esta
função é feita através de um menu de acesso (veja Figura 3.6). O VisualTC faz uma descrição
e informa dicas de utilização de cada parâmetro, não necessitando que o usuário sabia a função
dos parâmetros de cada elemento. A Figura 3.6 apresenta esta janela de propriedades.
Figura 3.6: A janela de Configurações dos elementos.
Além da configuração destes elementos, o usuário precisará definir as configurações dos
filtros. Por sua vez, a criação dos filtros, no VisualTC, é feita através da área de trabalho
denominada por Filtros. Nesta área de trabalho, o usuário poderá adicionar filtros, trocar a
ordem dos filtros existente na tabela, excluir um filtro e ainda voltar a editá-lo. No VisualTC,
estes filtros são criados através do uso da ferramenta iptables
3
do Linux. Estes são criados
através da tabela mangle que, basicamente, é a tabela responsável por marcar os pacotes. Os
filtros desta tabela são executados linha a linha. Assim, a ordem em que estes são criados
3 http://www.netfilter.org/projects/iptables/
3.3 Funcionamento do VisualTC
41
influenciam no funcionamento correto da aplicação desejada.
Figura 3.7: O ambiente Filtros do VisualTC.
A Figura 3.7 apresenta o ambiente de trabalho Filtros, neste exemplo proposto por esta
Figura, foram criados dois filtros: um que irá marcar todos os pacotes que estiverem com a
porta de origem 80 (aplicação HTTP) como pertencente a classe cujo identificador é 1:10. Já
o segundo filtro marcará os pacotes que estiverem com a porta de origem 22 (aplicação SSH)
como destino a classe de identificador 1:11. Deste modo, todo o fluxo de dados que possuir
um desses dois parâmetros serão encaminhados para os elementos 1:10 ou 1:11. Uma vez
estando em um desses elementos, o fluxo receberá o seu devido tratamento e encaminhado para
a interface de saı́da do roteador.
O usuário pode criar comentários em seu desenho da hierarquia de QoS. Deste modo o
usuário poderá lembrar-se, após algum tempo sem acessar seu projeto de QoS, da função de
cada elemento criado de maneira rápida e fácil. Entretanto, estas notas não são inseridas no
script de configuração gerado pelo VisualTC, sendo apenas ilustrado na interface gráfica. Um
exemplo de utilização de notas é mostrado através da Figura 3.4.
Ao final da criação da polı́tica de QoS, o VisualTC permite ao usuário exportar, através de
um menu, seu projeto de duas formas. Uma forma é exportar para uma imagem no formato
Portable Network Graphics (PNG), onde conterá o desenho de sua hierarquia de QoS. Já a
outra forma, sendo o principal objeto do software, é exportar para um script de configuração
que conterá todos os comandos das ferramentas TC e iptables. A Figura 3.8 apresenta o script
de configuração, da hierarquia utilizada com exemplo na Figura 3.4, gerado com VisualTC.
A Figura 3.8 apresenta o shell script que é possı́vel de se obter através do VisualTC. Da
3.3 Funcionamento do VisualTC
42
terceira linha à quinta, são informações que o software disponibiliza para o usuário. Estas
informações contém: nome do projeto criado, a data que foi gerado e que o script foi gerado com
a utilização do VisualTC. Da sétima linha à décima oitava são os comandos do TC necessários
para a configuração deste exemplo, na qual estão separados por nı́vel de hierarquia. As últimas
linhas deste script estão os comandos do iptables para criação dos filtros.
Uma vez criado o script de configuração contendo os comandos de TC para a configuração
da hierarquia de QoS desenhada, o usuário precisará executar este script em seu roteador Linux.
Após ter executado, o usuário terá como resultado a configuração de suas disciplinas de filas,
classes e filtros.
1
#!/bin/bash
2
3
4
5
# Shell script gerado a partir do arquivo de configuracao Exemplo
# em 02/12/2013 18:25:04
# atraves do software VisualTC.
6
7
8
# Deletando a qdisc root existente
tc qdisc del dev eth0 root 2>/dev/null
9
10
11
# 1o nivel da hierarquia
tc qdisc add dev eth0 root handle 1: htb default 12
12
13
14
# 2o nivel da hierarquia
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit
15
16
17
18
19
# 3o nivel da hierarquia
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40kbit ceil 40kbit burst
40 cburst 40 prio 1
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 40kbit ceil 40kbit burst
40 cburst 40 prio 2
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil 20kbit burst
20 cburst 20 prio 3
20
21
22
23
24
# 4o nivel da hierarquia
tc qdisc add dev eth0 parent 1:10 handle 10: pfifo limit 10
tc qdisc add dev eth0 parent 1:11 handle 11: pfifo limit 10
tc qdisc add dev eth0 parent 1:12 handle 12: pfifo limit 10
25
26
27
28
# Filtros
iptables -t mangle -A POSTROUTING -o eth0 -p tcp --sport 80 -j CLASSIFY --setclass 1:10
iptables -t mangle -A POSTROUTING -o eth0 -p tcp --sport 22 -j CLASSIFY --setclass 1:11
Figura 3.8: Shell script gerado pelo VisualTC.
O VisualTC é um software livre e está sob a licença GPLv3. O executável, bem como seus
códigos fontes, podem ser obtidos através do endereço http://goo.gl/XRn00i.
43
3.4 Conclusões
3.4
Conclusões
O VisualTC surgiu com o intuito de facilitar a criação de polı́ticas de QoS no Linux. O
usuário interage com uma interface gráfica amigável, ao invés de linhas de comando, que ao
final terá um script contendo todas os comandos necessários para implementar sua polı́tica de
QoS.
As caracterı́sticas do VisualTC, utilizando como base a Tabela 2.1 ilustrada na Seção 2.4,
são apresentadas através do uso da Tabela 3.1. Comparando ambas as tabelas, podemos ressaltar
as caracterı́sticas melhoradas com o software VisualTC: interface com o usuário, facilidade de
uso, conhecimento de sintaxe, facilidade de instalação e sistema operacional.
Caracterı́sticas
VisaulTC
Interface com usuário
Desktop
Interação com TC
Sim
Simulação
Não
Importa scripts
Não
Gera filtros
Sim
Suporte a filtros
u32
Facilidade de uso
Alta
Conhecimento de sintaxe
Baixa
Facilidade de instalação
Baixa
Sistema operacional
Linux e Windows
Tabela 3.1: As caracterı́sticas do VisualTC
Como o VisualTC consiste em um software que tem como principal objetivo facilitar a
utilização da ferramenta TC, sua interação com o usuário é através de uma interface desktop.
Esta interface foi criada com o intuito de o usuário ter uma alta facilidade na criação de disciplina de enfileiramento e filtros, permitindo uma melhor construção de regras de QoS através
da ferramenta TC.
Um outro diferencial do VisualTC está em sua instalação, uma vez que este procedimento
é feio através da execução de apenas uma script. Para tal, o usuário precisara ter acesso de administrador e executar o devido script de instalação (varia dependendo do sistema operacional).
Caso o usuário não tenha acesso de administrador, é possı́vel que este apenas execute o VisualTC. Para isto, basta executar o script de execução. Por fim, o VisualTC pode ser executado
em qualquer sistema operacional que possua a máquina virtual Java instalado.
44
4
Avaliação do VisualTC
Para validar o funcionamento do VisualTC, bem como sua facilidade de uso, foram montados cenários de testes, sendo estes: facilidade de uso, necessidade de conhecimento da ferramenta TC, instruções do manual e geração dos scripts de configuração.
A realização destes cenários de testes foi feita através de um grupo de alunos do Instituto Federal de Santa Catarina (IFSC) do curso Superior de Tecnologia Sistemas de Telecomunicações
no segundo semestre do ano de 2013. No cenário de avaliação da facilidade de uso e a necessidade de conhecimento do TC, o avaliado tinha que utilizar o VisualTC para desenhar uma regra
de QoS. Para avaliar as instruções do manual, o avaliado teria que recorrer ao manual de uso do
software para tirar suas dúvidas de utilização. Por fim, a avaliação dos scripts de configuração é
feita após o avaliado terminar seu desenho da regra de QoS, verificando se o script gerado está
de acordo com sua polı́tica de QoS.
4.1
Resultado dos experimentos
Os experimentos foram conduzidos por um grupo de alunos, num total de 9 alunos, que
estavam cursando a disciplina de Redes Multimı́dia. A escolha deste grupo foi dada por estes
possuı́rem o conteúdo de QoS e utilizarem a ferramenta TC nesta disciplina.
Inicialmente, na disciplina de Redes Multimı́dia, é apresentado para os alunos o funcionamento de QoS como um todo. Após isto, é introduzido o funcionamento da ferramenta TC,
suas disciplinas de filas, classes e filtros. Deste modo, o grupo de alunos criou diversas polı́ticas
de QoS utilizando a ferramenta TC. Ao final, foi apresentado o software VisualTC como um
software para facilitar o uso do TC.
Para avaliar a facilidade de uso e a necessidade de conhecimento da sintaxe da ferramenta
TC, os avaliados foram criando diversos desenhos de hierarquia de QoS. Neste cenário, o VisualTC teve aprovação de quatro avaliadores como um software que possui uma boa facilidade de
uso. Entretanto, três avaliadores julgaram que o VisualTC possui uma excelente facilidade de
4.1 Resultado dos experimentos
45
uso. Por fim, dois usuários julgaram que o software precisa de melhorias e dicas rápidas para
guiá-los em suas atividades, os quais devem ser implementados.
A Figura 4.1 apresenta um gráfico contendo a avaliação da facilidade de uso e a necessidade
de conhecimento da sintaxe do TC no VisualTC. A medida do eixo vertical deste gráfica é a
nota relacionada a este quesito, sendo elas: ruim, médio, bom e excelente. Já o eixo horizontal
é número de avaliadores que indicaram uma determinada nota.
Figura 4.1: Resultado da avaliação da facilidade de uso.
Após terminado a avaliação da facilidade de uso e a necessidade de conhecimento do TC, os
quais eram necessários a criação do desenho da hierarquia de uma polı́tica de QoS, os avaliados
geraram seus scripts de configuração contendo os comandos necessário para implementação da
sua polı́tica. Em sua grande maioria, acharam que o script correspondeu com seu desenho de
hierarquia e que o corpo deste script foi gerado de uma maneira que facilitou o entendimento
de todos.
A Figura 4.2 ilustra o gráfico contendo o resultado da avaliação dos scripts munido dos
comandos do TC e iptables necessários para a configuração de uma polı́tica de QoS. Com
este gráfico, podemos observar que a melhor nota indicada pelos avaliados é a nota “Bom”.
Entretanto, três usuários julgaram que sua nota deveria ser “Excelente” e um avaliador achou
que a nota ideal para este cenário seria “Médio”.
Figura 4.2: Resultado da avaliação do script gerado pelo VisualTC.
Alguns avaliados tiverem problemas com o desenho de sua hierarquia de QoS, os quais
4.1 Resultado dos experimentos
46
resultaram em um mau funcionamento do VisualTC, prejudicando sua avaliação final. Este
problema, com alguns usuários, ocorre por não ter ocorrido um treinamento de utilização do
VisualTC para todos os avaliados.
O motivo por não haver este treinamento de utilização do software está relacionado com a
avaliação do manual. Deste modo, o usuário teria que buscar ajuda nas instruções do manual
para sanar suas dúvidas. Entretanto, não foram criados exemplos de hierarquia de QoS no
manual. Por conseguinte, na avaliação deste quesito os usuários acharam que faltava mais
informações e dicas de utilização. O resultado da avaliação deste cenário de teste é ilustrado na
Figura 4.3
Figura 4.3: Resultado da avaliação das instruções do manual.
Os avaliados ainda foram submetidos a outras avaliações relacionadas as crı́ticas, elogios,
descrição de erros encontrados e sugestões para futuras implementações. Nas suas crı́ticas e
elogios, os avaliados acharam que o software possui uma interface muito amigável, que permite
uma visualização do escopo da polı́tica de QoS e que possui um grande potencial para facilitar o
estudo da disciplina de enfileiramento. Entretanto, como crı́tica de alguns avaliadores, acharam
que a interface do VisualTC carece de legendas para tornar mais claros os elementos visuais e
que o software poderia liberar os elementos, da paleta lateral, a medida que for adicionando determinados elementos. Deste modo, o VisualTC estaria informando, para o usuário, o momento
correto de utilizar cada elemento.
Com a utilização do VisualTC pelos avaliadores, foram encontrados alguns erros no software. A maioria destes erros estava relacionado com a forma que foram desenhados as hierarquias de QoS. Deste modo, o erro do VisualTC está em permitir que o usuário possa criar estas
hierarquias inconsistentes. Outros problemas encontrados estavam relacionados com a geração
automática da identificação de cada elemento, no qual o software gerou de maneira equivocada
em algumas situações. As inconsistência de software encontradas pelos avaliados deveram ser
corrigidas.
Ao final de sua avaliação, os avaliadores deram sugestões para futuras implementações no
4.1 Resultado dos experimentos
47
VisualTC. Das sugestões propostas pelos avaliadores destacam-se: a possibilidade de configurar as polı́ticas de QoS desenhadas em um roteador remotamente, para além de gerar o script
contendo os comandos do TC, implementar as regras de imediato e coletar informações sobre regras já criadas; a criação de desenhos de hierarquia modelos contendo explicações de
implementações, para que o usuário possa guiar-se através destes. Com estes experimentos de
uso o VisualTC apresentou alguns erros de execução, os quais devem ser corrigidos.
48
5
Conclusões
A crescente demanda de utilização das redes de computadores para transportar pacotes de
aplicações multimı́dia, que necessitam de um tratamento diferenciado das aplicações convencionais, fez com que a utilização de técnicas de Qualidade de Serviço tivesse mais importância
para os administradores de redes. Juntamente com esta demanda, aumentou a utilização do
sistema operacional Linux, por este possuir uma licença gratuita, para implementar polı́ticas de
QoS.
Utilizar a ferramenta TC (Traffic Control) do Linux é algo que exige um amplo conhecimento, uma vez que esta se baseia em linhas do comando. O VisualTC surgiu com o intuito de
facilitar a criação de polı́ticas de QoS no Linux. O usuário interage com uma interface gráfica
amigável, ao invés de linhas de comando, que ao final terá um script contendo todas os comandos necessários para implementar sua polı́tica de QoS. Assim, espera-se que se tenha um ganho
na produtividade.
Uma vez feito a avaliação com alunos do IFSC, os quais antes de avaliar o VisualTC utilizaram a ferramenta TC para criação de polı́ticas de QoS, o VisualTC pode ser utilizado como
um ferramenta de apoio ao ensino para construção de polı́ticas QoS no Linux. Deste modo, o
software proporciona uma facilidade de estudo das disciplinas de enfileiramento e uma melhor
visualização do escopo do projeto de QoS como um todo.
O estudo apresentado na fundamentação teórica foi primordial para a implementação desta
solução, pois foi possı́vel estudar detalhadamente a ferramenta TC e proporcionar para o usuário
uma interface gráfica amigável que atenda todos os objetivos propostos. Entretanto, o VisualTC
ainda não está completo, necessitando de alterações e implementações que poderão ser feitas
em trabalhos futuros.
5.1 Trabalhos Futuros
5.1
49
Trabalhos Futuros
Este trabalho tem por objetivo iniciar a criação de um software que possua uma interface
gráfica amigável para implementações de polı́ticas de QoS no Linux tão sofisticado, de fácil
utilização e completo quanto os já existentes. Por se um projeto de código aberto, são inúmeras
as possibilidade de implementações e inserção de novas funcionalidades.
Como trabalhos futuros, pode-se destacar uma implementação de modelos de estruturas de
QoS, permitindo que o usuário possa futuramente, através de um menu, carregar estes modelos
como ponto de partida para construção de sua própria polı́tica. Outra possibilidade está na
implementação de filtros com o seletor u32, pois atualmente só implementa o seletor fw em
conjunto com o iptables.
O VisualTC não trata todas as disciplinas de filas existem na ferramenta TC. Sendo assim,
uma outra ideia de trabalho futuro é a implementação das disciplinas de filas que não foram
tratadas, são elas: RED, CBQ, GRED e DSMARK.
Outro trabalho futuro é permitir que o programa possa conectar-se com um roteador Linux e
implementar a configuração do desenho da hierarquia de QoS criado pelo usuário. Deste modo,
o VisualTC ganharia a funcionalidade de utilização local e remoto. Por fim, adaptar o código
para permitir a tradução da interface para outros idiomas.
50
Lista de Abreviaturas
CBQ Class Based Queueing
DSMARK Differentiated Service Marker
FIFO First-In First-Out
FTP File Transfer Protocol
GRED Generic Random Early Detection
HFSC Hierarchical Fair Service Curve
HTB Hierarchical Token Bucket
HTTP Hypertext Transfer Protocol
PFIFO Packet First-In First-Out
PNG Portable Network Graphics
PRIO Priority Queue
QoS Qualidade de Serviço
RED Random Early Detection
SFQ Stochastic Fair Queuing
SSH Secure Shell
TCP Transmission Control Protocol
TBF Token Bucket Flow
UML Unified Modeling Language
VoIP Voice over Internet Protocol
51
Referências Bibliográficas
ALMESBERGER, W. Linux traffic control-next generation. In: Proceedings of the 9th
International Linux System Technology Conference (Linux-Kongress 2002). [S.l.: s.n.], 2002.
ALMESBERGER, W. et al. Linux network traffic control—implementation overview. 1999.
BROWN, M. A. Traffic control howto. Guide to IP Layer Network, 2006.
BULEJ, L. Htb setup script. 2004. Disponı́vel em: <http://htbinit.sourceforge.net/>.
CARVALHO, R.; ABELÉM, A. phptcadmin: solução para implementação de qualidade de
serviço em redes de computadores baseada em software livre. 2008.
CLARK, D.; BRADEN, R.; SHENKER, S. Integrated services in the internet architecture:
an overview. IETF, 1994. RFC 1633. (Request for Comments, 1633). Disponı́vel em:
<www.ietf.org/rfc/rfc1633.txt>.
COSTA, S. M. da. Sistema de gerência, segurança e controle de banda em redes.
2011. Disponı́vel em: <http://lrodrigo.sre.lncc.br/images/5/52/SGS-Control-monografiaSuzana.pdf>.
FOROUZAN, B. A. Comunicação de dados e redes de computadores. [S.l.]: Bookman, 2006.
GOLUBEV, P.; BULEJ, L. Cbq.init traffic management script. 2004. Disponı́vel em:
<http://cbqinit.sourceforge.net/>.
HUBERT, B. et al. Linux advanced routing & traffic control. p. 213, 2003. Disponı́vel em:
<http://lartc. org>.
KUROSE J. F.; ROSS, K. W. Redes de Computadores e a Internet: Uma abordagem top-down.
Trad. 5 ed. São Paulo: Addison Wesley, 2010.
NICHOLS, K. et al. Definition of the differentiated services field (DS field) in the IPv4
and IPv6 headers. IETF, 1998. RFC 2474. (Request for Comments, 2474). Disponı́vel em:
<www.ietf.org/rfc/rfc2474.txt>.
OLSHEFSKI, D. Notes on linux network qos-tcapi version 1.0. 2001. Disponı́vel em:
<ftp://www-126.ibm.com/pub/tcapi/tcapi.tar.gz>.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. [S.l.]: McGraw Hill
Brasil, 2011.
SANTOS, A. L. d. Controle de banda em redes tcp/ip utilizando o linux. 2010. Disponı́vel em:
<http://www.ginux.ufla.br/files/mono-AldirSantos.pdf>.