diff --git a/http/dns.md b/http/dns.md
index 904c7d1e..0e9a923e 100644
--- a/http/dns.md
+++ b/http/dns.md
@@ -27,7 +27,7 @@
- 第 1 步，用户向“DNS 解析器”（Recursive resolver）发出解析 thebyte.con.cn 域名请求。“DNS 解析器”也称 LocalDNS，例如电信运营商的 114.114.114.114。
- “DNS 解析器” 判断是否存在解析缓存：
- 存在，返回缓存的结果，也就是直接执行第 8 步；
- - 不存在，执行第 2 步，向就近的“根域名服务器”（Root nameserver）查询域名所属“TLD 域名服务器”（TLD nameserver，也就是顶级域名服务器），TLD 域名服务器维护着域名托管、权威域名服务器的信息。值得一提的是，有些文章说“根域名服务器”只有 13 台，实际上“根域名服务器”的数量远不止 13 台，截止 2024 年 7 月，全世界共有 1,845 台根域名服务器[^3]。
+ - 不存在，执行第 2 步，向就近的“根域名服务器”（Root nameserver）查询域名所属“TLD 域名服务器”（TLD nameserver，也就是顶级域名服务器），TLD 域名服务器维护着域名托管、权威域名服务器的信息。值得一提的是，有些文章说“根域名服务器”只有 13 台，实际上“根域名服务器”的数量远不止 13 台，截至 2024 年 7 月，全世界共有 1,845 台根域名服务器[^3]。
- 获取 com.cn. 的“TLD 域名服务器”后，执行第 4 步，向该服务器查询 thebyte.com.cn. 的“权威域名服务器”（Authoritative nameserver）。
- 获取 thebyte.com.cn 的“权威域名服务器”后，执行第 6 步，向该服务器查询域名的具体解析记录。
- “DNS 解析器” 获取到解析记录后，再转发给客户端（第 8 步），整个解析过程结束。
diff --git a/http/https-latency.md b/http/https-latency.md
index 7ad53c2b..79b9175d 100644
--- a/http/https-latency.md
+++ b/http/https-latency.md
@@ -4,7 +4,7 @@
## 2.2.1 请求阶段分析
-一个完整、未复用连接的 HTTPS 请求需要经过以下 5 个阶段：**DNS 域名解析、TCP 握手、SSL 握手、服务器处理、内容传输**。
+一个完整、未复用连接的 HTTPS 请求需要经过 5 个阶段：**DNS 域名解析、TCP 握手、SSL 握手、服务器处理、内容传输**。
如图 2-1 所示，请求的各个阶段共需要 5 个 RTT（Round-Trip Time，往返时间）[^2] 具体为：1 RTT（DNS Lookup，域名解析）+ 1 RTT（TCP Handshake，TCP 握手）+ 2 RTT（SSL Handshake，SSL 握手）+ 1 RTT（Data Transfer，HTTP 内容传输）。
@@ -88,13 +88,13 @@ time_total=0.088744
## 2.2.3 HTTPS 的优化总结
-了解 HTTPS 请求各阶段耗时后，以下为相关的优化手段：
+了解 HTTPS 请求各阶段耗时后，以下为相关的优化手段。
-- **域名解析优化**：减少域名解析产生的延迟。例如，提前获取域名解析结果备用，那么后续的 HTTPS 连接就能减少一个 RTT；
-- **对传输内容进行压缩**：传输数据的大小与耗时成正比，压缩传输内容是降低请求耗时最有效的手段之一；
-- **SSL 层优化**：升级 TLS 算法和 HTTPS 证书，例如升级 TLS 1.3 协议，可将 SSL 握手的 RTT 从 2 个减少到 1 个；
-- **传输层优化**：升级拥塞控制算法以提高网络吞吐量。将默认的 Cubic 升级为 BBR，对于大带宽、长链路的弱网环境尤其有效；
-- **网络层优化**：使用商业化的网络加速服务，通过路由优化数据包，实现动态服务加速；
+- **域名解析优化**：减少域名解析产生的延迟。例如，提前获取域名解析结果备用，那么后续的 HTTPS 连接就能减少一个 RTT。
+- **对传输内容进行压缩**：传输数据的大小与耗时成正比，压缩传输内容是降低请求耗时最有效的手段之一。
+- **SSL 层优化**：升级 TLS 算法和 HTTPS 证书。例如，升级 TLS 1.3 协议，可将 SSL 握手的 RTT 从 2 个减少到 1 个。
+- **传输层优化**：升级拥塞控制算法以提高网络吞吐量。例如，将默认的 Cubic 升级为 BBR，对于大带宽、长链路的弱网环境尤其有效。
+- **网络层优化**：使用商业化的网络加速服务，通过路由优化数据包，实现动态服务加速。
- **使用更现代的 HTTP 协议**：升级至 HTTP/2，进一步升级到基于 QUIC 协议的 HTTP/3。
接下来，笔者将逐一介绍上述优化技术的原理和实践效果。
diff --git a/http/https.md b/http/https.md
index c6c505c1..3dd47bc8 100644
--- a/http/https.md
+++ b/http/https.md
@@ -7,7 +7,7 @@
HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热点或通信服务运营商节点时，传输的内容完全暴露。以明文传输，中间人还能篡改内容，且不被双方察觉。为防止“中间人攻击”（MITM），我们需要对信息进行加密。最容易理解的加密方式就是对称加密！
## 2. 什么是对称加密
-加密和解密都使用同一个密钥，密钥必须严格保密。换句话说，只有知道密钥的人才能解密密文，只要密钥不被中间人获取，两方通信的机密性就能得到保证。常用的对称加密算法有 AES、ChaCha20、DES 等。
+加密和解密使用同一个密钥，密钥必须严格保密。换句话说，只有知道密钥的人才能解密密文，只要密钥不被中间人获取，两方通信的机密性就能得到保证。常用的对称加密算法有 AES、ChaCha20、DES 等。
:::center
@@ -18,7 +18,7 @@ HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热 对称加密的关键在于保护密钥不被泄露。但是，HTTP 通信模型是 1 对 N，所有客户端共享同一个密钥，实际等同于没有加密。如果由每个客户端随机生成一个密钥，并传输给服务端，那是否解决了共享密钥的问题呢？但难题是，如何将随机密钥传给服务端，同时不被别人知道。 -此时，我们必须换一种思路，只使用对称加密就会陷入“无限套娃”的死胡同。现在，“非对称加密算法”登场！ +此时，我们必须换一种思路，只使用对称加密就会陷入无限循环的死胡同。现在，“非对称加密算法”登场！ :::center 
@@ -40,7 +40,7 @@ HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热 - 确认对称加密算法后，客户端随机生成一个对称加密密钥 K。 - 客户端使用公钥加密密钥 K，然后将密文传输给服务端。此时，只要服务端有私钥，就能能解密，得到密钥 K。 -如此，我们实现了”降低加/解密的耗时，同时又保证密钥传输的安全性“，达成既要安全又要效率的目标。 +如此，我们实现了降低加/解密耗时，同时保证密钥传输的安全性，达成既安全又高效的目标。 现在，继续讨论新的问题，客户端如何获取公钥？ diff --git a/http/latency.md b/http/latency.md index 6f3f4db0..0564c707 100644 --- a/http/latency.md +++ b/http/latency.md @@ -2,13 +2,13 @@ 既然目标是“足够快”，首先需要对计算机中“快”的概念有一个基本的认识。 -伯克利大学有个动态网页[^1]，里面汇总了历年计算机中各类操作延迟（（也称时延）的变化。笔者整理了 2020 年的数据供读者参考，如表 2-1 所示。这些延迟数据与软件设计和性能调优息息相关。例如，由于物理距离的限制，无论如何优化，也无法将从上海到美国的 HTTPS 请求延迟降到 750ms 以下。 +伯克利大学有个动态网页[^1]，里面汇总了历年计算机中各类操作延迟（也称时延）的变化。笔者整理了 2020 年的数据供读者参考，如表 2-1 所示。这些延迟数据与软件设计和性能调优息息相关。例如，由于物理距离的限制，无论如何优化，也无法将从上海到美国的 HTTPS 请求延迟降到 750ms 以下。 :::center 表 2-1 计算机中各类延迟数据参考 ::: 操作|延迟 -:---|:--:| +|:---|:--:| CPU 从一级缓存中读取数据| 1 ns CPU 分支预测错误（Branch mispredict）| 3 ns CPU 从二级缓存中读取数据 | 4 ns diff --git a/http/quic.md b/http/quic.md index 6afde5d2..5caea95f 100644 --- a/http/quic.md +++ b/http/quic.md @@ -1,6 +1,6 @@ # 2.8 QUIC 设计原理与实践 -QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于 UDP 封装的安全可靠传输协议，旨在取代 TCP，成为新一代互联网的主流传输协议。 +QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于 UDP 封装的安全可靠传输协议，旨在取代 TCP 成为新一代互联网的主流传输协议。 很多人可能以为是 IETF 在推动 QUIC 替代 TCP。实际上，这项工作始于 Google。 diff --git a/http/ssl.md b/http/ssl.md index a105db9f..73ce1519 100644 --- a/http/ssl.md +++ b/http/ssl.md @@ -11,7 +11,7 @@ 图 2-17 TLS1.3 对比 TLS1.2 ::: -以 Nginx 配置为例，确保 Nginx 版本为 1.13.0 或更高，OpenSSL 版本为 1.1.1 或更高。然后，在配置文件中使用 ssl_protocols 指令启用 TLSv1.3 支持。 +以 Nginx 配置为例，确保 Nginx 版本 ≥ 1.13.0，OpenSSL 版本 ≥ 1.1.1。然后，在配置文件中使用 ssl_protocols 指令启用 TLSv1.3 支持。 ```nginx server { listen 443 ssl; @@ -26,7 +26,7 @@ HTTPS 数字证书分为 RSA 证书和 ECC 证书，二者的区别如下： - **RSA 证书**使用 RSA 算法生成公钥，兼容性较好，但不支持完美前向保密（PFS）。PFS 可确保即使私钥泄露，泄露之前的通信内容仍无法被破解。 - **ECC 证书**使用椭圆曲线加密算法（Elliptic Curve Cryptography）生成公钥，提供更高的计算速度和安全性，并支持 PFS。ECC 能以较小的密钥长度提供相同或更高的安全性。例如，256 位的 ECC 密钥相当于 3072 位的 RSA 密钥。 -ECC 证书的唯一缺点是兼容性稍差。在 Windows XP 上，只有 Firefox 支持访问使用 ECC 证书的网站（因其独立实现 TLS，不依赖操作系统）；在 Android 平台上，需 Android 4.0 以上版本才能支持 ECC 证书。好消息是，从 Nginx 1.11.0 开始，支持配置 RSA/ECC 双证书。在 TLS 握手过程中，Nginx 会根据双方协商的密码套件（Cipher Suite）返回证书。如果支持 ECDSA 算法，则返回 ECC 证书；否则，返回 RSA 证书。 +ECC 证书的唯一缺点是兼容性“稍差”。在 Windows XP 上，只有 Firefox 支持访问使用 ECC 证书的网站（因其独立实现 TLS，不依赖操作系统）；在 Android 平台上，需 Android 4.0 以上版本才能支持 ECC 证书。好消息是，从 Nginx 1.11.0 开始，支持配置 RSA/ECC 双证书。在 TLS 握手过程中，Nginx 会根据双方协商的密码套件（Cipher Suite）返回证书。如果支持 ECDSA 算法，则返回 ECC 证书；否则，返回 RSA 证书。 Nginx 双证书配置示例如下： @@ -137,7 +137,7 @@ OCSP Response Data: 图 2-19 证书配置 ::: -接着，对不同证书（ECC 和 RSA），不同 TLS 协议（TLS1.2 和 TLS1.3）进行压测，测试结果如表 2-2 所示。 +接着，对不同证书（ECC 和 RSA）、不同 TLS 协议（TLS1.2 和 TLS1.3）进行压测，测试结果如表 2-2 所示。 :::center 表 2-2 HTTPS 性能基准测试 @@ -151,6 +151,6 @@ OCSP Response Data: |ECC 证书 + TLS1.2| 639.39| 100|203.319ms| |ECC 证书 + TLS1.3| 627.39| 100|159.390ms| -从测试结果来看，使用 ECC 证书相比 RSA 证书在性能上有显著提升。即使 RSA 证书启用了硬件加速技术 QAT（Quick Assist Technology），与 ECC 证书相比仍存在明显差距。此外，QAT 需要额外购买硬件，且维护成本较高，因此不再推荐使用。 +测试结果表明，使用 ECC 证书相比 RSA 证书在性能上有显著提升。即使 RSA 证书启用了硬件加速技术 QAT（Quick Assist Technology），与 ECC 证书相比仍存在明显差距。此外，QAT 需要额外购买硬件，且维护成本较高，因此不再推荐使用。 综合考虑，建议 HTTPS 配置采用 TLS 1.3 协议与 ECC 证书。 \ No newline at end of file