技术(?)分享

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

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

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

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

24年5月15日追记：更新了新版本的一些内容，尽可能的把旧版本的过时信息都更换为新版本的信息。我本来写这篇文章的目的只是给自己留个记录怕忘了，但不知道为什么这篇文章在写出来后会被很多人拿去参考了，同时也出现了很多询问我的人，为了避免过时信息造成误导，因此对 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 收益：

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

24年5月15日追记：在新版本中，Hitrate 的主要收益来自静态块中的 P1 块和 HC 块（High-Capacity Ranges，高容量范围）。

P1 块是收益的主要来源，负责低解析度图片的带宽供给。

P1 块数量对应大致的 Hitrate 区间如下（由于不同 P1 块命中率可能会有所区别，仅写出我自己观察到的数据和推算，仅供参考）：

• 中国大陆（P1=1000，HC=0，MaxSpeed 5500KB/s）：1700-2300 Hit/min （不限速的话会更高，具体取决你肯给多少）
• 日本（P1=1000，HC=0，不限速）：600-900 Hit/min
• 香港、新加坡（P1=1000，HC=0，不限速）： 500-700 Hit/min

HC 块负责高解析度图片的带宽供给，因为会用高分辨率看图片的人不多，因此 HC 块 Hitrate 收益比 P1 块低，但在特殊情况下可以产生大量的 Hathrate 收益。能获得 HC 块的区域为带宽资源过剩的地区，即除了中国大陆地区外的亚洲、欧洲、美洲，且必须有 8000KB/s 以上的 MaxSpeed、设置5TB/月以上的月传输量、100G 以上的硬盘空间。另外 HC 块与优先级的块不同，一个静态块可以是 P1/P2/P3/P4/P5 块，也可以是 HC 块。

由于 HC 块的流量波动非常大并且算法没有正式公开，目前无法准确判断 HC 块的 Hitrate 收益和 Hathrate 收益。但能确定的是在有很大需求的情况下，HC 块带来的 Hathrate 会非常可观，我的日本主力机有 350 个 HC 块，低峰期的 Hathrate 只有 120，但高峰期因为 HC 块的命中率高，Hathrate 有时甚至能达到 200，所以多获得一些 HC 块没有坏处。

中国大陆：

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

因此，在测速没问题的情况下，大部分时间都是你肯给 H@H 多大上行带宽，H@H 就能吃满多大上行，只有凌晨4-5点期间可能会出现一个流量小窟窿。

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

• 24年5月15日追记：菠萝在23年10月27日的更新中，把手机端（包括所谓的第三方客户端）在设置浏览分辨率为“自动”的情况下，将会默认加载 720x 分辨率的图像，而不是 1280x，大幅节省了 H@H 的带宽，因此大陆绅士的浏览体验可能会有较大提升。

所以大陆 H@H 的最大瓶颈在于 H@H 的峰值速度，其次才是 H@H 节点的硬盘大小，毕竟大陆连小盘鸡都能在 Hitrate 上秒杀大盘鸡。由于大陆无法分配到 HC 块，因此只要按照 H@H 的峰值速度分配即可。

算上 SSL 开销等等的额外带宽，Max Speed 与 H@H 的实际带宽占用是有差异的，实际流量会比 MaxSpeed 要大 7-10% 左右，别小看这 7%，它很可能会对家庭宽带的质量产生影响。我长期测试了大陆家庭宽带在 20M 30M 50M 上行带宽能稳定提供 H@H 带宽并且不会影响居家上网体验的最大速度和硬盘需求，也写出来做个参考。

20Mbps ：设置 Maximum Upload Rate 为 3125KB/s，Maximum Disk Cache Size 设置为 122.1 GB，一共 500 个静态块。

30Mbps：设置 Maximum Upload Rate 为 4688KB/s，Maximum Disk Cache Size 设置为 183.2 GB，一共 750 个静态块。

50Mbps：设置 Maximum Upload Rate 为 6875KB/s，Maximum Disk Cache Size 设置为 268.6 GB，一共 1100 个静态块。

100M 没有长期测试过，但也发现了个问题：不建议用单块 2.5 英寸的机械硬盘去跑这么高的速度，很容易出现硬盘瓶颈，导致 H@H 被 RPC 侧限速，并且减慢 P1 块的分配速度。

另外，即使是家宽，也尽量不要勾选 Enable Client-Side Speed Limit，因为有时会遇到奇怪的限速问题，只要按照上面的限速去运行，就不会对日常上网造成影响。

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

大陆外的亚洲其他地区的收益，最高的是日本，其次是亚洲几个主要地区（当然现在有 HC 块的存在，有时候收益能跟日本持平），东南亚除了新加坡外我没测试过，至于印度和以色列这些奇葩地区我也懒得测了，估计也没几个人会去开这些地区的机器。

在亚洲热门地区，由于家宽和 VPS 上传速度普遍高于 100M，且负载量没有大陆这么夸张，因此带宽瓶颈是基本不存在的（不过在静态块足够的情况下有小概率会出现 100M 不能完全吃下高峰期请求的情况），所以就需要一块尽可能大的硬盘来获取足够多的 P1 和 HC 块以换取更多的 Hitrate 和 Hathrate。

争夺 P1 块和 HC 块对于海外 H@H 的收益尤为重要。可以说没有 P1 块和 HC 块的海外 H@H 机器就是一台单纯的给其他 H@H 机器测速用的工具人。

大人，时代变了！H@H 新版本的已经不是靠静态块总量就能打天下了！

现在是 P1 为王，HC 为妃了的时代了。在没有 P1 块和 HC 块的情况下，即使你有 6000 个静态块，你的 Hitrate 收益也几乎可以忽略不计。

那么如何快速获得 P1 和 HC 块呢？我这边根据自己的记录发现 P1 和 HC 块的分配速度受到以下因素的影响：

1. 区域：不用多说，建议把机器放在热门地区以获得最大的 P1 块增加速度。
2. MaxSpeed：在其他条件不变的情况下，MaxSpeed 越快，分配到 P1 块的概率就越大。我有几台日本机，速度有 163840KB/s（1.5Gbps）、81920KB/s（1Gbps）、39489KB/s（500M）、10240KB/s（100M），他们获取到 P1 的速度是正相关的，而且 1.5Gbps 获取到 P1 块的速度明显比 1Gbps 的机器快，100M 的分配速度非常慢，一两个月都没分到几个 P1 块和 HC 块。
3. 静态块总数：每 2000 个静态块总数为一个区间，获取到 P1 块的概率都会提高，4000-6000 个块获取 P1 块的速度最快，其次是 2000-3999 个块，速度最慢的是 0-1999 个块。这也算是给长期稳定运行 H@H 的老人一些优待吧，毕竟是能确定是长期稳定运行的。
4. 端口：443 端口获取 P1 块和 HC 块的速度会比其他端口的速度快，因此对于不需要使用 443 端口的 VPS 来说，尽量让 H@H 占用 443 端口是最优解。

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

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

2. 静态块（Static Ranges）的上限取决于哪些因素？

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

那么有瓶颈的情况下呢？在不满足下面情况下，你的静态块的上限取决于你的限制。
在不考虑 HC 块的情况下：
硬盘大小：1个静态块需要 250MB 硬盘空间，在不考虑 HC 块的情况下 1465GB 封顶 6000 个。
网速：1个静态块需要 5KB/s 的 Max Speed，6000个静态块需要 30000KB/s。（2023年10月27日更新）
H@H 节点设置里的每月的流量限制（Monthly Data Transfer Target）：1个静态块需要每个月提供 5GB 的流量。

在考虑 HC 块的情况下：
硬盘大小：理论上 6000 个 HC 块需要 6TB 的硬盘空间，但实际上根本不可能分配的了这么多，基本上 500 来个 HC 块就已经非常多了，因如果硬盘有其他用途的话，建议最大只给 H@H 设置 1465GB，等 HC 块到达 750 以上，并且静态块总量超过 4000 再考虑增加空间。
网速： 设置里的 Maximum Upload Rate 需要大于 10240KB/s，否则无法分配到 HC 块。
H@H 节点设置里的每月的流量限制（Monthly Data Transfer Target）：需要大于 5TB/月，建议前期先不设置，让静态块以最快的速度填充，直到 VPS 有爆流量的可能性后再限制。

1. 在 HC 块实装之前，我见过有大佬给了 2T 空间的情况下，H@H 把这 2T 都吃满了，但静态块数量仍然是 6000，并且没有额外的 Hitrate 收益，修正成 1.5T 后除了释放出空间外没其他区别。但现在在实装了 HC 块的更新后，如果静态块数量已经超过 4000 以上，才考虑扩大硬盘空间，不然仍然建议先限制到 1465GB。

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

3. （失效）既然大陆 H@H 的最大瓶颈是网速，为什么仍建议扩大硬盘大小？

新版本已修复这个情况，故该方法不再写出。

4. 我想要冲 H@H Toplist 的年奖杯，我该怎么做？

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

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

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

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

我甚至见过有大佬只靠一台 200M 上行带宽的大陆 H@H 跑出了 9000Hit/min 就杀进前十的惊人数据，充分的证明了什么叫钞能力。

二、H@H 运作问题

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

可以完整保留静态块，但 P1 块在跨洲迁移的情况下需要清空 P1 块。
首先，静态块可以完整保留，只需要保证新的机器的 cache 数据完整就行。
但 P1 块有可能需要联系菠萝清空。

在23年10月29日的更新中，菠萝为了防止一些小聪明在 P1 块增长速度高的流量冷门地区拿到足够的 P1 块后搬去流量热门地区欺负正常的客户端。因此在跨大区搬运（比如从中国大陆搬去日本、欧洲搬去亚洲）时，在 H@H 页面的国家/地区会亮起红色。
在这个情况下不会再被分配新的静态块，同时 P1 块的收益会极大降低，可能会比原客户端的 P2 优先级还要低。
如果遇到该情况，请私聊菠萝，让菠萝把所有的 P1 块降级为 P2 块，从0开始攒 P1 块，或者搬回原来的地方。

同一个地区内的移动不受影响（比如从日本搬到香港、从台湾搬到新加坡、从美国搬到加拿大），只要国家/地区没有亮起红色，就不需要联系菠萝把 P1 块降级为 P2 块。

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

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

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

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

上文我说过，中国大陆在高峰期间有一部分流量需要调度到海外 H@H 节点承载，因此请尽可能保证你位于亚洲区域的 IP 没有被墙，否则可能会面临 Quality 和 Trust 死活上不去的问题（这对于新的 H@H 客户端来说最为严重）
24年5月15日追记：在23年10月2日的更新中，菠萝把中国大陆区域作为了单独的区域，由于跨区域调度失败不会影响 Trust 和 Quality，因此亚洲区域的 IP 就算无法被中国大陆访问也不会对客户端造成太大影响了，但考虑到 GP 收益，仍然强烈建议 IP 没有被墙。

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 二次限速。

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 请求，如果网络太差，就难以对请求提供文件，从而影响到 GP 收益。因此，我们可以启用 BBR / BBR Plus 优化到大陆的网络，缓解因非大陆优化路由导致连接过慢的情况。

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

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

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

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