下行流量大且可缓存，必须就近走边缘节点分发；上行流量小但实时性高，必须走中心源站保证一致性。这就是音视频链路分工的核心逻辑：边缘负责“喂饱”观众，中心负责“接住”创作者。
下行走边缘：把内容搬到观众家门口
边缘节点不是在“转发”，是在“代管”
很多人对边缘节点的理解是“一个离用户近一点的服务器”，这个理解没错，但低估了它的作用，真正的下行链路分工里，边缘节点是内容的“二房东”它不只帮你转发数据，而是直接把热门视频片段、直播流的切片缓存到自己家里。
当观众点开一个视频,请求首先被调度到离他最近的边缘节点，如果这个节点已经缓存了对应的内容分片，它直接本地吐数据，不回源站，这意味着什么？意味着你的中心源站承受的压力，从“每秒几万次请求”降到了“每秒几百次回源”，业内专家指出，一个配置合理的边缘缓存体系，可以让源站回源比例控制在个位数百分比。
下行链路的三个关键动作
- 缓存策略分级（比如刚上线的剧集、头部主播的直播流）采用“主动预热”，提前把内容推送到全国各边缘节点；中等热度内容采用“回源缓存”，第一次请求回源拉取，后续命中边缘；冷门内容则不缓存，直接穿透到中心。
- 调度算法要“反直觉”：不是永远选最近节点，而是选“最近且最闲”的节点，一个拥堵的近距离节点，不如一个空闲的中距离节点体验好，IPv6环境下尤其明显，调度系统需要同时考虑RTT（往返时延）、节点负载、丢包率三个指标。
- 分片粒度要精细：视频文件切成4秒到10秒的分片，按需拉取，用户拖进度条时，边缘节点只需要回源拉那一个分片，而不是整个文件，这个细节对带宽成本影响极大。
边缘节点选型的地域学问
国内做音视频分发,边缘节点的地域覆盖不是“均匀撒网”，而是跟着人口和网络条件走，北上广深及江浙沪区域的节点密度，通常是西部地区的三到五倍，这不是歧视，是因为这些区域的用户对延迟更敏感他们的宽带质量好、设备性能强，一旦卡顿，用户不会怪自己网络，只会怪你平台差。
弱网环境下行边缘优化是另一个极端，二三线城市、老旧小区、移动网络用户，他们的网络丢包率可能达到3%到5%，针对这类用户，边缘节点需要支持冗余编码（比如前向纠错FEC），在数据包层面多发送一些校验数据，让客户端即使丢了一两个包也能直接恢复，不用重传，这个能力必须在边缘节点做，因为重传一旦回源，延迟就失控了。
上行走中心：源站是唯一的事实来源
为什么上行不能“就近上传”
创作者推流、用户上传视频，为什么不也走边缘节点？因为上行流量有两个特性：量小但不可丢，一次推流可能只有几兆码率，但这几兆数据承载的是整场直播，如果推流走边缘节点，边缘节点缓冲完之后再转发给源站，中间多一跳，就多一次故障点。
更重要的是一致性问题，直播场景下，观众的弹幕、礼物、互动消息需要和画面同步，如果推流走了边缘节点，边缘节点和中心源站之间存在毫秒级延迟，就会出现“画面到了，弹幕还没到”的尴尬，行业共识认为，上行链路必须保持“单一路径”创作者的数据直接进入中心源站，由源站做统一处理后，再分发给下游的边缘节点。
上行走中心时的链路设计要点
- 接入点就近选，但逻辑链路直连：创作者的推流客户端，就近选择接入点（比如上海的创作者接入上海节点），但上海节点只做“入口转发”，数据包不在本地停留，立即通过专线转发到中心源站，转发延迟控制在5毫秒以内。
- 上行要做协议优化：TCP协议的拥塞控制算法在弱网下表现不佳，上行链路建议使用QUIC或者自研的UDP协议封装，实测在30%丢包率的环境下，优化后的上行协议仍能保持直播不中断。
- 多路复用和断点续传：上传大视频文件时，不能用一个HTTP连接从头传到尾，要切块并发上传（比如每个块4MB，同时传8个块），失败重传只重传具体块，而不是整个文件，短视频平台的上传体验，全靠这个细节撑起来。
上行中心节点的容量规划
中心源站处理上行流量,要做的是“宽进严出”，宽进，指入口带宽要充裕，不能因为带宽瓶颈拒绝创作者接入；严出，指源站的缓存和转码服务要有优先级实时互动数据（比如直播流）优先处理，非实时的文件转码任务排队处理。
源站的部署架构上,建议采用“双中心互备”，主中心承担日常上行接入，备中心实时同步数据，一旦主中心出现故障，上行链路在秒级切换到备中心，创作者的推流客户端要支持“自动降级”感知到主链路异常时，自动降低码率并切换备份链路，而不是直接断开连接。
链路的“分工”不只是技术选择，还是成本选择
带宽成本的中枢逻辑
音视频下行带宽边缘节点价格通常是中心源站带宽价格的1/3到1/5，原因很简单：边缘节点用的是“闲散带宽”，可以通过运营商的下沉节点、民营IDC的冗余带宽来拼凑，成本天然更低，而中心源站需要的是高可靠、低延迟的BGP带宽，价格自然高。
所以链路分工的经济学逻辑是：把贵的流量（下行）用便宜的带宽（边缘）承载，把便宜的流量（上行）用贵的带宽（中心）承载，整体成本最优。
一个典型的链路预算结构
| 环节 | 流量占比 | 带宽单价（相对） | 承载位置 |
|---|---|---|---|
| 下行分发 | 85%-95% | 低 | 边缘节点 |
| 上行接入 | 3%-5% | 高 | 中心源站 |
| 边缘回源 | 2%-5% | 中 | 中心到边缘专线 |
| 控制信令 | 1%以下 | 极低 | 单独信令通道 |
这里的核心要点是控制回源比例，回源流量虽然占比不大，但走的是中心到边缘的专线，价格按峰值带宽计费，如果边缘缓存命中率低，回源带宽会直接吃掉你省下的边缘成本。
选择方案时要问自己三个问题
排查问题的时候,可以换个角度：我的场景里，哪个链路是价值核心？
- 如果你的产品是点播平台（长视频、短视频），下行边缘是命脉，中心源站只是“存储+转码”，核心任务是把边缘的命中率做到极致。
- 如果你的产品是直播平台（电商直播、体育直播），上行接入和中心转发是命脉，因为直播流的实时性要求高，中心源站的处理能力决定了端到端延迟。
- 如果你的产品是实时音视频通话（在线教育、视频会议），下行边缘+上行中心”的分工模式其实不适用，你需要的是“多路接入+就近转发”的SFU架构，链路分工的逻辑完全不同。
选择下行边缘方案时，要重点考察边缘节点是否支持HTTP/3、是否细化到运营商维度（电信/联通/移动的互访延迟差异很大）、是否提供预推送API，选择上行中心方案时，要考察源站的接入协议是否开放、是否支持自定义传输参数、容灾切换的RTO是否达标。
实操：一套最小可行的链路分工配置
假设你是一个中小型直播团队,没有自建IDC，全部用云厂商服务，合理的架构是这样：
- 下行：使用云厂商的CDN产品，开启“直播流切片缓存”和“边缘转码”，注意关闭“回源跟随重定向”选项，防止边缘节点反复回源。
- 上行：使用云厂商的“媒体处理服务”作为虚拟源站，推流端通过RTMP或SRT协议推送到就近的接入点，控制台里设置“多路输入容灾”同时推两路流，源站自动择优。
- 关键参数：直播延迟设置控制在2到4秒（常规模式）或500毫秒以内（超低延迟模式），不要盲目追求最低延迟，低延迟意味着放弃边缘缓存，所有观众都直接回源，成本飙升数倍。
链路是否正常,配置完成后验证方法是：用手机5G网络直播推流，同时用另一台设备在同一个Wi-Fi下观看，直播正常后，用网络抓包工具观察正在观看的设备它连接的IP地址应该是一个边缘节点IP（通常属于当地运营商或云厂商CDN），且传输过程中的流量曲线平稳，说明边缘命中生效。
Q&A：关于上下行链路分工的常见问题
上行推流能不能也走边缘节点省钱？
可以,但有条件，如果你的业务是短视频上传（非实时），可以把上传流先打到边缘节点，边缘节点暂存后异步转中心，这能降低上传延迟和不稳定率，但如果是直播推流，不建议走边缘，因为边缘节点的转发链路多一跳，故障率提升且延迟不可控，实时的上行链路，中心直连永远是第一选择。
下行边缘与上行中心的切换阈值如何设定？
判断阈值不是看“流量大小”，而是看“数据可缓存性”，凡是可缓存、可重复使用的数据（视频分片、直播回看、封面图），一律走边缘，凡是不可缓存、需要实时响应的请求（用户登录状态、互动指令、上行推流），一律走中心，如果你的业务里有数据同时具备“可缓存”和“不可缓存”特性，按照两个维度拆分为两条链路并行处理，不要混在一起。
边缘节点缓存命中率做到多少算健康？
统计数据显示，行业内做得好的一线点播平台，整体缓存命中率能达到90%以上，直播场景的命中率会低一些，常规在70%到80%之间，因为直播流是实时的，边缘节点缓存窗口很小（通常只有几十秒），如果你的命中率低于60%，先检查调度策略是不是大量请求被调度到了没有缓存的节点；再检查缓存规则是不是配置了“不缓存动态参数”导致每一个请求都回源，注意，边缘节点是缓存整个文件而不是仅缓存响应头，如果你配置了“带鉴权参数的URL不缓存”，再热的内容也命中不了。