资讯动态

深入LocalSend协议v2:从设备发现到HTTPS文件传输的完整链路图解

发布时间:2026/9/3 9:10:29 来源:尧图企业网站定制
深入LocalSend协议v2从设备发现到HTTPS文件传输的完整链路图解【免费下载链接】localsendAn open-source cross-platform alternative to AirDrop项目地址: https://gitcode.com/GitHub_Trending/lo/localsendLocalSend 是一款开源、跨平台的 AirDrop 替代品核心能力是在局域网内快速、安全地传输文件。本文带你深入LocalSend 协议 v2完整图解从UDP 组播设备发现、mTLS 身份认证到HTTPS 文件传输的每一步链路帮助你理解它的设备发现、会话管理与安全机制是如何工作的。一、协议 v2 的三大支柱发现、会话、安全在打开源码之前先建立整体认知。LocalSend 协议 v2当前版本为 v2.2由三块核心能力组成支柱解决的问题实现位置 设备发现同一 Wi-Fi 下的设备如何互相看见multicast/mod.rs 传输会话文件如何被授权、分片传输、取消http/client/v2.rs 安全认证如何防中间人、防伪造设备身份crypto/cert.rs三者全部基于HTTP(S) UDP 组播实现不依赖任何云服务、账号或蓝牙这也是 LocalSend 能同时跑在手机、电脑和网页上的关键。二、设备发现UDP 组播如何找到局域网里的伙伴1. 广播我在这里每台运行 LocalSend 的设备都会向局域网组播组 224.0.0.167的默认端口53317发送 UDP 公告报文内容包含设备别名、协议版本、端口和身份指纹IPv4 组播组224.0.0.167刻意选在224.0.0.0/24段因为部分 Android 设备只能接收该网段的组播IPv6 扩展同时向ff12::...fd3a:e420链路本地组播组发公告见 multicast/mod.rs防丢设计一次公告不够可靠设备会以 100ms → 500ms → 2000ms 的节奏重复发送 3 次见 multicast/mod.rs2. 公告只是打招呼确认靠 HTTP一个精巧的设计是UDP 只发不收。收到公告后接收方不会用 UDP 应答而是主动向对方发起一个POST /api/localsend/v2/register的 HTTP 请求来完成双向握手——这既绕过了 UDP 的不可靠又让双方都能从对方的 TLS 证书里验证真实身份公告中的指纹可能被伪造而 mTLS 证书不行。请求体结构定义在 http/dto_v2.rs核心字段包括alias设备名、version、port、protocolhttp/https和fingerprint身份指纹。三、身份认证mTLS 与自签名证书指纹 ️LocalSend 不信任任何 CA而是采用每台设备一证的方案自签名证书首次启动时生成 RSA-2048 密钥对和自签名证书见 crypto/cert.rs指纹即身份取证书 DER 格式的SHA-256 指纹大写十六进制作为设备唯一标识设备名可以改指纹不会变证书固定Pinning客户端连接时对端证书必须与发现阶段交换的指纹一致任何不匹配的握手都直接失败从根上杜绝中间人攻击这就是为什么 LocalSend 在设备详情里会显示一个类似#188的数字徽章——它就是指纹的可视化。四、文件传输链路四步完成一次安全传输一次完整的 LocalSend 文件传输链路如下发送方 A ──①prepare-upload──▶ 接收方 B 发送方 A ◀──②session_id 文件token── 接收方 B用户点击接受后 发送方 A ──③POST /upload 流式上传──▶ 接收方 B 发送方 A ◀──④200 OK / 422 校验失败重试── 接收方 B对应协议 v2 的四个端点均定义在 http/client/v2.rs步骤端点作用①POST /api/localsend/v2/prepare-upload携带文件元数据文件名、大小、SHA-256发起请求可附 PIN 码②响应session_id 每个文件的token接收方用户决定是否接受可部分接受③POST /api/localsend/v2/upload?sessionIdfileIdtoken凭 token 流式上传文件内容④完成/失败回调校验和不符返回 422 并重试全部结束触发 SessionEnd几个值得注意的细节token 机制每个文件单独发一个 token防止其他设备冒名上传IP 绑定会话锁定发送方 IP只有该地址能续传、能取消⏸️随时可取消POST /api/localsend/v2/cancel由任一端发起即可中止状态机清晰文件状态只有Pending → InProgress → Finished/Failed四种见 server/common/session.rs常见响应码也很直观204无需传输如纯文本、401需要 PIN、403被用户拒绝、409有其他会话占用、422校验和不匹配。五、服务端事件模型为什么接收方能实时弹窗v2 服务端把所有关键动作抽象成事件推给应用层核心定义在 http/server/v2.rs 的ServerEventV2Register有新设备登记TLS 模式下会先校验指纹与证书一致才发出PrepareUpload收到传文件请求应用通过decision_tx通道答复接受/拒绝——这就是界面上那个是否接受文件弹窗FileUpload文件正在落盘应用通过target_tx指定保存位置SessionEnd会话结束释放唯一的会话槽位CancelReceived / PrepareUploadAborted / ListenerFailed覆盖取消、断连、系统回收 socket如 iOS 挂起应用等边缘情况这种服务端只管协议、应用层做决策的分层设计让同一个内核同时支撑 Flutter 客户端、CLI 工具和 Web 下载页。六、Download API让手机变成临时文件服务器 除了推模式v2 还有反向的拉模式Download API接收方调用POST /api/localsend/v2/prepare-download获取文件列表再并行GET /api/localsend/v2/download拉取内容。配套静态页面包括 download.html 和 upload.html意味着浏览器也能直接参与传输——手机发个链接电脑浏览器就能下载无需安装任何软件。七、源码导读从哪些文件入手 如果你准备深入 LocalSend 协议 v2 源码推荐按这个顺序阅读packages/core/src/multicast/mod.rs —— 组播发现与公告重发逻辑packages/core/src/http/dto_v2.rs —— 所有请求/响应数据结构packages/core/src/http/client/v2.rs —— 发送端完整调用链packages/core/src/http/server/v2.rs —— 接收端事件模型packages/core/src/crypto/cert.rs —— 证书生成与指纹计算packages/core/tests/ —— 含 TLS 固定、Web 下载等集成测试是最好的活文档小结 LocalSend 协议 v2 用一条优雅的链路串起了局域网传输的全部难题UDP 组播负责发现、mTLS 证书指纹负责信任、带 token 的 HTTP 会话负责传输全程零云端、零账号、零第三方。理解这套协议后你会发现AirDrop 替代品远不只是模仿——它的安全设计每设备一证 证书固定 IP 绑定 校验重试值得每个做局域网工具的人参考。【免费下载链接】localsendAn open-source cross-platform alternative to AirDrop项目地址: https://gitcode.com/GitHub_Trending/lo/localsend创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价