浮生 David942 主要是我只有100兆的上传啊，如果不限制人数连上来60个人，很多上传带宽其实是在分享已经上传出来的东西，而不是去给那些下的最多的人分享新的上传，这样下的最快的那一批人一直下不完，我就一直在刷上传数据。
浮生 init0 不是啊，如果50个人都连在我这个100兆的上传上，只有很少的一部分带宽被用来分享最新，还没有分享出来的内容啊，绝大多数带宽都是在分享已经在种子里的内容，缩一下人数实际上所有人下的都快一点啊。
浮生 David942 比如我现在电脑上连了50个人，只有5个下了80%，其他45个连那80%都没下完。如果我把我这100兆的小水管分给这50个人，只有5个人分到的很小的带宽是在下那80%之外的，很大一部分上传带宽都是在分享那80%以内的内容，那实际上不就是把整体的下载速度拖慢了吗？ 还是说我想错了
David942 浮生 我只能说我好像真没碰到过这个问题，因为有盒子的存在下载用户间的相互上传带宽也很高，多数都是同步的，剩下的拉不动只能让他在后续买free再拉；只能说在你想的框架下确实是拖慢了，至于框架能不能形成我不知道😂
xuanqing 浮生 你想的没太大的问题，当然也没你想的那么极端，因为没有同时达到80%进度的通常都是来晚了再加上小水管，所以这部分人分不了太多的带宽。你想极限提高上传量，可以手工操作，分拨次ban几个快盒子的IP以节约带宽，等后面慢的追上来后再放盒子都回来，不过必要性不大就是了，玩到后面能快出种是好事
xuanqing 浮生 从短期看，让盒子最短时间下完才是最有利于传播的，因为盒子有很高的上传带宽和更好的连接性。而想让自己上传最大化，大多数方法都和最利传播的目的不完全重合。真想研究，可以看(๐•ᴗ•๐)的大包还有官种的出种过程以及控速的操作，做一些数据分析就能得到一些结论
