Projeto de Redes IIIIII

Prévia do material em texto

PROJETO DE REDES I – 
ANÁLISE DE DESEMPENHO DE 
REDE 
AULA 6 
 
 
 
 
 
 
 
 
 
 
 
Prof. Luis José Rohling 
 
 
 
2 
CONVERSA INICIAL 
Após identificar quais são os protocolos que estão sendo trafegados na 
rede e conhecer os mecanismos de operação desses protocolos, possibilitando 
que tenhamos uma estimativa de como será o impacto desses mecanismos de 
comunicação na rede, poderemos, então, finalmente, realizar a análise do 
desempenho da rede, considerando esses parâmetros. 
Dessa forma, nesta aula, faremos a abordagem dos principais protocolos 
utilizados nas redes de dados, cujo mecanismo de operação já estudamos 
anteriormente, realizando a análise de desempenho da rede em relação a esses 
protocolos, detalhando os parâmetros que devem ser avaliados, para a análise 
de desempenho. E, para esse processo de análise, utilizaremos as ferramentas 
de captura e análise de protocolos, que é o Wireshark, e veremos também outras 
ferramentas que nos auxiliam nesse processo. 
Devemos, ainda, considerar que o processo de análise de desempenho 
da rede faz parte do processo de operação e manutenção das redes, 
empregando ferramentas e processos que também são utilizados por essas 
outras tarefas. Assim, para realizar uma análise de desempenho, é necessário 
coletar dados sobre o desempenho da rede comparar os resultados obtidos com 
os parâmetros esperados. Para a definição dos parâmetros esperados é 
necessário o conhecimento dos mecanismos de comunicação empregados 
pelos diversos protocolos que trafegam na rede, bem como a estimativa de 
utilização dela, quanto ao número de usuários e aplicações que estão sendo 
executados e os protocolos de comunicação utilizados por essas aplicações. 
Inclusive, essa base de informações é utilizada para a definição da política de 
segurança, para a implementação das medidas de segurança da rede, de forma 
a bloquear o tráfego que não corresponda com as aplicações que estão 
devidamente autorizadas a trafegar na rede. 
Além dos protocolos da camada de rede e de transporte que estamos 
abordando nos conteúdos, existem os protocolos da camada de aplicação, que 
devem ser analisados com maior profundidade, em função do resultado obtido 
na avaliação de desempenho das camadas inferiores. Assim, por exemplo, ao 
detectar um volume de tráfego acima do esperado para um determinado host, 
tendo como critério inicial de avaliação o endereço de camada de rede, devemos 
analisar quais são as aplicações que estão demandando um maior volume de 
 
 
3 
tráfego, utilizando-se o Wireshark para realizar a análise de protocolos. E um dos 
parâmetros que indicará esse tráfego será a porta de origem ou de destino, caso 
a aplicação esteja utilizando uma das portas conhecidas, no intervalo de 
endereços de portas de 1 a 1024. Caso a porta utilizada pela aplicação esteja 
acima desse intervalo de portas, será necessário realizar uma pesquisa, para 
identificar quais aplicações poderiam estar utilizando a porta identificada, e, 
assim, determinar qual é a aplicação que está comprometendo o desempenho 
da rede. 
TEMA 1 – DESEMPENHO DO PROTOCOLO TCP 
Conforme vimos anteriormente, o protocolo TCP é um dos protocolos 
utilizados na camada de transporte, sendo um protocolo orientado à conexão, e 
que realiza também a multiplexação das aplicações da camada superior e o 
controle de fluxo. 
Figura 1 – Os protocolos e as camadas do modelo TCP/IP 
 
Fonte: Rohling, 2021. 
Para analisar o desempenho do processo TCP, no estabelecimento das 
sessões, devemos analisar as mensagens utilizadas para o processo de 
“handshake” triplo, a partir dos valores contidos no cabeçalho do protocolo TCP, 
no campo de flags, detalhados na figura seguinte. 
 
Acesso à rede 
IP - Internet 
TCP - Transporte 
Aplicação 
 
 
4 
Figura 2 – Os flags do cabeçalho do protocolo TCP 
 
Fonte: Rohling, 2021. 
Para analisar o desempenho do processo de estabelecimento de sessão 
do TCP devemos realizar a filtragem baseada nos flags envolvidos nesse 
processo, que são os flags de SYN e de ACK. 
Para especificar esses flags como critério de filtragem no Wireshark, 
devemos levar em consideração que o campo a ser utilizado é identificado como 
“tcp.flags” para o qual deverá ser fornecido o valor em hexadecimal, referente 
aos flags desejados. Assim, para especificar como critério de filtragem os 
pacotes que contenham o flag de SYN setado, ou seja, com nível lógico 1, tem-
se a combinação binária do campo de Flags mostrada na figura a seguir. 
Figura 3 – O flag de SYN setado 
 
Fonte: Rohling, 2021. 
Número de sequência 
Porta de Origem Porta de Destino 
Número de confirmação 
Tam. Tamanho de janela 
Checksum Ponteiro urgente 
Opções 
Reserv. Flags 
URG ACK PSH RST SYN FIN 
URG ACK PSH RST SYN FIN 
0 0 0 0 1 0 
Valor em Hexadecimal: 0x02 
 
 
5 
Portanto, para analisar a quantidade de pacotes TCP capturada e que 
pertence ao processo de estabelecimento de sessões, que incluem apenas o 
flag de SYN, aplicaremos o filtro “tcp.flags == 0x02”, conforme mostrado na figura 
seguinte. 
Figura 4 – Aplicação do filtro com o flag de SYN setado 
 
Fonte: Rohling, 2021. 
Assim, no exemplo anterior, pudemos verificar que o processo de 
inicialização das sessões TCP representou 1,1% do tráfego total capturado, o 
que pode ser considerado um valor normal. 
 
 
6 
Podemos, ainda, confirmar o critério utilizado, selecionando um dos 
pacotes e expandindo a visualização dos detalhes do protocolo TCP, obtendo-
se a visualização mostrada a seguir. 
Figura 5 – Detalhamento dos flags do TCP 
 
Fonte: Rohling, 2021. 
1.1 O controle de congestionamento 
O processo de controle de fluxo, implementado pelo protocolo TCP, é 
baseado no estabelecimento de uma janela de transmissão, conforme vimos 
anteriormente. Assim, o controle de fluxo é realizado com o envio das 
mensagens de confirmação de recebimento dos segmentos, de acordo com o 
tamanho da janela. E essas mensagens permitem o controle de 
congestionamento, pois, caso ocorra um congestionamento na rede, os pacotes 
transmitidos ficarão armazenados nos buffers dos roteadores, até que os links 
possam transmitir esses pacotes. Dessa forma, o remetente ficará aguardando 
a confirmação do recebimento, antes do envio de mais pacotes, evitando-se 
sobrecarregar ainda mais a rede, e diminuindo o impacto dos 
congestionamentos que eventualmente venham a ocorrer durante a 
transmissão. 
Nesse processo de comunicação, o impacto no desempenho da rede, em 
relação ao mecanismo de controle de fluxo, será o tamanho da janela, pois é 
necessário definir um tamanho de janela que otimize o processo de 
comunicação, mas sem sobrecarregar a rede. Assim, se o tamanho da janela for 
muito elevado, em caso de congestionamento, o servidor ainda enviará muitos 
pacotes, mesmo com a perda de desempenho da rede. E se o tamanho da janela 
 
 
7 
for muito reduzido, teremos uma demora no envio do tráfego, pois o servidor terá 
que aguardar a confirmação do cliente para o envio dos próximos pacotes. 
Assim, um dos parâmetros que pode der utilizado para avaliar o 
desempenho do processo de transmissão é o tamanho de janela, que é um 
parâmetro contido no cabeçalho TCP dos pacotes. A figura a seguir apresenta o 
detalhamento do cabeçalho TCP de um pacote capturado com o Wireshark. 
Figura 6 – O tamanho de janela do TCP 
 
Fonte: Rohling, 2021. 
Além do tamanho de janela, que nesse exemplo é igual a 2049, podemos 
identificar que essa mensagem é a confirmação do encerramento de uma sessão 
TCP, pois os flags de FIN e ACK estão setados. 
 
 
8 
Para analisar o desempenho de todas as conexões é necessário verificar 
qual é o tamanho de janela contido em cada pacote TCP, sendo que esse 
tamanho de janela é proposto inicialmente pelo servidor e pelo cliente, 
considerando-se o maior tamanho possível, em função da sua capacidade de 
recebimento de tráfego.Ou seja, o destinatário dos pacotes é que deverá 
informar ao transmissor qual é o tamanho de janela, em função da perda dos 
pacotes no processo de transmissão. 
Assim, para identificar os valores típicos, a partir de um exemplo de 
captura do tráfego de acesso à WEB, utilizando o protocolo HTTPS, aplicaremos 
o filtro “tcp.flags == 0x02”, que corresponde à ativação do flag de SYN, que 
permite analisar os pacotes que são a solicitação inicial para estabelecimento de 
sessão com o servidor, em que teremos o tamanho de janela informado pelo 
cliente. No exemplo seguinte veremos uma amostra do resultado da aplicação 
do filtro indicado. 
Figura 7 – Filtragem das mensagens de SYN 
 
Fonte: Rohling, 2021. 
 
 
9 
Nesse exemplo está detalhado o pacote enviado pelo cliente, cujo 
endereço IP é o 192.168.15.153, o que caracteriza um cliente na rede interna 
por se tratar de um endereço IPv4 privado, com destino a um servidor externo, 
cujo endereço é o IPv4 público, igual a 186.192.91.9. Podemos também verificar 
que se trata de uma solicitação de estabelecimento de sessão, pois o único flag 
que está ativo é o flag de SYN. E, como era nosso objetivo principal, podemos 
verificar que a janela proposta pelo cliente é igual à 64240 bytes. Este valor é 
um múltiplo de 1460, pois cada pacote IP tem um tamanho máximo de 1500 
bytes, incluindo o cabeçalho do protocolo IPv4, devido ao limite de transporte do 
quadro Ethernet. Descontando 20 bytes do cabeçalho IP, a carga útil de cada 
pacote é de 1480 bytes. Descontando o cabeçalho TCP, também de 20 bytes, 
teremos uma carga útil para o transporte dos segmentos, na pilha TCP/IP/ETH, 
de 1460 bytes. 
Portanto, com um tamanho de janela de 64240, o servidor enviará 44 
segmentos TCP sucessivos, sem confirmação, e, então, parará o envio e 
aguardará a confirmação do recebimento dos dados, pelo cliente. 
Utilizando-se o exemplo anterior, mas aplicando-se o filtro para a resposta 
do servidor, utilizando-se como critério os flags de SYN e ACK, com a expressão, 
“tcp.flags == 0x12”, teremos o resultado mostrado na figura seguinte. 
Figura 8 – Filtragem das mensagens de SYN + ACK 
 
Fonte: Rohling, 2021. 
 
 
10 
No exemplo anterior, o primeiro pacote exibido, com a aplicação do filtro, 
é a resposta do servidor externo 207.198.113.179 para o cliente 192.168.15.153, 
em que podemos verificar que os flags de SYN ACK estão ativos, indicando que 
se trata da resposta do servidor a uma solicitação de sessão do cliente. Nesse 
caso, o servidor está informando que irá operar com um controle de 
congestionamento com uma janela de tamanho igual 29200. Fazendo-se a 
divisão desse valor pelo tamanho dos segmentos TCP, que é de 1460 bytes, 
obteremos como resultado o valor igual a 20, o que significa que o servidor irá 
aguardar o recebimento de um total de 20 pacotes para enviar a confirmação de 
recebimento. 
Caso tenhamos um congestionamento na rede, com a perda de pacotes 
enviados do servidor para o cliente, o cliente enviará novamente a confirmação 
do recebimento dos pacotes da janela anterior, para que o servidor envie 
novamente os pacotes da nova janela. A partir da percepção de que os dados 
foram perdidos, a janela de transmissão é reduzida, de forma que o servidor 
enviará uma quantidade menor de pacotes e aguardará a confirmação do 
recebimento. Esse mecanismo permite o controle de congestionamento, 
evitando que seja necessária a retransmissão de pacotes, o que iria causar um 
aumento do congestionamento. Dessa forma, o próprio mecanismo do protocolo 
TCP já realiza a “análise de desempenho” da rede, diminuindo o tamanho de 
janela em caso de congestionamento, que esteja causando a perda de pacotes, 
e, consequentemente, a retransmissão. 
Porém, caso o congestionamento da rede não leve efetivamente a uma 
perda de pacotes, mas apenas ao atraso em sua entrega, o mecanismo do TCP 
permitirá esse ajuste no processo de transmissão. Isso ocorre porque o servidor 
irá aguardar a confirmação de recebimento dos pacotes enviados, por meio de 
uma mensagem de ACK do cliente, o que ocorrerá após a entrega de todos os 
bytes da janela definida na sessão, forçando o servidor a “aguardar”. Esse tempo 
de espera permitirá, provavelmente, que ocorra a redução no congestionamento. 
TEMA 2 – ANÁLISE DE DESEMPENHO COM O ICMP 
O protocolo ICMP, descrito na RFC 792 (IETF, 1981), conforme vimos 
anteriormente, é um dos protocolos que nos auxiliam no processo de diagnóstico 
do desempenho das redes, utilizando-se as mensagens definidas por esse 
protocolo e que fornecem as informações sobre o processo de roteamento da 
 
 
11 
rede IP. Assim, ao realizar o teste da conectividade, com a utilização das 
mensagens de “Echo Request” e “Echo Reply”, além de validar o acesso a um 
determinado destino, teremos dois valores mostrados nas respostas, que são o 
tempo de propagação da mensagem e o campo TTL, conforme mostrado no 
exemplo a seguir. 
Figura 9 – Teste de ping com o ICMP 
 
Fonte: Rohling, 2021. 
O tempo de propagação, mostrado nas respostas recebidas, é medido a 
partir da diferença entre o tempo decorrido entre o envio e o recebimento de 
cada uma das mensagens enviadas, baseado no relógio do terminal. Como o 
desempenho da rede pode ter uma alteração durante a execução do teste, 
poderemos ter alguma diferença entre as quatro mensagens, sendo mostrado 
também os valores mínimo, máximo e a média calculada. 
Baseado nos valores de tempo poderemos avaliar a “distância” entre o 
terminal utilizado para o teste e o terminal que possui o endereço testado. Como 
existe um tempo de propagação dos pacotes por meio dos links físicos, bem 
como o tempo dispendido pelos roteadores, no processo de roteamento, e 
enfileiramento nas interfaces de entrada e saída dos equipamentos 
>ping 186.192.90.12 
 
Disparando 186.192.90.12 com 32 bytes de dados: 
Resposta de 186.192.90.12: bytes=32 tempo=9ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=7ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=9ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=8ms TTL=248 
 
Estatísticas do Ping para 186.192.90.12: 
 Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 7ms, Máximo = 9ms, Média = 8ms 
 
 
12 
intermediários, temos um tempo de resposta das mensagens ICMP que depende 
da quantidade de roteadores no caminho, bem como do desempenho dos links. 
Além disso, podemos ter a alteração desses tempos, em função da variação da 
taxa de ocupação dos links, o que acarretará aumento das filas nas interfaces 
dos equipamentos. 
2.1 Parametrização do ICMPv4 
Além do “teste padrão”, podemos alterar os parâmetros do teste de ping, 
o que nos permite avaliar o desempenho da rede de forma mais efetiva, sendo 
que os parâmetros que podem ser ajustados no comando de ping, de acordo 
com o protocolo ICMPv4, são mostrados a seguir. 
• -t: executa ping no host especificado até ser parado. Para ver as 
estatísticas e continuar, pressionar Control-Break e para parar, pressionar 
Control-C; 
• -a: resolve os endereços para nomes de host; 
• -n count: define o número de solicitações de eco a serem enviadas; 
• -l size: define o tamanho do buffer de buffer; 
• -f: define o sinalizador “Não Fragmentar” no pacote (somente IPv4); 
• -i TTL: define a vida útil do pacote; 
• -v TOS: define o tipo de Serviço (somente IPv4. Essa configuração foi 
preterida e não afeta o tipo de campo de serviço no Cabeçalho IP); 
• -r count: registra a rota de saltos de contagem (somente IPv4); 
• -s count: carimbo de data/hora para saltos de contagem (somente IPv4); 
• -j host-list: rota de origem flexível em host-list (somente IPv4); 
• -k host-list: rota de origem rígida em host-list (somente IPv4); 
• -w timeout: tempo limite em milissegundos de espera por cada resposta; 
• -R: usa o cabeçalhode roteamento para testar também a rota inversa 
(somente IPv6). Conforme RFC 5095, o uso desse cabeçalho de 
roteamento foi preterido. Alguns sistemas podem remover solicitações de 
eco se esse cabeçalho for usado; 
• -S srcaddr: define o endereço de origem a ser usado; 
• -c compartment: identificador de compartimento de roteamento; 
• -p: executa ping em um endereço de provedor de Virtualização de Rede 
Hyper-V; 
 
 
13 
• -4: força o uso do IPv4; 
• -6: força o uso do IPv6. 
Esses parâmetros podem ser vistos ao executar o comando ping, sem 
nenhum parâmetro adicional, quando teremos a resposta do comando conforme 
mostrada a seguir: 
Uso: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] 
 [-r count] [-s count] [[-j host-list] | [-k host-list]] 
 [-w timeout] [-R] [-S srcaddr] [-c compartment] [-p] 
 [-4] [-6] target_name 
Assim, ao executar o teste de ping, podemos inserir um ou mais desses 
parâmetros, de acordo com o resultado desejado. 
Uma forma mais usual da realização do teste de ping é a execução do 
teste especificando-se o nome do servidor, de modo que seja realizada a 
consulta ao servidor de DNS e enviadas as mensagens de “Echo Request”. Por 
esse motivo, podemos especificar qual será o protocolo empregado, se o IPv4 
ou o IPv6, conforme mostrado na figura seguinte. 
 
 
 
14 
Figura 10 – Especificação da versão do protocolo 
 
Fonte: Rohling, 2021. 
2.2 Analisando o resultado do ICMP 
A figura seguinte apresenta um exemplo da execução do comando de ping 
com a especificação do parâmetro “-l”, que corresponde ao tamanho do pacote 
enviado. Asim, esse parâmetro foi empregado para especificar um tamanho de 
1000 bytes para os pacotes de “Echo Request” a serem enviados para o 
endereço de destino, que é o 8.8.8.8. 
 
>ping uol.com.br -6 
Disparando uol.com.br [2804:49c:3102:401:ffff:ffff:ffff:36] com 32 
bytes de dados: 
Resposta de 2804:49c:3102:401:ffff:ffff:ffff:36: tempo=10ms 
Resposta de 2804:49c:3102:401:ffff:ffff:ffff:36: tempo=10ms 
Resposta de 2804:49c:3102:401:ffff:ffff:ffff:36: tempo=8ms 
Resposta de 2804:49c:3102:401:ffff:ffff:ffff:36: tempo=8ms 
 
Estatísticas do Ping para 2804:49c:3102:401:ffff:ffff:ffff:36: 
 Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 8ms, Máximo = 10ms, Média = 9ms 
 
 
>ping uol.com.br -4 
 
Disparando uol.com.br [200.147.3.157] com 32 bytes de dados: 
Resposta de 200.147.3.157: bytes=32 tempo=8ms TTL=248 
Resposta de 200.147.3.157: bytes=32 tempo=8ms TTL=248 
Resposta de 200.147.3.157: bytes=32 tempo=9ms TTL=248 
Resposta de 200.147.3.157: bytes=32 tempo=8ms TTL=248 
 
Estatísticas do Ping para 200.147.3.157: 
 Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 8ms, Máximo = 9ms, Média = 8ms 
 
 
15 
Figura 11 – Ping com o parâmetro “-l” 
 
Fonte: Rohling, 2021. 
Neste exemplo podemos observar que, mesmo tendo sido alterado o 
tamanho do pacote enviado, para 1000 bytes, as respostas recebidas do 
servidor, que são as mensagens de “Echo Reply”, contêm este parâmetro 
novamente alterado, para um tamanho de pacote de 68 bytes. 
Um dos testes para a análise de desempenho das redes é o envio dos 
pacotes com o tamanho máximo do pacote IP, que é de 1500 bytes, e com o 
parâmetro “-t”, para que as mensagens sejam enviadas de maneira contínua. E 
esse tipo de teste pode ser utilizado quando for necessário avaliar, por exemplo, 
uma detecção de lentidão na rede reportada pelos usuários, ou para a verificação 
de um possível congestionamento na rede. Assim, caso haja a perda dos 
pacotes de “Echo”, que irão ser enviados de maneira contínua, poderemos 
constatar se realmente existe um congestionamento na rede, que estaria 
causando a perda de pacotes. 
O exemplo seguinte mostra o resultado da execução de um ping com os 
parâmetros “-l 1000” e “-t”, em que é mostrado o resultado final do envio de 78 
pacotes, nos quais podemos observar que o tempo-resposta variou de 8 ms a 
21 ms, com uma média igual a 9 ms, não ocorrendo nenhuma perda de pacotes. 
 
>ping 8.8.8.8 -l 1000 
 
Disparando 8.8.8.8 com 1000 bytes de dados: 
Resposta de 8.8.8.8: bytes=68 (enviado 1000) tempo=10ms TTL=116 
Resposta de 8.8.8.8: bytes=68 (enviado 1000) tempo=10ms TTL=116 
Resposta de 8.8.8.8: bytes=68 (enviado 1000) tempo=9ms TTL=116 
Resposta de 8.8.8.8: bytes=68 (enviado 1000) tempo=10ms TTL=116 
 
Estatísticas do Ping para 8.8.8.8: 
 Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 9ms, Máximo = 10ms, Média = 9ms 
 
 
16 
Figura 12 – Resultado do ping com o parâmetro “-t” 
 
Fonte: Rohling, 2021. 
Porém, para realizar a análise mais efetiva, de um eventual 
congestionamento da rede, é necessária a execução do teste por um período 
muito maior, chegando a milhares de pacotes enviados, para obter a estatística 
mais confiável. 
Para utilizar o teste de ping, para análise do desempenho da rede, é 
necessário acompanhar o resultado das respostas visualizando a tela do 
terminal, o que nem sempre representa uma solução prática. Assim, para uma 
análise mais eficiente, uma das soluções é a utilização de ferramentas 
específicas de monitoração de tráfego, que apresentam o resultado em forma de 
gráficos, que podem ser visualizados em um painel de gerenciamento da rede. 
Inclusive, essas ferramentas possibilitam a geração de avisos e alarmes, quando 
os valores predefinidos de alguns dos parâmetros monitorados são atingidos. 
TEMA 3 – PROTOCOLOS DE GERENCIAMENTO 
Para automatizar o processo de análise de desempenho das redes é 
necessário utilizar ferramentas de gerenciamento, que irão coletar os dados e 
disponibilizar os valores de forma gráfica, também permitindo a análise 
estatística desses dados, bem como possibilitar a geração de alarmes, a partir 
dos valores coletados. E esse processo de análise de desempenho e de 
gerenciamento irá ocorrer em tempo real, permitindo que a equipe de 
manutenção e operação da rede possa atuar imediatamente, em caso de uma 
falha ou de uma queda significativa do desempenho da rede. 
Para a operação dessas ferramentas há alguns protocolos de 
gerenciamento, sendo que os protocolos mais usuais são o Syslog, definido na 
RFC 5424 (IETF, 2009) e o SNMP, definido na RFC 1157 (IETF, 1990), que 
Estatísticas do Ping para 8.8.8.8: 
 Pacotes: Enviados = 78, Recebidos = 78, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 8ms, Máximo = 21ms, Média = 9ms 
 
 
17 
normalmente são suportados por todas as soluções de gerenciamento das 
redes, bem como pelos dispositivos intermediários de rede e pelos dispositivos 
terminais, tais como os servidores. O protocolo Syslog é amplamente utilizado 
pelos dispositivos gerenciados de redes, tais como switches e access points 
gerenciáveis, bem como pelos roteadores, para a geração de mensagens de 
alarmes. Portanto, apesar de ter como foco a geração de alarmes de falhas, as 
mensagens de Syslog podem colaborar para o processo de análise de 
desempenho da rede, em função do nível de alarme gerado, que pode ser 
ajustado para sinalizar possíveis falhas de desempenho da rede. 
O protocolo que certamente irá permitir uma coleta de dados da rede para 
realizar a análise de desempenho mais detalhada da rede é o protocolo SNMP, 
pois ele suporta um envio e recebimento de mensagens entre o sistema de 
gerenciamento e os dispositivos de rede, com praticamente todos os dados dos 
dispositivos de rede. O protocolo SNMP também é empregado para o 
gerenciamento dos servidores, pois possibilita a coleta de dados relacionados 
ao hardware do equipamento, taiscomo taxa de utilização do processador, 
ocupação de memória e de discos rígidos, incluindo a taxa de dados transmitidos 
por meio das interfaces de rede. E para os dispositivos de rede, é possível ainda 
monitorar o estado dos equipamentos, tal como o dos servidores, mas também 
podemos coletar os dados das interfaces e taxa de ocupação dos buffers das 
interfaces, o que permitirá uma análise de desempenho da rede. 
Assim, no processo de análise de desempenho da rede podemos, em uma 
primeira etapa, avaliar o volume de dados trafegados na rede, com a utilização 
das ferramentas baseadas no protocolo SNMP, e, caso seja identificado um 
desempenho inadequado, tal como uma alta taxa de transmissão de dados em 
uma determinada interface, podemos realizar a análise detalhada desse tráfego, 
com a utilização da ferramenta de captura e análise de protocolos, tal como o 
Wireshark, conforme vimos anteriormente. 
3.1 O Protocolo SYSLOG 
O temo Syslog é empregado para descrever tanto as mensagens quanto 
o próprio protocolo de envio de mensagens, padronizado pelo IETF, na RFC 
3164 de 2001. O protocolo Syslog utiliza a porta UDP 514 para enviar 
mensagens de notificação de eventos para os servidores, que são chamados de 
 
 
18 
collectors, e que recebem e armazenam as mensagens dos eventos 
monitorados, como podemos ver na figura a seguir. 
Figura 13 – Componentes do padrão Syslog 
 
Fonte: Rohling, 2021. 
A padrão do IETF define três elementos para o Syslog, que são o 
Originator, que irá gerar as mensagens de syslog; o Collector, que armazenará 
as mensagens; e o Relay, que recebe as mensagens e as encaminha para os 
servidores ou outro relay. 
Muitos dos dispositivos de rede suportam o protocolo syslog, incluindo os 
roteadores, switches, servidores de aplicativos, firewalls e outros dispositivos de 
rede, enviando as mensagens do sistema, por meio da rede, para os servidores 
Syslog. E para a instalação de um servidor Syslog temos diversas soluções de 
software, para os sistemas operacionais Windows e UNIX, sendo muitos deles 
do tipo software livre, sem custo de licenciamento. 
As mensagens de Syslog contêm, além da identificação de originar a 
mensagem, a indicação de um nível de severidade e de um identificador de 
facilidade. Assim, as mensagens Syslog com menores valores numéricos 
representam os alarmes de syslog mais críticos, de forma que o nível de 
gravidade das mensagens pode ser utilizado para definir como serão exibidas 
as mensagens. Assim, podemos definir a geração de um alarme no painel de 
monitoração da rede apenas para as mensagens mais críticas, e apenas 
armazenando as mensagens que terão um nível de criticidade menor, para 
posterior análise, se necessária. 
E a base de dados, formada pelas mensagens recebidas, incluindo as 
mensagens menos críticas, poderá ser empregada para a análise de 
desempenho da rede. Por exemplo, podemos identificar que em determinado 
Clientes Syslog 
Servidor 
Syslog 
 
 
19 
equipamento de rede estamos tendo a incidência de muitas mensagens de 
configuração, o que poderia prejudicar o desempenho da rede. Assim, essas 
mensagens não seriam utilizadas para o sistema de monitoramento, mas são 
significativas para o processo de análise de desempenho da rede. E os níveis de 
mensagens Syslog que podem ser geradas, de acordo com a RFC 5424, são 
mostradas na tabela seguinte. 
Tabela 1 – Níveis de severidade do Syslog 
Severidade Nível Descrição 
Emergencial Level 0 System Unusable 
Alerta Level 1 Immediate Action Needed 
Crítico Level 2 Critical Condition 
Erro Level 3 Error Condition 
Alarme Level 4 Warning Condition 
Notificação Level 5 Normal, but Significant Condition 
Informação Level 6 Informational Message 
Depuração Level 7 Debugging Message 
Fonte: Rohling, 2021. 
3.2 Configuração do SYSLOG 
Para utilizar o Wireshark para a análise do protocolo Syslog podemos 
aplicar o critério de filtragem para o nível de severidade de mensagens que 
desejamos analisar. E as mensagens de Syslog apresentam uma estrutura de 
campos conforme mostrada a seguir: 
%facility-severity-MNEMONIC: description 
Assim, por exemplo, a mensagem que será gerada pela alteração do 
estado de um link de um switch, cujo evento possui nível de severidade, 
classificado como um erro, será: 
%LINK-3-UPDOWN: Interface Port-channel1, changed state to up 
 
 
20 
Nessa mensagem podemos ainda identificar, no campo de descrição do 
evento, que ocorreu a mudança para o estado ativo da interface do tipo Port-
channel, nesse caso, a interface 1. Dessa forma, se capturarmos também o 
tráfego de Syslog podemos aplicar as expressões de filtro do Wireshark 
utilizando como critério os valores que identificam as facilidades, os níveis de 
severidade, os mnemônicos das mensagens, ou até mesmo as strings de 
descrição. 
Assim, caso haja uma quantidade muito grande de mensagens com a 
descrição “changed state to down”, por exemplo, devemos verificar se essas 
mensagens pertencem às portas de acesso dos hosts ou das portas de conexão 
entre o switchs. Caso tenhamos muitas mensagens desse tipo nas interfaces de 
tronco, devemos verificar a possível causa, pois isso certamente afetará o 
desempenho da rede. 
As quedas de conexão entre switches, além de causar a indisponibilidade 
da conectividade dos hosts, afeta o desempenho da rede, em função da 
operação do processo de encaminhamento do switch, que é baseado em uma 
tabela de endereços MAC. Dessa maneira, quando uma interface passa para o 
estado de “down”, todas as entradas da tabela de endereços MAC dessa 
interface são removidas, fazendo com que o Switch passe a realizar a inundação 
dos quadros para todas as interfaces, mesmo com o retorno da interface para o 
estado de “up”. É necessário, então, que o switch aprenda novamente todos os 
endereços associados à interface que sofreu a queda e foi restabelecida. E 
enquanto esse processo de aprendizagem não for completado novamente, 
temos uma inundação dos quadros, afetando o desempenho da rede. 
Para a configuração dos switches e roteadores Cisco (CISCO, 2021), para 
o envio das mensagens para o servidor Syslog, é necessário definir o endereço 
do servidor e iniciar o processo de envio de mensagens, utilizando os comandos 
mostrados a seguir, sendo mostrada a mensagem de console no roteador 
informando a ativação do serviço. 
Router(config)#logging <ip_address> 
Router(config)#logging on 
Além da configuração anterior, é necessária a configuração para a 
inclusão do valor de tempo e hora em que foi gerada a mensagem, que é o 
campo de timestamp, com o comando mostrado a seguir: 
 
 
21 
Router(config)#service timestamps log datetime 
3.3 O protocolo SNMP 
O protocolo SNMP (Simple Network Management Protocol) permite o 
gerenciamento dos diversos dispositivos de rede e terminais de usuário, 
possibilitando realizar a monitoração do desempenho da rede. O SNMP é um 
protocolo da camada de aplicação, que define as mensagens empregadas no 
processo de comunicação entre os sistemas de gerenciamento e os dispositivos 
gerenciados. O sistema de SNMP é constituído de três elementos, que são o 
gerenciador SNMP, os agentes de SNMP, que são instalados nos nós 
gerenciados, e a base de dados, chamada de MIB – Management Information 
Base, que é armazenada nos dispositivos gerenciados. 
O gerenciador SNMP normalmente é um dos componentes do sistema de 
gerenciamento de rede, chamado de NMS (Network Management System), que 
coleta as informações dos agentes SNMP, que estão sendo executados nos 
equipamentos gerenciados, utilizando o processo de “get”. Além disso, o 
gerenciador poderá realizar a alteração das configurações dos agentes, 
utilizando a ação “set”. Além disso, os agentes SNMP podem enviar as 
informações diretamente para o gerenciador de rede, usando o processo de 
comunicação de “trap”, semelhante ao processo do protocolo Syslog. 
Na figura seguinte podemosobservar o processo de envio de mensagem 
entre o servidor e os agentes SNMP. 
Figura 14 – As mensagens SNMP 
 
Fonte: Rohling, 2021. 
get 
set 
trap 
trap 
Servidor 
SNMP 
Agente SNMP 
Agente SNMP 
 
 
22 
Além do gerenciador SNMP há os agentes SNMP e as MIBs, que ficam 
alocadas nos dispositivos que são os clientes SNMP, sendo que os clientes 
SNMP devem executar um software, com a funcionalidade de agente SMNP. Os 
dados armazenados nas MIBs, que são as informações sobre o dispositivo e as 
estatísticas operacionais, podem ser acessados para que seja realizada a 
análise de desempenho da rede e dos equipamentos. 
Dessa forma, assim como no protocolo Syslog, podemos realizar a 
captura das mensagens do protocolo SNMP, para realizar a sua análise, sendo 
necessário conhecer a operação do protocolo SNMP, cujas mensagens são 
mostradas na tabela a seguir. 
Tabela 2 – As mensagens e as operações do SNMP 
Operação Descrição 
get-request Recupera um valor de uma variável específica. 
get-next-request 
Recupera um valor de uma variável dentro de uma tabela; 
o gerente do SNMP não precisa saber o nome exato da 
variável. Uma pesquisa sequencial é realizada para 
encontrar a variável necessária dentro de uma tabela. 
get-bulk-request 
Recupera grandes blocos de dados, como várias linhas 
em uma tabela, que de outra forma exigiria a transmissão 
de muitos pequenos blocos de dados. (Só funciona com 
SNMPv2 ou posterior.) 
get-response 
Responde a uma solicitação de get-request, get-
next-request e set-request enviadas por um NMS. 
set-request Armazena um valor em uma variável específica. 
Fonte: Rohling, 2021. 
Para realizar a análise de desempenho da rede, podemos buscar os 
valores armazenados nas MIBs dos switches da rede, com o envio de 
mensagens de “get-request” para o equipamento-alvo, especificando o 
parâmetro desejado. A partir das mensagens de “get-response” podemos obter 
os valores necessários para avaliar se os parâmetros estão de acordo com os 
valores esperados, que caracterizam o correto desempenho da rede, como a 
taxa de utilização dos links entre os switches. 
 
 
 
23 
TEMA 4 – FERRAMENTAS DE MONITORAÇÃO 
Na análise de desempenho das redes é possível empregar os dados da 
rede que são coletados pelos sistemas de gerenciamento, que normalmente 
operam no modelo cliente/servidor, em que o servidor é instalado em uma 
máquina Linux, Windows ou até mesmo em uma máquina virtual. E o módulo do 
cliente, que também é chamado de agente, será instalado nos computadores, 
servidores e dispositivos de rede que serão gerenciados. 
Para o processo de coleta de dados, as ferramentas de monitoração e 
gerenciamento podem utilizar os protocolos Syslog ou SNMP, que implementam 
o processo de comunicação entre o servidor central e os agentes, que estão 
instalados nos dispositivos gerenciados. Há diversas plataformas disponíveis no 
mercado, sendo algumas disponibilizadas por meio das licenças de código livre 
e outras no modo licenciado, com custo de aquisição das licenças. Inclusive, 
algumas ferramentas são disponibilizadas para a utilização sem custo de 
aquisição de licença, porém, com recursos limitados, sendo necessária a 
aquisição de uma licença para obtenção de acesso a todos os recursos do 
software. Como exemplo de plataformas de gerenciamento da rede, têm-se o 
Nagios (NAGIOS, 2021), o Zabbix (ZABBIX, 2021) e o PRTG (PAESSLER, 
2021), que veremos adiante, mais detalhadamente. 
Para a escolha de uma das plataformas disponíveis é necessário avaliar 
os diversos aspectos associados a essas soluções, sendo que a primeira 
característica a ser avaliada é o tipo de sistema operacional necessário para a 
instalação da ferramenta, sendo que existem sistemas que são executados em 
ambiente Linux e outros em sistema operacional Windows. Também é 
necessário verificar quais são os protocolos empregados para o processo de 
coleta de dados, garantindo que sejam suportados pelos dispositivos a serem 
gerenciados. Outro recurso dessas plataformas é a disponibilização de relatórios 
e painéis de monitoração, que são também chamados de Dashboards, sendo 
que estes Dashboards normalmente podem ser customizados, de acordo com a 
necessidade de cada empresa. E os relatórios gerados seão a base de dados 
para a análise de desempenho da rede, que devem, preferencialmente, 
disponibilizar essas informações em um formato que possa ser importado para 
a ferramenta de análise de protocolo, tal como o Wireshark. 
 
 
24 
Com a implementação de uma plataforma de gerenciamento, tem-se 
como benefício a possibilidade de implementação de uma monitoração 
centralizada, otimizando a equipe de operação e a manutenção da rede, 
possibilitando a análise de desempenho de toda a rede em tempo real. Inclusive, 
outra funcionalidade de uma plataforma centralizada é a geração de alarmes, a 
partir de determinados eventos ou parâmetros predefinidos, de modo que a 
equipe de manutenção e operação da rede possa atuar imediatamente, em caso 
de uma queda de desempenho significativa da rede. 
4.1 O Nagios 
Entre as diversas plataformas de gerenciamento utilizadas no mercado, 
uma das soluções bastante utilizada é o Nagios, que é uma aplicação executada 
em sistema operacional Linux, CentOS ou RedHat. Há, basicamente, duas 
versões da plataforma de gerenciamento Nagios, sendo uma das versões 
disponibilizadas no modelo de código aberto, do tipo Open Source, que é 
chamada de Nagios Core, e uma versão licenciada, que é o Nagios XI. E, como 
a versão de código aberto é a base para o desenvolvimento da versão licenciada, 
podemos também utilizar o Nagios Core como base para o gerenciamento da 
rede, porém, com algumas limitações. Como o Nagios deve ser executado em 
um sistema Linux, caso seja necessária a instalação em um servidor com 
sistema operacional Windows Server, deve-se fazer a instalação de uma 
máquina virtual. E a distribuição licenciada Nagios XI possuí duas versões, que 
são a Standard Edition e Enterprise Edition, com um conjunto de recursos 
diferenciado. Além dessas distribuições, há ainda o Nagios Network Analyzer, 
que é utilizado para a análise de fluxo dados de rede, e o Nagios Fusion, utilizado 
para a visualização do status operacional da rede. 
 
 
 
25 
igura 15 – O software Nagios 
 
Fonte: Disponível em: <www.nagios.com>. 
Para o processo de monitoração da rede, o Nagios disponibiliza um 
dashboard que permite a visão centralizada e detalhada do status de cada 
dispositivo de rede. Para o processo de gerenciamento e configuração da rede, 
o Nagios ainda possui outras funcionalidades, como a reinicialização automática 
de dispositivos e até mesmo de serviços, facilitando o processo de resolução de 
problemas. 
Para o processo de análise de desempenho da rede, o Nagios permite a 
visualização das tendências dos parâmetros monitorados, o que permitirá a 
realização de um planejamento proativo, identificando os pontos de queda de 
desempenho, inclusive para uma atuação mais efetiva, em tempo real. Além 
disso, com a geração dos relatórios é possível realizar o acompanhamento do 
desempenho da rede, garantindo os níveis de serviço que tenham sido 
acordados com a gestão da empresa, que é chamado de SLA (service-level 
agreement). 
4.2 O Zabbix 
Outra ferramenta utilizada para o gerenciamento das redes é o Zabbix, 
distribuído pela Zabbix LLC no modelo Open Source. E o modelo de operação 
dessa plataforma de gerenciamento é constituído de um Servidor Zabbix, que 
permitirá a monitoração centralizada a partir desse servidor, e os agentes Zabbix, 
que serão instalados nos dispositivos de rede, permitindo a sua monitoração e 
com um baixo consumo de recursos. 
 
 
26 
Quanto à operação do agente Zabbix, têm-se dois modos de operação: o 
modo passivo e o modo ativo, de maneira semelhante à operação do protocolo 
SNMP. Na operação do modo passivo, que é também chamado de“pooling”, o 
servidor envia as requisições para os agentes, com solicitações de informações 
sobre os parâmetros gerenciados. Na operação do modo ativo, que é chamado 
de “trapping”, o agente é quem solicitará ao servidor Zabbix uma lista dos 
parâmetros a serem verificados, que são as chamadas verificações ativas. Esse 
processo de verificações pode ser realizado em intervalos de tempo periódicos 
ou em horários específicos, devendo ser programados de forma a causar o 
menor impacto possível no desempenho da rede. Caso contrário, o processo de 
coleta de dados, para a análise de desempenho da rede, poderá ser a causa da 
queda de desempenho, e não o tráfego real da rede. 
Figura 16 – O software Zabbix 
 
Fonte: Disponível em: <www.zabbix.com>. 
De maneira semelhante às demais soluções de gerenciamento da rede, o 
Zabbix também permite a monitoração das mensagens de log e das notificações 
geradas pelos dispositivos gerenciados. Além disso, a ferramenta permite o 
escalonamento do envio de notificações, em caso de geração de alarmes, de 
acordo com o SLA. Assim, os casos de falha, ou de queda de desempenho, de 
maior criticidade podem gerar uma mensagem informando o nível gerencial da 
empresa, para que possa tomar as medidas necessárias de contingência. Ou 
podem, ainda, realizar o escalonamento técnico, acionando as equipes de 
 
 
27 
manutenção especializadas, de acordo com o nível de criticidade e do 
equipamento que gerou o alarme. 
Para implementação de um processo de comunicação segura entre o 
servidor e os agentes Zabbix, pode ser aplicada a criptografia das mensagens, 
suportando diversos métodos de autenticação. E como o Zabbix é distribuído em 
código aberto, é possível implementar o processo de auditorias de segurança, 
possuindo também as APIs para integração com outras aplicações. Além disso, 
com o recurso do modo de Auto Discovery, o servidor Zabbix pode localizar de 
forma automática todos os agentes que estejam instalados em uma determinada 
rede, o que facilitará o processo de instalação e configuração da ferramenta. 
4.3 O PRTG 
A análise de desempenho das redes é uma tarefa baseada nos valores 
obtidos pela medição de parâmetros da rede, o que certamente será facilitada 
com a utilização de ferramentas de análise gráfica de valores. Assim, as 
ferramentas de gerenciamento de redes que contribuem mais significativamente 
para a análise de desempenho da rede certamente são as ferramentas que 
apresentam esse recurso, e entre elas há o PRTG. O software PRTG é uma 
ferramenta de monitoração de redes, executada em plataforma Windows e 
desenvolvida pela Paessler AG, que realiza a monitoração dos parâmetros da 
rede a partir de gráficos de desempenho. 
Figura 17 – O software PRTG 
 
Fonte: Disponível em: <www.peassler.com>. 
 
 
28 
O PRTG NETWORK MONITOR é disponibilizado em uma versão de teste, 
por 30 dias, inclusive com a possibilidade de escolha do idioma, para ser 
instalada em português. Após o prazo de teste, é necessária a aquisição de uma 
licença permanente de uso para a utilização de todos os recursos, pois a versão 
livre apresenta algumas limitações. Como o PRTG opera baseado em sensores 
e sondas, que são os parâmetros monitorados, uma das limitações da versão 
não licenciada é que o número de sensores é igual à 100, sendo que na versão 
de teste tem quantidade de sensores ilimitada. O PRTG permite a monitoração 
de sistemas, de dispositivos e de aplicativos, suportando o protocolo SNMP, as 
tecnologias Flow, o acesso remoto via SSH, a integração com o WMI, as 
mensagens de Ping e opera com uma base de dados SQL. 
Um dos principais parâmetros monitorado pelo PRTG, para a análise de 
desempenho da rede, é a ocupação da largura de banda das interfaces, cuja 
monitoração é feita em tempo real, sendo disponibilizados os gráficos de 
ocupação com periodicidade diária, semanal, mensal e anual. Dessa forma, 
quando houver uma reclamação de usuários pela rede estar lenta, é possível 
identificar a raiz do problema, pois o PRTG permite determinar quanta largura de 
banda os dispositivos e aplicativos estão usando, podendo ser utilizados 
diferentes protocolos, como o SNMP, e as ferramentas de captura e análise de 
pacotes. A maioria das soluções de análise de largura de banda é capaz de 
verificar apenas o tráfego de internet em um único dispositivo, assim, para medir 
todo o tráfego da rede é necessário monitorar os dados diretamente no roteador. 
Porém, com a utilização dos protocolos SNMP, NetFlow e WMI é possível 
monitorar o uso da largura de banda em todos os demais pontos da rede, pois o 
PRTG coleta os dados sobre o tráfego de todos os dispositivos, permitindo 
identificar quais aplicativos ou quais computadores ou servidores estão 
utilizando maior largura de banda. 
O PRTG também pode enviar as mensagens de alarmes, conforme a 
configuração dos parâmetros monitorados. Assim, já no processo de instalação 
do software, é solicitado o e-mail para o envio das mensagens, conforme 
mostrado na figura a seguir. 
 
 
 
29 
Figura 18 – Configuração do PRTG 
 
Fonte: Rohling, 2021. 
A figura seguinte mostra um exemplo do gráfico gerado pelo PRTG na 
monitoração da interface do computador em que a ferramenta foi instalada. 
Figura 19 – Gráfico gerado pelo PRTG 
 
Fonte: Rohling, 2021. 
 
 
 
30 
TEMA 5 – PARÂMETROS DE REDE 
Um dos principais parâmetros para a análise de despenho das redes é a 
taxa de ocupação dos links, pois uma alta taxa de ocupação das conexões entres 
os equipamentos de redes certamente afeta todas as comunicações que 
trafegam por esses links. Dessa maneira, conforme vimos anteriormente, os 
sistemas de monitoração da rede devem coletar os dados dos links entre os 
switches, e, principalmente, os links com os servidores e com o roteador de 
conexão com internet. Porém, como o tráfego das redes IP tem o perfil de rajada, 
mesmo com uma ocupação normal do link, é possível ter o congestionamento, 
em função de um tráfego de rajada gerado por algum dos hosts conectados à 
rede. Mas como, normalmente, essas rajadas têm um curto período de duração, 
o congestionamento é momentâneo, e, muitas vezes, nem é percebido pelos 
demais usuários. 
Além disso, conforme vimos, o projeto da rede deve ser elaborado tendo 
como base a média estimada do tráfego das aplicações e da quantidade de 
usuários, para o dimensionamento dos links. Mas, em muitos casos, não temos 
a definição de todas as aplicações que são utilizadas, sendo feito esse “ajuste” 
após a implementação da rede, com a medição do tráfego real. 
Sendo assim, as ferramentas de medição do tráfego de rede servem para 
identificar efetivamente qual será a taxa de ocupação dos links, em uma rede 
que já está em operação. Para contemplar as rajadas de tráfego, devemos 
considerar a necessidade de ter uma largura de banda disponível nos links na 
ordem de 20% da largura de banda, para comportar esse tráfego de rajada. 
Porém, o impacto do tráfego na rede depende também de outros fatores, como 
as aplicações utilizadas na rede e a quantidade de hosts conectados, pois a 
análise deve contemplar o estudo estatístico do tráfego de rede. 
5.1 Ocupação da largura de banda 
Para ilustrar o processo de análise de desempenho, a figura a seguir 
mostra o exemplo do tráfego de uma interface de um computador, em que estava 
sendo acessado um servidor de streaming de vídeo, cujo tráfego foi capturado 
com o PRTG, apresentando um tráfego médio de 6 Mbps. No gráfico podemos 
identificar algumas rajadas de tráfego, atingindo o valor de 18 Mbps, sendo que 
as rajadas, apesar de atingirem três vezes o patamar de tráfego médio, 
 
 
31 
representam um valor adicional de 12 Mbps, em apenas uma medida, o que 
representa uma duração de menos de 60 segundos. 
Figura 20 – Rajadas de tráfego - PRTG
 
Fonte: Rohling, 2021. 
No caso do exemplo anterior, ao considerar que se tem um acessoà 
internet de 100 Mbpps, a rajada de tráfego consumiria a largura de banda de 
12% da banda total, ficando dentro da margem de 20%, conforme valor de 
referência visto anteriormente. Dessa forma, a rajada de tráfego não causaria a 
saturação do link de acesso à internet, caso esteja operando com uma ocupação 
de 80%, e não afetaria o tráfego dos demais computadores conectados na rede. 
Ao realizar uma análise estatística desse tráfego, como tivemos quatro 
rajadas de tráfego em um intervalo de captura de mais de 30 minutos, em que 
os valores são contabilizados a cada 60 segundos, tem-se uma relação de quatro 
medidas de rajadas em 30 medidas de tráfego, o que representa 
aproximadamente 13% das medidas. 
Nesse exemplo, devemos ainda considerar que a aplicação utilizada para 
gerar o teste de ocupação da rede foi uma aplicação de streaming de vídeo, que 
é uma das aplicações que mais exigem largura de banda, gerando um impacto 
significativo no desempenho da rede. Porém, ao avaliar o desempenho da rede 
para esse tipo de aplicação, há uma maior garantia de que a rede apresentará 
um melhor desempenho para as demais aplicações, que terão um menor 
impacto no desempenho da rede, quanto à ocupação de largura de banda. 
5.2 Latência da rede e QoS 
Além da taxa de largura de banda, outro parâmetro empregado na análise 
de desempenho das redes é a latência, que é o tempo de propagação dos 
pacotes na rede IP. Para as aplicações chamadas de tempo real, como as 
 
 
32 
tecnologias de VoIP, este parâmetro é essencial para o correto funcionamento 
da aplicação. Assim, para que a qualidade de uma chamada de voz sobre o 
protocolo IP seja considerada aceitável, deve-se ter uma latência máxima de 120 
ms. Para garantir a qualidade dessas aplicações, tem-se a utilização dos 
mecanismos de QoS, que alocam os recursos de rede de acordo com a 
necessidade de cada uma das aplicações. Porém, a configuração dos recursos 
de QoS nos equipamentos de rede, para a alocação dos recursos, deve ser 
avaliada em relação ao impacto das configurações no desempenho da rede para 
as demais aplicações. 
A configuração do QoS pode afetar as demais aplicações, pois quando 
ocorrer o congestionamento da rede, o tráfego que pertence às classes definidas 
pela política de QoS será priorizado, e caso esse tipo de tráfego ocupe todo o 
recurso de rede, podemos ter o descarte de todos os demais pacotes, que 
pertençam às demais aplicações. Porém, como normalmente o tráfego que 
necessita esse tratamento diferenciado não representa uma parcela majoritária 
do tráfego, provavelmente a configuração de QoS não será tão prejudicial aos 
demais tipos de tráfego da rede. 
Uma das técnicas básicas de QoS é a priorização do tráfego nas 
interfaces dos dispositivos de rede, como switches e roteadores. Porém, para 
que a priorização ocorra é necessário que o tráfego seja corretamente 
classificado, no modelo de implementação de QoS chamado de Serviços 
Diferenciados, conhecido pela sigla em inglês DiffServ – Differentiated Services. 
Inclusive, no cabeçalho dos protocolos de rede, no IPv4 e no IPv6, tem-se um 
campo específico para a marcação das classes, identificado como DSCP. A 
partir dessa marcação, os dispositivos de rede que irão implementar o QoS 
podem diferenciar as classes de tráfego, aplicando as regras de tratamento 
diferenciado para cada uma delas. Assim, no processo de análise de 
desempenho da rede, devemos também avaliar os parâmetros para as classes 
de tráfego, de maneira específica, para avaliar se a rede está conseguindo 
atender o nível de serviço necessário para essas classes. 
Concluindo, os parâmetros que devem ser monitorados, para os quais 
devem ser especificados os níveis a serem garantidos, de acordo com as classes 
de tráfego, são a largura de banda, o atraso fim-a-fim, a variação do atraso e a 
perda de pacotes. Para acompanhar o desempenho das redes em relação a 
esses parâmetros, podemos utilizar os próprios protocolos usados pelas 
 
 
33 
aplicações de tempo real, que são o protocolo RTP – Real Time Protocol e o 
RTCP – Real Time Control Protocol. Como o protocolo RTCP gera um relatório 
sobre as sessões abertas, que utilizam o protocolo RTP para o transporte dos 
pacotes de mídia, sobre o protocolo UDP, podemos capturar os pacotes RTCP 
e avaliar os valores contidos nas mensagens do protocolo, com a utilização do 
Wireshark. 
FINALIZANDO 
Para que possamos realizar de forma efetiva o processo de análise de 
despenho da rede é necessário conhecer quais são os protocolos e as 
aplicações que estão trafegando na rede, qual é a dinâmica do processo de 
comunicação das aplicações e protocolos, e utilizar as ferramentas adequadas 
para a coleta de dados da rede, para a captura do tráfego e para a análise do 
tráfego capturado. Assim, conforme vimos nesta disciplina, há diversas 
ferramentas que podem ser utilizadas, entre as quais uma das ferramentas de 
maior destaque é o Wireshark, em conjunto com uma aplicação de monitoração 
da rede, sendo que o PRTG é a ferramenta que irá facilitar o acompanhamento 
do desempenho da rede em tempo real, disponibilizando os dados em um 
formato de gráficos, o que facilita o processo de análise e de acompanhamento 
da variação dos parâmetros da rede. 
Assim, uma parte do processo será automatizada, com as ferramentas de 
gerenciamento da rede, em relação à coleta de dados e apresentação dos 
valores nos painéis de monitoração. Porém, no caso de uma queda significativa 
do desempenho da rede, é necessária a avaliação mais detalhada, o que será 
realizada com a captura e análise dos protocolos. Essa etapa do processo 
demanda, além da utilização das outras ferramentas, o conhecimento dos 
parâmetros dos protocolos, bem como os recursos da ferramenta de análise de 
protocolo, para que seja possível identificar efetivamente a causa da queda do 
desempenho da rede. 
Quando se tem uma saturação de algum link da rede, a ocorrência é 
facilmente percebida pelos painéis de gerenciamento da rede, podendo inclusive 
gerar um alarme, antecipadamente, quando ultrapassar um determinado nível, 
tal como 90% da capacidade do link. 
Outro parâmetro crítico da rede é a latência, sendo que, quando houver a 
alteração no tempo de propagação na rede, teremos um impacto diferente em 
 
 
34 
cada uma das aplicações. Nesse caso, as aplicações que utilizam protocolos 
que implementam o controle de fluxo, como o protocolo TCP, na camada de 
transporte, se “adequarão” a essa alteração da latência da rede. Porém, as 
aplicações de tempo real são diretamente afetadas, sendo que, aqui, a solução 
mais eficiente é a operação dos mecanismos de QoS, pois a solução do 
problema de aumento da latência deve acontecer de forma “automática”. Assim, 
a análise dos pacotes e dos protocolos não é necessária, pois a rede deve se 
ajustar a essa alteração, que provavelmente foi gerada pelas rajadas de tráfego 
normais do protocolo IP. 
Já o último parâmetro que deve ser avaliado é a perda de pacotes, pois 
caso isso ocorra, significa que há um congestionamento na rede e que o espaço 
nos buffers das interfaces também está totalmente ocupado, levando ao 
descarte de pacotes pelos equipamentos intermediários. Porém, como a 
ocupação dos buffers ocorre apenas quando há uma saturação da capacidade 
do link, a ocorrência deve ser detectada pela monitoração da ocupação dos links. 
Assim, é necessária a monitoração da ocupação dos buffers, em conjunto com 
a ocupação do link, podendo-se avaliar se está ocorrendo o descarte de pacotes. 
Com um conjunto adequado de ferramentas e tendo o conhecimento dos 
protocolos trafegados na rede, podemos realizar a análise do desempenho, 
comparando o resultado obtido com o desempenho esperado e projetado para a 
rede, realizando os eventuais ajustes necessários, com a alteração de 
configuração ou até mesmo com a substituição dos equipamentos, para atingir 
osníveis desejados. Esse deve ser um processo contínuo, pois temos uma 
alteração no perfil de uso da rede, bem como a utilização de novas aplicações e 
protocolos, que certamente impactarão no desempenho da rede. 
 
 
 
35 
REFERÊNCIAS 
CISCO. Networking Academy. Disponível em: <https://www.netacad.com/pt-
br>. Acesso em: 2 abr. 2021. 
PRTG Network Monitor. Paessler AG, 2021. Disponível em: 
<https://www.paessler.com/bandwidth_monitoring/>. Acesso em: 2 maio 2021. 
RFC 792 - Internet control message protocol. Internet Engineering Task Force 
– IETF, setembro 1981. Disponível em: 
<https://datatracker.ietf.org/doc/html/rfc792>. Acesso em: 2 maio 2021. 
RFC 1157 - A Simple Network Management Protocol (SNMP). Internet 
Engineering Task Force – IETF, maio 1990. Disponível em: 
<https://datatracker.ietf.org/doc/html/rfc1157>. Acesso em: 2 maio 2021. 
RFC 5424 - The Syslog Protocol. Internet Engineering Task Force – IETF, 
março 2009. Disponível em: <https://datatracker.ietf.org/doc/html/rfc5424>. 
Acesso em: 2 maio 2021. 
THE NAGIOS IT Management Software Suite. Nagios Enterprises. Disponível 
em: <https://www.nagios.com/>. Acesso em: 2 maio 2021. 
ZABBIX Monitor. Zabbix LLC. Disponível em: <https://www.zabbix.com/>. 
Acesso em: 2 maio 2021.