fix typo

balance/summary.md

@@ -10,7 +10,7 @@
 
 或者出于扩展服务能力的考虑，又或者出于提高容错性的考虑，大多数系统通常以集群形式对外提供服务。
 
-以集群形式对外提供服务时，外界的请求无论由哪台服务器处理，都应获得一致的结果；另一方面，集群还需对外界保持足够的度透明。也就是说，外界与集群交互时仿佛面对一台高性能、高可用的单一服务器。集群内部任何变动（增加或删除服务器、某个服务器故障等），外界不会察觉，也无需对应修改任何配置。
+以集群形式对外提供服务时，外界的请求无论由哪台服务器处理，都应获得一致的结果；另一方面，集群还需对外界保持足够的透明。也就是说，外界与集群交互时仿佛面对一台高性能、高可用的服务器。外界不会察觉到集群内部任何变动，比如增加或删除服务器、某个服务器故障等，也无需对应修改任何配置。
 
 为集群提供统一入口并实现上述职责的组件称为“负载均衡器”（或称代理）。负载均衡器是业内最活跃的领域之一，产品层出不穷（如专用网络设备、基于通用服务器的各类软件等）、部署拓扑多样（如中间代理型、边缘代理、客户端内嵌等）。无论其形式如何，所有负载均衡器的核心职责无外乎 “选择处理外界请求的目标”（即负载均衡算法）和“将外界请求转发至目标”（即负载均衡的工作模式），本章我们围绕这两个核心职责，深入理解负载均衡的工作原理。
 :::center

consensus/conclusion.md

@@ -1,11 +1,11 @@
 # 6.5 小结
 
-尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识的研究，并提供了一种可验证的数学模型。
+尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识研究的先河。
 
-Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 的核心思想。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为现代分布式系统，如 etcd、Consul、TiKV、MinIO 等等实现一致性的主流选择。
+Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 的核心思想。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为分布式系统关键组件实现一致性的主流选择。
 
 最后，再让我们思考一个问题，Raft 算法属于“强领导者”（Strong Leader）模型，领导者负责所有写入操作必限制整个 Raft 集群的写入性能，那如何突破 Raft 集群的写性能瓶颈呢？
 
-一种常见的方法是使用一致性哈希算法将数据划分为多个独立部分。例如，一个拥有 100TB 数据的系统，可以将数据分成 10 个部分，每部分只需处理 10TB。这种通过规则（如范围或哈希）将数据分散到不同部分进行处理的策略，被称为“分区机制”（Partitioning）。分区机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分区机制便能够支持几乎无限规模的数据处理。
+一种方法是使用一致性哈希算法将数据划分为多个独立部分。例如，一个拥有 100TB 数据的系统，可以将数据分成 10 个部分，每部分只需处理 10TB。这种通过规则（如范围或哈希）将数据分散到不同部分进行处理的策略，被称为“分区机制”（Partitioning）。分区机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分区机制便能够支持几乎无限规模的数据处理。
 
 解决了数据规模的问题，接下来的课题是“将请求均匀地分摊至各个分区”，这部分内容我们在下一章《负载均衡》展开讨论。

http/congestion-control.md

@@ -1,16 +1,14 @@
 # 2.6 网络拥塞控制原理与实践
 
-你可能听说过与 TCP/IP 协议相关的术语，如 Cubic、Tahoe、Vegas、Reno、Westwood 以及近年来流行的 BBR 算法，这些都是网络传输层使用的拥塞控制算法。
-
-本节，我们分析拥塞控制的原理，回顾互联网不同阶段拥塞控制算法的设计，探讨如何在弱网环境下提升网络吞吐率。
+本节，我们分析互联网不同阶段拥塞控制算法原理，以 Google 发布的 BBR 算法为例，讨论大带宽、高延迟的网络环境下改善“网络吞吐量”（Network Throughput）的设计。
 
 ## 2.6.1 网络拥塞控制原理
 
-网络吞吐效率与 RTT、带宽密切相关：
-- RTT 越低，数据传输的延迟越短；
+网络吞吐量与 RTT、带宽密切相关：
+- RTT 越低，数据传输的延迟越低；
 - 带宽越高，网络在单位时间内传输的数据越多。
 
-图 2-22 展示了这两者的变化逻辑，以及对网络吞吐效率的影响。
+图 2-22 展示了这两者的变化逻辑，以及对网络吞吐量的影响。
 
 :::center
   ![](../assets/bbr-cc.png)<br/>
@@ -36,22 +34,20 @@
 
 早期互联网的拥塞控制以丢包为控制条件，控制逻辑如图 2-21 所示。
 
-发送方维护一个称拥塞窗口的状态变量 cwnd，其值取决于网络拥塞的程度和所采用的拥塞控制算法。当发送方开始发送数据时，进入慢启动（Slow Start）阶段，也就是慢慢增大拥塞控制窗口；当出现丢包时，进行拥塞避免（Congestion Avoiance）阶段，也就是减小拥塞控制窗口；当丢包不再出现时，再次进入慢启动阶段，如此一直反复。
+发送方维护一个称为“拥塞窗口”（cwnd）的状态变量，其大小取决于网络拥塞程度和所采用的拥塞控制算法。数据传输过程中，发送方首先进入“慢启动”阶段，逐步增大拥塞窗口；当发生丢包时，进入“拥塞避免”阶段，逐步减小拥塞窗口；丢包消失后，再次进入慢启动阶段，如此一直反复。
 
 :::center
   ![](../assets/cc.png)<br/>
  图 2-21 早期以丢包为条件的拥塞控制
 :::
 
-以丢包为控制条件的机制适应了早期互联网的特征：低带宽和浅缓存队列。
-
-随着移动互联网的快速发展，特别是图片和音视频应用的普及，网络负载大幅增加。与此同时，摩尔定律推动设备的性能不断提升和成本不断降低。当路由器、网关等设备的缓存队列增加，网络链路变得更长、更宽时，RTT 可能因缓存队列增大而增加，丢包则可能源于链路过长。网络变差，并不总是因链路拥塞所致。
+以丢包为控制条件的机制适应了早期互联网的特征：低带宽、浅缓存队列。
 
-因此，以丢包为控制条件的传统拥塞控制算法就不再适用了。
+随着移动互联网的快速发展，尤其是图片和音视频应用的普及，网络负载大幅增加。同时，摩尔定律推动设备性能不断提升、成本持续下降。当路由器、网关等设备的缓存队列增大，网络链路变得更长、更宽时，RTT 可能因队列增加而上升，丢包则可能由于链路过长。也就是说，网络变差并不总是因为拥塞所致。因此，以丢包为控制条件的传统拥塞控制算法就不再适用了。
 
 ## 2.6.3 现代拥塞控制旨在效能最大化
 
-早期的拥塞控制算法主要侧重于收敛，以避免互联网服务因“拥塞崩溃”而失效。BBR 算法的目标则更进一步，充分利用链路带宽、路由/网关设备缓存队列，以最大化网络效能。
+早期的拥塞控制算法侧重于收敛，以避免互联网服务因“拥塞崩溃”而失效。BBR 算法的目标更进一步，充分利用链路带宽、路由/网关设备缓存队列，最大化网络效能。
 
 最大化网络效能的前提是找到网络传输中的最优点，图 2-22 中的两个黑色圆圈即代表网络传输的最优点：
 - 上面的圆圈为 min RTT（延迟极小值）：此时，网络中路由/网关设备的 Buffer 未占满，没有任何丢包情况;
@@ -91,60 +87,17 @@ BBR 的拥塞控制状态机是实现上述设计的核心基础。该状态机
  图 2-23 BBR 状态转移关系
 :::
 
-## 2.6.5 BBR 的应用
-
-Linux 内核从 4.9 开始集成了 BBR 拥塞控制算法。此后，在绝大数的 Linux 发行版中，只要几个命令就能使用 BBR 提升网络传输效率。
-
-1. 首先，查询系统所支持的拥塞控制算法。
-```bash
-$ sysctl net.ipv4.tcp_available_congestion_control
-net.ipv4.tcp_congestion_control = bbr cubic reno
-```
-上面返回的结果中，显示当前系统支持 bbr、cubic 和 reno 三种拥塞控制算法。
-
-2. 查询当前使用的拥塞控制算法。
-
-```bash
-$ sysctl net.ipv4.tcp_congestion_control
-net.ipv4.tcp_congestion_control = cubic
-```
-绝大部分 Linux 系统默认的拥塞控制算法为 Cubic 算法。
-
-3. 指定拥塞控制算法为 bbr。
-```bash
-$ echo net.ipv4.tcp_congestion_control=bbr >> /etc/sysctl.conf && sysctl -p
-```
-网络拥塞控制是单向生效，也就是说作为下行方的服务端调整了，BBR 算法即可生效。
-
-## 2.6.6 BBR 性能表现
+## 2.6.5 BBR 的性能表现
 
-接下来，我们使用 tc 工具模拟弱网环境，使用网络性能测试工具 iperf3 测试弱网环境下不同的拥塞控制算法的表现。
+此后，大多数 Linux 发行版只需通过几个命令即可启用 BBR。接下来，我们使用 Linux 流量控制工具（tc）在两台机器之间调节延迟、丢包参数，测试不同拥塞控制算法的表现。
 
-首先，在服务端设置 eth0 网络接口上的流量丢包率为 1%、延迟为 25ms。
-
-```bash
-$ tc qdisc add dev eth0 root netem loss 1% latency 25ms
-```
-
-接着，在服务端使用 iperf3 开启测试服务，以服务端模式运行，设置监控时间2秒，并指定端口为 8080。
-
-```bash
-$ iperf -s -p 8080 -i 1
-```
-
-在客户端节点使用 iperf3 以客户端模式运行，请求 10.0.1.188 服务端的 8080 端口。
-
-```bash
-$ iperf3 -c 10.0.1.188 -p 8080
-```
-
-测试结果如表 2-3 所示。可以看出，BBR 在轻微丢包的网络环境下表现尤为出色。
+测试结果见表 2-3。可以看出，在轻微丢包的网络环境中，BBR 的表现尤为突出。
 
 :::center
 表 2-3 不同网络环境下，各拥塞控制算法的网络吞吐表现 [表数据来源](https://toonk.io/tcp-bbr-exploring-tcp-congestion-control/index.html)
 :::
 
-|服务端的拥塞控制算法|延迟|丢包率|网络吞吐表现|
+|服务端的拥塞控制算法|延迟|丢包率|网络吞吐量表现|
 |:--|:--|:--|:--|
 | Cubic| <1ms| 0% |2.35Gb/s|
 | Reno| <140ms| 0% |195 Mb/s|
@@ -158,6 +111,4 @@ $ iperf3 -c 10.0.1.188 -p 8080
 | Reno| <140ms| 3% |0.65 Mb/s| 
 | Cubic| <140ms| 3% |0.78 Mb/s| 
 | Westwood| <140ms| 3% |0.97 Mb/s| 
-| BBR| <140ms| 3% |**132 Mb/s**| 
-
-
+| BBR| <140ms| 3% |**132 Mb/s**| 

http/quic.md

@@ -15,19 +15,17 @@ QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于
 
 ## 2.8.1 QUIC 出现的背景
 
-QUIC 出现之前，HTTP 使用 TCP 作为可靠数据传输的底层协议。
+QUIC 出现之前，HTTP 采用 TCP 作为底层协议来实现可靠的数据传输。
 
-作为四十年前开发的传输层通信协议，TCP 的设计者显然没有预见今天移动设备盛行的场景。在当今复杂的移动网络环境中，TCP 存在先天的设计缺陷，集中在以下几点：
+作为四十年前开发的传输层协议，TCP 的设计者显然没有预见今天移动设备盛行的场景。现如今的移动网络环境中，TCP 暴露出来的先天设计缺陷，主要体现在以下几个方面：
 
 - **建立连接时握手延迟大**：HTTPS **初次连接（TCP 握手 + TLS 握手）至少需要 3 个 RTT** 才能建立。
 - **队头阻塞问题**：以 HTTP/2 为例，多个数据请求在同一个 TCP 连接上所有 stream（流，HTTP/2 传输的数据单元）**必须按顺序依次传输**。如果一个 stream 的数据丢失，后面其他的 stream 将被阻塞，直到丢失的数据被重传。
 - **TCP 协议僵化问题**：作为一个运行了接近 40 多年的协议，许多中间设备（如防火墙和路由器）**已经变得依赖某些隐式规则**，打补丁或者说推动 TCP 协议更新脱离现实。
 
 ## 2.8.2 QUIC 的特点
 
-在汲取 TCP 的设计经验以及现在的网络环境因素影响，QUIC 基于 UDP 实现了一种全新的可靠性传输机制，具有更低的延迟和更高的吞吐量。
-
-下面列举 QUIC 的部分重要特性，这些特性是 QUIC 被寄予厚望的关键。
+在借鉴 TCP 设计经验并考虑当前网络环境的基础上，QUIC 基于 UDP 实现了一种全新的可靠传输机制，具备更低的延迟和更高的吞吐量。下面列举 QUIC 的部分重要特性，这些特性是 QUIC 被寄予厚望的关键。
 
 ### 1. 支持连接迁移
 

network/linux-bridge.md

@@ -1,13 +1,12 @@
 # 3.5.4 虚拟交换机 Linux bridge
 
-在物理网络中，通常使用交换机连接多台主机，组成小型局域网。在 Linux 网络虚拟化技术中，也提供了物理交换机的虚拟实现，即 Linux 网桥（Linux bridge）。
+在物理网络中，通常使用交换机连接多台主机，组成小型局域网。Linux 网络虚拟化技术中，也提供了物理交换机的虚拟实现 —— Linux bridge（Linux 网桥，也称虚拟交换机）。
 
-Linux bridge 作为虚拟交换机，具备与物理交换机相似的功能。当使用 brctl 命令将多个网络接口（如物理网卡 eth0、虚拟接口 veth、tap 等）桥接后，它们的通信与物理交换机的转发行为一致，数据帧进入 Linux bridge 时，它根据数据帧的类型和目的地 MAC 地址，按照如下规则处理：
-
-- 如果是广播帧，转发给所有桥接到该 Linux bridge 的设备。
-- 如果是单播帧，查看 FDB（地址转发表）中 MAC 地址与网络设备接口的映射：
-	- 如找不到记录，则洪泛（Flooding）给所有接入网桥的设备，并把响应设备的网络接口与 MAC 地址记录到 FDB 表中；
-	- 如找到记录，则将数据帧转发至对应的接口。
+Linux bridge 作为虚拟交换机，功能与物理交换机类似。通过 brctl 命令将多个网络接口（如物理网卡 eth0、虚拟接口 veth、tap 等）桥接后，它们的通信方式与物理交换机的转发行为一致。当数据帧进入 Linux bridge 时，系统根据数据帧的类型和目的地 MAC 地址执行以下处理：
+- 对于广播帧，转发到所有桥接到该 Linux bridge 的设备。
+- 对于单播帧，查找 FDB（Forwarding Database，地址转发表）中 MAC 地址与设备网络接口的映射记录：
+	- 若未找到记录，执行“洪泛”（Flooding），然后根据“泛红”响应将设备的网络接口与 MAC 地址记录到 FDB 表中；
+	- 若找到记录，直接将数据帧转发到对应设备的网络接口。
 
 举一个具体的例子，使用 Linux bridge 将两个命名空间接入到同一个二层网络。该例子的网络拓扑结构如图 3-15 所示。
 
@@ -68,7 +67,7 @@ PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
 
 你可能注意到，我们仅为命名空间内的 veth 接口分配了 IP 地址，而未为连接到 Linux bridge 的另一端分配地址。这是因为 Linux bridge 工作在数据链路层（第二层），主要负责 ARP 解析、以太网帧转发以及广播等工作。
 
-但与物理二层交换机不同的是，Linux bridge 本质上是 Linux 系统中的虚拟**网络设备**，具备网卡特性，可以配置 MAC 和 IP 地址。从主机的角度来看，配置了 IP 地址的 Linux bridge 设备相当于主机上的一张网卡，能够参与数据包的 IP 路由。因此，当将网络命名空间的默认网关设置为 Linux bridge 的 IP 地址时，原本隔离的网络命名空间便可以与主机进行网络通信。
+但与物理二层交换机不同的是，Linux bridge 本质上是 Linux 系统中的虚拟**网络设备**，具备网卡特性，可以配置 MAC 和 IP 地址。从主机的角度来看，配置了 IP 地址的 Linux bridge 设备相当于主机上的一张网卡，能够参与数据包的 IP 路由。因此，当将网络命名空间的默认网关设置为 Linux bridge 的 IP 地址时，原本被隔离的网络命名空间便可以与主机通信。
 
 实现容器与主机之间的互通是容器跨主机通信的关键步骤。笔者将在第七章的 7.6 节中详细阐述容器跨主机通信的原理。