fix 友好格式

network/conntrack.md

@@ -18,16 +18,18 @@ $ cat /proc/net/nf_conntrack
 ipv4     2 tcp      6 88 ESTABLISHED src=10.0.12.12 dst=10.0.12.14 sport=48318 dport=27017 src=10.0.12.14 dst=10.0.12.12 sport=27017 dport=48318 [ASSURED] mark=0 zone=0 use=2
 ```
 
-conntrack 连接记录是 iptables 连接状态匹配的基础，也是实现 SNAT 和 DNAT 的前提。在 Linux 系统进行 NAT 时，conntrack 跟踪每个连接的源地址和目标地址的映射关系，以确保返回流量能够正确重定向到原始请求的主机。
+conntrack 连接记录是 iptables 连接状态匹配的基础，也是实现 SNAT 和 DNAT 的前提。
 
 我们知道 Kubernetes 的核心组件 kube-proxy，作用是负责处理集群中的服务（Service）网络流量。它实现的本质其实是个反向代理（也就是 NAT）。当外部请求访问 Service 时，请求被 DNAT 成 PodIP:Port，响应时再经过 SNAT。
 
 举一个具体的例子，客户端向 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。
+- 节点中的 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 模块维护的连接记录包含了从客户端到 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 在同一个主机内（图 3-5），问题就来了：
+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 在同一个主机内（图 3-5），问题就来了：
 - 发起请求时，数据包经过网络层时，内核中的 conntrack 模块根据 iptables 规则，判断是否需要进行 DNAT；
 - 返回响应时，如果 Linux 网桥检测到目的 IP 位于同一网桥上，则直接通过链路层转发，并没有触发网络层的 conntrack 模块，也就是不进行 SNAT。
 

network/iptables.md

@@ -1,20 +1,18 @@
 # 3.3.2 数据包过滤工具 iptables
 
-Netfilter 的钩子回调固然强大，但得通过程序编码才能使用，并不适合系统管理员日常运维。
-
-为此，基于 Netfilter 框架开发的应用便出现了，典型的就是 Xtables 系列，包括 iptables、nftables、ebtables、arptables、ip6tables 等。
+Netfilter 的钩子回调固然强大，但得通过程序编码才能使用，并不适合系统管理员日常运维。为此，基于 Netfilter 框架开发的应用便出现了，如 iptables。
 
 用过 Linux 系统的工程师多多少少都使用过 iptables，它常被称为 Linux 系统“自带的防火墙”。严谨地讲，iptables 能做的事情其实远超防火墙的范畴，它的定位应是能够代替 Netfilter 多数常规功能的 IP 包过滤工具。
 
 ## 1. iptables 表和链
 
-Netfilter 中的钩子，在 iptables 的术语里叫做“链”（chain）。
+Netfilter 中的钩子，在 iptables 中称作“链”（chain）。
 
-iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。从名字上看，它们分别对应 Netfilter 的 5 个钩子。
+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/..）以及应用层协议（HTTP/FTP/SMTP/..）等。
 
-如下为部分常见的动作及说明：
+如果数据包匹配规则，则触发定义好的动作。如下为部分常见的动作及说明：
 
 - ACCEPT：允许数据包通过，继续执行后续的规则。
 - DROP：直接丢弃数据包。
@@ -26,7 +24,9 @@ iptables 把一些常用数据包管理操作总结成具体的动作，当数
 - MASQUERADE：地址伪装，可以理解为动态的 SNAT。通过它可以将源地址绑定到某个网卡上，因为这个网卡的 IP 可能是动态变化的，此时用 SNAT 就不好实现；
 - LOG：内核对数据包进行日志记录。
 
-不同的链上能处理的事情有区别，而相同的动作放在一起也便于管理。如数据包过滤的动作（ACCEPT，DROP，RETURN，REJECT 等）可以合并到一处，数据包的修改动作（DNAT、SNAT）可以合并到另外一处，这便有了规则表的概念。将规则表与链进行关联，而不是规则本身与链关联，通过一个中间层解耦了链与具体的某条规则，原先复杂的对应关系就变得简单了。
+不同的链上能处理的事情有区别，而相同的动作放在一起也便于管理。如数据包过滤的动作（ACCEPT，DROP，RETURN，REJECT 等）可以合并到一处，数据包的修改动作（DNAT、SNAT）可以合并到另外一处，这便有了规则表的概念。
+
+将规则表与链进行关联，而不是规则本身与链关联，通过一个中间层解耦了链与具体的某条规则，原先复杂的对应关系就变得简单了。
 
 iptables 共有 5 规则表，它们的名称与含义如下：