xqcherry站点

Cloudflare 525 故障复盘：从回源握手失败到 Tunnel

Thu, 24 Sep 2026 00:00:00 GMT

博客接入 Cloudflare 后，访问一度稳定返回 525 SSL handshake failed。最终确认：静态站点、Nginx 和证书都能正常工作，问题出在 Cloudflare 到源站公网 443 的 TLS 协商链路。

现象

原始链路如下：

浏览器 → Cloudflare → 源站公网 443 → Docker/Nginx

Cloudflare 开启“完全（严格）”SSL 后，站点返回 525；但绕过 Cloudflare、使用 SNI 直连源站时，首页可以正常返回 HTTP 200。

curl -k -I --resolve example.com:443:<源站 IP> https://example.com/

这说明问题不在静态站点构建、Nginx 基础配置或端口可达性。

排查结论

服务器抓包表明，Cloudflare 的请求已经到达源站网卡，并转发到 Nginx；Nginx 也正常返回了握手数据。

握手日志中的关键现象是：

Cloudflare ClientHello
→ Nginx ServerHello
→ 对端发送 RST

TLS 1.3 中，ServerHello 发生在证书发送之前。因此这次中断不足以证明是证书、私钥或域名校验的问题。

后续也逐一排除了这些常见原因：

源站安全组或 443 端口未开放；
Nginx 未正确转发；
证书过期、私钥不匹配或域名不匹配；
TLS 1.2 / TLS 1.3 不支持；
服务器时间漂移；
在 Cloudflare “完全”与“完全（严格）”之间切换。

故障边界最终收敛为：Cloudflare 到源站公网 443 的链路，在 TLS 参数协商阶段中断。 这类问题无法仅靠站点代码或常规 Nginx 配置可靠解决。

解决方案：目前还是解决解决不了

目前还是不知道问题出在哪

只能暂时采用别的方案，将公网回源改为 Tunnel：

浏览器 → Cloudflare → Cloudflare Tunnel
→ cloudflared → Docker 内网 → Nginx

cloudflared 与 Nginx 加入同一个 Docker 网络，再在 Cloudflare Zero Trust 中为域名配置 Public Hostname。Tunnel 建立后，由服务器主动向 Cloudflare 发起连接，不再依赖 Cloudflare 访问源站公网 443。

切换完成后，站点恢复 HTTP 200。现阶段保持 Tunnel 作为默认链路。

LCR 110. 所有可能的路径：DFS 回溯枚举 DAG 路径

Wed, 23 Sep 2026 00:00:00 GMT

题目要求列出从节点 0 到节点 n - 1 的全部路径。图是 DAG，因此沿边递归不会遇到环；每次递归只需维护一条当前路径。

class Solution {
public:
    vector<vector<int>> g, res;
    vector<int> path;
    int n ;

    vector<vector<int>> allPathsSourceTarget(vector<vector<int>>& graph) {

        g = graph;
        n = graph.size();

        path.push_back(0);
        dfs(0);

        return res;
    }

    void dfs(int u) {

        if(u == n - 1) {
            res.push_back(path);
            return ;
        }

        for(auto& v : g[u]) {
            path.push_back(v);
            dfs(v);
            path.pop_back();
        }
    }
};

回溯的关键

push_back 代表选择下一节点，递归返回后的 pop_back 代表撤销选择。遗漏撤销会让相邻分支共享错误路径。输出本身可能有指数级大小，因此总时间复杂度至少与答案规模成正比。

141. 环形链表：哈希集合判圈

Wed, 23 Sep 2026 00:00:00 GMT

遍历链表时，把每个访问过的节点地址加入集合。若当前节点已存在于集合中，说明沿 next 指针回到了此前位置，链表存在环。

/**
 * Definition for singly-linked list.
 * struct ListNode {
 *     int val;
 *     ListNode *next;
 *     ListNode(int x) : val(x), next(NULL) {}
 * };
 */
class Solution {
public:
    typedef struct ListNode* PtrtoNode;
    bool hasCycle(ListNode *head) {
        
        set<PtrtoNode> s;

        while(head != NULL) {
            if(s.count(head)) return 1;
            s.insert(head);
            head = head->next;
        }

        return 0;
    }
};

没有环时会遍历到 nullptr；有环时会再次访问某个节点。时间复杂度为 $O(n)$，额外空间为 $O(n)$。

76. 最小覆盖子串：滑动窗口的扩张与收缩

Mon, 21 Sep 2026 00:00:00 GMT

滑动窗口的核心不是枚举所有区间，而是维护一个不变量：窗口何时已经覆盖 t。当前实现用 nd 记录目标字符计数、win 记录窗口计数，并用 check() 判断是否满足覆盖条件；右指针负责扩张，左指针负责删除冗余字符并更新最优答案。

#include<bits/stdc++.h>
using namespace std;

map<char, int> nd, win;
string s, t;
string res;

int check() {
    for(auto& [c, cnt] : nd) {
        if(win[c] < cnt) return 0;
    }
    return 1;
}

int main() {

    cin >> s >> t;

    int m = s.size();
    int n = t.size();

    for(auto& c : t) nd[c] ++;

    int l = 0, r = 0;
    int resl = 0, mlen = 1e9;

    while(r < m) {
        win[s[r]] ++;

        while(check()) {

            if(r - l + 1 < mlen) {
                mlen = r - l + 1;
                resl = l;
            }

            win[s[l]] --;
            l ++;
        }

        r ++;
    }

    if(mlen == 1e9) res = "";
    else res = s.substr(resl, mlen);

    cout << res << "\n";

    return 0;
}

边界

check() 会逐一确认 nd 中所有字符的需求量，因此能正确处理 t 中的重复字符。两个指针都只向右移动；单次检查需要遍历目标字符集合。

785. 判断二分图：DFS 染色与冲突检测

Sun, 20 Sep 2026 00:00:00 GMT

二分图的顶点可以分成两个集合，任意边只连接不同集合。把两个集合抽象为 0 与 1 两种颜色，就得到 DFS/BFS 染色问题。

class Solution {
public:

    vector<int> color;
    vector<vector<int>> graphs;

    bool isBipartite(vector<vector<int>>& graph) {
        int n = graph.size();
        graphs = graph;

        color.assign(n, -1);

        for(int i = 0; i < n; i ++ ) {
            if(color[i] == -1) {
                if(!dfs(i, 0)) return 0;
            }
        }

        return 1;
    }

    int dfs(int u, int c) {
        color[u] = c;

        for(auto& v : graphs[u]) {
            if(color[v] == -1) {
                if(!dfs(v, 1 - c)) return 0;
            }
            else if(color[v] == color[u]) {
                return 0;
            }
        }

        return 1;
    }
};

图可能不连通，不能只从 0 号节点开始。每个未染色节点都应作为一个新连通分量的起点。时间复杂度为 $O(V+E)$，空间复杂度为 $O(V)$。

315. 计算右侧小于当前元素的个数：离散化与树状数组

Sun, 20 Sep 2026 00:00:00 GMT

处理 nums[i] 时，右侧元素已经加入数据结构；问题变成查询“已加入元素中有多少值小于 nums[i]”。值域可能很大或包含负数，所以先离散化为连续排名。

#include<bits/stdc++.h>
using namespace std;

const int N = 1e5 + 10;

int n;
int a[N], tree[N];

int lowbit(int x) {
    return x & -x;
}

void add(int x, int v) {
    while(x <= n) {
        tree[x] += v;
        x += lowbit(x);
    }
}

int query(int x) {
    int res = 0;

    while(x) {
        res += tree[x];
        x -= lowbit(x);
    }

    return res;
}

int main() {

    cin >> n;
    vector<int> alls, res;

    for(int i = 0; i < n; i ++ ) {
        cin >> a[i];
        alls.push_back(a[i]);
    }
        
    sort(alls.begin(), alls.end());
    alls.erase(unique(alls.begin(), alls.end()), alls.end());

    for(int i = n - 1; i >= 0; i -- ) {
        int rk = lower_bound(alls.begin(), alls.end(), a[i]) - alls.begin() + 1;

        res.push_back(query(rk - 1));
        add(rk, 1);
    }

    reverse(res.begin(), res.end());

    for(auto& x : res) cout << x << " ";

    return 0;
}

树状数组的 query(rank - 1) 正好排除与当前值相等的元素，符合“严格小于”的要求。排序离散化与每次查询/更新的总复杂度均为 $O(n\log n)$。

罗马数字转整数：识别特殊减法对

Sun, 20 Sep 2026 00:00:00 GMT

罗马数字通常从左到右累加；IV、IX、XL、XC、CD、CM 是需要整体处理的减法组合。代码用一个单字符映射和一个双字符映射分别处理它们。

class Solution {
public:
    int romanToInt(string s) {
        map<char, int> m = {
            {'I', 1}, {'V', 5}, {'X', 10}, {'L', 50},
            {'C', 100}, {'D', 500}, {'M', 1000}
        };

        map<string, int> n = {
            {"IV", 4}, {"IX", 9},
            {"XL", 40}, {"XC", 90},
            {"CD", 400}, {"CM", 900}
        };

        int res = 0;

        for(int i = 0; i < s.size(); i ++ ) {
            if(i + 1 < s.size()) {
                string t = s.substr(i, 2);
                if(n.count(t)) {
                    res += n[t];
                    i ++;
                    continue;
                }
            }
            res += m[s[i]];
        }

        return res;
    }
};

复杂度

时间复杂度：$O(n)$。
空间复杂度：$O(1)$；符号映射大小固定。

:::note[判断条件] 不必逐一枚举 IV、IX 等减法组合。比较当前字符与下一个字符，就能统一覆盖全部合法减法对。 :::

三数之和：排序加双指针去重

Sun, 20 Sep 2026 00:00:00 GMT

目标是在数组中找到所有和为 0 且不重复的三元组。暴力枚举需要 $O(n^3)$；排序后固定一个数，可将后两数搜索降为线性。

思路

排序后枚举 i。在区间 [i + 1, n - 1] 中维护 left、right：和太小就右移 left，和太大就左移 right，恰好为零时记录答案并跳过重复值。

class Solution {
public:
    vector<vector<int>> threeSum(vector<int>& nums) {
        int n = nums.size();
        vector<vector<int>> res;

        if(n == 3) {
            int x = nums[0] + nums[1] + nums[2];
            if(!x) {
                res.push_back(nums);
                return res;
            }
            else {};
        }

        sort(nums.begin(), nums.end());
        for(int i = 0; i < n - 2; i ++ ) {
            if(i > 0 && nums[i] == nums[i - 1]) continue;
            int x = -nums[i];

            int l = i + 1, r = n - 1;
            while(l < r) {
                int t = nums[l] + nums[r];

                if(t == x) {
                    res.push_back({-x, nums[l], nums[r]});
                    while(l < r && nums[l] == nums[l + 1]) l ++;
                    while(l < r && nums[r] == nums[r - 1]) r --;
                    l ++, r --;
                } 
                else if(t > x) r --;
                else l ++;
            }
        }

        return res;
    }
};

易错点

去重不只发生在 i：找到答案后，左右指针也必须越过相同元素，否则会重复收集同一三元组。时间复杂度为 $O(n^2)$，排序以外只使用常数额外空间。

42. 接雨水：双指针维护两侧最高柱

Sun, 20 Sep 2026 00:00:00 GMT

第 i 个位置能接的雨水由左右最高柱中较低的一侧决定：$\max(0, \min(L_i, R_i) - h_i)$。预处理两组最高值可解题，但会消耗 $O(n)$ 空间。

双指针不变量

使用 left、right 从两端收缩，分别维护 leftMax 和 rightMax。若 leftMax <= rightMax，当前位置左侧的上界已经确定，右侧必然至少有 rightMax，所以可以立即结算 left；反之处理 right。

class Solution {
public:
    int trap(vector<int>& height) {
        int n = height.size();

        int l = 0, r = n - 1;
        int lmax = 0, rmax = 0;

        int res = 0;

        while(l < r) {
            lmax = max(lmax, height[l]);
            rmax = max(rmax, height[r]);

            if(lmax < rmax) {
                res += lmax - height[l];
                l ++;
            }
            else {
                res += rmax - height[r];
                r --;
            }
        }

        return res;
    }
};

时间复杂度为 $O(n)$，额外空间为 $O(1)$。空数组或只有一个柱子时循环不会执行，答案自然为零。

两数之和：哈希表查找补数

Sun, 20 Sep 2026 00:00:00 GMT

题目要求在数组中找到两个不同下标，使其元素之和等于 target。关键是把“寻找另一个数”转换为“查询补数”。

思路

先把每个数值与其下标写入映射；随后遍历数组，查询补数 target - nums[i] 是否存在，且其下标不能与当前下标相同。

:::tip[当前代码的处理方式] 这份实现采用“先建表、后查询”的两次遍历；m[k] != i 用于排除同一个元素被重复使用的情况。 :::

class Solution {
public:
    vector<int> twoSum(vector<int>& nums, int target) {
        int n = nums.size();

        map<int, int> m;
        vector<int> ans;

        for(int i = 0; i < n; i ++ ) m[nums[i]] = i;

        for(int i = 0; i < n; i ++ ) {
            auto x = nums[i];
            int k = target - x;
            if(m.count(k) && m[k] != i) {
                ans.push_back(i);
                ans.push_back(m[k]);
                break;
            }
        }

        return ans;
    }
};

复杂度与边界

时间复杂度：$O(n)$，每次哈希查询均摊为常数时间。
空间复杂度：$O(n)$。
数组存在重复元素时仍然有效；题目保证唯一答案时可直接返回。

1871. 跳跃游戏 VII：用滑动窗口优化可达性 DP

Sat, 19 Sep 2026 00:00:00 GMT

令 dp[i] 表示能否到达位置 i。当 s[i] 为 0 时，若区间 [i - maxJump, i - minJump] 中任意位置可达，则 dp[i] 为真。

暴力 DP

以下是原始的区间枚举版本：

class Solution {
public:
    bool canReach(string s, int minJump, int maxJump) {
        int n = s.size();
        vector<int> f(n, 0);

        f[0] = 1;

        for(int i = 0; i < n; i ++ ) {
            if(!f[i]) continue;

            for(int j = i + minJump; j <= min(n - 1, i + maxJump); j ++ ) {
                if(s[j] == '0') f[j] = 1;
            }
        }

        return f[n - 1];
    }
};

直接检查整个区间需要 $O(n^2)$。观察到该区间随 i 右移，维护窗口内可达位置数 count 即可。

滑动窗口优化

class Solution {
public:
    bool canReach(string s, int minJump, int maxJump) {
        int n = s.size();

        vector<int> f(n, 0);
        f[0] = 1;

        int cnt = 0;
        for(int i = 1; i < n; i ++ ) {

            int r = i - minJump;
            if(r >= 0 && f[r]) cnt ++;

            int l = i - maxJump - 1;
            if(l >= 0 && f[l]) cnt --;

            if(s[i] == '0' && cnt) f[i] = 1;
        }

        return f[n - 1];
    }
};

enter 是新进入可跳区间的位置，leave 是刚离开区间的位置；两者的下标是最容易写错的部分。时间复杂度 $O(n)$，空间复杂度 $O(n)$。

52. N 皇后 II：回溯与方向检查

Fri, 18 Sep 2026 00:00:00 GMT

每一行只能放一个皇后，因此递归的第 row 层只需尝试该行的各列。冲突只可能来自同列、主对角线或副对角线。

状态设计

由于按行递归，当前行之下尚未放置皇后。检查位置 (r, c) 时，只需向上检查同列、左上对角线和右上对角线。

#include<bits/stdc++.h>
using namespace std;

const int N = 10;

int n, res;
int g[N][N];

int check(int r, int c) {

    for(int i = r - 1; i >= 0; i --) {
        if(g[i][c] == 1) return 0;
    }

    for(int i = r - 1, j = c - 1; i >= 0 && j >= 0; i --, j --) {
        if(g[i][j] == 1) return 0;
    }

    for(int i = r - 1, j = c + 1; i >= 0 && j < n; i --, j ++) {
        if(g[i][j] == 1) return 0;
    }

    return 1;
}

void dfs(int r) {

    if(r == n) {
        res ++;
        return ;
    } 

    for(int c = 0; c < n; c ++ ) {
        if(check(r, c)) {
            g[r][c] = 1;
            dfs(r + 1);
            g[r][c] = -1;
        }
    }
}

int main() {

    cin >> n;

    for(int i = 0; i < n; i ++)
        for(int j = 0; j < n; j ++)
            g[i][j] = -1;

    dfs(0);

    cout << res << "\n";

    return res;
}

回溯最重要的是撤销状态；忘记恢复任一数组都会污染下一条搜索分支。搜索树最坏规模为 $O(n!)$，剪枝显著减少实际分支。

DES 与 Feistel 网络：理解经典分组密码的轮函数设计

Fri, 18 Sep 2026 00:00:00 GMT

DES（Data Encryption Standard）是研究分组密码结构的重要案例，但其 56 位有效密钥已无法抵抗现代穷举攻击，因此不应再用于新系统。

参数速览

参数	值
分组长度	64 bit
标称密钥长度	64 bit
有效密钥长度	56 bit（其余为校验位）
网络结构	Feistel 网络
轮数	16
每轮子密钥	48 bit

DES 的处理过程

64 bit 明文
  → 初始置换 IP
  → 分为 L₀、R₀（各 32 bit）
  → 16 轮 Feistel 变换
  → 合并并执行逆初始置换 IP⁻¹
  → 64 bit 密文

第 $i$ 轮可抽象为：

$$L_i=R_{i-1}, \qquad R_i=L_{i-1}\oplus F(R_{i-1}, K_i)$$

轮函数 $F$ 将右半部分与子密钥混合，经扩展、S 盒非线性代换和置换后输出 32 位结果。多轮迭代使局部差异逐步扩散到整个分组。

为什么 Feistel 结构重要

即使轮函数 $F$ 本身不可逆，整个 Feistel 网络仍可逆：解密时按相反顺序使用子密钥即可。这使结构设计更灵活，也影响了后续许多密码算法。

:::caution[安全现状] DES 已废弃；3DES 也正逐步退出。新系统应选择 AES-GCM 或 ChaCha20-Poly1305 等现代认证加密方案。 :::

分组密码：混淆、扩散与 Feistel / SPN 结构

Thu, 17 Sep 2026 00:00:00 GMT

分组密码以固定长度的数据块为单位进行变换，是对称密码的核心构件之一。DES 和 AES 都属于分组密码，但采用了不同的内部结构。

两个设计目标

混淆（Confusion）

混淆让密钥、明文和密文之间的关系尽量复杂，降低攻击者从输入输出推导密钥的能力。典型组件是 S 盒：通过非线性查表引入非线性。

扩散（Diffusion）

扩散让一个明文比特或密钥比特的变化影响更多输出位，形成雪崩效应。置换、线性变换和列混合等操作都服务于扩散。

:::tip[理解方式] 可以把混淆理解为“关系难以预测”，把扩散理解为“影响尽可能传播开”。安全的分组密码需要两者多轮配合。 :::

两类经典结构

结构	核心思路	代表算法
Feistel 网络	分组左右拆分，轮函数只作用于一侧后再交换	DES
SPN（代换—置换网络）	多轮 S 盒代换与线性置换	AES

Feistel 的一个优点是加密和解密可以复用相近的结构，仅需调整子密钥顺序；SPN 则通过多轮非线性代换与扩散层累积安全性。

使用时的边界

分组密码描述的是底层原语，而不是完整安全方案。实际加密还需要安全的工作模式、随机数或 nonce，以及完整性保护。应使用 AES-GCM 等认证加密模式，而不要手动拼接加密流程。

从置换到代换：古典密码的两种基本思路

Thu, 17 Sep 2026 00:00:00 GMT

古典密码的实现各不相同，但可以归结为两种操作：置换改变符号的位置，代换改变符号本身。现代分组密码中的扩散与混淆，也能看到这两种思想的影子。

:::note[阅读目标] 这篇内容用于建立直觉，而非推荐实际使用这些算法。古典密码的密钥空间小、统计特征明显，不能用于现代安全通信。 :::

两条设计路线

方法	改变的对象	典型算法	直观效果
置换	字符的位置	密码棒、栅栏密码	字符没变，顺序被打乱
代换	字符本身	凯撒、维吉尼亚、Playfair	顺序不变，符号被替换

置换：重新排列已有字符

斯巴达密码棒

发送者把纸带缠在固定粗细的圆柱上，沿圆柱逐行写入明文，再沿纸带读出密文。接收者只有使用相同粗细的密码棒，才能恢复正确的排列顺序；因此密码棒的尺寸就是密钥。

栅栏密码

以两行为例，把 HELLOWORLD 按“之”字形写入，再逐行读出：

H   L   O   O   L
  E   L   W   R   D

密文：HLOOLELWRD

栅栏行数（或深度）是密钥。行数有限且字符频率没有被改变，因此它很容易被分析破解。

代换：用另一个符号替换原符号

凯撒密码

把每个字母在字母表中向后移动固定距离；例如偏移 +3 时，HELLO 变为 KHOOR。密钥就是移动位数。

维吉尼亚密码

维吉尼亚密码使用重复的关键字提供多个偏移量。对 HELLOWORLD 使用 KEYKEYKEYK，每个位置分别按对应字母的偏移量移动，可得到 RIJVSUYVJN。

相比凯撒密码，它不再是单表代换；但重复密钥会留下周期性，仍可借助频率分析破解。

Playfair 密码

Playfair 使用密钥构造 5×5 字母方阵（通常合并 I/J），每两个字符作为一组替换，因此属于多字母组代换。它比逐字符代换更难直接做频率分析，但并不具备现代密码学意义上的安全性。

小结

置换负责“打乱位置”，代换负责“隐藏符号”。现代密码通常会多轮组合非线性代换和线性置换，而不是单独依赖其中一种操作。

密码学入门：安全目标、基本模型与攻击能力

Thu, 17 Sep 2026 00:00:00 GMT

密码学关注的不是“把信息变得看不懂”，而是在不可信的环境中提供可验证的安全属性。

四项常见安全目标

目标	要解决的问题	常见技术
机密性	未授权者不能读懂内容	对称加密、公钥加密
完整性	内容没有被修改	哈希、MAC、数字签名
认证性	能确认消息来源	MAC、数字签名、证书
不可否认性	发送者不能事后否认	数字签名

:::important[不要混淆概念] 加密主要解决机密性；哈希本身不提供身份认证；数字签名通常同时服务于完整性、认证和不可否认性。 :::

一个密码系统如何工作

设明文为 $m$、密文为 $c$、加密密钥为 $k_e$、解密密钥为 $k_d$：

$$c = E(k_e, m), \qquad m = D(k_d, c)$$

发送者 Alice 将密文通过不安全信道交给 Bob；窃听者 Eve 可以截获密文，但不应从中恢复明文。现代密码学遵循 Kerckhoffs 原则：安全性应依赖密钥保密，而不是算法保密。

攻击者可能掌握什么

攻击模型按攻击者能力由弱到强排列：

唯密文攻击：只获得密文样本。
已知明文攻击：掌握部分明文及其对应密文。
选择明文攻击：可以选择输入并获取加密结果。
选择密文攻击：可以选择密文并获得解密反馈。

现代密码算法通常以能够抵抗选择明文攻击为基本要求；具体场景还会要求抵抗更强的选择密文攻击。

两类密码体制

体制	密钥关系	优势	典型用途
对称密码	加解密使用同一密钥或可互推密钥	速度快	大量数据加密
非对称密码	公钥与私钥不同	易于分发公钥	密钥交换、签名、身份认证

实际系统通常采用混合方案：先用非对称机制协商会话密钥，再用对称密码加密业务数据。

伪随机生成器与流密码：用短密钥保护长消息

Thu, 17 Sep 2026 00:00:00 GMT

一次一密要求密钥与消息等长，现实系统难以承担这种分发成本。伪随机生成器（PRG）提供了另一条路线：由短种子确定性地产生很长、计算上难以区分于随机数的序列。

PRG 的形式

$$G: {0,1}^{s} \rightarrow {0,1}^{n}, \qquad s \ll n$$

其中 $s$ 是种子长度、$n$ 是输出长度。相同种子必然产生相同输出；它的安全要求不是“真正随机”，而是有效攻击者无法在计算上将输出与真正随机序列区分开。

短种子 → PRG → 长伪随机密钥流

流密码如何加密

流密码将 PRG 生成的密钥流与明文逐位或逐字节异或：

$$c = m \oplus \operatorname{keystream}$$

解密使用同一密钥流再次异或即可恢复明文。它的结构与 OTP 相似，核心差异在于密钥流来自短密钥和算法，而非等长真随机密钥。

维度	一次一密	流密码
密钥材料	真随机、与消息等长	短密钥与 nonce/IV
安全基础	信息论安全	计算安全
可扩展性	很差	很好

:::warning[密钥流不能复用] 同一密钥和 nonce/IV 组合绝不能加密两条消息。复用后会产生与 OTP 密钥复用相同的问题：攻击者可通过两个密文的异或得到两个明文的异或。 :::

实践建议

不要自行组合“PRG + XOR”实现加密。工程中优先使用带认证的成熟方案，例如 ChaCha20-Poly1305 或 AES-GCM，并由可靠库负责 nonce、标签验证与密钥管理。

一次一密与完善保密：理论上最安全的加密方案

Thu, 17 Sep 2026 00:00:00 GMT

一次一密（One-Time Pad，OTP）展示了密码学中一个重要结论：只要密钥满足严格条件，密文可以不泄露任何关于明文的信息。

从异或开始

异或满足 $x \oplus x = 0$，因此：

$$ (m \oplus k) \oplus k = m $$

OTP 使用同一条密钥流进行加密与解密：

加密：c = m ⊕ k
解密：m = c ⊕ k

例如，10110010 ⊕ 01101101 = 11011111；将结果再次与相同密钥异或，即可恢复原文。

达到完善保密的三个条件

密钥必须真正随机。
密钥长度不能短于明文。
每个密钥只能使用一次。

:::caution[重复使用密钥会失效] 若 $c_1=m_1\oplus k$、$c_2=m_2\oplus k$，则 $c_1\oplus c_2=m_1\oplus m_2$。密钥被抵消，两个明文之间的关系暴露给攻击者。 :::

什么是完善保密

Shannon 对完善保密的表达是：

$$P(M \mid C) = P(M)$$

即攻击者观察到密文 $C$ 后，对明文 $M$ 的判断没有获得额外信息。对任意给定的 $m$ 与 $c$，OTP 都存在唯一的 $k=m\oplus c$；只要所有等长密钥等概率出现，任何候选明文都同样可能。

理论与现实的差距

OTP 的问题是密钥分发：加密 100 GB 数据，就需要预先安全地共享 100 GB 真随机且从不复用的密钥。这使它只适合少数具备专用密钥分发能力的场景。

维度	一次一密	现代流密码
密钥来源	等长真随机密钥	短密钥生成伪随机密钥流
安全性质	信息论安全	计算安全
实际可用性	密钥管理成本极高	适合通用系统

OTP 是理解安全上界的好模型；现实中更常见的选择是经过验证的现代流密码或认证加密方案。

区块链入门：数据可信、分布式共识与系统分层

Thu, 10 Sep 2026 00:00:00 GMT

区块链可以理解为一种由多个参与者共同维护的、按时间顺序追加的数据账本。它把数据结构、密码学、点对点网络与共识规则组合在一起，使参与者即使不完全互信，也能对账本状态达成一致。

:::note[先澄清一个常见误解] “不可篡改”不等于数据绝对无法修改。更准确地说，篡改已确认记录需要重写后续链条，并取得网络规则所要求的控制权，因此成本高、容易被发现；具体安全性取决于链的设计与参与者分布。 :::

区块链提供了什么

特性	含义	依赖的机制
共享账本	多个节点保存并验证同一份状态	分布式复制、P2P 网络
可验证历史	记录按顺序关联，便于追溯来源	区块结构、哈希链、Merkle Tree
一致性	节点对有效交易和区块顺序达成一致	共识机制、验证规则
可编程规则	将部分业务逻辑部署为链上代码	智能合约、虚拟机

密码学在其中承担的是身份认证、完整性校验与所有权证明；它并不自动解决所有信任、隐私、性能和治理问题。

四种常见部署形态

形态	参与和写入权限	常见适用场景
公有链	原则上任何人都可参与验证或使用	开放式数字资产、公共应用
私有链	由单一组织控制参与者	企业内部协作与审计
联盟链	多个预先许可的组织共同维护	跨机构供应链、金融协作
混合链	公开与受限数据/权限结合	需要公开验证又需保护业务数据的系统

选择部署形态的关键不是“是否使用区块链”，而是参与方之间的信任关系、性能要求、数据合规性及治理方式。

六层架构

数据层：定义区块、交易、哈希、数字签名与 Merkle Tree 等基础数据结构。
网络层：通过 P2P 网络传播交易、区块和节点发现信息。
共识层：让节点依据统一规则决定哪些记录有效、以何种顺序写入账本；PoW 与 PoS 是两类常见思路。
激励层：通过手续费、区块奖励或质押惩罚等机制，鼓励参与者按协议行为。
合约层：提供智能合约和执行环境，把可验证的业务规则写入链上。
应用层：面向用户提供钱包、资产、供应链溯源、身份和其他具体产品。

可以把这套结构记为：数据层决定“记录什么”，网络层决定“如何传播”，共识层决定“以谁为准”，合约层决定“规则怎样执行”，应用层决定“用户如何使用”。

进一步学习路径

建议按“密码学基础 → 哈希与数字签名 → P2P 网络 → 共识机制 → 智能合约安全”的顺序学习。理解每层的职责与边界，比单独记忆概念更重要。

学习笔记：用 Spec Coding 让 AI 编程更可控

Sat, 22 Aug 2026 00:00:00 GMT

AI 可以很快产出代码，但它无法自动知道需求中的隐含约束。Spec Coding（规格驱动开发）把“先对齐要做什么，再讨论怎么实现”变成显式步骤，从而减少猜测和返工。

从模糊需求到可验证行为

直接把一句需求交给 AI，通常会留下许多未决问题：边界条件是什么、接口如何变化、旧用户是否兼容、失败时如何处理、验收标准又是什么。

以“为登录系统加入二次验证”为例，规格不应止步于功能名称，而应描述可观察行为：

Requirement:
已开启二次验证的用户，必须完成第二因素验证后才能登录。

Scenario:
WHEN 用户提交正确的用户名和密码
AND 该用户已开启二次验证
THEN 系统要求输入一次性验证码
AND 验证通过后才返回登录会话

:::important[Spec 不是愿望清单] 好的规格要写清行为、边界和场景，并能转化为验收测试。它约束的是结果，而非单纯罗列实现方式。 :::

一个可复用的工作流

Intent → Specification → Design / Plan → Implementation → Verification

阶段	要回答的问题	产出
Intent	为什么做、用户要解决什么问题？	目标与范围
Specification	系统应表现成什么样？	需求、场景、验收条件
Design	用什么方案满足规格？	架构与关键取舍
Plan	具体按什么顺序做？	可执行任务
Implementation	如何改动代码？	代码与配置
Verification	如何证明实现正确？	测试、检查与人工验证

这里最容易混淆的是 Plan 和 Spec：Plan 是完成当前改动的临时执行路线；Spec 是系统行为的长期描述。前者回答“怎么做”，后者回答“应该做成什么样”。

规格应该包含什么

一份轻量但有效的 Spec 通常覆盖以下内容：

范围与非目标：本次要做什么，明确不做什么。
用户可观察的行为：正常路径、错误路径和边界条件。
兼容性约束：已有接口、数据和用户流程是否受影响。
验收方式：哪些自动化测试、手工步骤或指标能证明完成。

:::tip[先写最小规格] 不需要为每个小改动写长文档。先列出能消除关键歧义的场景与验收条件；复杂需求再逐步补充分支和设计决策。 :::

工具与方法论的分工

在 AI 编程工作流中，规格管理工具和 Agent 工作流框架常被一起使用，但职责不同：

关注点	规格管理	Agent 工作流
核心问题	系统现在是什么、这次要改变什么？	Agent 应如何分析、实现与验证？
典型产物	当前规格、变更提案、设计、任务	调研、计划、测试、评审、验证流程
价值	保留项目长期上下文	提升一次开发过程的可重复性

例如 OpenSpec 一类工具适合沉淀“当前系统行为”和“待合并变更”；Superpowers 一类工作流适合规范 brainstorm、计划、TDD、评审与验证。它们可以组合，但都不能代替对需求本身的判断。

练习方式

下一次让 AI 修改代码前，先写下三件事：

1. 用户最终能看到什么变化？
2. 哪些旧行为必须保持不变？
3. 用什么证据确认它真的完成了？

这三问足以将多数模糊 Prompt 转化为可执行的规格，也是开始实践 Spec Coding 最小、最有价值的一步。

从域名到应用：Route 53、CloudFront、Nginx 与 Next.js 的部署链路

Tue, 21 Jul 2026 00:00:00 GMT

一个面向公网的 Web 应用通常由“域名注册、DNS 解析、CDN 入口、源站代理与应用进程”几层构成。把职责拆开，排查访问、缓存或证书问题时就能快速定位到正确的一层。

浏览器
  → DNS（Route 53）
  → CDN（CloudFront）
  → 源站域名（origin.example.com）
  → Nginx
  → Next.js 应用

各组件的职责

组件	负责什么	不负责什么
域名注册商	域名归属与续费	不必然提供 DNS 解析
Route 53	DNS 托管与记录解析	不提供应用服务
CloudFront	HTTPS 入口、边缘缓存、回源转发	不替代源站业务逻辑
Nginx	反向代理、请求限制、响应头	不生成 Next.js 页面
Next.js	页面渲染、API 和业务逻辑	不管理 DNS 或 CDN 证书

DNS 与入口配置

常见的记录关系是：

example.com        A/AAAA Alias → CloudFront 分发
www.example.com    A/AAAA Alias → CloudFront 分发
origin.example.com A/AAAA          → 源站公网地址或负载均衡器

主域名和 www 交给 CloudFront，源站使用专门的子域名。这样迁移服务器时只需更新源站记录，不必改动 CDN 分发配置。

:::note[证书位置] 为 CloudFront 自定义域名签发的 ACM 证书必须位于 us-east-1 区域。源站若使用 HTTPS，还需要一张与 origin.example.com 匹配且由 CloudFront 信任的证书。 :::

缓存策略要与请求类型匹配

路径类型	推荐策略
带哈希的 JS/CSS/图片	长缓存，文件名变化即更新
页面 HTML	依据是否 SSR、ISR 或静态导出设置短缓存/不缓存
`/api/*`	通常不缓存，转发必要请求头和查询参数
`/ws/*`	不缓存，并确认 CDN 与源站均允许 WebSocket 升级
`/_next/image*`	结合 Next.js 图片优化和缓存策略配置

不要把“动态接口一律缓存”或“静态资源一律不缓存”作为默认策略；缓存键、TTL、Cookie 与查询参数都要随业务调整。

源站反向代理示意

server {
  listen 443 ssl http2;
  server_name origin.example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

生产环境还应限制源站仅接受 CloudFront 或受信网络的访问、启用访问日志和健康检查，并避免把管理后台直接暴露在未保护的子域名上。

排查顺序

遇到访问故障时，按“DNS 记录 → CloudFront 分发与证书 → 源站可达性 → Nginx 日志 → 应用日志”逐层验证。每层只确认一个事实，可以避免在错误的组件上反复修改配置。

WireGuard 组网实践：用 VPS 建立私有服务器网络

Sun, 28 Jun 2026 00:00:00 GMT

WireGuard 适合将多台分散的服务器连接到一个私有网段。以下示例以公网 VPS 为中心节点，两个内网节点通过加密隧道互通；示例地址请按自己的网络规划替换。

Internet
   │
VPS / WireGuard Server · 10.20.0.1
   ├── Node A · 10.20.0.2
   └── Node B · 10.20.0.3

:::warning[密钥安全] 每个节点必须生成独立密钥对。私钥仅保存在节点本机，不能提交仓库、发送给他人或出现在截图中；配置示例中的占位符不是实际密钥。 :::

1. 安装并生成节点密钥

在每个节点执行：

sudo apt update
sudo apt install -y wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey

记录每个节点的公钥，并安全保存其私钥。VPS 需要开放 UDP 51820（或自定义端口）。

2. 配置中心 VPS

编辑 /etc/wireguard/wg0.conf：

[Interface]
Address = 10.20.0.1/24
ListenPort = 51820
PrivateKey = <VPS_PRIVATE_KEY>

[Peer]
PublicKey = <NODE_A_PUBLIC_KEY>
AllowedIPs = 10.20.0.2/32

[Peer]
PublicKey = <NODE_B_PUBLIC_KEY>
AllowedIPs = 10.20.0.3/32

AllowedIPs 同时用于路由和对端身份约束；服务端应为每个 peer 精确指定单个地址或必要的私有子网，避免使用过宽的范围。

3. 配置客户端节点

以 Node B 为例：

[Interface]
Address = 10.20.0.3/24
PrivateKey = <NODE_B_PRIVATE_KEY>

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
Endpoint = <VPS_PUBLIC_HOST>:51820
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25

PersistentKeepalive = 25 对位于 NAT 后的节点很有帮助，它会周期性维持映射。Node A 按相同方式配置自己的地址和密钥。

4. 启动与验证

sudo systemctl enable --now wg-quick@wg0
sudo wg show
ping 10.20.0.1

当 wg show 出现最近握手时间、收发字节数增长时，说明隧道已建立。随后可从节点间 ping 私网地址，或用 ip route 检查预期路由。

常见故障排查

没有握手：检查 UDP 端口、防火墙、Endpoint 地址和双方公钥是否对应。
能握手但无法访问：检查 AllowedIPs、本机路由及防火墙规则。
需要让一个节点转发到其他子网：在转发节点启用 IP forwarding，并明确增加路由与最小化的防火墙/NAT 规则。

仅需服务器之间私网互访时，不要把 AllowedIPs 配为 0.0.0.0/0；这会把全部流量都导向 VPN，增加意外断网和暴露风险。

Linux 服务器初始化：创建管理员用户并启用 SSH 密钥登录

Wed, 27 May 2026 00:00:00 GMT

新服务器不应长期直接使用 root 账户，也不应把密码作为主要远程登录方式。下面的流程将日常操作切换到拥有 sudo 权限的普通用户，并通过 SSH 密钥认证访问服务器。

:::caution[避免把自己锁在门外] 请保持当前 root 会话不断开，在另一个终端确认新用户可以通过密钥登录并运行 sudo 后，再修改 SSH 的密码登录策略。 :::

1. 创建日常管理员账户

将 <user> 替换为实际用户名：

sudo useradd --create-home --shell /bin/bash <user>
sudo passwd <user>
sudo usermod -aG sudo <user>

在 Debian/Ubuntu 上，可用以下命令验证该用户是否拥有 sudo 权限：

su - <user>
sudo -v

2. 在本地生成 SSH 密钥

如果还没有可用密钥，在本地机器执行：

ssh-keygen -t ed25519 -a 100 -C "your_email@example.com"

私钥应始终只保留在你的受控设备或密钥管理工具中；不要上传、粘贴到聊天记录，也不要提交到仓库。

3. 部署并验证公钥

使用密码仅完成这一次公钥部署：

ssh-copy-id <user>@<server-host>
ssh <user>@<server-host>

无法使用 ssh-copy-id 时，可将本地 ~/.ssh/id_ed25519.pub 的内容追加到服务器用户的 ~/.ssh/authorized_keys，并确保权限正确：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. 验证后收紧 SSH 策略

确认密钥登录正常后，在 /etc/ssh/sshd_config.d/hardening.conf（或发行版对应的 sshd 配置文件）加入：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

检查配置并平滑重载服务：

sudo sshd -t
sudo systemctl reload ssh

:::important[恢复方式] 在关闭密码认证前，确保至少两台受控设备保存了可用私钥，或确认云厂商控制台能够提供带外恢复入口。 :::