vault backup: 2026-05-27 00:12:00

2026-05-27 00:12:00 +08:00
parent 838e5e7824
commit 91b4fe3f36
9 changed files with 1116 additions and 180 deletions
@@ -74,16 +74,16 @@ graph BT
 ```mermaid
 flowchart LR
    A["OSI 七层模型<br/>ISO 标准"] --> B{谁先落地？}
-    B -->|"1970s 末"| C["TCP/IP 已部署在 ARPANET"]
-    B -->|"1980s 后"| D["OSI 标准太多太复杂"]
+    B -->|"1983 Flag Day"| C["TCP/IP 正式接管 ARPANET"]
+    B -->|"标准滞后"| D["OSI 标准太多太复杂"]
    C --> E["事实标准 ✅"]
    D --> E
    style E fill:#98FB98,color:#000
 ```

- **先发优势**：ARPANET / Internet 先用上了 TCP/IP，基础设施已经建成
+- **先发优势**：1983 年 1 月 1 日（Flag Day），ARPANET 强制切换到 TCP/IP，基础设施已建成，生态不可逆转
 - **简单粗暴**：TCP/IP 只关心能不能跑通，不搞复杂的标准化流程
- **开源免费**：Berkeley BSD Unix 内嵌 TCP/IP 协议栈，免费分发
+- **开源免费**：Berkeley BSD Unix 内嵌 TCP/IP 协议栈（1983 年 4.2BSD），免费分发
 - **OSI 的反面教材**：层层审批导致协议膨胀（X.400 邮件、X.25 分组交换），开发者根本懒得用

 ## 五层教学模型
@@ -92,10 +92,10 @@ flowchart LR

 ```mermaid
 flowchart TD
-    A["应用层 — Application<br/>HTTP DNS SMTP SSH FTP SMTP POP3 IMAP WebSocket"] --> T["传输层 — Transport<br/>TCP UDP SCTP"]
-    T --> N["网络层 — Internet<br/>IP IPv6 ICMP ARP NAT"]
-    N --> D["链路层 — Link<br/>Ethernet Wi-Fi 802.11 VLAN HDLC PPP"]
-    D --> P["物理层 — Physical<br/>双绞线 光纤 无线电 IEEE 802.15"]
+    A["应用层 — Application<br/>HTTP, DNS, SMTP, SSH, FTP, POP3, IMAP, WebSocket"] --> T["传输层 — Transport<br/>TCP, UDP, SCTP"]
+    T --> N["网络层 — Internet<br/>IP, IPv6, ICMP, ARP, NAT"]
+    N --> D["链路层 — Link<br/>Ethernet, Wi-Fi, 802.11, VLAN, HDLC, PPP"]
+    D --> P["物理层 — Physical<br/>双绞线, 光纤, 无线电, IEEE 802.15"]
    style A fill:#DDA0DD
    style T fill:#FFD700
    style N fill:#87CEEB
@@ -153,7 +153,19 @@ sequenceDiagram
 > 每一层只知道自己那一层的 header 是什么格式，对其他层的内容一无所知。这就是**层间透明**原则。

 > [!QUESTION] 如果每一层都要加头部，开销岂不是很大？
-> 没错。一个 1 字节的应用层数据，经过 TCP/IP/以太网三层封装后，可能膨胀到 50+ 字节（TCP 头 20B + IP 头 20B + 以太网帧头帧尾 18B）。这就是为什么对小数据量、低延迟场景，业界会选择 **UDP**（头部仅 8 字节）甚至 **QUIC**（合并传输层与加密层）来减少开销。
+> 没错。一个 1 字节的应用层数据，经过 TCP/IP/以太网三层封装后，可能膨胀到 58 字节（TCP 头 20B + IP 头 20B + 以太网帧头帧尾 18B）。这就是为什么对小数据量、低延迟场景，业界会选择 **UDP**（头部仅 8 字节）甚至 **QUIC**（合并传输层与加密层）来减少开销。
+
+### MTU 与 MSS：分层边界如何约束数据大小
+
+分层不只是理论模型，它直接决定了每层能传多大的数据：
+
+| 概念 | 所在层 | 含义 | 典型值 |
+|------|--------|------|--------|
+| **MTU**（Maximum Transmission Unit） | 链路层 | 一个帧能承载的最大数据量 | 以太网默认 **1500B** |
+| **MSS**（Maximum Segment Size） | 传输层 | 一个 TCP 段能承载的最大应用数据 | 1500 - 20(IP) - 20(TCP) = **1460B** |
+
+> [!QUESTION] 为什么下载大文件时网络层会有大量小包？
+> 当你要发一个 100KB 的文件时，TCP 会按 MSS（1460B）将其切割成约 70 个段，每个段再交给网络层封装成 Packet，最后由链路层加上帧头帧尾变成 Frame。**分层的每一级都有自己的大小限制**，超出就要分片或分段——这就是 Path MTU Discovery（路径 MTU 发现）存在的原因：找到整条路径上最小的 MTU，避免中间路由器做 IP 分片（分片会严重影响性能）。

 ## 分层在代码中的体现