监控网络选百兆还是千兆，应计算每条链路实际经过的码流，尤其是多台摄像机共用的上联。不能按像素数套固定摄像机台数，也不能把“百兆只能用50Mb/s”当作所有交换机的规律。先列码流和访问路径，再留出合理余量，最后用真实业务验收。
摄像机产生码流，交换机转发报文
摄像机把图像编码为连续的视频数据，码率表示每秒产生多少比特。交换机通常不重新压缩视频，而是转发承载这些数据的以太网报文。因此所谓“计算交换机码率”，实际是在估算通过某个端口的业务流量，以及该出口是否能及时发送。录像存储需求与网络链路需求有关，却不完全相同，不能把录像文件大小直接当作所有链路的流量。
网络工程常用十进制单位：1000kb/s等于1Mb/s；把Mb/s换成MB/s则除以八。不要将千比特与千字节混用，也不要在没有说明的情况下统一按1024换算。统计界面可能采用不同显示方式，应核对单位和采样周期。同一份数据从不同工具读取时，先确认它们是在统计有效视频、协议报文还是端口总流量。
只相加经过被计算链路的业务
假设四台摄像机各有一路8Mb/s主码流发往录像机，它们共用的上联至少要承载约32Mb/s的视频数据，另加音频、协议和其它经过该链路的业务。这是教学示例，不是任何像素数必然对应的码率。单台摄像机的接入口只承担自身流量，四台摄像机共同使用的上联则承担汇总流量，两者不能使用同一个台数结论。
主码流和子码流不是在任何情况下都要机械相加。只有实际被请求、并且经过这一链路的流才应计入。如果维修电脑与摄像机在同一接入交换机，查看的子码流可能在本地转发，不经过录像机上联；若客户端位于上联另一侧，就需要计入。多个客户端各自请求单播视频，还可能产生多份相同内容的传输。组播是否能减少某段重复传输，取决于设备与网络配置，不能默认已经启用。
平均码率与峰值码率需要分别记录
视频数据量会受到编码方式、图像复杂度、运动、噪声、帧率及质量设置影响。同样分辨率的两台摄像机，码流不一定相同；同一台设备在安静画面与多人运动画面下也可能变化。H.265可能提高压缩效率，但不能承诺任何场景都比H.264恰好节省一半。应先阅读摄像机的码率控制说明，再用符合现场情况的画面观测。
可变码率允许数据量随画面变化；最大码率或平均码率控制有各自的质量与时间尺度取舍，具体行为按摄像机实现核对。只拿一分钟平均值规划，可能漏掉短时峰值。记录时还应覆盖夜间、复杂运动、事件录像和多人预览等状态，确认统计周期不会把关键突发平滑掉。不要通过无限降低码率换取表面流量合格，却让录像质量失去使用价值。
为何有余量，还会卡顿或丢帧
出口在每个时刻只能按链路速率发送。入口突然送来更多报文时，交换机暂存尚未发送的数据；突发结束后，空出的发送能力让队列逐渐缩短。如果流量持续大于出口容量，缓冲迟早耗尽，之后可能丢包。缓冲并不增加线路速率，QoS优先级也不凭空产生带宽，只是在拥塞时决定不同业务的处理顺序。
一个100Mb/s端口不是固定只有50%或70%可以使用。有效业务比例受到报文大小、协议开销、设备性能和测试方法影响，规划余量是工程选择，不能伪称硬件天生折半。先测实际流量和错误，再确定允许的持续利用率与突发空间；对关键控制或监控业务，余量应与业务可靠性目标相匹配，不能套用一个万能百分比。
从接入到录像机，逐段建立容量预算
先画摄像机、接入交换机、汇聚设备、录像机及客户端的连接关系，标出每条物理链路的方向和业务来源。对每个出口相加经过该处的并发码流，加入音频、管理及其它共享业务，再考虑协议开销、峰值和扩容。全双工链路两个方向有独立的发送能力，不能把一个方向的需求简单除以二；回放与上传并存时也要确认各自流向。
飞畅导轨交换机目录提供不同光电端口组合，选型时可分别核对接入口和上联。其万兆4光千兆8电产品详情明确区分光口与电口能力，高速汇聚可为多条接入流量提供容量，但这不证明任意摄像机数量都能同时运行。光模块与链路兼容、整机转发、录像机网口、存储写入和解码能力都应一起核查，避免只升级交换机而保留其它瓶颈。
用业务测试决定最终配置
验收先核对端口是否协商到计划速率，再同时开启计划中的录像、实时预览、事件业务和回放，观察持续流量、短时峰值、错误与丢包。网络传输正常而画面仍卡顿时，进一步检查录像机写盘、CPU、解码与摄像机本身，不把所有问题都归到交换机。测试用同样的画质和并发条件，才能比较升级前后的效果。
保留每台摄像机的编码参数、请求流数量、拓扑、端口计数及录像结果，形成可追溯的容量表。新增终端或改变客户端访问方式后重新计算。压力测试应在隔离测试网或获准的维护窗口进行，提前备份配置和安排回退，不用生产视频业务作无计划试验。合格的容量规划应能解释每一条链路为何足够，而非只报一个“最多接多少台”的数字。
机制参考：Axis码率控制资料；产品依据：飞畅导轨交换机目录、万兆4光千兆8电详情。原理图为通用机制示意，不代表具体产品实测。
