diff --git a/assets/balancer-ha-2.svg b/assets/balancer-ha-2.svg
index 9d1b25fb..8af1c52e 100644
--- a/assets/balancer-ha-2.svg
+++ b/assets/balancer-ha-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/assets/global-load-balancer.svg b/assets/global-load-balancer.svg
new file mode 100644
index 00000000..d211053b
--- /dev/null
+++ b/assets/global-load-balancer.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/lvs-ha.svg b/assets/lvs-ha.svg
index 934275ea..e1d402a0 100644
--- a/assets/lvs-ha.svg
+++ b/assets/lvs-ha.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/balance/balance4.md b/balance/balance4.md
index a9eb3d1e..b3752b64 100644
--- a/balance/balance4.md
+++ b/balance/balance4.md
@@ -121,46 +121,44 @@ $ echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
从上述可见，网络地址转换模式下，负载均衡器代表整个服务集群接收和响应请求。因此，当流量压力较大时，系统的瓶颈就很容易体现在负载均衡器上。
-## 4.4.4 主备容错模式
+## 4.4.4 主备模式
-到目前为止，本节讨论的单个负载均衡器的工作模式。假如单个负载均衡器挂了呢？如果一个负载均衡器实例挂了，那所有经过这个负载均衡器的的连接都会受到影响。
+到目前为止，我们讨论的都是单个负载均衡器的工作模式。假如负载均衡器挂了呢？那所有经过负载均衡器的连接都会受到影响。为了避免负载均衡器故障导致服务停摆，负载均衡器通常都是以高可用模式部署。
-为了避免单个负载均衡器挂掉导致应用不可用，负载均衡器通常都是以高可用的形式部署。
-
-如图 4- 11 所示，这是一种典型的主备模式设计。
+图 4-11 展示的是最常见主备模式。其核心在于每台节点中运行着 Keepalived 软件。该软件实现了 VRRP（Virtual Router Redundancy Protocol）协议，虚拟出一个 IP 地址（VIP）作为对外服务的地址。该 VIP 绑定默认绑定在主节点上，由主节点（Master）处理所有流量请求。备用节点（Backup）始终监测主节点状态，并在故障时迅速接管 VIP，以保证服务不中断。
:::center
- 图 4-11 负载均衡主/备设计
+ 图 4-11 主备模式
:::
-主/备方案在现今的分布式系统非常常见，但这种方式存在明显的缺陷：
-- 平稳状态下 50% 的资源是空闲的，备用服务器一直空转，**资源无法充分利用**。
-- 其次，**现代分布式系统追求更高的容错性**。理想情况下，一个系统就算多个实例同时挂掉，预期仍能继续运行，而主/备实例同时挂掉时，服务就彻底挂了。
+主/备模式的设计在现今的分布式系统非常普遍，但这种方式存在下述缺陷：
+- 平正常运行时，50% 的资源处于闲置状态，备用服务器一直空转，导致资源利用率不足。
+- 此外，现代分布式系统更注重高容错性。理想情况下，即便多个实例同时故障，服务仍应能持续运行。而在主备模式下，一旦主备实例同时故障，服务将完全中断。
+
+## 4.4.5 基于集群和一致性哈希的容错和可扩展模式
+近些年，大型互联网基础设施系统开始设计和部署全新的大规模并行四层负载均衡系统。这些系统的设计目标是：
+- 避免主备模式的缺点。
+- 从厂商的商业硬件方案，迁移至基于标准服务器和网卡的通用软件方案。
-## 4.5.5 一致性哈希容错模式
+如图 4-12 所示，这种设计被称“基于集群和一致性哈希的容错和可扩展”（fault tolerance and scaling via clustering and distributed consistent hashing）。它的工作原理如下：
+- N 个边缘路由器使用相同的 BGP 权重通告所有 Anycast VIP。通过 ECMP（Equal-cost Multi-path Routing）确保同一流（flow）的所有数据包都经过相同的边缘路由器。一个流通常由 4 元组（源 IP/端口和目的 IP/端口）组成。简而言之，ECMP 是一种通过一致性哈希将流量均匀分发到多台权重相同的路由器的机制。虽然边缘路由器通常不关心每个数据包的具体去向，但它们希望同一流的所有包始终走相同路径，以避免因乱序而导致性能下降。
-接下来我们继续看**基于集群的一致性哈希容错和可扩展设计方案**，它的工作原理如图 4-12 所示。
+- N 个四层负载均衡器使用相同的 BGP 权重向所有边缘路由器通告所有 VIP。通过 ECMP，边缘路由器确保相同流（flow）的数据包始终选择相同的四层负载均衡器。
+- 每个四层负载均衡器实例，使用一致性哈希算法为每个流（flow）选择一个后端。
:::center
- 图 4-12 负载均衡一致性哈希容错和可扩展设计方案
+ 图 4-12 基于集群和一致性哈希的容错和可扩展模式
:::
-- 多个边缘路由器以相同的 BGP 权重通告所有 Anycast VIP，通过 ECMP（Equal-cost, Multi-path routing，等价多路由）保证每个 flow 的所有包都会到达同一个边缘路由器。
-- 多个四层负载均起以相同的 BGP 权重向所有的边缘路由器通告所有的 VIP 继续使用 ECMP 的方式为相同 flow 的包选择相同的四层负载均衡器。
-- 每个四层负载均衡器实例会做部分连接跟踪（conntrack）工作，然后使用一致性哈希为每个 flow 选择 一个后端。通过 GRE 封装将包从负载均衡器发送到后端。
-- 然后使用三角传输模式将应答包从后端直接发送到边缘路由器，最后到客户端。
-
综合上述，看看一致性哈希容错模式是如何避免主备方式的缺陷：
-- **边缘路由器和负载均衡器实例可以按需添加**。因为每一层都用到了 ECMP，当新实例加入的时候，能最大程度地减少受影响的 flow 数量；
-- 在预留足够的突发量和容错的前提下，系统的资源利用率想达到多高就可以到多高。
-
-各类云厂商中的 SLB 以及绝大部分的现代四层负载均衡系统都在朝着这种设计演进。
-
-
+- 边缘路由器和负载均衡器实例可以根据需求动态扩展。每一层都使用 ECMP，确保新实例加入时，受影响的流量（flow）数量最小化。
+- 在预留足够的突发量和容错空间的基础上，系统的资源利用率可以根据需求达到最优水平。
+- 无论是边缘路由器，还是负载均衡器均可基于通用硬件构建，其成本仅为传统硬件负载均衡器的一小部分。
+绝大部分的现代四层负载均衡系统都在朝着这种设计演进，像各类云厂商的负载均衡系统，绝大部分都是这种设计。
\ No newline at end of file
diff --git a/balance/balance7.md b/balance/balance7.md
index 5303da56..6a920bd8 100644
--- a/balance/balance7.md
+++ b/balance/balance7.md
@@ -1,6 +1,6 @@
# 4.5 七层负载均衡技术
-早期的七层负载均衡器（如 Nginx），使用原始的静态配置手段，提供最基本的请求代理功能。随着微服务和自动扩缩容等技术的发展，负载均衡器对管理配置的手段和功能的要求日益提高。本节将简要概述一些代表性的七层负载均衡器，介绍它们提供的核心功能，以供读者参考。
+早期的七层负载均衡器（如 Nginx）采用静态配置，提供基本的请求代理功能。随着微服务和自动扩缩容等技术的发展，负载均衡器对配置管理和功能的需求不断增加。本节将简要概述一些现代七层负载均衡器的核心功能，供读者参考。
根据实现语言以及应用场景来说，业界较流行的七层负载均衡器如表 4-1 所示。
diff --git a/balance/global-load-balancer.md b/balance/global-load-balancer.md
index 136918e3..b35e3da5 100644
--- a/balance/global-load-balancer.md
+++ b/balance/global-load-balancer.md
@@ -1,25 +1,24 @@
-# 4.6 全局负载均衡
+# 4.6 全局负载均衡设计
未来的负载均衡系统会越来越将单个负载均衡器看做通用组件。
图 13 展示了全局负载均衡系统的一个例子。这个例子包含如下内容：
- 每个边车代理（Sidecar Proxy）同时和位于三个 zone 的后端通信；
-- 根据图，可以看到 90% 的流量到了 zone C，zone A 和 B 各只有 5%；
-- 边车代理和后端定期向全局负载均衡器汇报状态。这使得全局负载均衡器可以基于延迟、负载、请求失败率等参数做出决策；
-- 全局负载均衡器定期配置每个 sidecar 的路由信息。
+- 边车代理和后端定期向全局负载均衡器汇报状态。全局负载均衡器根据延迟、负载、请求失败率等参数做出最合适的决策；
+- 全局负载均衡器向边车代理下发决策。根据图，可以看到 90% 的流量到了 zone C，zone A 和 B 各只有 5%。
:::center
- 
+ 
图 4-10 全局负载均衡器
:::
全局负载均衡器可以做越来越复杂、单个负载均衡器无法完成的事情。例如：
-- 在多个 Zone 间实现自动故障转移（failover），在特定区域出现中断或高负载时，将流量切换到其他可用区域。
-- 应用全局安全和路由策略
+- 在多个 Zone 间实现自动故障转移：特定区域出现中断或高负载时，将流量切换到其他可用区域。
- 使用机器学习和神经网络技术检测和缓解流量异常，包括 DDoS 攻击
+- 应用全局安全和路由策略，确保整个系统配置的一致性
- 提供可视化运维平台，帮助工程师直观地理解和维护整个分布式系统。
-全局负载均衡器在服务网格领域称为控制平面（control plane）。控制平面专注于决策生成、管理和下发，数据平面专注于高效地执行这些决策。二者相辅相成的分离式设计是现代网络架构的核心设计原则。
\ No newline at end of file
+现代软件发展的主流趋势是分离式设计。全局负载均衡器在服务网格领域称为控制平面（control plane）。控制平面专注决策生成、管理和下发，数据平面专注地执行这些决策。
\ No newline at end of file
diff --git a/network/iptables.md b/network/iptables.md
index 2dcb6bf6..5043cfd6 100644
--- a/network/iptables.md
+++ b/network/iptables.md
@@ -10,9 +10,9 @@ Netfilter 中的钩子，在 iptables 中称作“链”（chain）。
iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。从名字上看，它们分别对应了 Netfilter 的 5 个钩子。
-iptables 把一些常用数据包管理操作总结成具体的动作，当数据包经过内核协议栈的钩子时（也就是 iptables 的链），判断经过此链的数据包是否匹配 iptables 规则。iptables 规则包括匹配 IP 数据包的源地址、目的地址、传输层协议（TCP/UDP/ICMP/..）以及应用层协议（HTTP/FTP/SMTP/..）等。
+iptables 把一些常用数据包管理操作总结成具体的动作，当数据包经过内核协议栈的钩子时（也就是 iptables 的链），判断经过此链的数据包是否匹配 iptables 规则。iptables 规则包含匹配 IP 数据包源地址/目的地址、传输层协议（TCP/UDP/ICMP/...）等。
-如果数据包匹配规则，则触发定义好的动作。如下为部分常见的动作及说明：
+如果数据包匹配规则，则触发定义好的动作。如下为部分常见的动作说明：
- ACCEPT：允许数据包通过，继续执行后续的规则。
- DROP：直接丢弃数据包。