Vpn from WireGuard Impl — 从论文批判到 Go 手写隧道
这篇把两段东西并在一起读:
上半场(理论与动机) 是读 WireGuard 论文(NDSS 2017)整理出来的——VPN 三代演进、论文怎么把 IPsec 当反派批判、为什么 VPN 必须走 UDP、为什么 Go 也能写出一个完整 VPN;
下半场(动手实现) 是顺着这套理论真正写起来的个人项目 mini-vpn-go(用户态 VPN,从零手写、逐 phase 演进,最终对标 WireGuard),目前跑通到 Phase 2 的明文 IP-in-UDP 隧道。
源码:~/Desktop/tun_example/phase2/(仓库名是 tun_example,但 Go module 是 github.com/1WesleyYou/mini-vpn-go)。
一、理论与动机
VPN 史前简介
VPN 这个名字里的 virtual 来自 1990 年代企业的实际诉求, 当时跨地办公要靠租用专线, 业界想用便宜的公网 Internet 模拟出专线效果, virtual 是说虚拟出一根原本要靠物理拉线才有的专网;
接下来 30 年里, VPN 的主流协议大致经过三代:
IPsec ( ...
Tree of Thought: 不再是 left-to-right 单向思维架构
📝 概念别名
thought: 一个"思考单元", 不是单 token, 也不是一整道解, 而是介于两者之间的中间步骤;
state sss: 输入 + 当前已有的 thought 序列 [z1,z2,…,zi][z_1, z_2, \dots, z_i][z1,z2,…,zi];
thought generator G(pθ,s,k)G(p_\theta, s, k)G(pθ,s,k): 在 state sss 下产生 kkk 个候选下一步 thought;
state evaluator V(pθ,S)V(p_\theta, S)V(pθ,S): 给一组 state 打分, 用来指导搜索;
为什么需要 Agent Planning
单纯 CoT 把推理当作"一条链", 一旦中间某一步走错就没机会回头, 也没法在多个候选方案之间挑最好的; 对于需要 explore, lookahead, backtrack 的任务 (数学求解, 写作规划, 字谜填空), 我们需要让 LM 不止一次地, 沿着多条路径思 ...
0. 从 Minimax 到 MCTS - 经典博弈树搜索基础
📝 博弈树搜索黑称
game tree (博弈树): 把所有可能走法画成的有根树, 每个 node 是 state, 每条 edge 是 action
zero-sum game: 一方 gain = 另一方 loss, 两边目标完全对立
Minimax: 假设对手最优时自己能保证拿到的最佳 outcome
Alpha-Beta Pruning: Minimax 的剪枝加速版
MCTS (Monte Carlo Tree Search): 用随机采样 + 统计估计替代完整树搜索
UCT (Upper Confidence bounds for Trees): MCTS 的 Selection 阶段公式
rollout / playout / simulation: 从 leaf 出发 random play 到终局, 拿 1 个 noisy sample
Markov property: 给定当前 state, 未来跟历史无关 — MCTS / minimax 都依赖这个
为什么要写这一篇
读 LATS (Language Agent Tree Sea ...
Unix 电源管理
状态机心智模型
任何 sleep / lock / logout / hibernate 操作, 本质都是在调 4 个开关的不同组合; 判断"这个操作干了什么"只要看这 4 件事:
用户进程还在不在? (Chrome, IDE, SSH 连接是否还活着);
CPU 还在不在执行指令?;
RAM 还通不通电?;
磁盘上有没有内存镜像? (用来还原的);
对照表 (从轻到重)
操作
用户进程
CPU
RAM
磁盘镜像
唤醒/恢复
功耗
典型场景
熄屏 (DPMS)
跑
跑
通电
—
瞬间 (动鼠标)
省 ~10W (只关显示器)
短暂离开几分钟
锁屏 (lock)
跑
跑
通电
—
输密码
同平时
离开座位防别人乱碰
Suspend (S3 / s2idle)
冻结
停
自刷新通电
—
1-3s
电池 1-3%/小时
合盖, 临时离开
Hibernate (S4)
冻结
停
断电
整块写到 swap
10-30s
0
过夜, 长时间不用
Hybrid sleep
冻结
停
通电
同时写盘
RAM 没掉就秒开, 掉了从盘恢复
1-3%/小 ...
ReAct + Reflexion - Reasoning Acting and Verbal Reinforcement Learning
[!联读黑称 / 术语速查]
ReAct 协议:
thought: 模型自言自语写出的 reasoning trace, 不出现在环境里
action: 模型对外发出的工具调用 / 环境指令, 会被执行
observation: 工具或环境返回给模型的下一段输入
trajectory: thought →\rightarrow→ action →\rightarrow→ observation →\rightarrow→ thought →\rightarrow→ … 的整条交替序列
act-only: 没有 thought, 只对外发 action 的 baseline (WebGPT, SayCan 那一派)
CoT-only: 全程在脑子里推, 不调外部工具的 baseline (Wei et al. 2022)
Reflexion 协议:
Actor: 真正生成 action 的 policy LM, 在 Reflexion 实验里基本就是套了一层 ReAct 协议的 GPT
Evaluator: 产生 reward signal 的判官, 可以是 ground-tru ...
Onion - Identifying Incident-indicating Logs for Cloud Systems
📝 术语别名
II-log: Incident-Indicating Log, 真正能告诉你故障在哪的那批 log;
Log clique: 一组高度相似 / 频繁共现的 log template, 是 Onion 聚类的产物;
Anomalous server: incident 时段触发了 alert 或 metric 异常的实例;
Normal server: 同服务下未受影响的同伴实例;
Bilateral: 双边对比, 这里指 anomalous 集 vs normal 集的对比;
前置: 为什么 raw log 不能直接喂给 RCA 系统
云服务一次 incident 的 log 量级通常是百万到亿条, 真正与故障有因果关系的可能只有几十条; 中间夹着大量噪声:
routine heartbeat;
健康探针 (GET /health 200);
周期性 batch / cron 任务的常规 log;
跨实例都有的全局事件 (版本 reload, 集群配置 push);
上下游服务的非关键 warning;
如果直接把全量 log 倒给 ...
RCACopilot - Automatic Root Cause Analysis via Large Language Models for Cloud Incidents
📝 术语别名
RCA: Root Cause Analysis, 根因分析, 找到事故的真正起因;
OCE: On-Call Engineer, 轮值工程师, 收到告警的那个人;
Handler: 一段事先写好的诊断流程, 由 OCE 编写, 系统按 alert 类型匹配执行;
Diagnostic Information: handler 收集到的所有运行时证据 (logs / metrics / traces / configs 等);
CoT: Chain-of-Thought, 让 LLM 先一步步推理再下结论的 prompt 技巧;
In-context Learning / Few-shot: 在 prompt 里给 LLM 几条相似历史例子作为参考;
前置: cloud incident RCA 是个什么问题
云服务一旦出事 (latency 飙高、error rate 飙升、磁盘炸了、配置错了), 监控系统会在毫秒到秒级吐出一条 incident 警报, 然后人接手:
OCE 起夜接到 page;
翻 dashboard, 看 met ...
MemGPT - Towards LLMs as Operating Systems
[!MemGPT 的 OS 类比词典]
main context: LLM 的 context window, 类比物理 RAM
external context: 向量库 / 关系库 / 日志, 类比 disk
function call: 模型主动触发的 I/O, 类比 system call
queue manager: FIFO 驱逐器, 类比 page replacement policy
heartbeat: 定时唤醒, 类比 timer interrupt
Context Window 的硬上限
现有商用 LLM 每次 forward 能看到的 token 数是有限的, 比如 GPT-4 turbo 是 128K, Llama-2-chat 是 4K; 一旦 input + output 超出这个窗口, 后续内容要么被截断, 要么只能靠外部检索 (classic RAG) 在推理前硬塞进去;
这带来两个根本问题:
长对话: session 时间够长后, 早期轮次会被挤出窗口, 模型彻底"忘"掉用户之前说过的事实
长文档分析: 单份文档已经接近 ...
ZeRO - memory optimizations toward training trillion parameter models
📝 并行理论的黑称
Vertical Split: 竖切, PP
Horizontal Split: 横切, TP
消耗显存的模块分类
Part
Category
Included Items
Description
1
Model states
optimizer states, gradients, parameters
For large models, the majority of the memory is occupied by model states.
2
Residual states
activation, temporary buffers, unusable fragmented memory
The remaining memory is consumed by residual states.
Model State 不足分析 + ZeRO-DP 性能
Parallelism Method
Why Compute Efficiency Is High / Low
Why Memory Effi ...
Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve
Prefill vs. Decode
Prefill 阶段做了什么
prefill = 对整个 prompt 做一次完整的 transformer forward。
包括了:
对所有输入 token 一起做 embedding
过每一层的 attention
过每一层的 FFN
同时把每层对应的 K/V 写入 KV cache
最后根据最后位置的 hidden state 过 lm head,得到 next-token logits
采样 / greedy / top-k / top-p,选出第一个输出 token
这个过程由于是有了所有的输入参数的计算,所以其可以在输入启动阶段就做所有启动处理,结果是 compute-bound.
Decode 阶段做了什么
对每一个新的 token (这里来看类似于一个单词的 向量表示), 来计算他们预测的下一个单词输出,这里应该会经过多个阶段,分别是
linear 阶段,也就是从 token X 处理得到 Q, K, V
attention 阶段,也就是通过 QKV, softmax 等计算得到 attention 得分
FFN 阶段,也就 ...
