fix typo

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,33 +1,33 @@
 # 8.7 服务网格的未来
 
-随着服务网格的逐步落地，Sidecar 模式的缺点逐渐显现：
+随着服务网格的逐步落地，Sidecar模式的缺点也逐渐显现：
 
-- **网络延迟问题**：服务网格使用 iptables 拦截服务间的请求，服务之间的通信原本是 A->B，现在变成 A->iptables+Sidecar->iptables+Sidecar->B，调用链的增加也带来了额外的性能损耗。虽然 Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务来说，额外的延迟损耗是放弃服务网格最主要的原因。
-- **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变成了不小的数目。
+- **网络延迟问题**：服务网格通过 iptables 拦截服务间的请求，将原本的 A->B 通信改为 A->（iptables+Sidecar）-> （iptables+Sidecar）->B，调用链的增加导致了额外的性能损耗。尽管 Sidecar 的引入通常只会增加毫秒级（个位数）的延迟，但对于对性能要求极高的业务来说，额外的延迟是放弃服务网格的主要原因。。
+- **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变得相当可观。
 
-考虑解决以上的问题，开发者们思考：“是否应该将服务网格和 Sidecar 划上等号？”，开始探索服务网格形态上的其他可能性。
+为了解决上述问题，开发者们开始思考：“是否应该将服务网格与Sidecar划等号？”，并开始探索服务网格在形态上的其他可能性。
 
 ## 8.7.1 Proxyless 模式
 
 既然问题出自代理，那就把代理去掉，这就是 Proxyless（无代理）模式。
 
 Proxyless 模式的设计理念是，服务间通信总是要选择一种协议，那么将实现协议的类库（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，必然有更优秀的性能表现，Sidecar 为人诟病的延迟问题将迎刃而解。
 
-2021 年，Istio 官方博客发表了一篇文章 《基于 gRPC 的无代理服务网格》[^1]，文中介绍了一种基于 gRPC 框架实现的 Proxyless 模式的服务网格。该模式的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式，也就是在 gRPC 库中实现。此外，该模式需要额外一个代理（图中的 Istio Agent）通过 xDS 协议与控制平面交互，负责告知 gRPC 库如何连接到 istiod、如何获取证书、处理流量的策略等。
+2021 年，Istio 官方博客发表文章 《基于 gRPC 的无代理服务网格》[^1]，文中介绍了一种基于 gRPC 框架实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式，也就是在 gRPC 库中实现。此外，该模式需要额外一个代理（图中的 Istio Agent）通过 xDS 协议与控制平面交互，负责告知 gRPC 库如何连接到 istiod、如何获取证书、处理流量的策略等。
 
 :::center
   ![](../assets/proxyless.svg)<br/>
  图 8-19 Proxyless 模式
 :::
 
-相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方博客的性能测试报告来看：gRPC Proxyless 模式下的延迟情况接近基准测试，资源消耗也相对较低。
+相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方博客的性能测试报告来看，gRPC Proxyless 模式下的延迟情况接近“基准”（baseline），资源消耗也相对较低。
 
 :::center
   ![](../assets/latencies_p50.svg)<br/>
  图 8-20 Proxyless 性能测试报告（结果越低越好）
 :::
 
-不过，回过头再看，所谓 Proxyless 模式其实和传统的 SDK 并无二致，只是将流控能力内嵌到负责通信协议的类库中，因此它具有和传统 SDK 服务框架相同的缺点。所以，业内很多人认为 Proxyless 模式本质上是一种倒退，是回归到传统的方式去解决服务间通信的问题。
+回过头来看，所谓的 Proxyless 模式其实与传统的 SDK 并无太大区别，只是将通信治理逻辑内嵌至库中，有着与传统 SDK 服务框架的相同缺点。因此，许多人认为 Proxyless 模式本质上是一种倒退，是回归传统方式解决服务间通信问题。
 
 ## 8.7.2 Sidecarless 模式
 
@@ -85,7 +85,7 @@ Ambient Mesh 的设计理念是：将数据平面分层，分为“安全覆盖
 
 Ambient 分层模式允许你以逐步递进的方式采用 Istio，你可以按需从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理和策略。
 
-根据官方的博客信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个动作一定程度上说明了 Ambient Mesh 不是什么实验性质的“玩具”，而是 Istio 的未来发展方向之一。
+根据 Istio 公开的信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个举措在一定程度上表明，Ambient Mesh 并非实验性质的“玩具”，而是 Istio 未来发展的重要方向之一
 
 无论是 Sidecarless 还是 Ambient Mesh，它们的设计思路本质是：用中心化的代理，替代位于应用容器旁边的 Sidecar 代理。这在一定程度上解决了传统 Sidecar 模式带来的资源消耗、网络延迟问题。但反面是，服务网格的设计理念本来就很抽象，引入 Proxyless、Sidecarless、Ambient Mesh 等模式，让原本抽象的设计更加难以理解。
 

http/quic.md

@@ -74,19 +74,19 @@ QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，
 
 ## 2.8.3 QUIC 实践
 
-笔者在本文中花了大量篇幅探讨和赞美 QUIC 协议。那么，QUIC 在实际应用中的表现究竟如何呢？
+笔者花了大量篇幅探讨和赞美 QUIC 协议。那么，QUIC 在实际应用中的表现究竟如何？
 
-说一千道一万，不如动手做一遍。2022 年，爱奇艺基础架构团队针对 HTTP/1.1、HTTP/2 和 HTTP/3，在不同网络条件测试它们之间性能差异。笔者将测试数据在此分享，供读者参考。
+说一千道一万，不如动手做一遍。2022 年，爱奇艺基础架构团队对 HTTP/1.1、HTTP/2 和 HTTP/3 在不同网络条件下的性能差异进行了测试。笔者将测试数据在此分享，供读者参考。
 
-从请求耗时表现来看（图 2-30），相同的网络质量下，HTTP/3 的耗时比 HTTP/2 降低了近一半，证明了上述的讨论不虚。
+从请求耗时表现来看（图 2-30），相同的网络质量下，HTTP/3 的耗时比 HTTP/2 降低了近一半，证明了上述讨论不虚。
 :::center
   ![](../assets/quic-1.png)<br/>
  图 2-30 不同网络质量下，各协议耗时表现（耗时单位 ms）
 :::
 
-不过，测试中也发现了一个值得注意的问题：根据图 2-31 所示的网络请求成功率来看，HTTP/3 的失败率明显高于 HTTP/2。笔者“猜测”有两方面的原因：
-- 某些网络环境（如网络设备配置不当、防火墙规则限制）下，UDP 数据包更容易被丢弃或阻断。
-- QUIC 作为较新的协议，虽然发展迅速，但其在一些边缘场景（如复杂的企业网络、旧版网络设备等）中的兼容性和适应性还是不够完善。
+不过，从测试数据中也发现一个值得注意的问题，根据图 2-31 所示的网络请求成功率来看，HTTP/3 的失败率明显高于 HTTP/2。笔者“猜测”有两方面的原因：
+- 在某些网络环境（如网络设备配置不当或防火墙规则限制）下，UDP数据包更容易被丢弃或阻断。。
+- QUIC 作为较新的协议，在一些边缘场景（如复杂的企业网络、旧版网络设备等）中，兼容性、适应性还是不够完善。
 
 :::center
   ![](../assets/quic-3.png)<br/>
@@ -95,5 +95,5 @@ QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，
 
 综上所述，无论是服务端还是客户端，集成 QUIC 协议并非一件易事：
 
-- 服务端层面：**不仅需要适配 QUIC 协议，还要确保与 TCP 协议兼容**。此外，TCP 经过多年的深度优化，引发了一个问题：“QUIC 在实际应用中的效能表现是否能够与 TCP 相媲美？”。
-- 客户端层面：面临适配与收益之间的成本权衡。采用 QUIC 协议的客户端需要**具备降级容错能力**，并做好**长时间同时维护新旧两种网络库的准备**。
+- 服务端层面：**不仅需要适配 QUIC 协议，还要确保与 TCP 协议兼容**。此外，TCP 经过多年的深度优化，QUIC 实际的效能表现是否能够与 TCP 相媲美？。
+- 客户端层面：需要在适配、收益之间进行成本权衡。采用 QUIC 协议的客户端必须具备降级容错能力，并准备长时间同时维护新旧两种网络库。

http/summary.md

@@ -8,9 +8,11 @@
 —— by《计算机网络》作者 Andrew S. Tanenbaum [^1]
 :::
 
-不少人的第一直觉是“路由的 hops、运营商线路的质量，决定网络请求的延迟以及传输效率”，由此盲目断定网络因开发者不可控而无法插手。实际上，应用层的网络请求是否与传输协议提倡的方式匹配，这对提升传输效率、降低延迟也施加不小的影响。最容易体现这一点的便是各类网络优化技巧。
+不少人的第一直觉是“路由的 hops、运营商线路的质量，决定网络的延迟以及吞吐量”，由此盲目断定网络因开发者不可控而无法插手。实际上，应用层的网络请求是否与传输协议提倡的方式匹配，这对提升网络吞吐量、降低网络延迟也施加不小的影响。最能体现这一点的，便是各类网络优化技巧。
 
-本章，我们将分析应用层 HTTPS 请求的完整过程，探讨其中 DNS、SSL、QUIC 以及拥塞控制的原理，研究各种网络优化技巧，讨论如何实现“构建足够快的网络服务”目标！具体内容安排如图 2-0 所示。
+本章，我们将分析应用层 HTTPS 请求的完整过程，探讨其中 DNS、SSL、QUIC 以及网络拥塞控制的原理，研究各种网络优化技巧，讨论实现“构建足够快的网络服务”目标！
+
+本章内容安排如图 2-0 所示。
 
 :::center
   ![](../assets/http-summary.png)<br/>

network/kernel-bypass.md

@@ -1,5 +1,6 @@
 # 3.4 内核旁路技术
 
-通过前文对“Linux 系统收包流程”和内核网络框架的介绍，相信读者已经感受到 Linux 内核网络系统的复杂性。对于网络密集型应用，内核态与用户态的频繁切换，以及复杂的网络协议栈处理，常常导致 Linux 内核成为性能瓶颈。
+
+通过前文对“Linux系统收包流程”和内核网络框架的介绍，读者应该已经认识到，对于网络密集型应用，内核态与用户态的频繁切换、复杂的网络协议栈处理，常常使 Linux 内核成为性能瓶颈。
 
 在人们想办法提升 Linux 内核性能的同时，另外一批人抱着它不行就绕开它想法，提出了一种“内核旁路“（Kernel bypass）思想的技术方案。其中，DPDK 和 XDP 是主机内“内核旁路”思想的代表技术，RDMA 是主机之间“内核旁路”思想的代表技术。