这几年我一直对一个问题感到不太舒服：
为什么我们传一个文件，几乎一定要把数据交给第三方服务器？
打开网易新闻 查看精彩图片
不管是微信、QQ、网盘、临时文件分享网站，哪怕是很多“加密传输工具”，
本质上都还是：
你的文件先到他们服务器，再转给对方。
这在功能上当然很方便，但从工程角度和隐私角度来说，其实一直不太“干净”。
于是我花了比较长时间，做了一个产品：
LocSend
它的核心目标只有一句话：
让文件尽可能只在两台设备之间流动，而不是经过服务器。
LocSend 到底是怎么工作的？
LocSend 基于浏览器原生 WebRTC。
打开网易新闻 查看精彩图片
这意味着：
- 文件数据走的是浏览器底层的点对点加密通道
- 数据不经过我的服务器
- 服务器只做一件事：帮两端交换“信令”以建立连接
你可以把它理解成：
服务器只是“介绍你们认识一下”，
真正聊天和传文件，是你们私下自己聊。
一旦连接建立完成：
- 我这边看不到你在传什么
- 也拿不到你的文件内容
- 甚至连你传了多大的文件，我都不知道
那它是不是“完全离线”？
这是我刻意说得非常实在的一点。
严格意义上讲：
- WebRTC 建立连接时，浏览器需要短暂访问 STUN 服务器
- 用来判断彼此的网络地址、NAT 情况
所以你需要有网络，哪怕只是能访问一个 STUN 地址。
但一旦连接建立完成之后：
- 文件数据本身是点对点直连
- 不经过 LocSend 服务器
- 服务器即使当场宕机，已建立的连接也能继续传
如果双方都在同一局域网、或者都是 IPv6 直连环境，
甚至连 STUN 都不会走。
我为什么要坚持“不走中转服务器”这条路？
说实话，这条路是更难的
因为一旦你不用服务器中转：
- NAT 穿透会变复杂
- 某些极端网络环境会失败
- 调试成本会高很多
- 功能扩展也更慢
但我还是坚持了这个方向，原因很简单：
- 隐私更干净
我不想在技术上“有能力看到你的数据”。 - 结构更诚实
我不需要写一堆“我们不会偷看你文件”的免责声明，
因为从架构上我就看不到。 - 未来更可控
这套东西可以被移植到离线包、本地 HTML、内网环境，
而不是永远依赖云服务。
LocSend 适合什么人用？
如果你是：
- 偶尔需要给同事 / 朋友传大文件
- 不想先传网盘、再发链接
- 不想注册账号、登录、实名认证
- 不想把文件短暂地“寄存在别人服务器上”
那 LocSend 其实挺合适的。
你打开网页 → 对方打开网页 → 自动连上 → 直接传。
不需要安装软件，不需要注册账号。
它现在还不完美吗？
非常不完美（笑）。
目前 LocSend 还在快速迭代中，比如：
- 极端 NAT 环境下可能连接失败
- 移动端体验还在持续优化
- UI 还有明显“工程师审美”
- 还没有做 TURN 中转兜底（这是我刻意克制的）
打开网易新闻 查看精彩图片
但它已经稳定支持：
- GB级别大文件直传
- 浏览器端到端加密
- 30–100 MB/s 的局域网速度
- 自动信令交换、无需手动复制 SDP
我更想把它当成一个“方向正确的工具”
LocSend 不是为了取代所有网盘、IM、传文件工具。
它更像一个很纯粹的补充选项：
当你真的不想让文件经过任何第三方服务器时，
你还有一个能用、而且好用的选择。
如果你对 WebRTC、P2P、隐私工具、
或者“更干净的互联网通信方式”感兴趣，
可以试试它：
有 Bug、体验不好、设计很丑、想法很蠢，
你都可以直接喷我。
我真的会改。
热门跟贴