网络协议 on 方糖猫Blog

基于 UDP 通信的洋葱网络设计：服务器、Android 客户端与 P2P 控制总结

Tue, 19 Dec 2017 10:00:00 +0800

基于 UDP 通信的洋葱网络设计：服务器、Android 客户端与 P2P 控制总结

最近要实现端到端的加密通信，现在把设计方案记录下来。目标读者：刚接触洋葱网络、P2P 或 UDP 信令设计，想了解「怎么用 UDP 搭一个匿名转发网络，再基于它做 P2P」的同学。
阅读目标：建立整体架构图、理解关键模块职责、记住常见踩坑点。

0. 写在前面：为什么用 UDP 做洋葱网络 + P2P 信令？

洋葱网络（Onion Network）的核心思想是：数据像剥洋葱一样，一层一层加密转发。每一跳节点只知道上一跳和下一跳，不知道完整路径，从而保护通信双方的隐私。

传统洋葱路由（如 Tor）多跑在 TCP 上，因为 TCP 可靠、有序。但在移动场景或 P2P 场景里，UDP 有几个独特优势：

开销小：UDP 头只有 8 字节，没有连接建立/拆除开销，适合移动弱网。
NAT 友好：UDP 是 NAT 打洞（Hole Punching）最常用的传输层协议，STUN/TURN/ICE 都优先用 UDP。
适合信令：P2P 建立连接前的「打招呼」消息很短，UDP 足够用；真正的大数据再切到 P2P 直连或中继。
抗审查更灵活：无连接特性让流量更像普通 DNS/QUIC/游戏报文，便于混淆。

但 UDP 也带来问题：

不保证可靠、不保证顺序，需要自己在应用层做重传、去重、拥塞控制。
报文可能被分片、被防火墙限制、被运营商 QoS。

这篇文章会带你从「一个 UDP 报文怎么进洋葱网络」开始，逐步拆解：

洋葱网络的层次结构与加密过程。
服务器（目录服务 + 中继 + 信令服务）应该怎么设计。
Android 客户端的结构与关键代码思路。
怎么用这套 UDP 信令网络做 P2P 控制（NAT 穿透、打洞、直连、中继回退）。
新人最容易踩的坑与规避方法。

1. 洋葱网络核心概念：先建立「知识地图」

1.1 洋葱路由 vs 普通代理的区别

对比项	普通代理	洋葱网络
路径	单跳	多跳（通常 3 跳）
加密	端到端一次加密	每跳一层加密
节点知情范围	代理知道你是谁、你访问哪	每跳只知道上一跳和下一跳
代表	HTTP/SOCKS 代理	Tor、I2P、自定义洋葱网络

1.2 一次洋葱转发的过程

假设 Alice 要给 Bob 发消息，路径为：

flowchart LR
    A[Alice] --> E["入口节点 (Entry)"] --> M["中间节点 (Middle)"] --> X["出口节点 (Exit)"] --> B[Bob]

Alice 会先把报文从后往前逐层加密：

用 Exit 的公钥加密「Exit → Bob 的真实数据」，得到 C3。
用 Middle 的公钥加密「下一站是 Exit + C3」，得到 C2。
用 Entry 的公钥加密「下一站是 Middle + C2」，得到 C1。

然后 Alice 把 C1 发给 Entry。Entry 用自己的私钥解密后，看到「下一站是 Middle」，把 C2 转发给 Middle。Middle 解密后转发 C3 给 Exit。Exit 解密后拿到真实数据，发给 Bob。

flowchart LR
    A[Alice] -->|C1| E[Entry<br/>解密: 下一站 Middle] -->|C2| M[Middle<br/>解密: 下一站 Exit] -->|C3| X[Exit<br/>解密: 真实数据] -->|明文| B[Bob]

新人记忆点：洋葱网络的数据是「加密好的俄罗斯套娃」，每到一个节点就剥掉一层外衣。

1.3 UDP 洋葱报文的基本结构

一个 UDP 洋葱报文可以简单设计为：

+----------------+----------------+----------------+----------------+
|  版本 (1B)     |  命令 (1B)     |    跳数 (1B)   |   预留 (1B)    |
+----------------+----------------+----------------+----------------+
|                        会话 ID / 电路 ID (4B)                       |
+----------------+----------------+----------------+----------------+
|                         下一跳洋葱层数据 ...                       |
+------------------------------------------------------------------+

版本：协议版本，方便后续升级。
命令：路由、数据、建立、销毁、心跳等。
跳数 / TTL：防止报文无限循环，每经过一跳减 1。
会话 ID / 电路 ID：标识一条逻辑链路，让节点知道该用哪把密钥解密。
下一跳洋葱层数据：被当前节点私钥解密后，才能得到真正的下一跳地址和载荷。

新人容易混淆的点：洋葱网络里的「加密」不是端到端 TLS，而是逐跳加密。每一跳都能解密自己最外层，但看不到内层。

2. 系统整体架构

flowchart TB
    subgraph 公网服务层
        DS[Directory Server<br/>目录服务：发布可信节点]
        SS[Signaling Server<br/>信令服务：NAT 信息交换]
        RS[Relay Server<br/>中继服务：UDP 洋葱转发]
    end

    subgraph Android 客户端
        AC[App 业务层]
        CM[Connection Manager<br/>管理 Circuits / Peers]
        OC[Onion Core<br/>分层加密 / 解密]
        NC[Network Core<br/>UDP Socket / NAT / ICE]
    end

    subgraph 对端
        P2P[Peer B<br/>Android / Server / IoT]
    end

    AC --> CM
    CM --> OC
    CM --> NC
    OC --> NC
    NC -->|UDP| RS
    NC -->|UDP| SS
    NC -.->|查询节点列表| DS
    NC -.->|P2P 直连或中继| P2P

2.1 三类服务器职责

服务	职责	协议
Directory Server（目录服务）	维护可信中继节点列表、公钥、负载、版本	HTTPS / UDP 查询
Signaling Server（信令服务）	帮助两个 Peer 交换公网 IP:Port、NAT 类型、候选地址	UDP + 可靠信令协议
Relay Server（中继服务）	当 P2P 打洞失败时，转发 UDP 洋葱流量	UDP 洋葱路由

实际部署中，目录服务可以用 HTTPS 更稳；信令和中继为了速度和 NAT 友好，优先用 UDP。

3. 服务器端设计

3.1 目录服务（Directory Server）

目录服务就像「黄页」，让客户端知道哪些中继节点在线、可信、负载低。

核心数据模型

Node {
    node_id:        节点唯一 ID
    public_key:     Ed25519/X25519 公钥
    endpoint:       公网 IP:UDP 端口
    bandwidth:      声明带宽（Mbps）
    load:           当前负载（连接数 / 带宽占用）
    version:        协议版本
    flags:          入口 / 中间 / 出口 / 中继 标志位
    last_seen:      最后一次心跳时间
    signature:      节点用私钥对以上字段签名
}

客户端获取节点列表的流程

sequenceDiagram
    participant C as Android Client
    participant D as Directory Server
    participant N1 as Node Entry
    participant N2 as Node Middle
    participant N3 as Node Exit

    C->>D: HTTPS GET /nodes?count=3&flags=entry|middle|exit
    D-->>C: 返回节点列表 + 签名
    C->>C: 验证签名、选择路径
    C->>N1: UDP 建立 Circuit 请求
    N1-->>C: 返回 Circuit ID
    C->>N1: 经过 N1 转发到 N2 建立
    N2-->>C: 返回确认
    C->>N2: 经过 N1→N2 转发到 N3 建立
    N3-->>C: 返回确认

新人避坑：目录服务返回的节点列表必须带签名，客户端要校验，否则会被恶意节点钓鱼。

3.2 中继服务（Relay Server）

中继服务是洋葱网络里的「快递员」：收到一个 UDP 报文，解密最外层，转发给下一跳。

核心状态

Circuit {
    circuit_id:     本节点分配的 32 位 ID
    prev_node:      上一跳地址（IP:Port）
    next_node:      下一跳地址（IP:Port）
    shared_key:     与创建者协商的共享密钥
    created_at:     创建时间
    last_active:    最后活跃时间
    bytes_forward:  转发字节数
}

转发流程

flowchart TD
    A[收到 UDP 报文] --> B{报文格式合法?}
    B -->|否| C[直接丢弃]
    B -->|是| D[查找 circuit_id]
    D --> E{存在?}
    E -->|否| C
    E -->|是| F[用 shared_key 解密洋葱层]
    F --> G{解密成功?}
    G -->|否| C
    G -->|是| H[读取下一跳地址 + 内层数据]
    H --> I[TTL - 1]
    I --> J{TTL > 0?}
    J -->|否| K[发送销毁通知]
    J -->|是| L[转发给下一跳]

关键设计点

限速与防滥用：单 Circuit 限制带宽，防止被当免费代理滥用。
TTL 与环检测：每跳 TTL 减 1，到 0 丢弃，防止恶意构造环路。
密钥派生：每个 Circuit 用 X25519 ECDH 协商出共享密钥，再用 HKDF 派出发送/接收两个方向的对称密钥。
无日志策略：中继节点不记录明文内容、不记录完整路径（实际上也看不到）。

3.3 信令服务（Signaling Server）

信令服务是 P2P 的「媒人」：两个 Peer 无法直接找到对方公网地址时，通过信令服务交换信息。

数据模型

PeerInfo {
    peer_id:        用户/设备唯一 ID
    public_key:     用于加密信令的公钥
    nat_type:       全锥型 / 限制型 / 端口限制型 / 对称型
    local_candidates: [局域网 IP:Port, ...]
    srflx_candidates: [STUN 映射后的公网 IP:Port, ...]
    relay_candidates: [TURN 中继地址, ...]
    timestamp:      更新时间
    signature:      防止伪造
}

典型信令流程

sequenceDiagram
    participant A as Peer A
    participant S as Signaling Server
    participant B as Peer B

    A->>S: 注册/上报 PeerInfo（UDP 心跳包）
    B->>S: 注册/上报 PeerInfo

    A->>S: 请求连接 peer_B
    S->>S: 检查 A、B 是否在线
    S-->>A: 返回 B 的候选地址列表
    S-->>B: 转发 A 的连接请求 + A 的候选地址

    A->>A: 按优先级尝试直连 / 打洞
    B->>B: 同时尝试直连 / 打洞
    A-->>B: UDP 打洞成功，建立 P2P
    B-->>A: 业务数据互通

    alt 打洞失败
        A->>S: 请求中继
        S-->>A: 分配 Relay 地址
        S-->>B: 通知 B 通过 Relay 通信
        A->>R: 经中继与 B 通信
    end

新人避坑：信令服务本身不传输业务数据，只传「怎么找到对方」。不要把它当成聊天服务器用。

4. Android 客户端设计

Android 客户端需要同时处理：业务逻辑、洋葱路由、UDP 网络、NAT 穿透、后台保活。建议按层拆分。

4.1 客户端分层架构

flowchart TB
    subgraph 应用层
        UI[UI / ViewModel]
        API[业务 API]
    end

    subgraph 网络中间层
        CM[ConnectionManager<br/>管理多 Circuit / 多 Peer]
        P2P[P2PController<br/>打洞 / 直连 / 中继决策]
        SM[SignalingClient<br/>与信令服务通信]
    end

    subgraph 核心引擎层
        OC[OnionCore<br/>加密 / 解密 / 报文封装]
        NC[NetworkCore<br/>UDP Socket / ICE / STUN]
        CR[CircuitStore<br/>持久化 Circuit 状态]
    end

    UI --> API
    API --> CM
    CM --> P2P
    CM --> SM
    CM --> OC
    P2P --> OC
    P2P --> NC
    SM --> NC
    OC --> NC
    CM --> CR

4.2 关键模块说明

模块	职责	技术要点
`ConnectionManager`	管理所有活跃 Circuit 和 Peer 连接	连接池、复用、超时清理
`P2PController`	决定是否直连、打洞、还是走中继	ICE 候选排序、NAT 类型判断
`SignalingClient`	与信令服务器通信	UDP 心跳、请求/响应匹配、重传
`OnionCore`	分层加密/解密、报文打包	X25519、ChaCha20-Poly1305、HKDF
`NetworkCore`	UDP Socket、STUN/ICE、NAT 类型探测	DatagramChannel、线程模型、电池优化
`CircuitStore`	本地缓存 Circuit 信息	SQLite / MMKV、加密存储

4.3 NetworkCore 线程模型

UDP 网络层要避免在主线程做 IO，也避免一个线程处理所有事导致卡顿。

flowchart LR
    subgraph 网络线程
        RT[ReceiveThread<br/>阻塞 recvFrom]
        RT -->|Raw Packet| DP[DecoderPipeline<br/>STUN / 洋葱 / 业务]
        DP -->|业务消息| MQ[MessageQueue]
        DP -->|信令响应| SR[SignalingResponseMap]
    end

    subgraph 发送线程
        SQ[SendQueue<br/>优先级队列]
        ST[SendThread<br/>定时 flush]
        SQ --> ST -->|sendTo| Socket
    end

    subgraph 业务线程
        BH[BusinessHandler]
        MQ --> BH
    end

    Socket --> RT

4.4 Android 端 NAT 类型探测

客户端启动时，先用 STUN 服务器探测自己的 NAT 类型：

1. 向 STUN Server A 发 Binding Request，得到映射地址 M1。
2. 向 STUN Server B 发 Binding Request，得到映射地址 M2。
3. 比较 M1 和 M2：
   - 相同 → 可能全锥型 / 限制型
   - 不同 → 对称型 NAT（打洞困难）
4. 再测试其他 IP/Port 是否能把包送进本机，判断是限制型还是端口限制型。

flowchart TD
    A[开始探测] --> B[STUN A 请求]
    B --> C[得到 M1]
    C --> D[STUN B 请求]
    D --> E[得到 M2]
    E --> F{M1 == M2?}
    F -->|是| G[全锥 / 限制 / 端口限制]
    F -->|否| H[对称型 NAT]
    G --> I[进一步测试过滤规则]
    H --> J[P2P 大概率失败<br/>优先准备 Relay]

4.5 Android 后台保活与省电

P2P 需要客户端能被找到，但 Android 对后台限制越来越严。

方案	适用场景	注意事项
Foreground Service	需要长期在线	必须显示通知，用户可能反感
WorkManager 周期性心跳	非实时场景	最小间隔 15 分钟，无法保证即时
FCM / 厂商推送	唤醒 App 建立连接	国内厂商通道需要适配
保活 socket + 心跳	与信令服务维持 NAT 映射	心跳间隔建议 15-30s， balancing 电量

新人避坑：不要试图用「双进程守护」「1 像素 Activity」等旧保活手段，Android 高版本会被杀，且应用商店可能下架。

5. 通过 UDP 信令网络实现 P2P 控制

5.1 P2P 连接的三种结果

flowchart TD
    A[Peer A 想连 Peer B] --> B[通过信令服务获取 B 的候选地址]
    B --> C{尝试直连}
    C -->|成功| D[UDP P2P 直连]
    C -->|失败| E{尝试 NAT 打洞}
    E -->|成功| D
    E -->|失败| F[通过 Relay 中继]
    D --> G[业务通信]
    F --> G

5.2 ICE-like 候选地址优先级

graph LR
    A[直连候选<br/>局域网 IP] -->|优先级最高| B[srflx 候选<br/>STUN 映射公网地址]
    B -->|次高| C[prflx 候选<br/>对端看到的地址]
    C -->|再次| D[relay 候选<br/>TURN/中继服务器]

优先级规则：

host 候选：同一局域网直接连，延迟最低。
server reflexive（srflx）：STUN 映射后的公网地址，适合普通 NAT。
peer reflexive（prflx）：对端实际看到的地址，可能在打洞过程中发现。
relay 候选：最后兜底，走服务器转发。

5.3 NAT 打洞详细流程

假设 A 和 B 都在普通家用路由器后，NAT 类型为「端口限制锥型」。

sequenceDiagram
    participant A as Peer A
    participant SA as STUN/Signaling Server
    participant B as Peer B

    A->>SA: 注册：我的 srflx 是 1.1.1.1:10000
    B->>SA: 注册：我的 srflx 是 2.2.2.2:20000

    A->>SA: 请求连接 B
    SA-->>A: 返回 B 的地址 2.2.2.2:20000
    SA-->>B: 转发 A 的地址 1.1.1.1:10000

    A->>B: 发送 UDP 打洞包（可能到达或被过滤）
    B->>A: 发送 UDP 打洞包
    Note over A,B: 双方都先发包，让各自 NAT 建立映射

    A->>B: 收到 B 的包，回确认
    B->>A: 收到 A 的包，回确认
    Note over A,B: 打洞成功，后续直接通信

新人记忆点：NAT 打洞的本质是让双方路由器先记录一条「允许对方包进来」的映射。所以必须双方同时主动发一个包到对方公网地址。

5.4 基于洋葱网络的 P2P 控制通道

除了直接 P2P，还可以把「P2P 控制信令」本身也套在洋葱网络里，增强隐私：

flowchart LR
    A[Alice] -->|洋葱隧道| X[出口节点] --> S[信令服务器]
    B[Bob] -->|洋葱隧道| X

控制消息包括：

请求连接、交换候选地址。
协商加密密钥（用于 P2P 直连后的端到端加密）。
心跳、断开通知。
中继切换通知。

这样即使信令服务器被监控，攻击者也只能看到「某个洋葱出口在发信令」，不知道 Alice 和 Bob 的真实身份。

5.5 P2P 直连后的加密

P2P 直连本身不保证安全，还需要端到端加密：

sequenceDiagram
    participant A as Peer A
    participant S as Signaling Server（洋葱保护下）
    participant B as Peer B

    A->>S: 发送 X25519 公钥 PA
    S->>B: 转发 PA
    B->>S: 发送 X25519 公钥 PB
    S->>A: 转发 PB

    A->>A: ECDH 计算共享密钥 K
    B->>B: ECDH 计算共享密钥 K

    A->>B: 用 K 加密业务数据，UDP P2P 直连发送
    B->>A: 用 K 加密业务数据，UDP P2P 直连发送

新人避坑：洋葱网络的逐跳加密 ≠ P2P 端到端加密。如果数据离开出口节点后是明文，出口节点仍然能看到内容。真正保密需要在 P2P 直连后再做一次端到端加密。

6. 协议报文设计示例

6.1 洋葱路由报文

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version       | Command       | TTL           | Reserved        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Circuit ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+              Encrypted Onion Payload (variable)               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Command 定义示例：

值	命令	说明
0x01	CREATE	建立 Circuit
0x02	CREATED	建立成功响应
0x03	RELAY	中继数据
0x04	DESTROY	销毁 Circuit
0x05	HEARTBEAT	保活心跳

6.2 信令报文

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic (4B)    | Version (1B)  | Command (1B)  | Flags (2B)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Sequence Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Timestamp                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                    Encrypted Payload                          +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

信令 Command 示例：

值	命令	说明
0x10	REGISTER	客户端注册
0x11	OFFER	发起连接请求
0x12	ANSWER	响应连接请求
0x13	CANDIDATE	交换候选地址
0x14	HEARTBEAT	保活
0x15	ERROR	错误通知

新人避坑：UDP 报文要加 Magic 数和版本号，防止收到错乱的广播/扫描包时解析出错。

7. 关键算法与数据结构

7.1 Circuit 选择算法

客户端从目录服务拿到节点列表后，选择一条路径：

def choose_path(nodes, desired_hops=3):
    # 1. 过滤在线、版本兼容、flags 符合要求的节点
    valid = [n for n in nodes if n.is_online and n.version == PROTO_VERSION]
    
    # 2. 按负载和带宽评分，负载越低、带宽越高分越高
    scored = [(n, score(n)) for n in valid]
    scored.sort(key=lambda x: x[1], reverse=True)
    
    # 3. 随机选择前 K 个中的节点，避免总是选同一批
    candidates = scored[:max(len(scored)//3, desired_hops * 2)]
    
    # 4. 确保 Entry、Middle、Exit 来自不同运营商 / 网段，增加路径多样性
    path = []
    for role in ['entry', 'middle', 'exit']:
        chosen = pick_diverse(path, candidates, role)
        path.append(chosen)
    
    return path

7.2 消息可靠性保证

UDP 不保证可靠，应用层需要自己实现：

flowchart TD
    A[发送消息] --> B[分配 Seq]
    B --> C[加入重传队列]
    C --> D[UDP 发送]
    D --> E{收到 ACK?}
    E -->|是| F[从队列移除]
    E -->|否| G{超时?}
    G -->|否| E
    G -->|是| H[重传 N 次]
    H --> I{达到最大重试?}
    I -->|否| C
    I -->|是| J[通知上层失败]

重传策略建议：

初始超时：200ms（RTT 估计）。
退避：指数退避，最多 5 次。
ACK 去重：用滑动窗口或位图记录已确认 Seq。

7.3 连接状态机

P2P 连接可以建模为状态机：

stateDiagram-v2
    [*] --> Idle: 用户发起连接
    Idle --> Gathering: 收集 ICE 候选
    Gathering --> Connecting: 开始打洞/直连
    Connecting --> Connected: 收到对端包
    Connecting --> Relaying: 打洞失败，切中继
    Relaying --> Connected: 中继链路建立
    Connected --> Disconnected: 超时未收到心跳
    Disconnected --> [*]

8. 新人避坑技巧大全

8.1 UDP 层面的坑

坑	现象	规避方法
UDP 报文丢失	部分消息收不到	应用层 ACK + 重传；关键信令走可靠通道
UDP 乱序	消息顺序错乱	按 Seq 排序或丢弃过期包；业务层幂等
UDP 分片	大报文丢失率陡增	控制报文大小 < 1200 字节；必要时分片重组
运营商 QoS	高峰丢包严重	使用常见端口（如 443/8080）或混淆成 QUIC/DNS
防火墙拦截	某些网络 UDP 不通	准备 TCP 回退或 Relay 兜底

8.2 洋葱网络层面的坑

坑	现象	规避方法
Circuit 被重用	旧连接和新连接混用	每个 Circuit 带唯一 ID，过期销毁
时序攻击	入口和出口流量时间关联	引入填充（padding）和混合延迟
恶意出口节点	出口监听或篡改明文	P2P 必须端到端加密，不依赖出口
节点列表被污染	连上恶意节点	目录服务签名 + 节点身份固定 + 信誉系统
密钥管理混乱	加密失败或性能差	一个 Circuit 一对密钥，用 HKDF 派生

8.3 Android 层面的坑

坑	现象	规避方法
主线程网络	ANR / 卡顿	所有 UDP IO 放子线程或用协程
Doze 模式心跳中断	后台连接断开	使用 JobScheduler / WorkManager 补心跳
IPv4/IPv6 双栈	一端 v4 一端 v6 连不上	同时收集 v4/v6 候选地址
端口复用失败	`BindException`	Socket 设置 `SO_REUSEADDR` / `SO_REUSEPORT`
电量消耗高	用户卸载	动态心跳间隔，网络空闲时延长

8.4 P2P / NAT 层面的坑

坑	现象	规避方法
对称型 NAT 打洞失败	两边都收不到包	提前探测 NAT 类型，准备 Relay
hairpin NAT 不支持	同一局域网却走公网	优先尝试 host 候选
NAT 映射超时	长时间没通信后连不上	定期发送心跳保活
双方不同时打洞	一方先发可能被防火墙拦	设计让 A、B 同时主动发包
信令与数据通道混淆	安全边界不清	信令用短期密钥，数据用长期会话密钥

8.5 安全与隐私层面的坑

坑	现象	规避方法
只做了洋葱加密，没做端到端加密	出口节点可读明文	P2P 直连后再做一次 ECDH
时间戳不校验	重放攻击	每个报文带时间戳 + 滑动窗口
随机数可预测	Circuit ID 被猜中	用 SecureRandom / crypto.random
元数据泄露	包大小暴露内容类型	固定包长或随机填充
证书/公钥不校验	中间人攻击	目录服务签名 + 证书锁定

9. 一个最小可运行流程串起来

为了让新人有整体感，下面把一次「Alice 通过 UDP 洋葱网络控制 P2P 连接 Bob」的完整流程串起来。

sequenceDiagram
    participant A as Android Alice
    participant D as Directory Server
    participant S as Signaling Server
    participant R as Relay Server
    participant B as Android Bob

    %% 阶段 1：准备节点
    A->>D: HTTPS 获取节点列表
    D-->>A: 返回 Entry/Middle/Exit + 签名
    A->>A: 校验签名，选择路径
    A->>Entry: UDP CREATE Circuit
    Entry-->>A: CREATED
    A->>Middle: 经 Entry 转发 CREATE
    Middle-->>A: CREATED
    A->>Exit: 经 Entry→Middle 转发 CREATE
    Exit-->>A: CREATED

    %% 阶段 2：注册信令
    A->>S: 经洋葱隧道 REGISTER Alice
    B->>S: 经洋葱隧道 REGISTER Bob

    %% 阶段 3：发起 P2P
    A->>S: OFFER（请求连接 Bob）
    S->>B: 转发 OFFER + Alice 候选地址
    B->>S: ANSWER + Bob 候选地址
    S->>A: 转发 ANSWER

    %% 阶段 4：打洞
    A->>B: UDP 打洞包
    B->>A: UDP 打洞包
    A-->>B: 直连成功

    %% 阶段 5：业务通信
    A->>B: 端到端加密业务数据
    B->>A: 端到端加密业务数据

    %% 阶段 6：失败兜底
    alt 打洞失败
        A->>S: 请求 Relay
        S-->>A: 分配 Relay 地址
        S-->>B: 通知走 Relay
        A->>R: 经洋葱→Relay→Bob
    end

10. 总结：一张图记住全文

flowchart TB
    A[UDP 洋葱网络 + P2P] --> B[目录服务<br/>给节点]
    A --> C[信令服务<br/>撮合 Peer]
    A --> D[中继服务<br/>兜底转发]
    A --> E[Android 客户端<br/>洋葱 + NAT + P2P]
    E --> F[OnionCore<br/>逐跳加密]
    E --> G[NetworkCore<br/>UDP / STUN / ICE]
    E --> H[P2PController<br/>直连 / 打洞 / 中继]
    F --> I[隐私保护]
    G --> J[NAT 穿透]
    H --> K[去中心化通信]
    A --> L[避坑：可靠传输 / 端到端加密 / 后台保活]

核心要点回顾：

洋葱网络用 UDP 是为了轻量、NAT 友好、适合信令；但可靠性和顺序要自己补。
服务器分三类：目录服务（给节点）、信令服务（撮合 P2P）、中继服务（兜底转发）。
Android 客户端分层：业务层、连接管理层、核心引擎层、网络层，不要混在一处。
P2P 控制靠 UDP 信令交换地址，再用 ICE 候选优先级尝试直连、打洞、中继。
隐私不等于安全：洋葱网络保护路径隐私，P2P 业务数据还要端到端加密。
新人最容易踩的坑：UDP 当 TCP 用、忽略 NAT 类型、不做端到端加密、Android 主线程 IO。

参考与延伸阅读

Tor Project: https://www.torproject.org/
ICE / STUN / TURN RFCs: RFC 5245, RFC 5389, RFC 5766
WebRTC NAT Traversal 实践
Android DatagramSocket、WorkManager、Foreground Service 官方文档

如果你正在动手实现，建议先做一个「最小闭环」：一个目录服务 + 一个中继节点 + 两个 Android 客户端，先跑通「Alice 经洋葱网络发一条消息给 Bob」，再逐步加入 P2P 直连和 NAT 打洞。先跑通，再优化。

TCP/IP 学习总结与避坑指南

Sat, 09 Dec 2017 10:00:00 +0800

TCP/IP 学习总结与避坑指南

最近华为项目交付碰到各种头大的网络问题，现在整理下TCP/IP相关知识。参考书籍：W. Richard Stevens《TCP/IP 详解卷1：协议》、W. Richard Stevens《Unix 网络编程卷1：套接字联网 API》
目标读者：刚接触网络编程，或者学了很多概念但总觉得「协议栈串不起来」「代码一跑就掉坑」的同学。

TCP/IP 不是一门「背完就能会」的技术。它由一整套分层协议组成，每一层只关心自己的事情，又通过严格定义的头部把信息交给下一层。理解这套分层思维，是看懂网络报文、写出稳定网络程序、排查线上连接问题的第一步。

这篇文章不会把所有 RFC 都讲一遍（那是 1000 多页书做的事），而是帮你建立主干知识框架：

TCP/IP 协议栈为什么要分层？数据是怎么一层层包起来的？
IP、TCP、UDP、ARP、ICMP、DNS 这些协议各自解决什么问题？
Unix Socket 编程的核心 API 与调用顺序是什么？
写网络程序最容易踩哪些坑，怎么避开？
遇到连接失败、卡顿、端口耗尽这些问题，该按什么思路排查？

读完之后，你应该能看懂 Wireshark 里的大部分常见报文，也能独立写出稳定的 TCP 客户端/服务端，并具备基础的线上网络问题排查能力。

一、TCP/IP 协议栈：为什么必须分层？

网络通信的复杂度非常高：不同的物理介质、不同的操作系统、不同的应用程序要在全球范围内交换数据。如果不分层，每一台设备都要同时处理「电信号怎么传」「数据怎么路由」「传输可不可靠」「应用数据什么意思」所有问题。

分层的目的就是关注点分离：每一层只解决本层的问题，向上层提供服务，把复杂问题拆成可管理的小块。

1.1 OSI 七层模型 vs TCP/IP 四层模型

教学中常用 OSI 七层模型，但互联网实际运行的是 TCP/IP 四层模型。

graph LR
    subgraph OSI七层模型
        A7[7 应用层] --> A6[6 表示层]
        A6 --> A5[5 会话层]
        A5 --> A4[4 传输层]
        A4 --> A3[3 网络层]
        A3 --> A2[2 数据链路层]
        A2 --> A1[1 物理层]
    end

    subgraph TCP/IP四层模型
        B4[应用层<br/>HTTP/FTP/DNS/SMTP] --> B3[传输层<br/>TCP/UDP]
        B3 --> B2[网络层<br/>IP/ICMP/IGMP]
        B2 --> B1[网络接口层<br/>以太网/WiFi/PPP]
    end

    A7 -.对应.-> B4
    A6 -.对应.-> B4
    A5 -.对应.-> B4
    A4 -.对应.-> B3
    A3 -.对应.-> B2
    A2 -.对应.-> B1
    A1 -.对应.-> B1

TCP/IP 层	核心协议	解决的问题
应用层	HTTP、DNS、FTP、SMTP、SSH	应用程序之间「说什么」
传输层	TCP、UDP	进程到进程的通信，可靠或高效传输
网络层	IP、ICMP、IGMP、路由协议	主机到主机的寻址与路由
网络接口层	以太网、WiFi、ARP、PPP	相邻设备之间的物理/逻辑传输

新手容易混淆的点：TCP/IP 里的「应用层」实际上对应了 OSI 的应用层、表示层、会话层三层。不要死磕七层，实际工程里四层模型更常用。

1.2 数据封装与解封装

每一层都会给上一层的数据加一个「头部」，然后交给下一层。接收方则逐层去掉头部，把数据交给上层。

flowchart TB
    subgraph 发送方
        A[应用数据] -->|"应用层封装"| B["应用层头部 + 应用数据"]
        B -->|"传输层封装"| C["TCP/UDP 头部 + 应用层数据"]
        C -->|"网络层封装"| D["IP 头部 + TCP 数据段"]
        D -->|"链路层封装"| E["以太网头部 + IP 数据报 + 以太网尾部"]
    end

    E -->|"比特流在物理介质传输"| F

    subgraph 接收方
        F["以太网帧"] -->|"链路层解封装"| G["IP 数据报"]
        G -->|"网络层解封装"| H["TCP/UDP 数据段"]
        H -->|"传输层解封装"| I["应用层数据"]
        I -->|"应用层处理"| J[交给对应进程]
    end

关键概念：

MTU（Maximum Transmission Unit）：链路层帧能承载的最大数据量，以太网常见值是 1500 字节。
MSS（Maximum Segment Size）：TCP 一次能发送的最大数据段，通常 = MTU - IP 头 - TCP 头，以太网常见 1460 字节。
分片（Fragmentation）：当 IP 数据报超过链路 MTU 时，IP 层会把它切成多个片。TCP 一般会通过 MSS 避免分片，UDP 则容易触发分片。

避坑技巧：

不要随意修改 MTU，VPN/隧道场景特别容易出现「大数据包被静默丢弃」的问题。
UDP 应用如果要传输大报文，建议在应用层自己拆包，不要让 IP 层分片。

二、链路层与 ARP：同一局域网怎么找到对方？

链路层负责相邻节点之间的数据传输。在以太网里，设备用 MAC 地址标识，交换机根据 MAC 地址转发帧。

2.1 以太网帧结构

+----------------+----------------+----------------+----------------+----------------+
| 目的 MAC 6B    | 源 MAC 6B      | 类型 2B        | 数据 46~1500B  | FCS 4B         |
+----------------+----------------+----------------+----------------+----------------+

MAC 地址：48 位，全球唯一（理论上），用于局域网内定位网卡。
类型字段：例如 0x0800 表示上层是 IP，0x0806 表示 ARP。
FCS（Frame Check Sequence）：帧校验序列，检测传输过程中的比特错误。

2.2 ARP：IP 地址 → MAC 地址

ARP（Address Resolution Protocol）解决的是「知道对方 IP，但不知道对方 MAC」的问题。

sequenceDiagram
    participant A as 主机 A<br/>192.168.1.10
    participant B as 主机 B<br/>192.168.1.20

    A->>B: ARP 请求：谁的 IP 是 192.168.1.20？请告诉我你的 MAC
    Note over A,B: 广播帧，局域网内所有主机收到
    B->>A: ARP 应答：我是 192.168.1.20，MAC 是 xx:xx:xx:xx:xx:xx
    Note over A,B: 单播帧，只有 A 收到

ARP 表会缓存一段时间：arp -a 可以查看本机 ARP 缓存。

避坑技巧：

ARP 只在同一二层网络（同一广播域）有效。跨网段通信时，主机把报文发给网关，由网关继续转发。
网关配错是新手常见问题：如果默认网关不在同一子网，ARP 请求会失败，数据根本发不出去。
ARP 欺骗/中间人攻击在局域网内存在，敏感环境要开启动态 ARP 检测（DAI）或静态绑定。

三、IP 协议：主机到主机的寻址与路由

IP（Internet Protocol）是网络层的核心，负责把数据从源主机送到目的主机。它不保证可靠、不保证有序，这些由 TCP 或应用层自己处理。

3.1 IPv4 头部核心字段

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段含义：

Version：IPv4 填 4，IPv6 填 6。
IHL（Header Length）：头部长度，单位是 4 字节。没有选项时最小是 5，即 20 字节。
Total Length：整个 IP 数据报的长度，最大 65535 字节。
Identification / Flags / Fragment Offset：用于分片和重组。
TTL（Time to Live）：每经过一个路由器减 1，到 0 被丢弃，防止报文在网络里无限循环。
Protocol：上层协议类型。6 = TCP，17 = UDP，1 = ICMP，等等。
Source/Destination Address：源 IP 和目的 IP。

3.2 IP 地址、子网掩码与 CIDR

IP 地址 = 网络号 + 主机号。子网掩码用来划分这两部分。

IP 地址：    192.168.1.100   → 11000000.10101000.00000001.01100100
子网掩码：   255.255.255.0   → 11111111.11111111.11111111.00000000
网络号：     192.168.1.0     → 前 24 位
主机号：     0.0.0.100       → 后 8 位

CIDR 表示法：192.168.1.0/24，斜杠后面的数字表示网络号位数。

判断两台主机是否在同一子网：用各自的 IP 和子网掩码做按位与，得到网络号，网络号相同就在同一子网。

3.3 路由基础

当目的 IP 不在本子网时，主机会把报文发给默认网关（Default Gateway）。路由器根据路由表决定下一跳。

flowchart LR
    A[主机 A<br/>192.168.1.10/24] -->|"目的 IP 不在同一子网"| R[路由器<br/>192.168.1.1]
    R -->|"查路由表"| B[主机 B<br/>10.0.0.5/24]

常用查看命令：

# Linux/macOS
ip route show        # 查看路由表
route -n             # 旧命令

# Windows
route print

避坑技巧：

配置静态 IP 时，最容易漏掉或配错的就是子网掩码和默认网关。只配 IP 不配上两者，通常只能 ping 通同网段。
/24 和 /16 的区别不只是数字大小，它决定了网络规模和可用主机数。/24 有 254 个可用主机地址，/16 有 65534 个。
路由表顺序很重要：更具体的子网（前缀更长）优先于默认路由。

四、ICMP：IP 的「诊断助手」

ICMP（Internet Control Message Protocol）本身不传输用户数据，而是用于传递控制消息和诊断信息。

4.1 Ping 原理

Ping 使用 ICMP Echo Request 和 Echo Reply。

sequenceDiagram
    participant A as 主机 A
    participant B as 主机 B

    A->>B: ICMP Echo Request
    Note over A,B: 携带标识符和序列号
    B->>A: ICMP Echo Reply
    Note over A,B: A 根据往返时间计算延迟

Ping 不通不一定是对端关机，可能是：

防火墙拦截了 ICMP
路由不可达
对端 ARP 表异常
本机默认网关配错

4.2 Traceroute 原理

Traceroute 利用 TTL 递增或端口不可达来追踪路径。

flowchart LR
    A[主机] -->|"TTL=1"| R1[路由器 1]
    R1 -->|"TTL 超时，返回 ICMP Time Exceeded"| A
    A -->|"TTL=2"| R2[路由器 2]
    R2 -->|"TTL 超时，返回 ICMP Time Exceeded"| A
    A -->|"TTL=3"| B[目标主机]
    B -->|"端口不可达 / Echo Reply"| A

避坑技巧：

有些路由器配置了「不回应 ICMP Time Exceeded」，Traceroute 会显示 * * *，不代表网络不通。
防火墙可能会阻断 Traceroute 的 UDP 探测端口，换 -I（ICMP）或 -T（TCP）模式可能成功。

五、UDP：简单、高效、不可靠

UDP（User Datagram Protocol）提供无连接、不可靠、面向数据报的传输服务。

5.1 UDP 头部

 0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|     Source Port    |   Dest Port   |
+--------+--------+--------+--------+
|     Length         |   Checksum    |
+--------+--------+--------+--------+
|          data octets ...            |
+-------------------------------------+

Source Port / Dest Port：各 16 位，标识发送和接收进程。
Length：UDP 头部 + 数据的总长度。
Checksum：可选（IPv4 中），覆盖头部、数据和伪头部。

5.2 UDP 的特点与适用场景

特点	说明
无连接	不需要建立连接，直接发
不可靠	不保证到达、不保证顺序、不重传
低开销	头部只有 8 字节
面向数据报	发一次收一次，保留边界

适合用 UDP 的场景：DNS 查询、视频直播、在线游戏、VoIP、NTP、QUIC 底层。

避坑技巧：

UDP 没有流量控制，发送方太快会导致接收方丢包。实时音视频要做抖动缓冲（jitter buffer）和前向纠错（FEC）。
UDP 报文超过 MTU 会被 IP 层分片，分片丢失会导致整个 UDP 报文作废。大数据包要在应用层分片。
不要认为 UDP 一定比 TCP 快。在丢包率高的网络里，应用层自己实现可靠传输可能比 TCP 更复杂且效果更差。

六、TCP：可靠传输的基石

TCP（Transmission Control Protocol）是互联网最常用的传输协议。它提供面向连接、可靠、按序、字节流的服务。

6.1 TCP 头部核心字段

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段：

Sequence Number（序号）：标识本报文段发送的数据在字节流中的位置。
Acknowledgment Number（确认号）：期望收到的下一个字节的序号。
ACK：确认号有效。
SYN：发起连接。
FIN：结束连接。
RST：重置连接，通常表示异常。
Window（窗口大小）：接收方当前可用缓存大小，用于流量控制。

6.2 三次握手：建立连接

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    C->>S: SYN, seq=x
    Note over C,S: 客户端请求建立连接
    S->>C: SYN, seq=y, ACK=x+1
    Note over C,S: 服务端同意，也请求建立反向连接
    C->>S: ACK=y+1
    Note over C,S: 客户端确认，连接建立

为什么是三次？

两次握手无法确认客户端的接收能力，也不能防止历史重复连接请求造成资源浪费。
三次是「双方都能发送和接收」的最小验证次数。

关键状态：

客户端：SYN_SENT → ESTABLISHED
服务端：LISTEN → SYN_RCVD → ESTABLISHED

6.3 四次挥手：关闭连接

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    C->>S: FIN, seq=u
    Note over C,S: 客户端没有数据要发了
    S->>C: ACK=u+1
    Note over C,S: 服务端确认，但可能还有数据要发
    S->>C: FIN, seq=w
    Note over C,S: 服务端也没有数据要发了
    C->>S: ACK=w+1
    Note over C,S: 客户端确认

为什么一般是四次？

TCP 是全双工的，两个方向要分别关闭。一方发完 FIN 只表示「我这方向没数据了」，另一方可能还有数据要发。

关键状态与时间等待：

主动关闭方最后进入 TIME_WAIT，等待 2MSL（Maximum Segment Lifetime，通常 1-4 分钟）后才彻底关闭。
TIME_WAIT 的作用：
1. 确保最后一个 ACK 被对方收到，如果丢失可以重传。
2. 让网络中延迟的报文自然消失，避免影响下一个使用相同四元组的新连接。

6.4 TCP 状态机

stateDiagram-v2
    [*] --> CLOSED
    CLOSED --> SYN_SENT : 主动打开/send SYN
    CLOSED --> LISTEN : 被动打开
    SYN_SENT --> ESTABLISHED : 收到 SYN+ACK
    LISTEN --> SYN_RCVD : 收到 SYN
    SYN_RCVD --> ESTABLISHED : 收到 ACK
    ESTABLISHED --> FIN_WAIT_1 : 主动关闭/send FIN
    ESTABLISHED --> CLOSE_WAIT : 收到 FIN
    FIN_WAIT_1 --> FIN_WAIT_2 : 收到 ACK
    FIN_WAIT_1 --> TIME_WAIT : 收到 FIN+ACK
    FIN_WAIT_2 --> TIME_WAIT : 收到 FIN
    CLOSE_WAIT --> LAST_ACK : 发送 FIN
    LAST_ACK --> CLOSED : 收到 ACK
    TIME_WAIT --> CLOSED : 2MSL 超时

6.5 可靠传输机制

TCP 通过以下机制保证可靠性：

flowchart LR
    A[序号与确认机制] --> B[超时重传]
    C[滑动窗口] --> D[流量控制]
    E[拥塞窗口] --> F[拥塞控制]
    B --> G[可靠传输]
    D --> G
    F --> G

序号与确认：每发一个字节都有序号，接收方用 ACK 确认连续收到的最大序号。

超时重传：发送方启动定时器，超时未收到 ACK 就重传。

滑动窗口：允许发送方在没收到 ACK 的情况下连续发送多个段，提高吞吐量。

流量控制：接收方通过 Window 字段告诉发送方自己还能接收多少数据，防止接收方缓存溢出。

拥塞控制：发送方根据网络拥塞程度调整发送速率，主要算法包括慢启动、拥塞避免、快重传、快恢复。

6.6 拥塞控制四个阶段

flowchart TB
    A[慢启动<br/>cwnd 指数增长] -->|"cwnd >= ssthresh"| B[拥塞避免<br/>cwnd 线性增长]
    B -->|"收到 3 个重复 ACK"| C[快重传<br/>立即重传]
    C --> D[快恢复<br/>cwnd=ssthresh]
    D --> B
    B -->|"超时"| E[超时重传<br/>cwnd=1]
    E --> A

慢启动（Slow Start）：初始窗口小，每收到一个 ACK 窗口近似翻倍，直到达到慢启动阈值（ssthresh）。
拥塞避免（Congestion Avoidance）：超过阈值后，窗口线性增长。
快重传（Fast Retransmit）：收到 3 个重复 ACK 就立刻重传，不等超时。
快恢复（Fast Recovery）：快重传后不把窗口降到 1，而是降到 ssthresh，再线性增长。

6.7 Nagle 算法与延迟 ACK

Nagle 算法：减少小报文数量。如果上一次发送的数据还没被确认，且当前数据量小于 MSS，就把小数据攒起来一起发。
延迟 ACK：接收方不立即对每个收到的段发 ACK，而是等 40ms 左右，看是否有数据要一起回，减少 ACK 数量。

避坑技巧：

Nagle + 延迟 ACK 会造成明显延迟：发送方等小 ACK，接收方等大数据一起回，形成「写 - 等 - 写 - 等」的 ping-pong 效应。
交互式应用（如游戏、SSH、RPC）通常要关闭 Nagle：setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on))。
批量传输场景（文件下载）可以保留 Nagle，减少小包数量。

七、DNS 与 DHCP：网络配置的基础设施

7.1 DNS：域名 → IP

DNS（Domain Name System）是互联网的「电话簿」，把人类可读的域名解析成 IP 地址。

flowchart LR
    A[客户端] -->|"查询 example.com"| B[本地 DNS 缓存]
    B -->|"未命中"| C[递归 DNS 服务器]
    C -->|"迭代查询"| D[根 DNS 服务器]
    D --> E[.com 顶级域服务器]
    E --> F[example.com 权威服务器]
    F -->|"返回 IP"| C
    C -->|"返回 IP"| A

DNS 记录类型：

类型	用途
A	域名 → IPv4 地址
AAAA	域名 → IPv6 地址
CNAME	域名别名
MX	邮件交换服务器
NS	权威 DNS 服务器
TXT	文本记录，常用于验证和 SPF

避坑技巧：

DNS 有缓存，修改记录后全球生效可能要几分钟到 48 小时（受 TTL 控制）。
注意 DNS 解析失败和连接超时的区别：先 nslookup/dig 确认域名能否解析，再 ping/telnet 确认网络层是否通。
gethostbyname 不是线程安全的，现代程序应使用 getaddrinfo。

7.2 DHCP：自动获取网络配置

DHCP（Dynamic Host Configuration Protocol）让主机自动获取 IP 地址、子网掩码、网关、DNS 服务器。

sequenceDiagram
    participant H as 主机
    participant D as DHCP 服务器

    H->>D: DHCP Discover（广播）
    D->>H: DHCP Offer
    H->>D: DHCP Request
    D->>H: DHCP ACK

八、Unix 网络编程核心：Socket API

Socket 是 Unix 系统提供的网络编程接口，屏蔽了底层协议细节，让程序像读写文件一样通信。

8.1 TCP 服务端典型调用流程

flowchart TB
    A[socket] --> B[bind]
    B --> C[listen]
    C --> D[accept]
    D --> E[read/write]
    E --> F[close]

8.2 TCP 客户端典型调用流程

flowchart TB
    A[socket] --> B[connect]
    B --> C[read/write]
    C --> D[close]

8.3 核心 API 说明

API	作用
`socket()`	创建套接字，指定协议族（IPv4/IPv6）和类型（流式/数据报）
`bind()`	把套接字绑定到本地地址和端口
`listen()`	把套接字置为监听状态，指定全连接队列长度
`accept()`	从全连接队列取出一个已完成握手的连接
`connect()`	客户端发起连接
`read()/write()` 或 `recv()/send()`	收发数据
`close()`	关闭连接
`shutdown()`	半关闭：只关闭读或写

8.4 最简 TCP 服务端示例

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define PORT 8080
#define BACKLOG 128

int main() {
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd < 0) {
        perror("socket");
        exit(1);
    }

    int reuse = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(PORT);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        exit(1);
    }

    if (listen(listen_fd, BACKLOG) < 0) {
        perror("listen");
        exit(1);
    }

    printf("Server listening on port %d\n", PORT);

    while (1) {
        struct sockaddr_in client_addr;
        socklen_t len = sizeof(client_addr);
        int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &len);
        if (conn_fd < 0) {
            perror("accept");
            continue;
        }

        char buf[1024];
        ssize_t n = read(conn_fd, buf, sizeof(buf) - 1);
        if (n > 0) {
            buf[n] = '\0';
            printf("Received: %s\n", buf);
            write(conn_fd, "OK\n", 3);
        }

        close(conn_fd);
    }

    close(listen_fd);
    return 0;
}

8.5 最简 TCP 客户端示例

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define SERVER "127.0.0.1"
#define PORT 8080

int main() {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) {
        perror("socket");
        exit(1);
    }

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(PORT);
    inet_pton(AF_INET, SERVER, &addr.sin_addr);

    if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("connect");
        exit(1);
    }

    write(fd, "hello\n", 6);

    char buf[1024];
    ssize_t n = read(fd, buf, sizeof(buf) - 1);
    if (n > 0) {
        buf[n] = '\0';
        printf("Server reply: %s", buf);
    }

    close(fd);
    return 0;
}

九、Unix 网络编程常见陷阱与避坑技巧

9.1 必须设置 SO_REUSEADDR

int reuse = 1;
setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

原因：服务端主动关闭连接后会进入 TIME_WAIT，该连接的本地端口短时间内不能复用。如果不设置 SO_REUSEADDR，重启服务时可能报 Address already in use。

注意：SO_REUSEADDR 允许复用 TIME_WAIT 的端口，但不会允许两个进程同时绑定到完全相同的 IP:端口（Linux 上 SO_REUSEPORT 才能做到）。

9.2 正确处理 SIGPIPE

向一个已经收到 RST 的 socket 写数据会触发 SIGPIPE 信号，默认行为是终止进程。

signal(SIGPIPE, SIG_IGN);  // 忽略信号

更优雅的做法是在写之前检查连接状态，或者使用 MSG_NOSIGNAL 标志：

send(fd, buf, len, MSG_NOSIGNAL);

9.3 处理部分读写

TCP 是字节流，read 和 write 不保证一次读完或写完。

// 可靠的写：循环写直到写完
ssize_t write_all(int fd, const void *buf, size_t len) {
    const char *p = buf;
    size_t remaining = len;
    while (remaining > 0) {
        ssize_t n = write(fd, p, remaining);
        if (n < 0) {
            if (errno == EINTR) continue;
            return -1;
        }
        p += n;
        remaining -= n;
    }
    return len;
}

9.4 处理 EINTR

慢系统调用（如 accept、read、write）被信号中断后会返回 -1 并设置 errno = EINTR。 robust 的程序应该重试：

while ((n = read(fd, buf, len)) < 0 && errno == EINTR)
    ;

9.5 不要用 strlen 计算二进制数据长度

send(fd, buf, strlen(buf), 0) 只适合文本。二进制数据里可能有 \0，要用实际长度。

9.6 使用 getaddrinfo 替代 gethostbyname

gethostbyname 只支持 IPv4，不是线程安全的，已经被废弃。现代程序应使用 getaddrinfo：

struct addrinfo hints, *res;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;      // 支持 IPv4 和 IPv6
hints.ai_socktype = SOCK_STREAM;

int err = getaddrinfo("example.com", "80", &hints, &res);
if (err != 0) {
    fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(err));
    exit(1);
}

int fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
connect(fd, res->ai_addr, res->ai_addrlen);

freeaddrinfo(res);  // 记得释放

9.7 区分 close 与 shutdown

close(fd)：关闭文件描述符，引用计数减到 0 时释放资源，双向关闭。
shutdown(fd, SHUT_WR)：只关闭写方向，读仍然可以接收数据，常用于通知对端「我发完了」。

9.8 阻塞 vs 非阻塞 IO

模式	特点	适用场景
阻塞	调用没完成就挂起	简单程序、每个连接一个线程/进程
非阻塞	调用立即返回，没数据返回 EAGAIN/EWOULDBLOCK	高并发、IO 多路复用

9.9 IO 多路复用

单线程服务大量连接时，要用 IO 多路复用同时监视多个 fd 的就绪状态。

flowchart LR
    A[主线程] --> B[select/poll/epoll]
    B -->|"哪些 fd 可读/可写"| C[处理可读 fd]
    B --> D[处理可写 fd]

机制	特点
select	有 fd 数量限制（通常 1024），每次调用要遍历全部 fd
poll	用数组描述 fd，没有数量硬限制，但仍需遍历
epoll（Linux）	事件驱动，只关注活跃的 fd，支持边缘触发和水平触发
kqueue（BSD/macOS）	类似 epoll，事件驱动

epoll 水平触发（LT）vs 边缘触发（ET）：

LT：只要 fd 还有数据可读，epoll 就会一直通知。
ET：只有 fd 状态变化时通知一次，需要一次性把数据读完，通常配合非阻塞 IO。

十、典型 Unix 网络障碍问题与排查思路

10.1 排查流程总览

flowchart TD
    A[网络问题] --> B[确认是 DNS/路由/端口/应用哪一层]
    B --> C{能解析域名吗?}
    C -->|否| D[检查 DNS / hosts / 防火墙]
    C -->|是| E{能 ping 通 IP 吗?}
    E -->|否| F[检查路由 / ACL / 安全组]
    E -->|是| G{端口通吗?}
    G -->|否| H[检查服务是否监听 / 防火墙 / 安全组]
    G -->|是| I[检查应用日志 / 抓包 / 连接状态]

10.2 Connection refused

原因：目标 IP 可达，但目标端口没有进程在监听，或者防火墙明确拒绝。

排查：

# 服务端检查是否在监听
ss -tlnp | grep 8080
netstat -tlnp | grep 8080

# 客户端测试端口是否开放
telnet server_ip 8080
nc -vz server_ip 8080

10.3 Connection timed out

原因：报文到达目的地过程中被丢弃，没有收到任何 RST 或响应，常见于防火墙静默丢弃、路由不可达、NAT 映射问题。

排查：

# 看路径到哪里断了
traceroute server_ip
mtr server_ip

# 抓包看 SYN 有没有出去、有没有回来
tcpdump -i any port 8080 -nn

10.4 Too many TIME_WAIT / 端口耗尽

现象：高并发短连接场景下，客户端连接失败，报错 Cannot assign requested address。

原因：大量主动关闭的连接堆积在 TIME_WAIT，占用了本地端口。

解决思路：

尽量使用长连接 / 连接池。
服务端设置 SO_REUSEADDR。
Linux 可调整 net.ipv4.ip_local_port_range 扩大临时端口范围。
开启 net.ipv4.tcp_tw_reuse（谨慎，仅对客户端出站连接有效，不要开 tcp_tw_recycle，已在内核 4.12 后移除）。

10.5 CLOSE_WAIT 堆积

现象：服务端 ss -tan | grep CLOSE_WAIT 看到很多连接。

原因：对端已经发了 FIN，但本端应用没有调用 close()，通常是因为：

应用逻辑忘记关闭 socket。
应用在处理完数据前阻塞在某处，无法执行 close。
异常分支没有释放连接资源。

解决：检查代码里所有异常路径是否都调用了 close，确保每个 accept 出来的 fd 都有对应的关闭点。

10.6 SYN Flood / 半连接队列溢出

现象：服务偶尔出现连接建立慢或大量 SYN_SENT/SYN_RECV。

原理：Linux 内核有两个队列：

半连接队列（syn queue）：存放收到 SYN 但还没完成三次握手的连接。
全连接队列（accept queue）：存放已完成三次握手但还没被 accept 取走的连接。

flowchart LR
    A[客户端 SYN] -->|"进入半连接队列"| B[SYN_RCVD]
    B -->|"收到 ACK"| C[ESTABLISHED]
    C -->|"进入全连接队列"| D[等待 accept]
    D -->|"accept 取走"| E[交给业务处理]

排查：

ss -s          # 查看连接统计
ss -lnt        # 看全连接队列长度和溢出次数
netstat -s | grep overflow

解决：

调大 net.ipv4.tcp_max_syn_backlog。
开启 SYN Cookies：net.ipv4.tcp_syncookies = 1。
增大 listen(fd, backlog) 的 backlog，同时配合 somaxconn 调整。
提升应用 accept 速度。

10.7 高并发下 accept 慢或全连接队列溢出

现象：连接完成三次握手，但客户端一直等待服务端响应。

原因：accept 处理太慢，全连接队列满了，新的完成连接被丢弃。

解决：

用多线程/多进程分担 accept。
使用 IO 多路复用 + 事件驱动架构。
调整 net.core.somaxconn 和 listen() 的 backlog。

10.8 MTU/MSS 导致的大包不通

现象：小数据包能通，大数据包不通；或某些网站/服务能打开，某些打不开。

原因：路径中某段链路 MTU 较小，大包被丢弃，且中间设备不发送 ICMP “Fragmentation Needed”，导致无法自动降包大小。这就是著名的 PMTUD（Path MTU Discovery）黑洞。

解决：

设置 net.ipv4.tcp_mtu_probing = 1 启用 TCP MTU 探测。
在 VPN/隧道两端统一调低 MTU/MSS。
中间网络设备不要丢弃 ICMP “Fragmentation Needed”。

10.9 应用层协议粘包/拆包

现象：TCP 客户端发了两条消息，服务端一次 read 读到了两条消息的内容。

原因：TCP 是字节流，没有消息边界。应用层需要自己定义消息边界。

常见解决方案：

固定长度：每个消息固定 N 字节。
分隔符：如 \n、自定义分隔符。
长度前缀：消息头 4 字节表示消息体长度。

// 长度前缀示例：先读 4 字节长度，再读对应长度的 body
uint32_t len;
read_all(fd, &len, 4);
len = ntohl(len);
read_all(fd, body, len);

十一、学习路线与推荐资源

11.1 学习顺序建议

flowchart LR
    A[网络分层模型] --> B[IP/子网/路由]
    B --> C[ARP/ICMP]
    C --> D[TCP 握手挥手与状态机]
    D --> E[滑动窗口与拥塞控制]
    E --> F[Socket API 编程]
    F --> G[IO 多路复用]
    G --> H[Wireshark 抓包分析]
    H --> I[线上问题排查]

11.2 推荐实践

用 Wireshark 抓一次完整的三次握手和四次挥手，亲眼看看每个字段的值。
写一个 echo 服务器，先用阻塞 IO，再用 select/epoll 改写。
故意制造问题：把客户端改成快速创建大量短连接，观察 TIME_WAIT；把服务端 accept 故意睡几秒，观察全连接队列溢出。
用 ss、tcpdump、traceroute、nc、iperf 这些工具做实验。

11.3 推荐参考书

《TCP/IP 详解卷1：协议》（W. Richard Stevens）——协议细节最权威。
《Unix 网络编程卷1：套接字联网 API》（W. Richard Stevens）——Socket 编程圣经。
《Wireshark 网络分析就这么简单》——抓包实战。
《Linux 高性能服务器编程》（游双）——中文入门友好。

十二、总结

TCP/IP 协议栈并不神秘，它的核心思想就是分层与解耦：

链路层负责「相邻设备怎么传」。
网络层负责「怎么找到对方主机」。
传输层负责「怎么把数据交给正确的进程，并决定可靠还是高效」。
应用层负责「这些数据代表什么业务含义」。

Unix 网络编程的核心是理解 Socket API 的调用顺序、IO 模型、以及 TCP 连接的生命周期。写出稳定的网络程序，不在于记住所有参数，而在于理解：

连接是什么时候建立的，什么时候关闭的。
数据是怎么流动的，会不会被截断、会不会粘包。
异常情况下系统会怎么表现，程序能不能正确处理。

希望这份总结能帮你把《TCP/IP 详解》里的知识点串成一张网，少踩一些网络编程里的经典大坑。