激励措施
今天的内容分发网络 (CDN) 所做的不仅仅是缓存和位推送。所有主要参与者都试图将他们的业务扩展到边缘计算领域。高级平台，例如 CDNetworks 的 CDN Pro， 提供 可编程性 支持边缘服务器上的复杂逻辑。一些逻辑，例如加密算法、正则表达式操作和数据压缩，可能需要大量计算。在 CDN 边缘运行它们不仅可以从源头卸载这些资源密集型活动，还可以显着减少延迟，为最终用户提供令人满意的体验。
然而，这种趋势并不总是反映在行业价格模型中。大多数 CDN 提供商继续主要根据流量（传送的字节数）或带宽（主要是 95p）收费。这个模型是几十年前创建的，当时大部分 CDN 成本是基于从 ISP 采购的带宽。当 CDN 仅用于交付高度可缓存的大文件 (HCLF) 时，该模型运行良好；然而，今天已不再是这种情况。例如，现代服务器可以轻松提供 40Gbps 的 HCLF；但是，要加速跨越太平洋的相同带宽的动态 API 服务，可能需要 500 台服务器。数据中心成本在很大程度上与服务器数量成正比。不同服务在资源消耗方面的巨大差异给 CDN 提供商及其客户带来了许多定价挑战。
为确保盈利，CDN 提供商必须将所有额外成本合并为每 GB 或每 Mbps 的价格。但在一项服务完全上线之前，准确估计它将产生的额外成本是不可行的。客户通常可以提供流量或带宽的大概数字，但他们无法说出需要多少台服务器。更不用说他们可能随时通过自助服务界面更改业务逻辑。根据传统模型来设定价格需要大量的猜测。因此，几乎不可能创建对所有客户和服务类型都公平的价格手册。解决方案非常简单：引入对 CPU 消耗的收费。 CPU从云诞生之初就一直是云计算的计费项目。因此，它被边缘计算所采用也就不足为奇了，这正是 CDN 正在发展的方向。
它是如何工作的？
由于 CDN 平台的资源在多个客户之间共享，因此衡量每个客户的使用情况并不容易。即使是流量这个最常用的计费项，也只有应用层的数据才能准确统计。在较低层收集网络开销并将其归因于每个客户是非常棘手的，因此大多数提供商决定不去理会这个。衡量每个客户的 CPU 利用率可能更具挑战性。然而，早在 2016 年 CDN Pro 项目开始时，我们就将此确定为必备功能。当我们决定基于 NGINX 构建边缘服务器时，我们的团队对 NGINX 的开源版本进行了广泛的更改。
NGINX 具有“事件驱动、非阻塞”架构。每个请求在等待 I/O 时都会“进入休眠状态”，当某些数据准备好处理时被唤醒，然后在处理完成时再次进入休眠状态。这可以在请求的生命周期中发生多次。我们在 Linux 上使用函数 clock_gettime() 来获取每个请求在每个活动间隔上花费的 CPU 时间（以纳秒为单位）以及在此过程中累积的时间。在请求的生命周期结束时，我们将消耗的总 CPU 时间写入访问日志，就像我们处理传输的字节数一样。CPU 时间包含在流量摘要日志中，以生成低延迟的每个域报告。
虽然此方法可以准确测量 NGINX 进程在每个请求上消耗的 CPU 时间，但它不包括以下内容：
● 内核处理来自网络接口卡或其他I/O 设备的中断。
● NGINX 主进程执行的常见任务。
● 运行在同一台服务器上的其他服务，如日志预处理、监控等。
数据
如上所述，CDN Pro 平台提供了一个时间序列报告来显示每个域消耗的 CPU 时间。它针对指定粒度的每个时间间隔返回此指标（以秒为单位）。有关详细信息，请参阅 API文档.该报告类似于流量报告，返回每个时间间隔内传送的字节数；在这种情况下，我们将值除以间隔宽度以确定流量带宽。对于 CPU 报告，划分结果是每个时间间隔内消耗的 CPU 内核数。另一个有趣的指标是每个请求的平均 CPU 时间。此值在 CDN Pro 服务的不同域中在几微秒到几秒之间变化。以下是影响此值的几个主要因素：
TLS 握手：下表显示了按连接顺序分组的每个请求的平均 CPU 时间。带有标签“1”的曲线对应于每个连接中的第一个请求。它与后续请求“2”、“3”和“4”之间的差异反映了 TLS 握手所消耗的 CPU 时间。我们可以看到，使用 RSA-2048 证书的 RSA 连接平均消耗大约 2.0 毫秒。相比之下，具有 ECDSA-256 证书的 EC 连接大约使用 0.9 毫秒。
TLS 重用因子：如果 TLS 连接被多个请求重用，则握手的成本由所有这些请求分担。
缓存命中状态：一次命中通常占用较少的CPU时间，如下图所示：
响应的大小：更大的响应需要更多的 CPU 能力来提供：
要确定传送固定数据量所需的 CPU 资源量，请将 CPU 时间除以流量。不同领域之间存在显着差异。如下表所示，具有 HCLF 的域每 GB 需要不到 1 秒，但高度动态的 API 服务可能需要数百倍的 CPU。
以下是来自具有千兆字节流量的 CDN Pro 客户域的最新统计数据。 CPU 时间列表示处理每 GB 数据所需的 CPU 时间。
（为了保护隐私，域名被隐藏了。）
| 领域 | 内容类型 | 传送 1GB 的 CPU 时间 |
| 域名1 | 动态API服务 | 453.66 秒 |
| 域名2 | 动态API服务 | 315.72 秒 |
| 域3 | 动态API服务 | 66.06 秒 |
| 域4 | 动态API服务 | 65.78 秒 |
| 域5 | 动态API服务 | 29.84 秒 |
| 域6 | 动态API服务 | 25.19 秒 |
| 域名7 | 动态API服务 | 18.81 秒 |
| 域8 | HCLF | 7.20 秒 |
| 域名9 | HCLF | 2.60 秒 |
| 域10 | HCLF | 2.12 秒 |
| 域名11 | HCLF | 1.75 秒 |
| Domain12 | HCLF | 1.56 秒 |
| 域名13 | HCLF | 801.98 毫秒 |
计费
上面的数据清楚地说明了第一部分提出的观点。仅根据网络流量对 CDN 服务收费是不公平的。这种方法类似于仅根据重量对超市中的所有商品进行收费。引入按 CPU 时间计费可确保每个客户就其使用的资源公平收费。 CDNetworks 网站已经正式介绍了这种新的计费方式。因此，HTTPS 请求的费用将被取消，因为相关费用将被更准确地涵盖。同时， 所有服务器组的流量价格 将显着减少。敬请期待！
