Portal 认证系统解决的是谁能上网，但上网之后还有一件事同样重要：带宽怎么分。如果所有流量一视同仁地抢，就会出现客人刷视频把收银系统的带宽挤掉，或者个别用户跑满带宽让其他人连网页都打不开。带宽分级要解决的正是这个优先级问题。它和认证不是替代关系，认证确认身份，分级决定这个身份能拿到多少资源、排在什么位置。
先把流量按用途拆开
做分级之前，要先梳理网络里到底有几种用途的流量。以门店场景为例，至少有四类：收银和交易类、监控调阅类、员工办公类、顾客上网类。这四类的重要性差别很大，收银断了直接影响生意，顾客网速慢一点只是体验差一些。梳理的时候要和业务方一起确认，不能技术侧自己拍脑袋，因为不同行业的关键业务不一样，医院、学校、工厂的关键业务各不相同。
关键业务要预留并且优先
分级的第一层是给关键业务预留带宽，并且把它的优先级提到最高。预留的意思是这部分带宽即使在其他流量跑满的情况下也能保住，不会被挤占。具体做法是在流控策略里为关键业务的地址段或者应用类型配置保障带宽和高优先级。这里有个容易忽略的点：预留值要按实际业务量来定，拍脑袋留得太大浪费带宽，留得太小关键时刻还是不够，需要看一段实际运行数据再调。
顾客类流量要限制总量
分级的核心是防止非关键流量无节制扩张。顾客上网这类流量，应该限制一个总的使用带宽，并把它放在较低的优先级上。这样即使客人集中刷视频，也不会越过这条线去挤占关键业务。总限额定多少，取决于出口带宽减去关键业务预留之后还剩多少，同时要留一定的冗余应对突发。定完之后要观察实际使用曲线，如果长期顶着上限跑，说明该扩容或者该调整分配比例了。
每用户还要单独限制
只限制总量会有个问题：总量之内，少数几个用户就能把带宽占满，其他人分到的很少，体验一样很差，而且这种情况在投诉里体现为网络时快时慢，很难解释。所以还要加一层每用户限制，让每个在线用户拿到的带宽大致相同。这一层的价值不在于省带宽，而在于公平性，它决定了同样一笔网费，用户之间的体验不会差太多。
优先级不等于没有上限
给关键业务最高优先级，不代表它可以无限使用带宽。如果关键业务出现异常流量，比如监控设备反复重传、或者配置错误导致流量翻倍，没有上限的话它会把整个出口吃掉，反而造成全面故障。所以即使是最关键的那一类，也应该设一个合理的上限，只是这个上限要明显高于它的正常用量，留给突发空间，同时防止它失控拖垮全网。
分级策略要跟着时段变
很多场所在不同时段的业务重点是不一样的。营业高峰时，交易和排队系统最重要；闭店之后，可能是数据同步和备份在跑，顾客流量几乎为零。如果策略全天不变，就会在高峰期浪费带宽给低优先级流量，或者在非高峰期限制了本来可以跑满的同步任务。比较合理的做法是按时段切换策略模板，把时段划分和业务节奏对上，而不是一套策略跑到底。
分级要靠真实业务验证
带宽分级配完之后，不能只用一个测速软件跑个数字就算验证通过。真正的验证是用真实业务去压：在关键业务运行的同时，让多个终端同时跑大流量，看关键业务的实际表现有没有受影响，看每用户限速是否真的把速度拉平。这种测试要在业务低峰期做，并且提前通知相关人员，避免被误当成真实故障。验证结果要记录，作为后续调整策略的基线。
分级策略要和认证身份绑定
带宽分级要真正生效，还要和认证身份绑起来。用户认证之后属于哪个用户组、拿到哪个套餐，决定了他适用哪一套带宽策略。员工组和顾客组的策略不同，不同套餐的用户策略也可能不同。这层绑定关系要在用户组和套餐的配置阶段就理清楚，不能等到上线之后发现某类用户拿错了策略再逐个调整。业务上每增加一种新的用户类型，就要同步确认它的带宽策略归属，漏配的话这类用户会落到默认策略上。
两个最常见的配置偏差
配置带宽分级时有两类偏差反复出现。第一类是只设了总带宽、没设每用户限制，结果高峰期少数用户占满带宽，其他人体验很差，而总带宽看起来还挺富裕。第二类是每用户限制设得太小，正常的应用都跑不动，用户会反馈网速慢，但看总量又远没到上限。判断该设多少，要看实际用量分布而不是拍脑袋：统计一段时间里用户的实际带宽占用，看中位数和长尾分别在哪，再据此定每用户的上限。