企业官网建设流程全解析

0. 一个前提：投屏是三段，不是一件事

[发送端] --发现--> [接收端清单] --协商--> [能力约定] --传输--> [画面数据] ↑ 组播 ↑ 单播/控制通道 ↑ 单播媒体流

“投屏不上”的投诉里，“找不到设备”是发现层故障，它一帧画面都不传。发现层用的是组播，所以有一个反直觉的结论：

网页、文件一切正常（单播好）不代表投屏能发现设备（组播好）。

1. 各种投屏协议到底走哪条路

mDNS 的端口与组播地址见 RFC 6762。注意最后一行：Miracast 不依赖局域网组播，所以“Miracast 能用但 AirPlay 不行”完全可能，别拿它证明网络没问题。

2. 为什么组播这么脆

1. 802.11 里组播/广播帧不确认、不重传，且通常被压到最低基础速率发送——成功率天然低于单播，且下降得很早；
2. 省电机制：休眠中的无线网卡可能错过组播；
3. 二层边界：224.0.0.251 属链路本地控制块，路由器不得转发到子网之外。跨 VLAN / 连了访客 Wi-Fi，发现必然失败；
4. 组播处理策略不对称：链路本地组播（224.0.0.251）不走 IGMP，很多交换机当广播泛洪；而 SSDP 用的 239.255.255.250 属管理范围地址，会进 IGMP snooping 判定——snooping 配得不对，会只干掉DLNA 那一类发现；
5. AP 开关：客户端隔离（同 SSID 内互不可见，直接致命）；多播转单播（把组播拆成单播逐个发，显著提升投递率）；
6. 主机侧：入站 UDP 5353/1900 被防火墙或安全软件拦；Windows 网络画像为“公用网络”、“网络发现”关闭；
7. IPv6 双栈不干净：苹果设备优先用 FF02::FB，组播被挡就出现“发现闪断”。

3. 实操：10 分钟定位

dns-sd-B_airplay._tcplocaldns-sd-B_googlecast._tcplocalavahi-browse-art|grep-iE"airplay|googlecast|_raop"ping<接收端IP>sudotcpdump-niany udp port5353sudotcpdump-niany udp port1900

判定表

变量隔离顺序（一次只改一个）：换 SSID → 关本机防火墙 → 只留 IPv4 → 换一台发送设备。四个实验做完，绝大多数“时有时无”都能落到具体某个开关上。

4. 检查清单（可直接抄进房间验收表）

• 会议室接收端与常用发送设备在同一二层域（同 SSID/同 VLAN）；
• 访客网络是否有意投屏：明确写进房间说明，不要靠临时放行；
• AP 上多播转单播已开启；客户端隔离策略已按投屏需求评审；
• 交换机IGMP snooping配置与 DLNA 类设备兼容（改动前后拿抓包比对）；
• 防火墙放行入站UDP 5353 / 1900（本地子网）；
• IPv6 要么配置干净，要么明确关闭，不留半吊子状态；
• 跨网段房间：已部署mDNS 反射/Bonjour 网关并纳入变更管理；
• 三段各有观测项：发现成功率 / 协商成功率 / 传输质量；
• 报修模板含：设备型号、SSID、协议、接收端 ping 结果。

5. 小结

• 投屏“找不到设备”绝大多数不是信号问题，而是发送端与接收端不在同一个组播域，或这个域里的组播被顺手关掉了；
• 单播正常不能作为投屏正常的证据；
• 把发现当成一条独立服务链来验收和监控，这类“时有时无”的投诉就会从玄学变成清单上的一行。