这就是一篇很无聊的研究文章，记录一下与DS老哥的快落Play（bushi
0.前言
开篇叠甲，本人并非计网专业，计算机网络知识仅仅只停留在表面，属于半瓶水晃荡，如有错误或问题欢迎diss : )
本文的研究和知识的总结均在大模型DeepSeek-R1-671B1的辅助下完成，包含AI辅助创作（回答内容均已部分删减，否则文本过于冗长）。
1.一切的起因
偶然的巧合，在逛中文 Minecraft Wiki的时候，看到了在教程:本地局域网联机页面中如何搭建局域网服务器板块中有这么一句话：
从技术层面讲，开放了局域网访问的Minecraft客户端会定期发送UDP多播报文，其他玩家的客户端会监听这些报文并将结果展示在他们的多人游戏菜单上。
结合在各种论坛上冲浪收集到的来自各位小白萌新们2的求助：为什么本地局域网有时候搜不到世界？
特此展开了一些些浅显的研究。
2.如何开始
有了AI都已经懒得自己思考叻，遂询问亲爱的DS老哥3如何理解这句话，于是就得到了以下几个重要知识点：
- UDP协议
- 多播（组播）通信
- 服务器发现机制
- 局域网（LAN）通信
- 应用层实现
那么很明显，本次的重点就是2和3，也就是UDP的多播通信和服务器的发现机制。
3.更进一步
确定了目标就需要得到更详细的资料，于是又详细询问了细节，得到了以下技术逻辑：
多播地址与端口的约定
Minecraft 客户端在局域网内使用固定的多播地址和端口进行通信：
- 多播地址：IPv4 中通常使用
224.0.2.60等保留地址（具体版本可能不同）。- 端口：默认使用
4445端口（不同版本可能调整）。所有支持局域网游戏的客户端都会默认监听这个地址和端口，形成隐式的“通信群组”。
服务端行为（开放局域网的客户端）
当玩家选择“开放局域网游戏”时：
生成服务信息：客户端会记录当前游戏世界的元数据，包括：
- 服务器监听的 IP 和端口（通常是本机局域网 IP + 随机分配的高位端口）。
- 游戏版本、世界名称、玩家数量、最大玩家数等。
- 周期性发送多播报文：以固定间隔（如每 1-2 秒）通过 UDP 向多播地址
224.0.2.60:4445发送广播报文，内容包含上述元数据。客户端行为（想要加入的玩家）
其他客户端的多人游戏菜单会持续监听多播地址
224.0.2.60:4445：
- 被动监听：客户端启动时即绑定到该多播地址和端口，加入多播组。
- 接收并解析报文：当监听到 UDP 报文时，解析其中的服务器信息（IP、端口、世界名称等）。
- 动态更新列表：将解析后的服务器信息添加到多人游戏菜单的“局域网游戏”列表中，用户可直接点击加入。
关键设计细节
无需预先知道 IP 和端口
- 服务端主动广播：开放游戏的客户端通过多播主动告知自己的存在，其他客户端无需主动扫描整个局域网的 IP 和端口。
- 多播组的隐式约定：所有客户端默认监听同一多播地址，天然形成“局域网游戏发现频道”。
网络层支持
- 多播路由：局域网内的交换机和路由器需支持多播（大多数家用设备默认允许）。
- 防火墙规则：客户端需允许 UDP 端口 4445 的入站和出站通信（通常由游戏自动配置）。
很好，介绍的很明白，如果还是不理解可以看下面这个简单的例子：
- 一群人正在进行头脑风暴，为了避免场面混乱，约定了举起（IP）右手（端口），再进行发言，但现在，全员都在烧烤4。
- 此时有一个人准备发言，ta举起了右手（对局域网开放），成功吸引了所有人的注意（全员监听），于是所有人都看向ta（列表出现了世界）。
类似的，Minecraft客户端之间的本地局域网联机就是用这种方法在多人游戏列表显示世界的。
4.验证
大语言模型的最大问题就是编造事实，所以针对技术细节需要加以实操验证。
目前根据DS老哥给出的信息，有以下几点需要验证：
- Minecraft客户端在打开多人游戏页面的时候，是否创建了一个UDP协议的监听，该监听地址+端口是否为
224.0.2.60:4445？ - Minecraft客户端在对一个世界对局域网开放时，是否创建了一个UDP连接，持续向
224.0.2.60:4445发送数据包？ - 在这个多播报文中到底包含了哪些内容？是否有AI列举的那些？
测试并不复杂，让我们一条一条来。
（测试版本为1.20.4，别问为什么是这个版本，顺手启动了就是这个版本XD）
4.1 验证点1
这点很简单，只需验证监听而已。
让我们启动Minecraft客户端，然后打开多人游戏界面等待，随后打开Windows自带的资源监视器。
在网络标签页中，网络活动的进程栏目里找到javaw.exe，然后即可在下方的监听端口栏目里看到有两个javaw.exe创建的UDP监听端口，地址有两个未指定的 IPv4/v6 地址，端口确认为4445。
由此可验证，Minecraft客户端确实如DS所说监听了UDP协议的4445端口，但是却没有指定IP地址，也就是实际上是全地址监听的，也挺不错的。
4.2 验证点2
对于第2点，验证起来也不麻烦，同样用到了Windows自带的资源监视器。
返回Minecraft客户端，打开一个单人存档，进入后对局域网开放，随机到的端口为：52772（1.19.3及以后版本可以自定义端口哟~）
于是可以在资源监视器的网络标签页中的网络活动栏目中，看到javaw.exe对地址224.0.2.60进行了发包，但是并不知道端口和连接协议。
利用netstat指令，即：
netstat -ano -p UDP（其中：-a：显示所有连接和监听端口。-n：以数字形式显示地址和端口（不解析域名）。-o：显示占用端口的进程 PID。-p UDP：仅显示 UDP 协议。）
利用任务管理器可以获取javaw.exe的PID：2756
在列表中找到该PID的UDP活动连接：0.0.0.0:60689
但这并不是目标端口，而是Minecraft客户端为了发送报文使用的UDP端口。
看似好像只验证了Minecraft客户端确实用UDP向地址224.0.2.60发送了包，但端口没法验证？
别急我们接着往下验证。
4.3 验证点3
关于这点，在验证过程中，也发现了另外一种不显示在列表中的原因。
要验证这一点，需要请出一个常用工具：Wireshark。
保持Minecraft的对局域网开放，打开Wireshark，选择网卡，开启混杂模式。
然后创建一个过滤器：ip.dst == 224.0.2.60（只显示出入网地址等于224.0.2.60的包）
开启捕获后，神奇的事情发生了，捕获了近万个包没有一个是指向224.0.2.60的。
但是资源监视器又明确指出Minecraft确实在库库发包。
不死心又启动了一个客户端，不出意料，多人游戏列表正常显示了这个开放的世界。
很奇怪，遂又一次询问DS老哥。
很给力的，提供了一个用netsh指令以查看多播组成员关系的方法：
netsh interface ipv4 show joins于是得到了以下关系：
Excuse me？我网卡不是以太网2吗？VMware你来凑什么热闹？？？
ojang5你是会写代码的嗷，多播给播VMware虚拟网卡上去了。
于是火速切换Wireshark捕获网卡，很好，确实是库库发包，平均1.5秒发一个：
顺便还得到了包的内容，不加密，好！
0000 01 00 5e 00 02 3c 00 50 56 c0 00 01 08 00 45 00 ..^..<.PV.....E.
0010 00 4a d2 50 00 00 01 11 47 6c c0 a8 fd 01 e0 00 .J.P....Gl......
0020 02 3c f1 b9 11 5d 00 36 18 23 5b 4d 4f 54 44 5d .<...].6.#[MOTD]
0030 37 37 38 5f 20 2d 20 e6 96 b0 e7 9a 84 e4 b8 96 778_ - .........
0040 e7 95 8c 5b 2f 4d 4f 54 44 5d 5b 41 44 5d 35 32 ...[/MOTD][AD]52
0050 37 37 32 5b 2f 41 44 5d 772[/AD]4.4 解析数据包内容
嘿，您猜怎么着？直接扔给DS老哥就完事儿了（虽然左侧的信息已经很详细了）：
完整数据包解析（基于Wireshark信息）
1. 帧基本信息（Frame 422）
- 长度：88字节（704位），实际捕获88字节。
- 捕获接口：
\Device\NPF_{8717FCFC...}（WinPcap/Npcap虚拟接口）。- 流索引：0（Wireshark用于关联同一会话的标记）。
2. 以太网帧头（Ethernet II）
目标MAC：
01:00:5e:00:02:3c
- 含义：IPv4多播MAC地址，对应多播IP
224.0.2.60（计算规则：01:00:5e+ IP低23位的十六进制）。源MAC：
00:50:56:c0:00:01
- 含义：VMware虚拟网卡（OUI
00:50:56为VMware保留）。- 类型：
08 00，即0x0800，表示负载为IPv4协议。3. IPv4头
- 版本：4（IPv4）。
- 头部长度：20字节（标准无选项IPv4头）。
- 服务类型（DSCP/ECN）：
00，即0x00（默认优先级，未启用拥塞控制）。- 总长度：
00 4a，74字节（包括IP头+负载）。- 标识符：
d1 19，即0xd119（53529，用于分片重组，此处未分片）。- 标志/分片偏移：
00 00，即0x0（未分片）。TTL：
01，即1
- 含义：多播包只能在本地网络传播（无法跨越路由器）。
- 协议：
11，即17（UDP）。- 头部校验和：
48 a3，即0x48a3（未验证）。- 源IP：
c0 a8 fd 01，即192.168.253.1（宿主机的VMware虚拟网卡IP）。- 目标IP：
e0 00 02 3c，即224.0.2.60（Minecraft默认局域网多播地址）。4. UDP头
源端口：
f1 b9，即61881（随机临时端口）。
- 意义：服务端发送多播包使用的临时端口。
目标端口：
11 5d，即4445（Minecraft局域网多播监听端口）。
- 客户端行为：客户端监听此端口以发现服务器。
- 长度：
00 36，即54字节（UDP头8字节 + 数据46字节）。- 校验和：
18 23，即0x1823（未验证）。5. 数据负载（Payload）
- 长度：46字节。
- 内容（已解析）：
数据内容为ASCII和UTF-8编码的文本，格式符合Minecraft局域网广播协议：5B 4D 4F 54 44 5D --> [MOTD] 37 37 38 5F 20 2D 20 --> 778_ - E6 96 B0 --> 新（UTF-8） E7 9A 84 --> 的（UTF-8） E4 B8 96 --> 世（UTF-8） E7 95 8C --> 界（UTF-8） 5B 2F 4D 4F 54 44 5D --> [/MOTD] 5B 41 44 5D --> [AD] 35 32 37 37 32 --> 52772（端口号） 5B 2F 41 44 5D --> [/AD]
关键字段：
[MOTD]：服务器名称与描述，此处为778_ - 新的世界。[AD]：附加数据，此处52772表示服务端监听的 TCP端口号（非默认25565，可能是自定义端口）。6. 关键问题与结论
多播包路径问题
- 源IP为虚拟网卡：
192.168.253.1属于VMware虚拟网络（如VMnet1），导致多播包仅在虚拟网络内传播。- 结果：物理局域网设备无法自动发现服务器（但可通过手动输入
虚拟网卡IP:52772连接）。TTL=1的影响
- 本地网络限制：TTL=1表示多播包只能在当前子网传播，无法通过路由器到达其他子网（即使路由正确）。
数据完整性验证
- IP总长度：IP头（20字节） + UDP总长度（54字节）= 74字节，与实际捕获长度一致。
- UDP数据长度：54字节（UDP头8字节 + 数据46字节），与负载大小匹配。
7. 协议层次结构示意图
+-----------------------------------+ | Ethernet II | |-----------------------------------| | Dst MAC: 01:00:5e:00:02:3c | | Src MAC: 00:50:56:c0:00:01 | | Type: IPv4 (0x0800) | +-----------------------------------+ | IPv4 Header | |-----------------------------------| | Src IP: 192.168.253.1 | | Dst IP: 224.0.2.60 | | Protocol: UDP (17) | | TTL: 1 | +-----------------------------------+ | UDP Header | |-----------------------------------| | Src Port: 61881 | | Dst Port: 4445 | | Length: 54 | +-----------------------------------+ | Data Payload | |-----------------------------------| | [MOTD]778_ - 新的世界[/MOTD] | | [AD]52772[/AD] | +-----------------------------------+
好家伙，写的那叫一个详尽，不愧是DS老哥，HEX转ASCII/UTF-8都信手拈来。
不过卑微的人类想要解码HEX还是借助工具吧：RapidTables
（这里的UDP发送端口与4.2节的端口不一致，是因为4.2节是后面补截的图，懒得改了就这样吧（瘫）
5.总结
由此可得，Minecraft客户端的对局域网开放是通过UDP多播向局域网内地址224.0.2.60:4445主动发包（频率为1.5秒/次），其余打开多人游戏页面的客户端则被动监听这个端口，获取到数据包后解析并显示再列表中即可。
这就导致了，出现以下任意一种情况，均无法在列表中发现对局域网开放的世界：
- 路由器/交换机开启了多播过滤：路由器/交换机禁止跨VLAN的多播转发。
- IGMP Snooping配置不当
- 无线网络开启了AP隔离
- 防火墙关闭了本机
4445端口的UDP协议通信 - 在同一个局域网但是处于不同的子网网段：由于TTL值为1，限制了包只能在所处网段传播
- IPv4与IPv6冲突：应该不会出现这种情况
- UDP的究极丢包：众所周知UDP只管发送不管送到（
- 网卡驱动缺陷：啊？（这条是DS说的，某些Realtek网卡在节能模式下会丢弃多播包6）
6.后记
很无聊的一次研究，但是DS老哥真得很强啊啊啊。
END.
Comments | NOTHING