fix linux 内核

Author: isno

.vuepress/config.js

@@ -135,7 +135,7 @@ export default defineUserConfig({
                 ]
             },
             {
-                text: '第三章：Linux 内核网络技术',
+                text: '第三章：深入 Linux 内核网络技术',
                 collapsable: true,
                 link: '/network/summary.md',
                 sidebarDepth: 2,

container/summary.md

@@ -10,9 +10,9 @@
 
 随着容器化和微服务架构的普及，管理大量容器实例和微服务变得异常复杂。为了自动化容器的管理、调度、扩展和故障恢复，容器编排系统应运而生。
 
-过去十年间，Kubernetes 逐渐发展成为容器编排系统的事实标准，并成为大数据分析、机器学习以及在线服务等领域广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，本身也逐渐演变成当今最复杂的软件系统之一。
+过去十年间，Kubernetes 逐渐发展成为容器编排系统的事实标准，并成为大数据分析、机器学习以及在线服务等领域广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，本身也演变成当今最复杂的软件系统之一。
 
-目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有对“为什么这么做”进行解释。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，笔者将从这几篇论文着手，介绍 Google 内部容器系统是怎么演变的。汲取背后的设计思想后，再来深入理解 Kubernetes 关于资源模型、网络通信、持久化存储、编排调度等方面的设计原理和应用。本章内容安排如图 7-0 所示。
+目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有对“为什么这么做”进行解释。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，笔者将从这几篇论文着手，介绍 Google 内部容器系统是怎么演变的。汲取背后的设计思想后，再来深入理解 Kubernetes 中 关于容器设计模式、网络通信、持久化存储、资源模型和编排调度等方面的设计和应用。本章内容安排如图 7-0 所示。
 
 :::center
   ![](../assets/container-summary.png)<br/>

http/Edge-Acceleration.md

@@ -1,4 +1,4 @@
-# 2.7 对网络请求进行“动态加速”
+# 2.7 对请求进行“动态加速”
 
 区别于静态文件缓存技术 CDN，“动态加速”并非依赖缓存数据，而是通过优化 IP 路由和传输层来实现网络加速。
 

http/https-summary.md

@@ -1,3 +1,3 @@
-# 2.5 HTTPS 加密原理及优化实践
+# 2.5 HTTPS 原理及实践
 
 想必读者都知道 HTTPS（SSL/TLS）的一些基本逻辑，但面对 HTTPS 中对称与非对称加密、数字签名、数字证书等一众术语时，除了了解它们“它是什么”，你是否想过“为什么是它”。搞清楚后者非常重要，否则你只是单纯地记住了被灌输的知识，而未真正理解它。

http/https.md

@@ -27,7 +27,7 @@
 
 ## 4. 什么是非对称机密
 
-简单说就是有两把密钥，通常一把叫做公钥（Public Key），可以向公众开放。一把叫私钥或密钥（Private Key key），私钥是必须保密的。用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
+简单说就是有两把密钥，通常一把叫做公钥（Public Key），可以向公众开放。另一把叫私钥或密钥（Private Key），私钥是必须保密的。用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
 
 :::center
   ![](../assets/types-of-encryption-asymmetric-encryption.png)<br/>

network/DPDK.md

@@ -1,8 +1,8 @@
 # 3.4.1 数据平面开发套件 DPDK
 
-2010 年，由 Intel 领导的 DPDK（Data Plane Development Kit，数据平面开发套件）实现了一套基于“内核旁路”思想的高性能网络应用开发解决方案，并逐渐成为了独树一帜的成熟技术体系。
+2010 年，由 Intel 领导的 DPDK实现了一套基于“内核旁路”思想的高性能网络应用解决方案，并逐渐成为了独树一帜的成熟技术体系。
 
-起初，DPDK 实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，DPDK 开始变成通用的处理方案。例如，处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器；网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
+起初，DPDK （Data Plane Development Kit，数据平面开发套件）实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，DPDK 开始支持更多的硬件。如处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器；网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
 
 图 3-6 展示了 DPDK（Fast Path）与传统内核网络（Slow Path）的区别。在 Linux 系统中，位于用户空间的 DPDK Lib 和 APP 的编译、连接和加载方式和普通程序没什么区别。但两者网络数据包在 Linux 系统中的传输路径完全不同：
 

network/conntrack.md

@@ -22,16 +22,16 @@ conntrack 连接记录是 iptables 连接状态匹配的基础，也是网络地
 
 我们知道 Kubernetes 的核心组件 kube-proxy，作用是负责处理集群中的服务（Service）网络流量。它实现的本质其实是个反向代理（也就是 NAT）。当外部请求访问 Service 时，请求被 DNAT 成 PodIP:Port，响应时再经过 SNAT。
 
-例如：客户端向 my-service 的 IP 10.0.0.10 发送 HTTP 请求，端口 80。
+举一个具体的例子。客户端向 my-service（IP 10.0.0.10 ）发送 HTTP 请求，端口 80。
 
 - kube-proxy 在节点上接收到这个请求后，执行 DNAT 操作，将目标地址 10.0.0.10:80 转换为某个 Pod 的 IP 和端口，例如 192.168.1.2:8080。
 - 在 Pod 生成响应并发送回客户端时，kube-proxy 执行 SNAT 操作，将响应的源地址 192.168.1.2:8080 转换为 Service IP 10.0.0.10:80。
 
-conntrack 维护的连接记录包含了从客户端到服务的 DNAT 映射（10.0.0.10:80 到 192.168.1.2:8080）以及从服务到客户端的 SNAT 映射（192.168.1.2:8080 到 10.0.0.10:80）。这样有来有回，是一条完整的 NAT 映射关系。
+conntrack 模块维护的连接记录包含了从客户端到 Pod 的 DNAT 映射（10.0.0.10:80 到 192.168.1.2:8080）以及从 Pod 到客户端的 SNAT 映射（192.168.1.2:8080 到 10.0.0.10:80）。这样有来有回，是一条完整的 NAT 映射关系。
 
-但如果发起请求的 Pod 和处理请求的 Pod 在同一个主机内（图 3-5），问题就来了：
+但如果发起请求的客户端和处理请求的 Pod 在同一个主机内（图 3-5），问题就来了：
 - 发起请求时，数据包经过网络层时，内核中的 conntrack 模块根据 iptables 规则，判断是否需要进行 DNAT；
-- 返回响应时，如果 Linux 网桥检测到目的 IP 位于同一网桥上，则直接通过二层转发（即链路层通信），并没有触发网络层的 conntrack 模块，也就是不进行 SNAT。
+- 返回响应时，如果 Linux 网桥检测到目的 IP 位于同一网桥上，则直接通过链路层转发，并没有触发网络层的 conntrack 模块，也就是不进行 SNAT。
 
 因此，通信双方不在同一“频道”上，与 NAT 相关的连接记录不完整，进而影响容器间通信，产生各类异常。
 
@@ -40,5 +40,5 @@ conntrack 维护的连接记录包含了从客户端到服务的 DNAT 映射（1
   图 3-5 请求和响应不在一个“频道”上，双方通信失败
 :::
 
-针对上述问题，Linux 内核提供了 bridge-nf-call-iptables 配置，决定内核是否将通过网桥的流量交由 iptables 规则匹配处理，也就是处理 NAT 保证 conntrack 连接记录的完整性。这也是为什么部署 Kubernetes 集群时，务必开启 Linux 系统配置 bridge-nf-call-iptables（设置为 1）的原因。
+针对上述问题，Linux 内核提供了 bridge-nf-call-iptables 配置，决定 Linux 网桥中的数据包是否触发 iptables 规则匹配。也就是处理 NAT 保证 conntrack 连接记录的完整性。这也解释了为什么部署 Kubernetes 集群时，务必开启 Linux 系统配置 bridge-nf-call-iptables（设置为 1）的原因。
 

network/iptables.md

@@ -1,12 +1,16 @@
 # 3.3.2 数据包过滤工具 iptables
 
-Netfilter 的钩子回调固然强大，但得通过程序编码才能使用，并不适合系统管理员日常运维。为此，基于 Netfilter 框架开发的应用便出现了，典型的就是 Xtables 系列，包括 iptables，nftables，ebtables，arptables，ip6tables 等。
+Netfilter 的钩子回调固然强大，但得通过程序编码才能使用，并不适合系统管理员日常运维。
+
+为此，基于 Netfilter 框架开发的应用便出现了，典型的就是 Xtables 系列，包括 iptables、nftables、ebtables、arptables、ip6tables 等。
 
 用过 Linux 系统的工程师多多少少都使用过 iptables，它常被称为 Linux 系统“自带的防火墙”。严谨地讲，iptables 能做的事情其实远超防火墙的范畴，它的定位应是能够代替 Netfilter 多数常规功能的 IP 包过滤工具。
 
 ## 1. iptables 表和链
 
-Netfilter 中的钩子，在 iptables 的术语里叫做“链”（chain）。iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING，从名字上看，它们分别对应 Netfilter 的 5 个钩子。
+Netfilter 中的钩子，在 iptables 的术语里叫做“链”（chain）。
+
+iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。从名字上看，它们分别对应 Netfilter 的 5 个钩子。
 
 iptables 把一些常用数据包管理操作总结成具体的动作，当数据包经过内核协议栈的钩子时（在 iptables 称为链），判断经过此链的数据包是否匹配 iptables 规则。iptables 规则包括匹配 IP 数据包的源地址、目的地址、传输层协议（TCP/UDP/ICMP/..）以及应用层协议（HTTP/FTP/SMTP/..）等。
 
@@ -22,9 +26,9 @@ iptables 把一些常用数据包管理操作总结成具体的动作，当数
 - MASQUERADE：地址伪装，可以理解为动态的 SNAT。通过它可以将源地址绑定到某个网卡上，因为这个网卡的 IP 可能是动态变化的，此时用 SNAT 就不好实现；
 - LOG：内核对数据包进行日志记录。
 
-不同的链上能处理的事情有区别，而相同的动作放在一起也便于管理，比如数据包过滤的动作（ACCEPT，DROP，RETURN，REJECT 等）可以合并到一处，数据包的修改动作（DNAT、SNAT）可以合并到另外一处，这便有了规则表的概念。
+不同的链上能处理的事情有区别，而相同的动作放在一起也便于管理。如数据包过滤的动作（ACCEPT，DROP，RETURN，REJECT 等）可以合并到一处，数据包的修改动作（DNAT、SNAT）可以合并到另外一处，这便有了规则表的概念。将规则表与链进行关联，而不是规则本身与链关联，通过一个中间层解耦了链与具体的某条规则，原先复杂的对应关系就变得简单了。
 
-将规则表与链进行关联，而不是规则本身与链关联，通过一个中间层解耦了链与具体的某条规则，原先复杂的对应关系就变得简单了。iptables 的 5 张规则表为：
+iptables 共有 5 规则表，它们的名称与含义如下：
 
 - raw 表：配置该表主要用于去除数据包上的连接追踪机制。默认情况下，连接会被跟踪，所以配置该表后，可以加速数据包穿越防火墙，提高性能。
 - mangle 表：修改数据包内容，常用于数据包报文头的修改，比如服务类型（Type of Service, ToS），生存周期（Time to Live, TTL），Mark 标记等。
@@ -33,17 +37,18 @@ iptables 把一些常用数据包管理操作总结成具体的动作，当数
 - security 表：安全增强，一般用于 SELinux 中，其他情况并不常用。
 
 
-一个链上可以关联的表可以有多个，所以这 5 张表在一个链上执行的时候得有个顺序：raw --> mangle --> nat --> filter --> security，即先去连接追踪，再改数据包，然后做源或目标地址转换，最后是过滤和安全。数据包具体经过的表、链的关系和顺序如图 3-3 所示。
+一个链上可以关联的表可以有多个，所以这 5 张表在一个链上执行的时候得有个顺序：raw --> mangle --> nat --> filter --> security，即先去连接追踪，再改数据包，然后做源或目标地址转换，最后是过滤和安全。
+
+数据包具体经过的表、链的关系和顺序如图 3-3 所示。
 
 :::center
   ![](../assets/Netfilter-packet-flow.svg)<br/>
   图 3-3 数据包通过 Netfilter 时的流向过程 [图片来源](https://en.wikipedia.org/wiki/Netfilter)
 :::
 
-
 ## 2. iptables 自定义链与应用
 
-除了 5 个内置链外，iptables 支持管理员创建用于实现某些管理目的自定义链。向自定义链添加规则和向内置链规则的方式是一样的。不同的地方在于，自定义链只能通过从另一个规则跳转（jump）到它。
+除了 5 个内置链外，iptables 支持管理员创建用于实现某些管理目的自定义链。
 
 自定义链可以看作是对调用它的链的扩展。例如，自定义链结束的时候，可以返回内置链，也可以再继续跳转到其他自定义链。自定义链的设计使 iptables 不仅仅只是一个 IP 包过滤工具，还在容器网络中也扮演了重要的角色。如 Kubernetes 的核心组件 kube-proxy，利用自定义链实现了 Service 功能。
 
@@ -77,7 +82,7 @@ iptables 把一些常用数据包管理操作总结成具体的动作，当数
 
 iptables 模式完全使用 iptables 规则处理容器间请求和负载均衡，因此它的性能也受 iptables 直接影响。问题是 Service 非常多的时候产生太多的 iptables 规则，非增量式更新会引入一定的时延，大规模情况下有明显的性能问题。
 
-为解决 iptables 模式的性能问题，kube-proxy 新增了 IPVS 模式，该模式使用 Linux 内核四层负载均衡模块 IPVS 实现容器间请求和负载均衡，性能和 Service 规模无关。不过需要注意的是，内核中的 IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。只不过，这些辅助性的 iptables 规则数量有限，不会随着 Pod 数量的增加而增加。
+为解决 iptables 模式的性能问题，kube-proxy 新增了 IPVS 模式，该模式使用 Linux 内核四层负载均衡模块 IPVS 实现容器间请求和负载均衡，性能和 Service 规模无关。需要注意的是，内核中的 IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。只不过，这些辅助性的 iptables 规则数量有限，不会随着 Pod 数量的增加而增加。
 
 如图 3-4 展示了 iptables 与 IPVS 两种模式的性能对比。可以看出，当 Kubernetes 集群有 1,000 个 Service（10,000 个 Pod）时，两者的性能表现开始出现明显差异。
 

network/linux-bridge.md

@@ -67,8 +67,8 @@ PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
 ```
 通过以上实验，我们验证了使用 Linux bridge 可以将多个命名空间连接到同一个二层网络中。你可能注意到，我们只为 veth 在命名空间内的一端分配了 IP 地址，而未为连接到 bridge 的那一端分配地址。这是因为 bridge 工作在二层（数据链路层），仅处理以太网帧，包括 ARP 解析、以太网帧的转发和泛洪。
 
-与物理二层交换机不同，Linux bridge 本质上是 Linux 系统中的虚拟网络设备，因此具备网卡的特征，可以配置 MAC 和 IP 地址。从主机的角度来看，配置了 IP 的 Linux bridge 设备就相当于主机上的一张网卡，能够参与路由和转发。因此，当将网络命名空间的默认网关设置为该 IP 时，原本隔离的网络命名空间就能与主机进行网络通信。
+与物理二层交换机不同，Linux bridge 本质上是 Linux 系统中的虚拟网络设备，因此具备网卡的特征，可以配置 MAC 和 IP 地址。从主机的角度来看，配置了 IP 的 Linux bridge 设备就相当于主机上的一张网卡，自然能够参与数据包的路由和转发。因此，将网络命名空间的默认网关设置为 Linux bridge 的 IP 后，原本被隔离的网络命名空间就能与主机进行网络通信。
 
-打通容器与主机之间的互通是实现容器跨主机通信的关键步骤。笔者将在后续的第七章 7.6 节中详细介绍容器跨主机通信的原理。
+打通容器与主机之间的互通是实现容器跨主机通信的关键步骤。笔者将在第七章 7.6 节中详细介绍容器跨主机通信的原理。
 
 

network/summary.md

@@ -1,4 +1,4 @@
-# 第三章：深入 Linux 内核网络
+# 第三章：深入 Linux 内核网络技术
 :::tip <a/>
 
 创造操作系统，就是去创造一个所有应用程序赖以运行的基础环境。从根本上来说，就是在制定规则：什么可以接受，什么可以做，什么不可以做。事实上，所有的程序都是在制定规则，只不过操作系统是在制定最根本的规则。
@@ -8,9 +8,9 @@
 —— 摘自《Linus Torvalds 自传》[^1]
 :::
 
-在大多数业务开发中，工程师只要掌握 HTTP 协议和基础的 TCP 知识，足够应付绝大部分的开发工作。然而，若要由"工程师"角色向"架构师"角色转变，那必须要对整个系统架构有一个宏观视角，能更准确地把握架构设计和技术选择的核心，深入理解应用系统的内在运行机制至关重要。
+在第二章，我们研究了请求怎么到达后端系统。这一章，进一步就请求达到 Linux 系统后的过程展开讨论。
 
-为此，我们将深入 Linux 内核网络，层层推进。首先，解析 Linux 内核中的数据包处理机制，理解 Linux 内核一些核心模块如何密切协作，以及它们对应用层设计产生的影响。然后，讨论 Linux 内核在密集网络系统下的瓶颈，并探讨业内一些“跨内核”的解决方案。最后，我们还要学习一些与虚拟化网络相关的协议和虚拟设备技术，这些是后续章节（负载均衡、容器网络、服务网格）等高级应用的基石。
+我们将深入 Linux 内核网络技术，根据数据包在 Linux 内核中的处理过程层层推进。解析 Linux 内核中关键模块（将介绍 netfilter、iptables 以及 conntrack）如何密切协作，以及它们对应用程序产生的影响。接着，讨论 Linux 内核在密集网络系统下的瓶颈，并探索业内一些“跨内核”思想的解决方案（将介绍 DPDK、RDMA 和 eBPF 技术）。最后，我们将学习一些与虚拟化网络相关的技术，这些内容是后续章节（负载均衡、容器网络、服务网格）等高级应用的基石。
 
 :::center
   ![](../assets/network-summary.png)<br/>