机房管理员最怕的一种下午,是上课铃响完三分钟,任课老师站在讲台前反复点"开始广播",底下一半学生机毫无反应,另一半黑屏卡住。学生在下面窃窃私语,老师在台上手忙脚乱,而你被电话叫过去的时候,离下课只剩三十五分钟。这类事故九成不是软件坏了,而是教师学生机系统这套东西从部署那天起就没被真正摸透过——它被当成一个"装完就能用"的工具,实际上它是一个横跨网络、操作系统、硬件保护卡和课堂流程的完整体系。

SULONG 这套教师学生机系统就是典型代表。它的核心职责很明确:把几十台学生机变成老师可以统一调度的一间教室,屏幕广播、监控、文件分发、作业收取、锁屏管控、上机考试,这些动作全都建立在"教师端发指令、学生端执行、网络承载流量"这条链路上。适合读这篇的人有三类:接手机房但没受过培训的新管理员、想把机房课真正上出效果的任课老师、以及需要给机房做选型和验收的技术负责人。下面我按部署、调优、实战、排障的顺序,把我在实际机房里踩出来的东西摊开讲。

1. 教师机与学生机的职责边界:先搞清楚谁在干活

1.1 这不是主从关系,而是"指挥端 + 执行端 + 心跳"

很多人第一次接触这套系统,会下意识把它理解成远程桌面:老师这边点一下,学生那边被操控。这个理解会直接导致后面所有排障都跑偏。真实结构是三层:教师端负责发起动作和聚合状态,学生端是一个常驻服务,负责接收指令、执行本地操作、并定时向教师端上报心跳;中间还有一层是网络承载,广播类动作走组播,文件类动作走单播。

三层里最容易出问题的是中间那层,因为它不显眼。教师端界面显示"在线 48 台",这个"在线"其实只是心跳包收到了,不代表广播流量能到;反过来,学生机能收到广播,心跳却可能因为防火墙规则被拦。我见过不止一次,管理员盯着教师端列表说"都绿着呢",结果一广播还是大面积黑屏——绿色的只是心跳,不是通道。

所以接手一套新系统,第一件事不是研究功能菜单,而是画一张链路图:教师端 IP 是多少、学生端 IP 段是多少、中间经过几台接入交换机、有没有跨网段、有没有防火墙。这张图画完,后面八成的问题都能在图上指出位置。

1.2 课堂动作拆成四条数据流,排障才有抓手

把所有功能按数据流归类,比按菜单归类有用得多。我习惯分成四类:

这么一分,排障思路立刻清晰:黑屏是实时流出问题,列表不刷新是状态流出问题,分发失败是文件流出问题,远程协助点不动是控制流出问题。这四类的病因几乎不重叠,先定位到流,再顺着流找节点,比盲猜软件 bug 高效得多。

1.3 验收时最该先问的三个问题

如果你是采购方或者验收方,别急着看功能演示。功能演示永远在最理想的网络里做,一台交换机、二十台机器、网线全新。我建议先问三个问题:

• 这套系统的广播是组播还是单播,如果接入交换机不支持 IGMP Snooping,你们怎么处理?
• 学生端安装包能否静默部署,有没有命令行参数,能不能和还原卡共存?
• 分发出错时的日志在哪里,是教师端本地文件还是学生端本地文件,保留多久?

这三个问题一抛出去,对方是做过真机房还是只做过演示厅,基本就露底了。尤其是第一个,组播这块能不能讲清楚,决定了后续三年你会不会天天被广播卡顿折磨。

2. 网络底座:广播跑不跑得稳,八成败在交换机上

2.1 组播为什么是屏幕广播的默认选择

先算一笔账。教师端 1920×1080 的画面,压缩后一帧大概 30 到 60KB,按 12 帧每秒算,单台学生机需要 0.4 到 0.7MB/s,也就是 3 到 6Mbps。如果用单播,50 台学生机就是 150 到 300Mbps,虽然有千兆上行顶着,但教师机的网卡、CPU 和交换机的上行口会同时吃紧,而且每加十台机器,压力线性上涨。

换成组播,教师端只发一份流量,由交换机在需要的位置复制,教师机出口带宽恒定在 5Mbps 左右,加机器不加负担。这就是为什么几乎所有教学广播系统都把组播当默认答案。代价是组播对网络配置有要求,配不好就退化甚至直接不通。

关键的一条:接入交换机必须开启 IGMP Snooping。不开的话,组播帧会被当成广播帧在 VLAN 内泛洪,几十台机器的接入层瞬间被打满,表现就是"一广播,整间教室网络全卡,连上网都慢"。开了之后,交换机会记录哪些端口有成员加入,只往那些端口转发。这一步没做,后面调什么参数都是白费。

还有一个坑:很多机房为了防环路、防私接,在接入交换机上开了端口隔离。端口隔离会让同一交换机下的学生机互相不可见,而组播成员关系有时候依赖这种互通性,结果就是广播只有部分机器收到。遇到这种情况,得把教师端所在端口设为隔离组的上联口,或者在隔离策略里放行组播地址段。

2.2 IP 规划与分组标签的实际划法

我推荐按"楼栋-楼层-机房-机位"四段来编,不要图省事用 DHCP 随机分。原因很实在:学生端是以 IP 或 MAC 标识身份的,IP 一变,教师端的座位表就全乱,分组、考勤、作业归属都得重来。

一个可落地的划法是这样:

192.168.10.0/24 一号机房 教师端 .10 学生机 .101-.160 192.168.11.0/24 二号机房 教师端 .10 学生机 .101-.160 172.16.20.0/24 多媒体教室 教师端 .10 学生机 .101-.140

机位号直接映射到 IP 末位,学生机 101 号就是第 1 排第 1 座,教师端座位表一眼能对上。这个习惯看着土,但排障时价值巨大——你说"37 号机广播黑屏",同事立刻知道该去哪个位置拔网线。

组播地址也要规划。教学广播常用的私有组播段是 239.0.0.0/8 这一块,建议按机房分配,比如一号机房用 239.1.1.x,二号机房用 239.1.2.x,避免跨机房串流。有些系统允许在配置里指定组播起始地址和端口,改之前先确认交换机有没有做组播组的静态过滤,否则改完直接不通。

2.3 学生端安装:静默参数与还原卡的配合

几十上百台机器手工点下一步,是不现实的。学生端安装包一般支持静默安装,常见形式是带/S或/silent参数,配合指定教师端地址的参数。具体参数名各版本不同,别照抄,先在两台机器上验证:

@echo off REM 示例:静默安装并预置教师端地址与机房分组 StudentClient_Setup.exe /S /SERVER=192.168.10.10 /GROUP="Room-01" /PORT=8000

比安装更麻烦的是还原卡。机房普遍装了硬盘保护,学生机一重启就回到初始状态,你辛苦配好的教师端地址、分组、机器名全没了。处理方式有三种,按可靠性排序:

1. 在保护状态下配置,然后提交保存——最稳。进保护卡的维护模式,把学生端装好、参数配好、注册表写完,再把这层状态设为基线。
2. 把配置项写到非保护分区——部分保护卡支持划一个"专属分区"或"数据盘"不还原,把配置文件放那里,学生端启动时读取。
3. 每次开机由脚本自动写入——最不优雅但最通用,开机脚本里判断配置是否存在,不存在就从共享目录拉一份。

第三种方案我用了很多年,因为它对保护卡型号不挑。代价是每次开机多花三五秒,但如果脚本写得干净,学生根本感知不到:

@echo off if exist "C:\ProgramData\SULONG\client.ini" goto :eof copy /Y "\\192.168.10.10\deploy\client.ini" "C:\ProgramData\SULONG\client.ini" net stop SULONGClient net start SULONGClient

这里有个细节值得强调:脚本里net stop和net start之间的间隔,部分机器上服务没完全停下来就重启会报错。加一句timeout /t 2 /nobreak >nul能省掉大量莫名其妙的"服务启动失败"。这种小坑文档里不会写,只能自己撞。

3. 屏幕广播与监控:把"卡不卡"拆成三个可调旋钮

3.1 卡顿的三种成因,先分清再动手

老师抱怨"广播卡",实际可能是完全不同的三件事,处理方式也完全不同。

第一种是画面卡成幻灯片但声音正常。帧率掉到个位数,通常是教师端编码能力不够或者组播丢包。查法很简单:在教师端看广播状态里的发送帧率和丢包计数,如果发送帧率本身就低,是编码问题,降低分辨率或换压缩档位;如果发送正常但学生端丢包,是网络问题。

第二种是画面正常但鼠标延迟明显。这是控制流和实时流走了不同路径,控制指令被网络延迟拖慢。多见于跨网段或者经过三层设备的环境。

第三种是开头几秒正常,半分钟后逐渐卡死。这个最典型,八成是交换机 MAC 地址表或组播表溢出,或者是学生端缓冲区堆积。前者要查交换机日志,后者要重启学生端服务验证。

我建议在机房里做一个"基准测试"习惯:每学期开学前,选三台机器(离教师端最近的、最远的、中间位置),跑一次十分钟的连续广播,记下帧率和丢包。有基线,后面出问题才有对比。

3.2 分辨率、帧率、压缩档位怎么配

这三个参数是互相拉扯的。分辨率决定单帧大小,帧率决定每秒发多少帧,压缩档位决定单帧能压到多小但会牺牲画质和 CPU。

代码演示为什么可以压到 8fps?因为屏幕内容大部分时间不变,变化区域少,人眼对静态文字的帧率不敏感。而设计类演示要看渐变、看色彩过渡,压缩太狠会出色块,老师一眼就能看出来"颜色不对",那就得把档位调低。

这里有个反直觉的经验:不要盲目追求 1080p。如果机房显示器就是 1920×1080,广播源用 1600×900 拉伸显示,画质损失其实很小,但带宽能省三成。真正需要满分辨率的场景是精细文字和 CAD 线条,普通课件演示完全没必要。

另一个常被忽略的参数是色深。把 32 位色降到 16 位,单帧体积能降 20% 到 30%,代价是渐变色可能出现色带。教学场景里,除了美术课和视频课,16 位色基本看不出差别,这是个很划算的交换。

3.3 监控墙:别让教师端自己先卡死

监控功能是把所有学生机画面缩略显示在教师端。听起来轻量,实际是教师端最吃资源的功能。50 台机器,每台每秒回传一到两帧缩略图,教师端要同时解码并绘制 50 个画面,CPU 占用轻松上 60%。

几个实测有效的控制手段:

• 降低监控帧率。缩略图不需要流畅,1 到 2 fps 完全够用来判断"这个学生在干什么"。把监控帧率从默认的 5fps 降到 1fps,教师端 CPU 占用能掉一半以上。
• 缩小缩略图尺寸。128×72 的缩略图足够看清是在写代码还是开了网页,不需要 320×180。
• 分组轮巡替代全量监控。50 台同时看,不如分 5 组,每组 10 台轮着看,每 30 秒换一组。老师的注意力本来也覆盖不了 50 个画面。
• 关闭监控的"实时刷新"开关。有些版本有"仅在被控端画面变化时刷新"的选项,打开后静态画面的机器几乎不产生流量。

我遇到过一次教师端监控一开就卡死的情况,排查半天发现是教师机显卡驱动太老,50 路缩略图同时绘制触发了驱动的某个 bug。换驱动解决。所以教师机的配置不能太寒酸,它是整套系统里负载最重的一台,别拿淘汰的办公机凑数。

4. 文件分发与作业收取:做成流水线才叫真省事

4.1 分发通道选型:看文件大小说话

小文件走单播就行,几十 KB 的配置文件、几 MB 的素材包,单播并发五十台也就几秒钟的事。大文件就必须考虑策略了,一个 2GB 的虚拟机镜像,单播并发五十台,教师机上行口直接被压满,同时段所有课堂动作全部卡住。

三种常见策略的取舍:

组播分发大文件理论上最优,但它有个硬伤:没有可靠重传。丢一个包,那台机器上的文件就废了,而且系统未必能立刻发现。所以在丢包率高的环境里,组播分发完必须做一次校验,比如对比文件大小和 MD5。

我自己机房里的做法是分层:小于 100MB 直接单播并发,100MB 到 1GB 单播但开限速(教师端限到 200Mbps),超过 1GB 就走组播加事后校验。这个分界线不是拍脑袋,是实测出来的——200Mbps 的上行限速下,50 台机器收 1GB 文件大约 4 分钟,和老师课间休息时间刚好对得上。

4.2 作业目录与命名规则,比工具本身更重要

作业收取功能做得好不好,一半看软件,一半看规则。我见过太多机房,收上来的作业是这样的:作业.docx、作业(1).docx、新建文件夹(3)。老师打开一看,根本不知道谁是谁的。

规则必须在开学第一节课就定死,并且写进学生端的默认保存路径。我的做法是:

\\192.168.10.10\Homework\2024秋-程序设计\第03周\ └── 20230101_张三_第03周作业\ ├── main.py └── report.pdf

路径里带学号、姓名、周次,学生端在收取时自动按规则生成目录。有些系统支持"收取时按学生账号建目录",这个功能一定要开,不要依赖学生自觉。

再补一条实战经验:作业目录必须和教师端的分发目录物理隔离。学生端如果对作业目录有写权限,同时对分发目录也有写权限,那迟早会出事故——某次一个学生误操作,把整个分发目录删了,第二天上课所有素材全没。现在我都是两个独立共享,作业目录给学生只写不改,分发目录对学生只读。

4.3 限速与大文件:几个实测数值

限速这块没有绝对标准,取决于你的教师机网卡和上行带宽。给一组我实测过的参考:

• 千兆教师机,上行百兆交换机:分发放到 80Mbps 比较稳,再高会挤占广播带宽。
• 千兆教师机,上行千兆交换机:分发放到 400Mbps 没问题,但广播正在跑的时候不要超过 250Mbps。
• 全千兆环境:分发放到 600Mbps,注意教师机磁盘 IO 往往先成为瓶颈。

磁盘 IO 这点容易被忽略。教师机如果是机械硬盘,同时读一个大文件分发给五十台,磁头反复寻道,实际吞吐可能只有 80MB/s,而且会拖慢整个系统响应。我的建议是教师机用 SSD,或者把常用分发素材提前放到 SSD 分区,这个投入比升级交换机便宜得多,收益也更直接。

5. 课堂管控的尺度:锁屏、禁网、远程协助怎么用不挨骂

5.1 三档管控强度与对应场景

管控功能是双刃剑。用得对,课堂秩序好;用过头,老师学生都烦。我把它分三档:

第一档,轻管控:只做屏幕广播和举手,不禁网不锁屏。适合高年级、自主性强的课,比如毕业设计指导。老师需要的是"能喊一声让所有人看屏幕",不需要控制。

第二档,中管控:禁网(只允许访问校内资源)+ 应用白名单。适合需要专注的上机练习,比如编程实训。学生能查校内文档,但打不开游戏和视频。

第三档,强管控:锁屏 + 全面禁网。只在考试和集中讲授时用。锁定之后学生机只有广播画面,连本地文件都动不了。

关键是档位要能随时切换,而且要提前告知。最忌讳的是老师上课上到一半突然锁屏,学生正在写的代码没保存。我建议在教室门口贴一张纸,写明"本节课管控档位",这个土办法比任何技术手段都管用。

5.2 远程协助的完整链路与失败点

远程协助是老师最喜欢的功能:某学生举手说"我这儿报错了",老师在自己机上点一下,直接接管那台学生机的鼠标键盘,当场演示一遍。链路是:教师端发起连接请求 → 学生端服务接受 → 建立控制通道 → 教师端把键鼠事件发过去 → 学生端执行并回传画面。

失败点集中在三处:

第一处,学生端服务没在跑。表现是点了没反应,或者提示"无法连接"。查法是到那台机器上services.msc看服务状态,或者用命令行:

sc query SULONGClient tasklist | findstr /i "student"

第二处,防火墙拦了控制端口。心跳用的是小包,可能已经从某个已放行的端口出去了,但控制通道用的是另一个端口,被入站规则拦掉。这种情况表现为"在线但连不上",非常迷惑。

第三处,远程协助和还原卡冲突。有些保护卡在远程操作时会拦截键鼠注入,或者操作完一重启全白干。这个只能靠提前测试,把常用软件装好再打基线。

5.3 管控误伤的补救手段

管控出岔子的场景很多:锁屏之后老师发现讲错了要放开、禁网之后发现某个教学网站被误拦、广播中断之后学生机停在黑屏状态不动。这些都需要一键恢复的能力。

我建议在教师端预设几个"急救"操作并练熟:全部解锁、全部恢复网络、强制刷新学生端连接、重启学生端服务。最后这个尤其重要,它能解决八成"状态卡住"的问题,而且不用跑到学生机跟前。

还有一个细节:学生端如果在黑屏状态下被强制重启服务,可能会一直停在黑屏。这时候需要"取消广播"的指令先发一次,再重新发起。这个操作顺序不能反,反了就是白屏继续挂着。这类顺序性的坑,只能靠一次次踩出来记在本子上。

6. 上机考试周:从环境快照到收卷还原的完整流程

6.1 考前:做一份能回滚的环境基线

考试环境和平时上课环境必须物理隔离,至少是逻辑隔离。我的做法是准备两套基线:一套"上课基线",装了各种工具软件;一套"考试基线",干净系统加考试客户端。

制作基线的步骤:

1. 在一台学生机上装好系统、驱动、考试客户端、输入法,不装任何娱乐软件。
2. 把这个状态提交为还原卡的基线。
3. 逐台机器做一致性检查:机器名、IP、学生端配置、系统时间,四项必须全部正确。系统时间不一致会导致考试系统时间戳错乱,这个坑很隐蔽。
4. 用教师端的文件分发把基线之外的补充文件推送到全部机器。

一致性检查可以写成脚本批量跑:

@echo off for /f "tokens=2 delims=:" %%a in ('ipconfig ^| findstr /i "IPv4"') do echo IP:%%a echo Computer: %COMPUTERNAME% echo Time: %DATE% %TIME% w32tm /query /status | findstr /i "Source"

把每台机器的输出收集起来,一眼能看出哪台不对。

6.2 考中:断线、断电、误操作的三套预案

考试过程中最怕三件事。断线:学生机心跳掉了,教师端显示离线,但学生还在答题。这时候不能慌着重启,先看那台机器的本地考试客户端是否还在正常计时,大多数客户端支持断线续答。通电:某台机器突然重启,如果还原卡生效,考试成绩可能丢了。所以考试期间必须关闭还原,或者把考试目录设在非还原分区。误操作:学生不小心关掉了客户端,这时候教师端一般有"重新拉起"的功能。

我建议考试前做一次"破坏性演练":故意拔一台机器的网线,看客户端怎么表现;故意重启一台,看数据有没有留住。演练过和没演练过,考场上的心态完全不一样。

6.3 考后:收卷校验与还原顺序

收卷不是点一下"收取作业"就完事。收完之后必须做三件事:校验数量、校验完整性、校验归属。

数量上,收了 47 份但应考 50 人,少的 3 个人是谁,当场就要问清楚。完整性上,有的客户端崩溃会留下 0 字节文件,这种要单独标记。归属上,文件名里没有学号的,要对照座位表人工补。

三件事做完才能还原环境。还原的顺序也很讲究:先还原学生机,再还原教师端,最后清空作业缓存。反过来做,一旦学生机还原失败,你连证据都没了。还原之后抽查三台机器,确认能正常启动、能连上教师端,才算收工。

7. 五个高频故障的完整排查链路

7.1 学生机"显示在线"却收不到广播

这是最常见的报障。列表绿的,广播黑屏。排查按这个顺序走,基本十分钟内能定位:

第一步,确认是单台还是多台。单台的话,八成是那台机器的网卡或驱动问题,直接去机器上看。多台的话,看是不是集中在同一台交换机下——如果是,问题在交换机。

第二步,在问题机器上验证组播能不能收到。用系统自带的ping试组播地址:

ping 239.1.1.10 -t

能 ping 通不代表能收流,但 ping 不通基本可以确定组播路径断了。

第三步,登交换机看组播组表。重点看问题端口有没有加入组播组,以及 IGMP Snooping 是不是真的开着。我遇到过一次,Snooping 开着但交换机重启后配置丢失,所有人都以为还开着。

第四步,查学生端防火墙。广播接收端口如果没在入站规则里,包到了本地也被丢掉。这一步最容易漏,因为心跳端口和广播端口往往不是同一个。

第五步,查教师端的分组。有些系统按分组下发组播组地址,学生机如果被分到了错误的分组,压根就监听不到那个地址。

7.2 教师端监控全是灰屏

灰屏说明学生端画面回传链路断了,但心跳还在。这个组合很典型,指向"状态流通、画面流不通"。

我先查教师端的解码线程有没有满载。打开任务管理器看 CPU,如果教师端自己就已经 90% 以上,那不是学生端的问题,是教师机扛不住,先降监控帧率。

如果教师机很闲,就查学生端的画面采集。部分系统在学生端用镜像驱动或者桌面复制接口抓屏,显卡驱动更新后接口变了,抓屏就失败。表现正是心跳正常、画面空白。这种情况换回旧版驱动,或者在系统设置里切换抓屏方式,一般能解决。

还有一种少见但恶心的情况:学生机同时登录了两个用户(快速用户切换),抓屏抓到了锁屏的那个会话。禁用快速用户切换就行。

7.3 还原卡一重启,配置就回到从前

这个坑我至少遇到五次,每次都是新接手的机房。根因永远是"配置写在被保护的分区里"。

排查链路:先确认还原卡的工作模式,是"每次还原"还是"每次不还原",还是"手动还原"。然后确认学生端配置文件的路径,是否在 C 盘。如果都在 C 盘且 C 盘受保护,那就必然丢。

解决有三种,前面第 2.3 节讲过:提交基线和配置、写到非保护区、开机脚本自动写入。我推荐第三种作为兜底,因为前两种一旦换硬件或者换保护卡方案就失效了。

7.4 分发到一半批量超时

前几台成功,后面全部超时。这种情况优先怀疑限速和并发数。教师端的并发分发线程数如果设得太高(比如 50 台同时传),每台的速率被摊薄到极低,看起来就像超时。

调整步骤:把并发数降到 8 到 10,单台限速设到 20 到 30Mbps,总吞吐控制在教师机上行带宽的 60% 以内。这样总耗时反而更短,因为不再有大量重传和超时。

如果调整后还是超时,那就查网络。重点看交换机端口有没有跑满,以及有没有人在同时跑其他大流量业务。机房里最常见的是某个学生开了下载,把交换机上行占满了。

7.5 登录或心跳缓慢,教师端列表要等十几秒才刷新

列表刷新慢,本质是状态流的响应时间长。三个层面的原因:

网络层面,学生机数量超过教师端的连接处理能力,每台的心跳都要排队。这个可以调大心跳间隔,比如从 3 秒改到 10 秒,教师端压力立刻下降。

主机层面,教师端的防火墙或者安全软件在做深度包检测,每个心跳包都被检查一遍。这个在教师机上把教学系统的进程加入白名单就行。

系统层面,如果是域环境,学生端服务启动时要先做身份验证,验证超时会拖慢整个启动。这种情况把服务改成用本地账户运行,能省掉大部分等待。

这五个故障我列的都是从现象到节点的路径,不是直接给答案。因为机房环境千差万别,直接抄答案经常抄错。养成"先定位到哪条流,再顺着流找节点"的习惯,比记住十个具体解决方案有用。

最后分享一个我坚持了很多年的做法:给每个机房建一份变更记录,谁在什么时候改了什么配置、改之前是什么状态,全写进去。这套东西看着笨,但它救过我至少三次——一次是交换机配置被人还原了,靠记录半小时内恢复;一次是广播参数被调乱,靠记录对比出到底哪一项不对。机房这东西,稳定运行靠的从来不是记住所有细节,而是留下能回退的痕迹。