2025年5月02日·1 分钟
从 CDN 到平台：Cloudflare 的边缘如何扩展
了解 Cloudflare 的边缘如何从 CDN 缓存演进为安全与开发者服务平台，随着流量向网络外围集中，它承担了更多职责。
什么是边缘网络（以及为什么现在它很重要）
边缘网络 是一组分布在多座城市的服务器，放在离终端用户“更近”的位置。与其让每个请求都回到公司的源站（或云区），边缘可以在就近位置响应、检查或转发该请求。
把它想像成在场馆入口处放置了客服，而不是把所有问题都推到后勤办公室。某些请求可以立即处理（比如返回缓存文件），而另一些则被安全地转发到源站。
“外围（perimeter）”是什么意思——以及为什么流量在此处集中
外围 是外部互联网流量第一次接触你系统的边界：你的网站、应用、API，以及保护和路由它们的服务。历史上，许多公司把外围当成一个薄门（DNS 和负载均衡器）。今天，这里发生最多且最具风险的交互——登录、API 调用、机器人、抓取、攻击与突发流量。
随着更多工作转到线上并且越来越多集成依赖 API，把流量引导到外围以便在请求触及核心基础设施之前统一应用规则（性能优化、安全检查和访问控制）变得愈发实际。
本指南的预期
本文按顺序展开：先讲性能（CDN），然后是边缘安全（DDoS、WAF、机器人管理、零信任），最后是开发者工具（在靠近用户的位置运行代码并处理数据）。
面向 非技术决策者：评估供应商的购买者、在做权衡的创始人，以及需要知道“为什么”和“会发生什么变化”的产品经理，而不必研读网络教材。
CDN 基础：起点
传统的 CDN（内容分发网络）最开始的承诺很简单：通过从离访问者更近的位置提供内容，让网站感觉更快。与其让每个请求回到源站（通常是单一区域或数据中心），CDN 在多个驻点（PoP）保存静态文件的副本——图片、CSS、JavaScript、下载文件。当用户请求某文件时，CDN 可以就近响应，降低延迟并减轻源站压力。
经典 CDN 的作用
在本质上，“纯 CDN”部署关注三件事：
- 缓存： 在边缘存储内容，让重复请求无需回源。\n- 降低延迟： 缩短用户与内容之间的物理距离（和网络跳数）。\n- 卸载源站： 处理大部分流量，让源站少传输字节和处理请求。
这种模式对静态站点、媒体密集型页面和请求模式可预测（相同资源反复被请求）的场景尤其有效。
早期 CDN 的成功指标
早期团队用一些实用指标评估 CDN：
- 缓存命中率： 多少百分比的请求由缓存响应而不是转发到源站。\n- 带宽节省： CDN 交付了多少 GB/TB，而不是你的基础设施。\n- 页面加载时间改善： 通常以首字节时间 (TTFB) 和整体渲染速度衡量。
这些数字很重要，因为它们直接转化为用户体验和基础设施成本。
CDN 在请求路径中的位置
即便是基础的 CDN 也会影响请求到达你站点的方式。最常见的是通过 DNS 引入：你的域名指向 CDN，CDN 将访问者路由到就近 PoP。之后，CDN 可能充当 反向代理——终止来自用户的连接，并在需要时与源站建立单独连接。
这种“处于中间”的位置很重要。一旦某个提供商可靠地置于你源站之前并在边缘处理流量，它就能做的不仅仅是缓存文件——还能检查、过滤和调整请求。
现代应用场景下“仅 CDN”的局限
许多现代产品不再主要是静态页面。它们是由 API 支撑的动态应用：个性化内容、实时更新、需认证的流程与频繁写操作。缓存有帮助，但无法解决所有问题——尤其是当响应因用户不同而异、依赖 cookie 或头字段，或需要即时的源站逻辑时。
这正是从“CDN”向更广泛边缘平台演进的空间所在。
为什么流量会在外围集中
互联网使用方式的重大变化把更多请求推向“边缘”（网络外围），在到达源站之前就先经过这里。现在不只是为了更快的网站——而是流量自然流动到哪里。
把流量往外拉的力量
HTTPS 普及是一个重要推动力。一旦大多数流量被加密，企业网络内部的网络中间设备就难以 inspect 或优化这些流量。因而组织倾向于在就近用户的地方终止和管理 TLS——在为此而建的边缘服务处。
API 也改变了流量形态。现代应用是一连串小请求，来自 Web 前端、移动客户端、合作方集成和微服务。再加上机器人（好的和坏的），大量“用户”并非真人——这意味着流量需要在触及应用基础设施之前进行过滤和速率控制。
还有移动网络的现实（延迟可变、漫游、重传）以及 SaaS 的兴起。你的员工和客户不再属于单一网络边界，因此安全和性能决策转向用户实际连接的位置。
分布式系统意味着更少的瓶颈点
当应用、用户和服务分散在不同区域和云时，能统一强制规则的地点变少了。传统控制点（如单一数据中心防火墙）不再是默认路径。边缘成为少数几个可以将大部分请求路由通过的稳定检查点之一。
边缘作为策略与保护的检查点
既然大量流量通过外围，它就是应用共享策略的自然位置：DDoS 过滤、机器人检测、WAF 规则、TLS 设置与访问控制。这减少了每个源站的“决策”负担，并在应用之间保持一致的保护。
运营权衡
在边缘集中流量可以隐藏源站 IP并减少直接暴露，这是一个重要的安全提升。代价则是依赖性：边缘的可用性与正确配置变得至关重要。许多团队把边缘视为核心基础设施的一部分——更接近控制平面，而不仅仅是简单缓存。
如需实用清单，请参见 /blog/how-to-evaluate-an-edge-platform。
从缓存到完整代理：关键架构转变
制作让利益相关者信服的演示
创建可运行的应用，用真实流量验证性能与安全假设。
传统 CDN 起始于“智能缓存”：在更靠近用户的位置存储静态文件的副本并在需要时从源站获取。它提升性能，但并未从根本上改变谁“拥有”连接。
当边缘不再只是缓存，而成为完整的反向代理时，发生了重大转变。
用通俗话说的反向代理
反向代理位于你网站或应用之前。用户连接到代理，代理再连接到你的源站。对用户而言，代理就是站点；对源站而言，代理看起来就像普通用户。
这种位置关系使得“缓存才做的事”无法做到的服务成为可能——因为每个请求在到达你的基础设施之前都可以被处理、修改或阻断。
当边缘终止 TLS 时会有哪些变化
当边缘终止 TLS（HTTPS）时，加密连接首先在边缘建立。这带来三项实际能力：
- 可见性： 边缘可以读取 HTTP 请求与响应（头、路径、方法），而不是仅传递加密字节。\n2. 路由控制： 边缘可以对每个请求做决策——把流量发往不同的源站、在故障时绕行，或按地理、设备或 URL 应用策略。\n3. 检测与执行： 由于边缘能解释请求，它可以运行安全检查（如过滤可疑负载或验证机器人）和性能逻辑（压缩、图片转换、请求整形）。
这里是一个思维模型：
user → edge (reverse proxy) → origin
权衡：更多控制，也更多依赖
把边缘放在中间会集中控制，这常常正是目标：一致的安全策略、更简单的发布和更少的“特殊情况”在各个源站。但它也增加了复杂性和依赖性：
- 运维耦合： 若边缘配置出问题，一切 都会快速中断。\n- 供应商依赖： 某些功能可能依赖专有规则、日志或 API，不易移植。\n- 排错成本： 你现在需要排查一个多跳路径（用户 ↔ 边缘 ↔ 源站），而不是直接连接。
这个架构转变将 CDN 变成了平台：一旦边缘成为代理，它就可以做远不止缓存的工作。
安全第一步：边缘的 DDoS 保护
DDoS（分布式拒绝服务）攻击本质上是尝试以大量流量压垮站点或应用，让真实用户无法访问。攻击者不是“入侵”，而是堵住车道。
为什么容量型攻击适合在边缘缓解
许多 DDoS 是容量型攻击：向你的 IP 地址发起大量数据以耗尽带宽或过载网络设备。如果你把防护留在源站（数据中心或云区），你已在买单——上游链路可能饱和，防火墙或负载均衡器成为瓶颈。
边缘网络的保护优势在于它把防护能力更靠近流量进入互联网的位置，而不是仅仅在你的服务器所在处。防护越分布式，攻击者就越难在单一瓶颈处堆积流量。
“吸收与过滤”在边缘意味着什么
提供商说 DDoS 保护会“吸收并过滤”，指的是在多个驻点同时发生两件事：
- 吸收： 接受并终止大量入站连接而不宕机，把负载分散到全球容量。\n- 过滤： 将合法请求与垃圾流量（例如畸形数据包、可疑模式或放大流量）区分开来，只把干净流量转发给源站。
关键好处是攻击的大部分影响可在你的基础设施上游被处理，从而降低你的网络或云账单成为牺牲品的风险。
速率限制：非专业人士也能理解的控件
速率限制是防止任一来源或行为在短时间内消耗过多资源的实用方法。例如，你可能限制：
- 登录端点的每分钟请求数\n- 每个令牌的 API 调用数\n- 单 IP 对昂贵页面的请求数
它并不能单独阻止所有类型的 DDoS，但作为在事件中保持关键路径可用的有效“减压阀”非常有用。
依赖前请验证哪些内容
在你依赖边缘 DDoS 保护前，确认：
- 覆盖面： 保护哪些流量类型（HTTP/S、TCP/UDP、DNS），是否自动适用于你所有域和应用。\n- SLA 与承诺： 提供商保证什么（可用性、缓解期望、支持响应），以及是否有限制或排除项。\n- 报告能力： 清晰的仪表盘与日志，展示攻击大小、持续时间、应用的缓解措施以及到达源站的流量——便于内部解释事件并随时间调整控制策略。
安全第二步：WAF 与机器人管理
构建移动端与后端
用 Flutter 开发应用并配合 Go API，使边缘策略同时覆盖客户端与后端。
在基本的 DDoS 过滤就位后，下一层是保护应用本身——尤其是那些“看起来正常”但带有恶意意图的请求。这就是 WAF 和机器人管理在边缘的日常作用。
WAF：阻止常见 Web 攻击的规则
WAF 会检查 HTTP/S 请求并应用设计用于阻止常见滥用模式的规则。经典示例包括：
- SQL 注入（SQLi）： 攻击者试图把数据库命令藏在表单字段、URL 或 API 参数中。\n- 跨站脚本（XSS）： 攻击者向页面注入脚本，使真实用户浏览器执行这些脚本。
让边缘在到达源站前过滤掉许多此类尝试，可以降低风险并减少浪费在计算与日志上的噪音。
机器人管理：并非所有流量都是“用户”
机器人可能是有益的（搜索引擎爬虫），也可能有害（凭证填充、抓取、囤积库存、假注册）。关键差别不在于“自动化”，而在于“意图”和“行为”。真实用户的会话通常具有自然的节奏、导航流程与浏览器特征；恶意机器人常常产生高频、重复请求，探测端点，或模拟用户代理但行为异常。
边缘用于决策的信号
因为边缘能在大量网站上观察到海量流量，它可以使用更广泛的信号来做更智能的判断，例如：
- IP 声誉 与历史滥用模式\n- 请求头（包括自动化常见的不一致性）\n- 行为模式，如请求速率、路径遍历与会话异常
最佳实践：先观察，再执行
实用的上线方式是先启用监控（日志）模式以查看本应被阻止的内容和原因。用这些数据调整对已知工具与合作方的例外规则，然后逐步收紧策略——从告警到挑战，最终对确认为恶意的流量执行阻断，以减少误报并迅速提升安全。
常见问题
用简单的话说，什么是边缘网络？
边缘网络是一组分布在许多城市的服务器（驻点/PoP），可以让请求更靠近用户被处理。根据请求类型，边缘可能会：
- 立即返回缓存的资源
- 检查并过滤流量（安全）
- 将请求路由到合适的源站或区域
实际效果是降低延迟，减轻并减少源站基础设施的暴露和负载。
“外围（perimeter）”是什么意思，为什么重要？
外围是指“外部互联网流量第一次接触你系统的边界”——你的站点、应用和 API，经常通过 DNS 和边缘反向代理到达这里。它之所以重要，是因为：
- 登录和敏感的 API 调用通常在这里发生
- 机器人、抓取和滥用会在此处显现
- 流量突增和攻击会首先打到这里
在外围集中控制能让你在流量到达核心服务前应用一致的性能和安全规则。
经典 CDN 与现代边缘平台有什么不同？
经典 CDN 专注于在边缘位置缓存静态内容（图片、CSS、JS、下载文件），通过缩短物理距离和减少源站请求来提升速度并减轻源站负载。
现代边缘平台则进一步成为“完整的反向代理”，可以对大部分流量进行路由、检测、安全拦截，并在某些情况下执行计算——无论内容是否可缓存。
DNS 通常如何在部署 CDN 或边缘服务时发挥作用？
DNS 往往是把 CDN/边缘服务放在站点前面的最简单方式：你的域名指向提供商，流量被引导到就近的 PoP。
在许多部署中，边缘还充当反向代理：用户先与边缘建立连接，边缘在需要时再与源站连接。正是这个“在中间”的位置，使得缓存、路由和安全可在大规模下生效。
当边缘终止 TLS（HTTPS）时会发生什么变化？
当边缘终止 TLS 时，HTTPS 加密连接在边缘建立。这带来三个实际能力：
- 可见性： 边缘可以读取 HTTP 路径、头和方法
- 执行： 可以应用 WAF 规则、机器人检测、速率限制和访问策略
- 路由决策： 可以按 URL、地理、设备或源站健康状况来转发请求
这增强了控制力——但也使得边缘配置成为关键的可用性点。
评估 CDN 性能最有用的指标有哪些？
评估 CDN 时，应选用能直接关联到用户体验和基础设施成本的指标，例如：
- 缓存命中率（多少请求由缓存响应）
- 带宽节省（有多少流量从源站被卸载）
- 延迟改善（通常看 TTFB 和 p95 页面/API 响应时间）
同时结合源站指标（CPU、请求率、出站流量）来确认 CDN 的确在关键处减轻了压力。
为什么 DDoS 保护通常在边缘比在源站更有效？
边缘缓解之所以通常比源站更有效，是因为许多 DDoS 攻击是**容量型（volumetric）**的——通过向你的 IP 地址发大量流量来耗尽带宽或网络设备。
分布式的边缘可以：
- 吸收大量连接洪峰，跨多个 PoP 分散负载
- 过滤垃圾流量，只把干净请求转发到源站
仅在源站防护通常意味着你在缓解生效前就已经承担了代价（链路饱和、负载均衡器过载、更高云账单）。
什么是速率限制，什么时候应该使用？
速率限制是在时间窗口内限制客户端（或令牌）请求数量，防止单一来源短时间内占用过多资源。
常见边缘场景包括：
- 限制登录尝试以减少凭证填充攻击
- 对昂贵端点（搜索、导出、结账）进行节流
- 按令牌实施配额（比仅按 IP 更有用）
它不能独自阻止所有类型的 DDoS，但作为抑制滥用峰值的有效阀门非常实用。
WAF 和机器人管理到底做什么？
WAF 会检查 HTTP 请求并应用规则以阻止常见应用层攻击（例如 SQL 注入和 XSS）。机器人管理则关注识别和处理自动化流量——既包括良性机器人（搜索引擎爬虫），也包括恶意机器人（抓取、假注册、凭证填充）。
一个实用的上线流程是：
- 先用监控/日志模式观察（monitor/log mode）
- 审查误报并为已知工具添加例外
- 逐步转为挑战，最终对确认的恶意流量进行阻断
什么是零信任访问，需要避免哪些常见错误？
零信任的通俗说法是：不要信任网络——验证每一个请求。无论用户在办公室、酒店 Wi‑Fi 还是家庭网络，访问决策都应基于身份、设备信号和上下文，而不是流量来自何处。
在边缘，它通常体现为：
- 将内部管理面板（如 /admin）放在登录 + MFA 后面，并限制特定组访问
- 在边缘保护内部工具（仪表盘、Wiki、工单系统）而无需公开暴露
- 通过浏览器提供 SSH/RDP，减少打开入站端口，便于审计
应避免的错误包括把零信任当成简单的 VPN 替代并就此结束；移除 VPN 改善可用性，但不会自动纠正薄弱的身份实践、过宽的权限或缺失的设备检查。
为什么 API 流量是性能与安全交汇的地方？
API 改变了边缘网络的价值，因为它们把大量“小门”暴露给外部：移动客户端、合作方集成、内部工具和自动化任务都会频繁调用 API，从而让机器流量（既有正当也有恶意）不断打到外围。
边缘若能就近路由、缓存并过滤 API 流量，就能降低延迟并避免源站在垃圾请求上浪费容量。
边缘平台对 API 提供了哪些常见控制？
边缘平台通常会提供类似 API 网关的功能，例如：
- 身份验证检查（验证令牌、强制要求作用域/声明）
- 模式验证概念（拒绝不符合预期字段、类型或大小的请求）
- 方法与路径规则（只允许预期的 HTTP 动词和路由）
- 请求规范化（对头字段和查询字符串做一致处理）
优先考虑三项实用功能：、，以及，这样开发者能更快修复客户端，安全团队也能更容易区分故障与攻击。
边缘计算是什么，团队会用它来做什么？
边缘计算是指在靠近用户的服务器上运行小段代码——在请求回到源站之前就做决策、转换请求，甚至生成响应。相比仅做缓存（传统 CDN），边缘现在可以处理认证校验、重定向、个性化和请求改写等轻量逻辑，从而减少到源站的往返并降低核心系统负载。
但边缘运行时有约束：
- 运行时限制： 代码需要快速完成
- 冷启动： 第一次请求可能略慢
- 状态管理： 边缘函数通常无状态；持久化状态需放到 KV/存储/数据库
把边缘计算当作应用的“前台柜台”来处理检查与决策，而把复杂业务逻辑留给源站，是常见的实用做法。
边缘附近的数据（存储）意味着什么，应该放什么数据？
如果你的函数在边缘执行但每次都要去远端拿数据，延迟优势会丧失。因此边缘平台通常也提供靠近计算的存储服务：键值（KV）存储、对象存储、队列，甚至某些场景下的数据库。
常见放在边缘的数据类型包括：
- 静态资源（图片、打包文件）+ 缓存
- 缓存的 API 响应，避免重复回源
- 特性开关和配置（KV）以供快速读取
- 可容忍复制延迟的“会话式”数据（需谨慎）
评估时关注持久性与 SLA、定价模型（请求、存储 GB、操作类型）以及出站/跨区流量成本。边缘存储最适合那些能接受“短暂不一致”而获益于低延迟的场景。
平台化有什么影响（整合、控制与风险）？
随着边缘从缓存演进为平台，一个常见模式是整合：组织倾向于将 DNS、CDN、DDoS 防护、WAF、机器人控制和应用访问放到单一控制面来协调流量进入和经过外围的方式。
好处包括：更少供应商、更简洁的路由和共享的分析视图；风险在于更高的集中化（单点故障、迁移难度、归属不清）。为了既享受便利又控制风险，应把边缘视为平台：定义清晰角色、使用变更管理、分阶段发布并保留回滚计划。
如何为组织评估边缘平台？
选择边缘平台不仅是选一个“更快的 CDN”，而是决定在哪里检查、加速并在需要时执行关键流量。把特性和你的实际约束（用户体验、风险、开发速度）对应起来。
实用清单：
- 性能需求： 哪些端点需全球加速？是否需要动态加速、图片优化、TCP/UDP 支持？
- 威胁模型： 哪些攻击最致命？将每种威胁映射到你期望在边缘实现的控制
- 开发者需求： 团队是否需要边缘计算、可编程路由、CI/CD 集成、预览环境或无须开工单即可自定义安全规则？
在无法将“必需”与可衡量结果（如更少事故、降低延迟、减少源站负载）关联时，把它视为可选项。建议从一个有代表性流量的应用/API 做试点（监控→执行），定义成功指标并制定 DNS 回退、旁路规则与应急路径。