内网直播卡顿这件事，是我做企业直播这些年遇到过最反直觉的问题之一。客户的逻辑非常朴素："我们自己的局域网，千兆到桌面，怎么可能比走公网还卡？"
但事实就是这么荒谬。今年五月，一家在无锡有两个厂区的制造企业找到摄行科技，他们自建的直播平台在办公区好好的，一到车间办公楼就整片卡成幻灯片。我们花了一天半做了一次完整的拓扑体检，最后定位的原因，跟带宽一点关系都没有。
下面这份体检报告的格式，我们现在给每个内网直播项目都在用。
体检项一：终端并发数与接入层收敛比
检查方法：统计单台接入交换机下同时观看的终端数量，除以该交换机上联带宽。
实测结果：客户车间办公楼的接入交换机是48口千兆，上联只有一条千兆光纤。会议当天该楼有213人观看，其中87人挂在同一台交换机下。单路码率3.8Mbps，87×3.8=330Mbps，理论上千兆上联绰绰有余。
问题在哪：这台交换机同时还承载着MES系统的数据回传和一套视频监控的存储流，实测上联口平均占用已经到了740Mbps。直播流一进来，瞬间打满，丢包率飙到4.7%。
结论：内网直播卡顿的第一大来源不是总带宽不够，而是收敛比设计时没把直播算进去。企业内网的带宽规划通常按"办公流量"做，直播是突发的、持续的、大流量的，属于计划外来客。
整改动作：给直播流单独划VLAN，接入层上联扩到万兆，或者退一步——把直播码率从3.8Mbps降到2.2Mbps。后者当天就能做，前者要走采购。
体检项二：组播有没有真的生效
检查方法：在交换机上查看IGMP Snooping状态，抓包确认直播流是以组播还是单播形式转发。
实测结果：客户平台号称"支持组播"，实际配置里IGMP Snooping只在核心层开了，接入层全是关的。
问题在哪：这是最典型的"以为开了其实没开"。组播的价值在于同一份数据在链路上只传一份，到分叉点才复制。如果接入层不做Snooping，交换机会把组播报文当广播处理，泛洪到所有端口——不但没省带宽，反而把不看直播的电脑也一起拖下水。当天有个财务同事跟我抱怨"我没看直播啊，我的电脑怎么也卡"，就是这个原因。
结论：组播配错，比不配还糟。这一条我在摄行科技的方案评审会上讲过很多次，客户方IT经常拿"我们设备支持组播"当作已经解决，支持和启用是两回事。
整改动作：逐台接入交换机开启IGMP Snooping，配置Querier，验证方式是在非观看终端上抓包，看不到组播流即通过。
体检项三：QoS策略与直播流的优先级
检查方法：查看交换机QoS队列配置，确认直播流的DSCP标记是否被识别并映射到高优先级队列。
实测结果：直播流DSCP标记为0（默认），和普通网页浏览同级。而客户的VoIP电话被标了EF，ERP系统被标了AF41，都排在直播前面。
问题在哪：一到整点，全厂的ERP在做数据同步，直播流被挤到最后。这就解释了为什么卡顿有明显的时间规律——每小时的第0到第8分钟最严重，客户之前一直以为是"网络玄学"。
结论：内网直播卡顿在时间上呈现规律性，几乎一定是QoS或者定时任务的问题，不用怀疑物理链路。
整改动作：把直播流标记为AF31或AF32，优先级高于普通数据、低于语音。别贪心标EF，抢了电话的资源，另一批人要来找你。
体检项四：无线覆盖与终端漫游
车间办公楼有相当一部分人用平板和手机看。我们扫了一遍无线环境：单AP最高挂载67个终端，2.4G频段信噪比只有12dB，隔壁还有三个邻居SSID同频。
无线这块的整改成本最低但见效最快：强制5G优先接入、关掉低速率协商（把1M、2M、5.5M、11M全禁掉）、单AP负载超过40个终端就分流。做完这三步，无线端的卡顿投诉减少了八成以上。
企业内网做直播和直接用公开平台的差别到底在哪，我在企业内训直播为什么不能直接用公开平台那篇里从合规和链路两个角度都算过账。如果是多点位同时铺开的场景，银行网点培训的千点位同步直播那个项目的分级分发结构可以直接参考。
整改优先级排序
体检完我们给客户排了个顺序，成本从低到高：
| 优先级 | 动作 | 成本 | 见效周期 |
|---|---|---|---|
| P0 | 接入层开启IGMP Snooping | 0元，配置即可 | 当天 |
| P0 | 直播流DSCP标记为AF31 | 0元，配置即可 | 当天 |
| P0 | 无线禁用低速率、5G优先 | 0元，配置即可 | 当天 |
| P1 | 直播码率从3.8降到2.2Mbps | 0元，画质略降 | 当天 |
| P2 | 接入层上联扩万兆 | 约6.4万元 | 三周 |
| P2 | 增补AP，单AP负载降到40以下 | 约2.8万元 | 两周 |
P0三条做完，客户第二周的全员大会直播零投诉，压根没等到P2的采购落地。这也是摄行科技一贯的建议：内网直播卡顿先做配置层，别一上来就谈扩容，八成的问题在配置里。
首帧打开慢和播放中途卡是两码事，前者的优化路径完全不同，具体可以看直播首帧秒开是怎么做出来的。
顺带说说终端侧的三个小动作
体检报告交付之后，客户IT又追问了一句："员工那边有没有什么能自己做的？"确实有几个动作成本为零。
一是让观看者优先用浏览器而不是各种客户端。很多企业IM内置的播放器为了兼容做了额外的转封装，实测同一路流在内置播放器里的缓冲次数是浏览器直开的2.3倍。
二是提前十分钟打开播放页面。直播开始那一瞬间几百人同时握手，接入层的ARP表和会话表会有一波抖动，提前进场能把这个尖峰摊平。摄行科技现在给客户的观看通知里都会写上"建议提前十分钟进入"，一句话的事，效果比很多技术优化都直接。
三是集中观看优于分散观看。同一个办公室里五个人各开一个窗口，等于五份流量；改成投到会议室大屏一起看，流量降到五分之一，效果还更好。这条在车间办公楼特别管用，因为那边本来就有集中开班前会的习惯，顺势而为不用额外推动。
一句实在话
企业内网的复杂度经常被低估。它不像公网有成熟的CDN托底，出了问题只能自己扛；它又背着ERP、监控、语音一堆业务，直播只是插班生。
做内网直播，与其寄希望于"带宽够大就没事"，不如老老实实做一次拓扑体检。相关的网络技术规范可以查中国通信标准化协会的公开文件，涉及内容播出的合规要求在国家广播电视总局官网也能找到对应依据。
如果你们厂区或者园区正被内网直播卡顿折磨，把网络拓扑图和一次卡顿时段的时间点发给摄行科技，我们可以免费出一份体检清单和整改优先级表，先做零成本的那几项，效果不好再谈别的。
#摄行科技
