Write Up: IHA：如何写一个更好的hypixel cdn

huzpsb

TL；DR
本文提出了一种可以使端内延迟<0ms*的，到处都是黑魔法的hypixel的的cdn方案。
你可以在 45.205.25.26 （直接作为服务器地址使用，续费至20250817）测试这个cdn。
你可以在 https://github.com/huzpsb/ih-accel/releases/tag/v1 下载这个cdn的可执行文件与ppt版的技术报告。

*：指的是到节点的motd延迟比到hypixel的TCP RTT更短。




EveryCast
众所周知，Hypixel有多个ip地址作为负载均衡。

一般来说，dns服务器只会返回其中的一个。
但是，我们可以使用神秘在线api对其进行全部查询。
显然，我们的cdn到各个源节点的延迟是不一致且变化的。
我们仅需每分钟对其进行一轮测速并选择延迟最低的节点即可。
然而，这么做会带来一个问题，即，当到目标ip的连接数过多时，许多运营商会对ip组进行限速。
因此，我们也以一定的概率选中更慢的ip，以确保所有的连接不以唯一的ip为目标。



HeadMod
如果你试过你就会发现，ngx不能当作hyp的cdn。
bc/vc不可用是显而易见的，因为hyp是正版服务器。为什么ngx不能用呢？

经过简单的研究我们可以发现，mc自己存在sni机制。



具体来说，
https://minecraft.wiki/w/Java_Edition_protocol/Packets#Handshake
Handshake包中包含一个MC-SNI
所幸这个包是不加密的，因此仅需对其进行篡改

就像这样。


SoftNaggle
MC的pvp体验由实体而非地形的同步性保证。

问题在于，在Encryption Request后，流量不再是明文，我们真的可以整活吗？、
能的兄弟，能的。
不难发现mc的许多包的大小非常的有特征。例如Update Entity Position，
PacketSize Varint 肯定是1b
Entity ID Varint 大概率是1b，可能是2b
最后是三个short一个bool，也就是说，9-10b的一系列包就是tick结束时的实体更新
我们知道，包越多越容易掉。
仅需利用包大小特征进行软粘包即可优化pps。
建议是相似的包黏在一起。


NoSleep
但是SoftNaggle会带来一个问题，即，有的时候会有超过10ms无raw包出现。

这可能会导致运营商认为我们的流量是非推流流量，触发限速，这不好。
仅需发送空包即可解决。
特别的，可以将空包替换为下一个TCP包的开始包（抢发），进行电表倒转。



Summary
基于上述的L4 Tricks，本方案成功地实现了端内延迟<0；

在破烂线路上进行测试，延迟小于开源的ZBProxy70-100ms；
取得了类似于雪糕、忆等付费方案的延迟与稳定性；
为Hypixel玩家社群提供了新的低成本的选择。