Skip to content

Commit d6a2803

Browse files
author
wangyazhou
committed
添加内核网络相关内容
1 parent a24675f commit d6a2803

28 files changed

+3673
-0
lines changed

Excalidraw/linux内核网络.excalidraw.md

Lines changed: 172 additions & 0 deletions
Large diffs are not rendered by default.

network/Linux内核网络.md

Lines changed: 301 additions & 0 deletions
Large diffs are not rendered by default.

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

Lines changed: 2988 additions & 0 deletions
Loading
Loading
Loading
Loading
Loading
Loading
Loading

network/attachments/bridge-call-iptables-Ca9l8Wli.svg

Lines changed: 1 addition & 0 deletions
Loading

network/attachments/linux-namespace-X9XifakO.svg

Lines changed: 1 addition & 0 deletions
Loading

network/attachments/networking-CafBaqd-.svg

Lines changed: 1 addition & 0 deletions
Loading

network/attachments/tun-B2X1RgPF.svg

Lines changed: 1 addition & 0 deletions
Loading

network/协议/HTTPS.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
2+
## 协议
3+
4+
### https协议握手流程
5+
请求的各个阶段共需要 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 内容传输)
6+
![](attachments/Pasted%20image%2020250603094553.png)
7+
8+
9+
### 使用 TLS1.3 协议
10+
2018 年发布的 TLS 1.3 协议通过优化 SSL 握手过程,将握手时延缩短至 1 RTT;在复用连接的情况下,还可利用 early_data 机制实现 0 RTT
11+
![](attachments/Pasted%20image%2020250603095427.png)
12+
以 Nginx 配置为例,确保 Nginx 版本 ≥ 1.13.0,OpenSSL 版本 ≥ 1.1.1。然后,在配置文件中使用 ssl_protocols 指令启用 TLSv1.3 支持。
13+
14+
### 使用 ECC 证书
15+
HTTPS 数字证书分为 RSA 证书和 ECC 证书,二者的区别如下:
16+
17+
- RSA 证书:在传统安全通信和数字签名应用中占主导地位,适用于对兼容性要求高,对性能要求不苛刻的场景。
18+
- ECC 证书:是新一代加密算法趋势,适合移动互联网、物联网等对资源敏感的场景,以及对安全性和性能要求高的新应用。
19+
20+
ECC 证书的优点是加密和解密操作更快速,对计算资源需求低,也更安全。在相同安全级别下,256 位的 ECC 密钥安全性大致相当于 3072 位的 RSA 密钥。
21+
22+
ECC 证书的主要缺点是兼容性较弱,一些“古代”系统(如 Windows XP、Android 4.0 等)不支持。值得庆幸的是,Nginx 自 1.11.0 起支持同时配置 RSA 和 ECC 证书。在 TLS 握手时,Nginx 会根据客户端支持的密码套件(Cipher Suite)选择兼容的证书。
23+
24+
Nginx 双证书配置示例如下:
25+
```nginx
26+
server {
27+
listen 443 ssl;
28+
ssl_protocols TLSv1.2 TLSv1.3;
29+
30+
# RSA 证书
31+
ssl_certificate /cert/rsa/fullchain.cer;
32+
ssl_certificate_key /cert/rsa/thebyte.com.cn.key;
33+
# ECDSA 证书
34+
ssl_certificate /cert/ecc/fullchain.cer;
35+
ssl_certificate_key /cert/ecc/thebyte.com.cn.key;
36+
37+
# 其他 SSL 配置...
38+
}
39+
```
40+
需要注意的是,配置了 ECC 证书并不意味着它一定会生效。ECC 证书的生效与客户端和服务端协商的密码套件(Cipher Suite)密切相关。
41+
Nginx 中密码套件的相关配置如下所示:
42+
```nginx
43+
server {
44+
# 设置协商加密算法时,优先使用我们服务端的加密套件,而不是客户端浏览器的加密套件。
45+
ssl_prefer_server_ciphers on;
46+
# 配置密码套件
47+
ssl_ciphers 'ECDHE+CHACHA20:ECDHE+CHACHA20-draft:ECDSA+AES128:ECDHE+AES128:RSA+AES128:RSA+3DES';
48+
49+
# 其他 SSL 配置...
50+
}
51+
```
52+
接下来使用 openssl ciphers -V 命令查看服务端支持的密码套件,及其优先级:
53+
```nginx
54+
$ openssl ciphers -V 'ECDHE+CHACHA20:ECDHE+CHACHA20-draft:ECDSA+AES128:ECDHE+AES128:RSA+AES128:RSA+3DES' | column -t
55+
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
56+
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
57+
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
58+
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
59+
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
60+
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
61+
```

network/协议/QUIC.md

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

network/协议/TCP.md

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

0 commit comments

Comments
 (0)