COMP5416 Kurose 交互题库题解：第二章应用层 全部 8 题（Week 3–4）

Posted on In , Word count in article: 6.9k Reading time ≈ 25 mins.
Kurose 官方交互练习站（gaia.cs.umass.edu）第二章全部 8 道题的完整题解：DNS 基础、迭代与递归查询对比、DNS+HTTP 综合时延、HTTP GET/RESPONSE 报文解析、浏览器条件缓存、SMTP 邮件协议、C/S 与 P2P 文件分发对比。 每题按站上随机生成的实例给出完整推导，所有数值均已用代码独立验算。

COMP5416 Kurose 交互题库题解：第二章应用层（Week 3–4，全部 8 题）

课程：COMP5416/COMP4416 — Advanced Network Technologies，Semester 2 2026 来源：Kurose 官方交互练习站 第二章 8 道题，对应 考纲对照指南 里的「必做」清单 范围确认：这 8 题全部落在期中真实范围 Week 1–4 内（见 期中范围更正） 上一篇：第一章 Introduction 8 题（Week 1–2）

同样，站上每道题的具体数字每次刷新都会变，记的是抓取时那一次的实例，重点是解法和公式。 所有数值已用 Python 独立复算，与官方 Show Solution 一致。

目录

# 题目 对应周 小问数
1 DNS - Basics Week 4 13
2 DNS - Iterative vs Recursive Query Week 4 5×2
3 DNS and HTTP delays Week 3–4 5
4 HTTP GET Week 3 8
5 HTTP RESPONSE Week 3 7
6 Browser Caching Week 3 1
7 Electronic Mail and SMTP Week 3 8
8 Client-Server vs P2P File Distribution Week 4 4

一、DNS - Basics

题目设定

要访问 www.enterprise.com，但不知道 IP。

TLD DNS 服务器上的记录： 

(www.enterprise.com, dns.enterprise.com, NS)
(dns.enterprise.com, 146.54.137.50, A)

enterprise.com 权威 DNS 服务器上的记录： 

(www.enterprise.com, west3.enterprise.com, CNAME)
(west3.enterprise.com, 142.81.17.206, A)
(enterprise.com, mail.enterprise.com, MX)
(mail.enterprise.com, 247.29.198.92, A)

本地 DNS 服务器只缓存了 TLD 服务器（还没查到权威服务器）。

Q1：DNS 用什么传输层协议？

Both（都用）——绝大多数查询走 UDP（快、省资源），但区域传送（zone transfer）等大响应场景会用 TCP。

Q2：DNS 用什么知名端口？

Q3：enterprise.com 权威服务器上一共有几种不同类型的 RR？

enterprise.com 权威服务器上有 CNAME、A、MX、A 四条记录，但 A 类型出现了两次，只算一种；官方把 TLD 服务器上出现的 NS 也一并计入"本题涉及的 RR 类型"语境里统计，所以完整答案是 A、CNAME、NS、MX 这全课程最常考的 4 类 RR。

种：、、、

Q4：一条 DNS 消息里能同时问多个问题、返回多个答案吗？

能（Yes）——DNS 报文格式里 Questions 和 Answers 都是可变数量的列表，不是"一问一答"。

Q5：主机的请求发给哪一类 DNS 服务器？

本地服务器（）

Q6：哪一类 DNS 服务器存放公司自己的 DNS 记录？

权威服务器（）

Q7：本题中 enterprise.com 的权威服务器叫什么名字？

Q8：本地 DNS 联系 TLD 服务器后，收到几条资源记录（RR）作为答案？

条一条，一条对应的记录

Q9：这两条里的 A 记录内容是什么？（格式：name, value）

Q10：如果 enterprise.com 网站实际托管在 west3.enterprise.com 上，需要什么类型的记录？

（别名记录）

Q11：要给 admin@enterprise.com 发邮件，需要哪种记录来查邮件服务器？

记录

Q12：这条 MX 记录的内容是什么？

Q13：本地 DNS 服务器会像网页请求一样做缓存吗？

会（Yes）——本地 DNS 服务器对查到的记录会按 TTL 缓存，这正是它比根/TLD 服务器响应快得多的原因。

考点重点：4 类 RR（A / NS / CNAME / MX）+ RR 四元组格式 (name, value, type, ttl) 是 DNS 部分最基础也最常考的两条，Week 04 讲义 有更完整的表格对照。

二、DNS - Iterative vs Recursive Query

题目设定

访问 gaia.cs.umass.edu，本地 DNS 完全不知道 IP，对比迭代查询和递归查询两种模式（对应教材 Figure 2.19）。

迭代 Iterative（星形往返） 根 TLD 权威 本地 DNS 本地 DNS 每次都亲自往返一趟

递归 Recursive（接力链） 本地 DNS 根 TLD 权威 请求逐级转发，响应原路弹回

两种模式的消息流向对比示意（原题配图见 DNS - Iterative vs Recursive Query）。

迭代查询（Iterative）

标准 8 步：主机 → 本地 DNS → 根 → 本地 DNS → TLD → 本地 DNS → 权威 → 本地 DNS → 主机。每一步都由本地 DNS 服务器亲自出面去问下一级，问完拿着答案再问。

问题 答案
Step 1→2 之间，本地 DNS 先查哪里？ DNS Root（根服务器）
Step 2→3 之间，根服务器没有答案时，响应指向哪里？ DNS TLD
Step 4→5 之间，TLD 服务器没有答案时，响应指向哪里？ DNS Authoritative（权威服务器）
Step 6→7 之间，权威服务器返回的是什么类型的记录？ A 记录
迭代和递归，哪种被认为是"最佳实践"？ 迭代（Iterative）

递归查询（Recursive）

同样 8 步，但根服务器和 TLD 服务器会替你把请求转发下去，而不是把"下一步问谁"返回给本地 DNS：

问题 答案
Step 1→2 之间，本地 DNS 先查哪里？ DNS Root
Step 2→3 之间，根服务器把请求转发到哪里？ DNS TLD（注意：不是"告诉你去问 TLD"，而是代替你去问）
Step 4→5 之间，权威服务器把响应转发回哪里？ DNS TLD（原路按查询链条向上返回）
Step 6–8，响应沿原路返回给用户，最终类型是？ A 记录
哪种是最佳实践？ 仍然是 Iterative（迭代）

为什么迭代是最佳实践？

递归会让根/TLD 服务器承担"转发+等待"的额外负担——它们要保持这个请求的状态直到收到下游响应，而迭代模式下根/TLD 服务器答完一句话就可以立刻服务下一个请求，完全无状态。全球只有 13 组根服务器，必须用迭代方式把压力甩给本地 DNS 服务器（数量多得多），这样系统才扛得住。

📌 画图口诀：迭代查询的箭头图是"之"字形（本地 DNS 每次都要跑一个来回）；递归查询的箭头图是"波浪一路向上再一路向下"（根/TLD/权威像接力棒一样往下传，再原路弹回）。考试如果给你一张图，先看本地 DNS 是不是每一步都参与——参与就是迭代，不参与（问一次就等最终答案）就是递归。

三、DNS and HTTP delays

题目设定

点击链接前，浏览器本地未缓存 IP，需要经过 3 台 DNS 服务器才能拿到 IP：

  • 本地 DNS 缓存： ms
  • 第二台： ms
  • 第三台： ms

与 Web 服务器之间： ms。

解题总框架：把它当"关键路径"问题算，不要死背公式

这类题的本质是时间线记账：从点击链接到页面完全显示，把整个过程拆成一段一段的"阶段"，每个阶段要么必须等上一段结束才能开始（串行，时间要累加），要么可以和别的阶段同时进行（并行，只算最长的那条，不重复计入）。算总时间，就是把所有串行阶段的耗时依次相加。

DNS 解析（3 段全部串行，环环相扣） RTT₀=3ms RTT₁=47ms RTT₂=42ms ← 拿到 Web 服务器 IP

TCP + HTTP（拿到 IP 之后才能开始，也是串行） TCP 握手 1×RTT_HTTP GET+响应 1×RTT_HTTP ← 拿到 HTML 对象，总计 116ms

三个 DNS 阶段不能并行——每一步都要等上一步告诉你"该去问谁"才能问下一个；TCP+HTTP 也不能在 DNS 没结束前开始——因为还不知道服务器 IP。

判断"能不能并行"只看一件事：这个阶段的发起，是否依赖前一个阶段的结果？ 依赖就必须串行等待；互相独立（比如浏览器同时开 5 条连接去分别拿 5 张图片）才能并行。

Q1：网页只有一个 HTML 对象（无嵌入对象），忽略传输时间，从点击到收到对象要多久？

阶段 说明 是否可并行 耗时
DNS 查询 1 问本地 DNS 服务器，它不知道，转告下一级该问谁 否，依赖上一步 ms
DNS 查询 2 问第二台，还是没有最终答案，继续转 否 ms
DNS 查询 3 问第三台，拿到 Web 服务器的 IP 否 ms
TCP 三次握手 必须先有 IP 才能建连 否，依赖 DNS 结果 ms
HTTP GET + 响应 必须先建好连接才能发请求 否，依赖握手结果 ms
合计 116 ms

为什么是 ，不是 个：TCP 是"先握手、再传数据"的协议——第 1 个 RTT 花在三次握手上（连接建立好，但还没发任何 HTTP 内容），第 2 个 RTT 才是真正发 GET 请求、等服务器把 HTML 传回来。这两个 RTT 谁都不能省，也不能并行，因为握手不完成 TCP 连接都不存在，更别提发数据。

Q2：网页额外引用 6 个很小的对象（同一服务器），非持久 HTTP、不并行，总共要多久？

非持久 HTTP 意味着每个对象都是一次独立的新 TCP 连接（发完这个对象就断开，下一个对象要重新握手）；不并行意味着这些新连接必须一个接一个来，不能同时开。所以除了拿到 HTML 本身要 ，后面 6 个嵌入对象每个也都要重新走一遍"握手+收发"这 ，而且是排队串行：

本身个对象串行

这里可以把"基础 HTML 对象"也看成第 0 个对象——一共 个对象，每个都花 ，全部串行，所以也能写成 ms，两种算法等价，选你觉得顺手的那种。

Q3：同样 6 个对象，非持久 HTTP，但客户端支持最多 5 条并行 TCP 连接？

现在"不并行"的限制解除了，但依然是非持久连接——每个对象还是要各自握手。6 个对象要占用 6 条连接，但客户端手里只有 5 个连接名额，所以只能分批：第一批 5 个对象同时开连接、同时收发（因为并行，这一批只算 份 ，不是 份），剩下 1 个对象等第一批腾出名额后，再单独走一轮 ：

批次 对象 耗时（并行只算一份）
第 1 批 对象 1–5（5 个同时握手+收发） ms
第 2 批 对象 6（剩下这 1 个单独再来一轮） ms

批次数 ，所以：

基础对象批，每批

⚠️ 易错点：很多人会把 "5 条并行" 理解成"6 个对象反正能同时挤下，直接按 1 批算"——错，并行连接数是硬性上限，超过 5 个就必须排下一批，这也是为什么要用 （向上取整）而不是简单除法。

Q4：同样 6 个对象，最多 5 条并行连接，改用持久 HTTP？

持久 HTTP 的关键变化：TCP 连接只需要建一次，后面所有对象都复用这条（或这几条并行的）已经建好的连接，不用再重复握手。所以基础 HTML 对象依然是全新连接、依然要 （握手+收发）；但 6 个嵌入对象走的是已经握好手的连接，每一批只需要 发请求+收响应这 1 个 RTT，不再需要额外的握手 RTT：

批次 对象 耗时（复用连接，只需 1×RTT_HTTP）
第 1 批 对象 1–5（5 个并行，复用已建好的连接） ms
第 2 批 对象 6 ms

基础对象（仍需全新握手）批，每批

⚠️ 持久连接省的是"重复握手"，不是"第一次握手"：基础对象那 一分都不能省——第一条连接总得先握手才能存在。"持久"只在后续对象身上生效，它们不需要再单独握手，所以每批只算 而不是 ——这正是 Q3（非持久并行）和 Q4（持久并行）唯一的区别。

Q5：三种方式里哪个最快？

（持久并行）最快

Nonpersistent-serial 260 ms

Nonpersistent-parallel 164 ms

Persistent-parallel 140 ms（最快）

同样 92ms 的 DNS 开销打底，差距全部来自"是否重复握手"+"是否能同时发多个对象"。

排序：Persistent-parallel（140ms） < Nonpersistent-parallel（164ms） < Nonpersistent-serial（260ms）。三者的 DNS 部分完全一样（都是 92ms），差距只来自后面处理 6 个嵌入对象的方式——是否要重复握手、是否能同时发多个。

通用公式 + 举一反三

设 = 嵌入对象数（不含基础 HTML 本身）， = 客户端最大并行连接数：

非持久串行

非持久并行

持久并行

三条公式长得很像，记差异点：非持久 vs 持久——嵌入对象那一项前面的系数是 还是 （要不要重复握手）；串行 vs 并行——嵌入对象是简单乘 ，还是先 分批再乘。特殊情况：如果 （并行数够多，一次性全发完），，公式退化成"嵌入对象只花 1 轮"，这也是并行 HTTP 理论上能达到的最好情况。

举一反三（换一组数字自己验算）：假设 ms， ms，网页有 个嵌入对象，客户端最多开 条连接：

模式 公式代入 结果
非持久串行 ms
非持久并行 ms
持久并行 ms

（：3+3+3+1，共 4 批）自己动手代一遍，比死记公式更不容易在考场上套错数字。

📌 这道题是 Week 05 tutorial（DNS and HTML） 的原题同款，建议两篇对照着刷。

四、The HTTP GET Message

题目：给定报文

GET /kurose_ross_sandbox/interactive/quotation2.htm HTTP/1.1
Host: gaia.cs.umass.edu
Accept: text/plain, text/html, image/jpeg, image/png, audio/mpeg, audio/mp4, video/mp4, video/mpeg,
Accept-Language: en-us, en-gb;q=0.2, en;q=0.5, fr, fr-ch, fi
If-Modified-Since: Thu, 10 Sep 2026 20:08:25 -0700
User Agent: Mozilla/5.0 (...) Firefox/9.0.1
Q 答案
1. 请求的文件名？ quotation2.htm
2. 客户端跑的是哪个 HTTP 版本？ HTTP/1.1
3. 客户端接受 html 文件吗？ True（Accept 里有 text/html）
4. 客户端接受 jpeg 图片吗？ True（Accept 里有 image/jpeg）
5. 客户端最偏好哪种英语？ 美式英语（en-us）——没写 q 值的语言默认 ，是列表里最高的
6. 客户端最不偏好哪种英语？ 英式英语（en-gb, q=0.2）——q 值最低
7. 客户端接受德语吗？ False（Accept-Language 里没有 de）
8. 客户端本地已经有缓存副本吗？ True——报文里带了 If-Modified-Since，说明客户端已经有一份旧副本，只是想确认有没有更新

📌 q 值规则：Accept-Language 里每个语言标签可以带 ;q=x.x 表示偏好权重（0~1），不写 q 就默认 1，数值越大越偏好。这题的陷阱就是"没写 q 值 ≠ 不偏好"，反而是最偏好。 If-Modified-Since 出现 = 客户端在做条件 GET，说明本地已有缓存——这和 Week 03 讲义、Week 04 的 Wireshark tutorial 里条件 GET 的判断逻辑完全一致。

五、The HTTP RESPONSE Message

题目：给定报文

HTTP/1.1 200 OK
Date: Fri, 11 Sep 2026 03:12:37 +0000
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 11 Sep 2026 03:12:57 +0000
ETag: 17dc6-a5c-bf716880.
Content-Length: 4340
Keep-Alive: timeout=55, max=77
Connection: Keep-alive
Content-type: text/html
Q 答案
1. HTTP 1.0 还是 1.1？ HTTP/1.1
2. 服务器成功发送文档了吗？ Yes（状态码 200 OK）
3. 文档多大（字节）？ 4340 字节（Content-Length）
4. 连接是持久的还是非持久的？ 持久（persistent）——Connection: Keep-alive
5. 服务器返回的文件类型？ text/html
6. 服务器名称和版本？（格式 server/x.y.z） Apache/2.2.3
7. 如果资源内容变了，ETag 会跟着变吗？ Yes——ETag 是资源内容的唯一标识，内容一变 ETag 必变

📌 ETag vs Last-Modified：两者都能用于条件 GET（If-None-Match 配 ETag，If-Modified-Since 配 Last-Modified），ETag 更精确（基于内容哈希，Last-Modified 只精确到秒，同一秒内多次修改会漏检）。这题和上一题（GET 报文）合起来看，正好是一问一答的完整 HTTP 事务。

六、Browser Caching

题目

RTT（客户端-服务器）= 30 ms；服务器发送一个对象的传输时延 = 0.5 ms；其余不含对象的消息传输时延忽略不计。客户端用 HTTP 1.1 + If-Modified-Since，连续发 50 个请求（发完一个等回复再发下一个）。假设这 50 个对象中有 30% 没有变化过（会命中 304）。

Q1：从发第一个请求到最后一个请求完成，一共经过多久？

每个请求都要 1 个 RTT（不管命中 304 还是拿到新内容，请求-响应都要走一个来回）；只有"没命中缓存"（70% 的对象）才需要额外传输对象本身的时间：

每个请求都要一个来回未命中，需要传对象

📌 两个陷阱： 1. 是串行发送（"等回复再发下一个"），所以 50 次请求至少要 ，不能想当然按并行算。 2. 只有 30%（未命中缓存的那部分是 70%）才产生对象传输时延——命中缓存的 30% 只收到一个 304 Not Modified（几乎零字节），不产生额外传输时延。别把 30% 和 70% 搞反：题目说"30% 未变化"，未变化的走 304（省流量），变化的（70%）才需要重新传对象。

七、Electronic Mail and SMTP

题目：Alice 给 Bob 发邮件

标准 Figure 2.15 流程图：Alice's agent →(2)→ Alice's mail server →(4)→ Bob's mail server →(6)→ Bob's agent（1、3、5 是每一跳内部"写入消息队列/邮箱"的动作）。假设 Bob 和 Alice 的用户代理都用 POP3 协议。

Alice's agent Alice's mail server Bob's mail server Bob's agent (2) SMTP (4) SMTP (6) POP3

简化流程示意，未画出①③⑤的本地队列/邮箱写入（原题配图即教材 Figure 2.15，见 Electronic Mail and SMTP）。

Q 答案
1. Point 2 用什么协议？ SMTP（Alice 的邮件客户端 → Alice 的邮件服务器）
2. Point 4 用什么协议？ SMTP（Alice 的邮件服务器 → Bob 的邮件服务器，服务器之间也是 SMTP，不是 POP3）
3. Point 6 用什么协议？ POP3（Bob 的邮件服务器 → Bob 的邮件客户端，取信用 POP3）
4. SMTP 用 TCP 还是 UDP？ TCP
5. SMTP 是"推"还是"拉"协议？ 推（push）——发送方主动把邮件推给接收方服务器
6. POP3 是"推"还是"拉"协议？ 拉（pull）——客户端主动去服务器把邮件取回来
7. SMTP 用什么端口？ 25
8. POP3 用什么端口？ 110

⚠️ 全程都是 SMTP，只有最后一步取信才是 POP3（或 IMAP）——这是最容易搞混的一点：很多人以为"发邮件用 SMTP，收邮件的通道也可能是别的协议"，但服务器到服务器之间永远是 SMTP，POP3/IMAP 只负责"用户代理从自己的邮件服务器上把信取下来"这最后一步。Week 03 讲义 里有 POP3 / IMAP 的完整对比表。

八、A Comparison of Client-Server and P2P File Distribution Delays

题目设定

文件大小 Gbits，分发给 8 个 peer。服务器上传速率 Mbps。

8 个 peer 的上传速率： Mbps 8 个 peer 的下载速率： Mbps

Q1：客户端-服务器（C/S）模型下，分发完成的最短时间？

Q2：这个最短时间的根本原因是什么？（答 's' 表示服务器，或 'ci' 表示某个客户端）

瓶颈是 那一项（）——服务器的上传带宽是唯一瓶颈：

Q3：P2P 模型下，分发完成的最短时间？

Q4：这个最短时间的根本原因是什么？（答 's' 服务器 / 'c' 客户端 / 'cu' 客户端+服务器上传总和）

瓶颈是 那一项（下载最慢的那个 peer，即 Mbps）——卡在某个客户端自己的下载带宽上：

📌 三项对比： - C/S 模式： —— 服务器要把文件发 遍，服务器带宽几乎总是瓶颈（除非某个客户端下载速度奇慢） - P2P 模式： —— 第一项是 不是 （服务器只需完整发一份出去，剩下靠 peer 之间互传），这是这个公式最容易写错的地方 - 本题体现的规律：C/S 卡在"服务器要发 8 份"（ s），P2P 卡在"下载最慢的那个 peer"（ s）——P2P 更快，但快的原因和 C/S 的瓶颈原因完全不同，做题时两个模型都要分别找各自的瓶颈项，不能混着比。

完整公式推导和 的极限分析见 Week 04 讲义 的 P2P 部分。

考点重点（第二章全览）

  1. DNS 4 类 RR：A / NS / CNAME / MX，记录格式 (name, value, type, ttl)。
  2. 迭代 vs 递归：迭代——本地 DNS 每步亲自出马（"之"字形）；递归——根/TLD 代为转发（接力再弹回）；迭代是最佳实践，因为根/TLD 服务器保持无状态。
  3. DNS+HTTP 综合时延四种情形的通用公式：非持久串行 ，非持久并行 ，持久并行 。
  4. Accept-Language 的 q 值：不写默认 （最高优先级），别被"没写"误导成"不要"。
  5. If-Modified-Since 出现 = 本地已有缓存；ETag 随内容变化而变化，比 Last-Modified 更精确。
  6. 浏览器条件缓存的时延公式：未命中比例——串行请求，只有未命中缓存的对象才产生额外传输时延。
  7. SMTP 贯穿"发送方到接收方服务器"全程（含服务器到服务器），POP3/IMAP 只负责用户代理从自己的服务器取信这最后一步。SMTP 用 TCP + 端口 25（push），POP3 用端口 110（pull）。
  8. C/S vs P2P 分发时延公式：C/S 卡在 （服务器带宽），P2P 卡在 、 或 三者之一——P2P 公式第一项是 不是 ，这是全课程最容易记错的一条公式。

上一篇 / 下一篇

Chapter 1（网络性能，Week 1–2，另外 8 题）见 COMP5416 Kurose 交互题库题解：第一章。

Chapter 3（传输层，全部 9 题，期末范围，非期中必做）见 COMP5416 Kurose 交互题库题解：第三章。