Not Enough Bandwidth Legacy

Not Enough Bandwidth Legacy（NEBL）

这是对Not Enough Bandwidth的旧版本移植。经原作者许可，我们将其移植到了较旧版本的 Minecraft，功能基本与原版 NEB 相同。

简介

NEBL 通过多种方式，尽可能减少 Minecraft 游戏过程中的网络流量，同时对模组和玩家保持透明。

在来自 TeaCon Jiachen的 ZZZZ 数据集中，与未经压缩的原始数据相比，NEBL 理论上可将服务器的出站流量降至原来的 7.6%，实际测得约为 13.8%。

在原版环境下进行的测试中，服务器出站流量降至原来的 18%。理论上，安装的模组越多，通过网络传输的内容就越庞大、越复杂，压缩效果也会更好。

游戏内，NEBL 提供了一个简洁的流量状态界面。你可以在按键设置中查看对应的按键，并使用该按键打开界面。

主要功能

紧凑数据包头

通过将数据包头 Identifier （数据包类型）替换为紧凑索引，优化 CustomPacketPayload 编码和解码。这样一来，模组网络数据包头的开销固定为 3–4 字节，而不再取决于网络数据包类型对应字符串的长度。

索引结构如下：

固定 8 位数据包头

┌------------- 1 byte (8 bits) ---------------┐
│               function flags                │
├---┬---┬-------------------------------------┤
│ i │ t │      reserved (6 bits)              │
└---┴---┴-------------------------------------┘

• i = indexed（1 位）
• t = tight_indexed（1 位，仅当 i=1 时有效）
• reserved = 6 位（留作未来用途）

索引数据包类型

• 如果 i=0（未索引）：

┌---------------- N bytes ----------------
│ Identifier (packet type) in UTF-8
└-----------------------------------------

• 如果 i=1 且 t=0（已索引，非紧凑）：

┌-------- 1 byte ---------┬-------- 1 byte --------┬-------- 1 byte --------┐
┌------------- 12 bits ---------------┬-------------- 12 bits --------------┐
│    namespace-id (capacity 4096)     │       path-id (capacity 4096)       │
└-------------------------------------┴-------------------------------------┘

• 如果 i=1 且 t=1（已索引，紧凑）：

┌--------- 1 byte ----------┬--------- 1 byte ---------┐
┌--------- 8 bits ----------┬--------- 8 bits ---------┐
│namespace-id (capacity 256)│  path-id (capacity 256)  │
└---------------------------┴--------------------------┘

接下来是数据包数据。

当网络数据包的命名空间和对应路径长度均小于 256 时，占用 3 字节；大于 256 时，占用 4 字节。最多支持 4096 个模组，每个模组最多支持 4096 个通道。

聚合与压缩

优化原版游戏经常产生大量小型网络数据包的问题。在 Connection 层拦截传输内容，每 20 毫秒将其组装成一个大型网络数据包，压缩后发送。

┌---┬----┬----┬----┬----┬----┬----...
│ S │ p0 │ s0 │ d0 │ p1 │ s1 │ d1 ...
└---┴----┴----┴----┴----┴----┴----...
    └--packet 1---┘└--packet 2---┘
    └----------compressed----------┘

• S = varint，压缩缓冲区的大小
• p = 前缀（medium/int/utf-8），表示此子数据包的类型
• s = varint，此子数据包的大小
• d = bytes，此子数据包的数据

延迟区块缓存

在原版游戏中，当玩家移动时，服务器会指示客户端立即忘记身后的区块；如果玩家返回原位置，则必须重新发送完整的区块数据。通过延迟这种“忘记”行为，可以节省四处探索时产生的区块传输流量。

配置

修改位于 config/NotEnoughBandwidthLegacyConfig.json的配置文件。

compatibleMode

在客户端和服务端上独立生效。

是否启用兼容模式。如果设为 true，将使用下方的 blackList。

blackList

在客户端和服务端上独立生效。

兼容模式的黑名单。此处列出的数据包将被 NEBL 跳过。默认包含一系列与 Velocity 相关的数据包，但你可以根据需要添加新的数据包。

为确保数据包顺序，黑名单中的数据包会中断正在进行的聚合。如果黑名单中的数据包较多，或相应数据包发送过于频繁，聚合压缩的效率将会降低。

contextLevel

在客户端和服务端上独立生效。

用于压缩的上下文窗口大小。有效值为 21 到 25 的整数，分别代表 2MB 到 32MB。默认值为 23（8MB）。

更大的上下文窗口可获得更好的压缩效果和带宽节省，但会消耗更多内存。

对于拥有 100 名玩家的服务器，设为 25 将导致约 3200MB 的额外内存占用。

dccSizeLimit、dccDistance、dccTimeout

仅在服务端生效。

延迟区块缓存（DCC）允许的最大缓存区块数、缓存区块距离和缓存超时时间。较大的值可能消耗更多内存，而较小的值可能更频繁地触发更新。