diff --git a/notes/计算机网络 - 应用层.md b/notes/计算机网络 - 应用层.md
index b92e40e1..8fab8730 100644
--- a/notes/计算机网络 - 应用层.md
+++ b/notes/计算机网络 - 应用层.md
@@ -16,6 +16,8 @@
* [3. DNS 解析域名](#3-dns-解析域名)
* [4. HTTP 请求页面](#4-http-请求页面)
* [附录：实测](#附录实测)
+ * [A1 访问网页各阶段的耗时](#a1-访问网页各阶段的耗时)
+ * [A2 DNS 的 TTL 与 CNAME](#a2-dns-的-ttl-与-cname)
* [参考资料](#参考资料)
@@ -32,11 +34,30 @@ DNS 是一个分布式数据库，提供了主机名和 IP 地址之间相互转
主机到本地 DNS 服务器是递归查询，主机只等最终结果；本地 DNS 服务器到其它服务器是迭代查询，由它自己一步步问下去。每一级的结果都按 TTL 缓存，所以大多数查询在本地 DNS 服务器甚至主机上就能得到结果。
+TTL 是每条记录自带的缓存时间，单位为秒，由权威服务器给出，缓存中的记录每过一秒剩余时间减 1。例如把公共 DNS 223.5.5.5 作为本地 DNS 服务器，查询 www.jd.com（dig 实测，见[附录 A2](#a2-dns-的-ttl-与-cname)）：
+
+```text
+www.jd.com. 74 IN CNAME www.jd.com.gslb.qianxun.com.
+www.jd.com.gslb.qianxun.com. 11 IN CNAME www.jd.com.s.galileo.jcloud-cdn.com.
+www.jd.com.s.galileo.jcloud-cdn.com. 20 IN CNAME wwwv6.jcloudimg.com.
+wwwv6.jcloudimg.com. 15 IN A 119.147.159.135
+```
+
+第二列是剩余的 TTL，5 秒后再查询，四个值都减少了 5；直接问京东的权威服务器，第一条记录的 TTL 是 120。修改记录后，各级缓存中的旧记录要等 TTL 到期才会失效，所以更换服务器的 IP 地址之前，通常先把 TTL 调小。
+
+这个结果也说明了 CDN 的调度方式：www.jd.com 通过 CNAME（别名记录）把解析交给 CDN 的调度系统，调度系统根据查询来源的位置返回较近的节点地址，TTL 只有几十秒，便于随时切换节点。DNS 负载均衡见 [DNS 域名解析](集群.md#2-dns-域名解析)，CDN 见 [CDN](缓存.md#三cdn)。
+
DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输：
- 如果返回的响应超过 512 字节（DNS 规定通过 UDP 传输的报文不超过 512 字节，使用 EDNS 扩展后可以更大）；
- 区域传送（主域名服务器把整个区域的数据传送给辅助域名服务器，称为 AXFR；只传送变化部分的增量传送称为 IXFR）。
+DNS 报文默认不加密，也不验证来源，常见的攻击有两种：DNS 劫持指的是攻击者控制了用户使用的 DNS 服务器或路由器，把域名解析到自己的地址；DNS 污染指的是在查询途中抢先返回伪造的响应，解析器会接受先到达的那个。防范的方法：
+
+- DNSSEC：权威服务器对记录签名，解析器验证签名后就能发现伪造的记录；
+- DNS over HTTPS（DoH）和 DNS over TLS（DoT）：加密主机与解析器之间的查询，途中无法查看和篡改；
+- HTTPS：即使域名被解析到攻击者的地址，攻击者也拿不到这个域名的证书，浏览器会报错。
+
## 文件传送协议
FTP 使用 TCP 进行连接，它需要两个连接来传送一个文件：
@@ -116,14 +137,14 @@ IMAP 协议中客户端和服务器上的邮件保持同步，如果不手动删
在浏览器中输入 https://www.example.com/ 并回车后，主要经过以下步骤：
-1. 浏览器解析 URL，检查缓存，有未过期的缓存时直接使用；
+1. 浏览器解析 URL，得到协议 https、主机名 www.example.com、端口（省略时 https 为 443）和路径 /，各部分的含义见 [URL](HTTP.md#url)，然后检查缓存，有未过期的缓存时直接使用；
2. DNS 解析域名，得到 IP 地址；
3. 与服务器进行 TCP 三次握手，HTTPS 还要进行 TLS 握手；
4. 发送 HTTP 请求，服务器处理后返回响应；
5. 浏览器解析 HTML，再请求其中引用的 CSS、JavaScript、图片等资源，最后渲染出页面；
6. 连接保持一段时间供后续请求复用，空闲后关闭。
-以下是访问该网址时各阶段的耗时（curl 实测，见[附录：实测](#附录实测)）：
+以下是访问该网址时各阶段的耗时（curl 实测，见[附录 A1](#a1-访问网页各阶段的耗时)）：
@@ -168,6 +189,8 @@ IMAP 协议中客户端和服务器上的邮件保持同步，如果不手动删
## 附录：实测
+### A1 访问网页各阶段的耗时
+
macOS 自带的 curl，网络的 RTT 约 200 ms，连续访问 3 次。各字段都是从开始到该阶段结束的累计时间：time_connect 为 TCP 连接建立，time_appconnect 为 TLS 握手完成，time_starttransfer 为收到响应的第一个字节。第 3 次的 TLS 握手明显变慢，属于网络波动，配图使用第 1 次的结果：
```text
@@ -177,6 +200,28 @@ namelookup 0.004086 connect 0.209781 appconnect 0.432419 starttransfer 0.6509
namelookup 0.001873 connect 0.216569 appconnect 1.441755 starttransfer 1.667668 total 1.668500 http 2
```
+### A2 DNS 的 TTL 与 CNAME
+
+macOS 自带的 dig 9.10.6，先向公共 DNS 223.5.5.5 查询两次，间隔 5 秒，再不经递归直接询问京东的权威服务器 ns1.jd.com：
+
+```text
+$ dig @223.5.5.5 www.jd.com +noall +answer
+www.jd.com. 74 IN CNAME www.jd.com.gslb.qianxun.com.
+www.jd.com.gslb.qianxun.com. 11 IN CNAME www.jd.com.s.galileo.jcloud-cdn.com.
+www.jd.com.s.galileo.jcloud-cdn.com. 20 IN CNAME wwwv6.jcloudimg.com.
+wwwv6.jcloudimg.com. 15 IN A 119.147.159.135
+
+$ （5 秒后）dig @223.5.5.5 www.jd.com +noall +answer
+www.jd.com. 69 IN CNAME www.jd.com.gslb.qianxun.com.
+www.jd.com.gslb.qianxun.com. 6 IN CNAME www.jd.com.s.galileo.jcloud-cdn.com.
+www.jd.com.s.galileo.jcloud-cdn.com. 15 IN CNAME wwwv6.jcloudimg.com.
+wwwv6.jcloudimg.com. 10 IN A 119.147.159.135
+
+$ dig @ns1.jd.com www.jd.com +noall +answer +norecurse
+www.jd.com. 120 IN CNAME www.jd.com.gslb.qianxun.com.
+www.jd.com.gslb.qianxun.com. 60 IN CNAME www.jd.com.s.galileo.jcloud-cdn.com.
+```
+
## 参考资料
- [RFC 1035: Domain Names - Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)
@@ -187,3 +232,7 @@ namelookup 0.001873 connect 0.216569 appconnect 1.441755 starttransfer 1.6676
- [RFC 1939: Post Office Protocol - Version 3](https://www.rfc-editor.org/rfc/rfc1939)
- [RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2](https://www.rfc-editor.org/rfc/rfc9051)
- [RFC 6891: Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891)
+- [RFC 7871: Client Subnet in DNS Queries](https://www.rfc-editor.org/rfc/rfc7871)
+- [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033)
+- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484)
+- [RFC 7858: Specification for DNS over Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc7858)
