From 5f0280728e92e61d248788bd9893bf6d6693470d Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 21 Jun 2024 06:18:02 +0800 Subject: [PATCH] fix typo --- http/protobuf.md | 2 +- network/linux-bridge.md | 10 ++++++---- network/linux-kernel-networking.md | 4 ++-- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/http/protobuf.md b/http/protobuf.md index 39f587d7..c5ff2301 100644 --- a/http/protobuf.md +++ b/http/protobuf.md @@ -1,6 +1,6 @@ # 2.4.2 使用 Protocol Buffers 序列化数据 -无论是微服务场景还是 Google 所开源的技术体系中，经常能看到 Protobuf 的身影。Protobuf 这个数据格式有何独特之处？以至于工程师们无论是高性能场景还是各类的标准/协议制定都默认选择它。 +微服务或者 Google 开源的技术体系中，经常能看到 Protobuf 的身影。Protobuf 数据格式有什么独特之处？以至于工程师们无论是高性能场景还是各类的标准/协议制定都默认选择它。 :::tip Protocol Buffers Protocol Buffers（简称 Protobuf 或者 pb）是 Google 公司开发的一种轻便高效的结构化数据存储格式，用来描述各种数据结构进行结构化数据串行化，或者说序列化。相比 XML 和 JSON，Protobuf 更小、更快、更简单，很适合做数据存储或 RPC 数据交换格式。 diff --git a/network/linux-bridge.md b/network/linux-bridge.md index a476f208..1894e7b5 100644 --- a/network/linux-bridge.md +++ b/network/linux-bridge.md @@ -10,16 +10,18 @@ Linux Bridge 是 Linux 内核 2.2 版本开始提供的二层转发工具，由 ::: -对于通过 brctl 命令显式接入网桥的设备，Linux Bridge 与物理交换机的转发行为是完全一致的，当有二层数据包（帧）从网卡进入 Linux Bridge，它就会根据数据包的类型和目标 MAC 地址，按照如下规则转发处理： +Linux Bridge 与物理交换机的转发行为是完全一致的，当有二层数据包（帧）从网卡进入 Linux Bridge，它就会根据数据包的类型和目标 MAC 地址，按照如下规则处理： -1. 如果数据包是广播帧，转发给所有接入网桥的设备。 +1. 如果数据包是广播帧，转发给所有桥接到该 Linux Bridge 的设备。 2. 如果数据包是单播帧： - 地址转发表中找不到该 MAC 地址（网桥与交换机类似，会学习 MAC 地址与端口的映射），则洪泛（Flooding）给所有接入网桥的设备，并把响应设备的接口与 MAC 地址学习到自己的 MAC 地址转发表中； - 地址转发表中找到了 MAC 地址，则直接转发到地址表中指定的设备。 -3. 如果数据包是此前转发过的，又重新发回到此 Bridge，说明冗余链路产生了环路。由于以太帧不像 IP 报文那样有 TTL 来约束，所以一旦出现环路，如果没有额外措施来处理的话，就会永不停歇地转发下去。那么对于这种数据包，就需要交换机实现生成树协议（Spanning Tree Protocol，STP）来交换拓扑信息，生成唯一拓扑链路以切断环路。 Linux Bridge 与普通物理交换机非常相似，但还是有点区别，普通的交换机只会做二层转发，**Linux Bridge 却还能把发给它的数据包再发送到主机的三层协议栈中**。 -Linux Bridge 肯定是在某台 Linux 主机上创建的，我们可以看作是 Linux Bridge 有一个与自己名字相同的隐藏端口，隐式地连接了创建它的那台 Linux 主机。因此，Linux Bridge 允许给自己设置 IP 地址，这样就比普通交换机多出了一种特殊的转发情况：**如果数据包的目的 MAC 地址为网桥本身，并且网桥设置了 IP 地址的话，那该数据包就会被认为是收到发往创建网桥那台主机的数据包**，这个数据包将不会转发到任何设备，而是直接交给上层（三层）协议栈去处理。这时，网桥就取代了物理网卡 eth0 设备来对接协议栈，进行三层协议的处理。 + +Linux Bridge 肯定是在某台 Linux 主机上创建的，我们可以看作是 Linux Bridge 有一个与自己名字相同的隐藏端口，隐式地连接了创建它的那台 Linux 主机。 + +因此，Linux Bridge 允许给自己设置 IP 地址，这样就比普通交换机多出了一种特殊的转发情况：**如果数据包的目的 MAC 地址为网桥本身，并且网桥设置了 IP 地址的话，那该数据包就会被认为应该发往创建网桥那台主机**，这个数据包将不会转发到任何设备，而是直接交给主机（三层）协议栈去处理。这时，网桥就取代了物理网卡 eth0 设备来对接协议栈，进行三层协议的处理。 读者们是否还记得 3.3.2 节提到的设置 bridge-nf-call-iptables 参数？就是因为 Linux Bridge 与普通交换机的一点不同。 diff --git a/network/linux-kernel-networking.md b/network/linux-kernel-networking.md index fc0248f6..fb1e0234 100644 --- a/network/linux-kernel-networking.md +++ b/network/linux-kernel-networking.md @@ -24,7 +24,7 @@ Netfilter 实际上就是一个数据包过滤器框架，Netfilter 在网络包 - LOCAL_OUT：本机产生的准备发送的包，在进入协议栈后立即触发此 hook。 - POST_ROUTING：本机产生的准备发送的包或者转发的包，在经过路由判断之后，将触发此 hook。 -**其它内核模块(例如 iptables、IPVS 等)可以向这些 hook 点注册钩子函数。当有数据包经过时，就会自动触发内核模块注册在这里的钩子函数，这样程序代码就能够通过钩子函数来干预 Linux 的网络通信**，进而实现对数据包过滤、修改、SNAT/DNAT 等各类功能。 +**其它内核模块(例如 iptables、IPVS 等)可以向这些 hook 点注册钩子函数。当有数据包经过时，就会自动触发内核模块注册在这里的钩子函数，这样程序代码就能够通过钩子函数来干预 Linux 的网络通信**，实现对数据包过滤、修改、SNAT/DNAT 等各类功能。 :::tip 额外知识 @@ -38,7 +38,7 @@ Hook 设计模式在其他软件系统中也随处可见，譬如 eBPF、Git、K 图 3-3 Kubernetes 服务的本质 ::: -如图 3-4 Kubernetes 网络模型说明示例，当一个 Pod 跨 Node 进行通信时，数据包从 Pod 网络 Veth 接口发送到 cni0 虚拟网桥，进入主机协议栈之后，首先会经过 PREROUTING hook，调用相关的链做 DNAT，经过 DNAT 处理后，数据包目的地址变成另外一个 Pod 地址，再继续转发至 eth0，发给正确的集群节点。 +如图 3-4 Kubernetes 网络模型说明示例，当一个 Pod 跨 Node 进行通信时，数据包从 Pod 的 veth-pair 接口发送到 cni0 虚拟网桥，进入主机协议栈之后，首先经过 PREROUTING hook，调用相关的链做 DNAT，经过 DNAT 处理后，数据包目的地址变成另外一个 Pod 地址，再继续转发至 eth0，发给正确的集群节点。 :::center ![](../assets/netfilter-k8s.svg)