介绍
Willow Games 有两条网络链路和两类工作：小型比分更新与大型彩排音频文件。两个服务都已运行，但响应最快的链路未必能最快传完大文件。
你将尝试正常交付，比较经两条路径到同一目标的时延与上传吞吐量，并在每次实验后恢复原来的路由。你需要基本终端操作能力，以及读取目的地址、下一跳和限定目标路由的能力；这些内容已在前面的路由项目中教授，也可通过等效练习掌握。不要求具备编程、媒体编码、流量整形或 iperf 经验。
所有命令都在 Event Client 中执行，接收记录在 Event Receipts 中查看。每个实验独立准备隔离网络，不依赖上一台 VM 的任何内容。45 分钟是作者估计，包含阅读和普通错误处理，并非测得的初学者完成时间。
尝试小型更新与大型交付
本步骤先使用已正常工作的比分台，再发送两项真实的示例交付。从 Event Client 开始。此终端是一个隔离 Linux 网络命名空间内的管理员 shell，已位于 /home/labex/project/event-links。接收端位于另一个命名空间，两者共享同一台 VM 的内核。不要在平台 shell 中执行这些命令。打开此标签页不会重建网络。
Willow Games 需要快速的比分交互和完整的彩排音频文件。小请求的大部分时间可能用于等待数据包往返；大文件上传还需要足够的传输能力来承载其字节。时延是传输的延迟，吞吐量是每秒交付的有效数据量。单看任何一项都不足以描述所有任务。
pwd 打印工作目录，cat 打印文件内容。如果命令提示文件不存在，请核对拼写，并使用下面完整的 cd 命令返回工作目录；输入错误不需要重置 VM。
pwd
cd /home/labex/project/event-links
cat links.tsv
这两行标识 lane1、lane2、各自的下一跳及本客户端的源地址。下一跳是数据包前往目标途中接收它的相邻节点。比分目的地址为 10.205.10.10，媒体使用另一个目的地址 10.205.10.20。两者均监听端口 8080。链路时延和传输能力由环境准备完成；请保持整形、地址和服务不变。
先读取现有的正常比分。curl 传输 HTTP 资源。--noproxy '*' 对所有地址绕过代理环境设置，引号防止 shell 展开通配符。-f 让 HTTP 错误导致命令失败，-s 隐藏进度条，-S 仍然打印错误。这些选项合写为 -fsS。--max-time 35 将整个传输限制为 35 秒。URL 指定实际的目的地址、端口和资源。
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
预期看到 warmup、1–1 的比分和 preserved。这个正常示例必须保持可用，它不是你要完成的新交付。
读取用 JSON 表示的示例比分：花括号包围命名字段，字符串使用双引号，两个比分值为整数。
cat source/demo.json
预期比赛为 demo，主队 1，客队 0。-H 设置 HTTP 内容类型。--data-binary @source/demo.json 读取这个确切的文件，并用 HTTP POST 提交；@ 表示以文件作为请求体。-w 在响应之后打印简短的计时结果。在其单引号字符串中，\n 表示换行，%{time_total} 表示经过的秒数。将整条命令作为一行复制：
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
读取回执中的 match、比分、peer_ip 和 local_ip。它们标识接收端接受的内容，以及实际连接的来源与目的地址。对同一比赛重复 POST 会替换该比赛的回执，不会创建重复比赛。
准备好的 demo.wav 是原创的两秒试音音调，为有效的 PCM WAV 音频。你不需要创建或编码媒体。-T 使用 HTTP PUT 上传文件请求体。对同一名称重复 PUT 会替换这一项媒体任务。
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
回执包含字节数及 SHA-256 内容摘要。摘要是字节内容的概括；摘要相同有助于确认内容一致，而仅凭文件名无法确认。要比较实际收到的文件，请重新下载。-o 将响应保存到指定路径。cmp 逐字节比较，成功时不输出任何内容：
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
切换到 Event Receipts 并选择 Refresh receipts。展开 Existing demonstration receipts，找到你的 demo 比分和 demo.wav。页面通过 Event Client 读取真实接收端，绝不会从源文件夹补齐缺失记录。主卡片在等待下一实验的新任务。
下方展开的示例区域展示已接受的 demo 比分，以及 demo.wav 的身份、内容摘要与实际连接来源。此时主卡片保持等待状态是正常现象。
如果 curl 退出码为 7，说明无法连接：返回 Event Client，核对地址、端口，以及下一步教授的 ip route get 命令。退出码 28 表示超出时间限制，不代表 HTTP 拒绝；退出码 22 表示 HTTP 错误。使用 -f 时，curl 会报告 HTTP 状态，但省略错误响应体；请核对确切的端点路径与提供的 JSON/请求体文件。用 cat 读取指定源文件并修正命令，保留提供的文件。即使连接成功，交付了错误任务也仍然是错误的业务结果。
测量每条路径的时延
本步骤通过两条链路，比较到同一目的地址的有限次时延采样。从 Event Client 开始。所有命令都在同一客户端运行，只改变媒体目的地址的路由。保持比分路由、参考路由、默认路由、接口、源文件和整形不变。
ip route show 列出当前路由。/32 只选择一个 IPv4 目的地址。ip route get 查询内核将使用哪条路由和哪个源地址，不会发送数据包。修改前先读取当前媒体路由：
ip route show
ip route get 10.205.10.20
预期看到 via 10.205.1.1 dev lane1 src 10.205.1.2。记住这条原始路由，每次实验后都要恢复它。本课程在隔离网络中使用预设的默认路由，不提供互联网访问。
ip route replace 仅添加或替换指定目的地址的路由。via 选择下一跳，dev 选择出接口。替换一个 /32 不会替换默认路由。先明确设置 lane1 测试路径：
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping 发送 ICMP 回显请求。-n 显示数字地址，-c 4 在发送四次请求后停止，-W 2 对每次回复最多等待两秒。往返时间（RTT）包含去程和响应，不是单向时延，也不是应用层比分响应时间。
ping -n -c 4 -W 2 10.205.10.20
读取全部四次回复，以及最后的 min/avg/max/mdev 行，其单位为毫秒（ms）。比较平均值与波动，不要只看最低值。在准备好的场景中，这条链路的 RTT 通常约为 11 ms。首次邻居发现或 VM 调度可能使某次采样变慢。
现在只将同一目的地址切换到 lane2：
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
测量前预期看到 via 10.205.2.1 dev lane2 src 10.205.2.2：
ping -n -c 4 -W 2 10.205.10.20
这条路径的 RTT 通常约为 180 ms。两者差距应很大，但这并不是对真实供应商或互联网的承诺。没有回复不自动意味着 HTTP 服务损坏：ICMP 和 HTTP 是不同协议。先检查此目的地址、下一跳和接口。如果数值接近，就逐条路径重复同样的有限次采样，不要并行测试。
恢复原来针对单个目的地址的路由，并确认：
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
你已经在不改变链路属性的情况下观察到两种传输时间。接下来测试响应更快的链路是否也能更快传输大批数据。
测量所需方向的吞吐量
本步骤比较同样两条路径的 TCP 上传吞吐量。从 Event Client 开始，媒体路由应已恢复为 lane1。准备好的接收端运行 iperf3 服务器，端口为 5201。客户端发起测试，服务器接收测试数据并报告收到的情况。这些测试字节不是你的媒体交付。
iperf3 -c 选择服务器地址，-t 5 将数据测试限制为五秒。默认 TCP 测试从客户端向服务器发送，与活动媒体上传的方向相同。这里不使用会反转方向的 -R。简短的建立连接和结果交换可能让整条命令略超过五秒。
第一次测试前确认路由：
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
读取最后的 receiver 行。Bitrate 列可能使用 Mbits/sec（Mbps），即每秒数百万比特。一个字节包含八个比特，因此将 Mbps 除以八可近似得到 MB/s。例如，2 Mbps 在扣除协议开销之前，最多约为 0.25 MB/s。传输列中的 MBytes 是数据量，不是速率。lane1 接收端速率通常接近 1.9 Mbps。
等命令结束后再改变路由。经 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
尽管 RTT 更长，lane2 通常能提供数十 Mbps。TCP 启动、确认、协议开销、调度及较短的观察窗口都会影响速率。虚拟接口的标称速度不等于测得的吞吐量。如果服务器报告测试正在进行，请等待当前有限时长测试结束后重试一次；不要另启服务器，也不要让更多测试重叠运行。
恢复原来的媒体路由，并确认：
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
低 RTT 链路适合小型交互，高吞吐量链路适合本次大文件上传。此结论仅适用于准备好的路径和测量方向。你没有测量 Wi-Fi、公共互联网容量或生产可靠性。下一个独立实验将要求你运用这些观察交付新的业务内容。
总结
你发送了真实比分和可播放音频，比较了到同一目标的两条路径，解读了 RTT 和 TCP 接收端吞吐量，并恢复了限定目标的路由。测量描述的是特定路径与方向；下一项任务将把这些观察转化为不同的业务路由。
