那么问题来了，程序的调度方案是怎样的？

程序该怎么去选择存储地点以及该怎么去下载你的文件？

这个程序很难写，很多厂商都不给普通用户提供接口，全得自己抓包，但抓包出来的接口可用性以及稳定性又十分堪忧。

各大厂商功能实现的也不同，而且还要考虑到可能的限速 /限流问题。

如果你有临时修补方案，请谨慎公开漏洞细节和 POC ，因为某些用户可能无法及时了解到该信息并予以修补。

如果你没有临时修补方案，请永远不要公开漏洞细节和 POC ，厂商不负责任不代表用户需要承担因你而造成的风险。

一旦公开漏洞细节和 POC ，该漏洞的利用门槛将显著降低。

前几楼老哥已经发了相关地址了，建议向上级反馈推动厂商积极性。

感谢你做出的努力。

说真的，个人对 OP 有点疑惑。。

刚注册的新号。

第一贴和第一个回复都是在这个帖子。

帖子内容还是自媒体这种鱼龙混杂的行业。

感谢分享，但是个人认为这种场景下使用服务端渲染意义似乎不算特别大。

1. 生成会比原来多发一次请求，这样本地的用户信息缓存就用不太上了，还是需要等服务端生成后传过来数据，有一定延迟。

2. 不管再怎么高性能高并发，它也仍然需要单独部署占用资源，请求量比较大的时候还是会对整体有影响，不利于优化，能在客户端做的事情还是在客户端做比较好。

感谢，以后再也不发涩图了。

@LeeReamond

它主要面向的人群是非专业客户。

干开发的不都是自己配开发环境跑吗，用得到这个？

运维用这个的话不可控因素太多了，而且部署方式非常局限。

奇怪。。好像刚才发的不可见了？

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你假设的这种情况。

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你所谓的因为得罪 org owner 被 delete 掉仓库的假想情况。

到浏览器开发者工具看下 ws 传输的数据，它会帮助你找到问题。

snapdrop 如果双方设备都支持 webrtc 的话，会走 webrtc datachannel 完成数据传输，这个传输理论上来说应该是完全内网的(除非打洞失败，需要走 turn)，并通过 ws 交换信令等信息。

如果有任何一方不支持 webrtc 的话，就会走服务器中转，用的也是 ws 。

还有一个可能会影响速度的点是，snapdrop 对文件数据做了分块处理，这在某种程度上会影响实际的传输速度。

最后，个人其实不太建议在国内环境用 snapdrop 做内网传输，这个项目设计有一个不好的点，它是以公网 ip 做房间名的，虽然我也没想到有啥别的方法，但是这么搞在某些国内运营商那边确实不好办。