关于我近期做种的一些心得体会

前言

2月份,春节开始,恰逢空中浩劫的ChineseACI字幕组春节没人做种分流,这就自发拿着自己多台空闲的VPS用来做种了(志愿做种),已经2个月过去了,(多台分流节点)做种上传的总量已经不知不觉超过了6TB,特别来讲讲自己的一些心得。

正文

罗马尼亚的分流节点图镇贴

这里只是一些ACI的,还有之前下完一直上传后因为空间不够不得不删掉的,总共加起来3个月里面也传了2TB了。

我其实也拿了一台柬埔寨的100Mbps的服务器、一台HostHatch的瑞典大盘服务器、韩国首尔的Oracle和新加坡的微软Azure服务器都用来当分流节点。由于服务器为了节省CPU和内存(记忆体)性能开支,除非有特定的需求,否则不会装图形化界面的Windows,而会去选择一些Linux发行版(比如AlamaLinux[CentOS8已经可以进入历史垃圾堆了]、Debian、Ubuntu等)

鉴于Linux的系统普遍不能很好的支持BitComet(没有原生的软体,使用Wine模拟的效率太低,而且稳定性不佳),所以选择了可以不带图形化界面的qBittorrent Enhanced Edition(自动屏蔽迅雷及一些离线下载器)

设置好Systemd和账号密码,Web登录端口。看起来似乎一切都搞定了,但是实则不然——qBittorrent默认的一些配置是不合理的,我们需要手动修改它们。

让我们看到这里,对于独占双核Ryzen高性能的服务器来说和服务器本身非常质量过硬的网卡来说,原先默认全局最大的连接数显然设置的过低,过于保守,而每个torrent的上传窗口数上限默认只有4个,这不只是做种者,对于一个正常BT下载的用户来说也太少了,除非上传宽带只有4Mbps,否则建议至少设置为10个及以上,对于有30Mbps及以上的上传宽带的,且CPU较好的,建议设置15个及以上。

因为我是服务器做种,上传宽带和下行宽带对等(1Gbps,也就是千兆宽带),所以我直接设置为25个上传窗口,全局50个上传窗口,保证每个用户都可以获得来自我方的上传。

对于下载连接协议的选择,我是比较犹豫的,因为设置为UDP的话,国内用户被运营商Qos的太厉害,就算连上了速度基本也就没有,所以最后还是设置了仅TCP。

图片

关于加密模式,我个人推荐强制加密,因为很多用户的BT客户端没有开强制加密,而他的运营商对BT协议严格管控,不开的话,就默认不会加密,这就导致连上就会秒断,所以只有我方开了强制加密,对方下载客户端才会选择通过加密模式连接到我这里,从而不会被干扰。

最后,之所以现在很多BT可以下载,都是靠做种者本身连续不断地买服务器自费做种才得以不让种子死种,整个大环境内愿意稍微做一下种的人都不多(大部分都是下完了就跑,进度条100%任务直接暂停),长期挂机做种的更是难得可贵,还有大体量的迅雷用户也就不提了。总而言之,使得做种者甚至都没办法停止维护之前的种子(只能问IDC或机房加硬盘,费用变得愈发昂贵)。

做种时遇到的一些奇葩事情

我曾在磁链/种子文件里面写明不要使用迅雷下载,但是根据我统计,每次依旧有大批人使用迅雷,而被我的qBittorrent Enhanced Ban掉,发现几乎没有速度,直接找到我的直链,还是使用的是迅雷,迅雷默认使用100进程拉我的服务器文件(而且提交任务的同时,迅雷服务器也会一起过来拉,使用的是1000进程,很容易短期搞死性能不好的服务器,和DOS攻击没区别,这样其他正常客户端的用户就下不了了),直接导致又被我的OSS服务器Ban掉,可以说完全抱着侥幸心理就是喜欢用迅雷来下载。

根据我做种服务器的日志文件分析,近40%的人在明知作者禁止使用迅雷的情况下,依旧试图使用迅雷下载,可以见得P2P “人人为我,我为人人”的口号,在目前的大环境下愿意遵守的人依旧不多,我们能做的只有通过技术手段,迫使那些迅雷用户无法得到资源,甚至反吸血,才能防止这些用户搞挂我们的做种服务器,以免造成昂贵的流量费用。

先说这么多,想到再更吧。

5個讚

禁止使用迅雷可能需要带一句什么原因?会不会有些人真搞不明白迅雷的吸血……

看你写了那么多,我也写一点吧
可以试试CentOS9,虽然Linux下我主力还在用centos6,因为2.6内核吞吐量最高,新内核修修补补各种东西导致性能下降严重,不过个人还是建议给服务器DD成 Windows2022,大盘鸡比较推荐hz,甚至购买存储桶只要10欧5T,这不香嘛?不过不抗DMCA就是了,罗马对于版权投诉的资源做种效率更好一些,因为可以无视投诉
顺便吐槽qbee是真的不行,不过Linux下也基本没其他选择了,当然Linux下对于种子服务器更加推 transmission,运行多年不重启都可以稳定工作跑10Gbps吞吐(1.2GB/s)
image
关于UDP这点我之前也提到过,必须禁掉,因为UDP不但跨国传输容易被QOS,也不能用TCP加速功能来提速。
然而迅雷不存在你说的这个被DOS情况,,无非就是下载用户过多,都是真实用户,而不是迅雷服务器,可以通过查询ip的asn字段,判断是dch(服务器线路)还是isp(家庭宽带)就知道了,例如使用这个ip库查询 IP Address Geolocation Lookup Demo | IP2Location
关于迅雷,所以才有了这个帖子教程,让迅雷服务器先吸完在发种,这样迅雷就不会来吸你的BT客户端了,会从迅雷服务器去下载,并且使用迅雷用户的下载速度有了极大的保证。
利用迅雷11离线下载,云盘功能添加磁力种子进行BT网络分流服务器加速上传下载的方法教程
甚至,有服务器的情况下,可以同时利用这个实现CDN提速
web seed 网络种子实现torrent CDN加速,这是我利用阿里云oss制作的一个测试种子,可以试试

关于迅雷的看法,我还是比较喜欢迅雷的,如上方流量数据,种子服务器都是10Gbps长期拉满的,所以很需要这种第三方下载加速服务,因为它可以给资源发布者,带来极大分流效果,甚至迅雷用服务器来承担长期的做种分流(会员加速),所以我作为一个字幕组动画资源发布者,我都会注明,推荐让用户使用迅雷下载,去吸迅雷服务器的速度,去吸迅雷的血

3個讚

wow,写了这么多,感谢回复啦~

CentOS6 内核2.6版本的TCP拥塞控制算法默认应该还是cubic吧?我不知道已经停止维护的锐速能不能用在2.x的内核上(早些年,我只在3.x的CentOS7上以及4.x的Debian8上用过锐速,调教参数比较麻烦,流量有效率比较低,重发包很多都浪费掉了)。其实UDP也是可以加速的,比较知名的还是UDPSpeeder,但是面对Qos完全无效,等于白搭233。

CentOS 9是Stream滚动发行版,我怕像ArchLinux系一样,莫名其妙就把系统滚崩了,那可就惨了(亲身经历,服务器上跑的Manjaro,结果自动滚动更新直接Kernel Panic了,欲哭无泪,差点数据都搞丢了)。

那个拉我1000线程的其实是同一个IP(所以被自动封禁了),那个IP的我去IPIP查过,是江苏盐城的IDC IP,因为迅雷的很多CDN都是类似的IP,而且迅雷不会在自家的IP上面标注自己的rDNS,迅雷的出口IP也都没有见到过迅雷的ASN,所以被我误以为是迅雷的了,现在看起来应该是某个不知名的离线网盘服务器的流氓拉取行为,这个是我错怪迅雷了。

利用迅雷的云盘来分流,这个想法很大胆新颖,受教了。当时迅雷推出这个功能的时候,我有抓包,拿IDM直接拉过迅雷的离线服务器直链,非会员账号服务器这边单线程给到差不多2Mbps(250KB/s),而迅雷客户端还应加上热门种子其他用户的P2P加速,很多时候可以跑满,相比于百度网盘确实是良心多了。下次我试一下,这样等同于迅雷用户在自己的小圈子里面互相加速,其他BT客户端又是另外一个阵营,确实是一个不错的解决办法。关于SDK的话…PikPak的离线不就是这样操作的吗(逃,我们俩应该都在pp的tg群里面

WebTorrent我之前就有试过,我第一次试就是在CometBBS里面发布了Dune(尘埃) 4K,我记得当时你还在下面贴出来参数List来着qwq

Hetzner大盘我其实是有一台的,只是盘没买这么大,考虑到不抗投诉,只能做一些自己压制的种子,想rabtv发布的Disney+之类种子都藏有蜜罐,这种就不敢拿hz来下了。所以我还是更喜欢卢森堡的BuyVM,价格和hz差不大多,都是走的Low End路线,虽然他们2家都是HDD的盘,说实话独占用来做种没太大问题,但是一边下载一边上传就会卡了,直接把上传窗口设置为0吧,这样只下载不上传的吸血,心理上有过不去,感觉还是挺难受的。

我罗马尼亚那台当时是在LowEndTalk论坛上面买的,带了512GB的SSD,所以这台做种就特别舒服了,基本不用考虑机械硬盘I/O有限的烦恼,又可以抗投诉,如果hz也能在罗马尼亚推出类似的套餐就好了。

不过,我最早在服务器上就是用的Transmission哦~ 只是最近不想再折腾了(跑屏蔽迅雷的脚本)才切换到的QBEE,2者在性能上的差距并没有明显的感受到,qbee可以配置的选项更多一些,特别是原生支持通过正则屏蔽一些客户端,这个我还是很喜欢的。

之前我一直担心的是,这些服务器做种到国内电信163的用户速度都不佳,对于冷门资源,没有国内其他用户可以帮忙分流,电信用户下起来速度会变得巨慢,我都想用接入4837/9929/CMI或CN2 GT/GIA的VPS服务器的大盘鸡来做种了,不过这样成本就高了。目前看来最经济的解决办法,就先去迅雷网盘创建一个磁力任务,等libtorrent拉取完成后,等于国内又多了一个可以分流的镜像。

关于TCP加速

我们也都知道,cubic其实在有轻微丢包的情况下,会导致速率大幅度下降。而现在主流的内核对TCP的拥塞都是交给BBR来控制的,但BBR是在4.9以后才正式出现在内核中的,并且在5.2版本有一个质的飞跃,现在一些社区第三方内核组如XanMod还改进了CPU的调度算法,也有对吞吐量的优化,我现在一般都是用XanMod的内核,在性能优化方面还是很靠谱的。

在DropBox的研究报告中也指明了,新版的BBR2算法相比BBR也省了很多CPU资源,毕竟国内电信163用户没BBR或锐速的加持下,拉国外的做种服务器几乎稳定在0-500Kbps,我个人觉得如果有一天电信163的国际网络拥堵情况改善的时候,还是开启BBR2+FQ_Pie会更友好,目前为了用户的下载速度更快一些,用的是BBR+FQ。

如有错误也请继续指正哦,就先酱紫吧

1個讚


感觉你说的是类似这种的,然后你误以为是迅雷了

1個讚

之前我还一味的抗拒迅雷下载,因为迅雷只吸BT,不共享上传。吸迅雷服务器的血,格局打开了

我也想做种加快大家的下载速度,但是没这个技术,有心无力 :joy:

中国大陆绝大多数宽带都是动态IP,IP地址每天都不一样,根本没法做种,跟别提还要搞什么内网穿透,更没多少懂了。用BT软件下载都没速度,上传做种更难,想做种都做不了。

原来是这样,怀疑我peer列表里的某些发达国家IP连上但总没速度就是这个原因