CS 168 · DISCUSSION 08 · GUIDED REASONING WORKBOOK
沿一次网页加载的真实依赖链推：先解析名字，再建立连接，再取 HTML，看到资源 URL 后才能并发或复用。
无需离开 CourseStack：先预测，再在表格、时间线或状态空间里完成推导；卡住时逐层打开提示，最后才展开解释与变式。
已阅读 Spring 2026 worksheet 与 official solution；以下是原创等价练习。官方 IDs 用于 coverage，对精确原题请回到页末 PDF。
对应官方 1.1、1.2、1.3、1.4、1.5、1.6
Why the official problem exists：避免把 anycast、TCP state、root query 与 HTTP pipelining 当成孤立事实。
同一 root anycast IP 在不同地点由多台无共享 TCP state 的 server 提供；client 需要解析并加载页面。
先预测：为何通常不用长 TCP connection 查询任意 root replica？
逐条判断：host 是否自己迭代、zone 是否冗余 nameserver、BGP anycast 与 TCP state 是否兼容、pipelining 与 multiplexing 差异。
每个断言都问 state 存在哪。
recursive resolver 承担迭代。
HTTP/2 multiplexing 可避免应用层队头阻塞。
host 通常把递归交给 local resolver；zone 需要冗余权威；root 用 anycast 接近用户；无连接查询更适合 replica path 变化。HTTP/1.1 pipelining 实践受 bugs/HOL 限制。
协议选择由状态放置和 failure behavior 解释，而非“常用/不常用”记忆。
若 anycast 服务用共享连接状态或 QUIC connection migration，哪些限制会变化？
对应官方 2.1、2.2、2.3
Why the official problem exists：把 cache hit 计算建立在绝对 expiry time，而不是“每 30 秒一定查询一次”。
client↔resolver one-way=a；resolver 依次访问 root/TLD/authority 的 RTT 为 2b、2c、2d、2e；website RTT=2t；总时间 T。
先预测：第一份 DNS answer 何时开始 TTL？
写 cold order cost；写 TTL≥T 后 first 与 subsequent cost；令所有 one-way=1s、TTL=30s，画 cache fill、expiry、orders 的绝对时间轴。
第一单与后续单分开。
TTL 从 resolver 获得记录时算。
有限 TTL 用 cycle timeline，不要只做 T/TTL。
cold cost=2a+2b+2c+2d+2e+2t；热 cache 后每单=2a+2t。有限 TTL 下先标 fill time，再数 expiry 前能完成的 requests，过期后下一次触发完整解析。
cache 是带期限 state；request timing 决定 hit/miss event。
CNAME 与 A 有不同 TTL，哪个先过期会让第二次访问少走哪些 authority steps？
对应官方 3.1、3.2、3.3、3.4、3.5
Why the official problem exists：检查 handshake、request propagation、transmission 和资源发现依赖是否被重复/并行计数。
HTML size=P，内含两个 M-sized images；small message one-way=z；单连接 throughput=T，并发两连接各 T/2。
先预测：两个 image 可以在 HTML 完成前请求吗？
为 sequential nonpersistent、concurrent nonpersistent、persistent sequential、pipelined 四种画 critical path，只把并行分支的 max 加入总时间。
先画 DAG，再算长度。
persistent 只付一次 handshake。
小 object propagation 主导，大 object transmission 主导。
nonpersistent sequential 重复三次 handshake；concurrent 在 HTML 后并行两套 image handshake；persistent 复用连接；pipelining 同时发两个 requests 但 response 在单连接上仍序列化。所有模式都先等待 HTML。
性能来自 critical path，而非简单把所有 message delay 相加。
若两个 images 来自不同 origins，persistent connection 能复用到哪里？
对应官方 4.1、4.2
Why the official problem exists：区分 client-proxy 与 proxy-origin 连接，并追 cache capacity=2 的逐请求状态。
proxy 缓存最近两个 objects；序列 A,B,C,D,C,A。link latency=L，Internet latency=I；miss 时 proxy 与两端各有独立 TCP session。
先预测：访问 C 第二次时？
| request | cache before | hit/miss | cache after |
|---|---|---|---|
| A | [] | ____ | ____ |
| B | [A] | ____ | ____ |
| C | [A,B] | ____ | ____ |
| D,C,A | ____ | ____ | ____ |
每次 miss 插入并 evict 最久未用。
hit 也刷新 recency。
延迟只沿当前 request 的实际路径计。
A miss→[A]；B miss→[A,B]；C miss 淘汰 A→[B,C]；D miss→[C,D]；C hit→[D,C]；A miss→[C,A]。hit 不穿越 Internet，miss 由 proxy-origin session 提供。
缓存性能取决于 state evolution，不是 object 是否“曾经访问过”。
改为 FIFO，重跑 D,C,A；哪次结果与 LRU 不同？
从空 DNS/cache 开始，为 HTML+3 resources 画一次完整 message DAG；指定 TTL 与 LRU=2，闭卷推第二次访问省掉的边。