激励措施
今天的内容分发网络 (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 has an “event-driven, non-blocking” architecture. Every request is “put to sleep” when waiting for I/O, awakened when some data is ready to be processed, and then put to sleep again when the processing is completed. This can occur many times during the lifecycle of a request. We use the function clock_gettime() on Linux to obtain the amount of CPU time, in nanoseconds, spent on each active interval of each request and accumulated along the way. At the end of the request’s lifecycle, we write the total CPU time consumed into the access log, the same way we treat the number of bytes transferred. The CPU time is included in the traffic summary log to generate low-latency, per-domain reports.
虽然此方法可以准确测量 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 请求的费用将被取消，因为相关费用将被更准确地涵盖。同时， 所有服务器组的流量价格 将显着减少。敬请期待！
