晚高峰课堂卡顿，第一件事不是重启路由器，而是先确认是不是遭遇了攻击绝大多数情况下你只是赶上了带宽拥堵，但排查顺序错了会浪费宝贵的课堂时间。
做过在线教育的朋友都有体会：晚上八点前后，学生上线率最高，平台压力最大，卡顿、延迟、掉线集中爆发，这个时间点太特殊了，既是晚高峰，也是攻击者最喜欢挑的时段，但说实话，真正被打的其实是少数，多数是网络拥堵和服务器性能不足，不先排除攻击，后面的优化动作可能全是白费。
晚高峰课堂卡顿，为什么先排查是不是遭遇了攻击
晚高峰课堂卡顿是什么原因？这是每个网课运营者都问过的问题，在晚高峰这个时间点，流量特征极其复杂：学生端家庭网络忙、云端带宽满、服务器负载高这些正常因素已经够让人头疼了，但如果这个时候混入恶意流量，问题会瞬间恶化，而且常规手段根本压不住。
晚间八点到十点为什么是攻击高发期？业内专家指出，攻击者倾向于在这个时段动手，因为此时业务处于最繁忙状态，防御方投鼠忌器，不敢轻易断开服务或重启系统，攻击效果被放大，对于机构来说，这个时段如果判断失误，把攻击当成普通卡顿来处理，后果很直接：
- 继续加带宽,结果攻击流量也跟着吃满资源，白花钱
- 反复重启服务,正常学生被反复踢下线，口碑崩坏
- 临时切备份节点,如果攻击面没堵住，新节点也会被打垮
所以步骤反过来了：先花两分钟确认有没有攻击痕迹，再决定走哪条排查路径，这就像去医院，先做分诊，再挂科室，而不是一进门就找专家号。
晚高峰卡顿和遭攻击的核心区别在哪里
正常拥堵和恶意攻击,表象相似，但底子完全不同，判断的关键看两点：流量曲线的平滑度和连接数的构成。
先看流量曲线,正常情况下，晚高峰流量是缓慢爬坡的，像潮水涨起来，有起伏但总体平滑，如果你打开流量监控面板，发现流量波形图上突然出现垂直拉升，从几百兆直接跳几G，而且十几分钟不回落，这大概率不正常。
再看连接数构成,普通用户的连接比较单一：一个人上课，建立两三个连接就够了，但如果服务器上出现大量来自同一IP段、成千上万个并发连接，而且每个连接的持续时间极短，这就不像正常上课的学生，依据行业共识，异常连接的共性包括源地址集中、连接频率过高、请求粒度碎。
如何判断服务器是否被攻击：先看三个关键指标
判断服务器是否被攻击,不需要复杂工具，服务器终端跑几条命令就能看出大概，我建议按下面的顺序来看。
第一步：看连接数总量和来源分布
在服务器上执行：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20
这条命令会把当前所有外部连接按来源IP聚合,排序列出前20个，正常情况下，晚高峰的IP分布应该是分散的，来自全国各个城市，每个IP的连接数在个位数到十位数之间，如果看到某个IP的计数达到几百甚至上千，这就是明显异常。
再看TIME_WAIT状态的数量：
netstat -nt | grep TIME_WAIT | wc -l
高连接数本身还不一定致命,但如果TIME_WAIT数量异常飙升，说明有大量短连接在快速建立和释放，这是典型的扫描或攻击特征。
第二步：看带宽占用和CPU负载的匹配度
攻击流量有个显著特点：带宽被打满，但服务器CPU内存的消耗不匹配。
你自己感受一下：如果是正常直播课堂，带宽和CPU是同步上升的，因为视频编解码和推流都需要计算资源，如果带宽出口已经跑满了，但top命令一看，CPU才用了三成，nginx进程占用也不高，那说明流量多半是垃圾包，根本不经过业务逻辑，直接打在网络层。
再配合iftop看实时流量：
iftop -i eth0 -n -B
观察流量是不是被单一几个IP占走大部分带宽,正常晚高峰哪怕学生再多，流量分布也不会极端集中。
第三步：看和机房互通的延迟和丢包
攻击往往伴随ICMP洪水或TCP SYN洪水，用mtr或ping测一下到机房的延迟：
mtr -rw www.yourdomain.com
如果丢包率超过百分之十且集中在某一跳,而且你的源IP是固定的，那基本可以确认链路被打了，但注意，学生上课用的是家庭宽带，他们测出来的丢包可能是自己局域网或运营商线路的问题，这里需要区分清楚。
直播课卡顿怎么排查：从流量特征到具体动作
如果上面三条命令查完,没有明显异常，那就进入常规的网络拥塞排查流程，直播课卡顿怎么排查也有固定套路，按优先级来。
先查出口带宽和CDN命中率
很多教育机构只有单线BGP带宽,晚高峰开通多个教室同时上课，出口带宽被占满就全体卡顿，这个数据你在云厂商控制台的监控图表里能直接看到，看带宽使用率是否持续超过百分之八十。
然后是CDN命中率,视频课件、讲义图片这些静态资源，如果命中率在九成以下，说明大量请求回源了，源站带宽压力陡增，学生加载课件就会慢，看CDN服务商的统计报表，低于九成要调缓存策略。
再查学生家庭网络的共性因素
如果服务器端和网络链路都没问题,卡顿可能出在学生侧，常见情况是：同一小区大量学生晚上同时在线，造成局部网络拥塞，还有智能电视、手机、监控摄像头抢占家庭宽带的带宽，这类问题表现为少数学生频繁卡顿，但老师端和其他学生不受影响，后台逐个查被卡学生的所在地区和运营商信息，看是不是集中在特定区域。
配合课堂端的实时状态做交叉验证
单纯看服务器不够,还要看客户端上报的体验数据，比如音视频延迟、丢帧率、上行码率，如果整个教室里大家的丢帧率普遍升高，那是平台问题；如果是某几个学生持续高延迟，那是个体网络问题，这种多维度交叉对比，能快速缩小故障范围。
确认遭遇攻击后，课堂服务器防御方案要分层
如果排查之后确认是攻击行为,别慌，但动作要果断，课堂服务器防御方案分三层：
- 接入层清洗：联系IDC或云厂商，开启DDoS高防IP，把攻击流量引到清洗节点，只放行正常业务流量，这个要在攻击早期做，晚了源站IP可能被打死，恢复就慢了。
- 应用层防护：如果攻击打的是Web应用或信令服务器，比如CC攻击，开启WAF，配置频率限制规则，封禁异常UA和单个IP的并发连接数。
- 业务层冗余：准备一个小容量备用节点，主节点被打时能把信令服务和课件服务切过去，很多机构栽在“只有一个节点”上，没有后路可言。
防御思路不用搞多复杂,核心就是“别让源站IP直接裸奔”，用高防产品或CDN回源中转把真实IP藏起来，攻击者找不到你的源站，攻击面就小了一半以上。
晚高峰课堂卡顿的完整排查清单
最后给一份可以直接照着做的清单,按顺序执行，每步控制在1-2分钟内：
- 查看服务器连接数Top20来源,观察是否有集中刷连接行为
- 对比带宽曲线和CPU曲线,判断流量是否绕过业务逻辑
- 用mtr测试对外链路质量,确认是否存在异常丢包
- 检查出口带宽使用率是否超过百分之八十
- 查看CDN命中率是否低于九成
- 随机抽样三个异常学生,对比他们的区域和运营商分布
- 查看信令服务器上的房间连接数,确认是否超出单房间承载上限
整个排查流程耗时不超过十分钟，但这十分钟决定了你在晚高峰里是能快速恢复课堂，还是陷入被动，卡顿本身不是末日，判断错方向才是。
晚高峰课堂卡顿是什么原因大多数时候答案是“正常拥堵”，但先花两分钟排除攻击，再谈带宽扩容和架构优化，能让你少走很多弯路。
关于晚高峰课堂卡顿的常见问题
学生端测速很快但上课还是卡，怎么回事
测速看的是带宽大小,但上课实时性看的是延迟、抖动和丢包率，高峰期家庭宽带的上行带宽容易被占用，如果测速没测上行，就发现不了瓶颈，另外无线信号干扰、路由器老旧也会增加抖动，让学生用网线直连光猫再试一节课，多数问题就清楚了。
机构的服务器在本地还是云端对防攻击有影响吗
有影响,本地机房带宽冗余有限，攻击来了扩容空间小，云上服务器可以较快调整带宽上限和迁移IP，不过云环境也要把安全组配置好，只放行业务端口，减少暴露面，判断服务器是否被攻击的方法是一致的，各平台都自带监控工具，直接用即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792019.html
