Introdução
A Willow Games está pronta para uma nova bateria. A mesa de placar precisa de interações ágeis; a mesa de mídia precisa de uma entrega completa de áudio de ensaio. Ambos os enlaces funcionam, mas a rota inicial envia os dois trabalhos por um único enlace.
Você repetirá medições curtas em um ambiente novo preparado, escolherá rotas separadas por destino e enviará o novo placar e o áudio completo. Conclua primeiro Meça as necessidades de rede de cada tarefa do evento ou tenha conhecimentos equivalentes de ping, iperf3 e rotas IPv4 com escopo limitado. Programação e codificação de mídia não são necessárias.
Use Event Client para comandos e Event Receipts para ver e reproduzir o conteúdo realmente recebido. Só as duas rotas de destino nomeadas e seus novos envios podem ser editados. Os 45 minutos são uma estimativa do autor; os nós isolados compartilham um kernel e representam caminhos virtuais cabeados, não medições de fornecedores públicos.
Escolha pela carga de trabalho declarada
Nesta etapa, você medirá os enlaces preparados e escolherá um para cada trabalho. Comece em Event Client, já em /home/labex/project/event-links. Este laboratório tem sua própria rede e arquivos novos. Ele pressupõe as ferramentas de atraso e vazão de Meça as necessidades de rede de cada tarefa do evento, além de leitura básica de rotas por destino; não há arquivos ou processos em execução herdados.
Primeiro observe a função normal que deve preservar. A mesa de placar já tem um registro de aquecimento. curl --noproxy '*' ignora proxies, -fsS falha em erros HTTP mostrando mensagens de erro e --max-time 35 limita a transferência:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Espere o placar warmup preservado de 1–1. Mude para Event Receipts. Os dois cartões principais aguardam heat-7 e opening-sound.wav; a página não considera o aquecimento um novo trabalho concluído. Volte a Event Client.
A mesa de placar precisa de interações curtas: escolha o enlace com RTT consistentemente baixo e média de amostra bem abaixo do orçamento de planejamento de 80 ms. A equipe de mídia precisa de capacidade de upload em massa: escolha o caminho com vazão no receptor bem acima de 10 Mbps neste cenário preparado. Esses orçamentos amplos orientam sua decisão; não são uma garantia de serviço de Internet. Não tente ajustar os enlaces para atingi-los.
Leia as identidades de enlace fornecidas e o novo placar. cat mostra cada arquivo:
cat links.tsv
cat source/score.json
Os dois destinos de negócio são 10.205.10.10 para placares e 10.205.10.20 para mídia, ambos na porta HTTP 8080. Inicialmente as duas rotas /32 usam lane1. Meça o mesmo alvo de mídia a partir deste mesmo cliente por cada enlace, um teste de cada vez. ip route replace altera apenas esse destino; via identifica o próximo salto e dev a interface. ip route get confirma o que o kernel seleciona antes de enviar tráfego.
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n usa endereços numéricos, -c 4 para após quatro requisições e -W 2 limita cada espera a dois segundos. Leia a média e a dispersão do RTT em milissegundos:
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c conecta à porta 5201 do receptor preparado; -t 5 executa um teste TCP de dados de cinco segundos. A direção padrão é upload do cliente ao receptor, como no trabalho de mídia. Leia a taxa final de receiver. Mbps significa milhões de bits por segundo; divida por oito para aproximar MB/s antes da sobrecarga.
iperf3 -c 10.205.10.20 -t 5
Espere a conclusão. Agora mude apenas a rota de mídia e repita:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Restaure a rota inicial da mídia após o experimento:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Você deve ver um grande contraste: lane1 com cerca de 11 ms de RTT e 1,9 Mbps; lane2 com cerca de 180 ms e dezenas de Mbps. A descoberta inicial de vizinhos e o escalonamento podem afetar uma amostra. Se um resultado estiver próximo ou um teste disser que o servidor está ocupado, deixe o teste finito terminar, confirme a rota e repita a mesma amostra em série. Não sobreponha testes nem altere a modelagem. Um relatório impresso não substitui tráfego real, e os bytes do iperf não entregam nenhuma das novas tarefas de negócio.
Altere apenas as rotas de destino
Nesta etapa, você transformará a decisão medida sobre as cargas em duas rotas específicas. Comece em Event Client. Lane1 oferece o baixo RTT necessário à pequena interação de placar. Lane2 oferece a capacidade de upload necessária ao grande arquivo de teste de som. Ambos os enlaces devem permanecer utilizáveis.
Leia a tabela inteira antes de editar:
ip route show
Mantenha a rota padrão do curso e o destino de referência 10.205.10.30 inalterados. Você pode substituir apenas as rotas 10.205.10.10/32 e 10.205.10.20/32. /32 significa exatamente um endereço IPv4; uma rota de rede mais ampla afetaria outros destinos. A rede da plataforma está fora desta tarefa.
Explicite a rota do placar usando a forma já ensinada com replace, via e dev:
ip route replace 10.205.10.10/32 via 10.205.1.1 dev lane1
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
Confira cada seleção real do kernel:
ip route get 10.205.10.10
ip route get 10.205.10.20
Espere tráfego de placar por 10.205.1.1 dev lane1 src 10.205.1.2 e mídia por 10.205.2.1 dev lane2 src 10.205.2.2. Se uma seleção estiver errada, repita apenas seu comando replace completo com próximo salto e interface corretos. Não esvazie a tabela nem altere a rota padrão.
Verifique a preservação da rota de referência independente com uma requisição real:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Espere a resposta original warmup, 1–1, preserved. Este exercício separa o tráfego por dois endereços de destino distintos. Ele não distingue aplicações que compartilham um alvo, não configura roteamento por políticas, não combina enlaces nem seleciona um ISP público.
Entregue novos placares e mídia
Nesta etapa, você entregará o novo trabalho pelas rotas escolhidas e comparará a mídia completa recebida. Comece em Event Client. O novo placar é da partida heat-7, casa 3, visitante 1. A nova tarefa de mídia é opening-sound.wav, um tom sintético original de 48 segundos para teste de som do ensaio. Seus bytes PCM WAV mono válidos estão preparados; você não os codifica nem edita.
Leia o placar fornecido antes de enviar:
cat source/score.json
Nomes e valores de string JSON usam aspas duplas; os placares são números. -H fornece o tipo de conteúdo JSON e --data-binary @source/score.json lê o arquivo exato e realiza POST. A string -w acrescenta os segundos decorridos após o comprovante: \n cria nova linha e %{time_total} é o tempo total do curl. Isso inclui estabelecer a conexão, não apenas RTT.
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/score.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Espere a partida e os placares corretos, local_ip de 10.205.10.10 e peer_ip de 10.205.1.2. O peer é a origem realmente observada pelo receptor. O comprovante é evidência desta entrega, não uma previsão da rota atual.
-T envia o arquivo dado com PUT ao serviço de mídia. Pode levar alguns segundos; espere o resultado:
curl --noproxy '*' -fsS --max-time 35 -T source/opening-sound.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/opening-sound.wav
Espere o novo nome, contagem de bytes, resumo de conteúdo, local_ip de 10.205.10.20 e peer_ip de 10.205.2.2. Uma resposta bem-sucedida para o arquivo de demonstração não concluiria esta tarefa.
Um POST com o mesmo ID de partida substitui essa partida; um PUT com o mesmo nome de mídia substitui essa tarefa. Se entregou pelo caminho errado, corrija a rota e reenvie a mesma tarefa. Alterar a rota após uma entrega não muda seu comprovante antigo. Nunca edite o armazenamento de comprovantes nem os arquivos de origem para simular um resultado.
Leia os receptores de forma independente com GET:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/receipts
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.20:8080/receipts
Baixe a mídia recebida em vez de copiar a origem local. -o salva a resposta, cmp compara cada byte e sha256sum mostra um resumo para cada arquivo indicado:
curl --noproxy '*' -fsS --max-time 35 -o received/opening-sound.wav http://10.205.10.20:8080/media/opening-sound.wav
cmp source/opening-sound.wav received/opening-sound.wav
sha256sum source/opening-sound.wav received/opening-sound.wav
Espere que cmp não mostre nada e que os dois resumos coincidam. Um arquivo vazio ou com conteúdo diferente não corresponderá ao áudio preparado. Renomear um arquivo não altera seus bytes nem seu hash. Se a comparação falhar, leia o comprovante de mídia, repita o PUT da origem inalterada ao destino correto, baixe novamente e compare.
Mude para Event Receipts, selecione Refresh receipts e procure heat-7 com 3 : 1, o novo nome de mídia e as origens de conexão diferentes. Reproduza pelo controle Received event audio e use Download received audio para obter os bytes do receptor. Seu navegador pode estar mudo ou sem dispositivo de som; a duração e o avanço da reprodução ainda confirmam que ele decodifica o WAV recebido. Inicie explicitamente a reprodução; a página não reproduz automaticamente.
Na visualização final abaixo, compare os dois valores Connection from ao lado do novo placar e do áudio recebido. O controle mostra a duração realmente decodificada e permite escolher uma posição de reprodução.
Se curl não conectar (saída 7) ou exceder o tempo (saída 28), volte a Event Client e confira novamente o resultado correspondente de ip route get e a URL exata. Uma rejeição HTTP (saída 22) é diferente: compare o caminho exato do endpoint e o arquivo JSON ou corpo fornecido. A opção -f omite o corpo da resposta de erro HTTP; não ajuste a rede para corrigir um erro de formato do negócio. A atualização da página só lê receptores e não conclui trabalho ausente.
Volte a Event Client e confirme novamente a referência preservada:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Você entregou duas cargas diferentes por caminhos adequados, mantendo ambos os enlaces, bytes originais, modelagem preparada, dados de referência e rotas não relacionadas. A avaliação lê registros de negócio e fatos nativos de rede existentes antes de suas sondagens GET limitadas; nunca envia placares, faz uploads ou repara um caminho.
Resumo
Você escolheu caminhos pela carga, alterou apenas duas rotas de destino e entregou um novo placar e mídia completa reproduzível. As origens de conexão do receptor provam por onde essas entregas chegaram; mudar uma rota depois não pode reescrevê-las. Você também preservou a referência existente e os dois enlaces preparados.
