Qualidade de Serviço e Desempenho

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Aplicar um método de diagnóstico de lentidão: delimitar o sintoma, medir por etapas (resolução de nomes, ligação, primeira resposta, transferência), comparar com uma referência e confirmar a causa antes de corrigir.
• Usar curl --write-out, ping, mtr, iperf3 e os contadores do tc para separar lentidão do servidor, perda na ligação e limitação de débito.
• Escrever um relatório de incidente de desempenho com evidências, causa provável, correcção, verificação e limites das medições.

«Está lento» não é um diagnóstico

Primeiro delimita-se: que serviço, que utilizadores, desde quando, sempre ou a certas horas, e comparado com quê. Depois divide-se o tempo de um pedido em etapas. O curl mostra, com --write-out, o tempo de resolução do nome (time_namelookup), de ligação TCP (time_connect), até ao primeiro byte da resposta (time_starttransfer) e total (time_total), e a velocidade média de transferência. Os tempos do curl são acumulados desde o início do pedido.

Leitura típica: resolução alta aponta para DNS; ligação alta aponta para rede ou servidor sobrecarregado a aceitar ligações; primeiro byte alto com ligação rápida aponta para a aplicação ou o servidor; transferência lenta com primeiro byte rápido aponta para débito, perda ou filas no caminho. São indícios, não provas: cada hipótese confirma-se com outra medição independente (ping e mtr para perda e atraso, iperf3 para débito, contadores do equipamento para descartes).

Confirmar, corrigir, verificar, registar

Mede-se antes de mexer, muda-se uma coisa de cada vez e volta-se a medir com os mesmos parâmetros. Sem uma referência (medição de quando estava normal) não se sabe o que é «lento». Nos equipamentos que a equipa gere, os contadores (por exemplo tc -s qdisc show: sent, dropped, overlimits) mostram se há descartes ou filas; nos equipamentos do operador, pede-se a informação com evidências.

O relatório diz o que foi medido, com que ferramenta e quando; distingue facto medido de hipótese; e indica limites (amostra pequena, horário, simulação). Uma medição feita na rede de prática nunca se apresenta como medição da rede real.

Caso fictício

Na delegação da DPE (fictícia), três pessoas dizem em dias diferentes que «descarregar relatórios do srv está lento». O formador, sem revelar, activa uma de três falhas na rede de prática. As duplas diagnosticam com medições, identificam a causa, pedem a correcção ao formador e verificam. Todos os valores são fictícios.

Prática guiada em rede isolada

Rede de prática fictícia, criada dentro de um computador de prática com o script base (módulo 1, lição 1). Nunca use estes passos na rede de produção nem contra endereços reais. As saídas mostradas são exemplos didácticos, não resultados de uma execução.

Topologia (descrição em texto)

• pc-adm (10.10.10.10) — ligado a r1 pela VLAN 10.
• srv (10.10.20.53) — ligado a r1 pela VLAN 20.
• r1 (encaminhador da sede) — ligado a pc-adm, srv, r2 e isp.
• r2 (encaminhador da delegação) — ligado a r1 e a pc-del (10.20.10.10).
• isp (operador simulado) — ligado a r1 e ao servidor externo 198.51.100.10 (endereço dentro de isp).
• Serviço: servidor web de teste no srv, porto 80, a servir um ficheiro de 1 000 000 bytes em /tmp/dpe-m10/l5.
• Falhas escondidas (só o formador aplica, uma de cada vez, sempre na saída r1-r2, sentido sede → delegação, ou no próprio servidor): A — atraso 20 ms e 3 % de perda (netem); B — limitação a 512 kbit/s (tbf); C — servidor que espera 2 s antes de responder.
• Limite da simulação: cada falha é artificial e isolada; na realidade podem coexistir várias causas.

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Prepare a pasta própria, o ficheiro de teste e o servidor lento (este só é usado na falha C).

   mkdir -p /tmp/dpe-m10/l5
   head -c 1000000 /dev/zero > /tmp/dpe-m10/l5/relatorio.bin
   cat > /tmp/dpe-m10/l5/lento.py <<'EOF'
   import functools, http.server, time
   class H(http.server.SimpleHTTPRequestHandler):
       def do_GET(self):
           time.sleep(2)
           super().do_GET()
   http.server.ThreadingHTTPServer(('10.10.20.53', 80), functools.partial(H, directory='/tmp/dpe-m10/l5')).serve_forever()
   EOF

3. Consola C: servidor web normal (esperar «Serving HTTP»). Meça a referência três vezes e registe.

   C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53 --directory /tmp/dpe-m10/l5
   for i in 1 2 3; do sudo ip netns exec pc-del curl -o /dev/null -s -w 'ligacao=%{time_connect} primeiro_byte=%{time_starttransfer} total=%{time_total} bytes_s=%{speed_download}\n' http://10.10.20.53/relatorio.bin; done

   Saída de exemplo (didáctica):

   ligacao=0.000210 primeiro_byte=0.001310 total=0.004920 bytes_s=203252032
   (três linhas semelhantes; é a referência na rede de prática, não um valor real)

4. Formador (consola própria, sem mostrar): aplica UMA falha. Para C, faz Ctrl+C no servidor normal da consola C e inicia o servidor lento.

   A: sudo ip netns exec r1 tc qdisc add dev r1-r2 root netem delay 20ms loss 3%
   B: sudo ip netns exec r1 tc qdisc add dev r1-r2 root tbf rate 512kbit burst 16kb latency 400ms
   C: sudo ip netns exec srv python3 /tmp/dpe-m10/l5/lento.py

5. Etapa 1 — decompor o pedido com curl (três repetições). Compare com a referência.

   for i in 1 2 3; do sudo ip netns exec pc-del curl -o /dev/null -s -w 'ligacao=%{time_connect} primeiro_byte=%{time_starttransfer} total=%{time_total} bytes_s=%{speed_download}\n' http://10.10.20.53/relatorio.bin; done

   Saída de exemplo (didáctica):

   Falha A: ligacao=0.020400 primeiro_byte=0.041200 total=2.310000 bytes_s=432900
   Falha B: ligacao=0.000300 primeiro_byte=0.001600 total=15.980000 bytes_s=62578
   Falha C: ligacao=0.000220 primeiro_byte=2.003100 total=2.007400 bytes_s=498156

6. Etapa 2 — atraso e perda: ping com amostra suficiente e mtr.

   sudo ip netns exec pc-del ping -c 100 -i 0.1 10.10.20.53 | tail -2
   sudo ip netns exec pc-del mtr -n -r -c 50 10.10.20.53

   Saída de exemplo (didáctica):

   Falha A: 100 transmitted, 97 received, 3% packet loss; rtt avg 20.3 ms; mtr: perda a partir do salto 2 (10.255.0.1) e no destino
   Falha B: 0% packet loss; rtt avg 0.08 ms (sem carga, a limitação não se vê no ping)
   Falha C: 0% packet loss; rtt avg 0.07 ms

7. Etapa 3 — débito no sentido sede → delegação (consola D: servidor iperf3; esperar «Server listening»).

   D: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -R -t 10 | tail -3

   Saída de exemplo (didáctica):

   Falha A: sender … 3.9 Mbits/sec  Retr 212; receiver 3.8 Mbits/sec
   Falha B: sender … 0.50 Mbits/sec  Retr 4; receiver 0.49 Mbits/sec
   Falha C: receiver com o débito da referência (a rede está normal)

8. Etapa 4 — confirmar no equipamento gerido (r1): contadores da fila de saída.

   sudo ip netns exec r1 tc -s qdisc show dev r1-r2

   Saída de exemplo (didáctica):

   Falha A: qdisc netem 8001: root … delay 20ms loss 3% … Sent … (dropped 212 …)
   Falha B: qdisc tbf 8002: root … rate 512Kbit burst 16Kb lat 400ms … (dropped 4, overlimits 1840 …)
   Falha C: qdisc noqueue 0: root (nenhuma fila configurada)

9. Etapa 5 — conclusão e pedido de correcção ao formador (que remove a falha: comandos na reversão). Repita a Etapa 1 para verificar que voltou à referência. Escreva o relatório.

   nano /tmp/dpe-m10/l5/relatorio-incidente.txt

Critérios de sucesso

• Para cada falha, a dupla identifica a etapa anómala no curl e confirma com pelo menos uma medição independente (ping/mtr, iperf3 ou contadores).
• A dupla distingue as três causas: perda na ligação (A), limitação de débito (B), servidor lento (C).
• A dupla verifica após a correcção, com os mesmos comandos, que os tempos voltaram à referência.
• O relatório separa factos medidos de hipóteses e indica que as medições são da rede de prática.

Como desfazer (reversão)

• Falhas A ou B: sudo ip netns exec r1 tc qdisc del dev r1-r2 root
• Falha C: Ctrl+C na consola onde corre lento.py (não usar pkill/killall).
• Ctrl+C nas consolas C e D se algum servidor ainda estiver activo.
• Guardar o relatório fora da VM, se necessário, e depois: rm -r /tmp/dpe-m10/l5 (remove ficheiro de teste, lento.py e relatório).
• Verificar: tc qdisc show dev r1-r2 mostra só «qdisc noqueue»; ip netns pids srv não lista python3 nem iperf3.

Alternativa em papel: tarefas e respostas esperadas

Para cada linha de curl de exemplo (falhas A, B e C), diga que etapa está anómala e qual a hipótese.

A: ligação e primeiro byte cerca de 20–40 ms (atraso) e transferência lenta → atraso e perda na ligação. B: ligação e primeiro byte normais, transferência muito lenta (≈ 62 kB/s ≈ 0,5 Mbit/s) → limitação de débito. C: ligação normal, primeiro byte 2 s, transferência rápida → servidor/aplicação.

Na falha B o ping sem carga era normal. Porque isso não descarta um problema de rede?

O ping sem carga usa muito pouco débito e não enche a fila; uma limitação de débito só se revela com transferências (iperf3, curl) ou com ping durante a carga, e nos contadores (overlimits) do equipamento.

Escreva o relatório de incidente para a falha A.

Sintoma: descargas lentas na delegação. Medições (rede de prática, data/hora): curl total 2,31 s vs referência 0,005 s; ping 100 amostras 3 % perda, RTT 20,3 ms; mtr perda a partir do salto 2; iperf3 -R 3,8 Mbit/s com 212 retransmissões; tc em r1 mostra netem com loss 3 %. Causa: perda e atraso na saída r1-r2 (simulados). Correcção: remoção da fila netem. Verificação: curl voltou à referência. Limites: falha artificial, amostras curtas.

Um colega reinicia o servidor e o encaminhador «para ver se resolve» antes de medir. Que problemas isso cria?

Perdem-se as evidências (contadores, estado), não se sabe qual acção resolveu, pode causar interrupção desnecessária e o problema pode voltar sem explicação. Primeiro mede-se, depois muda-se uma coisa de cada vez.

Verifique o que aprendeu

Questão 1

O curl mostra ligação em 0,2 ms e primeiro byte em 2 s. Onde procurar primeiro?

1. No cabo de rede
2. No servidor ou na aplicação, porque a ligação TCP foi rápida e a espera é pela resposta
3. No DNS
4. Na VLAN

Questão 2

Porque se mede com os mesmos comandos antes e depois da correcção?

1. Para gastar tempo
2. Para comparar de forma justa e provar que a correcção resolveu o problema
3. Porque o curl só funciona assim
4. Para apagar os registos

Em leitura fácil

• Primeiro pergunte: o quê, quem, quando.
• Meça antes de mudar qualquer coisa.
• Divida o pedido em partes: ligar, esperar resposta, receber.
• Confirme a causa com outra medição.
• Mude uma coisa de cada vez e volte a medir.
• Escreva o que mediu e o que ainda é só uma ideia.

Fontes

• curl — manual oficial (opção --write-out) (https://curl.se/docs/manpage.html)
• mtr — página oficial e manual mtr(8) (https://www.bitwizard.nl/mtr/)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• Linux iproute2 — páginas de manual ip(8), ip-netns(8), bridge(8), tc(8) (https://man7.org/linux/man-pages/man8/ip.8.html)
• IETF RFC 2681 — A Round-trip Delay Metric for IPPM (https://www.rfc-editor.org/rfc/rfc2681)
• IETF RFC 7680 — A One-Way Loss Metric for IP Performance Metrics (IPPM) (https://www.rfc-editor.org/rfc/rfc7680)
• IETF RFC 6349 — Framework for TCP Throughput Testing (https://www.rfc-editor.org/rfc/rfc6349)
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)