Compartilhe:

t

[Título do documento] [Subtítulo do documento]

James H. Baxter

Usando análise de pacotes para monitoramento de Qualidade da Experiência Escrito por: James H. Baxter Analista de desempenho/WCNA getpackets/PacketIQ® Inc.

Compartilhe: 2

Sobre o autor

James H Baxter é um analista de desempenho para a getpackets e presidente e CEO da PacketIQ Inc. Com mais de 30 anos de experiência no setor de TI, seu conhecimento técnico inclui eletrônica, radiofrequência, satélite, design de LAN/WAN e voz, gerenciamento de redes, tecnologias de fala, programação em Java/.NET.

Durante a maior parte dos últimos 18 anos, James vem trabalhando especificamente com problemas de desempenho de redes e aplicativos. Ele é analista de rede certificado em Wireshark® (WCNA), membro ativo da IEEE, CMG e ACM e acompanha os avanços da área de inteligência artificial.

Compartilhe: 3

Introdução Neste documento técnico, falarei sobre o que é uma análise de pacotes, algumas das informações úteis que ela oferece e como essas informações podem ser usadas para monitorar a experiência do usuário final de aplicativos.

Análise de pacotes

O setor de TI está cada vez mais reconhecendo e aproveitando o valor e a utilidade de análises de nível de pacote — também chamadas de Inspeção profunda de pacotes ou apenas Análise de pacotes — para identificar de forma rápida e precisa a verdadeira origem e natureza dos problemas de confiabilidade e desempenho de redes e aplicativos.

Uma análise de pacotes envolve "capturar" (fazer uma cópia) e inspecionar os pacotes de rede que trafegam entre os dispositivos Cliente e Servidor. Normalmente, isso é realizado com o uso de uma ferramenta comumente conhecida como "Sniffer", que era o nome de uma das primeiras ferramentas padrão do setor desenvolvidas para essa finalidade.

Mais recentemente, um aplicativo de software de código aberto chamado "Wireshark®" (anteriormente conhecido como "Ethereal") tornou-se a ferramenta líder para análise manual de pacotes. O Wireshark pode ser instalado em uma estação de trabalho ou laptop. Ele utiliza um driver de modo indiscriminado (que captura tudo) com um cartão de interface de rede embutido, o que o torna uma ferramenta muito eficiente. No entanto, essa solução costuma ser usada somente em casos de necessidade. Além disso, ela exige experiência para configurar corretamente o software, realizar as capturas e analisar/interpretar os fluxos de pacotes.

Vários fornecedores oferecem dispositivos especializados para realizar inspeções automatizadas e/ou profundas de pacotes no nível empresarial. Mas a implantação dessas ferramentas pode ser muito cara, especialmente quando são implantadas em vários locais com a expectativa de oferecer uma boa cobertura.

O console SolarWinds® Quality of Experience (QoE), que foi adicionado ao Network Performance Monitor, utiliza-se de uma análise de pacotes para oferecer uma excelente solução de monitoramento dedicado e em tempo integral do desempenho de redes e servidores críticos, bem como de tipos de tráfego e distribuições de volume a um preço acessível.

Os principais fatores que afetam os tempos de resposta do usuário final, ou Qualidade da Experiência, incluem:

• Tempo de processamento do cliente

• Tempo de processamento do servidor

• Atraso no transporte de rede

• Atraso nos ciclos de solicitações/respostas

Os mais significativos desses fatores são atrasos relacionados ao processamento do servidor e da rede.

Tela de captura do Wireshark

Compartilhe: 4

4

O que uma análise de pacotes pode oferecer Além de transportar dados entre clientes e servidores, os protocolos de rede modernos, como o TCP/IP, têm a função de garantir a entrega confiável de pacotes, minimizando a perda de pacotes e mantendo os controles de fluxo de dados em ordem para aperfeiçoar o desempenho da rede — principalmente quando estiverem lidando com redes congestionadas. Ao inspecionar os parâmetros de fluxos de pacotes e protocolos, é possível extrair informações úteis sobre o desempenho da rede.

A análise de pacotes também pode identificar todos os tipos e volumes relativos do tráfego de aplicativos que flui em uma rede com base nos endereços IP de hosts, portas e protocolos em uso.

Ao inspecionar e interpretar os fluxos de dados da rede no nível de pacote, é possível coletar uma grande quantidade de informações relacionadas ao desempenho. As seções a seguir abordam e ilustram algumas das possibilidades mais úteis.

Tempo de resposta da rede O tempo de resposta da rede — também conhecido como latência do caminho da rede — é uma medida do tempo que um pacote precisa para percorrer um caminho de rede desde o emissor até o receptor. Quando ocorrem latências no caminho da rede, o desempenho de aplicativos geralmente é afetado de forma desfavorável.

Causas de tempos de resposta altos da rede Quatro fatores principais que afetam a latência no caminho da rede:

• Atraso de propagação à velocidade da luz • Roteamento/distância geográfica da rede • Atraso de serialização em links da WAN • Atrasos de enfileiramento em dispositivos de rede

Atraso de propagação à velocidade da luz

Os sinais elétricos são transmitidos através do vácuo do espaço à velocidade da luz — aproximadamente 186.000 milhas por segundo, ou 299.792 quilômetros por segundo, ou 671 milhões de milhas por hora, dependendo da sua preferência. Apesar de essa velocidade ser quase inimaginável, ainda é preciso uma quantidade finita de tempo para um sinal elétrico ser transmitido pelas distâncias comuns do nosso ponto de referência.

As quatro principais causas de atraso de transporte no caminho da rede incluem os atrasos de propagação, roteamento, serialização e enfileiramento.

A primeira estimativa quantitativa da velocidade da luz foi feita em 1676 por Ole Christensen Rømer com base em observações de que os tempos da lua Io de Júpiter pareciam ser menores quando a Terra estava mais próxima de Júpiter do que quando ela se afastava dele.

A luz leva 8 minutos e 19 segundos para viajar do Sol até a Terra. -- Wikipédia

Compartilhe: 5

A distância em linha reta entre Nova York e Chicago, por exemplo, é de aproximadamente 1.150 quilômetros — a luz leva cerca de 3,8 milissegundos (ms) para percorrer essa distância.

Todavia, um sinal elétrico leva mais tempo para se propagar por mídia física, tal como cabos de cobre e fibra ótica comumente usados em telecomunicações para conectar um dispositivo ao outro por longas e curtas distâncias. Os sinais elétricos são transmitidos por cobre e fibra a apenas ~66% da velocidade da luz — portanto, um sinal levaria cerca de 5,8 ms para percorrer a distância entre Nova York e Chicago nesse cenário. E, obviamente, quanto maior for a distância entre o emissor e o receptor, maior será o tempo para transmitir os sinais.

Roteamento/distância geográfica da rede

O exemplo de atraso de propagação representado acima é uma distância em linha reta ideal. No mundo real, os sinais roteados entre Nova York e Chicago muito provavelmente passariam por várias centrais de comutação principais em locais não diretamente localizados entre os dois pontos de extremidade. Além disso, o cabeamento entre essas centrais de comutação precisaria estar disposto ao longo de caminhos transigentes junto a estradas de ferros e grandes rodovias e a outros corredores de passagem. O resultado final seria um roteamento físico de "dogleg" que pode acabar sendo muito maior do que o caminho em linha reta ideal.

Essa distância adicional pode contribuir para um tempo de atraso considerável no caminho de rede. Não é incomum ver latências de rede com tempo de ida e volta (RTT - Round Trip Time) (Cliente para Servidor e vice-versa) em cerca de 50-100 ms ou mais em caminhos de rede típicos dos EUA ou Europa/Reino Unido, e muito maior que isso em distâncias transglobais ou hops (saltos) de satélites.

Atraso de serialização em links da WAN

Apesar de o acesso a redes e links de Internet fora e entre os datacenters principais de uma empresa ser normalmente compatível com altas larguras de banda (+600 Mbps) para acomodar a demanda de tráfego, os links da WAN para os centros de distribuição e especialmente para os escritórios filiais podem ser muito menores — variando entre 512 Kbps a 45 ou 100 Mbps.

A velocidades de links mais baixas, uma quantidade de tempo significativa pode ser consumida para "registrar" o número de bits de dados contidos em um pacote de rede típico nessas porções de largura de banda menores de um caminho de rede. Considere o seguinte exemplo:

Um pacote de rede grande pode ter 1.476 bytes

Roteamentos de rede da Level 3 nos EUA – Europa – Reino Unido

Os dados são inseridos bit por bit em links de rede a taxas de velocidade de link. Quanto mais lento o link, mais tempo levará para registrar uma determinada quantidade de dados no link. http://e2e.ti.com/blogs_/b/analogwire/arc

Compartilhe: 6

1.476 x 8 bits / byte = 11.808 bits

Para um escritório filial operado por um T-1 (1.536 Kbps de largura de banda disponível para dados), ele consome:

11.808 bits / 1.536.000 bits/s = 0,00768 ou 7,68 ms Esse é o tempo que leva apenas para "registrar" ou "serializar" os dados do pacote através da interface de WAN e no link (um bit de cada vez, à taxa de velocidade do link) para que os dados possam ser transmitidos para a outra extremidade. O mesmo pacote levaria 23 ms para serializar em um link de 512 Kbps, mas apenas 1,2 ms para serializar em um link de 10 Mbps. Cada vez mais, menos tempo é necessário para links de maior velocidade; portanto, esses atrasos tornam-se relativamente insignificantes para links de alta velocidade.

Obviamente, esses atrasos de serialização contribuem para o atraso geral de rede. Além de usar links de maior velocidade (que se tornam cada vez mais caros), não há muito que possa ser feito para reduzir os efeitos desse tipo de atraso, a não ser usar compactação de dados de pacote, armazenamento em cache e outras técnicas (que são usadas em dispositivos de otimização de WAN) para reduzir a quantidade geral de pacotes necessária para atender a solicitações e/ou entregar dados.

Atrasos de enfileiramento em dispositivos de rede

Pequenos atrasos de processamento e comutação de nós são gerados quando os pacotes atravessam os vários switches e roteadores ao longo do caminho de uma rede. Mas, eles são relativamente insignificantes comparados à quantidade de tempo que os pacotes podem ficar retidos em buffers de roteadores aguardando sua vez de serem transmitidos pelos links da rede, especialmente pelos links de WAN mais lentos.

Esse atraso está estreitamente relacionado ao atraso de serialização descrito na seção anterior. Os pacotes se empilham e aguardam em filas de buffer de transmissão enquanto os pacotes na frente deles na fila são serializados em links da WAN mais lentos (o que pode aumentar quando os links ficam ocupados). Além disso, o tempo de um pacote na fila também pode ser afetado por políticas de Qualidade de Serviço (QoS) que podem estar em vigor para ajudar a garantir que o desempenho da rede seja otimizado para aplicativos críticos.

Talvez seja apropriado desviar um pouco do assunto e abordar os aplicativos sensíveis ao tempo, QoS e as razões para usá-los.

Enfileiramento no buffer de transmissão

Compartilhe: 7

Efeitos da rede sobre aplicativos sensíveis

Alguns aplicativos, como os de voz e videoconferência, são suscetíveis a perda de pacotes, atrasos e "jitter" (variações no tempo de entrega entre pacotes sequenciais).

Perda de pacotes e jitter podem afetar a qualidade geral de uma chamada de voz (causando "gaguez" e estranhos efeitos no tom de voz), enquanto que os altos níveis de atraso geral no caminho podem aumentar os efeitos notáveis de eco e atrasar as interações de quem fala devido a ‘sobreposição de falas’.

Perda de pacotes e altos níveis de atrasos no caminho podem ter efeitos ainda mais graves sobre os sistemas de videoconferência (também conhecida como "telepresença"). Uma perda de pacotes pode causar "pixelamento" e/ou tremores no vídeo, bem como interrupções no áudio. Alta latência de rede pode causar perda de sincronização de lábios, pois os pacotes de voz relativamente pequenos podem ser entregues em um intervalo de tempo diferente daquele para pacotes de conteúdo de voz maiores. Portanto, é importante que os pacotes de voz e vídeo fluam pela rede de forma regular e confiável.

Quando ocorre congestionamento de rede causado por breves picos no volume de tráfego, as políticas de QoS podem ajudar a garantir que os aplicativos sensíveis ao tempo e atraso continuem funcionando como o esperado.

Política de Qualidade de Serviço (QoS)

Os administradores podem configurar políticas de QoS em switches e roteadores para marcar pacotes de diferentes tipos de aplicativos com um "Valor de ponto de código de serviços diferenciados" (DSCP - Differentiated Services Code Point) que identifique sua prioridade relativa. À medida que cada pacote atravessa os dispositivos de rede ao longo de um caminho, eles podem ser tratados de forma diferenciada com base em seus códigos DSCP — isso é chamado de Per-Hop Behavior (PHB).

Quando um link de rede — tipicamente um link de WAN — tornar-se congestionado, os pacotes receberão prioridade com base na classe de códigos de DSCP que foi atribuída a eles. As classes de códigos DSCP de alta prioridade incluem o código Expedited Forwarding (EF) ou Assured Forwarding (AF) que pode ser aplicado a tráfego de voz e multimídia. Outros pacotes menos sensíveis ao tempo (como tráfego de e-mail) são marcados com prioridade inferior e podem permanecer em diferentes filas de transmissão por roteador, por mais tempo, aguardando sua vez de serem enviados. Em casos de congestionamento extremo, alguns pacotes podem ser totalmente ignorados, resultando em perda de pacotes.

Tempo entre pacotes VOIP/RTP e análise de jitter

Classificações de QoS para vários tipos de aplicativos Classe Cisco QoS no Cisco Live 2009 [QoS em switches Cisco]

Filas em buffer de pacotes http://www.h3c.com/portal/Products_Solutions/Technology/QoS/Technology_Introduction/200701/195599_57_0.htm

Compartilhe: 8

8

Quando ocorre um congestionamento de rede, as políticas de QoS ajudam a garantir que os aplicativos sensíveis ao tempo e atraso funcionem da forma esperada e a obter o máximo valor de links de rede dispendiosos. Mas, ao mesmo tempo, essas mesmas políticas podem afetar negativamente o desempenho de aplicativos de menor prioridade — incluindo aplicativos de interação do usuário/transacionais.

Efeitos de atraso de rede

Os efeitos acumulativos de atrasos de propagação, roteamento, serialização e enfileiramento podem resultar em atrasos de rede relativamente grandes entre um cliente e servidor sobre distâncias típicas.

Os protocolos TCP/IP servem para superar esses atrasos em transferências de dados em massa com técnicas do tipo "janelas deslizantes", nas quais os pacotes podem ser enviados e aguardar antes de serem "confirmados", resultando em uma transferência de dados mais eficiente.

Todavia, as interações diretas do usuário com um servidor são desfavoravelmente afetadas por maiores atrasos de rede, e alguns aplicativos podem se tornar "tagarelas". Isso ocorre quando eles usam uma quantidade bastante alta de ciclos de solicitações/respostas para realizar uma tarefa (chamados de "Application Turns" ou apenas "App Turns"). Cada um desses ciclos de solicitações/respostas incorre em atraso de ida e volta da rede — o tempo total para aplicativos altamente "App Turns" em um caminho de alta latência. É importante observar que esse tempo pode aumentar rapidamente.

Por exemplo, o carregamento de uma página da Web razoavelmente complexa que contenha um alto número de imagens e vários arquivos CSS e JavaScript pode resultar em MUITAS solicitações — uma para cada arquivo. Se forem necessários 35 arquivos para carregar uma página em um caminho RTT de 72 milissegundos, o tempo total incorrido apenas para ciclos de solicitações/respostas (App Turns) seria:

35 x 0,075 = 2,625 segundos

Isso seria apenas para atraso de ciclos de solicitações/repostas (App Turns) — aguardando as solicitações e respostas transpassarem o tempo de atraso mínimo de roteamento/propagação de rede. Esse tempo é somado a qualquer tempo de processamento de cliente e servidor e a outros atrasos de transporte da rede (serialização e enfileiramento) incorridos para transmitir os bytes de dados reais. É fácil notar como o carregamento de uma página da Web de alto conteúdo em um caminho de latência razoavelmente alta pode levar vários segundos.

Os aprimoramentos recentes de design e técnicas de otimização de páginas da Web incluem o uso de mais arquivos CSS em vez de gráficos para

Diagrama simplificado que ilustra o enfileiramento de QoS

Os navegadores da Web limitarão o número de downloads (conexões) simultâneos por servidor, da seguinte forma:

Internet Explorer® 7 e anterior: 2 conexões simultâneas por host/IP

Internet Explorer 8 e 9: 6 conexões por host

Internet Explorer 10: 8 conexões por host

Internet Explorer 11: 13 conexões por host

Chrome™ 32: 6 conexões por host

Firefox® 26: 6 conexões por host Consulte: http://www.browserscope.org/?category=network

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html

Compartilhe: 9

formatação de páginas, uma seleção de formatos e tamanhos mais adequados de gráficos e consolidação e compactação de arquivos CSS e JavaScript (via Gzip), de modo que sejam necessárias solicitações menores e em menor número para criar uma página. Além disso, os navegadores da Web atuais podem usar de 6 a 8 conexões simultâneas em um servidor da Web, permitindo concluir várias solicitações em um espaço de tempo relativamente curto. No entanto, nem todos os sites empregam esses aprimoramentos. Muitas empresas estão "amarradas" com navegadores mais antigos ou aplicativos "tagarelas" legados que não podem ou não serão atualizados por algum tempo. Nesse caso, os atrasos de ciclos de solicitações/respostas continuam sendo um fator significativo no desempenho de aplicativos.

Como podemos observar do que foi mencionado anteriormente, o atraso de rede em todas as suas formas é um fator significativo e importante para o desempenho geral de aplicativos, o que certamente justifica um monitoramento de aplicativos de missão crítica.

Medidas de atraso de rede

O atraso de rede em um caminho entre um cliente e um servidor é geralmente medido (por um processo manual) por meio de "Pings" de ICMP. Ele também pode ser observado e medido no nível de pacote a partir do tempo transcorrido entre pacotes específicos usados em uma sequência necessária para estabelecer sessões clientes com um servidor de aplicativos. Algumas informações de base são úteis para entender como isso pode ser realizado.

Handshake de três vias do TCP/IP

Quando um cliente inicia uma sessão com um servidor de aplicativos utilizando TCP/IP, ocorre um "handshake" de três vias (Handshake do TCP) para estabelecer uma conexão em ambas as direções e trocar parâmetros e opções que determinam como os dados deverão ser transferidos e como as condições de erro deverão ser tratadas.

Na primeira etapa desse handshake de três vias, o dispositivo cliente envia ao dispositivo servidor um pacote "SYN" (Sincronização) que contém um Número de Sequência Inicial (ISN) que foi aleatoriamente gerado (para proteção contra certos tipos de ataques de hackers).

O servidor responde com um pacote "SYN, ACK" que contém seu próprio número de sincronização e reconhece a solicitação SYN do cliente. Na última etapa do handshake, o cliente envia um pacote ACK reconhecendo a solicitação de conexão SYN do servidor. Agora, o cliente pode enviar solicitações de aplicativos para o servidor e, na verdade, poderia enviar no 3º pacote (ACK) na sequência.

Pacotes Ping ICMP são usados para medir a latência de RTT, mas também são usados para realizar rastreamentos de rota manipulando o contador de TTL para obter informações de cada hop no caminho.

Handshake de três vias do TCP

Compartilhe: 10

Durante esse handshake, o cliente pode indicar sua capacidade de oferecer suporte a dois recursos de TCP — Selective Acknowledgement (SACK, Reconhecimento seletivo) e Window Scaling (Escala de janela) — em seu pacote SYN inicial. Se o servidor também oferecer suporte a esses recursos, isso será indicado em seu pacote de retorno SYN, ACK. Se essas opções não forem suportadas por ambas as extremidades da sessão, elas não poderão ser utilizadas. Consulte RFC 2018

O recurso Selective Acknowledgement permite que um dispositivo indique especificamente um intervalo de bytes que estiver faltando devido a perda de pacote e, por associação, quais bytes ele pode ter recebido desde que o pacote foi perdido. Isso permite que o remetente retransmita os pacotes de dados ausentes em vez de interromper o processo até que ele receba o(s) pacote(s) perdido(s), exigindo assim que todos os pacotes subsequentes também sejam enviados.

O recurso Window Scaling é um método para indicar que o buffer de recebimento de um dispositivo pode ser maior do que o máximo de 65.535 bytes que pode ser reportado pelo campo de tamanho de janela, que tem dois bytes, nos cabeçalhos TCP. Esse valor máximo é indicado por um valor multiplicador que deve ser aplicado aos valores de campo de tamanho de janela reportados.

Os recursos SACK e Window Scaling podem melhorar de forma significativa a eficiência de transporte de dados, são suportados pelos mais recentes sistemas operacionais e podem ser verificados por uma inspeção dos pacotes de handshake de cada sessão.

Medindo atraso de rede de um handshake de três vias do TCP

A partir da extremidade cliente do caminho de rede, medindo o tempo que transcorre entre o pacote SYN inicial do cliente e o pacote de resposta SYN, ACK do servidor, temos uma reflexão precisa de RTT (tempo de ida e volta) entre o cliente e o servidor.

Se o ponto de observação/captura estiver na extremidade servidor do caminho da rede, o tempo entre o pacote SYN, ACK do servidor e o pacote ACK do cliente refletirá o tempo RTT da rede.

Finalmente, se o ponto de observação estiver em algum lugar no meio desse caminho, o RTT da rede será refletido como o tempo entre o pacote SYN inicial do cliente e o pacote ACK final do cliente (3o pacote do handshake de três vias).

Sobre números SEQ e ACK e retransmissões

Os números de sequência (SEQ) do TCP — juntamente com os números de reconhecimento (ACK) — são utilizados pelos dispositivos conectados em rede para controlar a quantidade de dados que foi transmitida e recebida. Além disso, eles controlam se algum pacote de dados foi perdido e quais precisam ser retransmitidos. Eles também determinam a ordem correta para reorganizar os pacotes caso eles cheguem fora de ordem.

Campos de pacote TCP SYN:

• Número de sequência • Window scaling

(Escala de janela) • Opção TCP SACK

Medida de tempo de ida e volta (RTT - Round Trip Time) da rede no lado cliente

Um analisador de pacotes mostraria o pacote SYN saindo do cliente e, 10 ms depois, mostraria o pacote SYN, ACK chegando do servidor.

Compartilhe: 11

Toda vez que um dispositivo transmite um pacote de dados, ele define o número de sequência como um valor que indica o número total de bytes já enviado antes desse pacote. Em seguida, o dispositivo destinatário indica que recebeu esse pacote mais recente enviando um pacote ACK de volta para o remetente com um número de reconhecimento que reflete o número de bytes que ele recebeu até o momento. Por sua vez, isso indica o número de sequência que ele espera ver no próximo pacote do remetente. Se algum pacote em uma série for perdido, o destinatário poderá identificá-lo. Isso é realizado enviando-se um pacote ACK de volta para o remetente com o número de reconhecimento do último pacote completo recebido. Como você deve se lembrar, esse número indica o número de sequência do próximo pacote esperado. Depois disso, o remetente retransmitirá o pacote que estiver faltando.

Não é incomum que um pequeno número de pacotes seja perdido durante uma sessão Cliente/Servidor. O tempo necessário para retransmissão dos pacotes perdidos não é significativo nem perceptível para o usuário final. Todavia, níveis mais altos de perda de pacotes devido a congestionamento de rede ou falhas de dispositivos em rede podem causar um efeito prejudicial e perceptível no desempenho, especialmente quando os algoritmos de recuo do TCP entram em ação e reduzem o desempenho (para acomodar congestionamento de rede), além dos processos de recuperação de pacotes.

Você pode ler as RFCs (Request For Comments - Solicitação para comentários) 793, 1122, 1323, 2018 e 5681 para obter o cenário completo de como o TCP lida com pacotes perdidos e retransmissões, congestionamento e controle de fluxo. Você também obterá uma descrição de como o TCP otimiza o desempenho em links de latência mais alta.

Tempo de processamento do servidor

A maioria dos aplicativos clientes interativos utiliza uma caixa de diálogo de solicitação/resposta com um servidor, com a expectativa de que o servidor responda à maioria das solicitações em tempo hábil — no máximo até 2 segundos.

Os aplicativos baseados em cliente/servidor podem ser hospedados em servidores da Web que contam com um ou mais servidores lógicos de aplicativos e/ou de banco de dados back-end. Esses servidores consultam os servidores back-end para obter dados, processar os dados e criar e entregar a resposta ao cliente. Isso pode levar mais tempo do que o esperado quando as solicitações são particularmente complexas, a carga do servidor é alta ou as consultas de banco de dados ou o design do aplicativo são ineficientes.

Uma medida de RTT no lado servidor no mesmo caminho marcaria o momento de saída do pacote SYN, ACK e o pacote ACK do cliente chegando 10 ms mais tarde.

Progressão de números SEQ e ACK com diferentes tamanhos de janelas

--Wendel l Odom

Compartilhe: 12

Tratando-se de atrasos de rede, os tempos de processamento do servidor podem ser um fator significativo nos tempos de resposta de aplicativos abaixo do nível esperado. Mas como determinar rapidamente qual é o fator? A resposta é monitorar ambos continuamente.

Medindo o tempo de processamento do servidor O tempo de processamento do servidor pode ser medido no nível de pacote observando-se um conjunto específico de três pacotes.

Quando um cliente faz uma solicitação ao servidor, ele envia um pacote que contém a solicitação e todos os parâmetros que possam ser necessários. Geralmente, o servidor responde imediatamente à solicitação com um pacote ‘ACK’ para informar ao cliente que ele recebeu a solicitação. Depois, um certo tempo é transcorrido (de milissegundos a vários segundos) enquanto o servidor processa a solicitação e prepara a resposta. O próximo pacote que for enviado pelo servidor (ao cliente solicitante) será o primeiro pacote contendo os dados solicitados. O tempo que expira entre o pacote ACK do servidor e o primeiro pacote de entrega de dados (também conhecido como "Tempo até o primeiro byte") é o tempo de processamento do servidor.

Então, repetindo, a sequência é:

1. O cliente envia uma solicitação 2. O servidor reconhece (ACK) imediatamente a solicitação

um certo tempo é transcorrido... 3. O servidor inicia a entrega dos dados solicitados

O tempo de processamento do servidor pode, então, ser medido observando-se o ACK do servidor em relação aos tempos de pacote de entrega dentro dessa sequência.

Tempo de processamento do cliente

Geralmente, os tempos de processamento do cliente não representam um fator contribuinte significativo e nem uma área de risco na análise geral de desempenho de tempo de resposta, mas existem duas exceções que precisam ser mencionadas.

Os aplicativos complexos do lado cliente (compilados ou aplicativos JavaScript) que precisam realizar muito processamento local ao mesmo tempo em que recebem dados de um servidor remoto podem ficar sobrecarregados para atender adequadamente aos dados recebidos. Um número excessivo de outros aplicativos (e-mail, sessões de navegadores da Web, mensagens etc.) em execução em segundo plano e que consomem tempo excessivo do processador (tais como aplicativos de varredura de vírus ou Dropbox), podem saturar a(s) CPU(s) do cliente por longo tempo e afetar

Cliente – Servidor da Web – Servidor de aplicativos – Fluxos de solicitações/ respostas do servidor de bancos de dados

Sequência GET – ACK – RESPONSE. O tempo de processamento do servidor foi de ~1,2 segundos

Compartilhe: 13

a capacidade do cliente de atender adequadamente a outros aplicativos de maior prioridade do usuário.

Quando um cliente fica congestionado, o buffer de recebimento de um determinado aplicativo que estiver recebendo dados poderá ficar cheio. Isso ocorre porque o cliente não pode mover os dados recebidos para fora do buffer e para o aplicativo para serem processados de maneira suficientemente rápida, ou o próprio aplicativo não pode processar os dados na mesma velocidade em que os recebe.

O congestionamento do cliente pode, sem dúvida, afetar o desempenho do aplicativo, e o usuário final pode não perceber que o desempenho precário está sendo causado pelos eventos da sua própria estação de trabalho.

Buffers de recebimento cheios e congestionados não acontecem somente nos clientes. Os servidores também estão suscetíveis a esses mesmos sintomas.

Um congestionamento de dispositivos pode ser detectado em uma análise de nível de pacotes observando-se o dispositivo destinatário afetado enviar um pacote "Zero Window" para o host que está enviando dados, o que instrui esse host a interromper a transmissão até que ele receba um pacote Window Update do dispositivo congestionado que indique que ele agora tem espaço suficiente no buffer para acomodar outro segmento de dados. Enquanto isso, o remetente transmite pacotes periódicos Zero Window Probe ao dispositivo afetado para verificar se ele está pronto para receber novos dados. Esses pacotes Zero Window Probe são enviados em intervalos de tempo que mais ou menos se duplicam (0,5 segundos, 1 segundo, 2 segundos, 4 segundos etc.) até que o congestionamento do dispositivo seja resolvido e ele envie um pacote Window Update ou até que a sessão expire e a conexão caia.

Ao observar um número excessivo de pacotes Zero Window, Zero Window Probe, Zero Window Probe ACKs e Window Update, é prudente investigar os dispositivos afetados.

Análise de distribuição de tráfego

A análise de pacotes também permite categorizar tráfego por tipos com base em endereços IP do servidor de destino, portas usadas e medida dos volumes totais e relativos de tráfego para cada tipo. Isso é útil para identificar os volumes de tráfego que fluem em um link de rede e/ou para servidores/ aplicativos específicos para fins de gerenciamento de capacidade, A análise também pode ser útil para identificar níveis excessivos de tráfego não empresarial (mídia social, navegação na Web externa etc.) que podem precisar ser filtrados ou, de outra forma, eliminados.

Pacotes do ZeroWindow, ZeroWindowProbe, ZeroWindowProbeAck e Window Update

Exemplo de estatísticas de hierarquia de protocolos

Compartilhe: 14

Monitoramento de Qualidade da Experiência

As técnicas de análise de pacotes abordadas nas seções anteriores descreveram várias oportunidades e metodologias para monitorar os fatores mais críticos que podem afetar o desempenho de aplicativos do usuário final e, consequentemente, sua satisfação.

A SolarWinds desenvolveu uma solução chamada Quality of Experience (QoE) que oferece monitoramento e relatórios, em tempo integral, baseados em análise de pacotes de fatores de desempenho críticos. Essa solução está incluída no SolarWinds Network Performance Monitor (NPM).

Compartilhe: 15

O painel do SolarWinds Quality of Experience

O painel do SolarWinds Quality of Experience apresenta um resumo geral de uma variedade de métricas de desempenho de rede e aplicativos para todos os aplicativos configurados que estiverem sendo monitorados pelos coletores da QoE (também conhecido como "sensores").

Dez principais métricas de desempenho de tempo de resposta de aplicativos oferecem notificação rápida dos problemas de desempenho de aplicativos

Compartilhe: 16

Dez principais métricas de desempenho de tempo de resposta de rede oferecem identificação rápida dos problemas de latência na rede

Esse sistema processa e informa as métricas de desempenho derivadas de dados de análise de pacotes coletados dos sensores de captura. Esses sensores de captura podem ser implantados diretamente em servidores de aplicativos ou em dispositivos de coleta dedicados conectados às portas SPAN/Espelhamento de switches de rede. Eles oferecem monitoramento integral dos tempos de resposta da rede e dos aplicativos a uma grande quantidade de aplicativos pré-configurados ou personalizados. Também relatam sobre as taxas de transações gerais e volumes de dados em comparação com várias categorias de agrupamento de tráfego. Um recurso

Compartilhe: 17

importante do painel do QoE é a capacidade de identificar rapidamente as reduções ou alterações no desempenho de aplicativos (antes de os usuários começarem a telefonar para reclamar) e determinar se a alteração foi causada por um aumento de atraso na rede ou desempenho baixo de servidor de aplicativos. Isso responde à pergunta: É a rede ou o aplicativo? Você também pode examinar facilmente como as condições atuais se comparam às tendências históricas verificando os quatro gráficos dos 10 principais fatores (Top 10).

O sistema oferece gráficos dos 10 principais Tempo de resposta de aplicativos, Tempo de resposta de rede, Volume de dados e Transações. O sistema também oferece tabelas compatíveis com análise e comparação de tempos de resposta de rede e aplicativos (Médios e de Pico), e vários carregamentos — Volumes de dados médios e totais e Transações médias/ Nº mínimo e total de transações —para outras métricas de desempenho.

Os gráficos apresentam linhas codificadas por cores para cada aplicativo listado e mostra tendências de valores de amostragem com resolução de 5 minutos. Ao passar o ponteiro do mouse sobre um ponto em uma linha, uma janela de informações é exibida com um carimbo de data/hora, o nome do aplicativo e o valor dos dados daquela amostragem. Um controle deslizante sob o gráfico permite fazer um ajuste do intervalo do quadro visualizável.

Tabela dos 10 principais tempos médios de respostas de aplicativos

A tabela sob cada gráfico lista os aplicativos incluídos na sinopse dos 10 principais, juntamente com os valores Average (Médios) e Peak (de Pico). Os valores médios que excedem um limite definido para desempenho são realçados.

O painel do QoE inclui uma tabela que lista todos os nós monitorados, uma tabela de nós que excedem os limites e uma tabela de estatísticas de aplicativos do Quality of Experience que resume as quatro principais métricas de desempenho: Tempos de respostas de rede, Tempos de resposta de aplicativos, Volumes totais de dados e Nº total de transações por aplicativo.

Compartilhe: 18

Categorias de tráfego

Cada aplicativo monitorado pelo QoE — quer tenha sido selecionado na lista extensa de aplicativos pré-configurados ou seja um aplicativo HTTP personalizado configurado pelo usuário — é identificado como um tipo específico de cada uma das três categorias:

Categoria: Colaboração, Banco de dados, Transferência de arquivos, Jogos, Mensagens, Mensagens instantâneas, Monitoramento de rede, Redes, Proxy, Acesso remoto, Redes sociais, Mídia de streaming, VPN e Serviços da Web.

Nível de risco: Nenhum risco, Risco mínimo, Possível uso impróprio, Vazamentos de dados/Malware, Evita detecção/Desvia de firewalls.

Classificação de produtividade: Tudo social, Maioria social, Empresarial e social, Maioria empresarial, Tudo empresarial.

O console QoE também inclui três gráficos de pizza e tabelas para permitir identificação rápida de volumes relativos e específicos a tráfego. O tráfego é categorizado como Relacionado a empresas x Tráfego social, Tráfego por categoria e Tráfego por nível de risco — o último é especialmente útil para identificar rapidamente algum aumento incomum em tráfego potencialmente mal-intencionado.

Volume de tráfego por nível de risco

Tabelas de limites e estatísticas de aplicativos do QoE

Gráficos de volume de tráfego por classificação e categoria de produtividade

Compartilhe: 19

Painel de aplicativos

Ao clicar em um nome de aplicativo em qualquer uma das tabelas "Top 10" (CIFS, por exemplo) no painel principal do QoE, um painel específico ao aplicativo é aberto com os mesmos quatro gráficos e tabelas "Top 10" (Volume de dados, Transações, Tempos de resposta de aplicativos e Tempos de resposta de rede) referentes a esse aplicativo. Ele também inclui Detalhes do aplicativo (Nome, Categoria, Nível de risco e Classificação de produtividade), uma lista de nós indicando o aplicativo de destino e uma tabela resumida de todos os nós que excedem os limites predefinidos para cada uma das quatro métricas de desempenho.

Ao passar o ponteiro do mouse sobre as linhas em qualquer um desses gráficos, uma janela de informações é exibida com os nós específicos e seus respectivos valores para cada métrica.

Dez principais nós de tempos de resposta de aplicativos CIFS

Compartilhe: 20

Configuração do QoE

A configuração de um ambiente Quality of Experience é tão simples quanto usar um assistente passo a passo para implantar sensores e selecionar opções pré-configuradas ou personalizadas para monitorar aplicativos.

Implantação de sensores de análise de pacotes

Existem duas opções de implantação:

• Sensores de análise de pacotes para redes — usados para monitorar o tráfego de pacotes usando uma porta de SPAN/espelhamento e um sensor dedicado instalado em um servidor Windows

• Sensores de análise de pacotes para servidores — usados para

monitorar o tráfego de pacotes diretamente no seu servidor ou estação de trabalho do Windows

Compartilhe: 21

Para começar a instalar um sensor de análise de pacotes de rede, basta selecionar Add Node (Adicionar nó), selecionar o nó para instalar o agente e adicionar o nó selecionado. Em seguida, você será solicitado a fornecer as credenciais do nó. Depois disso, você poderá implantar o agente.

Gerenciar aplicativos no QoE

A próxima etapa é selecionar os aplicativos cujos tráfegos você analisará.

Você pode escolher um aplicativo pré-configurado na tela Manage QoE Applications (Gerenciar aplicativos no QoE), que oferece uma lista extensa de aplicativos disponíveis e prontos para uso. Uma caixa de pesquisa que aceita texto parcial facilita e agiliza a busca do aplicativo certo.

Compartilhe: 22

Selecionar a opção Create a new HTTP application (Criar um novo aplicativo HTTP) nessa tela permite criar um aplicativo personalizado, monitorado pelo QoE. Isso pode ser feito inserindo-se o nome do aplicativo, uma descrição, selecionando-se algumas opções das três categorias disponíveis para classificar corretamente o aplicativo para fins de relatório e selecionando-se uma string de qualificador e um filtro de URL para instruir o sistema QoE sobre como coletar as métricas de desempenho desejadas para o aplicativo.

Compartilhe: 23

A opção URL Filter (Filtro de URL) permite que você configure o Agente do QoE para identificar seu aplicativo por um nome de host ou uma string de URL.

A opção URL permite especificar um subconjunto ou um caminho/página específico dentre os possíveis caminhos/páginas que possam estar hospedados naquela URL.

Depois de configurar o aplicativo, um ou mais nós que deverão coletar o tráfego desse aplicativo poderão ser selecionados. Ao clicar em Finish (Concluir), a configuração é concluída e o processo de coleta é iniciado.

Resumo A solução SolarWinds Quality of Experience adiciona recursos de análises complexas de nível de pacotes ao sistema Network Performance Monitor (NPM). Isso oferece suporte ao monitoramento integrado de desempenho de rede e aplicativos em toda a empresa.

A integração do QoE à solução NPM permite uma identificação automatizada dos problemas de desempenho, além de incluir o recurso de busca detalhada. Isso permite identificar a verdadeira origem e natureza dos problemas de desempenho, para que eles sejam rapidamente resolvidos — antes de os usuários começarem a telefonar.

E, o melhor de tudo, é que a solução SolarWinds QoE oferece as vantagens das análises profundas e sofisticadas de pacotes a um segmento do mercado que historicamente não dispõe de recursos financeiros para investir em soluções de inspeção de pacotes. Isso ajuda essas empresas a competirem no mesmo nível de outras em mercados onde o desempenho e a confiabilidade de serviços de aplicativos são fatores essenciais de concorrência.

Compartilhe: 24

SolarWinds Network Performance Monitor

Baixe uma avaliação gratuita de 30 dias totalmente funcional do SolarWinds Network Performance Monitor.

• Simplifica a detecção, o diagnóstico e a resolução de problemas de rede antes que as falhas ocorram

• Rastreia tempo de resposta, disponibilidade e tempo de atividade de roteadores, switches e outros dispositivos habilitados para SNMP

• Mostra estatísticas de desempenho em tempo real por meio de mapas de rede navegáveis e dinâmicos

• Inclui painéis, alertas, relatórios e orientações especializadas prontos para uso sobre o que monitorar e como monitorar

• Descobre automaticamente dispositivos de rede habilitados para SNMP e normalmente é implantado em menos de uma hora

Saiba mais

Compartilhe: 25

Sobre a SolarWinds

A SolarWinds (NYSE: SWI) fornece softwares de gerenciamento de TI avançados e acessíveis a clientes de todo o mundo, desde as empresas listadas na Fortune 500 até as de pequeno porte. Em todas as nossas áreas de mercado, nossa abordagem é consistente. Nós nos concentramos exclusivamente em Profissionais de TI e nos esforçamos para eliminar a complexidade que eles foram forçados a aceitar de fornecedores tradicionais de softwares corporativos. A SolarWinds cumpre esse compromisso com uma simplicidade surpreendente através de produtos fáceis de encontrar, comprar, usar e manter, ao mesmo tempo em que permitem lidar com qualquer problema de gerenciamento de TI em qualquer escala. Nossas soluções são criadas com base na nossa conexão estreita com nossa base de usuários que interagem em nossa comunidade online, thwack®, para resolver problemas, compartilhar tecnologia e práticas recomendadas, e participam diretamente do nosso processo de desenvolvimento de produtos. Saiba mais agora em http://www.solarwinds.com/.

Saiba mais

Para obter informações sobre os produtos ou adquirir os produtos SolarWinds, visite solarwinds.com ou fale conosco usando os contatos abaixo:

Américas

Telefone: 866-530-8100

Fax: 512-682-9301

E-mail: vendasbrasil@solarwinds.com

APAC

Tel.: +65 6593 7600

Fax: +65 6593 7601

E-mail: vendasbrasil@solarwinds.com

EMEA

Telefone: +353 21 5002900

Fax: +353 212 380 232

E-mail: vendasbrasil@solarwinds.com

Federal, Revendedor federal

e Vendas de soluções de

integração de sistemas

Telefone: 877-946-3751

Fax: +353 212 380 232

E-mail: federalsales@solarwinds.com

7171 Southwest Parkway, Building 400, Austin, Texas 78735, USA