：跨网络传大文件的最佳选择)
跨网络用 send.wang 传大文件是它最对路的场景——两台设备不在同一 WiFi 下它会通过 STUN/TURN 服务器协助穿透 NAT建立 P2P 直连后文件直接在两端浏览器之间走服务器只做握手不碰数据 。但能用和传得爽之间有几条边界你得先知道下面分两部分说清楚。 跨网络大文件传输的正确姿势第一步发起方创建房间在电脑或手机浏览器打开“https://send.wang”页面自动生成 6 位房间码 二维码 。第二步接收方跨网络加入把房间码告诉对方或者直接把房间链接形如“https://send.wang/?roomxxxxxx”发给对方——这是跨网络场景最省事的方式对方点链接就进同一个房间无需手动输码 。接收方也可以扫二维码加入 。第三步传文件连接状态显示 “Connected” 后发送方点「」选文件接收方点 Download 保存或提前开启自动下载 。 跨网络时send.wang 会通过 STUN/TURN 协助穿透 NAT。大部分家庭宽带、手机 4G/5G 网络都能直连成功只有双方都在严格对称型 NAT 后常见于部分企业网络才会降级到 TURN 中继此时文件会经过中继服务器转发速度和隐私优势会打折扣 。⚠️ 大文件传输的 5 条硬约束WebRTC 底层数据通道本来是为视频通话设计的不是为批量文件传输设计的 所以传大文件时有几条绕不开的限制页面不能关、不能刷新。传输期间发送方和接收方的浏览器标签页都必须保持打开关掉标签传输立刻中断 。浏览器内存是隐形天花板。受限于浏览器内存管理机制单次传输文件大小建议不超过 2GB超过此限制时需实现分片传输和断点续传功能。send.wang 做了分片 断点续传 SHA-256 校验理论上能撑更大文件但几十 GB 级大文件是它的适配上限 。速度取决于两端实际上下行带宽。P2P 直连不受厂商限速但跨网络时受限于双方各自的宽带上行/手机网络上行。一个 10GB 文件在对称千兆宽带下约 80 秒在普通家庭 20Mbps 上行下需要近 70 分钟——而且两台设备整个期间都得开着 。移动端浏览器要谨慎。移动版 Safari/Chrome 对后台标签页和 WebRTC 数据通道会激进节流超过 100MB 的传输可能失败或卡住 。跨网络传大文件优先用桌面端 Chrome/Edge/Firefox。SCTP 拥塞控制会自我克制。WebRTC 数据通道跑在 SCTP over DTLS over UDP 上拥塞时 SCTP 会主动退让导致一条本可跑 500Mbps 的连接实际只能跑到 50-100Mbps 。这是协议级的快不了不是 send.wang 的 bug。 让跨网络大文件传得更稳的实操清单优先用桌面 Chrome 或 Edge确保有足够内存处理大文件分片有线网络优于 WiFi台式机插网线笔记本靠近路由器避免传输中途 WiFi 抖动传之前先测速用“speedtest” 看一下自己的上行带宽据此估算耗时文件超过 20GB 时先压缩分卷用 7-Zip 切成 2-5GB 一份或考虑物理介质邮寄利用断点续传网络闪断不要慌保持页面打开网络恢复或对方重连后会自动续传已传部分自定义好记的房间码如“abc123”方便对方手动输入 什么情况下 send.wang 不是最佳选择如果你的场景命中以下几条任意一条建议换方案场景 更合适的方案对方不能实时在线你想现在发、对方明天收 云存储中转AWS S3 / 阿里云 OSS / Google Drive单文件超过 100GB、且需跨国传输 专用传输软件Aspera FASP、Signiant双方都有公网 IP、需长期定期同步 Resilio Sync、Syncthing、rsyncTB 级数据迁移 物理硬盘邮寄如 AWS Snowball企业级、需审计和权限管理 FileCatalyst、Signiant Media Shuttle⚠️ 一个常被忽略的点WebRTC P2P 工具的零服务器承诺只在直连成功时成立。一旦触发 TURN 中继文件就会经过服务商的基础设施此时隐私模型和普通云盘没有本质区别 。所以传真正敏感的数据时要么确认直连成功要么本地先加密再传。结论send.wang 跨网络传 几 GB 到几十 GB 级的大文件是合适的前提是双方用桌面浏览器、能保持页面长时间打开、不追求跑满带宽。超出这个范围就该考虑上表里的专业方案了。你这边具体要传多大的文件、从哪到哪比如北京传广州、国内传海外告诉我这两个信息我能给你更精确的方案选择和预估耗时。
跨网络用 send.wang 传大文件是它最对路的场景——两台设备不在同一 WiFi 下它会通过 STUN/TURN 服务器协助穿透 NAT建立 P2P 直连后文件直接在两端浏览器之间走服务器只做握手不碰数据 。但能用和传得爽之间有几条边界你得先知道下面分两部分说清楚。 跨网络大文件传输的正确姿势第一步发起方创建房间在电脑或手机浏览器打开“https://send.wang”页面自动生成 6 位房间码 二维码 。第二步接收方跨网络加入把房间码告诉对方或者直接把房间链接形如“https://send.wang/?roomxxxxxx”发给对方——这是跨网络场景最省事的方式对方点链接就进同一个房间无需手动输码 。接收方也可以扫二维码加入 。第三步传文件连接状态显示 “Connected” 后发送方点「」选文件接收方点 Download 保存或提前开启自动下载 。 跨网络时send.wang 会通过 STUN/TURN 协助穿透 NAT。大部分家庭宽带、手机 4G/5G 网络都能直连成功只有双方都在严格对称型 NAT 后常见于部分企业网络才会降级到 TURN 中继此时文件会经过中继服务器转发速度和隐私优势会打折扣 。⚠️ 大文件传输的 5 条硬约束WebRTC 底层数据通道本来是为视频通话设计的不是为批量文件传输设计的 所以传大文件时有几条绕不开的限制页面不能关、不能刷新。传输期间发送方和接收方的浏览器标签页都必须保持打开关掉标签传输立刻中断 。浏览器内存是隐形天花板。受限于浏览器内存管理机制单次传输文件大小建议不超过 2GB超过此限制时需实现分片传输和断点续传功能。send.wang 做了分片 断点续传 SHA-256 校验理论上能撑更大文件但几十 GB 级大文件是它的适配上限 。速度取决于两端实际上下行带宽。P2P 直连不受厂商限速但跨网络时受限于双方各自的宽带上行/手机网络上行。一个 10GB 文件在对称千兆宽带下约 80 秒在普通家庭 20Mbps 上行下需要近 70 分钟——而且两台设备整个期间都得开着 。移动端浏览器要谨慎。移动版 Safari/Chrome 对后台标签页和 WebRTC 数据通道会激进节流超过 100MB 的传输可能失败或卡住 。跨网络传大文件优先用桌面端 Chrome/Edge/Firefox。SCTP 拥塞控制会自我克制。WebRTC 数据通道跑在 SCTP over DTLS over UDP 上拥塞时 SCTP 会主动退让导致一条本可跑 500Mbps 的连接实际只能跑到 50-100Mbps 。这是协议级的快不了不是 send.wang 的 bug。 让跨网络大文件传得更稳的实操清单优先用桌面 Chrome 或 Edge确保有足够内存处理大文件分片有线网络优于 WiFi台式机插网线笔记本靠近路由器避免传输中途 WiFi 抖动传之前先测速用“speedtest” 看一下自己的上行带宽据此估算耗时文件超过 20GB 时先压缩分卷用 7-Zip 切成 2-5GB 一份或考虑物理介质邮寄利用断点续传网络闪断不要慌保持页面打开网络恢复或对方重连后会自动续传已传部分自定义好记的房间码如“abc123”方便对方手动输入 什么情况下 send.wang 不是最佳选择如果你的场景命中以下几条任意一条建议换方案场景 更合适的方案对方不能实时在线你想现在发、对方明天收 云存储中转AWS S3 / 阿里云 OSS / Google Drive单文件超过 100GB、且需跨国传输 专用传输软件Aspera FASP、Signiant双方都有公网 IP、需长期定期同步 Resilio Sync、Syncthing、rsyncTB 级数据迁移 物理硬盘邮寄如 AWS Snowball企业级、需审计和权限管理 FileCatalyst、Signiant Media Shuttle⚠️ 一个常被忽略的点WebRTC P2P 工具的零服务器承诺只在直连成功时成立。一旦触发 TURN 中继文件就会经过服务商的基础设施此时隐私模型和普通云盘没有本质区别 。所以传真正敏感的数据时要么确认直连成功要么本地先加密再传。结论send.wang 跨网络传 几 GB 到几十 GB 级的大文件是合适的前提是双方用桌面浏览器、能保持页面长时间打开、不追求跑满带宽。超出这个范围就该考虑上表里的专业方案了。你这边具体要传多大的文件、从哪到哪比如北京传广州、国内传海外告诉我这两个信息我能给你更精确的方案选择和预估耗时。
