在浏览器里把文件从这台设备直接传到那台设备，靠的是 WebRTC 的数据通道（DataChannel）：文件被切成小块，在两台设备之间点对点流动，不经过任何服务器中转。LanBeam 局域网快传 正是基于这条通道工作的。整个流程可以概括为三步：信令牵线、协商直连路径、在加密通道里分块传输并用背压控制节奏。
第一步：信令——让两台设备互相认识
浏览器并不知道对方设备在哪个网络地址上，需要有人先"介绍认识"，这个环节叫信令。信令服务器就像传话的前台：把你这边的网络候选地址和连接能力描述（专业名词叫 SDP）转交给对方，再把对方的信息带回来给你。
要注意的是，信令服务器只经手这些"名片"信息——设备名、连接参数，在 LanBeam 场景里还包括房间内的文件名清单，文件内容从头到尾不经过它。这也是为什么使用时设备需要能访问互联网：信令要走一次网络，而文件内容随后走的完全是另一条路。
第二步：协商出一条直连路径
双方拿到彼此的候选地址后，会逐一尝试连通、选出最合适的一条，这个过程叫 ICE 协商。候选地址包括设备在局域网里的内网地址、经过路由器映射后的公网地址等。同一个 WiFi 下的两台设备，通常会选中内网那条"近路"，文件因此直接在路由器内部流动，跑的是局域网带宽；只有直连不通时，才会退而选择更绕的路径。
第三步：加密通道、分块传输与背压控制
路径选定后，两台浏览器之间建立起 DataChannel。WebRTC 规范强制要求这条通道必须先完成 DTLS 加密握手，之后流动的所有数据都是密文——这不是可选项，而是协议的底线。
文件在通道里也不是一整块塞过去的，而是被切成一个个小块依次发送：读一块、发一块、收一块、写一块，几个 GB 的文件也不需要先整个装进内存。
最后是节奏问题。两台设备的处理能力往往不对等，如果发送方只顾全速灌数据，接收方消化不过来，数据就会堆积在发送缓冲区里，越积越占内存。所以发送方会随时观察通道里积压的数据量（缓冲区水位）：超过阈值就暂停发送，等水位降下来再继续。这种"你消化完我再喂下一口"的机制叫背压控制，它是网页端能稳定传输大文件的关键之一。