添加内核网络相关内容

Author: wangyazhou

Excalidraw/linux内核网络.excalidraw.md

@@ -0,0 +1,61 @@
+
+## 协议
+
+### https协议握手流程
+请求的各个阶段共需要 5 个 RTT（Round-Trip Time，往返时间）[[1]](https://www.thebyte.com.cn/http/https-latency.html#footnote1) 具体为：1 RTT（DNS Lookup，域名解析）+ 1 RTT（TCP Handshake，TCP 握手）+ 2 RTT（SSL Handshake，SSL 握手）+ 1 RTT（Data Transfer，HTTP 内容传输）
+![](attachments/Pasted%20image%2020250603094553.png)
+
+
+### 使用 TLS1.3 协议
+2018 年发布的 TLS 1.3 协议通过优化 SSL 握手过程，将握手时延缩短至 1 RTT；在复用连接的情况下，还可利用 early_data 机制实现 0 RTT
+![](attachments/Pasted%20image%2020250603095427.png)
+以 Nginx 配置为例，确保 Nginx 版本 ≥ 1.13.0，OpenSSL 版本 ≥ 1.1.1。然后，在配置文件中使用 ssl_protocols 指令启用 TLSv1.3 支持。
+
+### 使用 ECC 证书
+HTTPS 数字证书分为 RSA 证书和 ECC 证书，二者的区别如下：
+
+- RSA 证书：在传统安全通信和数字签名应用中占主导地位，适用于对兼容性要求高，对性能要求不苛刻的场景。
+- ECC 证书：是新一代加密算法趋势，适合移动互联网、物联网等对资源敏感的场景，以及对安全性和性能要求高的新应用。
+
+ECC 证书的优点是加密和解密操作更快速，对计算资源需求低，也更安全。在相同安全级别下，256 位的 ECC 密钥安全性大致相当于 3072 位的 RSA 密钥。
+
+ECC 证书的主要缺点是兼容性较弱，一些“古代”系统（如 Windows XP、Android 4.0 等）不支持。值得庆幸的是，Nginx 自 1.11.0 起支持同时配置 RSA 和 ECC 证书。在 TLS 握手时，Nginx 会根据客户端支持的密码套件（Cipher Suite）选择兼容的证书。
+
+Nginx 双证书配置示例如下：
+```nginx
+server {
+	listen 443 ssl;
+	ssl_protocols TLSv1.2 TLSv1.3;
+
+	# RSA 证书
+	ssl_certificate  /cert/rsa/fullchain.cer;
+	ssl_certificate_key  /cert/rsa/thebyte.com.cn.key;
+	# ECDSA 证书
+	ssl_certificate  /cert/ecc/fullchain.cer;
+	ssl_certificate_key  /cert/ecc/thebyte.com.cn.key;
+
+    # 其他 SSL 配置...
+}
+```
+需要注意的是，配置了 ECC 证书并不意味着它一定会生效。ECC 证书的生效与客户端和服务端协商的密码套件（Cipher Suite）密切相关。
+Nginx 中密码套件的相关配置如下所示：
+```nginx
+server {
+	# 设置协商加密算法时，优先使用我们服务端的加密套件，而不是客户端浏览器的加密套件。
+	ssl_prefer_server_ciphers on;
+	# 配置密码套件
+    ssl_ciphers 'ECDHE+CHACHA20:ECDHE+CHACHA20-draft:ECDSA+AES128:ECDHE+AES128:RSA+AES128:RSA+3DES';
+
+    # 其他 SSL 配置...
+}
+```
+接下来使用 openssl ciphers -V 命令查看服务端支持的密码套件，及其优先级：
+```nginx
+$ openssl ciphers -V 'ECDHE+CHACHA20:ECDHE+CHACHA20-draft:ECDSA+AES128:ECDHE+AES128:RSA+AES128:RSA+3DES' | column -t
+0x13,0x02  -  TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(256)             Mac=AEAD
+0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any   Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
+0x13,0x01  -  TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any   Au=any    Enc=AESGCM(128)             Mac=AEAD
+0xCC,0xA9  -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=CHACHA20/POLY1305(256)  Mac=AEAD
+0xCC,0xA8  -  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
+0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)             Mac=AEAD
+```

network/Linux内核网络.md

@@ -0,0 +1,59 @@
+
+## QUIC 设计原理与实践
+QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于 UDP 封装的安全可靠传输协议，旨在取代 TCP 成为新一代互联网的主流传输协议。
+
+很多人可能以为是 IETF 在推动 QUIC 替代 TCP。实际上，这项工作始于 Google。
+
+早在 2013 年，Google 就在自家服务（如 Google.com、YouTube.com）及 Chrome 浏览器中启用了名为“QUIC”（业内称为 gQUIC）的全新传输协议。2015 年，Google 将 gQUIC 提交给 IETF，经 IETF 规范化后的 QUIC 被称为“iQUIC”。早期的 iQUIC 有多个“草稿”版本，如 h3-27、h3-29 和 h3 v1。2018 年末，IETF 启动 HTTP/3 的标准化工作，并在 5 年后 (2022 年 6 月）将其正式定义为 RFC 9114，成为 HTTP 的第三个主要版本。
+可以看出 HTTP/3 最大的特点是底层基于 QUIC/UDP、默认集成了 TLS 安全协议。
+![](attachments/Pasted%20image%2020250603100754.png)
+###  QUIC 出现的背景
+QUIC 出现之前，HTTP 采用 TCP 作为底层协议来实现可靠的数据传输。
+
+作为四十年前开发的传输层协议，TCP 的设计者显然没有预见今天移动设备盛行的场景。在移动网络环境中，TCP 先天设计缺陷不断被放大。
+
+- **建立连接时延迟大**：HTTPS **初次连接（TCP 握手 + TLS 握手）至少需要 3 个 RTT** 才能建立。
+- **队头阻塞问题**：以 HTTP/2 为例，一个 TCP 连接上的所有 stream（流，HTTP/2 传输的数据单元）**必须按顺序依次传输**。如果一个 stream 丢失，后面的 stream 将被阻塞，直到丢失的数据重传。
+- **协议僵化问题**：作为一个运行了接近 40 多年的协议，许多中间设备（如防火墙和路由器）**已经变得依赖某些隐式规则**，打补丁或者说推动 TCP 协议更新脱离现实
+
+###  QUIC 的特点
+在借鉴 TCP 设计经验并考虑当前网络环境的基础上，QUIC 基于 UDP 实现了一种全新的可靠传输机制，具备更低的延迟、更高的吞吐量。下面列举 QUIC 的部分重要特性，这些特性是 QUIC 被寄予厚望的关键。
+
+#### 1. 支持连接迁移
+当用户的网络环境发生变化时，比如从 WIFI 切换到 4G，基于四元组的 TCP 连接无法保持存活。而 **QUIC 使用 Connection ID 标识连接**，不受环境变化影响。因此，QUIC 可以实现网络变化的无缝切换，保证连接存活和数据正常收发。
+![](attachments/Pasted%20image%2020250603100912.png)
+####  2. 低时延连接
+
+以 HTTPS 请求为例，即使是最新的 TLS 1.3 协议，**初次连接也至少需要 2-RTT 才能开启数据传输**。此外，像 TCP Fastopen 类补丁方案，由于协议僵化原因，实际上不会在复杂网络起到作用。
+
+QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，再经过 TLS 握手才开启数据传输。**QUIC 初次连接只需要 1- RTT 就能开启数据传输**。
+![](attachments/Pasted%20image%2020250603100934.png)
+
+#### 可插拔拥塞控制
+笔者曾推动升级某核心网络系统的 TCP 拥塞控制算法，过程艰难，主要因为需要升级操作系统内核版本。
+
+**大多数 QUIC 实现工作在用户空间，支持灵活“插拔”不同的拥塞控制算法**，如 Cubic、BBR 和 PCC 等。这让工程师在无需深入内核开发的情况下，能灵活调整可靠传输机制和拥塞控制策略。如 Cloudflare 开发的开源 QUIC 实现 quiche，提供了 setSendAlgorithm 方法，工程师可直接选择合适的拥塞控制算法，无需经过操作系统内核。
+
+#### 4. 降低对丢包的影响
+
+先来看 HTTP/2 Stream 的处理。
+
+如图 2-27 所示，若一个属于 Stream2 的 TCP 数据包丢失（如图中标记为 5 的圆圈），将导致后续数据包的传输阻塞。该问题就是业界常常提到的“队头阻塞”（head-of-line blocking）。
+
+相比之下，**QUIC 为每个 Stream 设计了独立的控制机制，Stream 之间没有先后依赖**。这意味着，如果一个属于 Stream2 的 UDP 数据包丢失，它只会影响 Stream2 的处理，不会阻塞 Stream1 和 Stream3 的传输。
+
+这样的设计有效避免了 TCP 协议中的队头阻塞问题。
+
+![](attachments/Pasted%20image%2020250603101009.png)
+此外，还需提及 QUIC 实现的另一个特性 —— QPACK。QPACK 通过更高效的头部压缩技术，减少了网络传输中的冗余数据量。这种压缩机制不仅提升了数据传输的效率，还能缓解前面提到的“队头阻塞”。
+
+经过上述全方面的优化设计，QUIC 确保了在当今网络环境中比 TCP 更安全、更快速的连接以及更高的传输效率。
+
+### QUIC 实践
+2022 年，爱奇艺基础架构团队对 HTTP/1.1、HTTP/2 和 HTTP/3 在不同网络条件下的性能差异进行了测试
+从请求耗时表现来看（图 2-28），相同的网络质量下，HTTP/3 的耗时比 HTTP/2 降低了近一半，证明了上述讨论不虚。
+![](attachments/Pasted%20image%2020250603101135.png)不过，根据图 2-29 所示的网络请求成功率来看，HTTP/3 的失败率明显高于 HTTP/2。笔者“猜测”有两方面的原因：
+
+- 某些网络环境下（如网络设备配置不当、防火墙限制），UDP 数据包更容易被丢弃。
+- QUIC 作为较新的协议，在一些边缘场景（如企业内部网络、陈旧的网络设备）中，兼容性不够完善。
+![](attachments/Pasted%20image%2020250603101155.png)

network/attachments/Netfilter-packet-flow-Rpo34JIM.svg

@@ -0,0 +1,88 @@
+
+
+
+## 拥塞控制
+
+### 网络拥塞控制原理
+网络吞吐量与 RTT、带宽密切相关，图 2-19 展示了这两者的变化对网络吞吐量的影响，可以看出：
+
+- RTT 越低，数据传输的延迟越低；
+- 带宽越高，网络在单位时间内传输的数据越多。
+![](attachments/Pasted%20image%2020250603100038.png)首先，解释图中的一些术语，它们的含义如下：
+
+- **RTprop (Round-Trip propagation time，两个节点之间最小时延)**：该值取决于物理距离，距离越长，时延越大。
+- **BtlBw（Bottleneck Bandwidth，瓶颈带宽）**：如果把网络链路想象成水管，RTprop 是水管的长度，BtlBw 则是水管最窄处的直径。
+- **BDP（Bandwidth-Delay Product，带宽、时延的乘积）**：它代表了网络上能够同时容纳的数据量（水管中有多少流动的水）。 BDP 的计算公式是：BDP = 带宽 × 时延。其中，带宽以比特每秒（bps）为单位，时延以秒为单位。
+- **inflight 数据**：指已经发送出去，仍在网络中传输，尚未收到接收方确认的数据包。
+
+受 RTT 和带宽影响，图 2-19 被分成了三个区间：
+
+1. (0，BDP)：称为“应用受限区”（app limited）。该区间内，inflight 数据量未占满瓶颈带宽。RTT 最小、传输速率最高。
+2. (BDP，BtlBwBuffSize)：称为“带宽受限区”（bandwidth limited）。该区间内，inflight 数据量已达到链路瓶颈容量，但尚未超过瓶颈容量加缓冲区容量。此时，应用能发送的数据量受带宽限制。RTT 逐渐变大，传输速率到达上限。
+3. (BDP + BtlBwBuffSize，infinity)：称为“缓冲受限区”（buffer limited）。该区间内，实际发送速率已超过瓶颈容量加缓冲区容量，超出部分的数据会被丢弃，从而产生丢包。RTT 以及传输速率均达到上限。
+
+从图 2-19 可以看出，拥塞的本质是 inflight 数据量持续偏离 BDP 线向右扩展。所以，拥塞控制的关键在于调节 inflight 数据量保持在合适的区间。显然，当 inflight 数据量位于“应用受限区”与“带宽受限区”的边界时，传输速率接近瓶颈带宽，且无丢包发生。
+
+
+### 早期拥塞控制旨在收敛
+
+早期互联网的拥塞控制以丢包为控制条件，控制逻辑如图 所示。
+
+发送方维护一个称为“拥塞窗口”（cwnd）的状态变量，其大小取决于网络拥塞程度和所采用的拥塞控制算法。数据传输过程中，发送方首先进入“慢启动”阶段，逐步增大拥塞窗口；当发生丢包时，进入“拥塞避免”阶段，逐步减小拥塞窗口；丢包消失后，再次进入慢启动阶段，如此一直反复
+![](attachments/Pasted%20image%2020250603100115.png)
+以丢包为控制条件的机制适应了早期互联网的特征：低带宽、浅缓存队列。
+
+随着移动互联网的快速发展，尤其是图片和音视频应用的普及，网络负载大幅增加。同时，摩尔定律推动设备性能不断提升、成本持续下降。当路由器、网关等设备的缓存队列增大，网络链路变得更长、更宽时，RTT 可能因队列增加而上升，丢包则可能由于链路过长。也就是说，网络变差并不总是因为拥塞所致。因此，以丢包为控制条件的传统拥塞控制算法就不再适用了
+
+### 现代拥塞控制旨在效能最大化
+早期的拥塞控制算法侧重于收敛，以避免互联网服务因“拥塞崩溃”而失效。BBR 算法的目标更进一步，充分利用链路带宽、路由/网关设备缓存队列，最大化网络效能。
+
+最大化网络效能的前提是找到网络传输中的最优点，图 2-21 中的两个圆圈即代表网络传输的最优点。
+
+- 上面的圆圈为 min RTT（延迟极小值）：此时，网络中路由/网关设备的 Buffer 未占满，没有任何丢包情况。
+- 下面圆圈的为 max BW（带宽极大值）：此时，网络中路由/网关设备的 Buffer 被充分利用。
+
+当网络传输处于最优点时：
+
+- 数据包投递率 = BtlBW（瓶颈带宽），保证了瓶颈链路被 100% 利用；
+- 在途数据包总数 = BDP（时延带宽积），保证了 Buffer 的利用合理。
+
+然而，最小延迟与最大带宽互相矛盾，无法同时测量。如图 2-21 所示，测量最大带宽时，必须填满瓶颈链路，此时缓冲区被占满，导致延迟增大；测量最小延迟时，需确保缓冲区不能被占满，这又无法测量最大带宽。
+![](attachments/Pasted%20image%2020250603100147.png)
+
+### BBR 的设计原理
+BBR 的解题思路是不再考虑丢包作为拥塞的判断条件，而是交替测量带宽和延迟，观测一段时间内的最大带宽和最小延迟来估算发包速率：
+
+- 为了最大化带宽利用率，BBR 周期性探测链路条件的改善，并在检测到带宽提升时增加发包速率；
+- 为了防止数据在中间设备缓存队列中堆积，BBR 定期探测链路的最小 RTT，并根据最小 RTT 调整发包速率。
+
+BBR 的拥塞控制状态机是实现上述设计的核心基础。该状态机在任何时刻处于以下四种状态之一：启动（STARTUP）、排空（DRAIN）、带宽探测（PROBE_BW）和时延探测（PROBE_RTT）。
+
+这四种状态的含义以及转换关系如图 2-22 所示。
+
+- **启动阶段**（STARTUP）：连接建立时，BBR 采用类似传统拥塞控制的慢启动方式，指数级提升发送速率，目的是尽快找到最大带宽。当在连续一段时间内检测到发送速率不再增加，说明瓶颈带宽已达到，此时状态切换至排空阶段。
+- **排空阶段**（DRAIN）：此阶段通过指数级降低发送速率，执行启动阶段的反向操作，目的是逐步清空缓冲区中的多余数据包。
+- **带宽探测阶段**（PROBE_BW）：完成启动和排空阶段后，BBR 进入带宽探测阶段，这是 BBR 主要运行的状态。当 BBR 探测到最大带宽和最小延迟，并且在途数据量（inflight）等于 BDP 时，BBR 以稳定的速率维持网络状态，并偶尔小幅提速探测更大的带宽或小幅降速以公平释放带宽。
+- **时延探测阶段**（PROBE_RTT）：如果未检测到比前一周期更小的最小 RTT，则进入时延探测阶段。在该状态下，拥塞窗口（Cwnd）被设定为 4 个 MSS（最大报文段长度），并重新测量 RTT，持续 200ms。超时后，根据网络带宽是否已满载，决定切换至启动阶段或带宽探测阶段。
+
+![状态转移关系](attachments/Pasted%20image%2020250603100235.png)  
+
+从 Linux 4.9 内核开始，BBR 被正式集成。此后，大多数 Linux 发行版仅需几条命令即可启用 BBR 算法。
+
+通过 Linux 流量控制工具（tc），可以在两台机器之间模拟不同的延迟和丢包条件，以测试各类拥塞控制算法的性能。直接来看测试结果，可以发现，在轻微丢包的网络环境下，BBR 的表现尤为突出。
+
+| 服务端的拥塞控制算法 | 延迟     | 丢包率  | 吞吐性能表现    |
+|------------|--------|------|-----------|
+| Cubic      | <1ms   | 0%   | 2.35Gb/s  |
+| Reno       | <140ms | 0%   | 195 Mb/s  |
+| Cubic      | <140ms | 0%   | 147 Mb/s  |
+| Westwood   | <140ms | 0%   | 344 Mb/s  |
+| BBR        | <140ms | 0%   | 340 Mb/s  |
+| Reno       | <140ms | 1.5% | 1.13 Mb/s |
+| Cubic      | <140ms | 1.5% | 1.23 Mb/s |
+| Westwood   | <140ms | 1.5% | 2.46 Mb/s |
+| BBR        | <140ms | 1.5% | 160 Mb/s  |
+| Reno       | <140ms | 3%   | 0.65 Mb/s |
+| Cubic      | <140ms | 3%   | 0.78 Mb/s |
+| Westwood   | <140ms | 3%   | 0.97 Mb/s |
+| BBR        | <140ms | 3%   | 132 Mb/s  |