Redes de Longa Distância

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Distinguir rede local e rede de longa distância pelo alcance, pelo proprietário do meio e pelas características da ligação.
• Comparar as tecnologias de ligação mais comuns (fibra, rádio ponto-a-ponto, ligação móvel, satélite, circuito dedicado do operador) por débito, atraso, disponibilidade e custo relativo.
• Medir, numa ligação simulada, como o atraso e a perda alteram a experiência de um serviço.

O que muda quando a ligação sai do edifício

Numa rede local a instituição é dona dos cabos e dos comutadores, as distâncias são curtas e o débito é alto. Numa rede de longa distância (WAN) o meio pertence normalmente a um operador, a distância é grande e cada megabit é pago. O técnico deixa de controlar o caminho: passa a controlar o contrato, os equipamentos das pontas e a forma como o tráfego é enviado.

Quatro medidas descrevem uma ligação WAN: débito (quantos bits por segundo passam), atraso (tempo de ida e volta, RTT), variação do atraso (jitter) e perda de pacotes. Uma ligação pode ter débito alto e mesmo assim ser má para chamadas de voz, se tiver atraso ou jitter elevados.

Tecnologias comuns e compromissos

Fibra óptica do operador: débito alto e atraso baixo, mas depende de a fibra chegar ao local. Rádio ponto-a-ponto: útil entre edifícios com linha de vista; sensível a obstáculos e chuva forte em algumas frequências. Ligação móvel (4G/5G): rápida de instalar, com débito e atraso variáveis consoante a cobertura e a carga da célula. Satélite geoestacionário: chega a zonas remotas, mas o atraso de ida e volta é tipicamente superior a 500 ms por causa da distância ao satélite; constelações de órbita baixa têm atrasos menores. Circuito dedicado ou serviço de rede privada do operador: características garantidas por contrato, custo mais alto.

Não há tecnologia «melhor» em absoluto. Escolhe-se pelo serviço que vai passar, pela disponibilidade no local, pelo orçamento e pela necessidade de alternativa. Os valores concretos de débito, atraso e preço vêm sempre da proposta escrita do operador e de medições no local.

Caso fictício

A Direcção Provincial de Exemplo (DPE, fictícia) vai abrir uma delegação distrital. O operador A oferece ligação móvel (débito anunciado 20 Mbit/s, atraso típico 60 ms); o operador B oferece satélite geoestacionário (10 Mbit/s, atraso típico 600 ms). A delegação usará o sistema de gestão documental na sede e fará videochamadas semanais. 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).
• A ligação r1–r2 (10.255.0.0/30) representa a WAN sede–delegação.
• Simulação: o atraso e a perda são introduzidos com tc netem na interface r2-r1 (só dentro do espaço de nomes r2).

Passos

1. Pré-requisito: confirme que a delegação chega ao srv (rotas do módulo 3).

   sudo ip netns exec pc-del ping -c 3 10.10.20.53

   Saída de exemplo (didáctica):

   3 packets transmitted, 3 received, 0% packet loss
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms

2. Consola C: inicie um serviço web de teste no srv (esperar «Serving HTTP»).

   sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53

3. Meça o tempo de um pedido web sem simulação.

   sudo ip netns exec pc-del python3 -c "import time,urllib.request as u; t=time.time(); u.urlopen('http://10.10.20.53/').read(); print(round((time.time()-t)*1000),'ms')"

   Saída de exemplo (didáctica):

   3 ms

4. Simule a ligação móvel do operador A. O netem só atrasa os pacotes que saem de r2-r1; aplicando 60 ms num só sentido, a ida e volta fica perto de 60 ms.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem delay 60ms 10ms
   sudo ip netns exec pc-del ping -c 5 10.10.20.53

   Saída de exemplo (didáctica):

   rtt min/avg/max/mdev = 51.2/60.4/69.8/6.1 ms

5. Repita o pedido web e anote.

   sudo ip netns exec pc-del python3 -c "import time,urllib.request as u; t=time.time(); u.urlopen('http://10.10.20.53/').read(); print(round((time.time()-t)*1000),'ms')"

   Saída de exemplo (didáctica):

   125 ms (cerca de duas idas e voltas: estabelecer a ligação TCP e o pedido)

6. Simule o satélite do operador B (600 ms) e repita as duas medições.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 600ms 20ms
   sudo ip netns exec pc-del ping -c 5 10.10.20.53

   Saída de exemplo (didáctica):

   rtt min/avg/max/mdev = 582.0/601.3/619.5/13.2 ms
   Pedido web: cerca de 1210 ms

7. Acrescente 2 % de perda à simulação do operador A e observe o ping.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 60ms 10ms loss 2%
   sudo ip netns exec pc-del ping -c 50 -i 0.2 10.10.20.53

   Saída de exemplo (didáctica):

   50 packets transmitted, 49 received, 2% packet loss (o número exacto varia em cada execução)

Critérios de sucesso

• A tabela da dupla tem, para cada cenário, RTT médio, tempo do pedido web e perda.
• O formando explica porque o pedido web demora cerca de duas vezes o RTT.
• A dupla recomenda um operador para o caso, com duas razões e um risco.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root
• Ctrl+C na consola C (servidor web).
• Verificar: sudo ip netns exec r2 tc qdisc show dev r2-r1 deve mostrar só a fila por omissão (noqueue ou pfifo_fast).

Alternativa em papel: tarefas e respostas esperadas

Com as saídas de exemplo, preencha: cenário | RTT médio | pedido web. (sem simulação, operador A, operador B).

Sem simulação: 0,07 ms | 3 ms. Operador A: 60 ms | 125 ms. Operador B: 601 ms | 1210 ms.

Qual operador recomenda para a delegação do caso? Dê duas razões e um risco.

Operador A (móvel): atraso de 60 ms serve para a gestão documental e para videochamadas; débito anunciado maior. Risco: débito e atraso variam com a cobertura e a carga da célula; é preciso medir no local e prever alternativa. O satélite fica como alternativa se não houver cobertura móvel.

Uma ligação tem 100 Mbit/s mas 5 % de perda. Serve para chamadas de voz?

Dificilmente: a perda corta a voz e o TCP abranda por causa das retransmissões. O débito alto não compensa a perda.

Verifique o que aprendeu

Questão 1

Numa ligação por satélite geoestacionário, o que mais prejudica uma videochamada?

1. O débito, que é sempre inferior a 1 Mbit/s
2. O atraso de ida e volta elevado
3. A falta de endereço IP
4. O número de VLAN

Questão 2

Porque um pedido web demorou cerca de 125 ms numa ligação com 60 ms de RTT?

1. Porque o servidor é lento
2. Porque são precisas pelo menos duas idas e voltas: estabelecer a ligação TCP e enviar o pedido
3. Porque o tc duplica os pacotes
4. Porque o DNS falhou

Em leitura fácil

• Uma rede de longa distância liga edifícios longe uns dos outros.
• O caminho normalmente é do operador, não da instituição.
• Veja quatro coisas: velocidade, atraso, variação do atraso e perda.
• Muita velocidade não chega se o atraso ou a perda forem altos.

Fontes

• 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 9293 — Transmission Control Protocol (https://www.rfc-editor.org/rfc/rfc9293)
• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• Debian 12 «bookworm» — Manual de Segurança e pacotes oficiais (https://www.debian.org/doc/manuals/securing-debian-manual/)