我的世界Minecraft连接服务器时出现unable to fit 2253638 into 3的报错

最新推荐文章于 2024-08-31 16:06:09 发布

有梦想的年轮哦

最新推荐文章于 2024-08-31 16:06:09 发布

阅读量958

点赞数 4

文章标签：经验分享笔记 java

本文链接：https://blog.csdn.net/timenianlun/article/details/134766888

版权

解决方法

将MC服务器的server.properties配置文件中的network-compression-threshold参数更改为0到2253637中的任意一个数就行，或者恢复到默认的256。

过程的记录

最近在玩我们自己制作的一个整合包，在整合包的一次微调以及部分内容的更新之后，玩家连接服务器就出现了unable to fit 2253638 into 3的报错。

我们先来直接翻译这段报错内容：

翻译后这也看不出有什么问题呀。

第一次出现报错

第一次出现的时候，在整合包作者的通宵努力下，就解决了。处理过程是将已经不存在的模组的数据从存档中删除。在整合包的更新中，有一些模组会被去掉，也有一些模组会被添加进来，按照这样来看，似乎是已经不存在的模组，其遗留在存档中的数据导致的问题。

第二次出现报错

直到这一次整合包更新再一次出现了这种情况。好在这一次是有比较详细的操作过程的，而且操作的内容不算多。

在这次整合包的更新，一开始并没有出现任何问题，玩家都是可以正常进入的。

因为这一次是更新了核心，从forge-1.20.1-47.1.46更新到了forge-1.20.1-47.2.4，所以server.properties配置文件需要重新进行配置。我为了方便，在对比了两个版本整合包的配置文件，检查新版本没有增删任何项目后，直接覆盖掉了原始的配置文件。并且，有一个定时自动关服模组的配置文件也需要重新进行调整。

那么也就是说，更改了两处地方，一个是server.properties配置文件，另一个是定时自动关服模组的配置文件。更改完后重启，玩家就进不去服务器了。

找出它

1.我是优先排查的定时自动关服模组，把它的配置文件以及server.properties配置文件都进行删除，让服务器重启，自动生成默认的。这次进入服务器没问题了，看来问题的确与这两处地方有关。

2.将更改后的定时自动关服模组的配置文件重新放回去，server.properties保持默认的不变，这次也成功进入服务器，成功排除模组的问题。

3.在server.properties配置文件中，其他的项目保持不变，将最不可能的几项进行了更改，分别为：

allow-flight(允许飞行)
difficulty(游戏难度)
max-players(服务器能同时容纳最大玩家数)
motd(玩家客户端的多人服务器列表中显示的服务器信息)
online-mode(是否开启正版验证)
view-distance(视距)

按照需求进行更改后重启，很好，并没有出现问题，成功进入服务器，排查范围进一步缩小。

4.接下来就剩下以下三项了，分别为：

enable-command-block(是否启用命令方块)
max-tick-time(服务器每个tick花费的最大毫秒数)
network-compression-threshold

*我将enable-command-block设置为true，默认为false，虽然是生存模式，没有命令方块，但为了保险，还是设置为允许了。重启后，能正常进入服务器。

*max-tick-time我设置为了-1，默认为60000，因为有机械动力的存在，服务器卡顿是日常，如果保持默认容易误判崩服，所以设置为-1禁用它。当然，不改问题也不大。重启后，能正常进入服务器。

问题所在

那么就只剩下最后一个了，不会吧，最后一个了才找到问题所在？好好好。

事实证明，是的，的确是到最后一个才找到。

network-compression-threshold默认的值为256。当数据包的字节大于或等于这个数时就会进行压缩，数据的压缩是需要消耗电脑性能的，如果不压缩，则对网络的带宽需求比较大。而我的电脑性能稍微逊色一些，网络倒是不存在什么瓶颈，所以我一般都将其值设置为-1禁用数据包压缩，让更多的性能用于MC服务器运行。

在我又将其值设置为-1，重启服务器之后，玩家连接服务器就成功出现了报错，那就基本可以锁定是network-compression-threshold的问题了。

到底是多少

然后我就开始一个一个数去找，查找值的上限和下限。下限是-1没问题了，得找上限是多少。而设置为0的话，就是完全压缩数据包(应该是按照64字节进行压缩)。

我们来看一下Minecraft Wiki上的说明：server.properties内容介绍https://zh.minecraft.wiki/w/Server.properties

接下来就是一个个值进行排除，1024、2048、4096、8192，10000，20000这几个数都没有问题。然后看到了network-compression-threshold上面的max-world-size=29999984，于是我一下把它的值调成29999984，结果就报错了。然后就从29999984这个数一直往下减小，报错，报错，报错，还是报错。

很好，这样来找上限实在是太麻烦了。network-compression-threshold的值的单位是字节，能不能从带宽的大小来入手？一般我们的上传都在50Mbps左右，我们直接拿100Mbps来算。也就是12.5Mb/s的上传速度，我们就取这一秒的数据大小，就粗略算为10Mb吧。转换成字节就是10000000。重启，进服，报错。(network-compression-threshold中的参数是每次传输的数据包的大小，这里只是粗略进行算取)

接下来又是不断地重复操作，减小数值、重启、减小数值、重启。。。报错、报错、报错。。。

就在一筹莫展之时，突然想到报错界面不是有一串数字嘛， 2253638，虽然并不抱有什么希望，但试了这么多，试试这个也没什么。

重启，进入服务器，欸！报错了。接着在原基础上减1，即2253637，重启，进入服务器，欸！进去了！那么2253637就是我们要找的数了！

为什么是它

我对这方面其实不是很了解，后来找原因的时候发现这串报错内容之间还有冒号进行隔开，于是我将他们单个拎出来搜索。

Internal Exception这个是直接能翻译，翻译结果为：内部异常。
io.netty.handler.codec.encoderexception和java.lang.IllegalAgumentExcpetion单独直接翻译翻译不出来。
而io.netty.handler.codec.encoderexception单独搜索它也搜索不出来什么内容，大多数内容都很杂，并没有对其含义有解释。
java.lang.IllegalAgumentExcpetion倒是搜索出来解释了。大概意思就是当收到一个非法或者不合理的参数时，就会抛出异常。

以下是我的一个猜测：

我们看到， network-compression-threshold的数值其实还是有限值的，-1是将数据压缩禁用，说明就是将数值设定为了无穷大，也就超过了2253637。玩家进行连接的时候，进行了数据包的传输，结果服务器接受不了这个参数，于是玩家进入服务器就报错了。

但是很奇怪的是，之前的整合包版本也是这样进行设置，也都没问题，为什么这两个版本就出现问题了呢？其实平时和朋友玩小游戏的时候，我将其设置为-1，也发现了异常，玩家延迟会一时高一时低。

MTU是什么

我们注意到MINECRAFT WIKI对network-compression-threshold的注释中有MTU这个东西。

最大传输单元MTU（Maximum Transmission Unit，MTU），是指网络能够传输的最大数据包大小，以字节为单位。MTU的大小决定了发送端一次能够发送报文的最大字节数。如果MTU超过了接收端所能够承受的最大值，或者是超过了发送路径上途经的某台设备所能够承受的最大值，就会造成报文分片甚至丢弃，加重网络传输的负担。如果太小，那实际传送的数据量就会过小，影响传输效率。

大家感兴趣可以去看一下MTU的详细说明：

什么是MTU？https://info.support.huawei.com/info-finder/encyclopedia/zh/MTU.html按我的理解来说，就是网络中每次传输的数据包大小最大为1500字节，如果数据包的大小超过了1500字节，就可能会出现丢失。相当于一车货最多能拉5吨，但是我的货有6吨，多出的1吨装不下只能留在原地了，拉走的货只有这5吨。而且如果每次的数据包设置得很大，那么装货的时间就长了，需要达到这么多量才能发车，所以延迟就高了。这或许就是在小游戏中，network-compression-threshold设置为-1后出现间断性高延迟的原因之一。

ping了一下我的局域网，我的网络允许的最大MTU是1500。

如何知道自己的网络允许的最大MTU是多少：MTU查询https://www.xitongzhijia.net/xtjc/20210515/210940.html
为什么是ping 1472：为什么是ping1472字节？https://blog.csdn.net/as480133937/article/details/127291624

我实际测试了一下，将network-compression-threshold设置为1024、1500，传输带宽大小和设置为256的时候的差别并不大，没有特别需求，其实保持默认的256就好。

network-compression-threshold有用嘛？

平常和朋友联机用的都是内网穿透，为了排除内网穿透的局限，所以我用本地局域网连接了服务器。实际测得，当其值为256的时候，一个玩家在两百个模组的服务器内不断传送，带宽能跑到5Mbps。而设置为2253637，带宽能跑到30Mbps，看来还是有一定作用的。在一次传送中，设置为256和2253637的带宽跑的时间基本相同，但是带宽大小不同，设置为256的明显小于2253637，所以设置为256时，数据大小确实被压缩了。

像樱花穿透默认套餐为10Mbps也确实够用了。禁用数据压缩的话，带宽上行能跑到30Mbps以上(最大没见到有超过50Mbps)，对网络不太好的玩家是会有一定影响，看各位服主如何权衡了。

禁用数据包压缩对减小MC服务器在数据压缩上的性能损耗，其实感知并不明显。