fix typo

Observability/metrics.md

@@ -4,7 +4,7 @@
 
 Prometheus 项目的灵感来自 Google 内部的 Borg 监控系统（Brogmon），由前 Google 工程师在 SoundCloud 公司发起并将其开源。2016 年 5 月，Prometheus 继 Kubernetes 之后，成为云原生计算基金会（CNCF）的第二个正式项目。经过多年的发展，Prometheus 已成为云原生系统中指标监控的事实标准。
 
-如图 9-3 所示，Prometheus 是一个模块化系统，由多个独立组件组成，每个组件承担特定功能。其中，服务发现（Service Discovery）负责自动发现监控目标；Exporter 将监控目标的指标数据转换为 Prometheus 可理解的格式；Pushgateway 处理短期任务的监控数据；Prometheus 服务器负责数据的收集、存储和查询；而 Alertmanager 处理告警通知。
+如图 9-3 所示，Prometheus 是一个模块化系统，由多个独立组件组成，每个组件承担特定功能。其中，服务发现（Service Discovery）负责自动发现监控目标；Exporter 将监控目标的指标转换为 Prometheus 可理解的格式；Pushgateway 处理短期任务的指标；Prometheus 服务器负责指标存储和查询；而 Alertmanager 负责度量指标，触发告警动作。
 
 :::center
   ![](../assets/prometheus-arch.png)<br/>
@@ -27,15 +27,17 @@ Prometheus 项目的灵感来自 Google 内部的 Borg 监控系统（Brogmon）
 
 ## 2. 通过 Exporter 收集指标
 
-定义完指标类型后，接下来的任务是从监控目标中收集这些指标。采集指标看似简单，但现实情况复杂得多，许多现有的服务、系统，甚至硬件设备，并不会直接暴露 Prometheus 格式的指标。例如：
+定义完指标类型后，接下来的任务是从监控目标中收集这些指标。
 
-- Linux 的许多指标信息以文件形式记录在 /proc 目录下，如 /proc/meminfo 提供内存信息，/proc/stat 提供 CPU 信息；
+采集指标看似简单，但现实情况复杂得多，许多现有的服务、系统，甚至硬件设备，并不会直接暴露 Prometheus 格式的指标。例如：
+
+- Linux 的许多指标信息以文件形式记录在 /proc 目录下。如 /proc/meminfo 提供内存信息，/proc/stat 提供 CPU 信息；
 - Redis 的监控信息需要通过 INFO 命令获取；
 - 路由器等硬件设备的监控数据通常通过 SNMP 协议获取。
 
 为了解决这个问题，Prometheus 通过 Exporter 实现了数据收集与监控系统的解耦。Exporter 作为连接监控系统与被监控目标的桥梁，负责理解不同来源的监控数据，并将其转换为 Prometheus 支持的格式。并通过 HTTP（通常暴露在 /metrics 端点）将指标提供给 Prometheus 进行抓取。
 
-如下所示，Prometheus 可以通过轮询的方式，从暴露指标的 /metrics 接口获取类型为 Counter 的 Exporter 实例。Prometheus 定期轮询这些监控目标，获取最新的指标数据，从而实现对系统状态的实时监控。
+如下所示，Prometheus 可以从暴露指标的 /metrics 接口获取名为 http_request_total，类型为 Counter 的指标数据。Prometheus 定期轮询这些监控目标，获取最新的指标数据，实现了对系统状态的实时监控。
 
 ```bash
 $ curl http://127.0.0.1:8080/metrics | grep http_request_total

Observability/profiles.md

@@ -3,11 +3,11 @@
 熟悉 Go 语言的开发者一定了解 pprof。当我们需要对软件性能调试与分析时，可以通过 pprof 的 CPU profiling 或 Memory profiling 功能来分析函数的耗时和内存占用情况。在可观测性领域，性能剖析（Profiling）和 Go 语言中的 pprof 作用相同，都是通过对动态程序进行剖析，生成程序运行时的动态画像（也就是 Profiles 数据）。从而帮助我们了解程序使用各类资源的全貌，确定代码和性能瓶颈之间的关联。
 
 
-Profiles 数据一般表示成火焰图、堆栈图或内存分析图等形式，是从“是什么”到“为什么”这一过程中至关重要的依据。例如，通过链路追踪发现延迟产生的位置，再借助 Profiles 生成的火焰图进一步定位到具体的代码行。2021 年国内某站崩溃，工程师们就是使用火焰图观察到到一处 Lua 代码存在异常，并定位到问题的源头[^1]。
+Profiles 数据一般表示成火焰图、堆栈图或内存分析图等形式，是从“是什么”到“为什么”这一过程中至关重要的依据。例如，通过链路追踪发现延迟产生的位置，然后依靠 Profiles 生成的火焰图进一步定位到具体的代码行。2021 年，国内某站崩溃，工程师们使用火焰图观察到到一处 Lua 代码存在异常，最终定位到问题的源头[^1]。
 
 :::center
   ![](../assets/lua-cpu-flame-graph.webp)<br/>
-  图 9-16 Lua 级别的 CPU 火焰图
+  图 9-16 Lua 代码的 CPU 火焰图
 :::
 
 :::tip 火焰图分析说明

balance/balance4-principle.md

@@ -6,20 +6,22 @@ LVS 通过修改报文中的 IP 地址和端口来实现网络流量的分发。
 
 ## 1. 链路层负载均衡
 
-LVS 的 DR（Direct Routing，直接路由）模式其实是一种链路层负载均衡技术。链路层负载均衡其实就是**修改请求数据帧中的 MAC 目标地址，让原本发送给负载均衡器请求的数据帧，被二层交换机转发至服务器集群中对应的服务器**，这样真实服务器（Real Server）就获得了一个原本目标并不是发送给它的数据帧。
+LVS 的 DR（Direct Routing，直接路由）模式是一种链路层（L2）负载均衡技术。
 
-- 由于链路层只修改了 MAC 地址，所以在 IP 层看来数据没有任何变化，继而被正常接收。
-- 由于 IP 数据包中包含了源（客户端）和目的地（负载均衡器）IP 地址，只有真实服务器保证自己的 IP 与 数据包中的目的地 IP 地址一致，这个数据包才能继续被处理。
+链路层负载均衡其实就是**修改请求数据帧中的 MAC 目标地址，让原本发送给负载均衡器请求的数据帧，被二层交换机转发至服务器集群中对应的真实服务器（Real Server）**，这样真实服务器就获得了一个原本目标并不是发送给它的数据帧。
 
-综上所述，因此使用这种负载均衡模式时，需要把真实服务器的 VIP（Vritual IP，虚拟 IP）配置成和负载均衡器的 VIP 一样，LVS 配置真实服务器的原因也是如此，如下代码示例。
+- 由于只修改了链路层数据帧的 MAC 地址，IP 层的数据没有任何变化。所以，被真实服务器正常接收。
+- 由于 IP 数据包中包含了源（客户端）和目的地（负载均衡器）IP 地址。所以，真实服务器需保证自己的 IP 与 数据包中的目的地 IP 地址一致，数据包才能继续被处理。
+
+综上所述，使用 DR 负载均衡模式时，需要把真实服务器的 VIP（Vritual IP，虚拟 IP）配置成和负载均衡器的 VIP 一样，LVS 配置真实服务器的原因也是如此，如下代码示例。
 
 ```bash
 // 真实服务器配置
 $ ifconfig lo:0 1.1.1.1 netmask 255.255.255.255 up // 绑定 VIP 地址在 lo 接口上才能收到目标地址为 VIP 的包。
 $ route add -host 1.1.1.1 dev lo  // 目标地址是 VIP 的数据包从本机 lo 接口发送出去
 ```
 
-DR 模式只有请求经过负载均衡器，而服务的响应无需从负载均衡器原路返回的工作模式中，整个请求、转发、响应的链路形成一个“三角关系”，这种模式也被形象的称为“三角传输模式”，如图 4-7 所示。
+DR 模式只有请求经过负载均衡器，而服务的响应无需从负载均衡器原路返回的工作模式中，整个请求、转发、响应的链路形成一个“三角关系”。因此，DR 模式也被形象地称为“三角传输模式”，如图 4-7 所示。
 
 :::center
   ![](../assets/balancer4-dsr.svg)<br/>
@@ -28,9 +30,9 @@ DR 模式只有请求经过负载均衡器，而服务的响应无需从负载
 
 使用 DR 模式的主要优势是在一些场景中，响应的流量要远远大于请求的流量（譬如典型的 HTTP request/response 模式）。**假设请求占 10% 的流量，响应占 90%，使用三角传输模式，只需 1/10 的带宽就可以满足系统需求，这种模式极大节省了带宽成本，还提高了负载均衡器的可靠性（流量越低肯定越好）**。
 
-虽然 DR 模式式效率很高，但它在缺陷也很明显：
+DR 模式效率很高，但它的缺陷也很明显：
 - **因为响应不再经过负载均衡器，负载均衡器就无法知道 TCP 连接的完整状态，防火墙策略会受到影响**（TCP 连接只有 SYN，没有 ACK）。
-- 其次因为是数据链路层通信，受到的网络侧约束也很大。
+- 其次，由于是数据链路层通信，负载均衡器和真实服务器必须在同一个子网内，受到网络侧的约束很大。
 
 总结 DR 模式的优势（效率高）和劣势（不能跨子网）共同决定了该模式最适合作为数据中心的第一层均衡设备，用来连接其他的下级负载均衡器。
 

consensus/raft.md

@@ -1,12 +1,12 @@
 # 6.3 Raft 算法
 
 :::tip 额外知识
-Raft 是由 Re{liable|plicated|dundant} And Fault-Tolerant 组合起来的单词，意思是可靠、复制、冗余和容错。同时，组合起来的单词在英文又有“筏”的含义，也隐喻 Raft 是一艘可以帮助你逃离 Paxos 小岛的救生筏。
+Raft 是由 Re{liable|plicated|dundant} And Fault-Tolerant 组合起来的单词，意思是可靠、复制、冗余和容错。同时，该词在英文有“筏”的含义，隐喻 Raft 是一艘可以帮助你逃离 Paxos 小岛的救生筏。
 :::
 
 不可否认，Paxos 是一个划时代的共识算法。Raft 出现之前，绝大多数共识算法的实现都是基于 Paxos 或者受其影响，同时 Paxos 也成为了教学领域里讲解共识问题时的示例。
 
-但不幸的是 Paxos 理解起来非常晦涩。此外，虽然论文中提到了 Multi Paxos，但缺少实现细节的描述。学术界和工业界普遍对 Paxos 算法感到十分头疼。那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中发现有很多难以逾越的难题，往往不得已又开发出一种与 Paxos 完全不一样的算法，这就导致 Lamport 的证明并没有太大价值。
+但不幸的是，Paxos 理解起来非常晦涩。此外，虽然论文中提到了 Multi Paxos，但缺少实现细节的描述。因此，无论是学术界还是工业界普遍对 Paxos 算法感到十分头疼。那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中发现有很多难以逾越的难题，往往不得已又开发出与 Paxos 完全不一样的算法，这导致 Lamport 的证明并没有太大价值。
 
 所以，在很长的一段时间内，实际上并没有一个被大众所认同的 Paxos 算法。
 
@@ -19,7 +19,7 @@ Paxos 算法描述与工程实现之间存在巨大的鸿沟，最终实现的
 2013 年，斯坦福的 Diego Ongaro 教授和 John Ousterhout 博士发表了论文 《In Search of an Understandable Consensus Algorithm》[^1]，提出了 Raft 算法。Raft 论文开篇第一句描述了 Raft 的证明和 Paxos 等价，然后详细描述了算法如何实现，也就是说 Raft 天生就是 Paxos 算法的工程化。
 
 :::tip 《In Search of an Understandable Consensus Algorithm》开篇
-Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos;
+Raft is a consensus algorithm for managing a replicated log. It produces a result **equivalent to (multi-)Paxos, and it is as efficient as Paxos,** but its structure is different from Paxos;
 :::
 
 此后 Raft 算法成为分布式容错系统开发的首选共识算法。

http/Edge-Acceleration.md

@@ -15,7 +15,7 @@
 :::
 
 
-根据笔者使用 Akamai 加速服务后的效果数据看，HTTPS 的请求延迟降低了 30% 右，如表 2-4 所示。
+根据笔者的线上数据看，使用 Akamai 加速服务后，HTTPS 请求延迟降低了 30% 右，如表 2-4 所示。
 
 :::center
 表 2-4 网络直连与使用动态加速的效果对比

http/quic.md

@@ -4,7 +4,7 @@ QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于
 
 许多人可能认为是 IETF（互联网工程任务组）在推动 QUIC 替代 TCP。实际上，QUIC 的开发先驱是 Google。早在 2013 年，Google 就在其服务器（如 Google.com、YouTube.com）和 Chrome 浏览器中启用了名为 “QUIC”（业内称为 gQUIC）的全新传输协议。2015 年，Google 将 gQUIC 提交给 IETF，经 IETF 规范化后的 QUIC 被称为 iQUIC。早期的 iQUIC 有多个“草稿”版本，如 h3-27、h3-29 和 h3 v1 等。2018 年末，IETF 发布了基于 QUIC 协议的最新一代的互联网标准 HTTP/3。
 
-图 2-26 展示了各个 HTTP 协议的区别。可以看出，HTTP/3 最大的特点是底层基于 QUIC 协议，并在内部集成了 TLS 安全协议。
+图 2-26 展示了各个 HTTP 协议的区别。可以看出，HTTP/3 最大的特点是底层基于 QUIC 协议，并且集成了 TLS 安全协议。
 
 :::center
   ![](../assets/http-quic.png)<br/>
@@ -34,9 +34,9 @@ QUIC 出现之前，HTTP 使用 TCP 作为传输数据的底层协议。然而
 
 ### 2. 低时延连接
 
-以一个 HTTPS 的请求为例，即使是最新的 TLS 1.3 协议，**初次连接也至少需要 2-RTT 才能开启数据传输**，像 TCP Fastopen 这类补丁方案，由于协议僵化原因，根本不会在复杂网络中起到作用。
+以一个 HTTPS 的请求为例，即使是最新的 TLS 1.3 协议，**初次连接也至少需要 2-RTT 才能开启数据传输**。此外，像 TCP Fastopen 类补丁方案，由于协议僵化原因，实际上不会在复杂网络生效。
 
-QUIC 内部集成了 TLS 安全协议，无需像 TCP 那样，先经过三次握手，再经过 TLS 握手才开启数据传输。**QUIC 初次连接只需要 1- RTT 就能开启数据传输**。
+QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，再经过 TLS 握手才开启数据传输。**QUIC 初次连接只需要 1- RTT 就能开启数据传输**。
 
 :::center
   ![](../assets/quic-handshake.png)<br/>
@@ -51,7 +51,7 @@ QUIC 内部集成了 TLS 安全协议，无需像 TCP 那样，先经过三次
 
 ### 4. 降低对丢包的敏感度
 
-先来看 HTTP/2 Stream 的处理，如图 2-29 所示，如果一个属于 Stream2 的 TCP 数据包丢失了（图中标 5 的圆圈），那么它将阻塞后续数据包的传输。这也就是我们常说的“队头阻塞问题”（head-of-line blocking）。
+先来看 HTTP/2 Stream 的处理。如图 2-29 所示，如果一个属于 Stream2 的 TCP 数据包丢失了（图中标 5 的圆圈），那么它将阻塞后续数据包的传输。这也就是我们常说的“队头阻塞问题”（head-of-line blocking）。
 
 而 QUIC 为每个 Stream 设计了单独控制，Stream 之间没有顺序依赖。这意味着，如果一个属于 Stream2 的 UDP 数据包丢失了，它只会影响 Stream2 的处理，不会阻塞 Stream1 和 Stream3 的传输。这样的好处是，完全避免 TCP 协议出现的队头阻塞问题。
 
@@ -66,7 +66,7 @@ QUIC 内部集成了 TLS 安全协议，无需像 TCP 那样，先经过三次
 
 ## 2.8.3 QUIC 实践
 
-QUIC 协议的表现如何，是否可以在正式环境应用？2022 年，爱奇艺基础架构团队对 HTTP/1.1、HTTP/2、HTTP/3 等各版本进行基准测试，笔者将测试数据在此分享，以供读者参考。
+QUIC 协议可用性如何，是否可以应用到正式环境？2022 年，爱奇艺基础架构团队对 HTTP/1.1、HTTP/2、HTTP/3 等各版本进行基准测试，笔者将测试数据在此分享，以供读者参考。
 
 图 2-30 展示了在不同网络质量下，各个 HTTP 协议的响应耗时表现。
 
@@ -75,7 +75,7 @@ QUIC 协议的表现如何，是否可以在正式环境应用？2022 年，爱
  图 2-30 不同网络质量下的协议耗时表现（耗时单位 ms）
 :::
 
-上述测试数据表明，在相同网络质量下，HTTP/3 相比于 HTTP/2 的响应时间减少了约一半。不过，测试还发现了另一个问题。根据图 2-31 的网络请求成功率测试结果，HTTP/3 的失败率高于 HTTP/2。
+上述测试数据表明：在相同网络质量下，HTTP/3 相比于 HTTP/2 的响应时间减少了约一半。不过，测试还发现了另一个问题：根据图 2-31 的网络请求成功率测试结果来看，HTTP/3 的失败率明显高于 HTTP/2。
 
 :::center
   ![](../assets/quic-3.png)<br/>

network/XDP.md

@@ -2,7 +2,7 @@
 
 由于 DPDK 完全基于“内核旁路”的思想，它天然无法与 Linux 内核生态很好地结合。
 
-2016 年，在 Linux Netdev 会议上，演讲者 David S. Miller[^1] 喊出了“DPDK is not Linux”的口号。同年，随着 eBPF 技术的成熟，Linux 内核终于迎来了属于自己的高速公路——XDP（eXpress Data Path，快速数据路径）。XDP 具有媲美 DPDK 的性能，并且背靠 Linux 内核，具备无需第三方代码库和许可、无需专用 CPU 等多种独特优势。
+2016 年，在 Linux Netdev 会议上，Linux 内核开发领域的知名人物 David S. Miller[^1] 喊出了“DPDK is not Linux”的口号。同年，随着 eBPF 技术的成熟，Linux 内核终于迎来了属于自己的“高速公路” —— XDP（eXpress Data Path，快速数据路径）。XDP 具有媲美 DPDK 的性能，并且背靠 Linux 内核，具备无需第三方代码库和许可、无需专用 CPU 等多种独特优势。
 
 DPDK 技术是完全绕过内核，直接将数据包传递到用户空间进行处理。而 XDP 则正好相反，它选择在内核空间中执行我们定义的程序来处理数据包。那么，如何在内核中执行用户空间定义的程序呢？这就需要用到 BPF（Berkeley Packet Filter，伯克利包过滤器）技术 —— 一种允许在内核空间运行经过安全验证的代码的机制。
 
@@ -51,5 +51,5 @@ $ cilium bpf nat list
 $ cilium bpf ct list global
 ```
 
-[^1]: Linux 内核开发者，自 2005 年开始，已经提交过 4989 个 patch，是 Linux 核心源代码第二大的贡献者。
+[^1]: Linux Netdev，专注于 Linux 网络栈和网络技术的会议。David S. Miller 是 Linux 内核网络子系统的主要维护者之一，也是 Linux 内核开发领域的知名人物。
 [^2]: 相较 AF_INET 是基于传统网络的 Linux socket，AF_XDP 则是一套基于 XDP 的高性能 Linux socket。