技术(?)分享

E站 Hentai@Home 客户端研究笔记

去年6月份偶然发现了E站的一些神奇功能,其中就有一个类 PCDN 项目名为 Hentai@Home,在为广大绅士提供带宽的同时也能当作画廊下载器使用(具体的作用和搭建教程什么的我就不多说了,毕竟网上教程一堆),到现在已经跑了大半年,Windows 客户端和 Linux 客户端都有,这篇文章我想记录下跑 H@H 时发现的东西。

很多坑都没做笔记忘记了,如果想起我再补充。

这篇文章没有记录 H@H 的安装教程,都是些比较进阶但容易遇到的问题,安装教程去谷歌翻翻有一堆。

!重要!由于近期 H@H 的算法出现了显著变化,因此该文章大部分内容已过时

序、我跑 H@H 的大致情况

我从22年7月份开始跑 H@H,到今年年初,H@H 日排名才进入前 10,所以我的笔记的有效日期范围就是22年7月份到现在,不保证以前或者以后都没任何改变,但后续如果有其他问题,我也会在这继续补充。

我目前跑了 12 台 H@H,但归属地基本都在亚洲,所以我 H@H 的笔记也可能仅适用于亚洲,其他区域我无法保证。

在运行 H@H 的时候,我也用 Grafana 做了个监控和告警,有任何异常都能发到 Telegram Bot 及时通知到我方便检查是否有 H@H 客户端出现故障。

一、收益相关问题

1. 亚洲“盛产” H@H 客户端的国家和地区的 Hitrate 收益:

中国大陆 >>>> 日本 >> 台湾 ≈ 香港 ≈ 新加坡

具体来说,如果每台客户端配了个 512G 硬盘,有 2000 个静态块(Static Ranges),那么大致的 Hitrate 区间如下:

  • 中国大陆(限速 50Mbps):800-1000 Hit/min (不限速的话会更高,具体取决你肯给多少)
  • 日本(不限速):330-400 Hit/min
  • 台湾、香港、新加坡(不限速): 120-160 Hit/min

讲个笑话,我新上的 288 个 Ranges 的大陆公有云跑出来的流量比我 2000 个 Ranges 的新加坡机器的流量还要高…这还是在我限速了 10Mbps 的情况下跑出来的,要是把带宽限制解开估计更吓人。

中国大陆:

中国大陆绅士数量多,且多线程下载画廊的第三方 APP 占有量大,由此造成了大陆对 H@H 节点的带宽需求非常大。但由于大陆宽带中带公网 V4 的用户很少,平均上行速度也低,同时还有着各种不可言述的风险,因此导致大陆 H@H 节点所能提供的带宽资源严重不足。

因此,在测速没问题的情况下,大部分时间都是你肯给 H@H 多大上行带宽,H@H 就能吃满多大上行。

最严重的是绝大部分大陆 H@H 节点的带宽都是日常处于满载甚至不健康状态,甚至在高峰期间有一部分流量需要调度到海外 H@H 节点承载。这也是大陆绅士经常反映直连状态下图片加载缓慢、失败率极高的原因。

所以大陆 H@H 的最大瓶颈在于 H@H 的峰值速度,其次才是 H@H 节点的硬盘大小,毕竟大陆连小盘鸡都能在 Hitrate 上秒杀大盘鸡。当然也建议扩大 H@H 硬盘的大小获取更大的静态块收益和更极限的 Hitrate 收益,硬盘大小与带宽的比重建议为 1KB/s 比 500MB。

PS. 为什么在有带宽瓶颈的情况下仍建议扩大 H@H 的硬盘大小,我在后文会说到。

除中国大陆外的其他亚洲地区:

大陆外的亚洲其他地区的收益,最高的是日本,其次是亚洲几个主要地区,东南亚除了新加坡外我没测试过,至于印度和以色列这些奇葩地区我也懒得测了,估计也没几个人会去开这些地区的机器。

在海外,由于家宽和 VPS 上传速度普遍高于 100M,且负载量没有大陆这么夸张,因此带宽瓶颈是基本不存在的(不过日本在静态块足够的情况下有小概率会出现 100M 不能完全吃下高峰期请求的情况),所以就需要一块尽可能大的硬盘来获取足够多的 Hitrate。

2. H@H 要不要考虑用欧洲或者美洲的机器挂?

如果有闲置机器,就算不跑 H@H 也有其他用途的就可以挂。但不推荐为了挂 H@H 而买欧洲和美洲的机器挂 H@H,因为这两个区域的 H@H 客户端已经基本饱和,你将很难分配到静态块,导致 Hitrate 跑了几个月都没怎么动。
如果是为了挂 H@H 而挂 H@H,请尽量选择亚洲机器,推荐用中国大陆的大带宽机器跑,其次是亚洲大盘灵车去跑。

3. 静态块(Static Ranges)的上限取决于哪些因素?

一个 H@H 节点没有任何瓶颈的情况下最大静态块为 6000,注意:我说的是没有任何瓶颈。

那么有瓶颈的情况下呢?在不满足下面情况下,你的静态块的上限取决于你的限制。
硬盘大小:1个静态块需要 250MB 硬盘空间,1465GB 封顶 6000 个。
网速:1个静态块需要 0.5KB/s 的 Max Speed。(这点与 EHWiki 上的描述不符,Wiki 说是 1KB/s = 1静态块,但经我测试,确实是 0.5KB/s = 1静态块)
H@H 节点设置里的每个小时的流量限制(Hourly Bandwidth Limit),1个静态块需要每小时提供 3.6MB 的流量。

1. 我见过有大佬给了 2T 空间的情况下,H@H 把这 2T 都吃满了,但静态块数量仍然是 6000,并且没有额外的 Hitrate 收益,修正成 1.5T 后除了释放出空间外没其他区别,因此不用想投机取巧了,老实限制在 1465GB 吧。

2. Max Speed 指的是在 H@H 主页对应的节点显示的 Max Speed,不是你手动修改的那个 Max Speed,如果需要收集满 6000 个静态块,这个数值要高于 3000KB/s,设定的话需要设置为 3750KB/s 以上。(EHWiki 有说明,最大带宽利用率为设置速度的 80%)

3. 这个问题我是在论坛上找到的,但 EHWiki 也没有详细说明,只是页面底部有个不显眼的链接。

4. 既然大陆 H@H 的最大瓶颈是网速,为什么仍建议扩大硬盘大小?

即使 Max Speed 有上限,但通过 RPC 的调度,能在带宽上限不变的情况下达到更高的 Hitrate 收益。这个有点投机取巧的成分,但实际上不违规,因为 RPC 调度的结果我们无法干预,具体可以看下面的说明。
建议硬盘大小与带宽的比重为 1KB/s 比 500MB,贴着静态块的“网速”上限走。
比如你的 Max Speed 为 2000KB/s,那么硬盘就给到 977GB(4000 静态快)。

为什么要这样建议呢?这个跟 RPC 的调度策略有关。根据我的抓取日志分析,RPC 在正常情况下会保障每一位绅士对单张图片的请求有 400KB/s 以上的速度,这个我称之为健康速度。也就是说,一个健康的节点在最大速度为 3500 KB/s 的情况下,1秒钟处理 8.75 个请求,即 525 Hit/min 是最合适的。

但问题是大陆的情况太不正常了,仔细看看我上面的图,我的大陆 H@H 在 3500KB/s 的情况下达到了 1270.6 Hit/min,平均1秒钟需要处理 21.17 个请求,即单请求速度只有 165KB/s,不到健康速度的 1/2。

然而这也是从 RPC 调度的结果,为什么会出现如此不正常的情况呢?我没有 RPC 端的源码,不知道为什么会变成这样,但推测可能是因为 RPC 在设计之初没有考虑到多线程第三方 APP 的情况,结果被第三方 APP 扰乱了 RPC 的调度机制所导致。

这个情况容易出现在静态块数量足够高且带宽不足的节点中,因此即使带宽瓶颈严重,只要有够多的静态块,对 Hitrate 也是有帮助的。

但代价是什么呢?我也说了,单请求的速度不健康,最直观的反映就是大陆绅士们打开图片容易出现卡顿,以我的大陆 H@H 为例,165KB/s 只是平均速度,我在日志里抓到过至少有 5% 的请求速度是低于 100KB/s 的,可想而知,如果你的请求被分配到这个节点,你也会不爽是吧。

但我们也无法控制,这是 RPC 的调度结果,我们没有进行任何违规操作,有问题我们也无法解决;其次,这个问题的根源可能还是第三方 APP 的不合理请求导致的,我们同样无法干预;另外,第三方 APP 大多数没有点击 reload 的“举报”功能,因此难以对 Trust 和 Quality 造成影响,这也是大陆 H@H 容易保持 10000 Quality 的原因之一。

5. 我想要冲 H@H Toplist 的年奖杯,我该怎么做?

先说一句:如果你没有带宽够大的家庭宽带,就不要为了冲银杯和金杯跑 H@H,自己的钱包才是最重要的。况且最近大陆绅士多了很多,跑杯需要的量级比以往大了不少。

先说下金银铜杯的稳定档线(2023 仅供参考,波动可能比较大):

金杯(前10):16,800,000/年,平均一天 46027 分,Hitrate 要求:3196.3Hit/min

银杯(前25):10,800,000/年,平均一天 29589 分,Hitrate 要求:2054.7Hit/min

铜杯(前50): 4,800,000/年,平均一天 13150 分,Hitrate 要求:913Hit/min

H@H Toplist 的分数是访问量除以100,可以用日分数大致推出来。

然后根据这个分数算就知道到底缺多少了量,以及需要稳定跑多久了,因为不同人具体情况不同,就自行计算吧,但要注意,如果从中途开始追的话,需要另外计算要多久才能达到这个量级。

考虑到 H@H 的静态块增长也需要大量时间,如果冲金杯,建议提前半年做好准备,特别是想用海外机器去追的,建议无脑砸日本机直接起飞(当然你的钱包也会起飞)。

建议还是使用带公网 IP 的大水管大盘大陆机,前期也能快速出量,7天就能达到 180Hit/min,50M 上行带宽两个月轻松破千,后期稳定 1500Hit/min 没问题。

100M 上行 2000Hit/min 随便破,如果后期遇到流量高峰,甚至可以破 3000Hit/min。(前提是你的盘得够大)

PS. 我现在给宽带限速了 30Mbps,5571 个静态块,Hitrate 在 1270Hit/min,而且 Hitrate 实际上还在升,所以预计 50M / 100M 能给出的量会比我上面预估的还要大些。

二、H@H 运作问题

1. 把一个带有大量静态块(Static Ranges)的 H@H 迁移到另一个国家或区域后是否可以完整保留所有的静态块?

可以,静态块可以完整保留,只需要保证新的机器的 cache 数据完整就行。
如果迁移地区后新 IP 的位置识别正确,就不需要联系菠萝,直接放置不管就 OK。如果新 IP 位置识别错误,就先挂着 H@H 保持在线,然后 PM 菠萝改。我 PM 菠萝时我会附上新机器的网络信息,并附上 speedtest 的结果链接。
注意:如果迁移前私聊菠萝改过 H@H 归属地,在迁移后尽快让菠萝修改为新端的归属地或者取消归属地覆盖,如果放置不管可能会被禁止使用 H@H。

2. 如果 Linux 的 H@H 因维护等需求需要临时关闭,请优雅的关闭,不要直接 kill -9。

请使用 kill -15 或 kill -2 或者 Ctrl + C 优雅关闭 H@H,否则下次启动容易触发文件检查,如果用的是 HDD 并且拥有大量静态块,那检查时间都是半个小时起步的了。
网上的停止 H@H 的脚本很多都是写的 kill -9,是个大坑。

3. 亚洲区域的 H@H 请尽可能保证你的 IP 可以被中国大陆访问(即没有被墙)

上文我说过,中国大陆在高峰期间有一部分流量需要调度到海外 H@H 节点承载,因此请尽可能保证你位于亚洲区域的 IP 没有被墙,否则可能会面临 Quality 和 Trust 死活上不去的问题(这对于新的 H@H 客户端来说最为严重)

4. 为什么有时候一台 H@H(特别是大陆 H@H)会被突然限制在一个很低的固定速度并且无法解除

如果你的客户端突然被限制在一个固定的低速,比如你 Maximum Upload Rate 设置了 10000KB/s,speedtest.net 也能达到这个速度,但 H@H 的 Max Speed 被限速到 1243KB/s,且持续几天都没有变动,那大概率是因为你的 H@H 节点被 RPC 二次限速了,请在排查好自身问题(路由器端口转发性能、本机硬盘读速、CPU 负载等)PM 菠萝解除限速(或者等2星期直到 RPC 自动解除限速)

注意:PM 菠萝解除限速前请先解决好本地的瓶颈(推荐把设备接入 Grafana 方便随时查看流量和对应时间段的瓶颈),硬件太烂就换,或者手动在 Maximum Upload Rate 限速后再 PM 菠萝解除限速,否则你大概率会再次被 RPC 二次限速。

PM 示例

5. 为什么有时候一台H@H(特别是小水管 H@H)会被动态限制速度,而且越限制越低

注意,这个问题跟上面的不一样,限速是动态的,而且每次测速后流量都会有些许降低,直到某个值见下图。
这个问题我暂时不知道原因,推测可能是宽带的上传带宽短时间被其他服务抢了,H@H 测速结果低于预期而导致的一个 BUG。日志没发现异常,但解决问题的方法是有的。
  1. 停止 H@H 客户端(请优雅关闭)
  2. 在 H@H 的设置页面里,把 Enable Client-Side Speed Limit 关掉(如果有打开)
  3. 启动 H@H 客户端。
  4. 等待速度恢复正常(可能需要几个小时)
  5. (可选)如果有需要,则重新打开 Enable Client-Side Speed Limit。

6. 跑 H@H 的降低 HDD 负载的一个建议(非强制):给机器分配更多的 RAM 并关闭 HDD 上的 swap。

H@H 会在 RAM 中用大量的内存作为缓存使用,如果有足够的 RAM 给 H@H 做缓存,那将可以显著降低 HDD 的读取速度,一般推荐 1000KB/s 增加 2G RAM。
尽量不要在跑 H@H 的硬盘上开 swap。

7. 非中国大陆优化路由的 H@H 节点优化:启用 BBR / BBR Plus。

我们在海外运行的 H@H 节点一般都是灵车,不会带中国大陆的优化路由,但因为有时会承载到来自大陆的 H@H 请求,如果网络太差,就难以对请求提供文件,从而影响到 Trust 和 Quality。因此,我们可以启用 BBR / BBR Plus 优化到大陆的网络,缓解因非大陆优化路由导致连接过慢的情况。

BBR 对于我们老主机玩家来说是个福音。BBR 有以下优势:

  1. 在有一定丢包率的网络上可以更加充分的利用带宽,因此很适合高延迟、高带宽的网络。
  2. 降低网络链路上的 Buffer 占用率,从而降低延迟,因此很适合慢速接入网络的用户。

这些优势不仅适用于 fq,也同样适用于非大陆优化路由的 H@H,因此我们可以启用 BBR / BBR Plus 来提高到大陆的速度,减少因为因连接过慢导致 Trust 和 Quality 降低,具体方法请在谷歌搜索,因为可能涉及换内核操作,请确保启用成功后再搭建 H@H。

有些没做笔记,如果有其他想到的,我会再补充。

Comments

qiuye
2023年10月29日 at 下午1:28

请问如果把国内NAT VPS的流量转发到海外的大硬盘VPS上,这样是可行的吗?



    2023年10月30日 at 下午3:43

    理论上可行,但有几个前提条件
    1、你的国内的 NAT VPS 必须可以在绑定域名+非标端口的情况下运行 web 服务。
    (验证方法:在 NAT VPS 上安装 nginx,绑定你想运行 H@H 的端口,然后随便绑个域名,再通过域名访问,能正常打开就是正常,会弹出未备案的页面就是不行,机房 IP 基本都 NG)

    2、你必须有 VPS 的 root 权限。
    (因为需要使用 zerotier 或者 wireguard 等工具)

    3、NAT VPS 的入口 IP 与出口 IP 必须相同。
    (验证方法:进入 NAT VPS 输入 curl https://ip.sb,如果返回的结果与你的入口 IP 一致则通过)

    4、NAT VPS到海外大盘鸡的网络不能太差。
    (非必需,但你运行起来的 Trust 和 Quality 可能会很感人,因为你可以理解为这台 NAT VPS 全天24小时都在高强度 fq,对网络的要求可影响而知)

    如果这4个前提都能达到条件,那恭喜你,可以。但请注意,这个方法要求对 linux 非常熟悉,操作错误有炸机的风险,因为我没这个需求,所以我无法提供教程,感兴趣的话可以自己研究。
    这个方法可以简单理解为你把国内 NAT VPS当成了一台路由器,你把自己的电脑接在了这个路由器后面上网。
    大致步骤如下:
    1、使用 zerotier 和 wireguard 等工具打通你国内的 NAT VPS 和海外的大盘机的隧道。
    2、修改 NAT VPS 的 iptables 设置,打开 NAT VPS zerotier 网卡到 NAT VPS 对外网卡的转发,同时设置端口转发,把 NAT VPS 的 H@H 对外端口的流量从国内 NAT VPS 转发到大盘机的 H@H 运行端口。
    3、修改大盘机的 iptables 设置,把大盘机的出向流量 NAT 到国内的 NAT VPS 的 zerotier 网卡。
    (验证方法:在大盘机输入 curl https://ip.sb,如果输出结果为国内 NAT VPS 的公网 IP 则为成功)
    4、在大盘机运行 H@H,那样就可以以国内 NAT VPS 的公网 IP 跑 H@H 了。(需要在 H@H 运行参数上添加参数 --disable-ip-origin-check



      qiuye
      2023年10月30日 at 下午8:13

      谢谢大佬的建议Orz,我后来NAT VPS没申请到(没办法实名),所以搞了个上行15MB/s的免实名机子,预计Max speed开个7000KB/s,留个流量转发到海外的机器
      先捣鼓个几天,有结果的话再回来回报
      还有你女儿的主题曲真好听OwO



rei
2023年12月5日 at 上午9:32

博主你好,请问一下国内和ehentai通信问题要怎么解决,我是国内独立ipv4的大盘鸡,高位非标端口,每次都是挂没多久(十几个小时或者几个小时)就会报错[WARN] java.net.SocketTimeoutException: Connect timed out 或者 [WARN] Failed stillAlive test: (KEY_EXPIRED) – will retry later,Trust直接就负数了,正常的时候速度是没问题的,能到20MB/s以上,不知道在小鸡上直接挂代理分流连ehentai域名能不能解决问题



    2023年12月12日 at 下午12:30

    按理来说 Still Alive Test 失败不会影响 Trust,因为测试失败后,H@H RPC 会停止向你的 H@H 客户端分配流量。
    连接超时、存活测试失败是机器到 RPC 的网络炸了,而 Trust 负数是机器到大陆绅士的网络炸了。
    三者会共同发生的话一般都是取交集,就是你机器的对外网络有问题(机器到城域网部分),所以我认为代理分流解决不了你的问题。
    这个只能自查机器网络,或者联系你的 IDC 或者 ISP 上游协助检查(当然如果你不怕被查水表的话)。

    个人看法,仅供参考,建议去 EH 论坛的 Site Discussion & Help Desk 模块发帖问问。



fengzyzy
2023年12月25日 at 下午10:39

看了博主的分享,我将H@H从德国迁移到霓虹了



2024年2月5日 at 下午3:46

Windows下的Hentai@Home也会自动占用内存吗 我看任务管理器万年都是137MB的占用 用PrimoCache 分了8G 缓存命中率低得可怜



    2024年2月6日 at 上午11:39

    Windows 的我不确定诶,Linux 也是显示 H@H 只占用了几百 MB,但实际上会在 Grafana 发现会有大量的内存被拿去做 Cache 了(当然可以清空)



发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注