计算机基础 on 方糖猫Blog

编译原理学习总结：新人也能看懂的编译器流水线与避坑指南

Mon, 17 Aug 2020 09:00:00 +0800

编译原理学习总结：新人也能看懂的编译器流水线与避坑指南

参考教材：王生原、董渊、张素琴、吕映芝、蒋维杜《编译原理（第 3 版）》，清华大学出版社。目标读者：刚开编译原理课、被「NFA/DFA/LL(1)/LR」一堆缩写吓到的同学；或者工作中想手写个 DSL、规则引擎、配置解析器，发现需要补编译基础的工程师。

编译原理这门课的劝退点不在「难」，而在概念链条太长：正则表达式→NFA→DFA→最小化，文法→FIRST→FOLLOW→分析表，每一环都建立在前一环上，掉队一步后面全懵。这篇总结帮你做三件事：

建立主干认知：编译器就是一条「翻译流水线」，六个阶段各干一件事；
给出最小可运行的实现：词法分析器、递归下降 Parser、一个 60 行的计算器；
把新人必踩的坑（左递归、二义性、优先级结合性、FIRST/FOLLOW 算错）提前标出来。

一、先建立心智模型：编译器 = 翻译流水线

编译器做的事，和人工翻译一篇文章一模一样：先认单词，再分析句子结构，再理解含义，最后用另一种语言重新表达。对应六个阶段：

flowchart LR
    SRC["源程序<br/>a = b + 2 * c"] --> LEX["词法分析<br/>切成单词"]
    LEX --> SYN["语法分析<br/>搭出句子结构树"]
    SYN --> SEM["语义分析<br/>检查含义是否合理"]
    SEM --> ICG["中间代码生成<br/>三地址码"]
    ICG --> OPT["代码优化"]
    OPT --> CG["目标代码生成<br/>汇编/机器码"]

    SYM(["符号表<br/>记录每个名字是什么"]) -.贯穿.- LEX
    SYM -.贯穿.- SYN
    SYM -.贯穿.- SEM
    ERR(["错误处理<br/>报错并恢复继续"]) -.贯穿.- LEX
    ERR -.贯穿.- SYN
    ERR -.贯穿.- SEM

记三个要点，后面全部内容都挂在这上面：

符号表和错误处理不是独立阶段，而是贯穿全程的两条辅助线。符号表回答「这个名字是什么（类型、作用域、地址）」；错误处理保证发现一个错不崩溃，继续分析把后面的错也找出来。
前三个阶段是「理解原文」（分析/前端），后三个阶段是「重新表达」（综合/后端）。中间代码是分界线——这也是为什么 GCC/LLVM 能「N 种语言 × M 种CPU」：每种语言写个前端，每种 CPU 写个后端，中间用统一的 IR 对接。
每个阶段的输出是下一个阶段的输入，所以学的时候务必搞清每个阶段的「输入是什么、输出是什么」，概念就不容易混。

日常最常见的对照例子：

阶段	干的事	日常类比	典型报错
词法分析	字符流 → Token 流	认出单词	`invalid character`
语法分析	Token 流 → 语法树	分析句子结构	`unexpected token`
语义分析	检查类型、声明	理解句子含义	`undefined variable` / 类型不匹配
中间代码	语法树 → 三地址码	列翻译提纲	—
优化	等价变换让代码更快	润色	—
目标代码	IR → 汇编/机器码	正式成文	—

二、词法分析：把字符流切成单词

2.1 任务与产出

输入 a = b + 2 * c，输出 Token 序列：ID(a) ASSIGN PLUS...。每个 Token 带「种别 + 属性值」。

2.2 理论主线：正则表达式 → NFA → DFA → 最小化

这是教材第 3 章的核心链条，也是新人最容易断掉的地方。一张图记住四个概念的关系：

flowchart LR
    RE["正则表达式<br/>letter(letter|digit)*"] -->|Thompson 构造| NFA["NFA<br/>一个字符可走多条路"]
    NFA -->|子集构造法| DFA["DFA<br/>每个状态+字符<br/>只有唯一去处"]
    DFA -->|状态划分| MINDFA["最小化 DFA<br/>合并等价状态"]

三个构造算法各自一句话记住：

Thompson 构造：把正则的每种运算（连接、|、*）各对应一个固定的 NFA 拼图，像搭积木一样拼出整图。因为允许 ε 边（不读字符就能跳的边），所以拼起来毫无难度——这就是引入 NFA 的原因。
子集构造法：DFA 的每个状态 = NFA 的「一组状态的集合」（从起点出发、经过任意条 ε 边能到达的所有状态，即 ε-闭包）。NFA 的不确定性被「打包进集合」消掉了。
最小化：不断把「行为一样」（对每个字符都跳到同一组）的状态合并。

避坑：ε-闭包是子集构造里最容易漏算的一步——每读一个字符到达新状态后，必须再沿 ε 边补一轮闭包，漏了就会丢边，识别结果出错。

2.3 例：识别标识符与整数的 DFA

stateDiagram-v2
    [*] --> S0
    S0 --> S1 : 字母
    S1 --> S1 : 字母或数字
    S0 --> S2 : 数字
    S2 --> S2 : 数字
    S1 --> [*] : 其他字符，接受 ID
    S2 --> [*] : 其他字符，接受 NUM

2.4 手写实现：实践中没人先画 NFA

工程上写词法分析器，直接用「最长匹配 + 逐个分派」的循环，十几行搞定，理论留在脑子里：

import re

TOKEN_SPEC = [
    ("NUM",   r"\d+"),            # 数字
    ("ID",    r"[A-Za-z_]\w*"),   # 标识符
    ("OP",    r"[+\-*/=]"),       # 运算符
    ("SKIP",  r"[ \t]+"),         # 空白，跳过
    ("BAD",   r"."),              # 兜底：非法字符
]

def tokenize(code):
    pattern = "|".join(f"(?P<{k}>{v})" for k, v in TOKEN_SPEC)
    for m in re.finditer(pattern, code):
        kind, val = m.lastgroup, m.group()
        if kind == "SKIP":
            continue
        if kind == "BAD":
            raise SyntaxError(f"非法字符: {val!r}")   # 词法错误在这里报
        yield (kind, val)

print(list(tokenize("a = b + 2 * c")))
# [('ID','a'), ('OP','='), ('ID','b'), ('OP','+'), ('NUM','2'), ('OP','*'), ('ID','c')]

避坑：正则的排列顺序就是优先级（= 要排在 == 后面之类），以及永远留一个兜底规则报「非法字符」，否则遇到乱字符直接静默跳过，后面语法分析报错位置会莫名其妙。

三、语法分析：把单词流搭成结构树

3.1 上下文无关文法（CFG）与推导

语法规则用 CFG 描述，例如表达式文法：

E → E + T | T
T → T * F | F
F → ( E ) | id | num

2 + 3 * 4 的语法树（注意 * 比 + 离根更远——离根越远越先算，优先级就藏在这里）：

flowchart TD
    E1["E"] --> E2["E"] & PLUS["+"] & T1["T"]
    E2 --> T2["T"] --> F1["F"] --> N2["num 2"]
    T1 --> T3["T"] & MUL["*"] & F2["F"]
    T3 --> F3["F"] --> N3["num 3"]
    F2 --> N4["num 4"]

3.2 两大流派：自顶向下 vs 自底向上

flowchart TB
    subgraph TD["自顶向下（LL 家族）"]
        direction LR
        A1["从根开始<br/>预测该展开哪条规则"] --> A2["代表：递归下降<br/>LL(1) 表驱动"]
        A2 --> A3["优点：好写好懂<br/>缺点：怕左递归/回溯"]
    end
    subgraph BU["自底向上（LR 家族）"]
        direction LR
        B1["从叶子开始<br/>移进-归约"] --> B2["代表：LR(0)/SLR/<br/>LALR(1)/LR(1)"]
        B2 --> B3["优点：能力强<br/>缺点：表难手写<br/>用 Yacc/Bison 生成"]
    end

手写 Parser 用递归下降（每个非终结符一个函数），工具生成用 Yacc/Bison（LALR）。工业界主流语言（GCC 的 C++、Go、Rust 前端）大量采用手写递归下降——错误信息友好、调试容易。
LR 家族记一个不等式：LR(1) ⊃ LALR(1) ⊃ SLR ⊃ LR(0)，能力依次减弱、表依次变小。Yacc 生成的是 LALR(1)——能力和表大小的折中。

3.3 LL(1) 的三道手续：左递归、左公因子、FIRST/FOLLOW

把文法改造成 LL(1) 可用，是教材第 4 章的主线，也是作业/考试重灾区：

坑 1：左递归会让递归下降死循环。 E → E + T 翻译成函数就是「解析 E 先调自己」，无限递归。必须改写成右递归/迭代形式：

E  → T E'
E' → + T E' | ε      （原来是左递归 E → E + T | T）
T  → F T'
T' → * F T' | ε
F  → ( E ) | id | num

坑 2：左公因子导致「选哪条规则」看不准。 S → if E then S | if E then S else S 两条规则开头一样，提取公因子：

S  → if E then S S'
S' → else S | ε

坑 3：FIRST/FOLLOW 算错，分析表全错。 记住用途就不容易错：

FIRST(A)：A 推出的串开头可能是什么终结符——决定「看到某个 token 该选哪条产生式」；
FOLLOW(A)：A 后面可能跟什么终结符——只在「考虑是否选 ε 产生式」时用。

算 FOLLOW 的三条规则（教材原文浓缩）：$ 进 FOLLOW(S)；A → αBβ 则 FIRST(β)−ε 进 FOLLOW(B)；A → αB 或 β 可空时 FOLLOW(A) 进 FOLLOW(B)。最常犯的错就是漏掉第三条，考试拿分点也在这里。

3.4 手写实现：递归下降表达式解析器

改造后的文法直接翻译成人话：每个非终结符一个函数，看到什么 token 走哪条分支：

class Parser:
    def __init__(self, tokens):
        self.tokens = list(tokens)
        self.pos = 0

    def peek(self):
        return self.tokens[self.pos] if self.pos < len(self.tokens) else (None, None)

    def eat(self, kind):
        k, v = self.peek()
        if k != kind:
            raise SyntaxError(f"期望 {kind}，实际 {k}:{v}")  # 语法错误在这里报
        self.pos += 1
        return v

    # E → T E'
    def parse_E(self):
        val = self.parse_T()
        while self.peek() == ("OP", "+"):
            self.eat("OP"); val += self.parse_T()   # E' → + T E'
        return val

    # T → F T'
    def parse_T(self):
        val = self.parse_F()
        while self.peek() == ("OP", "*"):
            self.eat("OP"); val *= self.parse_F()   # T' → * F T'
        return val

    # F → num | ( E )
    def parse_F(self):
        if self.peek()[0] == "NUM":
            return int(self.eat("NUM"))
        self.eat("LP"); val = self.parse_E(); self.eat("RP")
        return val

三个层次各管一件事：E 管加减、T 管乘除、F 管括号与原子——优先级靠「调用层级」天然保证，结合性靠 while 循环方向保证（左结合）。

四、语义分析与中间代码

4.1 语义分析：语法对了，意思对吗

int x = "abc"; 语法完全合法，但语义不通。语义分析干三件事：

查符号表：变量声明过吗？作用域对吗？重复定义了吗？
类型检查：运算两边类型兼容吗？函数调用参数个数/类型对吗？
理论上用**属性文法/语法制导翻译（SDD/SDT）**描述：给语法树节点挂「综合属性」（从下往上传，如类型）和「继承属性」（从上往下传，如声明的类型传给变量表项）。

避坑：语义错误往往是「前面埋雷后面炸」——声明处没检查，使用处才报。写编译器时把检查尽量前移到「信息刚产生的地方」。

4.2 中间代码：三地址码

a = b + 2 * c 翻成三地址码（每条指令至多一个运算符）：

t1 = 2 * c
t2 = b + t1
a  = t2

作用：把前端和后端解耦。LLVM IR、Java 字节码都是这个思想——前端不管什么 CPU，后端不管什么语言。

五、优化与目标代码

5.1 优化：等价变换，不改结果改速度

新人只需记住四类常见优化，看到汇编里的「怪异写法」能认出是哪种：

优化	例子	效果
常量折叠/传播	`2*3` → `6`	编译期算掉
公共子表达式消除	`a+b` 算两次 → 算一次存临时量	少算
死代码消除	删掉结果没人用的语句	代码变小
循环优化	`i*4` → 强度削弱为加法；循环不变量外提	热点提速

避坑：优化的铁律是「语义等价」。浮点运算不满足结合律，(a+b)+c 和 a+(b+c) 结果可能不同——所以激进优化可能改变浮点结果（GCC 的 -ffast-math 就会），数值程序测试对不上时先查这个。

5.2 目标代码：核心是寄存器分配

指令选择、指令调度了解一下即可，真正值得记住的是寄存器分配：寄存器快但数量有限，谁住寄存器谁住内存？经典解法是图着色——变量当顶点、同时活跃的变量连边，寄存器当颜色，给图染色。这个「把分配问题建模成图着色」的思想，比算法细节本身更有迁移价值。

六、动手实战：60 行写一个四则运算计算器

把第二、三章的东西拼起来：词法用正则，语法用递归下降，语义直接求值（跳过中间代码），支持 + - * / ( )：

import re

def tokenize(code):
    spec = [("NUM", r"\d+"), ("OP", r"[+\-*/]"),
            ("LP", r"\("), ("RP", r"\)"), ("SKIP", r"\s+"), ("BAD", r".")]
    pattern = "|".join(f"(?P<{k}>{v})" for k, v in spec)
    for m in re.finditer(pattern, code):
        if m.lastgroup == "SKIP": continue
        if m.lastgroup == "BAD": raise SyntaxError(f"非法字符 {m.group()!r}")
        yield (m.lastgroup, m.group())

def calc(code):
    ts, pos = list(tokenize(code)), [0]          # pos 用列表包一层方便改
    def peek(): return ts[pos[0]] if pos[0] < len(ts) else (None, None)
    def eat(k):
        if peek()[0] != k: raise SyntaxError(f"期望 {k}, 得到 {peek()}")
        pos[0] += 1; return ts[pos[0]-1][1]
    def expr():                                  # expr → term ((+|-) term)*
        v = term()
        while peek() in (("OP","+"), ("OP","-")):
            op = eat("OP"); r = term()
            v = v + r if op == "+" else v - r
        return v
    def term():                                  # term → factor ((*|/) factor)*
        v = factor()
        while peek() in (("OP","*"), ("OP","/")):
            op = eat("OP"); r = factor()
            v = v * r if op == "*" else v / r
        return v
    def factor():                                # factor → NUM | ( expr )
        if peek()[0] == "NUM": return int(eat("NUM"))
        eat("LP"); v = expr(); eat("RP"); return v
    result = expr()
    if pos[0] != len(ts): raise SyntaxError("表达式未结束，多了内容")
    return result

print(calc("2 + 3 * (4 - 1)"))   # 11

写完这个，你就走完了一个迷你编译器的完整前端：字符 → Token → 语法树（隐含在调用栈里）→ 结果。想再进一步，把 expr/term/factor 里的「直接求值」换成「返回 AST 节点」，就有了语法树；遍历 AST 输出三地址码，就有了中间代码层。

七、典型问题速查（新人必踩的坑）

症状	根因	解法
递归下降死循环/栈溢出	文法有左递归 `E → E + T`	改写为右递归形式（`E → T E'`）
同一个输入两种语法树	文法二义性（如 `E → E+E`）	分层文法（E/T/F）或显式声明优先级结合性
if-else 挂错位置（dangling else）	二义性经典案例	规定 else 匹配最近的未配对 then（Yacc 默认移进优先即可）
`1+2*3` 算成 9	优先级没分层	运算符按优先级各分一层非终结符
`8/4/2` 算成 4	结合性错了（写成右结合）	左结合用 `while` 循环收集，右结合（如 `^`、赋值）用递归
LL(1) 分析表一格填了两条	FIRST 集相交，或 ε 规则的 FIRST∩FOLLOW 非空	提左公因子；重算 FIRST/FOLLOW
遇到一个错就整个编译中断	没做错误恢复	恐慌模式：跳过 token 直到同步符号（`;`、`}`）再继续
子集构造结果丢边	读完字符后忘了补 ε-闭包	每步「先 move 再 closure」写成固定套路
优化后浮点结果对不上	浮点不满足结合律，优化重排了运算	关掉激进浮点优化，或接受精度差异

八、学习路线建议

第一周：看懂六阶段流水线图，用正则手写一个词法分析器。
第二周：攻形式语言——正则→NFA→DFA→最小化，动手做一遍子集构造的纸面推导（这步走一遍比看十遍有用）。
第三周：递归下降写表达式 Parser，亲手把左递归文法改写成 LL(1)。
第四周：跑通本文的计算器，然后加变量赋值（需要符号表）——这一步会让你真正理解符号表为什么贯穿始终。
进阶：读 LR 分析表构造（SLR→LALR），用 Yacc/Bison 或 ANTLR 生成一个 Parser 对比手写的差别；再往后可以啃「龙书」的优化章节。

最后说一句教材反复强调的心法：编译器的每个阶段都是「输入一种表示，输出另一种表示」。学不懂某个概念时，先问两个问题——它输入什么、输出什么？答案往往就是理解本身。

参考资料：

王生原、董渊、张素琴、吕映芝、蒋维杜《编译原理（第 3 版）》，清华大学出版社

Aho 等《编译原理》（龙书, Compilers: Principles, Techniques, and Tools）

ANTLR 官方文档（工具生成 Parser 的现代选择）

LLVM 官方文档（中间代码与后端思想的工业界范本）

基于 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 打洞。先跑通，再优化。