展开本页目录
开始前准备什么
- 下载本题完整练习包，区分待实现 starter 与作者完成 reference。
- 按README准备本题原生依赖；所有输入均为原创或明确标注的本地fixture。
- 本地练习不需要付费模型Key；真实模型调用未执行，MiniLM题另有明确实际推理说明。
- 打开收发标签页
- 交换本机信令
- 连接DataChannel
- 分块控制背压
- 中途关闭通道
- 校验接收哈希
- 明确网络范围
原创输入、待完成starter、作者reference及实际运行产物，依README本地准备依赖。
环境要求、具体操作、产物核对与未运行范围。
1. 打开收发标签页
使用同源两个浏览器标签页，分别作为发送端和接收端。输入是固定公式生成的512KiB二进制，不读取私人文件，也不上传外部存储。
2. 交换本机信令
本机教学信令通过 BroadcastChannel 交换 SDP 和 ICE。它只适合同源本地标签页；生产中的跨设备信令服务需要另行设计。
本地启动与复现
cd reference
python3 -m http.server 87873. 连接DataChannel
创建 ordered RTCDataChannel，并等待真正的 open 事件再发送。作者环境使用本机 loopback 候选与允许loopback的Chromium参数，避免VPN虚拟网卡影响，不连接公网 STUN/TURN。
4. 分块控制背压
每次发送16KiB，检查 bufferedAmount，超过阈值等待 bufferedamountlow。进度表示已交给通道的字节，不能直接代表接收端完整收到。
5. 中途关闭通道
故意在传输前段关闭通道，接收端记录已收字节和预期长度，并保持 interrupted。只有完整结束标记与哈希核验都满足才允许完成。
6. 校验接收哈希
接收端拼接实际 ArrayBuffer，核对总长524288及SHA256，再通过通道回 ACK。发送端与接收端记录的完整哈希必须相等。
7. 明确网络范围
阅读两端原生运行结果与源码。此练习证明本机DataChannel二进制传输和完整性，不代表已经解决公网NAT、TURN、移动设备断网恢复，也未运行Cursor账号。
怎样确认已经完成
- 真实DataChannel接收524288字节，接收端SHA与发送输入一致。
- bufferedAmount背压生效，完整校验后才发送ACK。
- 中途断开保持interrupted，loopback成功不外推公网NAT穿透。
常见问题
不用把文件上传服务器，两个浏览器能直接传文件吗？
可以通过WebRTC DataChannel传二进制。本题两个本机标签页真实传输，使用本机信令与loopback；公网NAT/STUN/TURN未覆盖。
点对点传完显示100%，怎么确认文件一个字节也没丢？
接收端用实际拼接后的字节计算完整SHA256并比较总长，再发ACK。发送缓冲区100%不能替代接收完整性。
哪些部分实际运行，哪些需要独立验证？
两标签页原生WebRTC DataChannel已传输512KiB并核对接收端完整SHA；关闭通道后半份输入不标完成，仅验证本机loopback。 目标AI助手账号生成、云平台部署和生产环境不在本次执行范围。