Fundamentos de Gerência de Redes

Prévia do material em texto

Fundamentos de gerência de redes de
computadores
Você aprenderá sobre a arquitetura de redes TCP/IP, suas motivações, monitoramento de tráfego,
limitações de qualidade de serviço e soluções para mitigá-las, além da implementação de classes de
serviço na Internet.
Prof. Guilherme Dutra Gonzaga Jaime
1. Itens iniciais
Propósito
O conhecimento sobre a arquitetura de redes TCP/IP é fundamental para profissionais de TI, pois permite o
gerenciamento eficiente e a análise de redes de computadores. Compreender as limitações de qualidade de
serviço e as soluções para mitigá-las é crucial para garantir a performance e a segurança das redes.
Objetivos
Construir uma visão geral da arquitetura TCP/IP, com motivação definida para o gerenciamento e
análise de redes a partir do exame dos conceitos gerais de monitoramento e medição de tráfego.
 
Definir Qualidade de Serviço (QoS) em redes IP, a partir da descrição de Redes de Melhor Esforço e da
identificação de Múltiplas Classes de Serviço.
Introdução
Neste conteúdo, você revisará a arquitetura de redes TCP/IP, um requisito primordial para aqueles que
pretendem realizar gerenciamento e análise de redes de computadores. Em seguida, estudará as motivações
por trás desse gerenciamento e análise de redes, e verá também uma analogia e um cenário próximo ao real
para amparar a discussão sobre a motivação. Por fim, analisará os conceitos gerais de monitoramento e
medição de tráfego.
 
Você aprenderá sobre as limitações relativas à qualidade de serviço, presentes na camada de rede da
internet. Também serão abordadas possíveis soluções usadas para mitigar as limitações discutidas, e você
aprenderá sobre o método padrão de implementação de classes de serviço na Internet.
 
Este conteúdo é essencial para quem deseja aprofundar seus conhecimentos em redes de computadores,
oferecendo uma visão abrangente e prática dos principais conceitos e desafios enfrentados na área. Ao final,
você estará mais preparado para lidar com as complexidades do gerenciamento e análise de redes, aplicando
soluções eficazes para garantir um desempenho otimizado e uma melhor qualidade de serviço.
• 
• 
1. Fundamentos e troubleshooting de redes de computadores
A eficiente organização em camadas
A internet é um sistema extremamente complicado e possui muitos componentes. Para prover uma estrutura
organizada para o estudo, projeto, desenvolvimento, gerência e análise de redes de computadores, os
projetistas de redes organizam protocolos — e o hardware e o software de rede que os executam ― em
camadas. Assim, cada protocolo pertence a uma das camadas.
 
Percebemos, então, que os sistemas de camadas têm vantagens conceituais e estruturais. Além de
proporcionar um modo estruturado para o estudo e a discussão, facilita a atualização dos componentes do
sistema, e a complexidade do sistema como um todo se torna mais tratável. De maneira geral, o modelo em
camadas segue a tática de “dividir para conquistar”.
Atenção
Para manter um sistema tão complexo em funcionamento, o administrador de rede deve monitorar,
analisar, controlar ativamente e pró-ativamente sua rede. Felizmente, existem sistemas disponíveis para
auxiliar o administrador de rede nessas tarefas, incluindo alarmes que disparam quando os parâmetros
da rede saem daquilo que é esperado. 
Modelo TCP / IP
O Modelo TCP / IP de camadas talvez seja o mais difundido exemplo de definição de um modelo de camadas
baseado no OSI, mas com algumas simplificações. 
 
Sendo:
 
TCP: Protocolo de camada de transporte que garante transmissão confiável fim a fim.
 
IP: Protocolo de Internet.
Suas cinco camadas são: aplicação, transporte, rede, enlace, física.
As funções de cada camada do modelo TCP/IP são similares às das camadas do modelo OSI. As principais
diferenças são que os serviços das camadas de Aplicação, Apresentação e alguns serviços da camada de
Sessão do modelo OSI são englobados pela camada de Aplicação do modelo TCP/IP.
 
Em outras palavras, é tarefa do programador de uma aplicação que rodará sobre uma rede TCP/IP programar
os controles estudados na camada de Apresentação e Sessão no modelo OSI.
Atenção
Alguns autores representam o modelo TCP/IP como tendo 4 camadas. A diferença é que esses autores
consideram que a camada de “Enlace” e “Física” são agrupadas na camada “Acesso à rede”. Ambas as
abordagens são consideradas corretas. 
Nível físico ou camada física
O nível físico ou camada física tem a função primordial de representar a informação (bits) em um meio de
transmissão definido. Para que essa função primordial seja alcançada, os seguintes serviços são fornecidos
pela camada física:
Codificação de dados
Alterar o padrão de sinal digital entre dois estados que representam 1s e 0s.
A codificação, em geral, envolve robustos métodos matemáticos que buscam acomodar o método de
codificação escolhido às características do meio físico a ser usado.
Essa codificação pode ser dividida em subserviços de acordo com algumas questões, como:
Qual estado de sinal representa o 1 binário?
Qual estado de sinal representa o 0 binário?
Como a estação de recepção sabe quando um “tempo de bit” começa?
Como a estação de recepção delimita um quadro?
Conexão do meio físico
Conexão do meio físico, englobando várias opções de meio físico:
Um transceptor externo será usado para a conexão com o meio?
Quantos pinos têm os conectores e para que serve cada um deles?
Técnica de transmissão
Determina se os bits codificados serão transmitidos por sinalização digital ou analógica.
• 
• 
• 
• 
• 
• 
Transmissão no meio físico
Determina quais meios físicos podem ser usados (cobre, fibra, ar);
Verifica quantos volts/dB devem ser usados para representar um determinado estado de sinal,
dado o meio físico escolhido.
Para que a camada de enlace usa os serviços da camada física?
 
A camada de enlace de dados usa os serviços da camada física e a incrementa, implementando seu objetivo
fundamental: a transmissão de unidades de dados entre dois nós (como as interfaces de rede) adjacentes/
vizinhas.
 
Para realizar essa função, a camada de enlace pode fornecer os serviços de:
 
Enquadramento/delimitação de quadros;.
 
Estabelecimento e fechamento de conexão.
 
Detecção de erros (troca de bits).
 
Controle de acesso ao meio.
 
Transmissão confiável (garantia de entrega).
 
Obstáculos
Nem todos os serviços da camada de enlace são implementados por todos os padrões/protocolos de camada
de enlace. A escolha de qual serviço será implementado depende das necessidades/limitações do meio físico
envolvido na camada física.
 
Considerando uma rede hipotética que implementa apenas as camadas física e de enlace, então seria
hipoteticamente possível realizar a comunicação de dados entre dois nós adjacentes vizinhos.
 
Entretanto, redes de comunicação são bem mais complexas e envolvem, por exemplo, uma malha de
roteadores que servem de infraestrutura de comunicação entre nós não adjacentes, ou seja, nós remotos,
como mostrado na imagem a seguir.
• 
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Malha de roteadores interligando nós (hosts) remotos: a camada de enlace
(vizinho a vizinho não é suficiente para entregar pacotes entre dois hosts
quaisquer).
Assim, novos problemas aparecem, como, por exemplo, como escolher, dentre os vários caminhos possiveis,
entre o remetente e o destinatário, qual é o caminho mais eficiente.
 
A camada de rede, então, depende da transmissão vizinho a vizinho implementada pela camada de enlace e,
em cima deste serviço, possui o objetivo primordial de tomar possivel a troca de unidades de dados entre
quaisquer hosts (sistemas finais, computadores ou qualquer dispositivo rodando aplicações) remotos, seja
qual for sua localização geográfica, isto é, transmissâo "host a host".
Contorno dos obstáculos
Para alcançar esse objetivo, a camada de rede contorna uma série de obstáculos através da implementação
dos seguintes serviços:1
Roteamento
Para definir algoritmos e protocolos de roteamento capazes de escolher, dentre as várias opções
de caminho até o destino, o caminho mais eficiente.
2Controle de congestionamento
Em algumas tecnologias de camada de rede, os roteadores podem contribuir com um host
transmissor, solicitando diminuição da taxa de transmissão para que não haja sobrecarga nas filas
(buffers) dos roteadores.
3
Estabelecimento / fechamento de conexão
Em alguns padrões de camada de rede, os roteadores participam do estabelecimento de um
caminho fixo e da reserva de recursos para uma sessão solicitada pelo host remetente.
4
Fragmentação
Se a camada de rede de um roteador notar que o tamanho máximo de pacotes permitidos no
próximo enlace de comunicação é menor do que o tamanho do pacote atual, então, o pacote será
fragmentado para respeitar a limitação em questão.
5
Contabilidade de uso da rede
Algumas tecnologias de camada de rede têm funções de contabilidade para manter o controle dos
quadros encaminhados por sistemas intermediários da rede, para produzir informações de
cobranças.
Infraestrutura de comunicação
Note, na imagem analisada anteriormente, que a infraestrutura formada pelas três primeiras camadas (física,
enlace e rede) forma o arcabouço necessário para uma infraestrutura de comunicação de dados funcional.
Em outras palavras, os roteadores que formam a infraestrutura de comunicação de grandes redes, como a
internet, implementam os serviços de três camadas: física, enlace e de rede.
Entretanto, quando se trata da troca de dados entre dois aplicativos quaisquer rodando em hosts remotos
diferentes, o conjunto formado pelas três primeiras camadas não é capaz de vencer todos os desafios
impostos à comunicação fim a fim (aplicativo a aplicativo, processo a processo).
Exemplo
Um hosts pode rodar mais de um aplicativo simultaneamente. Ao receber dados vindos de um host
remoto, como o host decidirá para qual dos aplicativos ativos os dados deverão ser entregues? Esse é
um desafio que não é tratado por nenhuma das três camadas já estudadas. 
Camada de transporte
A Camada de transporte tem o objetivo fundamental de realizar a troca de dados fim a fim (aplicativo a
aplicativo). Uma consequência desse objetivo fundamental é uma característica muito interessante presente
na camada de transporte e ausente nas três camadas inferiores (rede, enlace, física). Veja:
A camada de transporte é implementada apenas nos sistemas finais (hosts), ou seja, não é
implementada pelos roteadores e comutadores.
Na imagem da malha de roteadores interligando nós (hosts) remotos, que analisamos anteriormente, você
pode observar que a camada de transporte está presente apenas nos sistemas finais.
Malha de roteadores interligando nós (hosts) remotos
Para alcançar seu objetivo fundamental, a camada de transporte tem um série de desafios para contornar. 
 
Para isso, os seguintes serviços são oferecidos:
Segmentação de mensagens
Aceitar uma mensagem da camada de sessão;
Dividir essa mensagem em unidades menores;
Adicionar os campos de cabeçalho da camada de transporte;
Transmitir unidades menores para que a camada de rede entregue ao host desejado.
• 
• 
• 
• 
Entrega confiável
A camada de transporte do host remetente pode manter uma cópia de um segmento enviado e
manter uma contagem regressiva para aguardar uma confirmação, vinda da camada de transporte do
host destino.
Se a confirmação não chegar a tempo, a cópia do segmento será reenviado e haverá uma nova
espera por confirmação.
Os segmentos recebem, em seu cabeçalho, números de sequência que permitem ao receptor
detectar se um segmento recebido é um novo segmento um uma cópia que foi retransmitida (para o
caso de o segmento original ter apenas chegado atrasado, e não ter sido de fato perdido).
Controle de tráfego de mensagens
Neste serviço, a camada de transporte do host destino instrui o host remetente a diminuir sua taxa de
transmissão para evitar sobrecarga no buffer de recebimento.
Multiplexações de sessões
Através dos campos de cabeçalhos da camada de transporte, vários aplicativos em um host
remetente podem enviar concomitantemente diferentes fluxos de dados a diferentes aplicativos
remotos. Para a multiplexação de sessões um identificador lógico da sessão em questão é inserido no
campo de cabeçalho da camada de transporte.
Camada de aplicação
Por fim, temos a camada de aplicação. Nela, qualquer serviço ao usuário final é implementado através de
aplicativos desenvolvidos pelos programadores. 
 
Veja alguns exemplos comuns de serviços aos usuários:
 
Acesso remote a arquivos.
 
Acesso remote a impressoras.
 
Gerenciamento de rede.
 
Serviços de diretório.
 
Correio eletrônico.
• 
• 
• 
• 
• 
 
Navegação web.
 
Streaming de áudio e vídeo.
Onde é implementada cada camada do modelo TCP/IP e como se dá a comunicação entre camadas?
 
Essas são dúvidas de muitos estudantes de redes de computadores. 
 
Veja a seguir um resumo dessas informações:
Camada Onde é implementada
Aplicação Espaço do usuário (aplicativos)
Transporte Sistema Operacional
Rede Sistema Operacional
Enlace Interfaces (Placas) de Rede
Física Meios físicos (cabo, ar)
Tabela: Onde cada camada do modelo TCP/IP é implementada.
Guilherme Dutra Gonzaga Jaime.
Entenda como acontece a comunicação em rede por camadas.
 
A comunicação entre a camada física e a camada de enlace se dá através de comandos de hardware
da interface (placa) de rede;
 
A comunicação entre a camada de enlace e a camada de rede, ou seja, entre a placa de rede e o
sistema operacional se dá através de drivers do dispositivo que são fornecidos pelo fabricante;
 
Comandos internos do S.O. são usados para a comunicação entre a camada de rede e a camada de
transporte;
 
Quem desenvolve um aplicativo e deseja que a aplicação envie/receba dados pela rede, deve usar uma
API (Interface de Programação de Aplicação) de alguma linguagem de programação para realizar as
solicitações ao S.O. e receber as respectivas respostas. Sockets usados pelas linguagens C e C++ e
Java são exemplos dessas APIs.
Principais protocolos de domínio público do modelo TCP/
IP
Na internet, os serviços a serem implementados por cada camada são definidos por padrões de domínio
público que estão disponíveis através de documentos chamados RFC (Request For Comments).
 
O esquema abaixo exemplifica os principais protocolos de domínio público presentes em cada camada do
modelo TCP/IP.
• 
• 
• 
• 
• 
• 
RFC
Documentos de domínio público que definem cada padrão/protocolo usado pela Internet. Estes
documentos estão gratuitamente disponíveis na internet.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Motivação para o gerenciamento e análise de redes
Antes de falarmos especificamente de rede, vamos analisar uma analogia proposta no livro Redes de
Computadores e Internet, de James F. Kurose, Capítulo 9, 6ª edição. Observe:
 
Suponha um avião. Este é um sistema extremamente complexo e heterogêneo (sistemas mecânicos,
hidráulicos, elétricos, eletrônicos, computacionais).
 
Para que o comandante consiga operar com eficiência este sistema complexo, é necessário uma cabine de
comando muito bem equipada com instrumentos para que o piloto possa monitorar e controlar os mais
diversos componentes da aeronave.
Comentário
Neste exemplo, o “administrador” monitora equipamentos remotos e analisa os dados para garantir que
os equipamentos estejam funcionando e operando dentro dos limites especificados. Por exemplo,
impedir que o combustível do avião não acabe, que sua rota esteja dentro do esperado, e que a
velocidade de voo não esteja acima dos limites para que a resistência do ar não gere danos estruturais à
aeronave, nem abaixo dos limites para que não haja risco de a aeronave perder a sustentação e começar
a cair (stall). 
Entre os trabalhos do administrador do voo (o comandante), está controlar reativamente o sistema, realizando
ajustes de acordo com as modificaçõesocorridas no sistema ou na atmosfera, e gerenciar proativamente o
sistema, detectando tendências ou comportamentos anômalos que permitem executar uma ação antes que
surjam problemas mais sérios.
 
Para auxiliar o comandante nesta difícil tarefa, são disponibilizados sistemas de auxílios que disparam alarmes
logo que alguma anormalidade é detectada.
 
De maneira análoga, o administrador de redes de computadores deve:
 
Monitorar
 
Analisar
 
Controlar reativamente
 
Controlar proativamente
 
Felizmente, assim como no caso do exemplo da aeronave, existem sistemas disponíveis para auxiliar o
administrador de rede nestas tarefas, incluindo alarmes que disparam quando os parâmetros da rede saem
daquilo que é esperado.
 
Veja, a seguir, um exemplo de gerenciamento de rede:
 
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
• 
• 
• 
• 
Um cenário simples que ilustra a utilização do gerenciamento de rede.
Cenários de monitoração
Mesmo em um cenário aparentemente simples, que envolve poucas dezenas de hosts, 3 servidores, 3
roteadores, 3 switches e 1 link para a internet, há muitos cenários de monitoração em que o administrador
precisará ter ferramentas de gerenciamento e análise adequadas para que possa trabalhar com eficiência. 
 
Veja algumas situações em que essas ferramentas são necessárias:
1
Detecção de falha em uma placa de interface em um servidor ou roteador
Usando uma ferramenta adequada, um servidor ou roteador pode notificar o administrador caso
uma de suas interfaces falhe.
2
Monitoração dos hosts
Checar se os hosts estão ativos e operacionais.
3
Monitoração de tráfego para auxiliar o oferecimento de recursos
Através do monitoramento de tráfego, o administrador pode, por exemplo, detectar que a maior parte
das consultas transmitidas a um servidor está vindo de outra rede. O administrador pode, então,
trocar o servidor de rede para que ele esteja mais próximo dos hosts que mais realizam consultas a
ele. Assim, as respostas do servidor chegarão mais rapidamente e os links entre roteadores
observarão diminuição de carga.
4Detecção de mudanças rápidas nas tabelas de roteamento
Algoritmos de roteamento mal configurados podem gerar, por exemplo, alternâncias de rotas para
uma mesma rede destino. Seria muito importante para o administrador ser capaz de notar esta
alternância para consertá-la antes que a rede caia.
5
Monitoração de SLAs
SLAs (Service Level Afreements) ou Acordos de Nível de Serviço são os contratos entre um provedor
e um cliente que prevê quando determinados parâmetros de desempenho estão acima de um limite
definido. Como o cliente paga por esses acordos, é claro que tem interesse em monitorar as métricas
constantes no contrato a fim de checar sua conformidade. Por exemplo, a vazão, a latência (delay), a
fração perda de pacotes e a ocorrência de interrupções de serviço (quedas do link) podem constar
em contratos SLAs e serem monitorados pelo cliente.
6
Detecção de invasão
Qualquer administrador de rede sempre deseja receber notificações, caso haja a ocorrência de
tráfego suspeito em sua rede.
Conceitos gerais de monitoramento e medição de tráfego
Existe, atualmente, um modelo padrão para o gerenciamento de rede disponibilizado pela ISO (International
Organization for Standardization). A ideia deste modelo é organizar os possíveis cenários de gerenciamento e
análise de redes em um arcabouço melhor estruturado. 
 
Observe:
Cenário Breve descrição
Gerenciamento de
desempenho
Busca quantificar, medir, informar, analisar e controlar o
desempenho e uma rede.
Gerenciamento de
falhas
Detectar, registrar (em logs) e reagir a falhas.
Gerenciamento de
configuração
Permite que se saiba quais dispositivos fazem parte da rede e
quais são as configurações usadas para os hardwares e
softwares.
Gerenciamento de
contabilização
Permite que o uso de recursos por usuários seja monitorado para
fins como cobrança.
Gerenciamento de
Segurança
Controlar o acesso aos recursos de acordo com as políticas
estabelecidas.
Tabela: modelo padrão para o gerenciamento de rede.
Guilherme Dutra Gonzaga Jaime.
Mas o que eu posso medir em relação ao desempenho de uma rede?
 
O gerenciamento do desempenho é um tópico especial, dentro dos cenários definidos pelo modelo ISO. A
resposta é que existem métricas que comumente são de interesse dos administradores de rede.
 
Dentre as métricas, destacam-se:
Vazão (throughput)
Mede a quantidade de bits que passa pelo meio de comunicação por intervalo de tempo.
Atraso em uma direção (one-way delay)
O atraso em uma direção representa o tempo decorrido entre o instante em que o pacote sai do
remetente até o momento em que o pacote chega no destinatário final.
Atraso de ida e volta (RTT - Round Trip Time)
É dado pelo tempo medido desde o momento em que o pacote é transmitido até o momento em que
uma resposta é recebida.
Variação do atraso (Jitter)
O jitter é dado pela diferença entre os intervalos de tempo entre transmissões de pacotes no
transmissor e o intervalo de tempo entre chegadas de pacotes no receptor.
Fração de perda de pacotes (Packet Loss Ratio)
Mede a razão entre a quantidade de pacotes que não foram entregues ao receptor dado a quantidade
total enviada.
Tamanho das filas (Queue size)
Esta métrica é importante por duas razões principais. Primeiro porque a medida em que as filas dos
roteadores aumentam, o atraso observado (exemplo RTT) aumenta consideravelmente.
Depois, porque se a fila fica completamente cheia, não haverá espaço para armazenamento dos
pacotes que chegam e eles serão descartados.
Taxa de colisão (Collision Rate)
É o número de colisões que ocorrem em um dado intervalo de tempo.
Carga/Utilização da rede
Esta métrica apresenta qual é a percentual de tempo em que a rede está em uso dividido pelo tempo
total de observação.
Percentual de tráfego por protocolo
Esta métrica busca observar qual é a percentual de dados relativos a cada protocolo em relação a
todos os dados que passaram pela rede.
Para saber mais, leia ao conteúdo sobre métricas para medir o desempenho de uma rede.
Verificando o aprendizado
Questão 1
Analise os itens abaixo e, em seguida, faça a relação com suas definições.
 
( ) Rede
( ) Enlace
( ) Sistemas operacionais d sistemas finais (hosts).
( ) RTT
 
1. É a camada do modelo TCP/IP que possui a função fundamental de transportar unidades de dados entre
interfaces vizinhas/adjacentes.
 
2. É a camada do modelo TCP/IP que possui a função fundamental de transporte de dados hosts a host.
 
3. É uma métrica de análise de desempenho de redes de computadores que mede o atraso de ida e volta.
 
4. Local onde são implementadas as camadas de redes e de transporte do modelo TCP/IP.
A 2 − 1 − 4 − 3
B 2 – 1 – 3 - 4
C 1 − 4 − 3 − 2
D 4 − 2 − 1 − 3
https://cdn-conteudo.ensineme.com.br/a01_t13_2fe43154de.pdf
A alternativa A está correta.
Isso se justifica porque a camada de transporte do modelo TCP/IP é responsável pelo transporte de dados
de host a host (2), a camada de enlace é responsável por transportar unidades de dados entre interfaces
vizinhas/adjacentes (1), os sistemas operacionais dos sistemas finais (hosts) são onde são implementadas
as camadas de redes e de transporte do modelo TCP/IP (4), e o RTT (Round-Trip Time) é uma métrica de
análise de desempenho de redes que mede o atraso de ida e volta (3). 
2. Qualidade de Serviço (QoS)
O que é Qualidade de Serviço?
O protocolo de camada de rede da internet, o IP, provê um serviço denominado de melhor esforço. Em outras
palavras, a internet faz seu melhor esforço para transportar cada datagrama do remetente ao receptor o mais
rapidamente possível, mas não faz nenhuma promessa sequer sobre a Qualidade de Serviço (QoS – Quality of
Service) a ser alcançada.
 
Entende-se QoS, então, como:
A garantia de que métricas como o Atraso, a Variação no Atraso, a Perda de Pacotes e a Banda
estarão em níveis adequados para uma determinada aplicação.
Portanto, quandose diz que a internet, em sua camada de rede, oferece o serviço de melhor esforço significa
que a rede, em princípio, não oferece QoS.
Diferentes requisitos quanto à QoS
É importante destacar que diferentes classes de aplicações possuem diferentes requisitos quanto à QoS. Por
exemplo, aplicações multimídia (streaming de áudio/vídeo, telefonia IP etc.) tipicamente requerem que a taxa
de transmissão esteja acima de um nível definido para que a aplicação funcione.
 
Veja algumas características:
 
O atraso e a perda também impactam na qualidade da experiência do usuário e não podem ser muito
altos. 
 
Outras aplicações, como downloads de arquivos, correio eletrônico e aplicações de bancos de dados,
não toleram bem degradações no atraso e na taxa de transmissão, mas não toleram perda de dados.
 
A falta da garantia (QoS) na internet impõe desafios significativos, principalmente ao projeto de redes
que deve suportar aplicações multimídia.
 
Streaming de áudio/vídeo, vídeo conferência e telefonia IP (VoIP) são exemplos de aplicações que são
bastante sensíveis à variação de atraso e à taxa de transmissão e, nos casos das aplicações multimídia
de tempo real (teleconferência), ao atraso.
 
Algum nível de perda é tolerável, desde que não seja muito alta. Em geral, atrasos acima de 150ms já
impactam fortemente aplicações de videoconferência e VoIP.
• 
• 
• 
• 
• 
 
Um nível de perda de pacotes que ultrapasse a faixa de 1% a 20% também gera forte degradação na
experiência do usuário de aplicações multimídia.
Exemplo de VoIP
Para manter a discussão em termos concretos, suponha as limitações de um serviço de IP de melhor
esforço no contexto de um exemplo específico de VoIP. O remetente gera bytes a uma taxa de
8.000bytes por segundo. A cada 20ms, o emitente agrupa esses bytes em um bloco. Um bloco e um
cabeçalho especial (discutiremos sobre isso em seguida) são encapsulados em um segmento UDP
por meio de uma chamada à interface do socket. Sendo assim, o número de bytes do bloco é:
(20ms) ∙ (8.000bytes/s) = 160bytes
Um segmento de UDP é enviado a cada 20ms. Se cada pacote chega ao receptor com um atraso fim
a fim constante, então, os pacotes chegam no receptor a cada 20ms. Nessas condições ideais, o
receptor pode simplesmente reproduzir cada parte assim que ele chega. Infelizmente alguns pacotes
talvez se percam e a maioria deles não possuirá o mesmo atraso fim a fim ainda que a internet esteja
ligeiramente congestionada. Por esse motivo, o receptor deve se empenhar em determinar:
1 - quando reproduzir uma parte; e
2 - o que fazer com uma parte perdida.
Considere um dos segmentos UDPs gerado por nossa aplicação VoIP.
 
O segmento UDP é encapsulado por um datagrama IP. Enquanto o datagrama vagueia pela rede, ele passa por
buffers (filas) nos roteadores, onde aguarda para ser transmitido em enlaces de saída.
 
É possível que um ou mais dos buffers na rota entre o remetente e o destinatário estejam lotados e não
possam aceitar o datagrama IP. Nesse caso, o datagrama IP será descartado e nunca chegará à aplicação
receptora.
A perda pode ser eliminada enviando os
pacotes por TCP (que proporciona
transferência de dados confiável) em vez de
por UDP. Contudo, os mecanismos de
retransmissão frequentemente são
considerados inaceitáveis para aplicações
interativas de áudio em tempo real, como o
VoIP, porque aumentam o atraso fim a fim.
 
Além disso, por causa do controle do TCP após
a perda de pacote, a taxa de transmissão no
remetente pode ser reduzida a uma taxa mais
baixa do que a de reprodução no receptor,
possivelmente ocasionando inanição no buffer e pausa forçada da aplicação para que o buffer seja
recarregado. Isso pode causar um forte impacto sobre a integridade da voz no receptor. Por essas razões,
quase todas as aplicações de VoIP existentes executam em UDP.
Por exemplo, o UDP é usado pelo Skype, a não ser que o usuário esteja atrás de um NAT ou de um firewall que
bloqueia os segmentos UDP (neste caso, TCP é usado).
 
• 
Porém, perder pacotes talvez não seja tão desastroso quanto se possa imaginar. Na verdade, taxas de perda
de pacotes entre 1% e 20% podem ser toleradas, dependendo de como a voz é codificada e transmitida e de
como a perda é ocultada no receptor (abordaremos isso daqui a pouco).
 
A tabela a seguir compila os principais tipos de aplicações e os respectivos requisitos de QoS:
Aplicação Perda de
dados Vazão Sensibilidade ao
tempo
Transferência/download de
arquivo
Sem perda Elástica Não
E-mail Sem perda Elástica Não
Documentos Web Sem perda
Elástica (alguns kbits/
s)
Nāo
Telefonia via Internet/
videoconferência
Tolerante à
perda
Áudio: alguns kbits/s -
1 Mbit/s Video: 
Sim: décimos de
segundo
Áudio/video armazenado
Tolerante à
perda
Igual acima
Sim: alguns
segundos
Jogos interativos
Tolerante à
perda
Poucos kbits/s - 10
kbits/s
Sim: décimos de
segundo
Mensagem instantânea Sem perda Elástico Sim e não
Tabela: Requisitos de QoS de aplicações de rede.
Guilherme Dutra Gonzaga Jaime. 
Motivação para a implantação de QoS em redes IP
A motivação para a implantação de QoS em redes IP vem da demanda por aplicações que são sensíveis:
 
Ao atraso (delay).
 
À variação do atraso (jitter).
 
À perda de pacotes (packet-loss).
 
À taxa de transmissão (transmission rate).
 
Dessa forma, é necessário prover algum tipo de técnica que busca obter mais do que o serviço de melhor
esforço sozinho é capaz de oferecer. Então, várias técnicas foram propostas para aprimorar o desempenho de
uma rede de melhor esforço (ou seja, da internet).
 
• 
• 
• 
• 
Na camada de aplicação, são aplicadas técnicas que foram criadas para uso na internet de melhor esforço de
hoje. São elas:
Bufferização de dados no cliente
Para contornar o jitter e a variação.
FEC (Forward Error Correction)
Para recuperação de perda de dados. na taxa
de transmissão de dados.
Lembre-se que elas estão em uso exatamente porque a internet oferece, em sua camada de rede, apenas
uma única classe de serviço: o melhor esforço (Best Effort).
Mecanismos para dar suporte à entrega de conteúdo de
multimídia
Como estudiosos de redes de computadores, não podemos evitar a pergunta:
 
Poderia a camada de rede da internet colaborar oferecendo mecanismos para dar suporte à entrega de
conteúdo de multimídia?
 
Como veremos nesta aula, a resposta é, naturalmente, sim!
 
É importante ressaltar que diversos dos mecanismos de camada de rede que estudaremos para melhorar a
QoS ainda precisam ser colocados em prática. Talvez isso se deva a sua complexidade e ao fato de que as
técnicas em nível de aplicação, junto com o serviço de melhor esforço e recursos de rede corretamente
dimensionados (como a largura de banda), podem, de fato, oferecer um serviço de entrega de multimídia de
fim a fim “bom o bastante” (mesmo que não seja perfeito).
 
A tabela a seguir resume 3 técnicas gerais para oferecer suporte em camada de rede para aplicações de
multimídia. Observe:
 
Técnica Granularidade Garantia Mecanismos Complexidade Implementação
no momento
Obtendo o
melhor do
serviço de
melhor
esforço.
Todo o
tráfego
tratado
igualmente.
Nenhuma
ou
flexivel.
Suporte da
camada de
aplicaçāo,
CDNs,
sobreposiçōes,
provisão de
recurso em
nivel de rede.
Minima
Em toda a
parte
Serviço
diferenciado.
Diferentes
classes de
tráfego
tratadas de
formas
diferentes.
Nenhuma
ou
flexivel.
Marcação,
regulação e
programação
de pacotes.
Média Alguma
Técnica Granularidade Garantia Mecanismos Complexidade Implementação
no momento
Garantias
de
qualidade
de serviço
(QoS) por
conexão.
Cada fluxo de
origem-
destino
tratado de
forma
diferente.
Flexivel
ou rigida,
uma vez
admitido
o fluxo.
Marcação,
regulação e
programação
de pacotes;
admissão e
sinalização de
chamadas.
Leve Pouca
Tabela: Técnicas em camada de rede para melhorar a QoS para aplicações multimídia.
Guilherme Dutra Gonzaga Jaime.
Veja, a seguir, uma descrição dos mecanismos para dar suporte à entrega de conteúdo de multimídia:
Obtendoo melhor do serviço de melhor esforço
Os mecanismos de camada de aplicação podem ser usados com sucesso em uma rede bem
dimensionada onde a perda de pacotes e o atraso excessivo de fim a fim raramente ocorrem.
Quando são previstos aumentos de demanda, os provedores incrementam, adquirindo novos
equipamentos e estabelecendo novos (e mais velozes) links, largura de banda e capacidade de
comutação para continuar a garantir um desempenho satisfatório com atraso e perda de pacotes.
Serviço diferenciado
Desde os primeiros dias da internet, tem sido previsto que diferentes tipos de tráfego (conforme
indicado no campo de tipo de serviço, TOS – Type of Service, do cabeçalho de pacote IPv4) poderiam
ser fornecidos com classes de serviço diversas em vez de um único serviço de melhor esforço
abrangente.
Com o serviço diferenciado, um tipo de tráfego poderia receber prioridade estrita sobre outra classe
de tráfego, quando os dois tipos forem enfileirados em um roteador. Por exemplo, pacotes
pertencentes a uma aplicação interativa em tempo real poderiam ter prioridade sobre outros pacotes
por causa de restrições de atraso mais rigorosas. A introdução do serviço diferenciado na rede exigirá
novos mecanismos para marcação de pacotes (indicando a classe de serviço de um pacote).
Garantias de qualidade de serviço (QoS) por conexão
Com garantias de QoS por conexão, cada instância de uma aplicação reserva explicitamente largura
de banda de fim a fim e, assim, tem um desempenho de fim a fim garantido.
Uma garantia rígida significa que a aplicação receberá sua qualidade de serviço (QoS)
requisitada com certeza.
Uma garantia flexível significa que a aplicação receberá sua qualidade de serviço requisitada
com alta probabilidade.
Por exemplo, se um usuário quiser fazer uma chamada VoIP do Hospedeiro A para o Hospedeiro B, a
aplicação VoIP do usuário reserva largura de banda explicitamente em cada enlace ao longo de uma
rota entre os dois hospedeiros.
Atividade
Pense, agora, na seguinte pergunta:
 
Por que o QoS por conexão não teve implementação significativa na internet?
Chave de resposta
Permitir que as aplicações façam reservas e exigir que a rede cumpra as reservas requer grandes
mudanças.
As mudanças necessárias são:
 
Precisamos de um protocolo que, em favor das aplicações, reserve largura de banda do enlace nos
caminhos dos remetentes aos destinatários.
 
Precisamos de novas políticas de escalonamento nas filas do roteador, para que as reservas de largura
de banda por conexão possam ser cumpridas.
 
Para fazer uma reserva, as aplicações precisam dar à rede uma descrição do tráfego que elas
pretendem enviar e a rede precisará regular o tráfego de cada aplicação para ter certeza de que
obedecerá a essa descrição.
Tais mecanismos, quando combinados, exigem software novo e complexo nos hospedeiros e nos
roteadores. Devido a isso, o serviço garantido de QoS por conexão não teve implementação
significativa na internet.
• 
• 
• 
• 
• 
Dimensionando Redes de Melhor Esforço
Fundamentalmente, a dificuldade no suporte de aplicações de multimídia surge de seus rigorosos requisitos
de desempenho — pouco atraso, variação de atraso, perda de pacotes e baixa taxa de transmissão de fim a
fim — e do fato de que atraso, variação do atraso e perda de pacotes ocorrem sempre que a rede fica
congestionada.
Uma primeira técnica para melhorar a qualidade
das aplicações de multimídia — e que, muitas
vezes, pode ser usada para resolver quase
qualquer problema onde os recursos são
restritos — é apenas “gastar dinheiro no
problema” e, desse modo, evitar disputa por
recursos.
 
No caso da multimídia em rede, isso significa
oferecer capacidade de enlace suficiente,
através da rede, para que nunca, ou raramente,
ocorra além de consequentes atrasos e perdas
de pacotes. Com capacidade de enlace
suficiente, os pacotes poderiam correr a internet de hoje sem atraso ou perda nas filas.
 
Por muitos pontos de vista, essa é uma situação ideal:
 
Aplicações de multimídia funcionariam perfeitamente.
 
Os usuários estariam satisfeitos.
 
Tudo isso poderia ser obtido sem mudanças na arquitetura de melhor esforço da internet.
Provisão e Dimensionamento
Tanto a provisão de largura de banda quanto o dimensionamento de rede são assuntos complexos e vão muito
além do que abordaremos aqui.
 
No entanto, vamos falar um pouco deles. Observe:
1
Provisão de largura de banda
A questão logicamente é quanta capacidade é “suficiente” para se conseguir esse paraíso e se os
custos para fornecer largura de banda “suficiente” são práticos do ponto de vista comercial para os
provedores.
 
Quanta capacidade oferecer nos enlaces de rede em determinada topologia para alcançar
determinado nível de desempenho costuma ser conhecida como provisão de largura de banda.
• 
• 
• 
2Dimensionamento de redes
A questão ainda mais complicada de como projetar uma topologia de rede (onde posicionar
roteadores, como interconectar roteadores com enlaces e que capacidade atribuir aos enlaces), para
alcançar determinado nível de desempenho de fim a fim, é um problema de projeto de redes que
muitas vezes é chamado de dimensionamento de redes.
Como oferecer capacidade suficiente para atender aos requisitos de desempenho de uma aplicação?
 
Veja a partir de agora as questões que precisam ser resolvidas para que se possa prever o desempenho em
nível de aplicação entre duas extremidades da rede oferecendo, assim, capacidade suficiente para atender
aos requisitos de desempenho de uma aplicação.
Modelos de demanda de tráfego entre as extremidades da rede
Os modelos podem precisar ser especificados em dois níveis:
Nível de chamada (por exemplo, os usuários “chegando” à rede e executando aplicações).
Nível de pacote (por exemplo, pacotes sendo gerados pelas aplicações em curso).
Observe que a carga de trabalho pode variar com o tempo.
Requisitos de desempenho bem definidos
Por exemplo, um requisito de desempenho para dar suporte ao tráfego sensível ao atraso (como uma
aplicação de multimídia interativa) poderia ser explicado pela probabilidade de o atraso de fim a fim
do pacote ser maior do que um atraso máximo tolerável.
Modelos para prever o desempenho de fim a fim
Nos modelos para prever o desempenho de fim a fim para determinado modelo de carga de trabalho
e técnicas para encontrar uma alocação de largura de banda de custo mínimo que resulte em cumprir
todos os requisitos do usuário, os pesquisadores estão ocupados desenvolvendo modelos de
desempenho que possam:
Quantificar o desempenho para determinada carga de trabalho.
Criar técnicas de otimização para achar alocações de largura de banda de custo mínimo
cumprindo requisitos de desempenho.
Por que a internet de hoje não dá suporte para o tráfego de multimídia em um nível de desempenho
apropriado?
 
• 
• 
• 
• 
Se fosse dimensionada, sabemos que a internet de melhor esforço de hoje poderia (do ponto de vista da
tecnologia) dar suporte para o tráfego de multimídia em um nível de desempenho apropriado. A internet de
hoje não faz isso devido a dois aspectos:
1
Aspectos organizacionais
As questões organizacionais talvez sejam ainda mais assombrosas.
 
Observe que um caminho de fim a fim entre duas extremidades de multimídia passará pelas redes
de vários provedores.
 
De um ponto de vista organizacional, esses provedores estariam dispostos a cooperar (talvez
compartilhando receitas) para garantir que o caminho de fim a fim seja dimensionado devidamente
para dar suporte a aplicações de multimídia?
2
Aspecto econômico
As respostas são principalmente econômicas.
 
Mas será que os usuários estariam dispostos a pagar a seus provedores o suficiente para que eles
instalassem largura de banda que desse suporte a aplicações de multimídia por uma internet de
melhor esforço?
Múltiplas classes de serviço
Talvez a melhoria mais simples no serviço de melhor esforço da internet atual seja dividir o tráfego em classes
e fornecer diferentes níveis de serviço para essas classes.
 
Veja algunsexemplos:
Um provedor poderia querer oferecer uma classe de serviço mais alta para o tráfego de VoIP (sensível
ao atraso) ou teleconferência (e cobrar mais por esse serviço) do que para o tráfego elástico (como e-
mail ou HTTP). Como alternativa, um provedor poderia simplesmente querer oferecer uma qualidade de
serviço mais alta para clientes que queiram pagar mais por esse serviço melhorado.
 
Diversos provedores de acesso residencial, com e sem fio, por celular adotaram esses níveis de serviço
em camadas — com assinantes de serviço “platina” recebendo um serviço melhor do que os assinantes
“ouro” ou “prata”.
 
Já estamos acostumados com diferentes classes de serviço em nossas vidas diárias. Os passageiros
de primeira classe em companhias aéreas, por exemplo, recebem melhor atendimento do que os da
classe executiva, que, por sua vez, recebem melhor atendimento do que aqueles que voam na classe
econômica.
 
Os VIPs recebem entrada imediata em eventos, enquanto todos os outros esperam na fila. Os idosos
são respeitados em alguns países e recebem assentos de honra e a melhor comida em uma mesa.
 
Podemos classificar as múltiplas classes de serviço em:
• 
• 
• 
• 
HTTP
Hyper Text Transfer Protocol – Protocolo padrão para navegação web da Internet.
Serviço diferencial entre agregações de tráfego
É importante observar que esse serviço diferencial é fornecido entre agregações de tráfego, ou seja, 
entre classes de tráfego e não entre conexões individuais.
Por exemplo, todos os passageiros de primeira classe são tratados da mesma forma, sem que
qualquer passageiro da primeira classe receba tratamento melhor do que qualquer outro da mesma
classe.
Seguindo os mesmos critérios, todos os pacotes VoIP receberiam o mesmo tratamento dentro da
rede, sem depender da conexão fim a fim à qual pertencem.
Conforme veremos, lidando com um pequeno número de agregações de tráfego em vez de um
número grande de conexões individuais, novos mecanismos de rede exigidos para fornecer um
serviço ainda melhor podem ser mantidos relativamente simples. Os primeiros projetistas da internet
claramente tinham essa noção de múltiplas classes de serviço em mente.
O campo Tipo de Serviço (ToS)
Vamos relembrar o campo Tipo de Serviço (ToS), no cabeçalho IPv4, que é descrito assim:
“O TOS fornece uma indicação dos parâmetros abstratos da qualidade de serviço desejada. Esses
parâmetros devem ser usados para guiar a escolha de parâmetros através de serviço quando um
datagrama estiver sendo transmitido através de uma rede específica. Muitas redes oferecem serviços
prioritários, os quais de alguma forma reservam mais atenção ao tráfego de prioridade alta do que aos
outros.” [ISI 1979]
Há três décadas, a visão de fornecer diferentes níveis de serviço a diferentes níveis de tráfego estava
evidente. No entanto, levou um longo período para que pudéssemos perceber essa visão.
Agora, analise a seguinte ilustração:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Características:
 
A ilustração mostra um cenário simples de rede em que dois fluxos de pacotes de aplicação se
originam nos hospedeiros H1 e H2, em uma LAN, e são destinados aos hospedeiros H3 e H4, em outra
LAN.
 
Os roteadores nas duas LANs são ligados por um enlace de 1 Mbits/s.
Temos os seguintes problemas:
 
1. Vamos admitir que as velocidades das LANs sejam bem mais altas do que 1Mbits/s e focalizar a fila de saída
do roteador R1. É aqui que ocorrerão atraso e perda de pacotes, se a taxa agregada de envio de H1 e H2
exceder 1Mbits/s.
 
2. Vamos supor ainda que uma aplicação de áudio de 1Mbit/s (por exemplo, uma chamada de áudio com
qualidade de CD) compartilhe o enlace de 1Mbits/s entre R1 e R2 com uma aplicação de navegação Web HTTP
que está baixando uma página Web de H2 para H4. Na Internet de melhor esforço, os pacotes de áudio e
HTTP são misturados na fila de saída de R1 e (em geral) transmitidos na ordem primeiro a entrar/primeiro a
sair (FIFO – First In First Out). Nesse cenário, uma rajada de pacotes da origem HTTP poderia lotar a fila,
fazendo pacotes IP de áudio sofrerem atraso excessivo ou perda por causa do estouro do buffer (fila) em R1.
Atividade
Como você resolveria esse problema potencial?
Chave de resposta
Dado que a aplicação de navegação Web HTTP não é sensível ao tempo, você poderia, por intuição, dar
prioridade aos pacotes de áudio em R1. Em uma disciplina estrita de escalonamento por prioridade, um
pacote IP de áudio no buffer de saída de R1 seria sempre transmitido antes de qualquer pacote HTTP
nesse mesmo buffer.
O enlace entre R1 e R2 pareceria um enlace dedicado de 1Mbits/s para o tráfego de áudio e o HTTP usaria
o enlace de R1 a R2 somente quando não houvesse nenhum tráfego de áudio na fila.
Para R1 distinguir os pacotes de áudio dos HTTP em sua fila, cada pacote deve ser marcado como
pertencente a uma das duas classes de tráfego.
Lembre-se de que esse era o objetivo original do campo de Tipo de Serviço (Type-Of-Service — ToS) do
IPv4.
Princípios dos mecanismos necessários para oferecer
múltiplas classes de tráfego
Primeiro princípio do fornecimento de múltiplas classes de serviço
A marcação de pacotes permite que um roteador faça a distinção de pacotes pertencentes a diferentes
classes de tráfego. Observe que, embora, nosso exemplo considere um fluxo concorrente de multimídia e
• 
• 
elástico, o mesmo princípio se aplica ao caso em que classes de serviço platina, ouro e prata são
implementadas. Um mecanismo de marcação de pacotes ainda é necessário para indicar a classe de serviço à
qual um pacote pertence.
 
Suponha agora que o roteador saiba que deve dar prioridade a pacotes da aplicação de áudio de 1Mbit/s.
 
Como a velocidade de saída do enlace é de 1Mbits/s, mesmo que os pacotes HTTP recebam prioridade mais
baixa, ainda assim receberão na média um serviço de transmissão de 0Mbit/s.
Atividade
Mas o que acontece se a aplicação de áudio começar a enviar pacotes a uma taxa de 1Mbits/s ou mais alta
(seja com má intenção, seja devido a um erro de aplicação)?
Chave de resposta
Nesse caso, os pacotes HTTP morrerão por inanição, isto é, não receberão nenhum serviço no enlace de
R1 a R2.
Problemas semelhantes ocorreriam se várias aplicações (por exemplo, várias chamadas de áudio), todas
com a mesma classe de serviço, estivessem compartilhando a largura de banda de um enlace. Elas
também poderiam coletivamente arruinar a sessão HTTP.
Segundo princípio do fornecimento de múltiplas classes de serviço
Idealmente, o que se quer é certo grau de isolamento entre classes de tráfego para proteger uma classe da
outra. Essa proteção poderia ser implementada em diferentes locais da rede — em todo e qualquer roteador
na primeira entrada na rede ou nos limites da rede entre domínios. Logo, este é o segundo princípio do
fornecimento de múltiplas classes de serviço:
É desejável fornecer algum grau de isolamento de trâfego entre as classes para que uma classe nāo
seja afetada adversamente por outra classe de comportamento inadequado.
Quando há a necessidade de atender a ambos os princípios, podemos utilizar algumas técnicas. Observe:
Leaky Bucket (Balde Furado)
Ao invés de usar uma disciplina de atendimento com prioridade estrita, existem técnicas para garantir que
ambos os princípios sejam atendidos, como o Leaky Bucket (Balde Furado), mostrado na imagem.
 
Se a aplicação regulada se comportar mal, mecanismos como o Leaky Bucket executarão alguma ação para
evitar que o tráfego de menor prioridade sofra de inanição (nunca seja atendido).
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Leaky Bucket (Balde Furado). Um fluxo de alta prioridade só pode exceder uma
taxa definida por um tempo curto (para evitar a inanição de fluxos de menor
prioridade).
Existem inúmeras técnicas alternativas ao Leaky Bucket para disciplinar o atendimento de pacotes em filas de
roteadores. Na verdade, poderíamos passar todo um semestre dedicado a uma disciplinaque trataria
exclusivamente deste assunto. Entretanto, por questões de escopo e limitação de tempo, deixaremos o Leaky
Bucket como o único exemplo.
Diffserv
Tendo visto a motivação, os princípios e os mecanismos específicos para oferecer múltiplas classes de
serviço, vamos encerrar nosso estudo dessas técnicas com um exemplo: a arquitetura Diffserv (RFC 2475).
RFC
Request For Comments – Documentos de domínio público que definem cada padrão/protocolo usado
pela Internet. Estes documentos estão gratuitamente disponíveis na Internet.
O Diffserv oferece diferenciação de serviço, isto é, a capacidade de lidar com as diversas classes de tráfego
de diferentes modos na internet de modo escalável.
 
A necessidade da escalabilidade vem do fato de que centenas de milhares de fluxos simultâneos de tráfego
de origem-destino estarem presentes em um roteador backbone.
 
Veremos, de modo breve, que essa necessidade é satisfeita ao colocarmos uma funcionalidade dentro do
núcleo da rede com operações de controle mais complexas, sendo implementadas na borda da rede. Assim,
há um possível uso da arquitetura Diffserv (outras variações são possíveis, como descreve o RFC 2475).
 
A arquitetura Diffserv consiste em dois conjuntos de elementos funcionais que falaremos a seguir.
Funções de borda: classificação de pacotes e condicionamento de tráfego
Na borda de entrada da rede (isto é, em um host habilitado para Diffserv que gera o tráfego ou, no primeiro
roteador habilitado para Diffserv, pelo qual o tráfego passa), os pacotes que chegam são marcados. Mais
especificamente, o campo Differentiated Service (DS) do cabeçalho do pacote IPv4 ou IPv6 é definido para
algum valor [RFC 3260].
Differentiated Service 
Campo de cabeçalho que substitui o antigo campo TOS, para dar suporte ao DIFFSERV. 
A definiçăo do campo DS teve por finalidade substituir as definiçöes mais antigas do campo de tipo
de serviço (TOS) do IPv4 e os campos de classe de tráfego do IPv6.
Veja um exemplo:
 
Na imagem, a seguir, os pacotes que estão sendo enviados de H1 para H3 poderiam ser marcados em R1, ao
passo que os pacotes enviados de H2 para H4 poderiam ser marcados em R2.
 
A marca que um pacote recebe identifica a classe de tráfego à qual ele pertence. Assim, diferentes classes de
tráfego receberão serviços diferenciados dentro do núcleo da rede.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Diffserv: Um exemplo simples
Função central: envio
Quando um pacote marcado com DS chega a um roteador habilitado para Diffserv, ele é repassado até seu
próximo salto, de acordo com o comportamento por salto (PHB – Per Host Behavior) associado à classe do
pacote.
 
O comportamento por salto influencia a maneira pela qual os buffers e a largura de banda de enlace de um
roteador são compartilhados entre as classes de tráfego concorrentes.
PHB – Per Host Behavior
Uma descrição do comportamento de repasse de um nó Diffserv que possa ser observado e
externamente aplicado a um comportamento agregado Diffserv em particular. 
Um dogma crucial da arquitetura Diffserv é que
o comportamento por salto do roteador se
baseará somente nas marcas dos pacotes, isto
é, na classe de tráfego a que o pacote
pertence.
 
Assim, se os pacotes que estão sendo enviados
de H1 para H3 receberem a mesma marca dos
que estão sendo enviados de H2 para H4, os
roteadores da rede tratarão esses pacotes
como um agregado sem distinguir se eles se
originam de H1 ou H2. Por exemplo, R3 não
faria nenhuma distinção entre pacotes de H1 e
H2 ao transmiti-los a R4.
 
Portanto, a arquitetura de serviço diferenciado evita a necessidade de manter o estado do roteador para 
pares origem–destino individuais. E isso é uma consideração importante para atender aos requisitos de
escalabilidade do Diffserv.
Primeiros pacotes classificados
Os pacotes que chegam ao roteador de borda são primeiros classificados. Veja como ocorre esse processo:
Passo 1
O classificador seleciona os pacotes com base nos valores de um ou mais campos de cabeçalho de
pacote (por exemplo, endereço de origem, endereço de destino, porta de origem, porta de destino, e
ID de protocolo) e dirige o pacote à funçāo de marcaçāo apropriada. Como já dissemos, a marca de
um pacote é carregada dentro do campo DS no cabeçalho de pacote (o antigo TOS).
Passo 2
Em alguns casos, um usuário final pode ter concordado em limitar sua taxa de envio de pacotes,
conforme um perfil de tráfego declarado. Esse perfil poderia conter um limite à taxa de pico, bem
como às rajadas do fluxo de pacotes, como visto no mecanismo de Leaky Bucket.
Passo 3
Enquanto o usuário enviar pacotes para a rede de um modo que esteja de acordo com o perfil de
tráfego negociado, os pacotes receberäo stua marca de prioridade e serão trans mitidos ao longo de
sua rota até o destino.
Passo 4
Por outro lado, se o perfil de tráfego for violado, pacotes que estão fora do perfil poderão ser
marcados de modo diferente, ajustados (por exemplo, atrasados de modo que seja observada a
limitação da taxa máxima) ou descartados na borda da rede.
Existe a função de medição que compara o fluxo de entrada de pacotes com o perfil de tráfego negociado. A
decisão de imediatamente remarcar, repassar, atrasar ou descartar um pacote é uma questão de política
determinada pelo administrador da rede e não está especificada na arquitetura Diffserv.
Comportamento por salto (PHB — Per-Hop Behavior)
O segundo componente fundamental da arquitetura Diffserv envolve o comportamento por salto (PHB — per-
hop behavior) realizado pelos roteadores habilitados para Diffserv. O PHB é definido como:
Uma descrição do comportamento de repasse de um nó Diffserv que possa ser observado externamente
aplicado a um comportamento agregado Diffserv em particular.
(RFC 2475)
Explorando essa definição mais a fundo, podemos ver diversas considerações importantes embutidas:
Um PHB pode resultar no recebimento de diferentes desempenhos por diferentes classes de tráfego
(isto é, comportamentos de repasse diferentes que possam ser observados externamente).
 
Embora um PHB defina diferenças de desempenho (comportamento) entre classes, ele não determina
nenhum mecanismo específico para conseguir esses comportamentos.
 
As diferenças de comportamento devem ser observáveis e, por conseguinte, mensuráveis.
 
Desde que os critérios de desempenho observados externamente sejam cumpridos, quaisquer mecanismos
de execução e quaisquer políticas de alocação de buffer/largura de banda podem ser usados.
 
Por exemplo, um PHB não exigiria que fosse utilizada uma disciplina de enfileiramento de pacotes em
particular (como um enfileiramento prioritário versus um enfileiramento WFQ versus um enfileiramento FCFS)
para atingir determinado comportamento.
 
O PHB é o fim para o qual os mecanismos de alocação e implementação de recursos são os meios.
 
Para o Diffserv foram definidos dois PHBs:
• 
• 
• 
Um PHB de repasse acelerado
Também como conhecido como Expedited Forwarding — EF [RFC 3246], que especifica que a taxa de
partida de uma classe de tráfego de um roteador deve ser igual ou maior do que uma taxa
configurada.
Um PHB de repasse assegurado
Também conhecido como Assured Forwarding — AF [RFC 2597], que divide o tráfego em quatro
classes e garante, a cada classe AF, o fornecimento de alguma quantidade mínima de largura de
banda e de buffer.
A tabela, a seguir, mostra um exemplo do valor do campo DS (TOS) do pacote IP para o PHB de repasse
acelerado [RFC 2745].
DSCP
value
Decimal
value Meaning Drop
probability
Equivalent IP
precedence value
101110 46
Expedited
forwarding (EF)
N/A 101 Critical
Tabela: Exemplo do valor do campo DS (TOS) do pacote IP para o PHB de repasse acelerado [RFC 2745].
Guilherme Dutra Gonzaga Jaime.
Expedited Forwarding (EF) - Tipo de PHB que especifica que a taxa de partida de uma classe de tráfego de
um roteador deve ser igual ou maior do que uma taxa configurada.
Modelo de serviço do Diffserv
Vamos encerrar nossadiscussão do Diffserv com algumas observações wm relação ao seu modelo de serviço:
1
Observação 1
Ele é disponibilizado dentro de um único domínio administrativo.
O caso mais típico é o do serviço fim a fim que tem de ser configurado para vários provedores
localizados entre os sistemas finais comunicantes.
 
Para prover serviço Diffserv fim a fim, todas os provedores entre o sistemas finais devem não
apenas prover esse serviço mas, acima de tudo, cooperar e fazer acordos para oferecer aos clientes
finais um serviço verdadeiramente fim a fim.
 
Sem esse tipo de cooperação, provedores que vendem serviço Diffserv diretamente a clientes terão
sempre de se justificar perante eles dizendo:
 
Sim, sabemos que você pagou um extra, mas não temos um acordo de serviço com os provedores,
que descartaram e adiaram o seu tráfego. Pedimos desculpas pelas muitas lacunas na sua chamada
VolP!
2Observação 2
Se o Diffserv estivesse disponível e a rede trabalhasse apenas sob carga moderada, na maior parte
do tempo, não se perceberia nenhuma diferença entre um serviço de melhor esforço e um serviço
Diffserv.
Na verdade, hoje, o atraso fim a fim em geral é dominado pelas taxas de acesso e saltos de
roteadores e não por atrasos de fila em roteadores.
 
Imagine o infeliz cliente do Diffserv que pagou a mais por um serviço diferenciado, mas descobre
que o serviço de melhor esforço oferecido por outros quase sempre apresenta o mesmo
desempenho!
Verificando o aprendizado
Questão 1
Analise os itens abaixo e, em seguida, faça a relação com suas definições.
 
( ) DIFFSERV.
 
( ) Best Effotr (Melhor Esforço).
 
( ) Isolamento de tráfego entre classes de serviço diferentes.
 
1. É o serviço em que a internet, em sua camada de rede, faz seu melhor esforço para transportar cada
datagrama do remetente ao receptor o mais rapidamente possível, mas não faz nenhuma promessa sequer
sobre a qualidade de serviço (QoS – Quality of Service) a ser alcançada.
 
2. Permite que uma classe de alta prioridade (como o VoIP) não consuma toda a banda, impedindo uma classe
de menor prioridade (como o e-mail) sofra de inanição (seus pacotes nunca são servidos das filas dos
roteadores).
 
3. Representa o serviço padrão da Internet que dá suporte à implementação de múltiplas classes de serviço.
 
A sequência correta é:
A 3 −2 −1
B 1 – 2 - 3
C 3 − 1 −2
D 2 – 3 - 1
A alternativa C está correta.
Isso se justifica porque o DIFFSERV representa o serviço padrão da Internet que dá suporte à
implementação de múltiplas classes de serviço (3), o Best Effort (Melhor Esforço) é o serviço em que a
internet faz seu melhor esforço para transportar cada datagrama do remetente ao receptor sem prometer
qualidade de serviço (QoS) (1), e o isolamento de tráfego entre classes de serviço diferentes permite que
uma classe de alta prioridade não consuma toda a banda, impedindo que uma classe de menor prioridade
sofra de inanição (2).
3. Conclusão
Considerações finais
Neste conteúdo, revisamos a arquitetura de redes TCP/IP, um requisito essencial para o gerenciamento e
análise de redes de computadores. Exploramos as motivações por trás desse gerenciamento e análise,
utilizando analogias e cenários próximos ao real para enriquecer a discussão. Além disso, abordamos os
conceitos gerais de monitoramento e medição de tráfego, fundamentais para entender o funcionamento das
redes.
 
Discutimos as limitações relativas à qualidade de serviço na camada de rede da internet, identificando os
desafios que impactam o desempenho e a eficiência das redes. Apresentamos possíveis soluções para mitigar
essas limitações, incluindo o método padrão de implementação de classes de serviço na Internet, que visa
melhorar a qualidade de serviço.
 
Este conteúdo é crucial para quem deseja aprofundar seus conhecimentos em redes de computadores,
oferecendo uma visão abrangente e prática dos principais conceitos e desafios enfrentados na área. Ao final,
você estará mais preparado para lidar com as complexidades do gerenciamento e análise de redes, aplicando
soluções eficazes para garantir um desempenho otimizado e uma melhor qualidade de serviço.
Explore +
Acesse o site do Wikipedia.org e leia o artigo DiffServ.
Referências
KUROSE, J. e ROS, K.; Redes de Computadores e a Internet. 6. ed. Nova Jersey: Pearson, 2013.
 
RFCs: 1028, 3410, 2578, 2579, 2580, 4293, 4133, 4022, 4502.
 
TANEMBAUM, Wetherall. Redes de Computadores. 5ª edição. Editora Pearson, 2011.
	Fundamentos de gerência de redes de computadores
	1. Itens iniciais
	Propósito
	Objetivos
	Introdução
	1. Fundamentos e troubleshooting de redes de computadores
	A eficiente organização em camadas
	Atenção
	Modelo TCP / IP
	Atenção
	Nível físico ou camada física
	Codificação de dados
	Conexão do meio físico
	Técnica de transmissão
	Transmissão no meio físico
	Obstáculos
	Conteúdo interativo
	Contorno dos obstáculos
	Roteamento
	Controle de congestionamento
	Estabelecimento / fechamento de conexão
	Fragmentação
	Contabilidade de uso da rede
	Infraestrutura de comunicação
	Exemplo
	Camada de transporte
	Segmentação de mensagens
	Entrega confiável
	Controle de tráfego de mensagens
	Multiplexações de sessões
	Camada de aplicação
	Principais protocolos de domínio público do modelo TCP/IP
	Conteúdo interativo
	Motivação para o gerenciamento e análise de redes
	Comentário
	Conteúdo interativo
	Cenários de monitoração
	Detecção de falha em uma placa de interface em um servidor ou roteador
	Monitoração dos hosts
	Monitoração de tráfego para auxiliar o oferecimento de recursos
	Detecção de mudanças rápidas nas tabelas de roteamento
	Monitoração de SLAs
	Detecção de invasão
	Conceitos gerais de monitoramento e medição de tráfego
	Vazão (throughput)
	Atraso em uma direção (one-way delay)
	Atraso de ida e volta (RTT - Round Trip Time)
	Variação do atraso (Jitter)
	Fração de perda de pacotes (Packet Loss Ratio)
	Tamanho das filas (Queue size)
	Taxa de colisão (Collision Rate)
	Carga/Utilização da rede
	Percentual de tráfego por protocolo
	Verificando o aprendizado
	2. Qualidade de Serviço (QoS)
	O que é Qualidade de Serviço?
	Diferentes requisitos quanto à QoS
	Exemplo de VoIP
	Motivação para a implantação de QoS em redes IP
	Bufferização de dados no cliente
	FEC (Forward Error Correction)
	Mecanismos para dar suporte à entrega de conteúdo de multimídia
	Obtendo o melhor do serviço de melhor esforço
	Serviço diferenciado
	Garantias de qualidade de serviço (QoS) por conexão
	Dimensionando Redes de Melhor Esforço
	Provisão e Dimensionamento
	Provisão de largura de banda
	Dimensionamento de redes
	Modelos de demanda de tráfego entre as extremidades da rede
	Requisitos de desempenho bem definidos
	Modelos para prever o desempenho de fim a fim
	Aspectos organizacionais
	Aspecto econômico
	Múltiplas classes de serviço
	Serviço diferencial entre agregações de tráfego
	O campo Tipo de Serviço (ToS)
	Conteúdo interativo
	Princípios dos mecanismos necessários para oferecer múltiplas classes de tráfego
	Primeiro princípio do fornecimento de múltiplas classes de serviço
	Segundo princípio do fornecimento de múltiplas classes de serviço
	Leaky Bucket (Balde Furado)
	Conteúdo interativo
	Diffserv
	Funções de borda: classificação de pacotes e condicionamento de tráfego
	Conteúdo interativo
	Função central: envio
	Primeiros pacotes classificados
	Passo 1
	Passo 2
	Passo 3
	Passo 4
	Comportamento por salto (PHB — Per-Hop Behavior)
	Um PHB de repasse acelerado
	Um PHB de repasse assegurado
	Modelo de serviço do Diffserv
	Observação 1
	Observação 2
	Verificando o aprendizado
	3. Conclusão
	Considerações finais
	Explore +
	Referências