Introdução
A Willow Games tem dois enlaces de rede e dois tipos de trabalho: pequenas atualizações de placar e grandes arquivos de som para ensaio. Os dois serviços já funcionam, mas o enlace que responde mais rápido pode não transportar um arquivo grande mais rápido.
Você fará entregas normais, comparará atraso e vazão de upload para o mesmo alvo pelos dois caminhos e restaurará a rota original após cada experimento. É necessário saber usar o terminal e ler um destino, próximo salto e rota com escopo limitado, como ensinado no projeto anterior de roteamento ou em prática equivalente. Não é necessária experiência em programação, codificação de mídia, modelagem de tráfego ou iperf.
Use Event Client para todos os comandos e Event Receipts para ler os registros dos receptores. Cada laboratório prepara sua própria rede isolada; nada de uma VM anterior é necessário. Os 45 minutos são uma estimativa do autor incluindo leitura e erros comuns, não um tempo de conclusão medido com iniciantes.
Experimente uma atualização pequena e uma entrega grande
Nesta etapa, você usará uma mesa de placar que já funciona e fará duas entregas reais de demonstração. Comece em Event Client. Este terminal é o shell de administrador dentro de um namespace de rede Linux isolado, já em /home/labex/project/event-links. O receptor está em outro namespace; ambos compartilham o kernel de uma VM. Não use um shell da plataforma para esses comandos. Abrir a aba não reconstrói a rede.
A Willow Games precisa de interações rápidas de placar e arquivos completos de som de ensaio. Uma requisição pequena passa grande parte do tempo esperando os pacotes viajarem; um upload grande também exige capacidade para transportar seus bytes. Latência é o atraso do percurso, e vazão é a quantidade de dados úteis entregue por segundo. Nenhuma delas descreve sozinha todos os trabalhos.
pwd mostra o diretório de trabalho. cat mostra um arquivo. Se um comando informar que falta um arquivo, compare a grafia e use o comando cd completo abaixo para retornar ao espaço de trabalho; um erro de digitação não exige reiniciar a VM.
pwd
cd /home/labex/project/event-links
cat links.tsv
As duas linhas identificam lane1 e lane2, seus próximos saltos e os endereços de origem deste cliente. Um próximo salto é o vizinho que recebe um pacote no trajeto até o destino. O destino do placar é 10.205.10.10; o de mídia é outro endereço, 10.205.10.20. Ambos escutam na porta 8080. O atraso e a capacidade dos enlaces são preparados pelo setup; mantenha a modelagem, os endereços e os serviços inalterados.
Comece com um placar existente que funciona. curl transfere um recurso HTTP. --noproxy '*' ignora as configurações de proxy do ambiente para todos os endereços; as aspas impedem a expansão do curinga pelo shell. -f faz erros HTTP causarem falha, -s oculta o indicador de progresso e -S ainda mostra erros. Combinadas, essas opções são escritas -fsS. --max-time 35 limita a transferência inteira a 35 segundos. A URL escolhe o destino real, a porta e o recurso.
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Espere warmup, um placar 1–1 e preserved. Este exemplo normal deve continuar disponível. Ele não é sua nova entrega.
Leia o placar de demonstração, representado como JSON: chaves envolvem campos nomeados, strings usam aspas duplas e os dois placares são inteiros.
cat source/demo.json
Espere a partida demo, casa 1, visitante 0. -H define o tipo de conteúdo HTTP. --data-binary @source/demo.json lê esse arquivo exato e o envia por HTTP POST; @ significa um corpo vindo de arquivo. -w mostra um pequeno resultado de tempo após a resposta. Na string entre aspas simples, \n significa nova linha e %{time_total} são os segundos decorridos. Copie o comando inteiro em uma linha:
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/demo.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Leia match, os placares, peer_ip e local_ip no comprovante. Eles identificam o que o receptor aceitou e a origem e o destino reais da conexão. Repetir um POST para a mesma partida substitui seu comprovante; não cria partidas duplicadas.
O arquivo preparado demo.wav é um tom original de teste de som de dois segundos, com áudio PCM WAV válido. Não é preciso criar ou codificar mídia. -T envia o corpo do arquivo por HTTP PUT. Repetir um PUT com o mesmo nome substitui essa única tarefa de mídia.
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
O comprovante inclui a contagem de bytes e o resumo SHA-256 do conteúdo. Um resumo representa os bytes; resumos iguais apoiam a identidade de conteúdo, enquanto apenas o nome do arquivo não a comprova. Para comparar o arquivo realmente recebido, baixe-o novamente. -o salva a resposta no caminho indicado. cmp compara cada byte e não mostra nada em caso de sucesso:
curl --noproxy '*' -fsS --max-time 35 -o received/demo.wav http://10.205.10.20:8080/media/demo.wav
cmp source/demo.wav received/demo.wav
Mude para Event Receipts e selecione Refresh receipts. Abra Existing demonstration receipts e encontre seu placar demo e demo.wav. A página lê os receptores reais por meio de Event Client; nunca preenche registros ausentes a partir da pasta de origem. Os cartões principais aguardam as novas tarefas do próximo laboratório.
A seção de demonstração expandida abaixo mostra o placar demo aceito e a identidade de demo.wav, o resumo de conteúdo e as origens reais das conexões. É esperado que os cartões principais estejam aguardando nesta fase.
Se curl sair com 7, não conseguiu conectar: volte a Event Client e confira endereço, porta e o comando ip route get ensinado a seguir. O código 28 significa que o limite de tempo expirou, não uma rejeição HTTP. O código 22 indica um erro HTTP. Com -f, curl informa o status HTTP, mas omite o corpo da resposta de erro; compare o caminho exato do endpoint e o arquivo JSON ou corpo fornecido. Leia a origem indicada com cat e corrija o comando, preservando os arquivos fornecidos. Uma conexão bem-sucedida com a tarefa errada ainda é um resultado de negócio errado.
Meça o atraso em cada caminho
Nesta etapa, você comparará uma amostra limitada de atraso até o mesmo destino por cada enlace. Comece em Event Client. Todos os comandos são executados neste mesmo cliente; só a rota do destino de mídia muda. Mantenha as rotas de placar e referência, a rota padrão, interfaces, arquivos de origem e modelagem inalterados.
ip route show lista as rotas atuais. /32 seleciona exatamente um destino IPv4. ip route get consulta qual rota e origem o kernel usaria; não envia pacote. Leia a rota de mídia atual antes de alterá-la:
ip route show
ip route get 10.205.10.20
Espere via 10.205.1.1 dev lane1 src 10.205.1.2. Lembre-se dessa rota original: você a restaurará após cada experimento. Este curso usa uma rota padrão preparada dentro da rede isolada; ela não oferece acesso à Internet.
ip route replace adiciona ou substitui apenas a rota do destino declarado. via seleciona o próximo salto e dev a interface de saída. Substituir um /32 não substitui a rota padrão. Primeiro torne explícito o teste por lane1:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping envia requisições de eco ICMP. -n mostra endereços numéricos, -c 4 para após quatro requisições e -W 2 espera no máximo dois segundos por resposta. O tempo de ida e volta (RTT) inclui a ida e a resposta; não é atraso em um só sentido nem resposta de placar da aplicação.
ping -n -c 4 -W 2 10.205.10.20
Leia as quatro respostas e a linha final min/avg/max/mdev, em milissegundos (ms). Compare a média e a dispersão, não só a menor amostra. Este enlace costuma ficar em torno de 11 ms de RTT no cenário preparado. A descoberta inicial de vizinhos ou o escalonamento da VM podem deixar uma amostra mais lenta.
Agora altere apenas esse mesmo destino para lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
Espere via 10.205.2.1 dev lane2 src 10.205.2.2 antes de medir:
ping -n -c 4 -W 2 10.205.10.20
Este caminho costuma ter cerca de 180 ms de RTT. A diferença deve ser grande; não é uma promessa sobre um fornecedor real ou a Internet. A ausência de respostas não significa automaticamente que o serviço HTTP está quebrado: ICMP e HTTP são protocolos diferentes. Confira primeiro esse destino, o próximo salto e a interface. Se os valores parecerem próximos, repita esta mesma amostra limitada por um caminho de cada vez; não inicie testes paralelos.
Restaure a rota original de um único destino e confirme:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Você observou dois tempos de percurso sem alterar as propriedades dos enlaces. A seguir, teste se a resposta mais rápida também transporta dados volumosos mais rápido.
Meça a vazão na direção necessária
Nesta etapa, você comparará a vazão de upload TCP nos mesmos dois caminhos. Comece em Event Client, com a rota de mídia restaurada para lane1. O receptor preparado executa um servidor iperf3 na porta 5201. O cliente inicia um teste; o servidor recebe os dados de teste e relata o que chegou. Esses bytes de teste não são sua entrega de mídia.
iperf3 -c seleciona o endereço do servidor e -t 5 limita o teste de dados a cinco segundos. O teste TCP padrão envia do cliente ao servidor, na mesma direção do upload de mídia do evento. Não usamos -R, que inverte a direção. As breves trocas de preparação e resultados podem fazer o comando completo levar um pouco mais de cinco segundos.
Confirme a rota antes do primeiro teste:
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Leia a linha final receiver. A coluna Bitrate pode usar Mbits/sec (Mbps): milhões de bits por segundo. Um byte tem oito bits, portanto divida Mbps por oito para obter aproximadamente MB/s. Por exemplo, 2 Mbps são no máximo cerca de 0,25 MB/s antes da sobrecarga do protocolo. MBytes na coluna de transferência é uma quantidade de dados, não uma taxa. A taxa do receptor por lane1 costuma ficar perto de 1,9 Mbps.
Espere o comando terminar antes de mudar a rota. Meça o mesmo destino por lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lane2 costuma entregar dezenas de Mbps apesar do RTT maior. A inicialização TCP, as confirmações, a sobrecarga do protocolo, o escalonamento e a janela curta de observação afetam a taxa. A velocidade nominal de uma interface virtual não é vazão medida. Se o servidor informar um teste em andamento, espere o teste limitado atual terminar e tente novamente uma vez; não inicie outro servidor nem sobreponha mais testes.
Restaure a rota de mídia original e confirme:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
O enlace de baixo RTT serve às pequenas interações, enquanto o de alta vazão serve a este upload volumoso. Essa conclusão se limita aos caminhos preparados e à direção medida. Você não mediu Wi-Fi, capacidade da Internet pública ou confiabilidade de produção. O próximo laboratório independente pede que use essas observações para entregar novos conteúdos de negócio.
Resumo
Você enviou um placar real e áudio reproduzível, comparou o mesmo alvo por dois caminhos, interpretou RTT e vazão do receptor TCP e restaurou a rota limitada. As medições descrevem um caminho e uma direção; a próxima tarefa transforma essas observações em rotas de negócio separadas.
