介绍
Willow Games 即将开始新一轮比赛。比分台需要响应迅速的交互，媒体台需要完整的彩排音频交付。两条链路均可用，但起始路由让两项工作都使用同一条链路。
你将在全新准备的环境中重复短时测量，选择不同的目的地址路由，并发送新比分与完整音频。请先完成 测量每项活动任务的网络需求，或具备等效的 ping、iperf3 和限定目标 IPv4 路由技能。不要求编程或媒体编码。
命令使用 Event Client，实际收到的内容在 Event Receipts 中查看和播放。只允许修改两条指定目的地址路由及提交你的新任务。45 分钟是作者估计；隔离节点共享同一个内核，表示有线虚拟路径，并非公共供应商的测量结果。
按明确的工作负载选择
本步骤测量准备好的链路，并为每项工作选择一条。从 Event Client 开始，当前已位于 /home/labex/project/event-links。本实验有独立的新网络与文件，假定你已掌握 测量每项活动任务的网络需求 中的时延、吞吐量工具和基本目的路由读取方法，不延续任何文件或运行进程。
先查看必须保留的正常功能。比分台已有一条热身记录。curl --noproxy '*' 绕过代理，-fsS 在 HTTP 错误时失败并显示错误信息，--max-time 35 限制传输时长：
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
预期看到保留的 warmup 比分 1–1。切换到 Event Receipts。两个主卡片等待的是 heat-7 和 opening-sound.wav；页面不会将热身记录当作已完成的新工作。返回 Event Client。
比分台需要短时交互：选择 RTT 持续较低、采样平均值明显低于 80 ms 规划预算的链路。媒体团队需要大批量上传能力：选择在此准备场景中接收端吞吐量明显高于 10 Mbps 的路径。这些宽松预算用于指导判断，不是互联网服务保证。不要调整链路来达到它们。
读取提供的链路标识和新比分内容。cat 打印每个文件：
cat links.tsv
cat source/score.json
两个业务目的地址分别为比分 10.205.10.10、媒体 10.205.10.20，都使用 HTTP 端口 8080。最初两条 /32 路由都使用 lane1。从同一客户端经各条链路测量同一媒体目标，每次只进行一项测试。ip route replace 只修改该目的地址，via 标识下一跳，dev 标识接口。发送流量前，ip route get 确认内核选择。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n 使用数字地址，-c 4 在四次请求后停止，-W 2 将每次回复等待时间限制为两秒。读取以毫秒表示的 RTT 平均值和波动：
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c 连接准备好的接收端端口 5201；-t 5 执行五秒 TCP 数据测试。默认方向为客户端上传至接收端，与媒体工作一致。读取最后的 receiver 比特率。Mbps 表示每秒数百万比特，除以八可近似得到扣除开销之前的 MB/s。
iperf3 -c 10.205.10.20 -t 5
等待测试结束。现在只修改媒体路由，再次测试：
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
实验后恢复起始媒体路由：
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
你应看到明显差异：lane1 的 RTT 约为 11 ms，吞吐量约为 1.9 Mbps；lane2 的 RTT 约为 180 ms，吞吐量为数十 Mbps。首次邻居发现和调度可能影响单次采样。如果结果接近，或测试提示服务器忙，请让有限时长测试结束，确认路由，再串行重复相同采样。不要重叠测试或更改整形。打印的报告不能替代真实流量，iperf 测试字节也没有交付任何新业务任务。
仅修改目的地址路由
本步骤将测量后的工作负载判断转化为两条具体路由。从 Event Client 开始。lane1 提供小型比分交互所需的低 RTT，lane2 提供大型试音文件所需的上传能力。两条链路都必须保持可用。
编辑前读取完整路由表：
ip route show
保持课程默认路由和参考目的地址 10.205.10.30 不变。你只能替换 10.205.10.10/32 和 10.205.10.20/32 路由。/32 恰好表示一个 IPv4 地址；更宽的网络路由会影响其他目的地址。平台网络不属于本任务范围。
使用已经教授的 replace、via、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
检查内核对每个目的地址的实际选择：
ip route get 10.205.10.10
ip route get 10.205.10.20
预期比分流量使用 10.205.1.1 dev lane1 src 10.205.1.2，媒体流量使用 10.205.2.1 dev lane2 src 10.205.2.2。如果某条不正确，只需用正确下一跳和接口重做该条完整的 replace 命令。不要清空路由表或修改默认路由。
发送实际请求，确认独立的参考路由仍然可用：
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
预期仍返回原来的 warmup、1–1、preserved。本练习按两个不同目的地址区分流量，不区分共享同一目标地址的应用，不配置策略路由、聚合链路或选择公共 ISP。
交付新比分与媒体
本步骤经选定路由交付新工作，并比较完整收到的媒体。从 Event Client 开始。新比分为比赛 heat-7，主队 3，客队 1。新媒体任务为 opening-sound.wav，这是原创的 48 秒合成彩排试音音调。有效的单声道 PCM WAV 字节已准备好，你无需编码或编辑。
发送前读取提供的比分：
cat source/score.json
JSON 名称和字符串值使用双引号，比分是数字。-H 提供 JSON 内容类型，--data-binary @source/score.json 读取确切文件并执行 POST。-w 字符串在回执之后添加经过的秒数：\n 表示换行，%{time_total} 表示 curl 总时间。它包含连接建立时间，并非只有 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
预期比赛和比分正确，local_ip 为 10.205.10.10，peer_ip 为 10.205.1.2。peer 是接收端实际观察到的来源。回执是本次交付的证据，不是根据当前路由作出的预测。
-T 使用 PUT 将指定文件上传至媒体服务，可能需要数秒；等待结果：
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
预期看到新文件名、字节数、内容摘要，local_ip 为 10.205.10.20，peer_ip 为 10.205.2.2。示例文件的成功响应不能完成这项任务。
同一比赛 ID 的 POST 会替换该比赛，同一媒体名称的 PUT 会替换该媒体任务。如果你经错误路径交付，请修正路由并重新发送同一任务。交付后修改路由不会改变旧回执。绝不要编辑回执存储或源文件来模拟结果。
通过 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
下载收到的媒体，而不是复制本地源文件。-o 保存响应，cmp 逐字节比较，sha256sum 为每个指定文件打印摘要：
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
预期 cmp 没有输出，两个摘要字符串相同。空文件或内容不同的文件不会与准备好的音频匹配。重命名不会改变文件的字节或哈希。如果比较失败，请读取媒体回执，将未改动的源文件再次 PUT 到正确目的地址，重新下载并比较。
切换到 Event Receipts，选择 Refresh receipts，寻找 heat-7，其比分为 3 : 1、新媒体文件名和不同的连接来源。播放 Received event audio 控件，并用 Download received audio 获取接收端字节。浏览器可能被静音或没有声音设备；控件显示的时长和推进的播放进度仍可确认其能够解码收到的 WAV。请主动开始播放，页面不会自动播放。
在下方最终视图中，比较新比分和收到音频旁的两个 Connection from 值。音频控件显示真实解码时长，并允许选择播放位置。
如果 curl 无法连接（退出码 7）或超时（退出码 28），返回 Event Client，重新检查对应的 ip route get 结果和确切 URL。HTTP 拒绝（退出码 22）不同：请核对确切端点路径和提供的 JSON/请求体文件。-f 选项省略 HTTP 错误响应体；不要通过调整网络来修复业务格式错误。页面刷新只读取接收端，不能补做缺失任务。
返回 Event Client，再次确认保留的参考：
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
你已通过合适路径交付两种不同的工作负载，同时保留两条链路、源字节、预设整形、参考数据和无关路由。评分先读取现有业务记录与原生网络事实，再进行有限的 GET 探测；它绝不会提交比分、上传文件或修复路径。
总结
你按工作负载选择路径，仅修改两条目的地址路由，并交付新比分与完整可播放媒体。接收端连接来源证明交付从哪里到达；事后修改路由无法改写它们。你还保留了现有参考和两条预设链路。
