快连流媒体类应用分流

流量特征：长连接加持续码率

主流视频服务普遍使用分片传输机制：播放器按固定时长拉取视频分片，缓冲区维持一定水位。当带宽持续低于码率，缓冲区逐渐耗尽，表现为卡顿；当带宽重新高于码率，缓冲区回升，卡顿消除。因此决定体验的是带宽的下限稳定性，而不是上限。

这与游戏类应用形成鲜明对比。游戏几乎不看带宽但极在意时延；流媒体对时延有一定容忍（缓冲区可以吸收几百毫秒的波动），但要求带宽不能出现持续低谷。

识别难点：同一进程内的两类流量

网页版视频服务把播放器、页面框架、缩略图、评论加载都放在同一组浏览器渲染进程里。如果按进程整体分流，会把大量静态资源也送进加速通道，既浪费带宽又挤占视频流本身的额度。

更精细的做法是结合目标特征区分：视频分片通常来自特定的媒体域名，且单个连接传输量大、持续时间长；页面资源则来自多个域名、单连接数据量小。按目标特征与连接特征组合判断，可以把两类流量分开处理。

识别方法

• 结合目标域名特征：视频分片常来自专门的媒体分发域名
• 结合连接特征：单连接累计传输量大、持续时间长的，更可能是媒体流
• 避免只按进程粗分：浏览器类进程内部流量类型差异极大
• 对客户端版播放器：通常进程独立，可直接按进程归属分流

路径取向建议

指标	权重取向	原因
持续吞吐	最高	必须稳定高于目标码率
带宽方差	高	低谷直接导致缓冲区耗尽
时延	低	缓冲区可吸收一定波动
抖动	低	对连续码率影响有限

常见异常与排查方向

高码率内容卡顿但低码率正常：说明带宽下限低于高码率需求，检查是否与其他大流量任务共享了通道。开始播放正常、几分钟后卡顿：典型的缓冲区逐步耗尽，问题在持续带宽而非首包速度。网页版流畅但客户端版卡顿：两者进程结构不同，检查客户端的识别归类是否正确。多个视频同时播放时全部卡顿：通道总带宽被分摊，需要串行化高码率任务。