企业官网建设流程全解析

一句话：CDN 把网站或游戏的静态文件（图片、安装包、补丁、视频）提前复制到全国乃至全球各地的服务器上，玩家从离自己最近的那台下载，速度更快，源服务器的压力也更小。

一、生活里的例子：电商的"前置仓"

一家网店的总仓库在广州：

• 没有前置仓：哈尔滨的用户下单，货从广州发，要好几天；"双十一"时总仓库门口的车排成长龙
• 有前置仓：提前把热门商品运到各城市的小仓库，哈尔滨的用户下单，从本地仓发货，当天到

二、没有 CDN 会遇到什么问题

假设游戏服务器在上海，发布了一个 2GB 的更新包：

带宽这个问题最致命：延迟可以忍，下载不动才是真的玩不了。

三、CDN 由哪几部分组成

┌──────────────┐ │ 源站 Origin │ ← 你自己的服务器 / 对象存储（OSS、S3） └──────┬───────┘ │ 回源 ┌────────┴────────┐ │ 中间层（回源保护）│ ← 汇总各地的回源请求，保护源站 └───┬────────┬────┘ ┌────────┘ └────────┐ ┌────┴────┐ ┌────────┐ ┌────┴────┐ │北京节点 │ │广州节点 │ │成都节点 │ ← 边缘节点：直接面对玩家 └────┬────┘ └───┬────┘ └────┬────┘ 玩家 玩家 玩家 调度系统（DNS / Anycast）：决定每个玩家连哪个节点

四、一次请求的完整流程

玩家要下载https://patch.mygame.com/v1.2/data.bundle：

1. 玩家电脑：patch.mygame.com 是哪个 IP？ → 问本地 DNS 2. DNS：patch.mygame.com 是一个别名（CNAME） → 指向 patch.mygame.com.cdn-vendor.net 3. CDN 的调度 DNS： 查看"来问的人"在哪：广东、电信 → 返回广州电信节点的 IP：203.0.113.25 4. 玩家连接 203.0.113.25，发起 HTTP 请求 5. 广州节点查缓存： ├─ 有，且没过期 → 直接返回（命中，最快） └─ 没有 / 已过期 → 去中间层或源站取 → 存一份 → 返回给玩家（回源） 6. 下一个广东电信玩家来要同一个文件 → 直接命中

用dig（或 Windows 上的nslookup）可以亲眼看到第 2、3 步：

$ dig patch.mygame.com patch.mygame.com. 300 IN CNAME patch.mygame.com.cdn-vendor.net. patch.mygame.com.cdn-vendor.net. 60 IN A 203.0.113.25

接入 CDN 的关键动作，通常就是在 DNS 里加一条 CNAME。你的代码和 URL 都不用改，这就是"接口不变、实现替换"。
不同地区的人查同一个域名，得到的 IP 不一样 —— 这就是 CDN 的"就近"。

另一种调度方式：Anycast

五、缓存规则：存多久？

CDN 节点判断"缓存还能不能用"，主要看源站返回的HTTP 响应头。

最重要的头：Cache-Control

Cache-Control: public, max-age=31536000, immutable

"变了没有"怎么问：304

CDN → 源站： GET /config.json If-None-Match: "abc123" ← 我手上这份的指纹 源站 → CDN： 304 Not Modified ← 没变，继续用你那份（只回一个头，不传内容） 或 200 OK + 新内容 + ETag: "def456" ← 变了，给你新的

不同文件，不同策略

六、最重要的工程技巧：用文件名做版本号

文件更新后，CDN 上还缓存着旧的，怎么办？

带哈希文件名的好处：

旧版本： version.json → 指向 data_8f3a2c.bundle （缓存 1 年） 新版本： version.json → 指向 data_c91e47.bundle （新文件，第一次访问时回源） ↑ 只有这一个小文件需要"不缓存/短缓存"

原则：大文件"永不变、永久缓存"，只让一个很小的入口文件保持新鲜。新旧版本的文件可以同时存在，玩家更新到一半也不会拿到混乱的组合。

还有一招：预热（Prefetch）

大版本发布前，提前让 CDN 把新文件拉到各节点。否则开服那一刻，几十万人同时触发回源，源站会被打垮 —— 这叫缓存击穿 / 回源风暴。

七、怎么衡量 CDN 用得好不好

命中率低的常见原因：

八、CDN 附带的"额外福利"

签名 URL 的大致样子：

https://cdn.mygame.com/vip/skin_01.bundle?expires=1735689600&sign=3f9a1c... sign = 哈希(密钥 + 文件路径 + expires)

CDN 节点用同一个密钥算一遍，对得上、没过期才放行。密钥只在服务器端，客户端只拿到已签好的 URL。

九、在游戏里，CDN 用在哪

✅ 适合

❌ 不适合

实时对战要的是另一类服务：游戏加速网络 / 全球加速（就近接入 + 专线回到游戏服务器）。它借用了 CDN"就近接入"的思路，但不做缓存，只负责走更稳的路线，降低延迟和抖动 —— 也就是减轻上一篇抖动缓冲区的压力。

十、实战：Unity 热更新的 CDN 流程

整体流程

游戏启动 │ ▼ 1. 下载 version.json（不缓存，或 TTL 很短） { "version": "1.2.3", "catalog": "catalog_c91e47.json" } │ ▼ 2. 和本地版本对比 → 一样？直接进游戏 │ 不一样 ▼ 3. 下载新的 catalog（文件名带哈希，可长期缓存） │ ▼ 4. 对比哪些资源包变了 → 只下载变化的（data_xxxx.bundle） │ ▼ 5. 校验文件哈希 → 全部通过 → 替换本地版本号 → 进游戏

Addressables 的关键设置

下载版本清单（简化示例）

usingSystem.Collections;usingUnityEngine;usingUnityEngine.Networking;publicclassVersionChecker:MonoBehaviour{conststringVersionUrl="https://cdn.mygame.com/android/version.json";[System.Serializable]classVersionInfo{publicstringversion;publicstringcatalog;}IEnumeratorStart(){usingvarreq=UnityWebRequest.Get(VersionUrl);// 告诉沿途缓存：要最新的（CDN 侧也应为这个文件配置短 TTL，双保险）req.SetRequestHeader("Cache-Control","no-cache");req.timeout=10;yieldreturnreq.SendWebRequest();if(req.result!=UnityWebRequest.Result.Success){Debug.LogWarning($"版本检查失败：{req.error}，使用本地资源进入");yieldbreak;// 网络问题不应该让玩家完全进不了游戏}varinfo=JsonUtility.FromJson<VersionInfo>(req.downloadHandler.text);stringlocal=PlayerPrefs.GetString("res_version","0");if(info.version!=local){Debug.Log($"发现新版本{info.version}，开始下载{info.catalog}");// 接着：下载 catalog → 计算差异 → 下载变化的 bundle → 校验哈希// Addressables 中可用 CheckForCatalogUpdates / UpdateCatalogs / DownloadDependenciesAsync}}}

注意：这里没有在 URL 后面加?t=时间戳来强制刷新。那样每次都会回源，CDN 命中率为零。正确做法是在 CDN 上给这个文件配短 TTL。

大版本日的流量规划

十一、和前面几篇的联系

十二、常见的坑

一句话总结

CDN = 源站 + 遍布各地的缓存节点 + 就近调度。玩家通过 DNS（CNAME）或 Anycast 被分配到最近的节点：有缓存就直接返回，没有就回源取一份再返回。
用好 CDN 的关键只有一条：大文件用"内容哈希命名 + 长期缓存"，只让很小的入口文件保持新鲜。
在游戏里，它负责安装包、补丁、热更新资源；而实时战斗流量需要的是加速网络，不是缓存。