fix typo

architecture/ServiceMesh.md

@@ -12,7 +12,7 @@
 —— by William Morgan
 :::
 
-ServiceMesh 之所以称为“服务网格”，是因为每台节点同时运行着业务逻辑和具备通信治理能力的网络代理（如 Envoy、Linkerd-proxy）。这个代理被形象地称为“边车代理”（Sidecar），其中业务逻辑相当于主驾驶，处理辅助功能的代理软件相当于边车。
+ServiceMesh 之所以称为“服务网格”，是因为每个节点同时运行着业务逻辑和具备通信治理能力的网络代理（如 Envoy、Linkerd-proxy）。这个代理被形象地称为“边车代理”（Sidecar），其中业务逻辑相当于主驾驶，处理辅助功能的代理软件相当于边车。
 
 :::center
   ![](../assets/sidecar-example.jpg)<br/>

architecture/architect.md

@@ -21,4 +21,5 @@
 9. 监控/观测：Prometheus、Grafana、OpenTelemetry。
 10. 机器学习/离在线业务混合部署：Volcano、Koordinator...。
 
-以上方案或相似或不同，适应什么场景？、解决了什么问题？、如何以最佳的姿势匹配业务？容笔者在本书后续章节一一解答。
+
+以上方案或相似或不同：适应什么场景？、解决了什么问题？、如何以最佳的姿势匹配业务？容笔者在本书后续章节一一解答。

architecture/background.md

@@ -22,7 +22,7 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人（
 计算机革命六十年，微处理器发明四十年，现代互联网兴起二十年，通过软件转变行业所需的所有技术终于有效，并可在全球范围内广泛传播。
 :::
 
-文中列出了被重塑的产业，具体有最大的书店 Amazon、最多人订阅的 Video service Netflix、最大的音乐公司 iTunes、Spotify and Pandora 等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 Google、Groupon、Facebook 等、成长最快的电信公司 Skype 、成长最快招聘公司 LinkedIn。
+文中列出了被重塑的产业，具体有最大的书店 Amazon、最多人订阅的 Video service Netflix、最大的音乐公司 iTunes、Spotify 和 Pandora 等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 Google、Groupon、Facebook 等、成长最快的电信公司 Skype 、成长最快招聘公司 LinkedIn。
 
 文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，**部分软件已经变成水电煤一样的社会经济中的基础设施**，感触更加深刻。思考这样的软件如果宕机，对社会产生什么影响？
 
@@ -58,7 +58,7 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人（
 这样的背景下，对软件质量有了更高的要求，软件开发的方式也不得不跟随时代而变化，首当其冲是：**如何解决规模越来越大，变更越来越快的难题**。
 
 
-## 1.2.3 云原生诞生
+## 1.2.3 云原生的诞生
 
 前面谈到了**软件对各行各业的渗透和对世界的改变，以及移动互联网时代巨大的用户基数下快速变更和不断创新的需求**对软件开发方式带来的巨大推动力，1.1 节描述的过去二十年间云计算的发展演进和软件上云的趋势，我们清晰地看到如此波澜壮阔的技术浪潮：
 
@@ -74,7 +74,7 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人（
 - 通过服务网格（ServiceMesh）将非业务逻辑从应用程序中剥离；
 - 通过声明式 API 描述应用程序的状态，而不用管中间的处理过程；
 - 通过 DevOps 理论以及配套的工具来提升研发/运维效率；
-- 通过 ...
+- 通过 ...。
 
 应用程序中的非业务逻辑不断被剥离，并下沉到云/基础设施层，代码越来越轻量。由此，工程师的开发工作回归本质（软件开发的本质是解决业务需求，各类“高深”、“复杂”的技术难题是业务需求的副产物，并不是软件开发的主题）。
 

architecture/cloud-native-tech.md

@@ -1,3 +1,3 @@
 # 1.5 云原生代表技术
 
-接下来的内容，我们将深入讨论云原生的代表技术：容器技术、微服务、服务网格、不可变基础设施、声明式设计以及 DevOps。
+接下来的内容，我们将深入讨论容器技术、微服务、服务网格、不可变基础设施、声明式设计以及 DevOps 等云原生代表技术。

architecture/container.md

@@ -1,7 +1,7 @@
 # 1.5.1 容器技术
 
 :::tip Google Cloud 对容器的定义
-容器是轻量级应用代码包，它还包含依赖项，例如编程语言运行时的特定版本和运行软件服务所需的库。
+容器是轻量级应用代码包，其中还包含依赖项，例如编程语言运行时的特定版本和运行软件服务所需的库。
 :::
 
 Google 对容器的解释看起来也云里雾里！那么，我们延续本章 1.1 节解释云计算的方式，从容器技术出现开始，了解它发展的历史，讨论容器技术各个阶段试图解决的问题，从而深入理解容器技术。
@@ -83,7 +83,7 @@ Docker 把内部管理容器执行、分发、监控、网络、构建、日志
   图 7-13 Containerd 架构 [图片来源](https://containerd.io/)
 :::
 
-根据图图 1-15，再来看 Docker 的架构。经过 runc、containerd 组件的拆分改造之后，Docker 就不再是一个简单的守护进程那么简单了，而是通过集成 containerd、containerd-shim、runc 等多个组件共同完成。
+根据图 1-15，再来看 Docker 的架构。经过 runc、containerd 组件的拆分改造之后，Docker 就不再是一个简单的守护进程那么简单了，而是通过集成 containerd、containerd-shim、runc 等多个组件共同完成。
 
 :::center
   ![](../assets/docker-arc.png)<br/>

http/congestion-control.md

@@ -47,8 +47,8 @@
 
 早期的拥塞控制算法侧重于收敛，以避免互联网服务因“拥塞崩溃”而失效。BBR 算法的目标更进一步，充分利用链路带宽、路由/网关设备缓存队列，最大化网络效能。
 
-最大化网络效能的前提是找到网络传输中的最优点，图 2-22 中的两个黑色圆圈即代表网络传输的最优点：
-- 上面的圆圈为 min RTT（延迟极小值）：此时，网络中路由/网关设备的 Buffer 未占满，没有任何丢包情况;
+最大化网络效能的前提是找到网络传输中的最优点，图 2-22 中的两个黑色圆圈即代表网络传输的最优点。
+- 上面的圆圈为 min RTT（延迟极小值）：此时，网络中路由/网关设备的 Buffer 未占满，没有任何丢包情况。
 - 下面圆圈的为 max BW（带宽极大值）：此时，网络中路由/网关设备的 Buffer 被充分利用。
 
 当网络传输处于最优点时：

http/dns-ha.md

@@ -25,7 +25,7 @@ Facebook 官方发布的故障原因是，运维人员修改 BGP 路由规则时
 ```
 根据上一篇内容的介绍，这是“权威解析服务器”出现了问题。那影响范围可就大了，世界上所有的用户都无法再正常打开 Facebook 相关的网站、APP。
 
-用户无法正常登陆 APP 时，通常会“疯狂”地发起重试。Facebook 用户太多了，云服务商 Cloudflare 的 DNS 解析器（1.1.1.1）请求瞬间增大了 30 倍。如果 1.1.1.1 宕机，恐怕半个互联网都会受到影响。
+用户无法正常登录 APP 时，通常会“疯狂”地发起重试。Facebook 用户太多了，云服务商 Cloudflare 的 DNS 解析器（1.1.1.1）请求瞬间增大了 30 倍。如果 1.1.1.1 宕机，恐怕半个互联网都会受到影响。
 
 <div  align="center">
 	<img src="../assets/cloudflare-dns.png" width = "650"  align=center />

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 步），整个解析过程结束。 

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。
 
 接下来，笔者将逐一介绍上述优化技术的原理和实践效果。

http/https.md

@@ -7,7 +7,7 @@
 HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热点或通信服务运营商节点时，传输的内容完全暴露。以明文传输，中间人还能篡改内容，且不被双方察觉。为防止“中间人攻击”（MITM），我们需要对信息进行加密。最容易理解的加密方式就是对称加密！
 
 ## 2. 什么是对称加密
-加密和解密都使用同一个密钥，密钥必须严格保密。换句话说，只有知道密钥的人才能解密密文，只要密钥不被中间人获取，两方通信的机密性就能得到保证。常用的对称加密算法有 AES、ChaCha20、DES 等。
+加密和解密使用同一个密钥，密钥必须严格保密。换句话说，只有知道密钥的人才能解密密文，只要密钥不被中间人获取，两方通信的机密性就能得到保证。常用的对称加密算法有 AES、ChaCha20、DES 等。
 
 :::center
   ![](../assets/types-of-encryption-symmetric-encryption.png)<br/>
@@ -18,7 +18,7 @@ HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热
 
 对称加密的关键在于保护密钥不被泄露。但是，HTTP 通信模型是 1 对 N，所有客户端共享同一个密钥，实际等同于没有加密。如果由每个客户端随机生成一个密钥，并传输给服务端，那是否解决了共享密钥的问题呢？但难题是，如何将随机密钥传给服务端，同时不被别人知道。
 
-此时，我们必须换一种思路，只使用对称加密就会陷入“无限套娃”的死胡同。现在，“非对称加密算法”登场！
+此时，我们必须换一种思路，只使用对称加密就会陷入无限循环的死胡同。现在，“非对称加密算法”登场！
 
 :::center
   ![](../assets/https-3.png)<br/>
@@ -40,7 +40,7 @@ HTTP 内容以明文传输，经过中间代理服务器、路由器、WIFI 热
 - 确认对称加密算法后，客户端随机生成一个对称加密密钥 K。
 - 客户端使用公钥加密密钥 K，然后将密文传输给服务端。此时，只要服务端有私钥，就能能解密，得到密钥 K。
 
-如此，我们实现了”降低加/解密的耗时，同时又保证密钥传输的安全性“，达成既要安全又要效率的目标。
+如此，我们实现了降低加/解密耗时，同时保证密钥传输的安全性，达成既安全又高效的目标。
 
 现在，继续讨论新的问题，客户端如何获取公钥？
 

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

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。
 

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 证书。