26、边缘计算：边缘节点部署、就近接入、延迟优化

聊到WebRTC的延迟优化，很多人的第一反应是调编码参数、改网络拥塞算法。这些当然重要，但有个更根本的问题——你的媒体数据，物理上离用户有多远？

我几年前做过一个跨国视频会议项目。服务器全放在美西，用户分布在全球。结果呢？新加坡的用户延迟200ms，南非的直奔400ms。调了半天FEC和码率，效果微乎其微。后来我们把媒体节点部署到新加坡、法兰克福、圣保罗，延迟直接砍到50ms以内。嗯，这就是边缘计算的价值。

为什么WebRTC需要边缘计算

WebRTC是P2P架构，但实际生产中很少纯P2P。原因很简单：

• NAT穿透失败率：即使有STUN/TURN，某些对称NAT场景下P2P连不上，必须走TURN中继
• 多人通信：3人以上就需要SFU（选择性转发单元）做媒体路由
• 录制/转码：需要中心节点处理

这些中继节点如果部署在中心机房，用户到节点的物理距离就成了硬伤。光速在光纤里大约是每毫秒200公里，但加上路由跳数、排队延迟，实际RTT往往是物理距离的3-5倍。

边缘节点部署策略

我个人习惯把边缘节点分为三层：

层级	位置	覆盖范围	典型延迟
L1 - 接入层	城市级IDC	单个城市	<5ms
L2 - 区域层	省级/国家级	省/国家	10-20ms
L3 - 中心层	跨区域骨干	全球	50-200ms

部署时要注意：

• L1节点只做转发：不转码、不录制，纯媒体包路由。这样一台8核机器能扛5000路并发
• L2节点做轻量处理：比如降噪、动态码率调整。我在项目中遇到过，L2节点如果做全量转码，CPU直接打满，延迟反而飙升
• L3节点做重活：录制、合流、AI处理。这些对延迟不敏感，可以接受50ms以上的开销

就近接入：用户怎么找到最近的节点

节点部署好了，用户怎么知道该连哪个？这里涉及两个关键机制：

1. DNS解析 + GeoDNS

最简单的方案。用户请求一个域名（比如 turn.example.com），GeoDNS根据用户IP返回最近的节点IP。优点是零额外延迟，缺点是粒度粗——同一个城市的用户可能被分到不同节点，负载不均。

// 伪代码：GeoDNS解析流程
function resolveNearestNode(userIP) {
    // 1. 根据用户IP查地理位置
    let geo = geoDB.lookup(userIP);
    // 2. 找到该区域最近的L1节点
    let node = nodeRegistry.findNearest(geo.city);
    // 3. 返回节点IP
    return node.ip;
}

2. 基于延迟的选路

更精确的做法。用户启动时，先向所有候选节点发探测包（类似STUN的Binding Request），测量RTT，选延迟最低的。我建议探测3-5个节点，取中位数，避免单次抖动影响判断。

// 伪代码：延迟探测选路
async function selectBestNode(candidates) {
    let results = [];
    for (let node of candidates) {
        let rtt = await measureRTT(node.stunAddr);
        results.push({ node, rtt });
    }
    // 按RTT排序，选最小的
    results.sort((a, b) => a.rtt - b.rtt);
    return results[0].node;
}

延迟优化的具体手段

节点部署好了，选路也对了，但延迟可能还是不够低。这时候需要从传输层面继续优化。

1. 减少媒体路径跳数

WebRTC的媒体路径通常是：用户A → L1节点 → L2节点 → L1节点 → 用户B。如果A和B在同一个城市，完全可以走：用户A → L1节点 → 用户B。我在项目中加了一个优化：当SFU检测到两个用户在同一L1节点下时，直接做本地路由，不走L2。

2. 使用UDP + FEC

TCP在弱网下会重传，导致延迟不可控。WebRTC默认用UDP，但UDP丢包怎么办？FEC（前向纠错）可以解决。我习惯用20%的冗余：每10个包加2个冗余包，丢包率在10%以内时完全无感。

// WebRTC中启用FEC
const rtpParameters = {
    encodings: [{
        rid: 'high',
        maxBitrate: 1000000,
        // 启用FlexFEC
        fec: { mechanism: 'flexfec', ssrc: 12345 }
    }]
};

3. 动态码率调整

边缘节点可以实时监控网络状况。如果检测到RTT突然升高，主动降低发送码率。我常用的策略是：RTT每增加50ms，码率降低20%，直到RTT恢复正常。

架构图：边缘计算下的WebRTC媒体流

下面这张图展示了我常用的边缘计算架构。用户从L1接入，L1之间可以直连（同城），也可以走L2中转（跨城）。L3只处理录制和AI。

实战中的几个坑

最后分享几个我踩过的坑，希望能帮你少走弯路。

• 节点健康检查不能少：我曾经有个L1节点挂了，但DNS缓存没更新，用户持续连到死节点上，延迟飙到500ms。后来我加了每5秒一次的健康检查，异常节点自动从选路池中移除。
• 不要迷信「最近」节点：物理距离近不代表网络延迟低。有一次用户离L1节点只有10公里，但中间经过了一个拥塞的城域网，延迟反而比50公里外的节点高。所以一定要用实际探测的RTT做决策。
• 边缘节点也要做冗余：每个城市至少部署2个L1节点。我遇到过机房光缆被挖断的情况，单节点直接失联，幸好有备用节点自动接管。

边缘计算不是银弹，但它确实是WebRTC延迟优化里性价比最高的手段之一。你想想看，调半天编码参数可能只省下10ms，但把节点从中心搬到用户旁边，直接砍掉100ms。这笔账，怎么算都划算。

---

公众号:蓝海资料掘金营，微信deep3321