遇到的问题
本文章只在高带宽需求情况下优化显著，如果想借此优化大量cpu性能其实还是有点有限的，如果你想进一步压榨mc服务器的性能或者节省带宽，其实有个近乎无感的方案，如标题所示，但前提是你的cpu要有性能冗余，或者带宽足够，什么？你不知道你服务器是性能不够还是带宽不够，也许这并不在本篇文章的讨论范围之内，如果你知道那我现在应该做什么:
network-compression-threshold=256
这是一个配置项，存在与各种代理端和各种单端配置文件，代理端配置文件为config.yml单端配置文件为server.properties配置内都有此项目的配置项，借用官方wiki对此配置项的解释：
为1M小水管的Minecraft服务器加速的各种尝试 - 知乎
知乎有篇文章通过此配置文件将带宽需求压缩到1M，追求极限的可以参考。其实大部分服主很难说达到带宽不够用的情况，cpu性能不够用可以换cpu或者优化其他项，但是如果带宽不够用，如果是使用的是云服务器之类的业务加带宽就需要加钱，其实此配置项是通过用CPU压缩网络压缩包来达到用CPU性能换带宽节省的，反之同理，含义是网络封包压缩的阀值。例如设置为16，代表封包大于16才被压缩，设置成256代表着封包大于256才被压缩。设置的值越小则会压缩更多的封包，可以使得宽带使用减少，提高网络流畅程度，但是也会增加性能的开销，设置的值太小，例如小于等于32会明显增加对性能的开销，不建议这么做。通常如果你的服务器是群组服有代理端bc什么的，你只需要修改bc的config.yml内的此配置项，子服需要在server.properties内调整为关闭数据包压缩，填写为-1
如果你想优化CPU占用，你可以将此配置项设置为-1 代表完全禁用数据包压缩
如果你想优化带宽占用，你可以将此配置项设置为0及以上的数值
当然我的服务器是群组服，CPU为9950x所以设置的值为32
实例测试
本服在一次圣诞节活动的人数情况大概是：一共有5个生存子服，2服大概40人+ 3服大概30人+全服零零散散有140人，特指2、3服是因为他们大部分玩家都在聚集开派对，但是因为设置值为0，压缩全部数据包，其实也就50m的上行，但是这种玩家聚集环境对带宽的要求极大！因为这是一种握手效应，每秒产生的“微小包”（如转头、走路）是指数级增长的，当时在活动高涨时，甚至飙升到了90m！
分散状态： 如果 30 个玩家分散在世界各地，玩家 A 的移动只发给玩家 A 自己（确认）和极少数附近的生物。
聚集状态： 当 30 个玩家聚集在同一个主城或活动中心时：
玩家 1 的每一个动作（走位、转头、挥手、换装）都要同步给其他 29 个人。
玩家 2 的动作也要同步给其他 29 个人。
但是我是mod服，此实例只能做个参考，所以大致得到理论为：
人聚在一起更吃带宽，分开生存游玩更吃CPU
在了解这个配置原理之前我一直以为就是需要无脑上带宽，不然根本开不了大型活动，人一旦聚在一起握手效应导致的网络包体就特别多，非常吃网络上行，其实可以在玩家日常游玩时调高配置项保证性能，在开活动或者要进行高带宽活动时调低或者之间全部压缩数据包来节省带宽
如果你的服务器是Fabric端你还可以安装增强数据包压缩 (Enhanced Packet Compression) - MC百科此mod来更进一步压缩
某ai对压缩和不压缩性能的回答（参考）
在Minecraft服务器的 server.properties 中，network-compression-threshold 是一个平衡“CPU算力”与“网络带宽”的杠杆。
简单来说：压缩能大幅节省带宽，但会增加CPU负担；不压缩则完全相反。
以下是根据不同配置（全部压缩 vs 完全不压缩）下的具体性能损耗与带宽表现分析：
1. 设置为 0（全部压缩）：带宽降至极致，CPU负载最高
将阈值设为 0 意味着服务器会尝试压缩每一个发往客户端的数据包（无论大小）。
带宽省下多少？
区块数据（Chunk Data）： 压缩率极高，通常能达到 70% - 90% 的节省。对于地图加载而言，原本 1MB 的区块数据压缩后可能只有 100KB。
移动/聊天/小封包： 节省几乎为 0。小数据包（如几十字节的坐标更新）压缩后可能因为增加了“压缩头”信息，体积反而变大或持平。
综合统计： 在玩家密集活动（如跑图）时，相比不压缩，总带宽占用能下降 50% - 80%。
性能损失多少？
CPU消耗： 显著增加。服务器必须为每一个玩家的每一次动作（每秒 20 次 Tick 产生的同步包）调用压缩算法（通常是 zlib）。
延迟影响： 如果 CPU 单核性能较弱，大量的压缩计算会导致主线程排队，产生明显的网络延迟（TPS 没掉但 Ping 高了）。
建议： 仅在你的服务器上行带宽极其有限（如 1-2Mbps）且 CPU 算力过剩时使用。
2. 设置为 -1（完全不压缩）：CPU零压力，带宽占用爆炸
禁用压缩意味着所有封包以原始大小发送。
性能省下多少？
CPU消耗： 网络 IO 部分的 CPU 占用会降至最低。对于千人服或者配置极低的 VPS，这能腾出关键的 CPU 周期给 AI 计算和红石。
处理能力： 因为省去了压缩步骤，封包发送的速度理论上更快（微秒级提升），但前提是你的水管够粗。
带宽浪费多少？
数据爆炸： 一个正在高速飞行的玩家，单人就能瞬间吃掉 5-10Mbps 的带宽用于加载区块。
综合统计： 相比默认设置（256），带宽消耗会直接翻 4 到 8 倍 甚至更多。
建议： 仅在局域网环境或**同一台物理机内的内网转发（如 BungeeCord 连后端子服）**时使用。
3. 为什么默认值是 256？（黄金分割点）
Minecraft 默认将阈值设为 256 字节，这是一个非常聪明的设计：
大包（区块、NBT）： 超过 256 字节，这些包通常包含重复率极高的地形数据，压缩收益巨大。
小包（移动、聊天、心跳）： 小于 256 字节，直接发送，不浪费 CPU 算力去压缩那些“压不动”的小玩意。
总结建议
具体数据参考：
在一个拥有 10 名玩家、正常生存探索的服务器上：
不压缩 (-1)： 上行带宽可能瞬时达到 20-40 Mbps。
全部压缩 (0)： 上行带宽可能稳定在 2-5 Mbps 左右，但 CPU 的 Netty 网络线程占用会提升 10%-20%。
结论： 除非你是专业折腾内网转发的，否则保持默认 256 或根据 CPU 强度微调到 512 是最优解。如果你发现玩家跑图时 CPU 飙升，就把这个值调大；如果发现上行带宽满了，就把这个值调小。