Syncthing：原理与配置

开源的点对点（P2P）文件同步工具，无需中央服务器，数据全程加密传输。

---

核心架构

┌─────────────────────┐          ┌─────────────────────┐
│   电脑（Windows）      │          │   手机（Android）     │
│                      │◄────────►│                      │
│  Syncthing 实例 A    │  P2P 加密  │  Syncthing 实例 B    │
│  192.168.1.2         │   直连    │  10.0.0.1（流量）    │
└─────────────────────┘          └─────────────────────┘
         │                              │
         │     ┌──────────────────┐     │
         └────►│  发现服务器（可选）  │◄────┘
               │  帮你找到对方 IP   │
               └──────────────────┘

---

三大核心机制

1. 设备发现（Device Discovery）

• 设备启动时向发现服务器（Discovery Server）注册自己的地址（IP + 端口）
• 对方设备通过发现服务器查询到你的当前地址
• 发现服务器只知道"哪个设备在哪个IP"，不知道你在同步什么文件
• 可关闭：手动填写对方设备 ID + IP 即可绕过发现服务器

2. 点对点传输（P2P Transfer）

• 双方设备直接建立 TLS 加密连接
• 使用 TLS 1.3 加密，密钥只有你的两台设备持有
• 传输内容是文件的差异同步（类似 rsync 算法），不是整个文件重传
• 局域网下走局域网直连，延迟低、速度快

什么是 TLS 加密？

TLS（Transport Layer Security，传输层安全协议）——互联网上数据加密的事实标准，HTTPS 就是 HTTP + TLS。

没有 TLS 的明文传输：

电脑                           手机
 │                              │
 │  "cat /root/flag.txt"       │
 │─────────────────────────────►│  ← 路由器A看到内容了
 │                              │
 │    picoCTF{xxxx}            │
 │◄─────────────────────────────│  ← Wi-Fi 热点也看到了

文件内容在传输路径上的每个路由器、每个运营商节点都是明文可见的。

有了 TLS：

电脑                           手机
 │                              │
 │  握手交换公钥                │
 │─────────────────────────────►│
 │◄─────────────────────────────│
 │                              │
 │  "cat /root/flag.txt"       │
 │  ┌─────────────────────┐    │
 │  │ TLS 加密 → 乱码      │───►│  ← 路由器看到的是乱码
 │  └─────────────────────┘    │
 │                              │
 │    picoCTF{xxxx}            │
 │  ◄───┌─────────────────────┐│
 │      │ TLS 解密 ← 乱码      ││
 │      └─────────────────────┘│

简要流程：

1. 握手阶段
   手机 ──── 你好，我用 TLS 1.3 ────► 电脑
   手机 ◄─── 好的，这是我的证书 ────── 电脑
   手机 ──── 验证证书 ✓，交换密钥 ──► 电脑

2. 加密传输
   手机 ──── 🔒 加密后的文件数据 ────► 电脑
   手机 ◄─── 🔒 加密后的确认 ──────── 电脑

密钥交换的完整过程

很多人会困惑：为什么 TLS 需要两种加密算法？原因很简单——

对称加密快，但不安全。非对称加密安全，但慢。

所以 TLS 的做法是：用非对称加密安全地传递一个"临时密钥"，然后双方用这个临时密钥做对称加密来传输实际数据。

1. 非对称加密阶段（慢，但安全）
   ┌───────────────────────────────────────────┐
   │ 手机 ──── 用电脑的公钥加密临时密钥 ────► 电脑 │
   │ 手机 ◄─── 用手机的公钥加密临时密钥 ──────── 电脑 │
   └───────────────────────────────────────────┘
                        │
                        现在双方都有同一个"临时密钥"了
                        │
                        ▼
2. 对称加密阶段（快，用于实际传输）
   ┌───────────────────────────────────────────┐
   │ 手机 ──── 用临时密钥加密文件数据 ────────► 电脑 │
   │ 手机 ◄─── 用临时密钥加密确认消息 ──────── 电脑 │
   └───────────────────────────────────────────┘

把"非对称"和"对称"说人话

对称加密 —— 一把钥匙开一把锁

        🔑（同一把钥匙）
   ┌──────┐              ┌──────┐
   │ 手机  │──加密/解密──►│ 电脑  │
   └──────┘              └──────┘

• 手机和电脑用同一把钥匙加密和解密
• 速度快（AES-256），适合传大文件
• 问题：如果钥匙在传输过程中被别人截获，加密就废了

非对称加密 —— 一把公锁 + 一把私钥

           🔓 公钥（公开给所有人）           🔑 私钥（只有自己留着）
   ┌──────┐                              ┌──────┐
   │ 手机  │──用电脑的公钥锁住数据──►        │ 电脑  │──用私钥解开
   └──────┘                              └──────┘

• 公钥像一把锁，谁都可以拿来锁上数据
• 私钥像唯一的钥匙，只有持有者能打开
• 就算别人拿到了公钥，也解不开锁住的数据
• 速度慢，不适合传大文件

为什么非对称加密能安全地传递对称密钥？

关键：非对称加密不需要先商量密码，公钥是公开的。

1. 电脑生成一对密钥：公钥（公开） + 私钥（自己藏好）

2. 手机拿到电脑的公钥（从证书里）

3. 手机自己生成一个随机临时密钥 "abc123"

4. 手机用电脑的公钥把 "abc123" 锁住，发给电脑

   手机 ──── 🔒 加密后的 "abc123" ────► 电脑
                │                         │
             别人截获了也看不懂            │
             因为没有电脑的私钥            └── 用私钥解开 → "abc123" ✓

5. 现在双方都知道 "abc123" 了

6. 后续所有文件数据都用 "abc123" + AES-256 加密传输，速度快

所以非对称加密只用来解决一个问题：“怎么安全地告诉对方对称密钥”。一旦双方都有了对称密钥，后面就用对称加密来传实际数据。

证书的作用

那问题又来了：你怎么确定你拿到的"公钥"真的是电脑的，而不是中间人伪造的？

            ┌── 我是电脑，这是我的公钥 ──┐
            │   但实际上我是黑客！      │
   ┌────┐   │                          │   ┌────┐
   │手机│   │◄─────────────────────────│   │黑客│──► 电脑
   └────┘   │                          │   └────┘
            └──────────────────────────┘

证书（Certificate） 就是解决这个问题的——它由可信的第三方机构（CA，如 DigiCert、Let’s Encrypt）数字签名，证明"这个公钥确实属于这台设备"。

• 操作系统/浏览器内置了受信任的 CA 列表
• 手机收到电脑的证书后，验证 CA 签名 → 确认公钥可信 ✅

3. NAT 穿透与中继（Relay）

• 手机在 4G/5G 下处于运营商 NAT 后，没有公网 IP
• Syncthing 会尝试 UPnP / STUN 打洞，建立直连
• 打洞失败时降级到中继模式：

电脑 ──加密──► 公共中继服务器 ──加密──► 手机

• 中继服务器只转发加密数据包，没有解密密钥，看不到内容
• 仅在 P2P 不通时使用，不影响数据安全
• 可关闭：但关闭后两台设备必须在同一局域网下才能同步

什么是 NAT？

NAT（Network Address Translation，网络地址转换）

你的手机连接 4G/5G 时，并没有一个"公网 IP"，而是和其他用户共用运营商的几个公网 IP。NAT 就是运营商路由器干的活——把所有人的内网 IP + 端口映射到同一个公网 IP + 不同端口。

手机 A: 192.168.0.2:54321
手机 B: 192.168.0.3:54321        WiFi/基站
            │                    │
            ▼                    ▼
     ┌───────────────────────────────┐
     │  运营商 NAT 路由器             │
     │  公网 IP: 120.xxx.xxx.50     │
     │  映射表:                      │
     │  192.168.0.2:54321 → 50001   │
     │  192.168.0.3:54321 → 50002   │
     └───────────────────────────────┘

问题： 互联网上的其他设备只知道公网 IP（120.xxx.xxx.50），但这个 IP 背后有几千个用户。它想主动连你的手机时，NAT 路由器不知道应该把连接转发给谁，于是拒绝。

什么是 NAT 穿透？

让 NAT 后面的两台设备互相找到对方并建立直连的技术。Syncthing 用的是 UDP 打洞（UDP Hole Punching）：

为什么必须是 UDP，TCP 不行？

NAT 路由器对待 UDP 和 TCP 的方式完全不同：

UDP 是无状态的：

手机 ──── 发一个 UDP 包去服务器 ────►
NAT 路由器看到这个包，在映射表记一笔：
  "手机 192.168.0.2:54321 → 公网 120.x:50001"

           ── 然后就不管了 ──

过了一会，公网上任何人往 120.x:50001 发 UDP 包
NAT 路由器：哦，这个端口我有映射 → 转发给手机 ✅

• NAT 只是记了个地址映射，不管是谁发回来的
• 只要映射没过期，任何外部主机往这个端口发包都能穿透

TCP 是有状态的：

手机 ──── TCP SYN（请求建立连接）────►
NAT 路由器记下映射，同时标记状态为"SYN_SENT"
           ── 等待 SYN-ACK ──

过了一会，另一台电脑往 120.x:50001 发 TCP SYN
NAT 路由器：等等，我的状态是 SYN_SENT，但你这个包是
一个新的 SYN，不是预期的 SYN-ACK → 丢掉 ❌

• NAT 会维护 TCP 连接状态机（SYN → SYN-ACK → ACK → ESTABLISHED）
• 只有符合当前状态的包才放行
• 外部主动发来的 SYN 会被视为非法包丢弃

关键差异：

	UDP	TCP
NAT 记录	IP:端口映射	映射 + 连接状态
外部主动发包	✅ 只要端口映射存在就转发	❌ 状态不匹配就丢弃
适合打洞	✅	❌

这就是为什么 Syncthing、WebRTC、BT下载都用 UDP 打洞。如果非要用 TCP，需要额外技术（如 TCP 捎带、SOCKS 代理），复杂得多。

Syncthing 具体的打洞流程：

1. 手机和电脑都先连上同一个"中间人"（发现服务器）
   ┌────┐   连上了，IP 是 120.x:50001  ┌──────┐
   │手机│─────────────────────────────►│发现服务器│
   └────┘                              └──────┘
   ┌────┐   连上了，IP 是 8.x:22000   ┌──────┐
   │电脑│─────────────────────────────►│发现服务器│
   └────┘                              └──────┘

2. 发现服务器告诉双方对方的 IP
   手机 ←──── 电脑在 8.x:22000 ──────→ 电脑
   手机 →──── 手机在 120.x:50001 ────→ 电脑

3. 双方同时往对方的 IP:端口 发一个包
   ┌────┐ ──── 去 8.x:22000 ────► ┌────┐
   │手机│                         │电脑│
   └────┘ ◄─── 去 120.x:50001 ──── └────┘

4. NAT 路由器收到"来自电脑的包"，发现映射表里刚好有手机那条记录
   → 放行！直连建立成功 ✅

如果打洞失败（运营商 NAT 过于严格），降级到中继模式——双方都连到一个公共中继服务器，服务器转发加密数据。

---

同步流程

1. 文件变更（新增/修改/删除）
       │
2. 本地索引更新（扫描文件变化）
       │
3. 通知远端设备"我有更新"
       │
4. 远端请求差异摘要
       │
5. 本地发送差异块（分块传输 + SHA256 校验）
       │
6. 远端重组 + 校验 → 写入磁盘

特点

• 双向同步：任一端的修改都会同步到另一端
• 冲突处理：两端同时修改同一文件，保留两个版本（file.冲突-设备名-时间.md）
• 版本管理：可配置保留历史版本，防止误删

---

和中心化方案对比

特性	Syncthing（P2P）	OneDrive / iCloud	自建 NextCloud
是否需要中央服务器	❌ 不需要	✅ 微软/苹果服务器	✅ 自建服务器
数据传输	直连加密	经第三方	经自建服务器
隐私性	最高	低（服务商可访问）	中（自己管）
速度	局域网最快	受云服务限速	受服务器带宽限速
可用性	双方在线才能同步	离线也能上传	服务器在线即可

---

实际体验

• 在家连同一个 Wi-Fi：秒级同步，和本地操作没区别
• 手机用流量：若 NAT 打洞成功 ≈ 1-2秒延迟；若走中继 ≈ 几秒延迟
• 写完 Obsidian 笔记按 Ctrl+S，拿起手机直接看——不需要手动上传或刷新

---

配置过程

环境

设备	系统	安装方式
电脑	Windows	官网下载 zip，解压运行
手机	Android	Google Play / F-Droid 安装 Syncthing-Fork

设备 ID

电脑: ABCDE12-FGHIJK3-LMNOPQ4-RSTUVW5-YZABCD6-EFGHIJ7-KLMNOP8-QRSTUV9
手机: ZYXWV9-UTSRQP8-NMLKJI7-HGFEDC6-BAZYXW5-VUTSRQ4-PONMLK3-JIHGFE2

设备 ID = 设备证书公钥的 SHA-256 指纹，用于身份验证，不能仅用 IP 替代。

配置步骤

电脑端

1. 从 syncthing.net/downloads 下载 Windows 版，解压
2. 双击 syncthing.exe 运行
3. 浏览器打开 http://127.0.0.1:8384 进入 Web UI
4. 点右上角 操作 → 添加远程设备
5. 填入手机的设备 ID，名称填 Phone
6. 共享文件夹勾选需要同步的目录
7. 点 保存

手机端

1. 安装 Syncthing App
2. 点右上角 + → 添加设备
3. 填入电脑的设备 ID，名称填 DESKTOP
4. 点 保存，收到配对请求后点 接受

完整同步流程

发现 → 身份验证 → TLS 加密 → 传输数据

Step 1: 发现
  手机 ──→ 发现服务器："ABCDE12-... 在线吗？"
  发现服务器 ──→ 手机："在的，IP 是 x.x.x.x:22000"

Step 2: 身份验证
  手机 ←── 电脑发来公钥
  手机 SHA-256(公钥) = ABCDE12-... ✅（自己手动输入的，可信）
  手机 ──→ 发起挑战（加密消息）
  电脑 ←── 用私钥解密 → 回复正确 ✅（没有私钥的人过不了这关）

Step 3: TLS 握手
  双方验证通过 → 非对称加密交换对称密钥 → 建立加密通道

Step 4: 传输数据
  电脑 ──→ 手机：TLS 加密后的文件差异数据
  手机解密 → 写入磁盘 → 同步完成

关于网络环境

目前手机使用梯子才能连接到电脑：

• Syncthing 的全球发现服务器和中继服务器被 GFW 封锁
• 手机开梯子后流量先加密出国，绕过封锁，才能发现电脑
• 同步成功后，关闭梯子会导致连接断开

后续优化： 在自建服务器上搭中继服务，国内直连即可同步，无需梯子。

---

参考

• Syncthing 官方文档
• Syncthing GitHub
• RFC 8446 — TLS 1.3
• UDP 打洞原理