19.网络协议思考题答案
# 网络协议原理 · 思考题与作业 · 参考答案
覆盖 17 篇全部思考题。基础题给结论，进阶题给推导，动手题给命令和思路框架。
# 第 01 篇·通过看新闻熟悉网络
# 基础思考题
Q1：DNS 解析过程
用户输入 www.163.com
→ 浏览器缓存（~1min）
→ OS hosts 文件（/etc/hosts）
→ 路由器缓存
→ ISP 递归 DNS 服务器
→ 根 DNS（.）→ 返回 .com 的 NS
→ .com 顶级域 DNS → 返回 163.com 的 NS
→ 163.com 权威 DNS → 返回 www.163.com 的 IP
→ 返回 IP 给浏览器
如果 /etc/hosts 配置了 127.0.0.1 www.163.com，DNS 查询走到第二步就停止了——hosts 文件优先级高于 DNS。
Q2：TCP 三次握手为什么是三次？
两次的缺陷：服务端 SYN+ACK 发出后无法确认客户端收到了——如果网络延迟导致旧 SYN 包半夜到达，服务端误开连接。三次让客户端用最后一个 ACK 确认"我收到了你的 SYN+ACK，而且我要的是这次连接"。
如果最后一个 ACK 丢失：服务端处于 SYN_RCVD（认为连接建立了一半），等待重传的 ACK。超时后（通常 63s）放弃。客户端处于 ESTABLISHED（认为自己已连上），但发第一个数据包时服务端可能会 RST 或忽略。
Q3：一次 HTTPS 请求涉及的所有协议
| 层 | 协议 | 职责 |
|---|---|---|
| 应用层 | HTTP/HTTPS | 请求/响应语义 |
| 应用层 | DNS | 域名→IP |
| 应用层 | TLS | 加密通信 |
| 传输层 | TCP | 可靠传输 |
| 网络层 | IP | 路由寻址 |
| 链路层 | 以太网 | MAC帧传输 |
Q4：HTTP 状态码匹配
| 场景 | 状态码 |
|---|---|
| 资源不存在 | 404 Not Found |
| 永久移走 | 301 Moved Permanently |
| 服务器异常 | 500 Internal Server Error |
| 缓存可用 | 304 Not Modified |
| 需要登录 | 401 Unauthorized |
Q5：Keep-Alive 的作用
- 关闭 Keep-Alive：100 个资源需要 100 个 TCP 连接（每个请求-响应后断开）
- 开启 Keep-Alive：浏览器复用连接，同一域名最多 6 个并发连接，100 个资源排队复用 ≈ 6 个连接。节省 94 次 TCP 握手。
- 假设 RTT=50ms，节省
94 × 50ms = 4.7s
# 进阶思考题
Q1：HTTPS 能防 DNS 劫持吗？
不能直接防。DNS 劫持发生在域名解析环节（DNS 阶段），HTTPS 保护的是通信环节（TCP 之后）。但 HTTPS 有间接防护：劫持到假 IP 后，假服务器拿不出对应的合法证书，浏览器会弹证书警告。用户点"继续访问"的话就防不住。
防御 DNS 劫持的建议：使用 HTTPDNS（绕过运营商 DNS）、DNSSEC（签名验证）、DoH（DNS over HTTPS）。
Q2：CDN 的 DNS 全局负载均衡
GSLB（全局负载均衡）在 DNS 解析环节介入：用户的 ISP DNS 查询 cdn.example.com 时，GSLB 看到请求来自北京 IP 的 DNS 服务器，返回北京 CDN 节点的 IP。本质是把 DNS 用作"请求来源→最近节点"的映射服务。
Q3：HTTP/2 的队头阻塞
HTTP/2 解决了 HTTP 层队头阻塞（多路复用流水线），但TCP 层仍有队头阻塞：TCP 按序交付，如果中间一个 TCP 包丢了，后面的包即使已经到达也要等重传才能交给上层。QUIC 为每个流独立编号和重传——流 A 丢了包不影响流 B 的数据交付。
Q4：curl https 抓包序列
→ TCP: SYN
← TCP: SYN+ACK
→ TCP: ACK
→ TLS: ClientHello（支持的密码套件）
← TLS: ServerHello + Certificate + ServerKeyExchange
→ TLS: ClientKeyExchange + ChangeCipherSpec + Finished
← TLS: ChangeCipherSpec + Finished
→ HTTP: GET / HTTP/1.1
← HTTP: HTTP/1.1 200 OK + 响应体
Q5：弱网优化方案
- DNS 预解析：
<link rel="dns-prefetch">提前解析域名 - 连接预建：
<link rel="preconnect">提前 TCP+TLS - QUIC/HTTP3：0-RTT 握手 + 连接迁移（换网不断连）
- 资源预加载：
<link rel="preload">关键资源 - 图片懒加载 + WebP 压缩
# 第 02 篇·通过购物熟悉加密
# 基础思考题
Q1：对称加密 vs 非对称加密
| 对称（AES） | 非对称（RSA/ECC） | |
|---|---|---|
| 密钥 | 加密解密用同一把 | 公钥加密，私钥解密 |
| 速度 | 极快（硬件 AES 几十 GB/s） | 慢（RSA 比 AES 慢千倍） |
| 安全性 | 密钥泄露=全翻 | 公钥公开也安全 |
| 用途 | 数据加密 | 密钥交换 + 签名 |
HTTPS 先非对称后对称的原因：非对称太慢不能加密全量数据，但可以安全地交换对称密钥。各取所长。
Q2：中间人攻击完整过程
客户端 ←→ 中间人（假装服务器，给假证书）←→ 真实服务器
HTTPS 防 MITM：① 证书验证服务器身份 ② 中间人无法伪造被 CA 签名的合法证书 ③ 浏览器弹出证书警告。
用户点"继续访问"就完蛋了——这是所有 HTTPS 安全边界的最后防线。
Q3：浏览器证书检查
- 证书链完整性（Root→Intermediate→Server）
- 域名匹配（证书 CN/SAN 和访问 URL 一致）
- 有效期（当前时间在 notBefore 和 notAfter 之间）
- 证书吊销状态（OCSP/CRL）
- 密钥用法（Key Usage/Extended Key Usage 匹配 TLS Server）
Q4：TLS 握手 RTT
- TLS 1.2：2-RTT（ClientHello→ServerHello+Cert→ClientKeyExchange→Finished）
- TLS 1.3：1-RTT（ClientHello 附带密钥猜测→ServerHello+加密数据→Finished）
Q5：前向安全性
私钥泄露后，过去截获的密文能否被解密？能=无前向安全，不能=有前向安全。
- RSA 密钥交换：攻击者存了所有密文，某天拿到私钥→解密所有历史记录。无前向安全。
- ECDHE：每次连接生成临时密钥对（ephemeral），用完即丢。私钥泄露只能解密本次连接。有前向安全。
# 进阶思考题
Q1：1.1 节小周场景——合法假证书怎么办？
2011 年 DigiNotar CA 被黑，攻击者拿到了合法签发权限，伪造了 *.google.com 证书，伊朗 30 万用户被中间人。防御手段：
- 证书透明度（Certificate Transparency）：所有 CA 签发的证书必须公开记录到 CT Log
- HPKP（已废弃）/Expect-CT：告知浏览器"本网站只接受这些公钥"
- CAA DNS 记录：网站声明"只有 Let's Encrypt 能给我签证书"
Q2：公共 WiFi 安全性
| 纯 HTTP | 自签名 HTTPS | |
|---|---|---|
| 数据加密 | ❌ 明文 | ✅ 加密 |
| 身份验证 | ❌ 无 | ❌ 未验证（自签名） |
| MITM 防护 | ❌ 零防护 | ⚠️ 加密但身份不可信 |
结论：都不安全。自签名至少数据不裸奔，但攻击者可以做自签名的 MITM。公开 WiFi 上只能用正规 CA 签发的 HTTPS。
Q3：OCSP 软失败的缺陷
大多数浏览器默认 OCSP 软失败——查询 OCSP 失败时"放过"证书（怕 OCSP 服务器挂了导致全网瘫痪）。2012 年事件中如果强制硬检查，假证书会被拦截。代价是全网脆断风险。OCSP Stapling 是折中方案：服务器自己定期从 OCSP 拿签名后的状态，附在 TLS 握手中，浏览器不用实时查。
Q4：量子计算 vs 加密
- RSA/ECC：Shor 算法能在多项式时间破解——量子计算机足够大后直接作废
- AES-128：Grover 算法只能把暴力搜索从 2^128 降到 2^64——AES-256 仍安全（2^128 搜不到）
后量子密码候选：CRYSTALS-Kyber（密钥封装）、CRYSTALS-Dilithium（签名）。NIST 2024 年已标准化。
Q5：TLS 1.3 0-RTT 的使用策略
可以安全用 0-RTT 的请求：幂等的 GET 请求（获取首页静态内容），丢了重发无副作用。
不可用 0-RTT 的请求：非幂等的 POST/PUT/DELETE，被重放会重复扣款。
淘宝策略：0-RTT 仅用于首屏静态资源，所有涉及交易的操作走完整握手。
# 第 03 篇·从0到1部署电商网站
# 基础思考题
Q1：Nginx 反向代理的作用
- SSL 终止：浏览器和 Nginx 之间 HTTPS，Nginx 和后端之间 HTTP（内网安全）
- 负载均衡：轮询 / IP Hash / 最少连接，把请求分到多台后端
- 静态文件服务：
root /var/www/html，静态资源不经过后端 - 安全防护：限制请求速率、过滤恶意 IP、隐藏后端真实地址
Q2：MySQL 主从复制原理
主库（Master）把每个写操作记录到 binlog → 从库（Slave）的 I/O 线程拉取 binlog 写成 relay log → 从库 SQL 线程执行 relay log。异步复制：主库不等待从库确认，从库可能有延迟（秒级）。
Q3：Redis 缓存策略
| 策略 | 原理 | 适用 |
|---|---|---|
| Cache-Aside | 先查缓存→miss查DB→写缓存 | 最常用 |
| Read-Through | 缓存层代查DB | 缓存抽象更好 |
| Write-Through | 同步写缓存+DB | 强一致性 |
| Write-Behind | 异步写DB | 高吞吐可容忍少量丢 |
Q4：CDN 工作原理
用户请求 cdn.example.com/img.jpg → DNS 解析到最近的 CDN 边缘节点 → 边缘节点检查是否有缓存 → 有则直接返回 → 没有则回源到源站拉取 → 缓存后返回。
# 第 04 篇·请求网络的通用流程
# 基础思考题
Q1：OSI 七层 vs TCP/IP 四层
| OSI | TCP/IP | 协议 |
|---|---|---|
| 应用层 + 表示层 + 会话层 | 应用层 | HTTP/DNS/TLS |
| 传输层 | 传输层 | TCP/UDP |
| 网络层 | 网络层 | IP/ICMP |
| 数据链路层 + 物理层 | 网络接口层 | 以太网/WiFi |
Q2：封装与解封装
发送方：应用数据 → +TCP头 → +IP头 → +MAC头 → 物理层比特流 接收方：物理层 → 去MAC头 → 去IP头 → 去TCP头 → 还原应用数据
每层只看自己的头部，不看上层内容。这就是分层抽象的威力。
Q3：MTU 和分片
以太网 MTU=1500 字节。IP 包超过 MTU 时路由器分片（Fragment）。但现代网络中建议使用 Path MTU Discovery 避免分片——分片增加了丢包风险和重组开销。
# 第 05 篇·网络编程模型的概念
# 基础思考题
Q1：IP 地址分类
| 类别 | 范围 | 默认掩码 |
|---|---|---|
| A | 1.0.0.0 - 126.255.255.255 | /8 |
| B | 128.0.0.0 - 191.255.255.255 | /16 |
| C | 192.0.0.0 - 223.255.255.255 | /24 |
| 私有 | 10/8, 172.16/12, 192.168/16 | 内网 |
Q2：端口号的本质
端口号是 16 位无符号整数（0-65535），用于区分同一 IP 上不同进程。0-1023 是知名端口（80=HTTP，443=HTTPS），需要 root 权限绑定。
Q3：DNS 记录类型
| 类型 | 含义 | 示例 |
|---|---|---|
| A | IPv4 地址 | example.com → 93.184.216.34 |
| AAAA | IPv6 地址 | |
| CNAME | 别名 | www → example.com |
| MX | 邮件服务器 | |
| TXT | 文本（SPF/DKIM） | |
| NS | 权威 DNS 服务器 |
# 第 06 篇·传输协议 TCP 和 UDP
# 基础思考题
Q1：TCP 可靠传输的四机制
- 序号 + 确认：每个字节有唯一序号，接收方 ACK 告知"期待下一个字节号"
- 超时重传：RTO 动态计算（Jacobson 算法），超时未 ACK 则重传
- 校验和：TCP 头包含 16 位校验和，检测传输错误
- 流量控制：接收方通告窗口大小（rwnd），防止缓冲区溢出
Q2：TCP 拥塞控制四阶段
- 慢启动：cwnd 从 1 MSS 开始，每 RTT 翻倍（指数增长）
- 拥塞避免：达到 ssthresh 后每 RTT +1 MSS（线性增长）
- 快重传：收到 3 个重复 ACK 立即重传（不等超时）
- 快恢复：重传后不回到慢启动，而是 ssthresh=cwnd/2，cwnd=ssthresh+3
Q3：UDP 适用场景
视频通话、游戏、DNS、IoT 传感器——延迟敏感 > 丢包容忍的场景。
# 进阶思考题
Q1：TCP 的 RTO 计算
RTO = SRTT + 4 × RTTVAR。SRTT（平滑 RTT）= (1-α)×旧SRTT + α×新RTT（α=1/8）。RTTVAR=（平滑偏差）。动态适应网络波动。
Q2：BBR 算法 vs CUBIC
CUBIC（默认）：基于丢包的拥塞控制——丢包=拥塞。问题：缓冲膨胀（bufferbloat）导致高延迟。
BBR（Google 2016）：基于带宽和 RTT 的模型——不依赖丢包信号。YouTube 部署后吞吐提升 40%。
# 第 07 篇·Socket 的发展和设计
# 基础思考题
Q1：Socket 核心函数
int sockfd = socket(AF_INET, SOCK_STREAM, 0); // 创建
bind(sockfd, &addr, sizeof(addr)); // 绑定
listen(sockfd, backlog); // 监听
int clientfd = accept(sockfd, &cliaddr, ...); // 接受
read(clientfd, buf, size); // 读
write(clientfd, buf, size); // 写
close(clientfd); // 关闭
Q2：TCP Socket 状态机
CLOSED → connect() → SYN_SENT → 收到 SYN+ACK → ESTABLISHED → close() → FIN_WAIT_1 → 收到 ACK → FIN_WAIT_2 → 收到 FIN → TIME_WAIT（2MSL≈60s）→ CLOSED
Q3：TIME_WAIT 为什么需要？
两个原因：① 确保最后的 ACK 被对方收到（如果丢了对端会重发 FIN）② 防止旧连接的残留数据包被新连接误收。
# 进阶思考题
Q1：BIO vs NIO vs AIO
| BIO | NIO | AIO | |
|---|---|---|---|
| 读操作 | 阻塞等数据 | 立即返回"有没有数据" | 内核读完通知你 |
| 线程模型 | 1连接1线程 | 1线程管N连接 | 回调/事件 |
| C10K 表现 | ❌ 崩 | ✅ 能扛 | ✅ 最优 |
| 复杂度 | 低 | 中 | 高 |
# 第 08 篇·传输数据的设计思想
# 基础思考题
Q1：序列化的本质
把内存里的结构化数据（对象/结构体）按约定格式转换成一串字节，对端按同样格式还原。
Q2：JSON vs Protobuf
| JSON | Protobuf | |
|---|---|---|
| 可读性 | ✅ 人类可读 | ❌ 二进制 |
| 大小 | 大（字段名重复） | 小（数字 tag 替代字段名） |
| 解析速度 | 慢（字符串解析） | 快（预生成代码直接映射） |
| Schema | 无 | 必须预定义 .proto |
Q3：大端小端
大端：高位字节在低地址（网络字节序）。小端：低位字节在低地址（x86）。htonl()/ntohl() 做转换。
# 第 09 篇·网络域名解析的流程
# 基础思考题
Q1：DNS 查询的两种方式
- 递归查询：客户端 → ISP DNS，"你帮我查到最终结果"。ISP 替你走完整个链路。
- 迭代查询：ISP DNS → 根 → .com → 权威，每一步返回"我也不知道，但你去问 X"。
Q2：为什么 DNS 改记录要等 48 小时？
各级 DNS 缓存的 TTL 叠加。权威 DNS 改了一个 A 记录的 TTL=86400（24h），但全球 ISP DNS 的缓存过期时间可能不一样——最后一个缓存清空前用户仍会拿到旧 IP。最长可能等 48 小时（有些 ISP 忽略短 TTL）。
Q3：DNS 污染和劫持
- 劫持：DNS 请求被重定向到假 DNS 服务器，返回假 IP
- 污染：假响应在真响应之前到达，被客户端接受
- 防御：DoH（DNS over HTTPS，端口 443 无法被中间设备识别为 DNS）
# 第 10 篇·HTTP 服务设计流程
# 基础思考题
Q1：HTTP 服务三大并发模型对比
| 多进程（Apache） | 多线程（Tomcat） | 事件驱动（Nginx/Node） | |
|---|---|---|---|
| 连接数 | 几百 | 几千 | 十万 |
| 内存 | 每进程~10MB | 每线程~2MB | 极低 |
| CPU 开销 | 进程切换 | 线程切换 | 几乎无 |
| 编程复杂度 | 简单 | 中 | 高（回调地狱） |
Q2：为什么 Nginx 比 Apache 快？
Nginx 的事件驱动 + epoll 模型用极少的 worker 进程处理成千上万连接——不阻塞，不等 I/O。Apache 的 prefork 模式每个连接一个进程，10000 连接 = 10000 进程 ≈ 100GB 内存。
Q3：负载均衡算法
- 轮询（Round Robin）：公平但不管服务器负载
- 最少连接（Least Connections）：适合长连接场景
- IP Hash：同一 IP 永远到同一台（会话保持）
- 加权轮询：好机器多分，差机器少分
# 第 11 篇·HTTP 协议设计思想
# 基础思考题
Q1：HTTP 动词的语义
| 动词 | 安全 | 幂等 | 用途 |
|---|---|---|---|
| GET | ✅ | ✅ | 读取 |
| POST | ❌ | ❌ | 创建 |
| PUT | ❌ | ✅ | 全量更新 |
| DELETE | ❌ | ✅ | 删除 |
| PATCH | ❌ | ❌ | 部分更新 |
| HEAD | ✅ | ✅ | 只取头 |
Q2：RESTful API 设计原则
- 资源用 URL 标识：
/users/123 - 用 HTTP 动词操作：GET 读，POST 创建
- 无状态：每个请求自包含
- 用 HTTP 状态码表达结果：201 Created，404 Not Found
Q3：常见 HTTP 状态码
| 分类 | 常见 | 含义 |
|---|---|---|
| 2xx | 200/201/204 | 成功 |
| 3xx | 301/302/304 | 重定向/缓存 |
| 4xx | 400/401/403/404 | 客户端错误 |
| 5xx | 500/502/503 | 服务端错误 |
# 第 12 篇·HTTPS 协议设计策略
# 基础思考题
Q1：TLS 1.2 vs 1.3 关键差异
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| 握手 RTT | 2 | 1 |
| 密钥交换 | RSA + (EC)DHE | 仅 (EC)DHE |
| 对称密码 | 多种 | AES-GCM / ChaCha20 |
| 安全性 | 有已知攻击 | 更强 |
Q2：证书类型
| 类型 | 验证深度 | 典型用途 |
|---|---|---|
| DV（域名验证） | 仅验证域名控制权 | 个人网站 |
| OV（组织验证） | 验证域名 + 组织 | 企业官网 |
| EV（扩展验证） | 最严格，地址栏显示公司名 | 银行、支付 |
Q3：HSTS 的作用
Strict-Transport-Security 响应头告诉浏览器"本网站永远只用 HTTPS"。防止 SSL Strip 攻击（中间人把 HTTPS 降级为 HTTP）。首次访问后浏览器记住这句话，下次在地址栏输入 http:// 也会自动跳 https://。
# 第 13 篇·HTTP 连接和跳转
# 基础思考题
Q1：301 vs 302
- 301 永久重定向：浏览器缓存这个跳转，下次直接访问新地址——搜索引擎更新索引
- 302 临时重定向：每次还问原地址——不影响 SEO
Q2：HTTP/1.1 的 Keep-Alive
Connection: keep-alive 让 TCP 连接复用，省去重复握手。Keep-Alive: timeout=5, max=100 表示空闲 5 秒断开或处理 100 个请求后断开。
Q3：HTTP/2 多路复用
一个 TCP 连接上多个 Stream 并发，互不阻塞。Stream 有优先级（Priority），重要资源（CSS）优先传输。解决了 HTTP/1.1 应用层队头阻塞。
# 第 14 篇·HTTP 代理和缓存设计
# 基础思考题
Q1：正向代理 vs 反向代理
| 正向代理 | 反向代理 | |
|---|---|---|
| 部署方 | 客户端 | 服务端 |
| 谁受益 | 客户端 | 服务端 |
| 例子 | 公司代理、VPN | Nginx、CDN |
| 作用 | 翻墙、匿名 | 负载均衡、缓存 |
Q2：缓存控制头
Cache-Control: max-age=3600（缓存 1 小时）Cache-Control: no-cache（每次都验证 ETag）Cache-Control: no-store（完全不缓存）ETag: "abc123"（内容指纹）
Q3：CDN 缓存策略
边缘节点缓存静态资源（图片/CSS/JS），根据 Cache-Control + Surrogate-Control（CDN 专用）决定缓存时长。回源率越低效果越好。
# 第 15 篇·如何去排查网络故障
# 基础思考题
Q1：逐层排障法
| 步骤 | 命令 | 检查什么 |
|---|---|---|
| ① | ping IP | 网络层可达 |
| ② | telnet IP port | 传输层端口 |
| ③ | curl -v URL | 应用层 HTTP |
| ④ | traceroute IP | 路由路径 |
| ⑤ | tcpdump -i eth0 port 80 | 抓包分析 |
Q2：ping 能通但 telnet 不通
ping 通=网络层 OK。telnet 不通=端口未开放或防火墙拦截。检查服务是否在监听（netstat -an | grep PORT）、防火墙规则（iptables -L）。
Q3：curl 返回 502 Bad Gateway
Nginx 收到了请求但后端服务没响应。检查后端进程是否活着、端口是否正确、超时设置是否太短。
# 第 16 篇·WebSocket 实时通信
# 基础思考题
Q1：WebSocket vs HTTP 长轮询
| 长轮询 | WebSocket | |
|---|---|---|
| 连接数 | 每请求一个 | 一个持久连接 |
| 开销 | HTTP 头每轮询都有 | 帧协议，开销极小 |
| 服务端推送 | 模拟（等请求到才回） | 原生双向 |
| 延迟 | 轮询间隔 | <1ms |
Q2：WebSocket 握手
客户端发 Upgrade: websocket → 服务器回 101 Switching Protocols → 后续走 WebSocket 帧协议。关键：复用 HTTP 80/443 端口，不需要额外开端口。
Q3：心跳机制
WebSocket 没有内置心跳。应用层实现 Ping 帧（opcode=9）和 Pong 帧（opcode=10），防止代理/负载均衡器因空闲超时断开连接。建议 30 秒 Ping 一次。
# 第 17 篇·HTTP3 与 QUIC 协议
# 基础思考题
Q1：QUIC 相对 TCP 的四大优势
- 0-RTT 握手（复用会话时）
- 连接迁移（换网不换 Connection ID）
- 无队头阻塞（每流独立重传）
- 用户态实现（可快速迭代）
Q2：QUIC 怎么做到连接迁移？
TCP 用四元组（源 IP+Port+目标 IP+Port）标识连接——WiFi→4G 时源 IP 变了，TCP 连接断。QUIC 用 Connection ID（64 位随机数）标识，IP 变了 ID 不变→连接无缝切换。
Q3：QUIC 的拥塞控制
QUIC 在用户态实现了类似 TCP CUBIC 的拥塞控制算法，但可以自由切换——应用可以选 BBR、Copa 等新算法，不需要改内核。这是 QUIC 相比 TCP 最大的架构优势。
# 自测：全书掌握度检查
- 从浏览器输入 URL 到页面显示——至少经过哪 7 个步骤？每步涉及什么协议？
- TCP 为什么是三次握手？TLS 1.2 握手需要几个 RTT？
- HTTP/1.1、HTTP/2、HTTP/3 的核心区别是什么？
- WebSocket 和 HTTP 的本质区别是什么？
- 网络排障三步铁律是什么？为什么顺序不能颠倒？
答案在本总结文件的 §18（贯通四句话）到 §20（诊断表）中。答不出任一题，回到对应篇章的速通卡重读。
