4. 性能测量与监控
说到多媒体流性能优化，CDN 绝对是绕不开的核心基础设施。我最早接触 CDN 是在做视频点播平台的时候，那时候用户一多，源站带宽就扛不住，播放卡顿率飙升到 30% 以上。后来上了 CDN，卡顿率直接降到 5% 以下。说白了，CDN 就是帮你的内容「跑腿」——把数据提前放到离用户最近的地方。
CDN 分发原理：内容是怎么「跑」到用户身边的？
CDN 的全称是 Content Delivery Network，内容分发网络。它的核心逻辑就一句话：把内容从「一个中心」复制到「多个边缘」。
用户请求一个视频文件时，不会直接打到源站，而是先被 DNS 解析到最近的边缘节点。这个「最近」不是物理距离，而是网络延迟最低、负载最轻的节点。边缘节点如果有缓存，直接返回；如果没有，就回源拉取，然后缓存下来供后续请求使用。
我习惯把 CDN 分发流程拆成四个步骤：
- 用户发起请求 — 浏览器或播放器请求一个 URL，比如
https://cdn.example.com/video/001.mp4 - DNS 调度 — 智能 DNS 根据用户 IP 和地理位置，返回最优边缘节点的 IP 地址
- 边缘节点处理 — 节点检查本地缓存，命中则直接响应，未命中则回源拉取
- 内容返回 — 数据从边缘节点传输给用户，同时节点缓存一份
关键点：CDN 不是简单的「缓存代理」，它包含了全局负载均衡、智能调度、协议优化、安全防护等一系列能力。我见过不少团队把 CDN 当纯缓存用，结果调度策略没配好，效果大打折扣。
边缘节点缓存策略：怎么存？存多久？
缓存策略是 CDN 的灵魂。配得好，命中率能到 90% 以上；配不好，回源请求把源站打爆，CDN 反而成了累赘。
我总结了几种常见的缓存策略：
| 策略 | 原理 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| TTL 过期 | 设置固定的缓存时间，到期后重新回源 | 静态文件（图片、CSS、JS） | TTL 设太长，用户看到旧版本 |
| LRU 淘汰 | 节点存储空间满时，淘汰最近最少使用的文件 | 热点内容频繁变化的场景 | 冷门内容频繁被淘汰，回源压力大 |
| 预热推送 | 主动将内容推送到边缘节点，用户请求时直接命中 | 大促活动、热门直播、新版本发布 | 预热范围太大，浪费带宽 |
| 分层缓存 | 边缘节点 + 区域节点 + 源站，逐层回源 | 大规模分发，减少源站压力 | 层级太多，延迟反而增加 |
我的习惯：对于视频流媒体，我会把视频切片（TS 或 fMP4）的 TTL 设为 24 小时，但索引文件（m3u8 或 mpd）的 TTL 只设 30 秒。这样既能保证缓存命中率，又能快速响应直播流的切换。
静态加速 vs 动态加速：到底有什么区别？
这个问题我经常被问到。很多人以为 CDN 就是加速，但其实「静态」和「动态」完全是两码事。
静态加速，说白了就是加速那些「不会变」的内容。图片、视频、CSS、JS 文件，这些内容一旦生成，很长时间内都不会变化。CDN 只需要把它们缓存到边缘节点，用户请求时直接返回缓存即可。
动态加速，加速的是「每次请求都不一样」的内容。比如用户登录、购物车查询、实时数据接口。这些内容不能缓存，CDN 需要做的是优化从用户到源站的网络路径——选最快的路由、做 TCP 优化、减少握手次数。
我整理了一个对比表格，方便你理解：
| 维度 | 静态加速 | 动态加速 |
|---|---|---|
| 内容特点 | 固定不变，可缓存 | 每次请求不同，不可缓存 |
| 核心手段 | 边缘缓存 + TTL 管理 | 路由优化 + TCP 加速 + 连接复用 |
| 延迟改善 | 降低 50%-80% | 降低 20%-40% |
| 典型场景 | 视频点播、图片下载、静态页面 | API 接口、实时数据、WebSocket |
| 回源频率 | 低（仅缓存过期时） | 高（每次请求都回源） |
注意：我曾经遇到一个项目，把动态 API 接口也配了 10 分钟的缓存，结果用户看到的订单状态一直是「待支付」，实际上早就支付成功了。动态内容千万不能随便缓存，除非你明确知道业务允许延迟。
动态加速的底层技术：CDN 是怎么「加速」动态请求的？
既然动态内容不能缓存，那 CDN 怎么加速？其实核心就三点：
- 智能路由 — CDN 节点之间建立私有网络，实时探测各条路径的延迟和丢包率，选择最优路径回源。不像公网那样走 BGP 路由，可能绕远路。
- TCP 优化 — 边缘节点和用户之间使用优化的 TCP 参数（更大的初始窗口、更快的拥塞控制），减少慢启动带来的延迟。
- 连接复用 — 多个用户请求复用同一个回源连接，减少三次握手的次数。
我举个例子。用户在北京请求一个动态接口，源站在上海。公网直连可能要经过 15 跳，延迟 50ms。但 CDN 的智能路由可能让北京节点先连到济南节点，再到南京节点，最后到上海，虽然跳数多了，但每跳的延迟更低，整体延迟反而降到 30ms。
一句话总结：静态加速靠「存」，动态加速靠「跑」。前者把内容放到离用户最近的地方，后者把网络路径优化到最短。
多媒体流场景下的 CDN 选型建议
做多媒体流优化，CDN 选型不能一刀切。我根据经验给几个建议：
- 视频点播（VOD） — 优先选静态加速能力强的 CDN，缓存命中率要高，支持大文件分片缓存。我个人习惯用 TTL 24 小时 + 预热推送的组合。
- 直播流（Live） — 需要动态加速 + 低延迟传输。直播内容虽然也是「流」，但每个切片都是新的，不能长期缓存。边缘节点需要支持实时转码和协议转换。
- 互动直播（连麦、弹幕） — 动态加速是刚需。信令数据必须实时到达，延迟超过 200ms 用户就能感觉到卡顿。
- 混合场景（比如 HLS + API） — 建议用两个域名，一个走静态加速（视频切片），一个走动态加速（API 接口），分别配置不同的缓存策略。
嗯，CDN 这部分内容其实很深，今天先讲到这里。记住一句话：没有最好的 CDN 配置，只有最适合你业务场景的配置。多测试、多调优，才能找到最优解。