网络包优化重制版

网络包优化重制版

NEBL 在 Minecraft 游戏过程中使用多种方法来节省网络流量。

性能

带宽不足：经典版（NEBL）

这是带宽不足（Not Enough Bandwidth）模组的向下移植版本。经原作者许可，我们将其移植到了更早的 Minecraft 版本，其功能与原版 NEB 基本相同。

NEBL

简介

NEBL 采用多种方法，在 Minecraft 游戏过程中尽可能节省网络流量，同时保持对模组和玩家透明。

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

output

在原生（Vanilla）环境测试中，服务器出站流量降至原始大小的 18%。理论上，随着安装模组数量的增加，网络传输内容会更大更复杂，压缩效果也会更好。

在游戏中，NEBL 提供了一个简洁的流量状态界面。你可以在按键控制中查看绑定按键，并使用它打开此界面。

image

主要特性

紧凑数据包头

通过用紧凑索引替换数据包头（包类型），优化 CustomPacketPayload 的编码和解码。这将模组网络包头开销减少到固定的 3-4 字节，而不是网络包类型对应的字符串长度。

索引结构如下：

固定 8 位头

┌------------- 1 byte (8 bits) ---------------┐
│               function flags                │
├---┬---┬-------------------------------------┤
│ i │ t │      reserved (6 bits)              │
└---┴---┴-------------------------------------┘
  • i = 索引标记（1 位）
  • t = 紧凑索引标记（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

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

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

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

contextLevel

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

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

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

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

dccSizeLimit、dccDistance、dccTimeout

仅在服务端生效。

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