问为什么CDN对较大的文件使用push？

EN

这可以归结为用例，考虑一下拉力会更好的情况，并将其与推送的情况进行比较是很有帮助的。这可能不是一个完美的答案，但我在过去出于不同的原因使用了这两种方法，它们如下所示。

在进入示例之前，让我们先说以下几点：

PUSH CDN:使用PUSH CDN时，您作为管理员负责将实际内容推送到CDN。CDN本身不会自动填充缓存，您必须为其提供要服务的内容(这仍然可以自动化，但仍然需要将内容发送到CDN)。

• 每个CDN POPs都有内容，即使在第一次加载时也是如此。
• 减少维护缓存的服务器开销。由于您更新了推送区域中的内容，如果有要缓存的文件的新版本，CDN将不必检查原始服务器。

拉CDN:当使用拉CDN时，CDN负责创建要存储的文件的缓存。它本质上是向CDN提供的静态URL的反向代理，然后缓存满足缓存条件的文件。

• 减少了管理员的开销。您不需要担心将内容发送到CDN。

现在，为每个示例提供一个用例示例：

拉CDN:图像主机

你的用户不断地上传新的图片，这些图像获得了可观的观看量，然后最终消失了，只收到很少的视图。随着新内容的不断出现，CDN做所有工作都是有益的，即使这意味着第一次访问页面的访问者或在CDN中的元素和文件过期后试图打开网页的访问者可能会经历稍微慢一些的加载时间，因为CDN从原始服务器获取内容。

PUSH CDN:软件仓库

当您发布最新版本的软件时，您希望所有下载更新的用户都会突然涌入，这将提示您使用CDN。在公开发布之前，您需要确保您的软件在所有CDN POP上，以便将内容推送到CDN。您还保留所有以前的版本可供下载，所有这些文件将永远不会被更新。CDN不需要联系原始服务器来检查当前正在缓存的文件的状态。

结论

为什么CDN推送区域对于更大的文件更理想？

正如我在上面所展示的，当涉及到您想要使用的CDN类型时，用例是一个更大的决定因素，而不一定是要缓存的文件的大小。无论是在CDN缓存被您希望为最终结果服务的文件填充之后使用推区还是拉区，对用户来说都是一样的。对于较大的文件来说，Push区域更理想，因为发送到源服务器的开销较小。

意见:我也相信，如果你特别需要一个CDN来承载更大的文件，那么使用推送区域就可以更多地与你的最终目标保持一致。